Megtámadták az indiánom!

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:

Slow-attack-apache-processes

Ugyanebben az időben a rendszer terhelése:

Slow-attack-load

A memória kihasználtsága:

Slow-attack-memory

És a processzorterhelés:

Slow-attack-cpu

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.