# Pare-feu (firewall) : filtre le trafic selon des règles (IP source/dest, port, protocole, état)
Stateless : évalue chaque paquet indépendamment (rapide, moins précis)
Stateful  : suit l'état des connexions (ex: n'autorise une réponse que si la requête sortante existe)

# iptables : règles de base pour un serveur exposant une API web (drop par défaut = whitelist)
iptables -P INPUT DROP                                   # tout refuser par défaut en entrée
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -A INPUT -i lo -j ACCEPT                         # autoriser loopback
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT  # autoriser les réponses aux connexions sortantes
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT       # SSH uniquement depuis le réseau admin
iptables -A INPUT -p tcp --dport 443 -j ACCEPT             # HTTPS ouvert au public
iptables -A INPUT -p tcp --dport 80 -j ACCEPT              # HTTP (redirection vers HTTPS uniquement)
iptables -A INPUT -j LOG --log-prefix "IPTABLES-DROPPED: " # journaliser avant le drop final implicite

# nftables (successeur moderne d'iptables), équivalent plus lisible
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input iifname "lo" accept
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport 22 ip saddr 10.0.0.0/24 accept
nft add rule inet filter input tcp dport 443 accept

# Segmentation réseau : limiter le "blast radius" d'une compromission
DMZ (zone démilitarisée)  : serveurs exposés publiquement (reverse proxy, API gateway)
Réseau applicatif         : services backend, isolés du réseau public direct
Réseau de données          : bases de données, accessible UNIQUEMENT depuis le réseau applicatif
Réseau d'administration    : accès SSH/bastion, isolé, accès restreint par IP + MFA

# Règle d'or : la base de données ne doit JAMAIS être directement joignable depuis Internet

# Exemple de segmentation avec Docker Compose : réseaux internes séparés
services:
  api:
    build: ./backend
    networks: [frontend_net, backend_net]

  db:
    image: postgres:16
    networks: [backend_net]        # PAS de réseau frontend -> injoignable depuis l'extérieur
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password

  reverse_proxy:
    image: nginx:alpine
    networks: [frontend_net]
    ports: ["443:443"]

networks:
  frontend_net:
  backend_net:
    internal: true                 # aucune route vers l'extérieur, isolation forte

# IDS (Intrusion Detection System) vs IPS (Intrusion Prevention System)
IDS : détecte et alerte, n'intervient pas sur le trafic (passif, en dérivation - "tap"/"span port")
IPS : détecte ET bloque en temps réel, en ligne sur le chemin du trafic (actif)

# Approches de détection
Signature-based : compare le trafic à une base de signatures d'attaques connues (rapide, faux négatifs sur 0-day)
Anomaly-based   : détecte les écarts par rapport à une baseline de trafic normal (détecte l'inconnu, plus de faux positifs)

# Suricata : IDS/IPS open-source, exemple de règle personnalisée détectant un scan de ports agressif
# /etc/suricata/rules/local.rules
alert tcp any any -> $HOME_NET any (msg:"Scan de ports détecté - nombreuses connexions courtes";   flags:S; threshold:type both, track by_src, count 20, seconds 10; sid:1000001; rev:1;)

# Lancer Suricata en mode IDS (écoute passive) sur une interface réseau
suricata -c /etc/suricata/suricata.yaml -i eth0

# fail2ban : réagit aux logs (ex: échecs SSH répétés) en ajoutant des règles de blocage dynamiques
# /etc/fail2ban/jail.local
cat <<'EOF' > /etc/fail2ban/jail.local
[sshd]
enabled = true
port    = 22
maxretry = 5
findtime = 600
bantime  = 3600
EOF
systemctl restart fail2ban
fail2ban-client status sshd