Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

Gerben Wierda
My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:

First a lot of:
2017-01-03 10:09:54.964765+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.044713+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.044835+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.202825+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.275621+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.275763+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.429740+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.504750+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.504856+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.663197+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.743275+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.743976+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.897671+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.971095+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.971197+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.127389+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.207804+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.207922+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.362779+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.436684+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.436791+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.594670+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.672957+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.673078+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.831483+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.906429+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.906548+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1

This was actually DOS-like, 10 per second, my clients had trouble reaching my own mail server. Later it first slowed down to 1 per second (from another IP):

2017-01-03 10:59:00.110590+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:00.110500+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:00.112063+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:00.112134+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:00.388175+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:00.388343+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:00.911768+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:01.198870+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:01.198986+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:01.654948+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:01.891412+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:01.891528+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:03.138730+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:03.410583+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:03.410701+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:03.931302+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:04.189197+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:04.189330+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:04.762571+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:05.759604+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:05.759719+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:08.667499+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:08.928175+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:08.928522+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:16.232049+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:16.473858+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:16.473999+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1

Then after a while a lot of:
2017-01-03 10:59:16.760758+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:17.667032+0100 0x629537   Default     0x0                  14264  smtpd: error: get user record: unable to open user record for user=[hidden email]
2017-01-03 10:59:17.667125+0100 0x629537   Default     0x0                  14264  smtpd: error: verify password: unable to lookup user record for: user=[hidden email]
2017-01-03 10:59:17.667270+0100 0x629537   Default     0x0                  14264  smtpd: error: authentication failed
2017-01-03 10:59:17.667463+0100 0x629537   Default     0x0                  14264  smtpd: warning: unknown[66.150.135.9]: SASL LOGIN authentication failed
2017-01-03 10:59:17.905241+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after AUTH from unknown[66.150.135.9]
2017-01-03 10:59:17.905356+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 auth=0/1 commands=1/2

It does the first part from a multitude of machines.

I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?

So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.

G
Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

Dominic Raferd
On 3 January 2017 at 12:37, Gerben Wierda <[hidden email]> wrote:

> My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:
>
> First a lot of:
> 2017-01-03 10:09:54.964765+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
> ...
>
> This was actually DOS-like, 10 per second, my clients had trouble reaching my own mail server. Later it first slowed down to 1 per second (from another IP):
>
> 2017-01-03 10:59:00.110590+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
> ...
>
> Then after a while a lot of:
> 2017-01-03 10:59:16.760758+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
> ...
>
> It does the first part from a multitude of machines.
>
> I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?
>
> So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.
>

For a smallish server maybe some of the settings below might help you.
More info at http://www.postfix.org/TUNING_README.html and of course
http://www.postfix.org/postconf.5.html. Seems to me that even if these
settings were to affect a legit sender adversely, and assuming the
backup mail server was down, the legit sender should just try again
later, so your clients should never fail to receive legit mails - just
the emails might (in theory) take a bit longer to reach them. Others
may have different/better suggestions.

smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
smtpd_error_sleep_time = 3s
Reply | Threaded
Open this post in threaded view
|

RE: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

angelo
In reply to this post by Gerben Wierda
Hi, are you already leveraging Anvil ? Or at least checked if it can help the situation ?

http://www.postfix.org/TUNING_README.html
http://www.postfix.org/anvil.8.html



-Angelo Fazzina
Operating Systems Programmer / Analyst
University of Connecticut,  UITS, SSG, Server Systems
860-486-9075

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Gerben Wierda
Sent: Tuesday, January 3, 2017 7:37 AM
To: Postfix users <[hidden email]>
Subject: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:

First a lot of:
2017-01-03 10:09:54.964765+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.044713+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.044835+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.202825+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.275621+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.275763+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.429740+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.504750+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.504856+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.663197+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.743275+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.743976+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:55.897671+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:55.971095+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:55.971197+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.127389+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.207804+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.207922+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.362779+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.436684+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.436791+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.594670+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.672957+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.673078+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1
2017-01-03 10:09:56.831483+0100 0x6254a9   Info        0x0                  12992  smtpd: connect from unknown[95.183.220.2]
2017-01-03 10:09:56.906429+0100 0x6254a9   Info        0x0                  12992  smtpd: lost connection after EHLO from unknown[95.183.220.2]
2017-01-03 10:09:56.906548+0100 0x6254a9   Info        0x0                  12992  smtpd: disconnect from unknown[95.183.220.2] ehlo=1 commands=1

