Zombie szégyenfal

Flame

Ha van Spammer szégyenfal, legyen Zombi is.

A felügyelt hostjaim logjaiból automatikusan gyűjtve egy szép csokor IP:)
Ha valaki ssh-n bepróbálkozik, netán portscant csinál, akkor bekerül.
Ezzel egyidejűleg megy neki az IPTABLES -I INPUT -j DROP is :)

formátum:
IP:count:TimeStamp

http://www.sysmaster.hu/hostiles.dnris

Egy időben még mindegyikre irtam volna a szolgáltató abuse címre...Belefáradtam.

2008-05-19 UPDATE: leállítottam ennek a gyűjtését és az eddigi IP listát is leszedtem. Sorry, nincs időm pöcsölni vele...

  • 3033 megtekintés

( Chain-Q v | 2006. 11. 13., h – 18:49 )

Ez jo otlet! Nagyon korrekt. Asszem applikalni fogok hasonlot a sajat cuccaimhoz. :) Esetleg ha eppen olyanod van, akkor a hasznalt eszkozokrol es pontos modszerekrol csinalhatnal vmi okos leirast. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Eleinte magamnak akartam kifejleszteni, aztán meggazdagodni belőle, de annyira a közérdek vezérel, hogy elérhető lesz, ha leküzdöm az alábbi problémákat:

- hogyan kezeljem a fake syslogot, aminek pont DOS attack a célja (pl. engem mint admint blacklistre tenni a felügyelt hostjaimon)
- hogyan kezeljem a megbízható/megbízhatatlan logforrásokat? valaki előfizet, lefigyeli a működést aztán szépen elkezdi fake forged logokkal bombázni és ellehetetleníteni a szolgáltatást.

Szal valami fasa autentikációs mechanizmus kéne meg checksum, md5sum vagy akármi Nem vagyok nagy kóder, inkább afféle "bitfaragó" (from Wagner tanár úr, ME GÉK, Info szak :)

-----
Si vis pacem, para bellum...

Hát, az ilyet legbiztosabb csak saját/megbízható szerverek esetén használni.
További opció, hogy
1. szankcionálni, ha kiderül a visszaélés.
2. Adott időn belül egy hosttól csak X darab tiltandó IP cím elfogadása. Nem túl valószínű, hogy mondjuk 1 órán belül 5-6 címnél többről érkezne portscan egy adott szerverre. Mondjuk a rendszer még így is felhasználható lenne arra, hogy mondjuk a konkurens cég IP-jét folyamatosan blokkolja valaki. :)
3. Csak akkor rakni be egy IP-t a listába, ha legalább 2 tag bejelenti adott időn belül. Ennek csak az a hátránya, hogy kevés tag esetén szinte kizárt, hogy bármi rákerüljön a feketelistára.

Authentikációval sajnos nem sokra mégy, mert a logba bármit be lehet tolni, nem kell az agentet megpiszkálni hozzá.

Tulajdonképp az igazi megoldás az, ha csak megbízható szerver van a hálózatban, vagyis amit te magad adminolsz.

"Tulajdonképp az igazi megoldás az, ha csak megbízható szerver van a hálózatban, vagyis amit te magad adminolsz."

Igen, én is erre jutottam. Ezt szolgáltatásként kiadni általam nem adminolt szerverekre nagyon veszélyes. Maradnak a trusted szerverek.
-----
Si vis pacem, para bellum...

Ha mégis szolgáltatást akarsz belőle csinálni, akkor esetleg még az szóba jöhet, hogy a kliens beállíthatja magának, hogy kikben bízik meg, mint forrás. Ez mondjuk peer2peer modellben elég eccerűen működhet.
Szerver-kliens modellben ugyanígy, csak ott a szerver olyan forrásból származ adatot küld csak a klienseknek, akik azt a forrást bejelölték maguknak mint megbízhatót. Ez szerver oldalon egy adatbázist igényel, ami elég sok erőforrást is elvihet.
Vagy valami hasonló...

