IPTABLES --state RELATED,ESTABLISHED -j ACCEPT felülbírálata

Security-all

Sziasztok,

A következőhöz kérném a segítségeteket, vagy ötletet.
Adott egy debian 7.1 szerver, honlapokkal, saját tűzfallal(iptables).
A honlapokat előszeretettel látogatják feltörési szándékkal, ezért beállítottam az apache2 config-jában, hogy bizonyos url-ek, amik nálam biztos, hogy nem szerepelnek (pl. wp-login) mod-rewrite segítségével automatikusan egy php scriptnél landolnak, ami a delikvens IP-jét beteszi egy iptables chain-be(fullbanned), értelemszerűen -j DROP-pal. Ez igy jól is működne, de mégsem jó, mivel

-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

előzőleg már engedélyezi, és utána már hiába tiltom a fullbanned-ben, ez már csak a következő, új kapcsolatokra fog vonatkozni. Igen, lehetne a sorrenden változtatni, de ahhoz túl nagy a net forgalom, hogy feleslegesen minden csomagot többször is ellenőrizzek, ezt szeretném elkerülni. Jelenleg, mivel jobb megoldást nem találtam a tcpkill-t használom az aktuális kapcsolat kinyírására, de hátha valakinek van jobb ötlete?
Például van valami mód arra, hogy a state flaget "NEW" ra állítsuk az adott IP-nél, mintha új csatlakozás lenne, vagy bármi más, amivel az adott IP kapcsolat meg lehet szakítani?

  • 6627 megtekintés

( joco01 v | 2013. 08. 24., szo – 14:24 )

Bármikor tud új kapcsolatot nyitni, most akkor mit szeretnél megakadályozni? Az a +3 (30, 300, bármi) CPU ciklus tényleg meglátszik?

--

hú de gyors voltal...
szóval, akkor másképp fogalmazva:
Adott egy átlagos tűzfal, bárki jön honlapot nézegetni, beengedi.
Jön az X-edik kérés, ami már tiltott szándékra vall, bekerül az IP a fullbanned chain-be, de ott csak akkor fog érvényesülni, ha a jelenlegi kapcsolat megszűnik, mivel az aktuális kapcsolatnál még érvényes a --state RELATED,ESTABLISHED -j ACCEPT
Tehát az a kérdés, hogy hogy tudom az iptables-sel a jelenlegi kapcsolatot megszakítani, hogy érvénybe lépjen a bann. Így már érted?

( blackluck v | 2013. 08. 24., szo – 14:28 )

"de ahhoz túl nagy a net forgalom, hogy feleslegesen minden csomagot többször is ellenőrizzek"

Mi szamit tul nagynak?

"de nem ez volt a kérdés"
De ez is a kérdéshez tartozik, ugyanis ha attól tartasz, hogy egy protokoll és portellenőrzés, valamint vélhetőleg elég kisszámú forrás IP ellenőrzésébe belerokkan a gép, akkor erre az a javaslat, hogy vagy a gépet kell fejleszteni, vagy be kell tenni elé egy kis hardveres tűzfalat.

Úgy építsd fel a szabályok sorrendjét, hogy ne legyen túl nagy overhead, valamint a lánc tartalmát időnként tisztítani is kell (lásd: fail2ban).

Ha már előkerült a fail2ban, az miért nem jó neked?

Mindkettőtöknek igazatok van, írtam is, igen, a sorrend változtatásával IS megoldható, de épp arra voltam kíváncsi, hogy van e más megoldás?
...és anélkül, hogy elmennénk a hardver erősségének irányába, arról sem szabad megfeledkezni, hogy egy-egy ilyen, felderítő jellegű, nem létező url-es kérés nemcsak a tüzfal szempontjából lényeges, hiszen éppúgy telenyomja az apache2 logját szeméttel, mint utána mondjuk a logcheck kimenetét.
Bizonyára láttatok már apache error logot, és azt is láttátok, hogy egy-egy ilyen IP-ről nem egy url-t kérdeznek le, hanem listából végigmennek az összes szóba jöhető támadási felületen, kezdve a phpmyadmin-tól a wordpress-es bugokig. Tehát a kérdés még mindig ugyanaz.

Az előző hozzászoláshoz kiegészítés:
"a lánc tartalmát időnként tisztítani is kell"
Igen, ez megoldott, php+mysql, a visszatérő ip mnden alkalommal +60s-el növelt időre kap bannt, ezután a php törli az iptables-ből. Jelenleg 6365 IP van az adatbázisban...