This was actually DOS-like, 10 per second, my clients had trouble reaching my own mail server. Later it first slowed down to 1 per second (from another IP):

2017-01-03 10:59:00.110590+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:00.110500+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:00.112063+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:00.112134+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:00.388175+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:00.388343+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:00.911768+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:01.198870+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:01.198986+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:01.654948+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:01.891412+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:01.891528+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:03.138730+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:03.410583+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:03.410701+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:03.931302+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:04.189197+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:04.189330+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:04.762571+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:05.759604+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:05.759719+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:08.667499+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:08.928175+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:08.928522+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1
2017-01-03 10:59:16.232049+0100 0x62947e   Info        0x0                  14260  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:16.473858+0100 0x62947e   Info        0x0                  14260  smtpd: lost connection after EHLO from unknown[66.150.135.9]
2017-01-03 10:59:16.473999+0100 0x62947e   Info        0x0                  14260  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 commands=1

Then after a while a lot of:
2017-01-03 10:59:16.760758+0100 0x629537   Info        0x0                  14264  smtpd: connect from unknown[66.150.135.9]
2017-01-03 10:59:17.667032+0100 0x629537   Default     0x0                  14264  smtpd: error: get user record: unable to open user record for user=[hidden email]
2017-01-03 10:59:17.667125+0100 0x629537   Default     0x0                  14264  smtpd: error: verify password: unable to lookup user record for: user=[hidden email]
2017-01-03 10:59:17.667270+0100 0x629537   Default     0x0                  14264  smtpd: error: authentication failed
2017-01-03 10:59:17.667463+0100 0x629537   Default     0x0                  14264  smtpd: warning: unknown[66.150.135.9]: SASL LOGIN authentication failed
2017-01-03 10:59:17.905241+0100 0x629537   Info        0x0                  14264  smtpd: lost connection after AUTH from unknown[66.150.135.9]
2017-01-03 10:59:17.905356+0100 0x629537   Info        0x0                  14264  smtpd: disconnect from unknown[66.150.135.9] ehlo=1 auth=0/1 commands=1/2

It does the first part from a multitude of machines.

I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?

So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.

G
Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

John Fawcett
In reply to this post by Gerben Wierda
On 01/03/2017 01:37 PM, Gerben Wierda wrote:
> My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:
> ...
> It does the first part from a multitude of machines.
>
> I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?
>
> So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.
>
> G

As well as the other advice given in the thread about tuning postfix
rate limiting, you might want to look into using postscreen with some
blocklists. Those will stop some of the traffic getting through to
smtpd. You can use this is conjunction with fail2ban to then block those
ips at the firewall if they keep connecting. Fail2ban is also useful
against repeated auth errors. Moving auth from port 25 to 587 will also
reduce the risks a bit.

John

Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

lists@lazygranch.com
Aways take advice from me with great caution since I'm new at this, but I use 587 as well and then firewall filter the hell out of 587 and all the email ports other than 25. In the case of this attack, the offender is a "commercial" server based on ip2location.com, so I would block their entire IP space using the Hurricane Electric tools from all but Web and port 25.

Having a VPS just for myself and not being a world traveller, I have blocked most countries from all but Web and 25. I have a script that pulls auth failures from the log and I investigate them as well. If not from any service I expect to use in the future, I block that IP space as well. Current the University of Michigan is my latest dictionary attacker, and now just gets the firewall treatment. 

Obviously if your email server handles a number of users, geographical restrictions aren't the easiest to implement. 

I implemented the anvil tweaks based on a thread about two months ago and they work well.

This dictionary attacking has got to be a fools errand, so their don't seem to be many offenders. I find I can go for two or three days between such attacks.
  Original Message  
From: John Fawcett
Sent: Tuesday, January 3, 2017 6:46 AM
To: [hidden email]
Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

