Securing Your Infrastructure

Securing Your Infrastructure

From SSH to AI Agents — Securing Every Layer of Your Stack

Secure your server infrastructure — SSH, firewalls, TLS, monitoring, Fail2ban, and incident response. Concrete examples, commands, and checklists for Ubuntu VPS.

180 pages DE, EN, ES, FR, JA, KO, PT, RU, TH

Ce que vous allez apprendre

  • You know how to connect to a server via SSH.
  • You know what a Docker container, a reverse proxy, and an API are.
  • You have an AI agent capable of executing commands on your server (Hermes, Claude Code, etc.).
  • You do not need to be a security expert — that's the purpose of this book.
  • Chapter 1** — Securing an Ubuntu VPS: SSH, firewall, monitoring, incident response. The foundations without which everything else is useless.
  • Chapter 2** — Securing a web server: TLS, security headers, Docker, FastAPI, rate limiting. What protects your users when they access your services.
  • Chapter 3** — Securing autonomous AI agents: prompt injection, permissions, sandboxing, kill switches. The new frontier of security in 2026.
  • Chapter 4** — Complete checklist: pre-deployment, monthly audit, automated tools. Consolidating everything into a reproducible process.

Chapitres détaillés

  • Introduction
    • My server isn't interesting to hackers — true or false?
    • Why this book
    • How to use this book
    • Prerequisites
    • What you will learn
    • A word on examples
    • Security is a process
  • Chapter 1: Securing an Ubuntu VPS
    • 1.1 SSH — the entry point
  • 1.2 Firewall (UFW)
    • 1.2 Firewall (UFW)
  • 1.3 Monitoring and logs
    • 1.3 Monitoring and logs
  • 1.4 Incident response — what to do when it happens
    • 1.4 Incident response — what to do when it happens
  • 1.5 Automatic Updates
    • 1.5 Automatic Updates
    • Chapter Summary
  • 1.6 Fail2ban — Automatically banning attackers
    • 1.6 Fail2ban — Automatically banning attackers
  • 1.7 Audit Prompts — Ubuntu VPS
    • 1.7 Audit Prompts — Ubuntu VPS
  • 2.1 TLS — Encrypting Communications
    • HTTP vs HTTPS: What YOU Lose Without TLS
    • TLS 1.3 vs 1.2: Why Upgrade
    • Certificates: The Logic, Not the Commands
    • HSTS: Forcing HTTPS
    • Mixed Content: When HTTPS Doesn't Protect
    • AI Prompt: TLS Configuration Audit
  • 2.2 Security Headers
    • Why HTTP Headers Are Your First Line of Web Defense
    • Content-Security-Policy: The Most Powerful Header
    • X-Frame-Options: Anti-Clickjacking
    • X-Content-Type-Options: Anti-MIME Sniffing
    • Referrer-Policy: Controlling What Is Shared
    • Permissions-Policy: Restricting Browser APIs
    • AI Prompt: Security Headers Audit
  • 2.3 Rate limiting and WAF
    • Why rate limit
    • Rate limit vs throttling
    • Where to apply rate limiting
    • Common rate limiting mistakes
    • WAF: when it's useful, when it's not enough
    • fail2ban for Nginx: the firewall ↔ web link
    • AI Prompt: rate limiting and WAF audit
  • 2.4 Docker — Isolation and Containment
    • Why a container is not a virtual machine
    • Container escape: how an attacker breaks out of a container
    • Never run as root
    • Resource limits: CPU, memory, disk
    • Docker Compose: separate to limit the blast radius
    • AI Prompt: Docker security audit
  • 2.5 FastAPI — Securing the API
    • CORS: Why it's necessary and when it's a risk
    • Input Validation: Pydantic as Defense in Depth
    • Secrets Management: .env files are not enough in production
    • Secure Logging: Never log tokens
    • AI Prompt: FastAPI API Security Audit
  • 2.6 WAF — Web Application Firewall
    • 2.6 WAF — Web Application Firewall
  • 2.7 CI/CD Security — Securing the Deployment Pipeline
    • 2.7 CI/CD Security — Securing the Deployment Pipeline
  • 2.8 Audit Prompts — Nginx, FastAPI, Docker
    • 2.8 Audit Prompts — Nginx, FastAPI, Docker
  • 3.1 Why AI Agents Are Different
    • An AI Agent Makes Decisions — Traditional Software Only Executes
    • The Attack Surface Is No Longer the Code, It's the Prompt
    • Real-World Case: The Meta Incident (March 2026)
    • Real-World Case: Summer Yue — The Deleted Inbox
    • The Lessons for Your Infrastructure
  • 3.2 Prompt injection — understanding the attack
    • Direct injection: manipulating the user prompt
    • Indirect injection: controlling the content the agent consumes
    • Why content filtering is insufficient
    • The permissions approach, not filtering
    • Real-world examples of successful attacks
  • 3.3 Permissions and Least Privilege
    • Why an AI Agent Should Have Fewer Rights Than You
    • Read-only vs read-write: Deciding per Action
    • API Scopes: Limiting Each Token to Its Purpose
    • Automatic Permission Expiration
    • AI Prompt: Audit an AI Agent's Permissions
  • 3.4 Sandboxing, kill switches, and auditability
    • Why an agent must run in an isolated environment
    • Containers, isolated networks, read-only filesystems
    • Hard gates vs soft prompts
    • Kill switches: the emergency stop button
    • Logs: every action must be traced
    • Masking and canary data
    • AI prompt: verifying an agent's fail-safes
  • 3.5 Control of Sensitive Tools and Logs
    • 3.5 Control of Sensitive Tools and Logs
  • 3.6 Audit Prompts — Autonomous AI Agents
    • 3.6 Audit Prompts — Autonomous AI Agents
  • 4.1 Pre-deployment checklist
    • VPS: SSH, firewall, users, updates
    • Docker: isolation, users, resource limits
    • API: headers, CORS, rate limiting, secrets
    • AI Agent: permissions, sandboxing, kill switch, logs
  • 4.2 Automated Auditing Tools
    • Lynis: Complete Machine Scanner
    • Trivy: Container and Image Vulnerabilities
    • docker-bench-security: CIS Docker Benchmark
    • Mozilla Observatory: HTTP Headers
    • Integration into a Monthly Workflow
    • AI Prompt: Run and Interpret a Complete Audit
  • 4.3 Monthly Audits and Frameworks
    • Why a Single Audit Is Not Enough
    • The 7 Essential Monthly Checks
    • When a Tool Flags a Vulnerability
    • Reference Frameworks: NIST, CIS, OWASP
  • 4.4 Audit Prompts — Complete Infrastructure
    • 4.4 Audit Prompts — Complete Infrastructure
  • Conclusion
    • Security is a process, not a state
    • Recap: the core principles
    • Next steps
    • Glossary
    • Additional resources