Köszi.
Én kliens-szerver megoldásban gondolkodom és valami olyasmin, hogy a szerver a log fogadást iphez kötni, nem előfizetett syslog csomagot eldobni.
Ez mondjuk a fake ip-ről jövő sysloggal továbbra sem tud mit kezdeni. Ezt valahogy úgy gondoltam megoldani, hogy csinálni egy SHA sum-ot mondjuk a trusted host passwd filejáról és azzal aláírni a csomagot. Ezt a signature-t együtt tárolni az IP-vel és csak akkor komolyan venni, ha a 2 egyezik.
Mondjuk mivan, ha a trusted hostot spoofolt ipről szkennelik, ezzel a trusted host küldi be a hamis logot a szervernek...ááá nem egyszerű.

A szerver pedig pl. scp-n tolja fel a kliensekre a szabályrendszert.

-----
Si vis pacem, para bellum...

Ja, csak a trusted host passwd-fájlja változhat.
Spoofolt IP ről asszem elég nehéz scannelni -nem vagyok security szakértő, de valahogy a scan eredményének vissza kell találni a scannelő gépre.

Asszem syslog-ng vel ki lehet alakítani TCP alapon olyan szerver-kliens kapcsolatot, hogy ne tudjon beküldeni fake IP-ről senki semmit.

Húvazz, ez egyre bonyolultabb lesz. :) :)

"Húvazz, ez egyre bonyolultabb lesz. :) :)"

Nahh ezaz.. Ezért nincs még kész:))

Spoofolt címről akkor érdemes szkennelni ha csak be akarsz tenni egy idegen IP-t a blacklistbe.

Pl. DoS-t akarsz csinálni az x.y.z.p levelező szerver ellen.

van ez a védelmi rendszer, tudsz róla, akérdéses szerver is bene van. fogod és spoofolt címről legitim smtp szerverek küldesz egy marék SYN csomagot 22-es és egyéb nyilvánvaló tcp portra, ezt portscannek veszi a rendszer és az összes hoston kitiltja a legitim smtp szervereket, megáll a levelezés.

na ezért veszélyes.
-----
Si vis pacem, para bellum...

pl kulon ssh, mindenkinek sajat RSA priv kulcs. beloginol, majd oda fossa a syslogot. igy megoldottad a fakeip, fake syslog dolgot. mar csak azet kell megoldanod, hogy az adott gepen sima user ne tudjon trukkozni. (echo "fgsfsfsd" | logger -megfeleloparameterek)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Erről jut eszembe, egyszer megpróbáltam úgy visszaverni egy spam floodot, hogy tail -f maillog, közben másik terminálon pedig iptables-el szúrtam be az IP-ket ezerrel. Görcsöt kapott a csuklóm, de egy idő után leállt a spem áradat...
ezzel is lehetne kezdeni valamit... bár félő, hogy a legitim szervereken bejövő spam is banra kerülhet.

-----
Si vis pacem, para bellum...

Még ugyan nincs vele személyes tapasztalatom (nemsokára lesz), de van egy fail2ban nevezetű python tool, ami ugyanezt csinálja. Figyeli a logfile-okat (pillanatnyilag az apache és ssh log formátumot ismer) és azt az IP-t, amin többszörös auth error-t lát ideiglenesen bannolja iptables/ipfwadm-en keresztül.

( zwei | 2006. 11. 13., h – 19:45 )

Tulajdonképpen real-time lenne jó az egészet csinálni.

Ha esetleg véletlenül nem javított remote-exploitod van, akkor lehet, hogy mire lefut a scripted, késő. Ráadásul, ha megvolt a portscan, és nem talált érdekes dolgot, akkor már nem túl valószínű, hogy visszajön.

Ha sok log van, akkor ráadásul jelentős erőforrásokat is ehet a scipt. (Ha jól értem logelemzőböl indítod.)

Portscan esetén knocking szerverhez hasonlóan meg lehetne oldani. Vagyis N darab nyitott porton figyel egy daemon (mondjuk valahol az első 70-ben, a portscan-ek többsége lentről kezdi), és ha X időn belül bepróbálkozik az összesen valami IP, az valószínűleg portscan, és mehet neki az iptables.
Mondjuk slow-scan ellen nem nagyon véd, de ezt már nem nagyon használják botok, és script-kiddie-k.

A következőképp működik: befutnak a logok a logszerverre több hostról is. Lefut a szkript, elemzi a logokat és ha talál valamit, akkor ban-ra veszi, majd _elkuldi_ az új feketelistát a védett hostokra, a védett hostok pedig magukra frissítik az új iptables szabályrendszert, amint bejött a feketelista.