failban?
Ismerem, más szervereken használom is, de ott a szerver logok monitorozására hsználom, url figyelésére én nem tudom, lehet-e használni, plusz azt is figyelni kell, hogy mondjuk a google-t, és kis társait nem illik kibannolni....

"szerver logok monitorozására hsználom, url figyelésére én nem tudom, lehet-e használni"
Tekintve, hogy a webszerver logjába bekerülnek a 404-ek is, így csak az igényeknek megfelelő regexp(ek)et kell megírnod hozzá.

"Jelenleg 6365 IP van az adatbázisban..."
Nem tudom mennyi idő után törölsz, de túl hosszú időre nincs értelme hagyni.

Utaltál arra, hogy a netfilter alapú ellenőrzést drágának találod. Biztos jól írtad meg a szabályokat? Mert amellett, hogy a hatezren felüli blokkolást soknak találom, az adott láncra nyilván csak a TCP/80-ra (443-ra stb.) menő NEW állapotú, SYN csomagok szűrésénél ugrottál eddig is, a többivel úgyis átugrottad ezeknek az IP-knek az ellenőrzését. Szóval milyen gyorsan jönnek az ilyen típusú kapcsolatok, amely annyira megviseli a hardvert?

Szóval... a 6365 ip az adatbázisban van, magában a fullbanned-ben változó számű, 10~100 ip van, az adatbázis elsődlegesen arra kell, hogy nyilvántartsam a visszatérőket, másrészt, ha már adott az adatbázis, akkor ez alapján törlöm (cron) a lejárt bann-okat.
Igen, a lánc jó, viszont csak akkor működik, ha visszatérő a látogató, ha új, akkor a cimben emlitett rule engedi neki a garázdálkodást. Egy példa a banned logból:

2013.08.16. 15:12:40; mysite.hu 211.110.140.196; POST;Mozilla...; .NET CLR 3.5.21022); /wp-login.php; badurl
2013.08.16. 15:12:40; mysite.hu 211.110.140.196; POST;Mozilla...; .NET CLR 3.5.21022); /wp-login.php; badurl
2013.08.16. 15:12:40; mysite.hu 211.110.140.196; POST;Mozilla...; .NET CLR 3.5.21022); /wp-login.php; badurl
2013.08.16. 15:12:41; mysite.hu 211.110.140.196; POST;Mozilla...; .NET CLR 3.5.21022); /wp-login.php; badurl
2013.08.16. 15:12:41; mysite.hu 211.110.140.196; POST;Mozilla...; .NET CLR 3.5.21022); /wp-login.php; badurl

MÁR AZ ELSÖ sornál bannolódik, de mivel --state RELATED,ESTABLISHED -j ACCEPT, ezért még további 80x próbálkozik a nyomorék koreai...
Igen, tudom, a sorrend... de pont ezért tettem fel a kérdést, hogy ezt másképp megoldani...
"Szóval milyen gyorsan jönnek az ilyen típusú kapcsolatok, amely annyira megviseli a hardvert?"
Nem, a hardver ennyitől még messze nem zakkan meg, de engem nagyon idegesít.... :-)
a többi hozzászólás alapján a conntrack környékén lesz a megoldás, de ha minden kötél szakad, akkor a fail2ban is jó ötlet lehet...

Szoval arrol van szo, hogy egy chain-t amiben van max 100 szabaly nem akarsz elorebb rakni? Conntrack-ben mennyi bejegyzes van atlagban vagy csucsidoszakban illetve kb mennyi packet/sec -rol beszelunk?
Mar nem azert de ennyi plusz szabalyt elore rakva nem lenne szabad eszrevenni teljesitmenyben es tovabbra is azt mondom, hogy felesleges megoldast keresel, de ha ennyire nem bizol iptables teljesitmenyeben akarod akkor probald ki ipset-et.

Szia!

Persze mindent meg lehet oldani másképp, ki mit szeret, pont ettől
szép a nix világa.
Szerintem annyit tegyél, hogy olvasd el ezt:
http://conntrack-tools.netfilter.org/conntrack.html

Ha mélyebben is érdekel a téma, hogy mi és miért van, akkor meg ezt:
http://www.iptables.info/en/connection-state.html

Ezek után módosítsd a php szkripted úgy, hogy az iptables blokkolási táblába
kerülés előtt még a conntrack táblából távolítsa el az adott IP-re vonatkozó
bejegyzést.

Aszabi

IGEN, ez lesz a jó megoldás, csak valószínűleg én kérdeztem rosszul...
A helyes kérdés az lett volna, hogy hogyan lehet eltávolítani a conntrack táblából egy adott IP-t.
Köszi a linket, átnézem, bár egy egyszerű mintát irhattál volna, hátha más is belefut valami hasonlóba:-)

