Apache ab elleni védelem

Linux-kezdő

Sziasztok,

A fenti témában kérem a segítségeteket. Hogyan tudok egy olyan tűzfalszabályt felállítani ami véd egy Web stress benchmarking eszköz ellen. Egy sima "ab -n 100 -c 20 " igazán hamar le tud dönteni egy webszervert a lábáról.
Előre is köszönöm.

  • 6878 megtekintés

( Z0l v | 2013. 01. 31., cs – 15:22 )

Elso korben iptables limit opciojaval kellene megismerkedni, aztan lehet "szofisztikalni" a dolgot. Ha mar ilyet csinalsz, akkor lehet erdemes elgondolkodni az egyeb protollokra (pl. ICMP) torteno limitek beallitasarol is.

Ha limitálom a 80-as portra bejövő kapcsolatokat? Az alábbi példa max. 20 kapcsolatot enged meg egy IP-ről.
És ha valaki egy proxy mögül kapcsolódik a 80-s porthoz, ahonnan már vannak kapcsolatok??

/sbin/iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 -j REJECT --reject-with tcp-reset

Nem kapcs.szám fontos önmagában, hanem adott idő alatti kapcsszám. Bulk downloaderek kíméljenek jelszóval. :D

Vmi hasonló:
"-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -m recent --set --name limiter --mask 255.255.255.255 --rsource
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -m recent --update --seconds 1 --hitcount 20 --name limiter --mask 255.255.255.255 --rsource -j LOG --log-prefix "(* reach limit) "
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -m recent --update --seconds 1 --hitcount 20 --name limiter --mask 255.255.255.255 --rsource -j DROP"

Esetleg vethetsz egy pillantást a HaProxy-ra.

Ha már itt vagyunk egy kicsit nagyobb szervernél hogyan érdemes egy ilyet megoldani?
Az én esetemben 1200-1400 connection/sec van napi átlaggal (csúcsokban 1600-1800), és kb 50-60 millió request / nap átlagosan.

Prímán hasít a cucc 1 másodperc alatti oldalletöltés időkkel, csak elgondolkodtam hogy lehet, hogy a csúcsterheléseken tompítani lehetne, ha pár "kevébé mezei" klienst kiszűrnénk...

Webszerver szinten nem akarok piszkálni, mert így is sz*rrá van optimalizálva, bármi plusz bele csak lassít, IP szinten meg nem kéne ártatlan klienseket kizárni, csak azért mert nagyobb proxy mögött ülnek.

Haproxy, session rate és aurája. Szerintem akár még terhelési feltételt is lehet belefogalmazni ügyesen a backendek közé. Pl. ugyanarra a szervizre több backend definíció (ami ugyanarra a szervizre mutat) az egyik izom, a másik session rate-es ha az izom maxconn-ja kifullad, mehet a wheight-ed backendek között az osztás a lassító vágányon.

(Nem túrtam fel a doksit, de 99.999%, hogy össze lehet rakni vmi hasonlót... Ez a Vili gyerek (a Tarreau) jól gondolkodik. Haproxyban eddig még nem csalódtam.)

De a kérdésedre a válasz engem is érdekel. :DDD

Prímán hasít a cucc 1 másodperc alatti oldalletöltés időkkel, csak elgondolkodtam hogy lehet, hogy a csúcsterheléseken tompítani lehetne, ha pár "kevébé mezei" klienst kiszűrnénk...

Hadd legyek olyan paraszt, hogy megkerdezem: tudjuk, hogy vannak ilyen lekeresek, vagy ez csak ugy egy nem teljesen ataludt ejszaka utan eszedbe jutott?

- Ritka, hogy bulk downloaddal terheljenek egy $RANDOM oldalt, foleg dinamikus tartalommal
- Ha nincs egyertelmu nyoma/jele, hogy ilyen van (logokbol ki tud derulni), akkor nem biztos, hogy erdemes vele foglalkozni. Ahogy itt korabban elokerult, ezzel nagyon meg tudod azokat szivatni, akik valamiert egy darab ip-rol latszanak. Nem csak nagy cegek ilyenek, hanem bizonyos videki szolgaltatok is, az ugyfeleiknek privat halos cimeket osztogatnak, kifele meg csak egy publik cimuk van.