Ezáltal ha letapogat egy hostot, percek kérdése és védetté válik a többi N-1 host.

Jelenleg 5 hosttal tesztelem.

A végleges verzió pedig: bejön a syslog a védendő hostokról, azonnali elemzés (pl. saját syslog szerverrel), majd azonnali remote iptables injektion az összes hoszton.

Jelenleg még én nyomkodom a proc_Hack.pl szkriptet időnként, amikor kedvem szottyan és látok bejövő logot. Még igy is egész jó.

-----
Si vis pacem, para bellum...

"A végleges verzió pedig: bejön a syslog a védendő hostokról, azonnali elemzés (pl. saját syslog szerverrel), majd azonnali remote iptables injektion az összes hoszton."

Azonnali elemzésre javaslom a logsurfer-t vagy az ehez hasonló real-time logelemző cuccokat.
Bár logserver-t sem nagy cucc írni... :)

Ja, ez nagyon jó ötlet, hogy a többi hostnak is lenyomod a scannelő IP-t. :) Saját ötlet?

Ja, mégvalami: az optimális az lenne, hogy bármelyik host kapja a portscan-t, az szóljon a többinek. Valami p2p, vagy szerver/kliensek jellegű kommunikációs dolgot bele lehetne csempészni. (Vagy ez most is így van?)
Asszem mintha ilyen témában mintha már valami dolgozat született volna...

( smica | 2006. 11. 13., h – 22:12 )

Szoktam látogatni néhány olyan oldalt, amelyekre ha beteszem a lábam, rögtön portscan -t jelez a tűzfalam és természetesen arról az IP -ről, ahol az adott honlap található.
Ezek közül az egyik a www.doksi.hu , amelyet én nagyon sokra tartok, mert a tartalmát tekintve rendkívül értékes, és először észre sem vettem az összefüggést (adott oldal meglátogat --> portscan loggolva)
Amikor a dolgot észrevettem, utánanéztem, hogy a logokban látott IP hová tartozik, majd e-mail -t írtam a rendszergazdáknak és ők azonnal válaszoltak és segítettek kideríteni, hogy miért történik ez az ő szerverükről rendszeresen.
A dologgal végül arra jukadtunk ki, hogy az adott oldal kódjában van olyan rész, amely valamiért automatikusan portscan -el, vagy csak portscan-gyanús tevékenységet folytat (nem értek a webprogramozáshoz, tehát nem tudom ennek okát).
Az oldal készítőit mondjuk nem értesítettem, pedig megtehettem volna. Ez az én hibám.

Egy másik eset szintén úgy zajlott, ahogy a fenti, ez pedig a www.boon.hu oldalt (és ilyenformán a SZON -t és a HAON -t is) érinti.
Az oldalon rendszeresen lehet szavazni e-mail -es megerősítéssel, de végül itt is hasonló levelet írtam, mikor észrevettem, hogy szavazáskor szintén portscan -t kiált a tűzfal. A levelet ugyanarról az e-mail címről küldtem, amelyikről szavazni szoktam.
A reakció az ő részükről már nem volt ilyen korrekt. Nem válaszoltak és azonnal letiltották az e-mail címem, így több lehetőségem szavazatmegerősítésre erről a címről nem volt, mert a megerősítő levelek egyszerűen nem érkeztek meg a szavazásokat követően.

A fenti dolgok egy éve történtek és nem kizárt, hogy azóta a dolog változott, de mivel már tudom, hogy miért történt így, ezért az utóbbi időben nem foglalkoztam ezzel a kérdéssel.

Remélem nem volt túl triviális számotokra a fent leírt jelenség, de örülnék, ha valaki elmondaná, hogy ez hogy lehetséges (a kérdés az adott oldal látogatásából eredő portscan-figyelmeztetésre irányul).

Szerk.: Azt még azért hozzátenném, hogy sysmaster megoldása szerintem nagyon jó.

( csaba | 2006. 11. 13., h – 22:49 )

Én a Denyhosts-ot használom ( http://denyhosts.sourceforge.net/ ), eddig sikeresen. Nem igazán erőforrásigényes, ellenben rendben teszi a dolgát. Hasznos a brute-force ssh kísérletek ellen is.

Csaba