On Wed, 2010-07-21 at 14:57 +0300, Thanos Chatziathanassiou wrote:

Timo Sirainen wrote:

...

On 21.7.2010, at 12.29, Thanos Chatziathanassiou wrote:

...

Would it be possible to deny login if username==password with a (non?)polite/custom message to go change your password to something less obvious ?

What passdb do you use?

passwd-file with md5-crypt though I could easily swap it for an SQL variant.

With SQL this should be pretty easy to do. If password matches username ('%w' = '%u') have it return 'y' as nologin and 'bad password' as reason.

I think I'll be fairly shielded from this kind of things in the future, just brought it up because all of us here manage people's mails one way or another.

I think this is one of the tons of different possible password policies and isn't really Dovecot's job. It really should be enforced while setting the password, not while checking it.

On 07/21/2010 02:35 PM Thanos Chatziathanassiou wrote:

Correct. Should be fairly easy to do - just need a compatible crypt() function in SQL. Never thought of that.

MySQL's encrypt() is your friend: select encrypt('foo', 'ab'); select encrypt('foo', '$1$01234567'); select encrypt('foo', '$5$rounds=1000$0123456789abcdef'); select encrypt('foo', '$6$rounds=1000$0123456789abcdef');

Regards, Pascal

The trapper recommends today: http://kopfkrebs.de/mitarbeiter/mitarbeiter_der_woche.html

Op 21 jul 2010, om 15:06 heeft Leonardo Rodrigues het volgende geschreven:

Em 21/07/2010 09:18, Timo Sirainen escreveu:

...

I think this is one of the tons of different possible password policies and isn't really Dovecot's job. It really should be enforced while setting the password, not while checking it.

i completly agree that dovecot is not the place for enforcing password policies nor checking them.

but, still on the subject, maybe dovecot could have some features for helping sysadmins to avoid/mitigate brute-force attacks. As told, some bots tries username=password, but those fuckers (the bots) also tries lots of common passwords, 123, 1234, the username followed by some numbers, and lots of others.

of course, if the provided password is not correct, dovecot denies access as it should .... but in those situations, logs can get pretty filled with login failed messages, specially on servers with lots of accounts. And, in some cases, after lots of tries, the bot can found the correct username/password combination.

i was thinking on something like ...

1. after N tries (lets say 10 for example) of wrong username/password combinations, dovecot could start delaying the answers for wrong authentications coming from that specific IP address or IP/username, thus slowing down the brute-force attacks; 1.1) or even, after some M (lets say 20 for example) wrong username/password combinations, dovecot could ban that IP address (or IP address/username combination to avoid problem with big networks with NAT access) for XX seconds/minutes, also slowing down the brute-force attack tries 1.2) this could probably be implemented using some in-memory internal backend, so it would be absolutely independent on passdb schema and would require no modifications on passdb schema.

   the original message says about bot brute-force attacks, but we can be facing REAL brute-force attacks against a specific account .... and i think that some features to help mitigate those could indeed be interesting. And if those features exists, they could surely help on those brute-force attacks coming from dumb bots as well.

   it wont solve the username=password specific case, but could help on real or bot brute-force attacks.

   what do you think on that Timo ?

Have a look at fail2ban, this is exactly what you need.

--

Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email gertrudes@solutti.com.br My SPAMTRAP, do not email it

YoungGuns Kasteleinenkampweg 7b 5222 AX 's-Hertogenbosch T. 073 623 56 40 F. 073 623 56 39 www.youngguns.nl KvK 18076568

On Qua, 21 Jul 2010, Leonardo Rodrigues wrote:

i completly agree that dovecot is not the place for enforcing  

password policies nor checking them.

but, still on the subject, maybe dovecot could have some  

features for helping sysadmins to avoid/mitigate brute-force
attacks. As told, some bots tries username=password, but those
fuckers (the bots) also tries lots of common passwords, 123, 1234,
the username followed by some numbers, and lots of others.

of course, if the provided password is not correct, dovecot  

denies access as it should .... but in those situations, logs can
get pretty filled with login failed messages, specially on servers
with lots of accounts. And, in some cases, after lots of tries, the
bot can found the correct username/password combination.

[snip]

I think none of this is dovecot's function. Let's keep the UNIX
filosophy: one tool does one function, and does that function well.
Dovecot is an execellent mail server. It should not be turned into a
monster Windows-like application that does dozens of
not-really-quite-related things.

What you want can be done with other tools.

-- Eduardo M KALINOWSKI eduardo@kalinowski.com.br

On 07/21/2010 03:06 PM Leonardo Rodrigues wrote:

 i was thinking on something like ...