Ce qui rend ce livre différent

Cypher Aeon Veda

There are hundreds of security guides on the internet. Blogs, videos, official documentation. But most suffer from one issue: they are either too theoretical (pages of concepts with no practical application) or too practical (lists of commands to copy-paste without understanding what they do).

This book takes a different approach.

Each chapter follows the same cycle:

  1. Understand — Why this security layer exists, what happens if it's missing, what the real risks are.
  2. Understand the principles — Reference frameworks (OWASP, CIS, NIST) explained in plain terms, not copy-pasted.
  3. Act via your AI agent — A ready-to-copy-paste prompt for your AI agent (Hermes, Claude Code, Cursor, or any other tool) so it audits your infrastructure and suggests corrections.

You won't need to memorize commands. You will understand why each security measure is necessary, and you will know how to ask your AI agent to verify that everything is in place.

Formats et compatibilité

Ebook

EPUB + PDF. Lisible sur Kindle, tablette, smartphone, PC.

Questions fréquentes

My server isn't interesting to hackers — true or false?
This is the phrase we hear most often when discussing server security. The reality is different: automated bots scan everything. Your VPS is not a target, but a number in a botnet. Brute-force SSH attacks start within hours of a fresh server going online.
How to use this book
**If you are a beginner** — Read the chapters in order. Each one builds on the previous one. **If you already have experience** — Jump to the chapters you need. The audit prompts at the end of each section are especially useful.
What you will learn
- **Chapter 1** — Securing an Ubuntu VPS: SSH, firewall, monitoring. - **Chapter 2** — TLS: certificates, mixed content, HTTP headers. - **Chapter 3** — Fail2ban, incident response, and ongoing security practices.
A word on examples
All examples in this book are generic. You won't find any ready-to-copy-paste commands for your specific setup — instead, you'll understand the logic behind each measure and be able to adapt it.
Security is a process
One last thing before we begin: there is no such thing as a "secured" server. Security is a continuous process. Today's best practices may be tomorrow's vulnerabilities. The goal is to raise the bar high enough to deter opportunistic attacks.
SSH — the entry point
SSH is the primary attack vector. Default port 22 is scanned millions of times daily. Key-based authentication, disabled root login, and fail2ban are your first line of defense.
Monitoring and logs
You can't protect what you can't see. Setting up basic monitoring (Uptime Kuma, Grafana) and log analysis (journalctl, logrotate) lets you detect attacks before they succeed.
Incident response — what to do when it happens
1) Don't panic. 2) Isolate the affected server. 3) Preserve logs. 4) Identify the breach. 5) Patch and restore. Having a pre-written incident response plan saves critical time.