On 01/03/2017 01:37 PM, Gerben Wierda wrote:
> My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:
> ...
> It does the first part from a multitude of machines.
>
> I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP. The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?
>
> So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.
>
> G

As well as the other advice given in the thread about tuning postfix
rate limiting, you might want to look into using postscreen with some
blocklists. Those will stop some of the traffic getting through to
smtpd. You can use this is conjunction with fail2ban to then block those
ips at the firewall if they keep connecting. Fail2ban is also useful
against repeated auth errors. Moving auth from port 25 to 587 will also
reduce the risks a bit.

John

Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

Gerben Wierda
In reply to this post by John Fawcett

On 3 Jan 2017, at 15:45, John Fawcett <[hidden email]> wrote:

On 01/03/2017 01:37 PM, Gerben Wierda wrote:
My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:
...
It does the first part from a multitude of machines.

I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?

So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.

G

As well as the other advice given in the thread about tuning postfix
rate limiting, you might want to look into using postscreen with some
blocklists. Those will stop some of the traffic getting through to
smtpd. 

Thanks all for the replies. 

smtpd_client_connection_rate_limit seems promising. 30 (per 60s) seems a reasonable amount for my setup. I added this, looked at the logging adn it turned out just at that moment I’m under attack at a rate of 10/sec:

2017-01-04 00:31:27.015068+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.015832+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 47 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.016353+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.129622+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.130658+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 48 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.132375+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.241234+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.241809+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 49 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.242435+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.344797+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.345426+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 50 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.345952+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.450440+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.451092+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 51 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.451651+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.555655+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.556521+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 52 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.557037+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.671469+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.672190+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 53 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.672735+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.783150+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.783718+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 54 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.784269+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.884856+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.885740+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 55 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.886326+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.999361+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.999895+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 56 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:28.000426+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
etc.

It was so quick and no login attempt that it was some sort of DoS?

You can use this is conjunction with fail2ban to then block those
ips at the firewall if they keep connecting. Fail2ban is also useful
against repeated auth errors.

fail2ban is not an option on macOS Sierra with Server 5.2.2 unless I compile my own postfix. Logging on macOS is quite different than other *ixes these days and fail2ban works on scanning logs and influencing the firewall. The firewall on macOS is also different. 

If I do a firewall solution, I’ll do it on the firewall/router where iptables is available. This has the added advantage that the server is not bothered at all by the attack.

Moving auth from port 25 to 587 will also reduce the risks a bit.

Yes, maybe it is time to do that. My clients already use 587, however in the past sometimes if they were on some public WiFi, only 25 was passed and they had to revert to 25 to be able to send mail out. I even at one time had a hotspot that intercepted all port 25 rerouted to its own SMTP which gave the fun effect of me trying to connect to my own postfix and being greeted by a Sendmail welcome message… But all that is years ago.

How do I make sure clients can only authenticate on 587 and not on 25? My master.cf now has

smtp   inet n - n - 1 postscreen
smtpd   pass - - n - - smtpd
  -o receive_override_options=no_address_mappings
dnsblog   unix - - n - 0 dnsblog
tlsproxy  unix - - n - 0 tlsproxy
submission inet n - n - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o receive_override_options=no_address_mappings
smtp   unix - - n - - smtp

So, 587 enforces encryption. I could remove tls support from port 25 (to prevent people from trying to guess usernames/w on port 25) and trust 587 for that, and then very strongly limit 587 somehow (low rate). What I was wondering about was what smtpd means in the first column of master.cf. smtp means listening on port 25, "smtpd pass" is internal handover in postfix?

Anyway, what do I do:

smtp   inet n - n - 1 postscreen
  -o smtpd_tls_security_level=none
or

smtpd   pass - - n - - smtpd
  -o receive_override_options=no_address_mappings
  -o smtpd_tls_security_level=none


G


John


Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

lists@lazygranch.com
‎http://bgp.he.net/AS16276#_prefixes
I'd switch to 587 and block everything OVH. Actually I do just that since OVH is on my Web Access blocking list, which I also use to block all mail ports other than 25.

OVH VPS are often used by hackers. I think they are as low as $3 a month.

The BGP tool often has CIDRs that overlap. Example:
Pick 20.

