Hogy az irokézek vagy a sápadtarcúak, az sajnos nem derült ki, az alábbi Munin diagramon viszont szépen nyomon követhető, hogy mi történt. A webszerver felé megnyitott kapcsolatok száma folyamatosan növekedett, miközben lezárásra egy sem került. Az újraindítás nem segített, a probléma azonnal visszatért. Az Apache processzek száma az alábbiak szerint alakult:
Ugyanebben az időben a rendszer terhelése:
A memória kihasználtsága:
És a processzorterhelés:
Vagyis a másik három diagramon semmi sem mutatja, hogy támadás érte volna a wigwamot. Az alábbi parancs viszont rengeteg élő kapcsolatot mutatott:
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort –n
Ugyanakkor a listában található IP címek nagy részének nyoma sem volt sem az access.log, sem pedig az error.log fájlokban.
Az elszenvedett támadás a Slow HTTP GET/POST névre hallgat, és ide kattintva olvashatsz felőle részletesen. A forgatókönyv a következő: a kliens egy kapcsolati kérelmet jelez a webszerver felé, de ennek fejlécét iszonyatosan lassan, csepegtetve küldi el a szervernek. Amíg viszont nem érkezik meg a fejléc, addig nincs valódi megnyitott kapcsolat sem, így a kliens IP címe nem kerül naplózásra. Ugyanakkor a webszerver, a fejléc adataira várva, fenntartja ezt a csatornát a kliens felé. A kliens oldalán ez az aljasság nevetségesen kevés erőforrást köt le, így jó sokat tud nyitni belőle, ha pedig mindezt egy botnet több száz számítógépe műveli, nem nehéz elképzelni, mi történik.
A rendelkezésre álló kapcsolatok száma villámgyorsan elfogy, így a legitim kéréseket a webszerver nem tudja többé kiszolgálni.
A fenti, Munin által készített CPU és Load grafikonokon ebből nem látszik semmi, egyedül a RAM kihasználtság Committed jellemzője mutatja, hogy az így fenntartott csatornák memóriát foglalnak, ha ki nem is használják azt.
A wigwam bejárata szépen bedugul, többé nem tud rajta senki közlekedni. Se ki, se be.
A webszervert újraindítva minden csatorna felszabadul, de az öröm rövid ideig tart, ugyanis a botnet felől érkező támadás újra dugulást fog okozni. Méghozzá nagyon gyorsan. Ennél tehát jobb megoldást kell találni.
mod_reqtimeout
Az első védelmi vonal a wigwam beáratánál az Apache mod_reqtimeout modulja.
A /etc/apache2/mods-available/reqtimeout.conf fájl tartalma legyen ez:
<IfModule reqtimeout_module> # Wait max 10 seconds for the first byte of the request line+headers # From then, require a minimum data rate of 1024 bytes/s, but don't # wait longer than 20 seconds in total. RequestReadTimeout header=10-20,minrate=1024 # Wait max 10 seconds for the first byte of the request body (if any) # From then, require a minimum data rate of 1024 bytes/s RequestReadTimeout body=10,minrate=1024 </IfModule>
Vagyis, a kapcsolatkérelem fejlécének első bájtjára maximum 10 másodpercet várunk, utána az adatátvitel sebessége nem eshet 1024 bájt/másodperc alá, és 20 másodperc alatt a fejléc adatainak teljesen meg kell érkeznie.
Utána a kérelem tartalmát jelentő adat első bájtjára maximum 10 másodpercig várunk, utána pedig az adatátvitel sebessége nem eshet 1024 bájt/másodperc alá.
Ha a fenti feltételek nem teljesülnek, a szerver 408 REQUEST TIMEOUT üzenetet küld a kliensnek és bontja a kapcsolatot. Ez pedig pontosan az, ami nekünk kell. De még csak félig vagyunk kész.
mod_security
A wigwam második védelmi vonala az Apache mod_security modulja, amellyel először is megvizsgáljuk, hogy egy meghatározott időtartam alatt IP címenként hány darab 408 REQUEST TIMEOUT üzenet generálódik, majd ennek ismeretében kínzócölöpre kötözzük az illetéktelen behatolót.
A /etc/modsecurity/modsecurity.conf fájlban helyezzük el az alábbiakat:
# Slow HTTP Attack SecRule RESPONSE_STATUS "@streq 408" "phase:5,t:none,nolog,pass, setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=300, id:'1234123456'" SecRule IP:SLOW_DOS_COUNTER "@gt 60" "phase:1,t:none,log,drop, msg:'Client Connection Dropped due to high number of slow DoS alerts', id:'1234123457'"
Illetve, ugyanitt az alábbi sort:
SecRuleEngine DetectionOnly
Cseréljük erre:
SecRuleEngine On
Röviden, ha 300 másodpercen belül egy kliens legalább 5 db 408 REQUEST TIMEOUT üzenetet kap, 60 percre letiltjuk a belépését a wigwamba. És ne felejtsd el újraindítani a webszervert sem.
A fenti két beállítással eláshatjuk a csatabárdot, és újra beköszön a béke. A visszatérő renitensek pedig rövid úton ismét a kínzócölöpön végzik. Az Apache processzek állapotáról tanúskodó Munin diagram utolsó két órája már ezt a nyugodt és békés állapotot mutatja.