Gestione degli attacchi HTTP w00tw00t

Ho un server con apache e di recente ho installato mod_security2 perché mi viene molto attaccato da questo:

La mia versione di apache è apache v2.2.3 e utilizzo mod_security2.c

Queste erano le voci dal registro degli errori:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Ecco gli errori da access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

Ho provato a configurare mod_security2 in questo modo:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

La cosa in mod_security2 è che SecFilterSelective non può essere usato, mi dà errori. Invece uso una regola come questa:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Anche questo non funziona. Non so più cosa fare. Qualcuno ha qualche consiglio?

Aggiornamento 1

Vedo che nessuno può risolvere questo problema usando mod_security. Finora l'utilizzo di ip-tables sembra l'opzione migliore per farlo, ma penso che il file diventerà estremamente grande perché l'ip cambia server volte al giorno.

Ho escogitato altre 2 soluzioni, qualcuno può commentarle per essere bravo o no.

1. La prima soluzione che mi viene in mente è escludere questi attacchi dai miei log degli errori di Apache. Questo renderà più facile per me individuare altri errori urgenti quando si verificano e non è necessario sputare attraverso un lungo registro.

2. La seconda opzione è migliore, penso, e sta bloccando gli host che non vengono inviati nel modo corretto. In questo esempio l'attacco w00tw00t viene inviato senza nome host, quindi penso di poter bloccare gli host che non sono nella forma corretta.

Aggiornamento 2

Dopo aver esaminato le risposte sono giunto alle seguenti conclusioni.

1. Avere la registrazione personalizzata per apache consumerà alcune risorse non necessarie e, se c'è davvero un problema, probabilmente vorrai guardare il registro completo senza nulla mancare.

2. È meglio semplicemente ignorare gli hit e concentrarsi su un modo migliore di analizzare i log degli errori. L'uso dei filtri per i tuoi registri è un buon approccio per questo.

Considerazioni finali sull'argomento

L'attacco di cui sopra non raggiungerà la tua macchina se almeno hai un sistema aggiornato, quindi praticamente non ci sono preoccupazioni.

Dopo un po 'può essere difficile filtrare tutti gli attacchi fasulli da quelli reali, perché sia ​​i registri degli errori che i registri degli accessi diventano estremamente grandi.

Prevenire che ciò accada in alcun modo ti costerà risorse ed è una buona pratica non sprecare le tue risorse su cose non importanti.

La soluzione che uso ora è logwatch Linux . Mi invia riassunti dei registri e questi vengono filtrati e raggruppati. In questo modo puoi facilmente separare l'importante dall'importante.

Grazie a tutti per l'aiuto e spero che questo post possa essere utile anche a qualcun altro.

Dal tuo registro degli errori stanno inviando una richiesta HTTP / 1.1 senza l'host: parte della richiesta. Da quello che ho letto, Apache risponde con un errore 400 (cattiva richiesta) a questa richiesta, prima di passare a mod_security. Quindi, non sembra che le tue regole verranno elaborate. (Apache lo gestisce prima di richiedere la consegna a mod_security)

Mettiti alla prova:

nome host telnet 80
OTTIENI /blahblahblah.html HTTP / 1.1 (invio)
(accedere)

Dovresti ottenere l'errore 400 e vedere lo stesso errore nei tuoi registri. Questa è una cattiva richiesta e Apache sta dando la risposta corretta.

La richiesta corretta dovrebbe apparire come:

OTTIENI /blahblahblah.html HTTP / 1.1
Presentatore: blah.com

Una soluzione a questo problema potrebbe essere la modifica di mod_uniqueid, per generare un ID univoco anche per una richiesta non riuscita, in modo che apache trasmetta la richiesta ai gestori delle richieste. Il seguente URL è una discussione su questo lavoro in giro e include una patch per mod_uniqueid che potresti usare: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Non sono riuscito a trovare altre soluzioni per esso e mi chiedo se una soluzione sia effettivamente richiesta.

Filtrare gli IP non è una buona idea, imho. Perché non provare a filtrare la stringa che conosci?

Intendo:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

