Re: Mail account brute force / harassment

Odhiambo Washington

11 Apr 2019 11 Apr '19

1:28 p.m.

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 ^[^#] :-)

Attachments:

attachment.html (text/html — 1.3 KB)

Show replies by date

Gerald Galster

11 Apr 11 Apr

1:35 p.m.

New subject: Mail account brute force / harassment

...

Am 11.04.2019 um 12:28 schrieb Odhiambo Washington via dovecot dovecot@dovecot.org:

On Thu, 11 Apr 2019 at 13:24, Marc Roos via dovecot mailto: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 :-)

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

Marc Roos

1:43 p.m.

New subject: Mail account brute force / harassment

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 ^[^#] :-)

Gerald Galster

1:57 p.m.

New subject: 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 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

...

-----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 ^[^#] :-)

Marc Roos

2:15 p.m.

New subject: Mail account brute force / harassment

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??

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 ^[^#] :-)

James

2:25 p.m.

New subject: Mail account brute force / harassment

On 11/04/2019 11:43, Marc Roos via dovecot wrote:

...

A. With the fail2ban solution

you 'solve' that the current ip is not able to access you

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).

...

it will continue bothering other servers and admins

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.

Marc Roos

2:49 p.m.

New subject: Mail account brute force / harassment

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:

...

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

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.

James

4:25 p.m.

New subject: Mail account brute force / harassment

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

Anton Dollmaier

4:33 p.m.

New subject: Mail account brute force / harassment

On 11.04.2019 13:25, James via dovecot wrote:

...

On 11/04/2019 11:43, Marc Roos via dovecot wrote:

...
A. With the fail2ban solution - you 'solve' that the current ip is not able to access you

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).

...
- it will continue bothering other servers and admins

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.

Probably there's an existing solution for both problems (subsequent attempts and dnsbl):

...

https://github.com/PowerDNS/weakforced

It was also discussed recently on this list:

...

https://www.dovecot.org/list/dovecot/2019-March/114921.html

Has already been on my personal todo list for some time, so I have no experience how (good) it actually works.

Best, Anton

James

12 Apr 12 Apr

10:21 a.m.

New subject: Mail account brute force / harassment

On 11/04/2019 14:33, Anton Dollmaier via dovecot wrote:

...

...
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.

Probably there's an existing solution for both problems (subsequent attempts and dnsbl):

...
https://github.com/PowerDNS/weakforced

"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.

exim dnsblist: https://www.exim.org/howto/rbl.html https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_...

Aki Tuomi

10:24 a.m.

New subject: Mail account brute force / harassment

On 12.4.2019 10.21, James via dovecot wrote:

...

On 11/04/2019 14:33, Anton Dollmaier via dovecot wrote:

...
...
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.

Probably there's an existing solution for both problems (subsequent attempts and dnsbl):

...
https://github.com/PowerDNS/weakforced

"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.

exim dnsblist: https://www.exim.org/howto/rbl.html https://www.exim.org/exim-html-current/doc/html/spec_html/ch-access_control_...

Weakforced uses Lua so you can easily integrate DNSBL support into it. We will not add DNSBL support to dovecot at this time.

Aki

James

10:34 a.m.

New subject: Mail account brute force / harassment

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?

Aki Tuomi

10:42 a.m.

New subject: Mail account brute force / harassment

On 12.4.2019 10.34, James via dovecot wrote:

...

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?

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

James

11:27 a.m.

New subject: Mail account brute force / harassment

On 12/04/2019 08:42, Aki Tuomi via dovecot wrote:

...

On 12.4.2019 10.34, James via dovecot wrote:

...
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?

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.

Thank you. I will study this - although I dispute your "easily"!

James.

mj

1:14 p.m.

New subject: Mail account brute force / harassment

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.

On 4/12/19 10:27 AM, James via dovecot wrote:

...

On 12/04/2019 08:42, Aki Tuomi via dovecot wrote:

...
On 12.4.2019 10.34, James via dovecot wrote:

...
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?

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.

Thank you. I will study this - although I dispute your "easily"!

James.

Joseph Tam

13 Apr 13 Apr

12:05 a.m.

New subject: Mail account brute force / harassment

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

mj

14 Apr 14 Apr

5:24 p.m.

New subject: Mail account brute force / harassment

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

...

"https://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1" # Project Honey Pot Directory of Dictionary Attacker IPs
"https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=1.1.1.1"  # TOR Exit Nodes
"https://www.maxmind.com/en/high-risk-ip-sample-list" # MaxMind GeoIP Anonymous Proxies
"http://danger.rulez.sk/projects/bruteforceblocker/blist.php" # BruteForceBlocker IP List
"https://www.spamhaus.org/drop/drop.lasso" # Spamhaus Don't Route Or Peer List (DROP)
"http://cinsscore.com/list/ci-badguys.txt" # C.I. Army Malicious IP List
"https://lists.blocklist.de/lists/all.txt" # blocklist.de attackers
"http://blocklist.greensnow.co/greensnow.txt" # GreenSnow
"https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level1.netset" # Firehol Level 1
"https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/stopforumspam_7d.ipset" # Stopforumspam via Firehol

Robert Kudyba

12 Apr 12 Apr

6:11 p.m.

New subject: Mail account brute force / harassment

...

Probably there's an existing solution for both problems (subsequent attempts and dnsbl):

...
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PowerDNS_weakforced&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=stCCTTs65S9mjT4ITx-MfXyqnP1M0FoOlvIsEA-iwdQ&e=

It was also discussed recently on this list:

...
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dovecot.org_list_dovecot_2019-2DMarch_114921.html&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=F_MZgSGFbhEPpQAsxd5uZPK_fbOBWgG4SIvzIXCWC1U&e=

Has already been on my personal todo list for some time, so I have no experience how (good) it actually works.

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,): 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.

