lee wrote:
> On Tue, Jun 07, 2011 at 09:58:20PM +0000, W B Hacker wrote:
>> lee wrote:
>>> Hi,
>>>
>>> is it possible to automatically blacklist clients that repeatedly fail
>>> SMTP authentication? And if so, how is it done?
>>>
>>
>> By 'clients' do you mean:
>>
>> - apparent break-in attempts
>
> Obvious break-in attempts:
>
> I´ve only recently enabled SMTP authentication so that I´m able to
> send email via my cellphone. So far, I´m the only user who uses it,
> and there aren´t going to be many more, if any. Today, I´ve seen a lot
> of authentication attempts logged from two different IP addresses,
> i. e. someone obviously trying to break in in order to use my server
> to relay their messages.
>
> Exim dropped the connections after so many failed non-mail commands:
>
>
> [...]
> 2011-06-07 22:58:00 fixed_cram authenticator failed for (cmykhhz.com) [217.97.156.130]: 535 Incorrect authentication data
> 2011-06-07 22:58:01 SMTP call from (cmykhhz.com) [217.97.156.130] dropped: too many nonmail commands (last was "AUTH")
>
>
> fixed_cram:
> driver = cram_md5
> public_name = CRAM-MD5
> server_secret = ${if eq{$1}{foo}{bar}fail}
>
>
>> And in any case, on which arrival port(s) and with which protocol?
>
> SMTP protocol on port 25
smtp? AND NOT esmtps?
Tell me you are joking?
>
>> The problem should go away with no need to blacklist if you get the
>> combination set optimally.
>
> What I have in mind is to simply have exim deny connections (or all
> auth attempts) from the IP in question after the authentication failed
> so many times --- perhaps that´s a feature already built in?
Sort of.
It usually JFW if you AUTH on the userland submission port and with the
encryption protocol expected:
587 with SSL/TLS
AND NOT 25 with neither...
That should cure it, but for those who do not learn, there are some
other ways to drop the WinBots on theirazz w/o blacklists;
Distinguish between traceable peer MTA with credentials and WinBots:
In acl_smtp_connect, do a by-IP VIP whitelist check to skip this, otherwise:
deny
condition = ${if eq{$interface_port}{25}}
!verify = reverse_host_lookup
God guys remain, 'bots are tossed off the teat without further ado.
Then on port 587, where you expect incoming to NOT be a credentialed
peer MTA, but rather NAT'ed DHCP off WiFi, GPRS, HDPSA, .. whatever ..
at least insure that AUTH is coming in over an encrypted connection by
checking $interface_port and $received_protocol.
At that point you should be safe with
authenticated = *
though that also can be further restricted.
>
> If it´s not a built-in feature, perhaps I can make it so that exim
> appends the IPs in question to some file which is used for a
> blacklist. I wouldn´t even need to expire the IPs anytime soon :)
>
Very Bad Idea.
At some point, a WinCrobe will be detected coming from the IP pool of
your *own* connectivity-provider, ELSE one you need when traveling, get
it listed, then one day you'll be given a DHCP lease on the same IP and
be unable to submit to your own host.
BTDT, GTTS .. and two post cards..
> This must be a very common problem. Everyone offering email services
> to remote clients and using SMTP authentication probably has it?
Not at all common. Rare as low taxes.
Further ... end-users trying to submit on port 25 is a bad idea for
ANOTHER reason.
Any sane connectivity-provider either blocks traffic TO any foreign port
25 as a destination FROM inside his subscriber IP pool, AND/OR diverts
it to their OWN MTA. That stops the majority of WinBots before they
blacken the provider's name and get his fixed-IP blacklisted as well.
By contrast, as encryption and AUTH are to be used on port 587, he is
not at risk - any abuse and it is the far-end MTA and IP range that take
the blame, not him, so it is very rare for 587 to be similarly blocked
or intercepted.
Mobile devices? I have an older-technology 2G-not-3G-not-4G GSM/GPRS
only Samsung BT2100 that has no problem with any of that.. just set for
separate smpt and IMAP, set protocol and port with manual over-rides if
the defaults don't fit your needs.
> It´s
> pretty unlikely that someone manages to find out the authentication
> information needed,
'Pretty unlikely' is the artillery round that vaporized the guy buried
in the tomb of the Unknown Soldier. And several hundred thousand others
like him.
'Coz it is actually NOT that unlikely. Read the news.
All too often the lazy use a subscriber's $local_part@domain as the UID,
and THAT info gets to be found all over the 'net as it is used.
HALF the mystery.. no longer requires guessing..
And encryption is a MUST i the OTHER half is not to be also exposed.
Then also passwords are often limited to 16 characters.
Not hard to brute-force that combination with modern equipment,
especially if a botnet is parallelizing the attempts across millions of
hijacked Winboxen.
Adding more places to the UID and PWD, and NOT using the email address
for UID, and insuring BOTH are ALWAYS transmitted over an encrypted
channel - end-to-end, is more effective than using so-called 'random'
characters on shorter ones. Hash alone is not good enough.
> yet there´s no point in letting them try as much
> as they want. There have been 5038 failed auth attempts from only two
> different IPs today, and I don´t like that.
They make the attempt because offering AUTH on port 25 (more especially
if not requiring encryption!) indicates legacy cluelessness, ergo expect
you to have made OTHER mistakes they can exploit.
WHEN you offer AUTH only on port 587 AND only SSL/TLS secured, those who
code such Winbots won't waste so much of their time and your resources.
Bill
--
韓家標