You have to make a judgment call on who is a bot and who has eyeballs. Your port 25 hackers want to spam. Maybe it is just me, but I get attacks on pop3 and imap. That is far more alarming. 

I've yet to get anyone hacking email from an ISP. When that day comes, I guess I will set up faul2ban.

From: Gerben Wierda
Sent: Tuesday, January 3, 2017 3:57 PM
To: Postfix users
Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?


On 3 Jan 2017, at 15:45, John Fawcett <[hidden email]> wrote:

On 01/03/2017 01:37 PM, Gerben Wierda wrote:
My postfix MTA has been under a lot of DOS-like attention. Such as a botnet sending many EHLO-requests, then password attempts:
...
It does the first part from a multitude of machines.

I want to stop this by setting a rate limiting rule in my firewall. I was wondering what rate to set if I want to limit access by the same IP.  The first pattern, I could stop by rate-limiting to maximally 3 per second or 180 per minute. That is already pretty high. What MTA is going to send me 180 per minute and still be legit?

So, because I do not want to lose valid stuff (though there is a backup mail server), I was wondering what a good rate limiting is to prevent these kinds of attacks.

G

As well as the other advice given in the thread about tuning postfix
rate limiting, you might want to look into using postscreen with some
blocklists. Those will stop some of the traffic getting through to
smtpd. 

Thanks all for the replies. 

smtpd_client_connection_rate_limit seems promising. 30 (per 60s) seems a reasonable amount for my setup. I added this, looked at the logging adn it turned out just at that moment I’m under attack at a rate of 10/sec:

2017-01-04 00:31:27.015068+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.015832+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 47 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.016353+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.129622+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.130658+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 48 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.132375+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.241234+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.241809+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 49 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.242435+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.344797+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.345426+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 50 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.345952+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.450440+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.451092+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 51 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.451651+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.555655+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.556521+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 52 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.557037+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.671469+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.672190+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 53 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.672735+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.783150+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.783718+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 54 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.784269+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.884856+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.885740+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 55 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:27.886326+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
2017-01-04 00:31:27.999361+0100 0x66aa12   Info        0x0                  32002  smtpd: connect from 67.ip-167-114-226.eu[167.114.226.67]
2017-01-04 00:31:27.999895+0100 0x66aa12   Default     0x0                  32002  smtpd: warning: Connection rate limit exceeded: 56 from 67.ip-167-114-226.eu[167.114.226.67] for service smtpd
2017-01-04 00:31:28.000426+0100 0x66aa12   Info        0x0                  32002  smtpd: disconnect from 67.ip-167-114-226.eu[167.114.226.67] ehlo=1 commands=1
etc.

It was so quick and no login attempt that it was some sort of DoS?

You can use this is conjunction with fail2ban to then block those
ips at the firewall if they keep connecting. Fail2ban is also useful
against repeated auth errors.

fail2ban is not an option on macOS Sierra with Server 5.2.2 unless I compile my own postfix. Logging on macOS is quite different than other *ixes these days and fail2ban works on scanning logs and influencing the firewall. The firewall on macOS is also different. 

If I do a firewall solution, I’ll do it on the firewall/router where iptables is available. This has the added advantage that the server is not bothered at all by the attack.

Moving auth from port 25 to 587 will also reduce the risks a bit.

Yes, maybe it is time to do that. My clients already use 587, however in the past sometimes if they were on some public WiFi, only 25 was passed and they had to revert to 25 to be able to send mail out. I even at one time had a hotspot that intercepted all port 25 rerouted to its own SMTP which gave the fun effect of me trying to connect to my own postfix and being greeted by a Sendmail welcome message… But all that is years ago.

How do I make sure clients can only authenticate on 587 and not on 25? My master.cf now has

smtp   inet n - n - 1 postscreen
smtpd   pass - - n - - smtpd
  -o receive_override_options=no_address_mappings
dnsblog   unix - - n - 0 dnsblog
tlsproxy  unix - - n - 0 tlsproxy
submission inet n - n - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o receive_override_options=no_address_mappings
smtp   unix - - n - - smtp

