Linux: éviter les inondations TCP sortantes

Je gère plusieurs centaines de serveurs Web derrière des équilibreurs de charge, hébergeant de nombreux sites différents avec une pléthore d'applications (dont je n'ai aucun contrôle). Environ une fois par mois, l'un des sites est piraté et un script d'inondation est téléchargé pour attaquer une banque ou une institution politique. Dans le passé, il s'agissait toujours d'inondations UDP qui ont été résolues efficacement en bloquant le trafic UDP sortant sur le serveur Web individuel. Hier, ils ont commencé à inonder une grande banque américaine de nos serveurs en utilisant de nombreuses connexions TCP vers le port 80. Comme ce type de connexions est parfaitement valable pour nos applications, le simple fait de les bloquer n'est pas une solution acceptable.

J'envisage les alternatives suivantes. Lequel recommanderiez-vous? Les avez-vous mis en œuvre et comment?

• Limiter le nombre de paquets TCP sortants du serveur Web (iptables) avec le port source! = 80
• Idem mais avec file d'attente (tc)
• Taux limite de trafic sortant par utilisateur et par serveur. Un fardeau administratif, car il y a potentiellement des milliers d'utilisateurs différents par serveur d'applications. Peut-être ceci: comment puis-je limiter la bande passante par utilisateur?
• Rien d'autre?

Naturellement, je cherche également des moyens de minimiser les risques de piratage sur l'un de nos sites hébergés, mais comme ce mécanisme ne sera jamais 100% étanche, je souhaite limiter sévèrement l'impact d'une intrusion.

Mise à jour: je teste actuellement avec ces règles, cela aurait empêché cette attaque spécifique. Comment proposeriez-vous de les rendre plus génériques? Suis-je en train de manquer une attaque TCP DoS connue lorsque je ne limite que le débit sur les paquets SYN?

iptables -A OUTPUT -p tcp --syn -m limit --limit 100/min -j ACCEPT
iptables -A OUTPUT -p tcp --syn -m limit --limit 1000/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -p tcp --syn -j REJECT --reject-with tcp-reset

À votre santé!

La meilleure solution possible à mon avis et celle qui a très bien fonctionné pour moi est de limiter le nombre de connexions / paquets pour la destination ip. Fixer la limite à un taux raisonnable empêchera l'attaquant d'envoyer une grande quantité de connexions à la cible. La définition du port et du protocole n'est pas une bonne idée car si l'attaquant envoie http flood aujourd'hui, il utilisera demain un type d'attaque différent. donc limiter les connexions par ip comme général serait une solution à votre problème.

J'espère que ça aide :)

La position que j'ai toujours adoptée est qu'un serveur Web ne devrait pas du tout établir de connexions TCP sortantes - uniquement envoyer du trafic en tant que serveur répondant aux demandes entrantes. (J'autorise également le TCP entrant uniquement pour le serveur Web et SSH.) (À ce sujet, je pense également qu'un serveur Web n'est jamais le bon hôte à partir duquel envoyer du courrier.) Cela n'empêchera pas seulement les attaques sortantes - cela ajoute également un peu de difficulté aux attaques lancées sur vos systèmes (les pirates informatiques ne peuvent pas obtenir une fenêtre xterm ou mettre leur boîte à outils à la disposition de votre hôte).