Fórumok
Vannak rosszindulatú klienseim, akiknek az IP címe, a tevékenységük kiderülése után blokkolásra kerül az iptables paranccsal.
Jelenleg 369 ilyen IP cím van a tűzfalban, de elég tevékenyek a fiúk, így nem tudom, meddig fog ez a szám nőni.
Mennyi IP címet lehet, szoktak, érdemes így blokkolni, és mi van, ha ezt a mennyiséget meghaladja?
Hány közös alhálózatba tartozó IP után érdemes, illő, szokás az IP-k helyett már a teljes alhálózatot blokkolni?
Van értelme elévülési időt is kezelni? Én elsőre azt gondolnám, hogy nincs.
Hozzászólások
"Van értelme elévülési időt is kezelni? Én elsőre azt gondolnám, hogy nincs."
Ezeket az IP-ket ellenőrizted, és mind kizárólag az adott cégre osztott, illetve statikus poolként jelölt címek? Mert ugye a dinamikus IP-k korában lehet, hogy ugyanaz az egy gép jön több címről, és ezzel az is lehet, hogy tartósan tiltasz ki olyanokat, akik csak pl. dinamikus poolból megkaptak egy olyan IP-t, amiről előzőleg valaki téged vett célba. Ezért is van értelme az időkorlátnak.
"Vannak rosszindulatú klienseim, akiknek az IP címe, a tevékenységük kiderülése után"
Röviden tudnád vázolni, hogy témakör szinten milyen jellegű ez a tevékenység? Nem mindegy, hogy pl. "csak" spamforrás, van DoS-olja az egyik szolgáltatásod stb.
Egyelőre a jelszópróbálgatásos belépési kísérleteket észlelem, és ezeket tiltom. Nem sikerült még behatolnia, túl sem terheli a rendszert, de ne is próbálgassa. Az ügyfelek erős jelszavaiban azért annyira nem bízom.
"Az ügyfelek erős jelszavaiban azért annyira nem bízom."
Az erős jelszavakat értelemszerűen neked kell kikényszerítened, és nem az ügyfélre bízni. Azt, hogy milyen a megfelelően erős jelszó, állítsd be. Az ügyfélnek nem is szabad tudnia a jelszó policynek nem mgfelelő jelszavat beállítania.
"jelszópróbálgatásos belépési kísérleteket észlelem"
De milyen szolgáltatáson? SSH? IMAP? SMTP?
A kérdésem arra vonatkozott, hogy biztos vagy-e abban, hogy ártatlanokat nem zársz ki? Illetve biztos-e, hogy tartósan kizárod-e azokat, akik próbálkoznak.
Amúgy a 369 IP blokkolása nagyjából nulla - még akkor is, ha ezt 369 szabályként veszed is fel.
Egy jó jelszókezelő rendszerben nem adhat meg az ügyfél bármilyen jelszót, de sajnos ez nem jó jelszókezelő rendszer, az ügyfél tud és állít is gyenge jelszót magának.
De ha jó jelszókezelő lenne, akkor sem akarnám, hogy felismerten rosszindulatú IP címek elérhessék a szervert.
Eléggé biztos vagyok benne, hogy ártatlanokat nem zárok ki. Legalábbis a kizárás pillanatában, mert a dinamikus IP címek valóban később kizárhatnak ártatlanokat. Ezen még finomítani fogok. Jelenleg, ha dinamikus címeket zárok is ki, azok egy távoli ország címei, és jellemzően egy tartományból több is jön, meg újak ... és még újak. Elég sok egy tartományba tartozó dinamikus cím esetén talán már érdemes lenne a teljes tartományt tiltani.
Továbbá nem elég a felismert rosszindulatú tevékenység az IP kizárásához, de az is szükséges, hogy ne legyen valós tevékenység ugyanarról az IP-ről.
Az IP címek többsége fel sem oldható, ami szintén egy jó szűrési feltétel.
Félő tehát, hogy sok új cím kerül még a listához, akár IMAP, SMTP, FTP vagy SSH alapján, de nem tudom, meddig növelhető az iptables mérete normális keretek között?
Ahogy lentebb is említették, elsősorban az ipset, ez a szép megoldás. De ilyen nagyságrendben még bőven nem kell aggódni a teljesítménycsökkenéssel kapcsolatban, akkor sem, ha IP-nként külön szabályokkal kezelnéd.
"de sajnos ez nem jó jelszókezelő rendszer, az ügyfél tud és állít is gyenge jelszót magának"
Nem írtál arról, hogy honnan megy az autentikáció, de nem tudsz alátenni pl. egy PAM modult (mondjuk passwdqc) sem?
ipset
esetleg fail2ban?
Gondolom, innen indult ez a topic: fail2ban érdekesség vagy bug?
Pontosan. Egyébként a fail2ban is csak iptables szabályokat csinál, tehát a méretet tekintve mindegy, milyen script gyártya le azokat.
"Egyébként a fail2ban is csak iptables szabályokat csinál"
Mondjuk ez így ebben formában csak részben igaz. Actionként bármit megadhatsz, nem csak az "iptables" parancsot a fail2ban default paraméterezésével.
Ezen felül nem csak a blokkoló szabályokat csinálja, hanem a feloldásukról is gondoskodik. A másik topikban felhozott bug az bug, de ettől a fail2ban valamivel több, mint egy iptables-sorokat generáló script. Viszont értem, ha bugba futottál, akkor nem akarod használni.
Megadhatok más action-t is, de ott sem tudnék mást megadni, mivel jelenleg nem tudok mást kezdeni egy rosszindulatú IP címmel, mint iptablessel tiltom.
Tehát, ha van más action ötleted, mit lehet velük kezdeni, azt is örömmel veszem.
Egyébként nem csak a bug miatt került elvetésre. A szabályokat egyedileg tudom csak meghatározni, nálam pedig az összes logot együttesen kell felolvasni, és csak azokat tilthatom, ahonnan nem volt valid forgalom. Ilyent nem tud a fail2ban, így végül kénytelen voltam magam megírni.
+1, n*10.000 IP-t is terhelés nélkül lekezel.
Ez érdekes, mert az ipset készítőjének mérése szerint már 200 szabály felett érezhető a különbség az ipset és az iptables között. Úgy látszik, azóta ennyit gyorsultak a rendszerek.
Összességében nagyon szépnek tűnik ez az ipset-es megoldás!
Több országot tíltok. Kb 65.000 IP van az ipset blacklist chainben. Nem látom, hogy nőtt volna a load (vagy az innen nem érkező látogatók adtak ennyi tehermentesítést a rendszernek és 0 lett az eredmény:) )
ipset alatt nem is szabad nőnie, mivel az közelítőleg konstans idő alatt találja meg a keresett elemet, a halmaz elemszámától függetlenül. Egyre szimpatikusabb.