Radzenie sobie z atakami HTTP w00tw00t

Mam serwer z Apache i niedawno zainstalowałem mod_security2, ponieważ często mnie atakują:

Moja wersja apache to apache v2.2.3 i używam mod_security2.c

To były wpisy z dziennika błędów:

[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:)

Oto błędy z dziennika dostępu:

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

Próbowałem skonfigurować mod_security2 w następujący sposób:

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:\)"

Rzeczą w mod_security2 jest to, że SecFilterSelective nie może być używany, daje mi błędy. Zamiast tego używam następującej reguły:

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:\)"

Nawet to nie działa. Nie wiem już, co mam robić. Czy ktoś ma jakąś radę?

Aktualizacja 1

Widzę, że nikt nie może rozwiązać tego problemu za pomocą mod_security. Jak dotąd używanie ip-tabel wydaje się najlepszą opcją, ale myślę, że plik stanie się bardzo duży, ponieważ ip zmienia się kilka razy dziennie.

Wymyśliłem 2 inne rozwiązania, czy ktoś może komentować je jako dobre, czy nie.

1. Pierwszym rozwiązaniem, jakie przychodzi mi do głowy, jest wykluczenie tych ataków z moich dzienników błędów apache. Ułatwi mi to wykrycie innych pilnych błędów, gdy się pojawią, i nie muszę przeszukiwać długiego dziennika.

2. Myślę, że druga opcja jest lepsza i polega na blokowaniu hostów, które nie są wysyłane w prawidłowy sposób. W tym przykładzie atak w00tw00t jest wysyłany bez nazwy hosta, więc myślę, że mogę zablokować hosty, które nie są w prawidłowej formie.

Aktualizacja 2

Po przejrzeniu odpowiedzi doszedłem do następujących wniosków.

1. Aby mieć niestandardowe rejestrowanie dla apache, zużyjesz trochę niepotrzebnych odwołań, a jeśli naprawdę istnieje problem, prawdopodobnie będziesz chciał zajrzeć do pełnego dziennika bez niczego brakującego.

2. Lepiej po prostu zignorować trafienia i skoncentrować się na lepszym sposobie analizy dzienników błędów. Dobrym rozwiązaniem jest stosowanie filtrów do dzienników.

Ostatnie przemyślenia na ten temat

Wspomniany wyżej atak nie dotrze do twojej maszyny, jeśli masz przynajmniej aktualny system, więc zasadniczo nie martw się.

Po pewnym czasie może być trudno odfiltrować wszystkie fałszywe ataki od prawdziwych, ponieważ zarówno dzienniki błędów, jak i dzienniki dostępu stają się bardzo duże.

Zapobieganie temu w jakikolwiek sposób będzie cię kosztować zasoby i dobrą praktyką jest nie marnowanie zasobów na nieistotne rzeczy.

Rozwiązaniem, którego teraz używam, jest Linux Logwatch . Wysyła mi podsumowania dzienników, które są filtrowane i grupowane. W ten sposób możesz łatwo oddzielić to, co ważne, od tego, co nieistotne.

Dziękuję wszystkim za pomoc i mam nadzieję, że ten post może być pomocny także dla kogoś innego.

Z Twojego dziennika błędów wysyłają żądanie HTTP / 1.1 bez części Host: żądanie. Z tego, co przeczytałem, Apache odpowiada błędem 400 (niepoprawne żądanie) na to żądanie, przed przekazaniem go do mod_security. Więc nie wygląda na to, że Twoje reguły zostaną przetworzone. (Apache radzi sobie z tym przed wymaganiem przekazania do mod_security)

Spróbuj sam:

nazwa hosta telnet 80
GET /blahblahblah.html HTTP / 1.1 (enter)
(wchodzić)

Powinieneś dostać błąd 400 i zobaczyć ten sam błąd w swoich logach. To zła prośba, a Apache podaje prawidłową odpowiedź.

Prawidłowe żądanie powinno wyglądać następująco:

POBIERZ /blahblahblah.html HTTP / 1.1
Host: blah.com

Rozwiązaniem tego problemu może być załatanie mod_uniqueid w celu wygenerowania unikalnego identyfikatora nawet dla nieudanego żądania, aby apache przekazał żądanie do swoich programów obsługi żądań. Poniższy adres URL to dyskusja na temat tego obejścia i zawiera łatkę dla mod_uniqueid, której możesz użyć: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

Nie mogłem znaleźć innych rozwiązań i zastanawiałem się, czy rozwiązanie jest rzeczywiście wymagane.

Filtrowanie adresów IP nie jest dobrym pomysłem, imho. Dlaczego nie spróbować filtrować znanego ciągu?

Mam na myśli:

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