So, 587 enforces encryption. I could remove tls support from port 25 (to prevent people from trying to guess usernames/w on port 25) and trust 587 for that, and then very strongly limit 587 somehow (low rate). What I was wondering about was what smtpd means in the first column of master.cf. smtp means listening on port 25, "smtpd pass" is internal handover in postfix?

Anyway, what do I do:

smtp   inet n - n - 1 postscreen
  -o smtpd_tls_security_level=none
or

smtpd   pass - - n - - smtpd
  -o receive_override_options=no_address_mappings
  -o smtpd_tls_security_level=none


G


John



Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

Dominic Raferd
On 4 January 2017 at 02:16, <
[hidden email]> wrote:
>
> ‎http://bgp.he.net/AS16276#_prefixes
> I'd switch to 587 and block everything OVH. Actually I do just that since OVH is on my Web Access blocking list, which I also use to block all mail ports other than 25.
>
> OVH VPS are often used by hackers. I think they are as low as $3 a month.


This is rash; we use OVH and we are not spammers - we need a static ip
(as it is not offered by our ISP) and they provide one at a good
price. You risk blocking genuine emails - this one included (except
you may receive it via the list mailserver).
Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

lists@lazygranch.com
Reread. I don't not block port 25.

I assure you, OVH has been used for C&C by hackers. Angler comes to mind. 

  Original Message  
From: Dominic Raferd
Sent: Tuesday, January 3, 2017 11:42 PM
To: [hidden email]; [hidden email]
Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

On 4 January 2017 at 02:16, <
[hidden email]> wrote:
>
> ‎http://bgp.he.net/AS16276#_prefixes
> I'd switch to 587 and block everything OVH. Actually I do just that since OVH is on my Web Access blocking list, which I also use to block all mail ports other than 25.
>
> OVH VPS are often used by hackers. I think they are as low as $3 a month.


This is rash; we use OVH and we are not spammers - we need a static ip
(as it is not offered by our ISP) and they provide one at a good
price. You risk blocking genuine emails - this one included (except
you may receive it via the list mailserver).
Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

John Fawcett
In reply to this post by Gerben Wierda
On 01/04/2017 12:56 AM, Gerben Wierda wrote:

>
>> On 3 Jan 2017, at 15:45, John Fawcett <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> On 01/03/2017 01:37 PM, Gerben Wierda wrote:
>>> My postfix MTA has been under a lot of DOS-like attention. Such as a
>>> botnet sending many EHLO-requests, then password attempts:
>>> ...
>>> It does the first part from a multitude of machines.
>>>
>>> I want to stop this by setting a rate limiting rule in my firewall.
>>> I was wondering what rate to set if I want to limit access by the
>>> same IP.  The first pattern, I could stop by rate-limiting to
>>> maximally 3 per second or 180 per minute. That is already pretty
>>> high. What MTA is going to send me 180 per minute and still be legit?
>>>
>>> So, because I do not want to lose valid stuff (though there is a
>>> backup mail server), I was wondering what a good rate limiting is to
>>> prevent these kinds of attacks.
>>>
>>> G
>>
>> As well as the other advice given in the thread about tuning postfix
>> rate limiting, you might want to look into using postscreen with some
>> blocklists. Those will stop some of the traffic getting through to
>> smtpd.
>
> Thanks all for the replies.
>
> smtpd_client_connection_rate_limit seems promising. 30 (per 60s) seems
> a reasonable amount for my setup. I added this, looked at the logging
> adn it turned out just at that moment I’m under attack at a rate of
> 10/sec:
>
> 2017-01-04 00:31:27.015068+0100 0x66aa12   Info        0x0          
>       32002  smtpd: connect from 67.ip-167-114-226.eu
> <http://67.ip-167-114-226.eu>[167.114.226.67]
> 2017-01-04 00:31:27.015832+0100 0x66aa12   Default     0x0          
>       32002  smtpd: warning: Connection rate limit exceeded: 47 from
> 67.ip-167-114-226.eu <http://67.ip-167-114-226.eu>[167.114.226.67] for
> service smtpd
> ...
> 2017-01-04 00:31:27.999895+0100 0x66aa12   Default     0x0          
>       32002  smtpd: warning: Connection rate limit exceeded: 56 from
> 67.ip-167-114-226.eu <http://67.ip-167-114-226.eu>[167.114.226.67] for
> service smtpd
> 2017-01-04 00:31:28.000426+0100 0x66aa12   Info        0x0          
>       32002  smtpd: disconnect from 67.ip-167-114-226.eu
> <http://67.ip-167-114-226.eu>[167.114.226.67] ehlo=1 commands=1
> etc.
>
> It was so quick and no login attempt that it was some sort of DoS?

