🛡️ AWS EC2 – Guide Anti-Attaques (Flood, WAF, ALB, Shield, Linux Firewall)

1) Architecture anti-attaques AWS (simple, robuste)

Architecture recommandée (sans Cloudflare)

Internet → ALB (subnets publics) → EC2 (subnets privés) → services internes (DB, cache).
WAF sur ALB Logs ALB VPC Flow Logs CloudWatch alarms

Internet
  |
  v
[ALB public]
  |
  v
[Target Group]
  |
  v
[EC2 private]

Composant	Rôle anti-attaque	Résultat
ALB	Front unique, termination TLS, health checks, points de mesure.	Tu arrêtes d'exposer EC2 directement.
WAF	Blocage IP/CIDR, règles managées, rate limit, geo match.	Les floods L7 sont filtrés avant ton OS.
Security Groups	Policy stateful : EC2 accepte seulement depuis ALB.	Un bot ne peut pas frapper EC2 en direct.
VPC Flow Logs	Vision L3/L4 : qui parle à qui, volumes, ports.	Tu identifies rapidement la source.

Règles de base (à ne pas négocier)

EC2 ne doit pas avoir le port 443 exposé à Internet (SG inbound depuis ALB seulement).
ALB a un certificat TLS (ACM) et termine HTTPS au front (option : re-chiffrement vers EC2).
WAF attaché au ALB : IPSet + rate-based + règles managées.
Logs : ALB access logs activés, métriques/alertes CloudWatch.

Piège classique : garder une Elastic IP sur l'instance et exposer 443 directement. Dans ce cas, WAF ne protège pas le trafic direct vers l'instance.

Checklist : mise en place en console AWS (FR)

Créer un groupe cible (Target Group) pour l'EC2 (HTTP ou HTTPS selon choix).
Créer un répartiteur de charge d'application (ALB) dans 2 subnets publics.
Créer un écouteur (Listener) HTTPS:443 avec un certificat ACM.
Attacher le Target Group à l'ALB, configurer le health check (ex: /health).
Mettre le SG de l'EC2 : inbound 443 uniquement depuis le SG de l'ALB.
Créer un Web ACL (WAF), l'associer à l'ALB, ajouter IPSet + rate limit + managed rules.
Activer les logs ALB vers S3, activer VPC Flow Logs (si nécessaire).

2) Comprendre les attaques (pour bloquer intelligemment)

Attaques courantes sur un serveur web

Attaque	But	Où ça frappe	Remède principal
SYN flood	Épuiser la table de connexions TCP.	L4 (TCP) + kernel	Shield + tuning kernel + SG/NACL
Slow HTTP / Slow TLS	Garder des connexions ouvertes, occuper threads/workers.	L7 (HTTP) + app server	ALB timeouts + WAF rate limit + limites nginx
HTTP flood	Surconsommer CPU/app, saturer backend.	L7	WAF (rate-based) + cache + autoscaling
Scan / brute force	Découvrir endpoints, failles, auth.	L7	WAF managed rules + hardening app

Symptômes observables

Beaucoup de connexions mais peu de débit utile.
Timeouts côté clients, p95/p99 qui explose.
CPU élevé (TLS/app), ou conntrack saturé (L4).
Nginx : workers occupés, 499/504 qui augmentent, files d'attente.

Bon réflexe : identifier si c'est L4 (TCP) ou L7 (HTTP). L4 = beaucoup de SYN/handshakes. L7 = beaucoup de requêtes valides mais abusives.

Tests rapides sur l'instance (diagnostic)

ss -Htan state syn-recv sport = :443 | wc -l
ss -Htan state established sport = :443 | wc -l
ss -Htan sport = :443 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Si tu vois énormément de syn-recv, c'est plutôt L4. Si tu vois surtout established + HTTP errors côté app, c'est plutôt L7.

3) Observabilité (voir vite, décider vite)

Métriques ALB à surveiller (CloudWatch)

RequestCount, HTTPCode_ELB_5XX, HTTPCode_Target_5XX
TargetResponseTime (latence backend)
ActiveConnectionCount, NewConnectionCount
RejectedConnectionCount (si quotas/timeouts)

Si RequestCount explose et TargetResponseTime grimpe, tu es souvent en L7 (ou backend saturé). Si NewConnectionCount explose sans requêtes utiles, suspecte un flood L4/TLS.

Logs qui te donnent la vérité

Log	Où	Ce que tu obtiens
ALB Access Logs	S3	IP client, path, code, latence, user agent, target.
WAF logs	CloudWatch Logs / Kinesis / S3	Règle matchée, action, IP, country, URI.
VPC Flow Logs	CloudWatch Logs / S3	Flux L3/L4 : src/dst/ports, accept/reject.
Nginx access/error	EC2	Requêtes, temps, codes, saturation applicative.

