Comment faire face à cette attaque par déni de service sur un serveur Apache?
J'ai été la cible de différentes attaques aujourd'hui. Le dernier a créé ce trafic sur le port 80. Apache est en panne et la charge sur le serveur reste élevée.
Le pare-feu est activé. Aucune suggestion?
15:27:10.203993 IP 188.125.110.42.38818 > 190.10.34.115.http: Flags [S], seq 3395115767, win 29200, options [mss 1460,sackOK,TS val 22777069 ecr 0,nop,wscale 7], length 0
15:27:10.204050 IP 103.21.182.66.62502 > 190.10.34.115.http: Flags [S], seq 3158122291, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
15:27:10.204079 IP 50.143.120.99.54622 > 190.10.34.115.http: Flags [S], seq 3624243404, win 29200, options [mss 1460,sackOK,TS val 273756706 ecr 0,nop,wscale 7], length 0
15:27:10.204128 IP 62.216.187.156.42248 > 190.10.34.115.http: Flags [S], seq 846253572, win 29200, options [mss 1460,sackOK,TS val 523062741 ecr 0,nop,wscale 7], length 0
15:27:10.204305 IP 23.105.195.199.38172 > 190.10.34.115.http: Flags [S], seq 2631287484, win 14600, options [mss 1460,sackOK,TS val 2125155826 ecr 0,nop,wscale 7], length 0
15:27:10.204774 IP 76.111.172.248.39602 > 190.10.34.115.http: Flags [S], seq 2199780458, win 29200, options [mss 1460,sackOK,TS val 249941894 ecr 0,nop,wscale 7], length 0
15:27:10.204797 IP 104.154.65.106.44962 > 190.10.34.115.http: Flags [S], seq 2397138535, win 28400, options [mss 1420,sackOK,TS val 1992688634 ecr 0,nop,wscale 7], length 0
Edit: This était notre solution au problème.
Il s'agit d'une attaque par inondation SYN classique, les mesures préventives comprennent
- hachage des paquets de synchronisation, implémentation des cookies de synchronisation
- vérifier si le client envoie correctement la TVD après qu'un paquet invalide lui a été renvoyé
- le logiciel d'atténuation de ddos propose souvent de temporiser des paquets de synchronisation spécifiques basés sur un filtrage avancé
- ne stocke pas le paquet syn complet pour référence ultérieure, uniquement l'IP et le numéro de séquence (nécessite également un pare-feu/logiciel supplémentaire à installer de votre part)
Limiter le trafic NEW
Sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT
Limiter le trafic established
Sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT
Activez syncookies sur votre noyau (Recommandé par @ Rápli András )
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Installez et configurez ddos-deflate
Caractéristiques notables:
- Il est possible de mettre des adresses IP en liste blanche, via
/etc/ddos/ignore.ip.list.- Il est possible de mettre en liste blanche les noms d'hôtes, via
/etc/ddos/ignore.Host.list.- Fichier de configuration simple:
/etc/ddos/ddos.conf- Les adresses IP sont automatiquement débloquées après un délai préconfiguré (par défaut: 600 secondes)
- Le script peut s'exécuter en tant que tâche cron à la fréquence choisie via le fichier de configuration (par défaut: 1 minute)
- Le script peut s'exécuter en tant que démon à la fréquence choisie via le fichier de configuration (par défaut: 5 secondes)
- Vous pouvez recevoir des alertes par e-mail lorsque les adresses IP sont bloquées.
- Contrôle le blocage par état de connexion (voir man netstat).
- Détection automatique du pare-feu.
- Prise en charge d'APF, CSF et iptables.
- Enregistre les événements dans
/var/log/ddos.log- Utilise tcpkill pour réduire la quantité de processus ouverts par les attaquants.
RESOLU
Dans ce cas, il s'agissait d'une attaque synflood avec des sites compromis Wordpress qui ont généré des tonnes de trafic (pingback) vers notre site à Gbytes/heure.
Voici la description complète de l'attaque. Dans le référent/en-tête, vous pouvez lire "Wordpress" en tant qu'agent utilisateur: https://www.hyperborea.org/journal/2014/03/pingback-ddos/
Le blocage de ces adresses IP avec une règle de pare-feu (voir la liste dans le lien) a résolu le problème. Je partage la liste, sans aucune responsabilité de malédiction.
LISTE DE 5000 IP impliqué pour être bloqué avec un pare-feu.
La sortie que vous montrez suggère que vous recevez un flot de paquets SYN et ne répondez à aucun d'entre eux. En extrapolant à partir des chiffres indiqués, cela représente environ 7,5 kpps. Même en supposant une taille de paquet maximale de 60 octets d'en-tête IPv4 et 60 octets de TCP en-tête qui totalise toujours moins de 8 Mbit/s.
Donc, si votre connexion réseau est de 10 Mbit/s ou plus, vous devriez pouvoir absorber ce trafic en supposant que vous disposez d'une puissance de traitement suffisante pour gérer le nombre de paquets par seconde.
À partir des informations limitées de votre question, il est impossible de déterminer la cause de la charge actuelle. Il est possible que vos règles de pare-feu soient structurées de manière à ce que chaque paquet consomme une quantité importante de temps processeur dans le pare-feu. Si tel est le cas, vous devez restructurer vos règles de pare-feu pour être plus efficace.
Il semble que vous ayez configuré un pare-feu pour supprimer silencieusement tous les paquets. Cela peut en fait aggraver le problème car les clients légitimes retransmettent leurs paquets SYN jusqu'à ce que vous répondiez (ou que le client expire).
Plutôt que de supprimer silencieusement les paquets, je vous recommande de répondre à autant d'entre eux que votre bande passante en amont le permet. Les réponses devraient être soit des paquets SYN-ACK, soit des paquets RST.
Si vous rencontrez un déluge SYN où vous ne pouvez pas faire la différence entre les paquets d'attaque et les paquets légitimes, et si vous devez continuer à servir les demandes des clients légitimes, je vous recommande d'activer les cookies SYN comme suggéré dans le réponse = par Rápli.
Dans de telles circonstances, les cookies SYN peuvent faire la différence entre que votre serveur répond lentement sous la charge ou ne répond pas du tout.
Ne bloquez pas les adresses IP basées uniquement sur les paquets SYN. Si vous ne voyez qu'un paquet SYN, l'adresse IP source peut être usurpée. Et un blocage basé sur cela ne vous servira à rien et vous ouvrira à un autre type d'attaque DoS.
Si un client termine une négociation et envoie ensuite du trafic incorrect, vous pouvez envisager de bloquer l'adresse IP. Cependant, le faire avec IPv4 peut entraîner des dommages collatéraux, donc cela ne devrait être fait qu'en dernier recours. Si vous bloquez le trafic de cette façon, assurez-vous de répondre avec des paquets RST et assurez-vous que vos règles de pare-feu sont structurées de manière à pouvoir être évaluées avec une consommation CPU minimale.