this ip is listed in zen.spamhaus.org, so with postscreen configured
with some appropriate lists, this traffic would not get to smtpd. You'd
still see it on your server, but postscreen could liquidate it quickly
without exhausting smtpd processes. Of course it won't stop traffic from
non listed ips so you will need rate limiting too. Poscreen also has
rate limitingj which defaults to the smtpd values.

I don't know what the point of these attacks is (ones that make multiple
connections and never attempt to authenticate or send email). When I
first saw them in 2013 I thought it was probably some run-away script,
but I guess that they are frequent enough that it is some kind of
exploit that works only via exhausting resources on the server. The
chances of it exploiting a postfix server would be pretty slim so maybe
the real target is some other mail server software. But that's just pure
speculation.

Here's an example postscreen rbl configuration, you would need to tune
the weights and lists to your own needs. In my case I accept zen as a
definitive source or a combination of any two other sources, with swl as
a whitelist.
postscreen_dnsbl_sites = zen.spamhaus.org*3
        bl.spamcop.net*1
        b.barracudacentral.org*2
        ix.dnsbl.manitu.net*2
        swl.spamhaus.org*-11
        mail.bl.blocklist.de*2
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_action = enforce

Before using any specific list investigate its policy and decide what
weight to give it.

>
>> You can use this is conjunction with fail2ban to then block those
>> ips at the firewall if they keep connecting. Fail2ban is also useful
>> against repeated auth errors.
>
> fail2ban is not an option on macOS Sierra with Server 5.2.2 unless I
> compile my own postfix. Logging on macOS is quite different than other
> *ixes these days and fail2ban works on scanning logs and influencing
> the firewall. The firewall on macOS is also different.
>

If the problem persists and is causing disservice despite other measures
you might need to look into home grown solutions that grep the logs for
the ips and adds them to an access file (for example:
postscreen_access_list)

> If I do a firewall solution, I’ll do it on the firewall/router where
> iptables is available. This has the added advantage that the server is
> not bothered at all by the attack.
>
>> Moving auth from port 25 to 587 will also reduce the risks a bit.
>
> Yes, maybe it is time to do that. My clients already use 587, however
> in the past sometimes if they were on some public WiFi, only 25 was
> passed and they had to revert to 25 to be able to send mail out. I
> even at one time had a hotspot that intercepted all port 25 rerouted
> to its own SMTP which gave the fun effect of me trying to connect to
> my own postfix and being greeted by a Sendmail welcome message… But
> all that is years ago.
>

Yes, today it is easier to find 587 open and 25 closed.

> How do I make sure clients can only authenticate on 587 and not on 25?
> My master.cf now has
>
> smtp  inetn-n-1postscreen
> smtpd  pass--n--smtpd
>   -o receive_override_options=no_address_mappings
> dnsblog   unix--n-0dnsblog
> tlsproxy  unix--n-0tlsproxy
> submission inet n-n--smtpd
>   -o smtpd_tls_security_level=encrypt
>   -o receive_override_options=no_address_mappings
> smtp  unix--n--smtp
>
> So, 587 enforces encryption. I could remove tls support from port 25
> (to prevent people from trying to guess usernames/w on port 25) and
> trust 587 for that, and then very strongly limit 587 somehow (low
> rate). What I was wondering about was what smtpd means in the first
> column of master.cf. smtp means listening on port 25, "smtpd pass" is
> internal handover in postfix?

the meanings of the columns can be found here
http://www.postfix.org/master.5.html. The first column is the service
name. For inet services (see second column) this is the port or
host:port. So smtp means listening on port 25. The smtpd pass entry is
the smtpd daemon that listens on a unix socket for receiving the file
descriptor of the connection (from postscreen).

