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.
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.
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.
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.
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.
źródło
Filtrowanie adresów IP nie jest dobrym pomysłem, imho. Dlaczego nie spróbować filtrować znanego ciągu?
Mam na myśli:
źródło
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
Filtr
źródło
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.
źródło
Osobiście napisałem skrypt Pythona do automatycznego dodawania reguł IPtables.
Oto nieco skrócona wersja bez logowania i innych śmieci:
źródło
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ć:
następnie w rsyslog.conf możesz mieć:
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.
źródło
Mówisz w aktualizacji 2:
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.
źródło
Co powiesz na dodanie reguły do modsecurity? Coś takiego:
źródło
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:
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.
źródło
co powiesz na to ?
działa dobrze dla mnie.
źródło
Jeśli używasz
hiawatha
serwera internetowego jakoreverse proxy
skanu, skany są automatycznie usuwane jako śmieci iclient
zbanowane. Filtruje równieżXSS
iCSRF
wykorzystuje.źródło