Sans logs ALB/WAF, tu bloques "à l'aveugle". Active-les avant la prochaine crise.

Alertes (CloudWatch) simples et efficaces

ALB: HTTPCode_ELB_5XX > seuil (sur 5 min)
ALB: TargetResponseTime p95 > seuil
WAF: BlockedRequests > seuil (indicateur d'attaque en cours)
EC2: CPU > seuil (si tu termines TLS sur l'instance)

Ajoute une alerte "attaque" basée sur WAF BlockedRequests et une alerte "impact" basée sur p95.

4) Security Groups + ACL réseau (blocage L4 net)

Security Group (stateful) : règle idéale quand tu as ALB

EC2 inbound 443 : source = SG de l'ALB (et rien d'autre). Cela coupe 100% des attaques directes vers l'instance.

Cible	Inbound	Source	Pourquoi
ALB SG	443	0.0.0.0/0	Le front doit accepter Internet.
EC2 SG	443 (ou 80)	ALB SG	Seul l'ALB parle au backend.

ACL réseau (stateless) : blocage CIDR brut

L'ACL réseau est utile pour bloquer des ranges entiers quand tu es attaqué et que tu veux couper vite.

Numéro	Type	Ports	Source	Action
50	HTTPS	443	45.186.0.0/16	DENY
100	All traffic	All	0.0.0.0/0	ALLOW

En NACL, le champ "ports" doit matcher ton service. Port 0 ne match pas 443.

Pièges fréquents (ce qui casse tout)

NACL stateless : si tu fais des règles trop agressives, tu peux casser les retours.
Mauvaise association : modifier une ACL qui n'est pas celle du subnet de l'instance/ALB.
SG trop ouvert : EC2 qui accepte 0.0.0.0/0 sur 443 rend WAF inutile pour le trafic direct.

5) ALB (Application Load Balancer) : setup précis

Étapes (Console AWS FR) : ALB + HTTPS

Service : EC2 → Équilibreurs de charge → Créer un équilibreur de charge.
Choisir : Équilibreur de charge d'application.
Réseau : sélectionner 2 sous-réseaux publics (2 AZ différentes).
Sécurité : SG de l'ALB inbound 443 depuis 0.0.0.0/0.
Écouteurs : HTTPS:443 et sélectionner un certificat ACM.
Groupe cible : créer/choisir un Groupe cible pointant vers ton EC2.
Créer l'ALB, puis vérifier l'état des targets (healthy).

Une fois l'ALB en place, tu mets le SG de l'EC2 en mode "backend only" (inbound depuis SG ALB).

Health checks : endpoint minimal

Expose un endpoint simple /health qui répond vite, sans DB lourde.

curl -fsS http://127.0.0.1/health

Paramètres : intervalle (ex: 10s), timeout (ex: 5s), thresholds (ex: 3). L'objectif est de sortir une instance malade du pool avant que les clients souffrent.

Timeouts et comportements anti-slow

Idle timeout : réduit l'impact des connexions dormantes.
Limiter les keep-alive abusifs côté backend (nginx/app server).
Utiliser WAF rate-based pour couper les patterns de requêtes.

Les slow attacks passent souvent si tu n'as pas de timeouts cohérents (ALB + nginx + app).

6) AWS WAF : guide didactique (IPSet + rate limit + managed rules)

Créer un Web ACL (Console AWS FR)