Szoval en eloszor megneznem, hogy letezik-e a problema, es akkor - de csakis akkor - kezdenek bele a megoldasaba, ha ez pozitiv megerositest nyert.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Hadd legyek olyan paraszt, hogy megkerdezem: tudjuk, hogy vannak ilyen lekeresek"
"Ritka, hogy bulk downloaddal terheljenek egy $RANDOM oldalt, foleg dinamikus tartalommal"

Sok szép szines kép van....azon lepődnék meg, ha nem lenne bulk download...:)
Már fogtunk ilyet a múltban, csak ott a reverse ip lookup alapján egyértelműen beazonosítható volt egy konkurens cég, úgyhogy a probléma megoldására elég volt egy telefon, hogy léci na ne már....

Egyébként tipikus jele pl. hogy egy IP 2-3 percig 100-200 konkurens kapcsolaton másodpercenként több száz kérést küld . (És nem kínai botnet, hanem pl. diginet dinamikus pool.)

Problémát egyébként nem jelent még, és egyenlőre nem is tudom érdemes -e a dologgal foglalkozni.

"Problémát egyébként nem jelent még"

En ettol a ponttol fogva allnek fel a geptol es mennek el setalni/focizni/baratkozni. Vagy legalabbis bezarnam a konzolokat, es elkezdenek jatszani. Mindegyik sokkal jobb, mint nem letezo problemak miatt aggodni.

De ha annyira szeretsz aggodni, megoldhatnad a vilagbeket. Azzal meg produktiv is lennel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

nem jelent MÉG.

szerinted baromság felkészülni előre arra az esetre, hogy ha a bulk downloadok elernek hirtelen olyan szintet, amikor mar problema lesz? vagy szerinted jobb, ha majd akkor allunk neki gondolkozni, nem baj, ha par napig/hetig akadozik a szolgaltatas...

hrgy, te sohasem lepsz meg engem.
csak azt nem ertem, hogy ilyen hozzaalassal ki a franc alkalmaz teged?! ez a tipikus leszarom/trehany, csinaljuk meg amit nagyon muszaj a tobbi le van tojva mentalitas...

"De ha annyira szeretsz aggodni, megoldhatnad a vilagbeket. Azzal meg produktiv is lennel."
ez a beszolas meg bazzeg... no comment.

Nyilvan jo dolog elore felkeszulni - csak nem mindegy, milyen temaban. Ha akut problema van, arra egy iptables rating szabaly tokeletesen elegendo lehet, aminek a megtalalasa kevesebb mind ket perc. A problema vegleges megoldasara pedig innentol kezdve rengeteg ido all rendelkezesre.

Nem azt mondom, hogy nem jo elore gondolkodni. En is epitek be olyan vedelmet a tuzfalaimba, amirol tudom, hogy nem biztos, hogy szukseg lesz ra. Ugyanakkor a felvetett problema olyan, hogy a legegyszerubb megoldasok egyben a legproblemasabbak is, tehat nem biztos, hogy a trivialis megoldas egyben a legjobb is, sok dolognak van itt beleszolasa.

Es eszre kellene venni, hogy adtam megoldasokat is, illetve a topicban tobb jo otlet is felmerult, meg _mielott_ beirtam volna a kommentet. Teszt kornyezetben ez alapjan nagyon sokfele modon el lehet indulni, amibol kialakulhat egyreszt egy akut, masreszt egy vegleges problema kezeles. Viszont mivel a problema _jelenleg_ jelentektelen meretu, igy en nem kezdenek el rogton aggodni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"tokeletesen elegendo lehet, aminek a megtalalasa kevesebb mind ket perc"

Rotfl.... 45 millió soros az átlag napi access log.
2 perc alatt egy sort nem fut le rajta.

Ebből kell olyan mintákat kiszűrni, amivel relative kevés fals pozitívval be lehet azonosítani a kívánt klienseket.
Tulajdonképpen az érdekel, hogy milyen mintázatokkal lehet beazonosítani egy ilyen renitens klienst. És mindezt ha lehet, majdnem valós időben.

És nem azért kérdem, mert annyira baromi nagy a probléma, hanem csak azért, mert érdekel, és ki tudja szükségem -e lesz rá a jövőben.
Annyira viszont nem érdekel, hogy ennél több időt fecceljek bele, de azért kösz, hogy foglalkoztál a kérdéssel.

