Re: Mail account brute force / harassment
On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot <dovecot@dovecot.org> wrote:
Instead of being evil, just use fail2ban to address this problem :-)
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
fail2ban is a good solution. I don't see any benefits in granting access to pop/imap as well. On the other hand if you to this with smtp, your service is probably abused for sending spam which you could use to train your spam filters :-)
Best regards Gerald
Please do not assume anything other than what is written, it is a hypothetical situation
A. With the fail2ban solution
- you 'solve' that the current ip is not able to access you
- it will continue bothering other servers and admins
- you get the next abuse host to give a try.
B. With 500GB dump
- the owner of the attacking server (probably hacked) will notice it will be forced to take action.
If abuse clouds are smart (most are) they would notice that attacking my servers, will result in the loss of abuse nodes, hence they will not bother me anymore.
If every one would apply strategy B, the abuse problem would get less. Don't you agree??
-----Original Message-----
From: Odhiambo Washington
Sent: donderdag 11 april 2019 12:28
To: Marc Roos
Cc: dovecot
Subject: Re: Mail account brute force / harassment
On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot <dovecot@dovecot.org> wrote:
Say for instance you have some one trying to constantly access an
account
Has any of you made something creative like this:
* configure that account to allow to login with any password
* link that account to something like /dev/zero that generates infinite amount of messages (maybe send an archive of virusses?) * transferring TB's of data to this harassing client.
I think it would be interesting to be able to do such a thing.Instead of being evil, just use fail2ban to address this problem :-)
--
Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", grep ^[^#] :-)
I disagree. If 100 servers "hack" your imap account and fetch 500GB then most likely your server is unreachable. If this is done over many servers then your rack switches become the bottleneck and uninvolved servers are affected too.
Your solution may work if traffic is expensive and limited but we're heading in the other direction: you can rent a server for 50 bucks with 1gbit bandwidth and unmetered traffic e.g. at hetzner.de <http://hetzner.de/>
Maybe you want to look into a solution like weakforced:
https://github.com/PowerDNS/weakforced <https://github.com/PowerDNS/weakforced> Wforce is a project by Dovecot, PowerDNS and Open-Xchange
Best regards Gerald
If I am not mistaken dovecot has already limited concurrent accounts/ips. Furthermore I thought it would be obvious of course to utilize for this only unused resources and don't jeopardize a production environment.
Furthermore it is logical to assume that one abuse host is not dedicated to me. So it probably has 50? other connections for every one of mine. So if it would be common practice to dump abuse to /dev/zero, the abuse host would be the first to 'die'.
-----Original Message----- From: Gerald Galster via dovecot [mailto:dovecot@dovecot.org] Sent: donderdag 11 april 2019 12:57 To: dovecot@dovecot.org Subject: Re: Mail account brute force / harassment
Am 11.04.2019 um 12:43 schrieb Marc Roos via dovecot <dovecot@dovecot.org>:
Please do not assume anything other than what is written, it is a
hypothetical situation
A. With the fail2ban solution
- you 'solve' that the current ip is not able to access you
- it will continue bothering other servers and admins
- you get the next abuse host to give a try.
B. With 500GB dump
- the owner of the attacking server (probably hacked) will notice it will be forced to take action.
If abuse clouds are smart (most are) they would notice that attacking my servers, will result in the loss of abuse nodes, hence they will not bother me anymore.
If every one would apply strategy B, the abuse problem would get less. Don't you agree??
I disagree. If 100 servers "hack" your imap account and fetch 500GB then most likely your server is unreachable. If this is done over many servers then your rack switches become the bottleneck and uninvolved servers are affected too.
Your solution may work if traffic is expensive and limited but we're heading in the other direction: you can rent a server for 50 bucks with 1gbit bandwidth and unmetered traffic e.g. at hetzner.de
Maybe you want to look into a solution like weakforced:
https://github.com/PowerDNS/weakforced Wforce is a project by Dovecot, PowerDNS and Open-Xchange
Best regards Gerald
-----Original Message-----
From: Odhiambo Washington
Sent: donderdag 11 april 2019 12:28
To: Marc Roos
Cc: dovecot
Subject: Re: Mail account brute force / harassment
On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot
<dovecot@dovecot.org> wrote:
Say for instance you have some one trying to constantly access an
account
Has any of you made something creative like this:
* configure that account to allow to login with any password
* link that account to something like /dev/zero that generates
infinite
amount of messages
(maybe send an archive of virusses?)
* transferring TB's of data to this harassing client.
I think it would be interesting to be able to do such a thing.
Instead of being evil, just use fail2ban to address this problem :-)
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)On 11/04/2019 11:43, Marc Roos via dovecot wrote:
It is only a solution if there are subsequent attempts from the same address. I currently have several thousand addresses blocked due to dovecot login failures. My firewall is set to log these so I can see that few repeat, those that do repeat have intervals of >1 week. Blocking these has minimal effect (other than to clog fail12ban and the firewall).
Which is why a dnsbl for dovecot is a good idea. I do not believe the agents behind these login attempts are only targeting me, hence the addresses should be shared via a dnsbl.
Yes indeed, we have already own dnsbl's for smtp and ssh/ftp access. How do you have one setup for dovecot connections?
-----Original Message----- From: James via dovecot [mailto:dovecot@dovecot.org] Sent: donderdag 11 april 2019 13:25 To: dovecot@dovecot.org Subject: Re: Mail account brute force / harassment
On 11/04/2019 11:43, Marc Roos via dovecot wrote:
It is only a solution if there are subsequent attempts from the same address. I currently have several thousand addresses blocked due to dovecot login failures. My firewall is set to log these so I can see that few repeat, those that do repeat have intervals of >1 week. Blocking these has minimal effect (other than to clog fail12ban and the firewall).
Which is why a dnsbl for dovecot is a good idea. I do not believe the agents behind these login attempts are only targeting me, hence the addresses should be shared via a dnsbl.
On 11/04/2019 12:49, Marc Roos via dovecot wrote:
Yes indeed, we have already own dnsbl's for smtp and ssh/ftp access. How do you have one setup for dovecot connections?
Two answers:
I wrote my own very simple implementation but it does not share other people's data. Sharing the key to viability so it is/was a pointless exercise. Without sharing a hacker gets at least one free shot per server per address. With sharing it is closer to one per address and less with honeypots.
I said "dnsbl for dovecot is a good idea", an idea. When this was raised previously we were told it was not needed and it can all be done with tcp wrappers, fail2ban and allow_nets.
https://dovecot.org/list/dovecot/2013-July/091236.html https://dovecot.org/list/dovecot/2014-June/096662.html
On 11.04.2019 13:25, James via dovecot wrote:
Probably there's an existing solution for both problems (subsequent attempts and dnsbl):
It was also discussed recently on this list:
Has already been on my personal todo list for some time, so I have no experience how (good) it actually works.
Best, Anton
On 11/04/2019 14:33, Anton Dollmaier via dovecot wrote:
"The goal of 'wforce' is to detect brute forcing of passwords across many servers"
The problem is not detecting but blocking. Dovecot has no mechanism for using the data; Dovecot needs DNSBL capability.
I tested a small sample of my IMAP hackers using the lists I use for SMTP blocking [1] and enough are in these list to make them worth using. Extra detection is not needed as many of these addresses are already known - maybe even by using weakforced.
James.
On 12/04/2019 08:24, Aki Tuomi via dovecot wrote:
Weakforced uses Lua so you can easily integrate DNSBL support into it.
How does this help Dovecot block? A link to some documentation or example perhaps?
We will not add DNSBL support to dovecot at this time.
Is there a reason why you will not support this RFE?
On 12.4.2019 10.34, James via dovecot wrote:
https://wiki.dovecot.org/Authentication/Policy
You can configure weakforced to return status -1 when DNSBL matches, which causes the user authentication to fail before any other processing happens.
We will not add DNSBL support to dovecot at this time.
Is there a reason why you will not support this RFE?
It's not a priority.
Aki
Hi,
What we do is: use https://github.com/trick77/ipset-blacklist to block IPs (from various existing blacklists) at the iptables level using an ipset.
That way, the known bad IPs never even talk to dovecot, but are dropped immediately. We have the feeling it helps a lot.
MJ
On 4/12/19 10:27 AM, James via dovecot wrote:
On Fri, 12 Apr 2019, mj wrote:
What we do is: use https://github.com/trick77/ipset-blacklist to block IPs (from various existing blacklists) at the iptables level using an ipset.
"www.blocklist.de" is a nifty source. Could you suggest other publically available blacklists?
That way, the known bad IPs never even talk to dovecot, but are dropped immediately. We have the feeling it helps a lot.
Really helps with uber-stupid BFD attacks that pound our plaintext ports even though Dovecot repeatedly responds with
-ERR [AUTH] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.
* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
xx NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.The irony is that even if it blunders onto a usable password, they wouldn't know it.
Joseph Tam <jtam.home@gmail.com>
Hi,
On 4/12/19 11:05 PM, Joseph Tam via dovecot wrote:
"www.blocklist.de" is a nifty source. Could you suggest other publically available blacklists?
The ones we are using are:
"file:///etc/ipset-blacklist/ip-blacklist-custom.list" # optional, for your personal nemeses (no typo, plural)
In this file we have our own manual additions
MJ
That was a thread I started. I got wforce to work. However the "reporting IP" in the logs always shows as 127.0.0.1, so I risk banning myself. Here's the log entry: Apr 12 10:06:12 auth: Debug: policy(ouruser,127.0.0.1,<OWoLzlWGDrh/AAAB>): Policy server request JSON: {"device_id":"","login":"ouruser","protocol":"imap","pwhash":"2a","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
I've tried setting auth_policy_server_url to examples such as:
- auth_policy_server_url = http://localhost:8084/
- auth_policy_server_url = http://0.0.0.0:8084/
- auth_policy_server_url = https://ourdomain.edu:8084/
in the custom config file for wforce and the rip (reporting IP, e.g., Apr 12 10:06:10 auth: Debug: client in: AUTH 1 PLAIN service=imap secured session=OWoLzlWGDrh/AAAB lip=127.0.0.1 rip=127.0.0.1 lport=143 rport=47118 resp=<hidden>) is either 127.0.0.1 or ourdomain.edu.
You are running some kind of proxy in front of it. If you want it to show real client IP, you need to enable forwarding of said data. With dovecot it's done by setting
login_trusted_networks = your-upstream-host-or-net
in backend config file.
For webmails, this requires both login_trusted_networks and also support from the webmail software to forward client IP.
Aki
You are running some kind of proxy in front of it.
No proxy. Just sendmail with users using emacs/Rmail or Webmail/Squirrelmail.
OK I changed it and restarted wforce and dovecot. Still seeing this: Apr 12 14:38:55 auth: Debug: policy(ouruser,127.0.0.1,<6GFTnVmGcMN/AAAB>): Policy server request JSON: {"device_id":"","login":" ouruser","protocol":"imap","pwhash":"43","remote":"127.0.0.1","success":false,"policy_reject":false,"tls":false}
For webmails, this requires both login_trusted_networks and also support from the webmail software to forward client IP.
I did get a reply from the Squirrelmail list: "Well, I've had code sitting around for a while that implements RFC2971 (ID command), so I just committed it. You can use it for this purpose by putting something like this into your config/config_local.php $imap_id_command_args = array('remote-host' => '###REMOTE ADDRESS###');"
Which I also added previously. But that doesn't address emacs/RMail users.
Could there be a setting in sendmail.mc/cf file that I'm missing?
Can you verify following?
doveconf auth_policy_request_attributes
auth_policy_request_attributes = login=%{requested_username} pwhash=%{hashed_password} remote=%{rip} device_id=%{client_id} protocol=%s
On some versions remote is mistakenly %{real_rip} which expands into where the connection came from instead of client IP.
If it's wrong just feel free to copypaste the setting above into dovecot config.
Aki
Aki
On 11 Apr 2019, at 04:43, Marc Roos via dovecot <dovecot@dovecot.org> wrote:
Unlikely. What is very likely is that your ISP shuts you don for network abuse.
Not at all the case.
If every one would apply strategy B, the abuse problem would get less.
No. The abuse problem wold be far worse.
-- I thank my lucky stars I'm not superstitious.
If you not block the request, but allow it, and redirect to a /dev/zero device that generates 500GB of messages. How can I ever be accused of network abuse.
Since your logics is not correct on this, how can I assume anything you write is correct?
-----Original Message----- From: @lbutlr via dovecot [mailto:dovecot@dovecot.org] Sent: donderdag 11 april 2019 19:11 To: Peter via dovecot Subject: Re: Mail account brute force / harassment
On 11 Apr 2019, at 04:43, Marc Roos via dovecot <dovecot@dovecot.org> wrote:
Unlikely. What is very likely is that your ISP shuts you don for network abuse.
Not at all the case.
If every one would apply strategy B, the abuse problem would get less.
No. The abuse problem wold be far worse.
-- I thank my lucky stars I'm not superstitious.
participants (10)
-
＠lbutlr
-
Aki Tuomi
-
Anton Dollmaier
-
Gerald Galster
-
James
-
Joseph Tam
-
Marc Roos
-
mj
-
Odhiambo Washington
-
Robert Kudyba