Service : WAF et Shield → AWS WAF.
Web ACL → Créer un Web ACL.
Région : choisir la même région que l'ALB.
Ressource : sélectionner ton ALB.
Action par défaut : Autoriser (puis tes règles vont bloquer ce qui doit l'être).
Ajouter les règles : IPSet block, rate limit, managed rules.

WAF ne protège que ce qui est attaché. Si des clients touchent l'EC2 en direct, WAF ne voit pas ce trafic.

Bloquer un CIDR (IPSet)

WAF → Jeux d'adresses IP (IP sets) → Créer un jeu d'adresses IP.
Ajouter : 45.186.0.0/16 (IPv4).
Dans Web ACL → Ajouter une règle basée sur ce IPSet → action Bloquer.

Le blocage CIDR est efficace, mais non adaptatif. Combine avec rate limit pour les attaques distribuées.

Rate-based rule (coupe automatiquement)

La règle rate-based bloque une IP si elle dépasse un seuil sur une fenêtre. C'est la base anti-flood L7.

Web ACL → Ajouter règle → Règle basée sur le taux.
Définir le seuil (ex: 1000 sur 5 minutes) puis action : Bloquer.
Option : scope-down statement (ex: ne compter que /login).

Example thresholds:
- login endpoint: 200 / 5 min / IP
- global: 2000 / 5 min / IP

Règles managées AWS (indispensables)

Pack	But	Action
AWSManagedRulesCommonRuleSet	Bloque patterns web courants (bad inputs, path traversal).	Block
AWSManagedRulesKnownBadInputsRuleSet	Inputs connus malveillants.	Block
AWSManagedRulesSQLiRuleSet	SQL injection basique.	Block

Si tu as des faux positifs, ne désactive pas tout : ajoute des exceptions ciblées (scope-down).

Logs WAF : indispensable pour comprendre

Web ACL → Journalisation et métriques → activer la journalisation.
Destination : CloudWatch Logs (simple) ou Kinesis Firehose vers S3 (massif).
Vérifier : règle matchée, action, URI, headers utiles.

Mets une phase "Count" sur une règle avant "Block" si tu veux valider sans risque.

7) AWS Shield (DDoS volumétrique) : ce que ça fait vraiment

Shield Standard (inclus)

Shield Standard est actif par défaut sur des ressources AWS (ex: ALB) et vise les attaques DDoS volumétriques et certaines attaques L3/L4.

Règle pratique

Shield aide sur le volumétrique (gros débit, gros SYN).
WAF aide sur le L7 (beaucoup de requêtes HTTP, bots).
ALB te donne le point d'entrée unique et la visibilité.

Si l'attaque est "smart" (slow HTTP), Shield seul ne suffit pas. Il faut WAF + timeouts.

8) Linux hardening (firewall, kernel, services)

Firewall local (utile, mais pas suffisant seul)

Si tu as ALB, l'EC2 peut être fermé à Internet : le firewall local devient une 2e barrière, pas la 1re.

iptables -I INPUT -p tcp --dport 443 -s 45.186.0.0/16 -j DROP
iptables -I INPUT -p tcp --dport 22 -s 1.2.3.4/32 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

sysctl réseau (limiter l'impact des floods)

sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.ipv4.tcp_fin_timeout=15
sysctl -w net.ipv4.tcp_tw_reuse=1

Change ces paramètres avec prudence. Test en préprod si possible.

Nginx (anti-slow) : timeouts et limites

client_header_timeout 10s;
client_body_timeout 10s;
keepalive_timeout 15s;
send_timeout 10s;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;

Ajuste selon ton trafic. Le but est de couper les clients qui gardent la connexion ouverte trop longtemps.

SSH : réduire la surface d'attaque

Préférer SSM Session Manager (pas de port 22).
Sinon : SG port 22 uniquement depuis ton IP admin.

sshd -T | grep -E "passwordauthentication|permitrootlogin"

9) Runbook incident (actions immédiates, ordre exact)

0-5 minutes : stabiliser

Confirmer impact : latence, erreurs, disponibilité.
Voir si EC2 est touchée directement : SG inbound 443 depuis Internet ?
Si ALB présent : regarder métriques ALB + WAF.
Blocage immédiat : WAF IPSet (si range clair) + rate-based rule.
Si nécessaire : NACL deny CIDR sur 443 (en dernier recours).

ss -Htan sport = :443 | wc -l
top -b -n 1 | head
dmesg | tail -n 50

5-30 minutes : comprendre et durcir

Activer / vérifier logs ALB et WAF.
Identifier patterns : URI, user agents, IP ranges, countries.
Mettre règles WAF ciblées : rate limit sur endpoints sensibles.
Vérifier timeouts ALB et nginx.
Décider d'une amélioration structurelle : EC2 behind ALB + private subnet si ce n'est pas déjà le cas.

Postmortem (pour ne plus revivre ça)

Timeline : début, pic, actions, effet.
Qu'est-ce qui a cassé : L4, L7, CPU TLS, workers, conntrack.
Mesures permanentes : ALB, WAF, logs, alarms, SG backend-only.
Playbook : règles WAF pré-configurées en mode Count, puis bascule Block.

Le vrai "pare-feu AWS" durable, c'est : ALB + WAF + SG backend-only + logs + alarms.

🛡️ AWS EC2 – Anti-Attaques & Anti-Flood (ALB, WAF, Shield, Linux)

Architecture anti-flood AWS

Comprendre les attaques

Observabilité "anti-crash"

SG + ACL réseau

ALB : le "front" obligatoire

AWS WAF : blocage + rate limit

AWS Shield

Linux : firewall + kernel

Runbook incident (minute par minute)