A teljesseg kedveert:
". Ha akut problema van, arra egy iptables rating szabaly tokeletesen elegendo lehet, aminek a megtalalasa kevesebb mind ket perc."

A rating szabaly szintaxisara gondoltam. Akut problema eseten pedig en mindenkire rakok rate controlt, es akinek ez problema, az majd kap kivetelt, vagy ha tudom elore, hogy az lesz, akkor azoknak eleve adok kivetelt. De - minthogy ez egy akut problema megoldasa - a jellegebol kifolyolag ez csak ideiglenes dolog - viszont addig sincs szetterhelve a gep, igy van ido peldaul a logok greppelesere.

Egyebkent pedig maga a pattern nagyon fugg attol, hogy mit keresel. Az ab - ha mar ilyen konkret volt a felvetes - egy darab URL-t hiv sokszor. De vannak crawlerek, hibakeresok (Acunetix peldaul), amik sok URL-t sokszor hivnak egymas utan, szunet nelkul. Ha ket masodpercen belul harom/negy tok kulonbozo dinamikus oldalra tortenik lekeres ugyanarrol az IP+UserAgent beallitasrol, akkor lehet gyanakodni, hogy valami nem koser. Akkor is, ha egy darab dinamikus oldalt tiz masodpercen belul otszor meghivnak, kulonbozo query parameterezessel.

De ez fugg az adott alkalmazastol, fugg a kornyezettol, fugg a felhasznaloktol... sok mindentol. Nincs uberalles megoldas.

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( igor | 2013. 01. 31., cs – 16:06 )

csf+lfd kell neked, abban port flood és connection limit opciók. Én ezzel oldottam meg, évek óta szépen megy.

( zsolt | 2013. 02. 01., p – 12:10 )

Nem akarlak elkeseríteni, de ez az alkalmazás valószínűleg nem érett még meg az éles használatra.

Ha egy weboldal 20 egyidejű kérést nem bír kiszolgálni, ott komoly gondok vannak szerintem.

Esetleg meg kéne próbálni alkalmazásszintű cache-elést beállítani, ha van ilyen. Ha nem, akkor a gyakori URL-eket cron-ból időnként letölteni és valami rewrite szabállyal azt kiszolgálni statikus tartalomként, hogy ne ezt a monstrumot bizgessék a látogatók élőben.

Esetleg a web-szervered kedvenc cache modulját is beállíthatod.

( rts | 2013. 02. 02., szo – 10:39 )

Ugye külön szerveren vannak a logok, nem a webszerveren?

Az én megoldásom eltérő az itt felsoroltaktól.. Haproxy, amikor egyébként jól működik a rendszer? Na ne..... A kérdező csupán védelmet akar a rosszfiúk ellen.
No akkor írjunk egy scriptet. :-) Elemezni kell a logokat és jól áttekinthető (shellscriptből vagy phpval legenerálni valami weboldalt) statisztikát gyártani belőlük, percenként, óránként, naponként leosztva.

Ha ez megvan, azonnal látod a legitim, rendszeresen látogató hostokat. (Pl. proxy.otpbank.hu + tsai.) (Egyébként azt is el tudnám képzelni, hogy ezen a logszerveren futó stat weblapon a hostra való kattintással azonnal blokkolhatom azt egy iptables szabály beillesztésével.)

A scriptedbe ezeket a jófiúkat belegyógítod whitelistre vagy skiplistnek is nevezhetném. A többi, X hit / Y idő-t meghaladó kérést produkáló hostot pedig automatikusan Z időre egy DROP-ra beillesztett iptables szabállyal elintézed, az egész rendszert pedig futtatod cronból P percenként. Persze mindig csak a logfájl azon utolsó sorait nézi át, amiket még nem látott, így gyorsabb lehet a feldolgozás. Ezért írtam, hogy külön szerveren legyen, ne a webszerveren. A feldolgozott logfájl meg mehet SQL-be a későbbi könnyebbség miatt VAGY már eleve SQL-be logolni. És vannak még ötleteim. :)

Biztos van erre az egészre már készen is valami progi. Esetleg aki ismer ilyet, megoszthatná. Fail2ban egy félnek jó, de ezen kívül?

\o\ |o| /o/