Hi, Thanx to everybody here, for so quick replies!
On 2/15/11 12:30 AM, Sam Varshavchik wrote: > Lorenzo Perone writes: > >> I was wondering whether there is some way in Courier (using authlib, >> using authmysql) to catch the event of a multiple login failure, such >> as in the case of spambots trying to bruteforce an account, to >> temporarily ban the IP? >> ... > Just have to have something parsing mail logs, which will record the > client's IP address, and a very distinctive error message. > > But, I don't believe that spambots are really that much of an issue > here. The built-in error delay makes spambots give up rather quickly. You're perfectly right, in fact. They weren't bruteforcing, just guessing a few typical pitfalls (doh!). And I had forgotten about the delay, which is a perfect deterrent. So we resorted to another idea. In fact problems with spammers using some compromised account have been extremely rare (until now), so it is more important to find out about it early than trying to solve an assumed cause. I'm now monitoring the mailq size via zabbix (as simple as mailq | wc -l ) and triggering alarms when it keeps growing too quickly. Do you think mailq output is a reliable indicator, or should we resort to maillog analysis for this, too? One reason why I ask is that I vaguely remember messages stuck in the mailq for months, allthough I haven't seen such ones in a while. Thanx for sharing your insight, for all these years over & over.. On 2/14/11 8:21 PM, Carlos Lopez wrote: >> You can use either, Mysql or authlib logs and then do a grep or any similar >> tools that can filter any failure login. >> On 2/14/11 8:27 PM, Bowie Bailey wrote: > Check out fail2ban. You can use it to watch the log files and ban any > IP with more than a certain number of failures. It can be used for any > service that logs failures. > Thanks for these tips too. I know about these possibilities, I just thought that maybe I was missing something more 'event based' or 'builtin'.. As for the bans (based on clam/other criteria), I already use a combination of temporary bans at courierfilter level (sql tables) and (for the stubborn IPs) at os level (pf tables, freebsd). Regards, Lorenzo ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
