Mailing List SIMS@mail.stalker.com Message #14954
From: Bill Cole <listbill@scconsult.com>
Subject: Re: Blacklist Setting
Date: Tue, 19 Apr 2005 10:49:07 -0400
To: SIMS Discussions <SIMS@mail.stalker.com>
At 9:15 AM -0500 4/19/05, Dave Pooser  imposed structure on a stream of electrons, yielding:
 If I have this entered in my blacklist entry
 222.0.0.0-222.183.255.255

 Why do I still get this in my logs?

 00:00:00 0 SYSTEM Opening a new log file on Tuesday, April 19, 2005
 00:00:00 0 SYSTEM Account {connect} Resources open failed. Error Code=-43
 00:00:00 1 SMTP {connect} AUTH failed: password(654321) is wrong.
 Connection from [222.183.149.23:1381]

Because SMTP AUTH overrides blacklists. You would have to block this range
at your firewall/router to prevent this sort of hacking attempt.

Just an expansion on that correct explanation...

The blacklist does not bite at connect time, but at RCPT time, i.e. blacklisted IP addresses are allowed to connect, introduce themselves, attempt to authenticate, and give the envelope sender address, but when they give envelope recipient addresses, they are all rejected. This is done to allow authentication override blacklisting and to do the rejection at the point where it is most likely to be treated by senders as a definitive permanent rejection.

Having SMTP AUTH override blacklisting is a useful tool. Beyond that, the way AUTH works means that there is no way to reject an SMTP client before AUTH in a way that would widely be recognized by normal mail senders as a definitive rejection, rather than an incident that should cause a retry at a secondary MX or a later time.

The solution for badly infested network space without a need for exceptions (like 218*-223* for most people without legitimate Asian mail sources... ) the only way to address this problem is at the network layer: just don't let the port 25 traffic from those addresses in at all. That is an imperfect approach, but it is all there really is to address the problem.

If SIMS were ever to get more features, one I'd like is a protection against just that sort of attack. One auth failure on a session should kill off its ability to have a successful auth (no mail client retries failed auth on the same session) and something like the dynamic TempBan list applied to auth failures would be useful as well. Any IP address with more than $SMALLNUM auth failures in $SHORTTIME even across multiple sessions should get tarpitted and shunned from any hope of auth success for an extended period.

On the other hand, I'm just a bit of free time away from migrating off of SIMS, and I expect that Tiger will make that simpler by having a more current version of Postfix than Panther. I should not be suggesting new features for SIMS at this point, no matter how slim the chance of them ever happening is.

--
Bill Cole
bill@scconsult.com

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster