hello,
Nagyon megszaporodott az egyik szerveremen a pop3 brute force kiserletek szama:
Aug 21 09:50:31 vili pop3d: Connection, ip=[::ffff:62.193.211.170]
Aug 21 09:50:31 vili pop3d: LOGIN FAILED, user=admin@56.12, ip=[::ffff:62.193.211.170]
Aug 21 09:50:36 vili pop3d: Disconnected, ip=[::ffff:62.193.211.170]
Aug 21 09:50:36 vili pop3d: Connection, ip=[::ffff:62.193.211.170]
Aug 21 09:50:36 vili pop3d: LOGIN FAILED, user=admin@56.12, ip=[::ffff:62.193.211.170]
Aug 21 09:50:41 vili pop3d: Disconnected, ip=[::ffff:62.193.211.170]
Aug 21 09:50:41 vili pop3d: Connection, ip=[::ffff:62.193.211.170]
Aug 21 09:50:41 vili pop3d: LOGIN FAILED, user=admin@56.12, ip=[::ffff:62.193.211.170]
Aug 21 09:50:46 vili pop3d: Disconnected, ip=[::ffff:62.193.211.170]
Aug 21 09:50:47 vili pop3d: Connection, ip=[::ffff:62.193.211.170]
Aug 21 09:50:47 vili pop3d: LOGIN FAILED, user=admin@56.12, ip=[::ffff:62.193.211.170]
A gepen postfix van a pop3 kiszolgalast courier vegzi.
Ki hogy szokott ez ellen vedekezni? Van valami courier beallitas, hogy pl. ha a sikertelen login kiserletek szama egy ip-rol egy adott ido alatt meghalad egy limitet, akkor varakoztassa mondjuk fel orat?
Tudom, az iptables-szel lehet ilyent csinalni, ill. talaltam egy fail2ban csomagot is. Melyik a "legolcsobb" eroforras-kimelo megoldas?
koszi
Zamek
Hozzászólások
fail2ban +1
--
Nem az erős, aki sosem esik el, hanem az, aki mindig fel tud állni!
+1 de mostanság annyi van, hogy lassan ez nem elég. Érdekes módon az SSH próbálkozások meg vissza estek.
Ha megengedi a szolgáltatás célközönsége, nyugodtan be lehet lőni, hogy csak magyarországi IP tartományokra engedélyezed a pop3-t.
Esetleg 1-2 környező ország és slussz.
-> ipdeny.com
Belottem a fail2ban-t, meglatjuk mire jut
Koszonom az otleteket
fail2ban sajnos kutyagumit sem ér ilyen esetben.
Mostanában egyre inkább pár száz IP-s botnetekkel találkozom, egy IP nem próbálkozik egymás után annyiszor, hogy a fail2ban blokkolná.
Vagy ha mégis, akkor sem ér semmit marad elég bot a netben....
Az egyetlen dolog amit hatásosan meg tudott fogni a fail2ban, az a szerencsétlen user volt, aki mail klienst cserélt, és nem emlékezett pontosan a jelszavára...
Én úgy gondolom, hogy a megoldás a levélforgalom valamilyen statisztikai elemzésében van, ami bizonyos eltérések esetén riaszt.
nem tudom, tegnap tettem fel es ezek vannak a logban:
Aug 13 07:50:56 vili pop3d: Maximum connection limit reached for ::ffff:66.85.157.94
Aug 13 07:51:27 vili last message repeated 101 times
Aug 13 07:52:28 vili last message repeated 183 times
Aug 13 07:53:29 vili last message repeated 228 times
Aug 13 07:54:30 vili last message repeated 115 times
Aug 13 07:55:31 vili last message repeated 154 times
Aug 13 07:56:32 vili last message repeated 135 times
Aug 13 07:57:33 vili last message repeated 203 times
Aug 13 07:58:40 vili last message repeated 82 times
Aug 13 07:59:40 vili last message repeated 140 times
Aug 13 08:00:40 vili last message repeated 257 times
Aug 13 08:01:40 vili last message repeated 182 times
valamit megiscsak er.
A jelenseg az volt, hogy sima brute-force-szal probalkoztak tobb szaz/ezer usernevvel
van amit megfog, van amit nem.
A semmitől a fail2ban is jobb.
Egyre gyakrabban látom nagyobb mail szervereknél, hogy botnetek próbálkoznak 100+ ip-ről, és elég kevés IP az, ami ténylegesen tiltólistára kerül.
http://configserver.com/free/csf/
"Ki hogy szokott ez ellen vedekezni?"
Egyre inkább védhetetlen.
Múltkor egy ügyfél szerverén felnyomták az egyik pop logint, és smtp auth-al kezdtek spammelni.
Alig lehetett észrevenni.
Már nem a "ráöntjük a spamet, hogy beledöglik a szerver" a menő technológia.
Valami kínai botnet lehetett, de egy IP-ről max 4-5 levél jött, és 1 perc alatt csak 15-20 levelet nyomtak be több IP-ről. (Összesen egyébként kb 2-300 IP-ről tolták a szart.)
A napi forgalom kevesebb mint 10-20%-al nőtt, a mail queue-ban alig volt több levél mint egy erősebb napon.
Ha direkt nem figyeled valahogy, és peched van, ezt napokig nem szúrod ki, mert teljesen beleolvad a normál mail forgalomba. A csak magyar IP sem játszik, mert pl. ezt a szervert alapesetben több országból is használták. (Adott ritka esetben még kínai IP is lehetett legitim kliens.)
Írtam rá egy kis python scriptet, ha 1 login 10 percen belül 10-nél több levelet küld (ip-től függetlenül), akkor visít.
A fail2ban-al ha jól emlékszem nem nagyon lehet megoldani, hogy ne nézze a kliens IP-jét.
az ipv6 terjedesevel pedig csak meg rosszabb lesz a helyzet...
Miert kell nekem sajnalnom a Klubradiot?
Miért?
Kb. mindennek egyedi IP-je lesz, így pl. kevesebb lesz a nat routerek mögül jövő, azonos IP címen lógó zombi, amit IP alapján fail2ban jellegű megoldásokkal jelenleg könnyen meg lehet fogni.
Ráadásul az IP címek számnak növekedésével a dinamikus IP alapú szűrések egyre több erőforrást fognak zabálni, ha minden szar folyamatosan változó egyedi címekről jön.
Subnetet kell nézni nem 1 darab ip-t.
nem, mert konkret subneteket fognak tiltani reflexbol
jaja, vegul is baltaval is lehet agymutetet vegezni...
Miert kell nekem sajnalnom a Klubradiot?
Most bannolsz egy ip-t ami mögött kitudja hány user van (NAT), ez után pedig majd /64-el operálsz.
ha olyan IP-t blokkolsz, ami mogott NAT es userek vannak, akkor valoszinuleg nagyon mellelottel. Aki meg /64-et (=2^64 IP-cim) akar blokkolni (biztos 1 spammerhez tartozo osszefuggo blokkrol van szo, LOL), arra en nem biznek mail szervert...
Miert kell nekem sajnalnom a Klubradiot?
ööö, te most mégis miről beszélsz?:)
Elvileg /64 lesz adva végfelhasználóknak, vagyis hasonlóan mint most az ipv4 cím.
"ha olyan IP-t blokkolsz, ami mogott NAT es userek vannak, akkor valoszinuleg nagyon mellelottel."
Te ezt el tudod dönteni? Mester, taníts!
LOL, mester, egyreszt odairtam, hogy "valoszinuleg", masreszt, ha mar rakerdeztel, akkor igen, el tudom donteni, legalabbis az alapjan, hogy a sajat spameket nezegetve a levelgane leggyakoribb forrasai a vps-ek, a colocation-ben ulo gepek, hirlevel szolgaltatok, gmail/yahoo/n+1-dik random freemail es persze a meg ki nem halt botnetek. Egyik mogott sincs ceges halo nat-olt userekkel...
Miert kell nekem sajnalnom a Klubradiot?
Egy vps-hez is kapsz min /64-et, miről beszélünk?
A botnetek meg csak szerverbol allhatnak, meg veletlenul sem fertozott, nat mogott ulo gepekbol. Ugyanmar, hogy josz te ahhoz hogy megprobalod szegenyt kioktatni?;)
szovegertes nem rulez, mester? En azt irtam, hogy "a sajat spameket nezegetve" nem ez a jellemzo, nem azt, hogy a jelenseg nem letezik...
Miert kell nekem sajnalnom a Klubradiot?
nekem irod hogy szovegertelmezes nem rulz, mikozben en kerdeztem ra arra, hogy mi alapjan mondod, hogy valami nem natolt/nem natolt, foleg egy botnet alapjan. Erre nem erkezett valasz, azota meg flame modba kapcsoltal. Az hogy a rlookup mit mond, megint egy masik kerdes
Amit írsz nagyon is valós probléma. Elég egy vírusos gép + outlook kliens.
A problémára első körben ezt találtam: http://www.simonecaruso.com/user-send-rate-limit-for-postfix/
Nem lőttem még be. Érdekelne esetleg más hasonló megoldás is, bár jónak tűnik.
Meghatározod a napi kvótát, ha túllépi lehet tovább gondolkozni.
Nyílván egy 10-20% baromira nehezen észrevehető, de ez függ az adott ügyfél levelezési szokásaitól.
Most jutott eszembe esetleg egy olyan követő kvóta, ami az előző hónap alapján követi az ügyfél szokásait. Ha átlagban kevesebbet levelezik, lentebb veszi a kvótát (előző hónap + x %). Nem kell feltétlen droppolnia, elég ha dob egy mailt neked, hogy ide érdemes ránézni.
Talán nem hasztalan gondolat.
az okozza a nehezseget, hogy mindig lesz par debil, aki egy realis kvotaba is beveri a fejet, mig a fenti spammer siman a radar alatt marad.
Miert kell nekem sajnalnom a Klubradiot?
Ez nem rossz.
Ezt talán úgy módosítanám, hogy egy soft-quotát is felvennék bele, aminek elérésekor figyelmeztető levelet küldd a rendszergazdinak, és a hard-quotát pedig megfelelő magasra állítanám alapból mindenkinek, és ha azt is eléri, akkor reject.
Abban mindenképpen jobb mint az én megoldásom, hogy userenként egyedileg is konfigurálható, így a rendszeres hírlevélküldő usereknél, vagy központi kimenő címet használó usereknél sincs gond.
ha lesz rá időm normálisan megcsinálni, szerintem használni is fogom. Köszi a linket.
Én úgy vettem ki, hogy itt is e-mail címenként állíthatod a limitet.
ez így van, pont ezért írtam, hogy jobbnak tűnik mint az én megoldásom.
Jaj, elnézést, a "mint"-et átfutottam :)
+1 Ez jól hangzik!:)
Végül próbálta valaki? Én most jutottam oda, hogy leteszteljem, de nem sikerül belőni.
A mysql kapcsolat felépül, ha szándékosan elrontom a mysql logint akkor csipog rá. Ha jó, akkor fogadja a kapcsolatokat. Logban jelzi is, hogy Client 127.0.0.1 connected.
Mást azonban nem logol és nem is updateli a mysqlben lévő értékeket.
Nem igazi védekezés, de nálam a user-ek login nevei user@domain formában vannak...
A naplókban csak user-t látok...
Így sosem fognak bejutni brute force-al...
--
Debian Linux rulez... :D
ne aggódj, majd rátalálnak az inteligensebb botok a szerverre, akik a domainek MX-e alapján keresgélnek, és csak user@domain -al próbálkoznak. :)
Még nem tették :D
--
Debian Linux rulez... :D
Akkor még mindig jó lesz a user.domain login :)
Ha sql-ben tárolod az usereket, szép terhelést tud okozni egy ilyen folyamatos próbálkozás.
És persze hogy nem sql-ben van... :D
--
Debian Linux rulez... :D
nscd ellenben nem ártana.
Ellenben ldap simán megbirkózik az ilyen dolgokkal... szóval nscd sem kell, mert virtuális userek vannak...
--
Debian Linux rulez... :D
Már ha nem ismered az indexelés fogalmát és képtelen vagy a my.cnf -et megfelelően birizgálni. query cache azért elég sok mindent megold.
Tehát azt mondod, hogy megoldható random username lekérések esetén az, hogy 1000 e-mail címes táblából terhelés nélkül _folyamatos_kiköpje, hogy van, nincs van, nincs, nincs, nincs, van?
Mert ugye a brute force során másodpercenként azért jónéhány kérést bekap.
Ha van rá konkrét megoldás, érdekelne.
valami rate limit jellegu dolog azert segithet a dolgon. Akar IP-szinten (pl. pf, iptables tud ilyet), akar alkalmazas szinten (nem tudok egy pop3 demonrol sem, ami ilyet tudna, de meg ha valoban igy is van, hat nem azert open source, hogy bele lehessen patkolni egy ilyet? :-))) idoegyseg alatt csak n db auth kerest szolgal ki per IP-cim/halozat, whatever.
Miert kell nekem sajnalnom a Klubradiot?
egy indexelt 1000-es tábla másodpercenként néhány lekérdezése túró.
Másodpercenként több száz sem okoz jelentősebb terhelést egy átlagos mail szervernek.
Mondjuk gépfüggő, de pl. postgres alatt elegendően kicsi (ezért gépfüggő) táblákat mindenképpen full table scan-el keres végig, tehát index se kell hozzá :)
--
Gábriel Ákos