Ui.: Ezt a linket(http://www.iptables.info/en/connection-state.html) én is megtaláltam, de akkor nem esett le, hogy ez kell nekem...

( csabka v | 2013. 08. 24., szo – 17:00 )

ipset?

amúgy a fail2ban "megoldása" is jó lehet neked.... mármint nem feltétlen fail2ban loganalizálás alapú iptables szabálylétrehozás automatikusan, hanem az, hogy iptables lánc elejére fűzöl egy match-et, amit eldobsz egy saját új láncra ahol szépen pakolod be a banned ip-ket..

pl:
# új lánc létregozása:
iptables -N blokkolt_lista
# új láncban ha nincs illeszkedés dobja vissza a főláncba és folytassa a tűzfalszabályok további illeszkedését:
iptables -A blokkolt_lista -j RETURN
# ez a szabály az INPUT táblából minden 22,443,80 -as portú forgalmat belepattint a saját láncra (persze itt lehet tovább finomítani a MATCH-et NEW,RELATED,ESTABLISHED -re stb)
iptables -I INPUT -p tcp -m multiport --dports 22,443,80 -j blokkolt_lista

# a scripted pedig "csak" pakolja a listába:
iptables -I blokkolt_lista -s 1.2.3.4/32 -j DROP

#fentiek alapján működik a fail2ban is, csak a listába pakolást logelemzéssel végzi...

az ipset azért elegánsabb mert akár több szerveren átívelő közös listát is lehet csinálni, illetve gyorsabb a matchelése, mert a listának adhatsz "típust" hogy pl ipv4 címeket tárolsz benne csak és kizárólag valamint lehet időt megadni, hogy meddig legyen a listába (bár Kadlacsik Józsi többet tudna mesélni erről, de úgy körvonalakban). Nézz utána.

Nem hiszem, hogy a forgalmon észreveszed (ipset-es esetben biztos vagyok benne hogy nem, mert gigabitre tervezték... de a fail2ban jellegű esetben is mivel return-al visszaugrik és nem vegyes matching van a saját láncban, hanem csak source ip+drop valamint párhuzamos láncon /nem a fő láncban/ ezért elhanyagolható, hogy a láncra ráterelsz related,established forgalmat is... )

Ezek a megoldások jók lennének, de valamiért a szabályai sorrendjén nem akart változtatni. Márpedig ahogy írta, az első szabálya csak conntrack alapú, "-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT". Ezt követően már bármi jöhet, akár recent modul, akár külön chain, akár ipset alapoon, ami a connection tracking szerint ESTABLISHED, az átmegy.

Ezt írta: "viszont ha "bent" van, és utána csinál valami nem megengedettet, akkor valahogy ki kell onnan lökni!". Lefordítva: ez gyakorlatilag az ő esetében a HTTP keepalive-os kapcsolatokat jelenti, ezeket akarja megszakítani, ha a kliens egyazon TCP sessionben nem kívánt URL-t kérdezett.

Márpedig ha a keepalive engedélyezve van a szerveren - és miért ne lenne - amíg a TCP session él, addig a webszerver engedni fogja a próbálkozásokat. (Apache esetén default 100 a MaxKeepAliveRequests értéke, azaz egy TCP sessionben akár 100 URL-t is megpróbálhatna a kliens.) A kérdező ezt szeretné megakadályozni, illetve egyre korlátozni.

A connection trackingből törli, így a következő csomag NEW lesz, ami azt jelenti, hogy az első szabályra nem illeszkedik, tehát a további szabályok is szóhoz jutnak.

Ami javaslatokat a conntrack módosításán kívül írtunk, mind feltételezte, hogy az ESTABLISHED átengedése elé kerülhetnek. Nem kerülhettek.

+1 Itt a pont!
Tegnap este átállítottam tcpkill-ről conntrack-ra, szépen, nyekkenés nélkül dolgozik!
Az igazsághoz tartozik, hogy nemrég feltettem az xtables-t, (GeoIp for iptables) és azóta hál' istennek, drasztikusan lecsökkent az ilyen támadások száma, de valahogy a tcpkill-es kilővést akkor sem tartottam jó megoldásnak, de nem találtam mást, azért kérdeztem itt a fórumon a tapasztaltabbakat.

teljesen világos volt, hogy mit szeretne, s tudtam, hogy a conntrack-ot lehet tekergetni ezügyben, s mivel valaki írta ezért már nem írtam én is meg... de akkor sem tűnik/tűnt életszerűnek a RELATED,ESTABLISHED utáni blokkolás indoka, hogy miért ne mehetne végig a blokkoló láncon a RELATED,ESTABLISHED láncokon jelenleg futó forgalom...

Erre írtam, hogy ipset objektum (pl ipv4 halmaz) alapú match-et tud paraméterezhetően (nem vagyok benne biztos, hogy a recent objektum alapú-e vagy sem, de úgy tudom, hogy az ipset gyorsabb... bár sosem mértem).
Így gyakorlatilag a RELATED,ESTABLISHED előtt egy sor lenne ami az ipsetre hivatkozva a benne levő ipcím objektumokra matchelés esetén blokkol... sokkal gyorsabban mintha láncban végig kellene mennie egyesével a forráscímek alapján... erre találták ki.

( kallaics | 2013. 08. 24., szo – 17:09 )

Hali,

a saját láncot előbb hívd meg vagy használj a -A helyett -I -t. Nem tudom,hogyan indítod a tűzfal scriptet attól függ melyik a kényelmesebb neked.

( bAndie9100 | 2013. 08. 24., szo – 19:45 )

az aktuális kapcsolat kinyírására, de hátha valakinek van jobb ötlete

vedd ki a conntrack táblából! 


conntrack -D -s $REMOTE_ADDR -d $SERVER_ADDR -p tcp --orig-port-dst $SERVER_PORT

mindemellett hülyeség a web portra beengedõ szabály után droppolni az adott forrást.

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

YESSSSSSS!!!! Ezt kerestem!

"mindemellett hülyeség a web portra beengedõ szabály után droppolni az adott forrást."
A beengedő szabály a default, hiszen ez egy több, közepes forgalmú honlapot tartalmazó szerver, viszont ha "bent" van, és utána csinál valami nem megengedettet, akkor valahogy ki kell onnan lökni!
KÖSZÖNÖM a SEGÍTSÉGED!

Szerintem az egész koncepció (amire itt megoldást adtál) egy orbitális faszság.
Ha egy TCP kapcsolatot megengedtem létrejönni, és ahhoz tartozik a gépen egy processz, aki azt a kapcsolatot terminálja (pl. egy apache), akkor a meglevő kapcsolatot nem úgy szüntetjük meg, hogy a tűzfalszabályokon keresztül mondunk akár egy TCP resetet, vagy depláne egy a silent DROP-ot, mert egyik se korrekt (a második mondjuk már az öntökönbökés tipikus esete).
A korrekt megoldást a kapcsolatot termináló processz tudja elvégezni: close(). Hogy erre az apache-ot hogy veszed rá, az már más tészta, de a történetet nem a tűzfalban kell megoldani (az majd jó lesz a további kapcsolatok kezelésére).

mint írtam, én ilyet pl. dhcp bérletek idõkorlátjának betartatására használok.
ezesetben még ha minden helyi processzben elintézem, hogy tudatosan zárja le a socket-ot, a távoli (NAT-olt) kapcsolatoknál ezt képtelenség a socket-ot fenntartó processzel elintézni.

ezért van egy olyan szabályom is, hogy 


-p tcp -m tcp --tcp-flags FIN,SYN,ACK ACK -m state --state NEW,UNTRACKED -j REJECT --reject-with tcp-reset

egy felépült kapcsolat flag-jeivel rendelkezõ, de a conntrack-ben nem nyilvántartott csomagot elméletileg RST-vel lezár.

igaz, még egyéb lehetõségek is léteznek a figyelt flag-ekre (PSH) és a lezárás flag-jeire (FIN), ezért nem tartom teljesnek ezt a módszert, de fenntartom, hogy a socket-ek ilyen szokatlan lezárását végezheti a tũzfal.

~~~~~~~~
Linux 3.2.0-0.bpo.4-486
Debian 6.0.7

"de a történetet nem a tűzfalban kell megoldani"
Igen, én is gondolkodtam rajta, hogy megkeresem Ivánt, Szását, a kis Xient, és a többieket, és jól orrba vágom őket, hogy haggyá már békén! ...de a tűzfal egyszerűbbnek, és gyorsabbnak tűnt. :)

Az apache2 rengeteg olyan modult tartalmaz, amivel növelhető a biztonság, de ezek nélkül is épp elég CPU-t, és MEM-et elzabál, ez (nekem legalábbis) light-abb megoldás minden szempontból.
Esetleg, ha egy konkrét példát írsz, hogy neked milyen jobb ötleted van, állok elébe, a tudástól még senkinek nem lett baja(állítólag) :)