Aki Tuomi

7:49 p.m.

New subject: Mail account brute force / harassment

...

On 12 April 2019 18:11 Robert Kudyba via dovecot dovecot@dovecot.org wrote:

...
Probably there's an existing solution for both problems (subsequent attempts and dnsbl):

...
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PowerDNS_weakforced&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=stCCTTs65S9mjT4ITx-MfXyqnP1M0FoOlvIsEA-iwdQ&e=

It was also discussed recently on this list:

...
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.dovecot.org_list_dovecot_2019-2DMarch_114921.html&d=DwID-g&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=X1Im4Y-eX0uEDwDWiGtbHA7-LMVH6EXlblUpquQsx9Y&s=F_MZgSGFbhEPpQAsxd5uZPK_fbOBWgG4SIvzIXCWC1U&e=

Has already been on my personal todo list for some time, so I have no experience how (good) it actually works.

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,): 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 (http://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

Robert Kudyba

9:45 p.m.

New subject: Mail account brute force / harassment

...

You are running some kind of proxy in front of it.

No proxy. Just sendmail with users using emacs/Rmail or Webmail/Squirrelmail.

...

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.

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?

Aki Tuomi

9:50 p.m.

New subject: Mail account brute force / harassment

...

On 12 April 2019 21:45 Robert Kudyba via dovecot dovecot@dovecot.org wrote:

...
You are running some kind of proxy in front of it.

No proxy. Just sendmail with users using emacs/Rmail or Webmail/Squirrelmail.

...
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.

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 (http://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

Robert Kudyba

10:01 p.m.

New subject: Mail account brute force / harassment

...

...
On 12 April 2019 21:45 Robert Kudyba via dovecot dovecot@dovecot.org wrote:

...
You are running some kind of proxy in front of it.

No proxy. Just sendmail with users using emacs/Rmail or Webmail/Squirrelmail.

...
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.

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 ( https://urldefense.proofpoint.com/v2/url?u=http-3A__sendmail.mc_cf&d=DwICaQ&c=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM&r=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY&m=CsaMqvBelGXz-_ClT0RDzwqz0tH3cTGNItJktQeULLs&s=JnUd5ej3Twniz2q3fiWUrV_qOFlAwvFHquFjfgsoQJ0&e=) 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.

Verified. I believe you told me that on the other thread and I made that change a while back.

Aki Tuomi

10:07 p.m.

New subject: Mail account brute force / harassment

＠lbutlr

11 Apr 11 Apr

8:11 p.m.

New subject: Mail account brute force / harassment

On 11 Apr 2019, at 04:43, Marc Roos via dovecot dovecot@dovecot.org wrote:

...

B. With 500GB dump

the owner of the attacking server (probably hacked) will notice it will be forced to take action.

Unlikely. What is very likely is that your ISP shuts you don for network abuse.

...

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.

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.

Marc Roos

8:20 p.m.

New subject: Mail account brute force / harassment

...

...
B. With 500GB dump

the owner of the attacking server (probably hacked) will notice it

...

...
will be forced to take action.

Unlikely. What is very likely is that your ISP shuts you don for network abuse.

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?

...

...
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.

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.

-----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:

...

B. With 500GB dump

the owner of the attacking server (probably hacked) will notice it will be forced to take action.

Unlikely. What is very likely is that your ISP shuts you don for network abuse.

...

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.

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.

2052

Age (days ago)

2055

Last active (days ago)

List overview

24 comments

10 participants

participants (10)

＠lbutlr
Aki Tuomi
Anton Dollmaier
Gerald Galster
James
Joseph Tam
Marc Roos
mj
Odhiambo Washington
Robert Kudyba