Czasami trzeba urozmaicić sobie życie, prawda? A więc dzisiaj kilka słów o kwestii DDoS i DoS (ataku slowloris). Szczerze pisząc, samego słowa kluczowego slowloris nie skojarzyłbym jeszcze jakiś czas temu. To był czysty przypadek, kiedy natrafiłem na informacje dotyczące tego ataku. Akurat ciekawość zaprowadziła mnie w czeluści Internetu, a mianowicie kwestie dotyczące zabezpieczeń przed DDoS serwera Apache. Tak, wiem to nie moja działka, ale nikt mi nie zabroni, by trochę rozpisać temat 🙂

O DDoS już każdy słyszał, każdy wie, że trzeba się bać, ale nie każdy chce, potrafi, czy też powinien wiedzieć więcej. Nie męcząc Was zbytnio terminologią, napiszę tylko, że DDoS to rozproszony DoS, a DoS to atak na komputer/serwer, by go unieruchomić. Szczególnym przypadkiem DDoS jest atak DRDoS, ale w ten temat zachęcam się zagłębić zainteresowanym pod adresem: https://pl.wikipedia.org/wiki/DRDoS.

W porządku, zatem został nam ciekawie brzmiący slowloris. Jego geneza sięga 2009 roku, a podatność jaką wykorzystuje jest bardzo interesująca – otwieranych wiele połączeń z serwerem, jednak wyłącznie przez niedokończone nagłówki oraz podtrzymywanie tych połączeń poprzez dosyłanie jakichś zupełnie nieznaczących nagłówków. Atak ten zapoczątkował erę ataków Slow HTTP DoS. Może on być wykonywany z kilku maszyn, ale nie jest to konieczne, aby osiągnąć cel.

Przykłady ataków dostępne są pod adresami: 1, 2.
Oczywiście wyłącznie do celów edukacyjnych. Pamiętajcie, że cyberprzestępstwo to nie żart i podlega ono wysokim karom – patrz rozdział XXXIII Kodeksu Karnego.

 

Ale jak żyć?

Nikt nie mówił, że będzie lekko. Lata mijają, a podatności serwerów na ataki typu slow nie znikają – o zgrozo. Częściowo spokojniejsi mogą być administratorzy serwerów IIS, nginx, lighttpd i kilku innych mniej znanych – ale nie popadajcie w euforię, gdyż mimo wszystko serwery te są podatne na inne ataki typu slow. Już pewnie się domyślacie w jakie serwery celował twórca ataku – jest to niestety grupa serwerów obsługująca ponad połowę stron internetowych – mianowicie Apache, dhttpd i kilka mniej znanych. Najgorsze jest to, że nawet w stosunkowo niedawno wypuszczonym Apache 2.4 (ciągle aktualizowanym) podatność nie została zabezpieczona.

Wynika to zastosowanej koncepcji obsługi żądań, która niestety otworzyła drogę tego typu atakom. Serwera Apache (korzystający z domyślnej konfiguracji) kończy połączenie, po 300 sekundach nieowocnego oczekiwania na dane od klienta. Wystarczy jednak w tym czasie dosłać jedno „małe ziarenko” (nagłówek) i wyzeruje licznik oczekiwania na dane.

 

Zalecane linie obrony

Często proponowaną linią jest moduł Apache mod_evasive, jednak najprawdopodobniej nie ma możliwości jego podłączenia na wersji 2.4 (lub jest utrudniona). Jak najbardziej nadaje się dla wersji 2.2. Sam moduł należy mocno przetestować (a właściwie parametry jakie ustawimy) zanim konfiguracja trafi na serwer produkcyjny.

mod_evasive i jego konfiguracji poczytacie tutaj: 1, 2.

Na potrzeby Apache 2.4 zalecany jest moduł mod_qos. Jak się okazuje – potrzeba matką wynalazków. Pierwotnie przeznaczeniem modułu było ograniczanie transferu.

mod_qos dowiecie się więcej tutaj: 1, 2.

Domyślam się jeszcze, że odpowiednie skonfigurowanie firewalla powinno też pomóc. Dodatkowo do zbadania podaję dwa inne moduły: mod_antiloris oraz mod_reqtimeout.

 

Miłego weekendu!