Iv ha anche iniziato a vedere questi tipi di messaggi nei miei file di registro. Un modo per prevenire questo tipo di attacchi è installare fail2ban ( http://www.fail2ban.org/ ) e impostare filtri specifici per inserire nella black list questi indirizzi IP nelle regole di iptables.

Ecco un esempio di filtro che bloccherebbe l'indirizzo IP associato alla creazione di quei messaggi

[Mar 16 ago 02:35:23 2011] [errore] [client] Il file non esiste: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t jail messaggi - regex e filter === Jail

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Filtro

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

w00tw00t.at.blackhats.romanian.anti-sec è un tentativo di hacking e utilizza spoof IP, quindi ricerche come VisualRoute segnaleranno Cina, Polonia, Danimarca ecc. in base all'IP assegnato in quel momento. Quindi impostare un Deny IP o un nome host risolvibile è quasi impossibile in quanto cambierà entro un'ora.

Personalmente ho scritto uno script Python per aggiungere automaticamente le regole IPtables.

Ecco una versione leggermente abbreviata senza registrazione e altra spazzatura:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

Credo che il motivo per cui mod_security non funzioni per te sia che Apache non è stato in grado di analizzare le richieste da solo, sono fuori specifica. Non sono sicuro che tu abbia un problema qui - Apache sta registrando strane cazzate che stanno accadendo in rete, se non lo registra non sarai consapevole del fatto che sta accadendo. Le risorse necessarie per registrare le richieste sono probabilmente minime. Capisco che è frustrante che qualcuno stia riempiendo i tuoi registri, ma sarà più frustrante se disabiliti la registrazione solo per scoprire che ne hai davvero bisogno. Come se qualcuno avesse fatto irruzione nel tuo server web e tu avessi bisogno dei registri per mostrare come sono entrati.

Una soluzione consiste nell'impostare la registrazione degli errori tramite syslog e quindi utilizzando rsyslog o syslog-ng è possibile filtrare e scartare in modo specifico queste violazioni RFC relative a w00tw00t. Oppure, in alternativa, puoi filtrarli in un file di registro separato in modo che il tuo ErrorLog principale sia di facile lettura. Rsyslog è incredibilmente potente e flessibile in questo senso.

Quindi in httpd.conf potresti fare:

ErrorLog syslog:user 

quindi in rsyslog.conf potresti avere:

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

Attenzione, questo approccio utilizzerà molte volte più risorse rispetto alla registrazione utilizzata originariamente direttamente in un file. Se il tuo server web è molto occupato, questo potrebbe diventare un problema.

È consigliabile che tutti i log vengano inviati a un server di registrazione remoto il più presto possibile e ciò sarà vantaggioso in caso di violazione, poiché è molto più difficile cancellare la traccia di controllo di ciò che è stato fatto.

Il blocco di IPTables è un'idea, ma potresti finire con un elenco di blocchi iptables molto grande che può avere implicazioni in termini di prestazioni. C'è un modello negli indirizzi IP o proviene da una grande botnet distribuita? Ci sarà bisogno dell'X% di duplicati prima di ottenere un vantaggio da iptables.

Dici nell'aggiornamento 2:

Problema che rimane Il problema che rimane è il seguente. Questi attacchi provengono da robot che cercano determinati file sul tuo server. Questo particolare scanner cerca il file /w00tw00t.at.ISC.SANS.DFind :).

Ora puoi semplicemente ignorarlo, che è più raccomandato. Il problema rimane che se un giorno hai questo file sul tuo server, hai qualche problema.

Dalla mia precedente risposta abbiamo scoperto che Apache sta restituendo un messaggio di errore a causa di una query HTML 1.1 scarsamente formata. Tutti i server web che supportano HTTP / 1.1 dovrebbero probabilmente restituire un errore quando ricevono questo messaggio (non ho ricontrollato la RFC - forse RFC2616 ci dice).

Avere w00tw00t.at.ISC.SANS.DFind: sul tuo server un po 'dove non significa misticamente "sei nei guai" ... Se crei il file w00tw00t.at.ISC.SANS.DFind: file nel tuo DocumentRoot o anche DefaultDocumentRoot non importa ... lo scanner sta inviando una richiesta HTTP / 1.1 non funzionante e apache sta dicendo "no, è una cattiva richiesta ... ciao". I dati nel file w00tw00t.at.ISC.SANS.DFind: il file non verrà servito.

L'uso di mod_security per questo caso non è richiesto a meno che tu non voglia davvero (nessun punto?) ... in tal caso, puoi guardare patch manualmente (link in altra risposta).

Un'altra cosa che potresti guardare è l'utilizzo della funzione RBL in mod_security. Forse esiste un RBL online che fornisce IP w00tw00t (o altri IP dannosi noti). Ciò significherebbe tuttavia che mod_security esegue una ricerca DNS per ogni richiesta.

Che ne dici di aggiungere una regola a modsecurity? Qualcosa come questo:

   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'"

Vedo che la maggior parte delle soluzioni sono già trattate sopra, tuttavia vorrei sottolineare che non tutti i client hanno inviato una richiesta HTTP / 1.1 senza attacchi del nome host e sono indirizzati direttamente sul tuo server. Esistono molti tentativi diversi di impronte digitali e / o sfruttamento del sistema di rete che precede il server, ad esempio utilizzando:

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

per indirizzare i router Linksys ecc. Quindi a volte aiuta ad ampliare la concentrazione e a dividere le attività di difesa tra tutti i sistemi con una condivisione uguale, ad esempio: implementare le regole del router, implementare le regole del firewall (si spera che la rete ne abbia uno), implementare il firewall del server / tabella IP regole e servizi correlati, ad esempio mod_security, fail2ban e così via.

cosa ne pensi di questo ?

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:

funziona bene per me.

Se si utilizza hiawathaun server Web come reverse proxyquesti scansioni vengono automaticamente eliminati come immondizia e clientvietati. Filtra XSSe CSRFsfrutta anche.