1. after N tries (lets say 10 for example) of wrong username/password combinations, dovecot could start delaying the answers for wrong authentications coming from that specific IP address or IP/username, thus slowing down the brute-force attacks; 1.1) or even, after some M (lets say 20 for example) wrong username/password combinations, dovecot could ban that IP address (or IP address/username combination to avoid problem with big networks with NAT access) for XX seconds/minutes, also slowing down the brute-force attack tries 1.2) this could probably be implemented using some in-memory internal backend, so it would be absolutely independent on passdb schema and would require no modifications on passdb schema.

Install dovecot 2.0.rc3 and try to 'break in'. You will see how dovecot slows down your 'attack'. When you test it with your botnet ( ;-) ), use doveadm penalty to see current penalties.

Regards, Pascal

The trapper recommends today: deadbeef.1020215@localdomain.org

Pascal Volk wrote:

On 07/21/2010 03:06 PM Leonardo Rodrigues wrote:

...

 i was thinking on something like ...

1. after N tries (lets say 10 for example) of wrong username/password combinations, dovecot could start delaying the answers for wrong authentications coming from that specific IP address or IP/username, thus slowing down the brute-force attacks; 1.1) or even, after some M (lets say 20 for example) wrong username/password combinations, dovecot could ban that IP address (or IP address/username combination to avoid problem with big networks with NAT access) for XX seconds/minutes, also slowing down the brute-force attack tries 1.2) this could probably be implemented using some in-memory internal backend, so it would be absolutely independent on passdb schema and would require no modifications on passdb schema.

Install dovecot 2.0.rc3 and try to 'break in'. You will see how dovecot slows down your 'attack'. When you test it with your botnet ( ;-) ), use doveadm penalty to see current penalties.

I should note that the patterns of attack we are seeing are extremely sophisticated. They are going out of their way to be "stealth" with respect to detection strategies. We do still see the focused brute force attacks where one IP futilely hammers at root (never allowed anyway), and where an IP tries all the various default system and application accounts. However, it seems that attacks are now going to distributed against distributed. That is to say, a large botnet (I recently identified 1235 IPs in one day cooperating in an attack) has a large list of hosts it wants to hit, and they randomize the hits across botnet IPs, across hosts, and across accounts being hit, with time delays between hits for any one host. You see this by looking across multiple servers and seeing the same IP trying different accounts across different servers, or the same account being tried by different IPs across different servers, and the accounts incrementing alphabetically, even though the IP trying them is changing.

I have only been able to tag these manually in a text oriented editor with multiple grep patterns to remove legitimate entries before I compile the list of IPs to be blocked. Then those are run through another script that does NS lookups and checks against already blocked IPs. What is left, I scan with my own eyes and remove things that could possibly be our own users.

Not an easy thing to deal with.

The odds of their getting into any particular server are slim, but that's multiplied by the huge number of servers they are hitting.

After blocking those, I continue to see steady streams of access denied in my auth logs, even weeks later.

These attempts are typically preceded with similarly distributed port scans and will hit whatever ports and protocols are available. I see mostly ssh, but also a significant number of attacks on pop3.

--

Chris Hoogendyk

• O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center

<hoogendyk@bio.umass.edu>

--------------- 

Erdös 4

Check out splunk (or similar) for multiple disparate event log correlations.

-----Original Message----- From: dovecot-bounces+jkrejci=usinternet.com@dovecot.org [mailto:dovecot-bounces+jkrejci=usinternet.com@dovecot.org] On Behalf Of Chris Hoogendyk Sent: Wednesday, July 21, 2010 10:19 AM To: Dovecot Mailing List Subject: Re: [Dovecot] Feature request: usernames and passwords

I should note that the patterns of attack we are seeing are extremely sophisticated. They are going out of their way to be "stealth" with respect to detection strategies. We do still see the focused brute force attacks where one IP futilely hammers at root (never allowed anyway), and where an IP tries all the various default system and application accounts. However, it seems that attacks are now going to distributed against distributed. That is to say, a large botnet (I recently identified 1235 IPs in one day cooperating in an attack) has a large list of hosts it wants to hit, and they randomize the hits across botnet IPs, across hosts, and across accounts being hit, with time delays between hits for any one host. You see this by looking across multiple servers and seeing the same IP trying different accounts across different servers, or the same account being tried by different IPs across different servers, and the accounts incrementing alphabetically, even though the IP trying them is changing.

I have only been able to tag these manually in a text oriented editor with multiple grep patterns to remove legitimate entries before I compile the list of IPs to be blocked. Then those are run through another script that does NS lookups and checks against already blocked IPs. What is left, I scan with my own eyes and remove things that could possibly be our own users.

Not an easy thing to deal with.

The odds of their getting into any particular server are slim, but that's multiplied by the huge number of servers they are hitting.

After blocking those, I continue to see steady streams of access denied in my auth logs, even weeks later.

These attempts are typically preceded with similarly distributed port scans and will hit whatever ports and protocols are available. I see mostly ssh, but also a significant number of attacks on pop3.

--

Chris Hoogendyk

• O__ ---- Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center

<hoogendyk@bio.umass.edu>

--------------- 

Erdös 4