Gérer les attaques HTTP w00tw00t

Je pense que la raison pour laquelle mod_security ne fonctionne pas pour vous est qu'Apache n'a pas été capable d'analyser les requêtes elles-mêmes, elles sont hors spécifications. Je ne suis pas sûr que vous ayez un problème ici - Apache enregistre les merdes bizarres qui se produisent sur le net, s'il ne les enregistre pas, vous ne serez même pas conscient qu'elles se produisent. Les ressources nécessaires pour enregistrer les requêtes sont probablement minimes. Je comprends que ce soit frustrant que quelqu'un remplisse vos journaux - mais ce sera encore plus frustrant si vous désactivez la journalisation pour découvrir que vous en avez vraiment besoin. Par exemple, quelqu'un s'est introduit dans votre serveur Web et vous avez besoin des journaux pour montrer comment il s'est introduit.

Une solution consiste à configurer la journalisation des erreurs via syslog, puis à utiliser rsyslog ou syslog-ng pour filtrer spécifiquement et écarter les violations de RFC concernant w00tw00t. Ou alternativement, vous pourriez les filtrer dans un fichier journal séparé simplement pour que votre journal d'erreurs principal soit facile à lire. Rsyslog est incroyablement puissant et flexible à cet égard.

Donc dans httpd.conf vous pourriez faire :

ErrorLog syslog:user 

alors dans rsyslog.conf vous pourriez avoir :

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

Attention, cette approche utilisera en fait plusieurs fois plus de ressources qu'à l'origine l'enregistrement direct dans un fichier. Si votre serveur web est très occupé, cela peut devenir un problème.

De toute façon, la meilleure pratique consiste à envoyer tous les journaux à un serveur de journalisation distant dès que possible, ce qui vous sera utile en cas d'effraction, car il est beaucoup plus difficile d'effacer la piste d'audit de ce qui a été fait.

Le blocage IPTables est une idée, mais vous risquez de vous retrouver avec une liste de blocage iptables très importante, ce qui peut avoir des répercussions sur les performances en soi. Les adresses IP présentent-elles un modèle ou proviennent-elles d'un vaste botnet distribué ? Il faut qu'il y ait X % de doublons pour que vous puissiez tirer profit d'iptables.

Vous dites dans la mise à jour 2 :

Problème qui subsiste Le problème qui subsiste est le suivant. Ces attaques proviennent de bots qui recherchent certains fichiers sur votre serveur. Cet analyseur particulier recherche le fichier /w00tw00t.at.ISC.SANS.DFind :).

Maintenant, vous pouvez simplement l'ignorer, ce qui est le plus recommandé. Le problème reste que si ce fichier se trouve un jour sur votre serveur, vous aurez des problèmes.

D'après ma réponse précédente, nous avons compris qu'Apache renvoie un message d'erreur en raison d'une requête HTML 1.1 mal formée. Tous les serveurs web supportant HTTP/1.1 devraient probablement retourner une erreur lorsqu'ils reçoivent ce message (je n'ai pas vérifié la RFC - peut-être que la RFC2616 nous le dit).

Avoir w00tw00t.at.ISC.SANS.DFind : sur votre serveur quelque part ne signifie pas mystiquement "vous avez des problèmes"... Si vous créez le fichier w00tw00t.at.ISC.SANS.DFind : dans votre DocumentRoot ou même DefaultDocumentRoot, cela n'a pas d'importance... le scanner envoie une requête HTTP/1.1 cassée et Apache dit "non, c'est une mauvaise requête... au revoir". Les données contenues dans le fichier w00tw00t.at.ISC.SANS.DFind : ne seront pas servies.

L'utilisation de mod_security dans ce cas n'est pas nécessaire, sauf si vous le voulez vraiment (aucun intérêt ?)... dans ce cas, vous pouvez regarder Parcheando manuellement (lien dans l'autre réponse).

Vous pouvez également envisager d'utiliser la fonction RBL du module Security. Il existe peut-être une RBL en ligne qui fournit des adresses IP w00tw00t (ou d'autres adresses IP malveillantes connues). Cela signifie toutefois que mod_security effectue une recherche DNS pour chaque requête.

Pourquoi ne pas ajouter une règle à la modsécurité ? Quelque chose comme ceci :

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

Je constate que la plupart des solutions sont déjà couvertes ci-dessus. le client a envoyé une requête HTTP/1.1 sans nom d'hôte Les attaques visent directement votre serveur. Il existe de nombreuses tentatives d'empreintes digitales et/ou d'exploitation du système de réseau qui précède votre serveur, par exemple en utilisant.. :

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

pour cibler les routeurs Linksys, etc. Il est donc parfois utile d'élargir son champ d'action et de répartir ses efforts de défense entre tous les systèmes à parts égales, c'est-à-dire : mettre en place des règles pour les routeurs, mettre en place des règles pour les pare-feu (si tout va bien, votre réseau en a un), mettre en place des règles pour les pare-feu et les tables IP des serveurs et les services associés, c'est-à-dire mod_security, fail2ban, etc.

Que pensez-vous de cela ?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

fonctionne bien pour moi.