( diego | 2013. 08. 24., szo – 19:34 )

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...