Iv również zaczął widzieć tego typu wiadomości w moich plikach dziennika. Jednym ze sposobów zapobiegania tego typu atakom jest skonfigurowanie fail2ban ( http://www.fail2ban.org/ ) i skonfigurowanie określonych filtrów, aby czarna lista tych adresów IP znajdowała się w twoich regułach iptables.

Oto przykład filtra, który blokowałby adres IP związany z tworzeniem tych wiadomości

[Wtorek 16 02:35:23 2011] [błąd] [klient] Plik nie istnieje: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t wiadomości więzienie - regex and filter === Więzienie

 [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

Filtr

 # 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 to próba hakowania, która wykorzystuje fałszywe adresy IP, więc wyszukiwania takie jak VisualRoute zgłaszają Chiny, Polskę, Danię itp. zgodnie z adresatem IP w tym czasie. Dlatego skonfigurowanie Odmówienia adresu IP lub możliwej do rozwiązania nazwy hosta jest prawie niemożliwe, ponieważ zmieni się ono w ciągu godziny.

Osobiście napisałem skrypt Pythona do automatycznego dodawania reguł IPtables.

Oto nieco skrócona wersja bez logowania i innych śmieci:

#!/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)

Uważam, że powodem, dla którego mod_security nie działa, jest to, że Apache nie był w stanie samodzielnie przeanalizować żądań, ponieważ są one niespecyfikowane. Nie jestem pewien, czy masz tutaj problem - apache rejestruje dziwne gówno, które dzieje się w sieci, jeśli się nie zaloguje, nie będziesz wiedział, że to się dzieje. Zasoby wymagane do zarejestrowania żądań są prawdopodobnie minimalne. Rozumiem, że frustrujące jest to, że ktoś wypełnia twoje logi - ale będzie to bardziej frustrujące, jeśli wyłączysz rejestrowanie tylko po to, aby naprawdę go potrzebujesz. Jakby ktoś włamał się do twojego serwera i potrzebujesz dzienników, aby pokazać, jak się włamał.

Jednym z rozwiązań jest skonfigurowanie funkcji ErrorLogging poprzez syslog, a następnie za pomocą rsyslog lub syslog-ng można w szczególności filtrować i odrzucać naruszenia RFC dotyczące w00tw00t. Ewentualnie możesz je przefiltrować do osobnego pliku dziennika, aby główny dziennik błędów był łatwy do odczytania. Rsyslog jest pod tym względem niezwykle potężny i elastyczny.

W httpd.conf możesz zrobić:

ErrorLog syslog:user 

następnie w rsyslog.conf możesz mieć:

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

Należy pamiętać, że takie podejście zużywa wielokrotnie więcej zasobów niż pierwotnie używane logowanie bezpośrednio do pliku. Jeśli twój serwer jest bardzo zajęty, może to stanowić problem.

Najlepszą praktyką jest wysyłanie wszystkich dzienników do zdalnego serwera rejestrowania tak szybko, jak to możliwe, a to przyniesie korzyść w przypadku włamania, ponieważ znacznie trudniej jest usunąć ścieżkę audytu tego, co zostało zrobione.

Blokowanie IPTables jest pomysłem, ale możesz skończyć z bardzo dużą listą bloków iptables, która sama w sobie może mieć wpływ na wydajność. Czy w adresach IP jest jakiś wzorzec, czy pochodzi on z dużego rozproszonego botnetu? Będziesz musiał uzyskać X% duplikatów, zanim będziesz mógł skorzystać z iptables.

Mówisz w aktualizacji 2:

Problem, który nadal występuje Problem, który nadal występuje, jest następujący. Te ataki pochodzą od botów, które wyszukują określone pliki na twoim serwerze. Ten konkretny skaner szuka pliku /w00tw00t.at.ISC.SANS.DFind :).

Teraz możesz po prostu zignorować to, co jest najbardziej zalecane. Problem polega na tym, że jeśli pewnego dnia masz ten plik na serwerze, masz jakieś problemy.

Z mojej poprzedniej odpowiedzi stwierdziliśmy, że Apache zwraca komunikaty o błędach z powodu źle sformułowanego zapytania HTML 1.1. Wszystkie serwery obsługujące HTTP / 1.1 powinny prawdopodobnie zwrócić błąd po otrzymaniu tego komunikatu (nie sprawdziłem dwukrotnie RFC - być może RFC2616 mówi nam).

Posiadanie w00tw00t.at.ISC.SANS.DFind: na twoim serwerze gdzieś nie oznacza mistycznie „masz kłopoty” ... Jeśli utworzysz plik w00tw00t.at.ISC.SANS.DFind: w twoim DocumentRoot lub nawet DefaultDocumentRoot to nie ma znaczenia ... skaner wysyła zepsute żądanie HTTP / 1.1, a apache mówi „nie, to złe żądanie ... do widzenia”. Dane w pliku w00tw00t.at.ISC.SANS.DFind: nie będą obsługiwane.

Użycie mod_security w tym przypadku nie jest wymagane, chyba że naprawdę chcesz (nie ma sensu?) ... w takim przypadku możesz spojrzeć na łatanie go ręcznie (link w innej odpowiedzi).

Inną rzeczą, na którą możesz spojrzeć przy użyciu, jest funkcja RBL w mod_security. Być może istnieje RBL online, który zapewnia adresy IP w00tw00t (lub inne znane złośliwe adresy IP). Oznaczałoby to jednak, że mod_security sprawdza DNS dla każdego żądania.

Co powiesz na dodanie reguły do ​​modsecurity? Coś takiego:

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

Widzę, że większość rozwiązań jest już omówionych powyżej, jednak chciałbym zauważyć, że nie wszyscy klienci wysyłający żądania HTTP / 1.1 bez ataków na nazwy hosta są skierowani bezpośrednio na twój serwer. Istnieje wiele różnych prób pobrania odcisków palców i / lub wykorzystania systemu sieciowego poprzedzającego serwer, np. Przy użyciu:

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

aby celować w routery Linksys itp. Czasami pomaga to zwiększyć koncentrację i podzielić wysiłki obronne między wszystkie systemy z jednakowym udziałem, tj .: wdrożyć reguły routera, wdrożyć reguły zapory ogniowej (mam nadzieję, że twoja sieć je posiada), wdrożyć zaporę serwera / tabelę adresów IP reguły i powiązane usługi, tj. mod_security, fail2ban i tak dalej.

co powiesz na to ?

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:

działa dobrze dla mnie.

Jeśli używasz hiawathaserwera internetowego jako reverse proxyskanu, skany są automatycznie usuwane jako śmieci i clientzbanowane. Filtruje również XSSi CSRFwykorzystuje.