Jak udaremnić ataki PHPMyAdmin?


6

setup.phpW naszych dziennikach dostępu widzimy wiele żądań dotyczących nieistniejących plików (patrz poniżej). W przypadku niektórych naszych klientów korzystających z reguł przepisywania każde z tych żądań spowoduje wykonanie skryptu PHP, powodując znaczne spowolnienie serwera i generowanie niepotrzebnego ruchu.

Czy można szybko odrzucić takie wnioski? Myślałem o określeniu ogólnej zasady odmowy, która zaprzecza wszelkim setup.phppowiązanym zapytaniom, ale może to nie być właściwe podejście. Jakieś sugestie?

217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PHPMYADMIN/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PMA/scripts/setup.php HTTP/1.1" 404 2444 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:39 +0100] "GET /PMA2005/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:47 +0100] "GET /SSLMySQLAdmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:42 +0100] "GET /SQL/scripts/setup.php HTTP/1.1" 404 2446 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:49 +0100] "GET /admin/phpmyadmin/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:58 +0100] "GET /admin/scripts/setup.php HTTP/1.1" 404 2442 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:00 +0100] "GET /bbs/data/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:01 +0100] "GET /cpadmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:03 +0100] "GET /cpadmindb/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:53 +0100] "GET /admin/pma/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:05 +0100] "GET /cpanelmysql/scripts/setup.php HTTP/1.1" 404 2450 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:11 +0100] "GET /cpanelphpmyadmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:13 +0100] "GET /cpanelsql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:23 +0100] "GET /cpphpmyadmin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:25 +0100] "GET /db/scripts/setup.php HTTP/1.1" 404 2441 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:26 +0100] "GET /dbadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:28 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:29 +0100] "GET /mysql-admin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:32 +0100] "GET /mysql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:33 +0100] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:35 +0100] "GET /mysqladminconfig/scripts/setup.php HTTP/1.1" 404 2453 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:36 +0100] "GET /mysqlmanager/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"

Odpowiedzi:


2

Nadal aktualne prawie 4 lata później.

Ponieważ prawdopodobnie mod_rewrite obsługuje ruch w dobrej wierze, skrypty te nie zwiększą obciążenia. Ale tak, mogą powodować chwilowe opóźnienie. Zasadniczo nie będziesz w stanie całkowicie temu zapobiec.

Modyfikacje i wtyczki mające na celu złagodzenie tego problemu koncentrują się na częstotliwościach i szybkościach przed zablokowaniem ip na lokalnej zaporze ogniowej (iptables). Lepsze podejście powinno obejmować podpisy, takie jak fragmenty nazw katalogów (fałszywe w normalnym użyciu). Następnie należy wziąć pod uwagę, jak musi to być reaktywne. Można zaadaptować części pakietu „denyhosts” (produkt do ochrony przed podobnymi problemami przy logowaniu haseł SSH), aby czytać za logiem i identyfikować „podpisy” w celu dodania adresów IP do /etc/hosts.deny.

Z reguły osoby te nie wracają z tego samego hosta, więc możemy chcieć czegoś szybszego. Piękno otwartego oprogramowania polega na tym, że możemy go ulepszyć. mod_evasive wydaje się OK, ale co, jeśli twój serwer jest legalnie sprawdzany przez skrypty (curl, wget i tym podobne). Stąd brak CAPTCHA i potrzeba białych list lub resetowania przez POST lub GET parms.

Dla tych z was, którzy martwią się ryzykiem ataku (PO nie był, OP był zaniepokojony zużyciem zasobów), jeśli faktycznie macie phpmyadmin:

Użyj dyrektyw dla poszczególnych katalogów.

ORDER DENY, ALLOW
DENY FROM ALL
ALLOW FROM *safe places*

Poważnie, bardzo niewiele osób powinno mieć dostęp. Jeśli nie są DBA, co uzasadnia ryzyko? Podczas incydentu Apache można skonfigurować na żądanie, aby otworzyć drzwi z jednego adresu. Jeśli nie ma Cię w sieci VPN, podłącz VPN do pulpitu VNC / RDP w tej samej sieci lub użyj proxy.

Ich skrypt nadal będzie cię atakował za 404 (i co najmniej jeden 403). Pozostawienie im fałszywych folderów i kodu konfiguracji, aby je znalazły, tylko zachęca ich. Po prostu używam grep -v, aby odfiltrować nazwy katalogów.


.. i oczywiście teraz zmienił się format dyrektyw ...
mckenzm

2

zacznij od nie dostarczania żadnych treści z domyślnego vhosta, więc boty, które atakują cię ślepo na podstawie adresu IP, mają mniejsze szanse na wysłanie żądania, które uruchomi dowolną akcję „ciężką” po twojej stronie.

następnie możesz użyć fail2ban i sprawdzić zawartość swoich dzienników + zablokować ips, z których pochodzi ślepe skanowanie.


Dzięki za sugestię fail2ban. Ataki nie są skierowane na adres IP serwera, ale na określone domeny na serwerze. Dziennik, który opublikowałem, pochodzi z pliku dziennika jednej konkretnej domeny.
Ton van den Heuvel


0

Upewnij się, że PHPMyAdmin jest aktualny. Ukryj, umieść w katalogu, w którym nie będą skanować /padmin32.


Już to wszystko robię. Nie jest to realne rozwiązanie problemu, ponieważ skanowanie będzie kontynuowane, obciążenie serwera pozostanie.
Ton van den Heuvel

1
@Ton van den Heuvel nie „prawdziwy problem” zostaje zhakowany.
Rook
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.