>
> Anyway, what do I do:
>
> smtp  inetn-n-1postscreen
>   -o smtpd_tls_security_level=none
> or
>
> smtpd  pass--n--smtpd
>   -o receive_override_options=no_address_mappings
>   -o smtpd_tls_security_level=none
>
>
> G
>
I would not recommend you to remove encryption from port 25. For a
public email server you should leave opportunistic encryption on port 25
so that you offer encryption to other MTAs that want to use it.

What I think you meant was to remove AUTH from port 25. In that case you
can do it by:

1. adding -o smtpd_sasl_auth_enable=no to the smtpd pass service, or

2. putting smtpd_sasl_auth_enable = no in main.cf (or removing the
setting entirely since this is the default) AND adding -o
smtpd_sasl_auth_enable=yes to the submission service in master.cf

Another parameter which is sometimes recommended for submission service
is smtpd_tls_auth_only = yes, but you can omit this so long as you have
-o smtpd_tls_security_level=encrypt in submission too.
>>
>> John
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

Dominic Raferd
In reply to this post by lists@lazygranch.com
On 4 January 2017 at 08:53,  <[hidden email]> wrote:

> Reread. I don't not block port 25.
>
> I assure you, OVH has been used for C&C by hackers. Angler comes to mind.
>
>   Original Message
> From: Dominic Raferd
> Sent: Tuesday, January 3, 2017 11:42 PM
> To: [hidden email]; [hidden email]
> Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?
>
> On 4 January 2017 at 02:16, <
> [hidden email]> wrote:
>>
>> ‎http://bgp.he.net/AS16276#_prefixes
>> I'd switch to 587 and block everything OVH. Actually I do just that since OVH is on my Web Access blocking list, which I also use to block all mail ports other than 25.
>>
>> OVH VPS are often used by hackers. I think they are as low as $3 a month.
>
>
> This is rash; we use OVH and we are not spammers - we need a static ip
> (as it is not offered by our ISP) and they provide one at a good
> price. You risk blocking genuine emails - this one included (except
> you may receive it via the list mailserver).

It's the false positive risk. 'Some [vps provider X] servers have been
used by hackers' does not mean 'all connections from [vps provider X]
servers are attempted hacks'. Of course you are entitled to your own
decision.
Reply | Threaded
Open this post in threaded view
|

Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

lists@lazygranch.com
But the point is OVH servers have no need to access submission, pop3, or imap. I have reduced the attack surface.

I can receive email from OVH servers since I provide no filtering on port 25 other than a few RBLs.

I don't condone filtering port 25. Leave that to the RBLs. But don't get in the RBLs sights by hanging out in a bad neighborhood. 

This list is supposed to support postfix and this conversation has strayed off that topic, granted partially my fault. ‎My apologies.

  Original Message  
From: Dominic Raferd
Sent: Wednesday, January 4, 2017 1:21 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?

On 4 January 2017 at 08:53, <[hidden email]> wrote:

> Reread. I don't not block port 25.
>
> I assure you, OVH has been used for C&C by hackers. Angler comes to mind.
>
> Original Message
> From: Dominic Raferd
> Sent: Tuesday, January 3, 2017 11:42 PM
> To: [hidden email]; [hidden email]
> Subject: Re: Rate-limiting access to postfix on the firewall, what are decent numbers (depending on overall traffic)?
>
> On 4 January 2017 at 02:16, <
> [hidden email]> wrote:
>>
>> ‎http://bgp.he.net/AS16276#_prefixes
>> I'd switch to 587 and block everything OVH. Actually I do just that since OVH is on my Web Access blocking list, which I also use to block all mail ports other than 25.
>>
>> OVH VPS are often used by hackers. I think they are as low as $3 a month.
>
>
> This is rash; we use OVH and we are not spammers - we need a static ip
> (as it is not offered by our ISP) and they provide one at a good
> price. You risk blocking genuine emails - this one included (except
> you may receive it via the list mailserver).

It's the false positive risk. 'Some [vps provider X] servers have been
used by hackers' does not mean 'all connections from [vps provider X]
servers are attempted hacks'. Of course you are entitled to your own
decision.