Re: Dictionary attacks
Matus UHLAR - fantomas writes: > I'm afraid it won't even help much - seems that dictionary attacks work much > slower. Not all of them are slow: Nov 5 06:19:35 mail postfix/smtpd[28906]: warning: AUTH command rate limit exceeded: 4 from unknown[106.58.210.27] for service smtp Nov 5 06:19:36 mail postfix/smtpd[29057]: warning: AUTH command rate limit exceeded: 5 from unknown[106.58.210.27] for service smtp Nov 5 06:24:50 mail postfix/smtpd[29584]: warning: AUTH command rate limit exceeded: 4 from unknown[45.82.153.76] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29931]: warning: AUTH command rate limit exceeded: 4 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29932]: warning: AUTH command rate limit exceeded: 5 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29933]: warning: AUTH command rate limit exceeded: 6 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29929]: warning: AUTH command rate limit exceeded: 7 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29930]: warning: AUTH command rate limit exceeded: 8 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29934]: warning: AUTH command rate limit exceeded: 9 from unknown[141.98.80.102] for service smtps Nov 5 06:31:34 mail postfix/smtpd[29935]: warning: AUTH command rate limit exceeded: 10 from unknown[141.98.80.102] for service smtps Nov 5 06:31:38 mail postfix/smtpd[29933]: warning: AUTH command rate limit exceeded: 11 from unknown[141.98.80.102] for service smtps Nov 5 06:31:38 mail postfix/smtpd[29932]: warning: AUTH command rate limit exceeded: 12 from unknown[141.98.80.102] for service smtps Nov 5 06:31:39 mail postfix/smtpd[29931]: warning: AUTH command rate limit exceeded: 13 from unknown[141.98.80.102] for service smtps Best regards, Olivier --
Re: Dictionary attacks
On 2019-11-04 03:32, Bernardo Reino wrote:
> You can create a custom action like:
> $ cat /etc/fail2ban/action.d/local_action.conf
> [Definition]
> actionban = /usr/local/sbin/fail2ban_action.sh add
> actionunban = /usr/local/sbin/fail2ban_action.sh delete
> actioncheck =
> actionstart =
> actionstop =
>
> [Init]
> $
>
> (exactly as is, the "" will then be replaced by fail2ban with the IP
> to be blocked/unblocked).
>
> Then in /usr/local/sbin/fail2ban_action.sh you write whatever you need to
> add or delete an IP from the filter.
>
> In my case it is:
>
> $ cat /usr/local/sbin/fail2ban_action.sh
> #!/bin/sh
>
> # nftables, set = fail2ban
> nft $1 element inet filter fail2ban { $2 } 2>&1
>
> exit 0
> $
>
> If the firewall were remote instead of local, I would just change the
> nft invocation to "ssh firewall nft ..."
>
> Once set, you only need to adapt your /etc/fail2ban/jail.local to use
>
> --
> banaction = local_action
> --
> (or whatever name you choose for the action .conf file)
>
> and of course, if not done already, enable the [sasl] module, like:
>
> --
> [sasl]
> enabled = true
> port = smtp,smtps,submission
> filter= postfix-sasl
> logpath = /var/log/mail.log
> --
>
> Hope that helps!
> Good luck.
>
Thanks for the mini-howto, Bernardo! I'll give it another try.
--
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
Re: Dictionary attacks
John Schmerold: What is the best way to protect against dictionary attacks in Postfix? Wietse Venema: Reportedly, fail2ban (no first-hand experience, because I have no SASL clients). On 03 Nov 2019, at 06:06, Wietse Venema wrote: Also, Postfix can rate-limit auth commands, on the assumption that good users don't make lots of repeated login attempts. Wietse htp://www.postfix.org/postconf.5.html#smtpd_client_auth_rate_limit smtpd_client_auth_rate_limit (default: 0) The maximal number of AUTH commands that any client is allowed to send to this service per time unit, regardless of whether or not Postfix actually accepts those commands. The time unit is specified with the anvil_rate_time_unit configuration parameter. On 03.11.19 06:39, @lbutlr wrote: That defaults to 60s so setting this to 3 would rate limit to three attempts per minute. That’s good to know. That might be useful, though I am not sure I am seeing very fast auth attempts. unfortunately, I do, multiple auth attempts from the same host to the same user, quick estimate says even 7 per minute. Apparently some clients don't keep smtp connections open in the background, so we must be very carefull here. Still, it certainly can’t hurt. I'm afraid it won't even help much - seems that dictionary attacks work much slower. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself.
Re: Dictionary attacks
On Sun, 3 Nov 2019, Phil Stracchino wrote:
On 2019-11-03 14:21, Bernardo Reino wrote:
On Sun, 3 Nov 2019, Phil Stracchino wrote:
I've been thinking about setting up exactly such a thing myself. Trying
to figure out how to make fail2ban talk to a Shorewall firewall on a
different box is just too much of a pain for such a fundamentally simple
task. It's like trying to set up a CNC mill when all you actually want
to do is file 2mm off a strike plate.
If you can do it locally, you can do it remotely (via ssh), like:
ssh remote-box whatever_local_shorewall_command
I assumed that was the approach to use, but I found fail2ban's
configuration and documentation opaque and confusing, and couldn't find
a good how-to that explained how to set it up. It was enough of a
headache that I decided my time was probably better spent building
something simple and lightweight purpose-built to do exactly what I want
it to than in trying to figure out the right subset of many complex
configuration options for a tool designed to do a whole lot of things I
don't actually need it to do.
You can create a custom action like:
$ cat /etc/fail2ban/action.d/local_action.conf
[Definition]
actionban = /usr/local/sbin/fail2ban_action.sh add
actionunban = /usr/local/sbin/fail2ban_action.sh delete
actioncheck =
actionstart =
actionstop =
[Init]
$
(exactly as is, the "" will then be replaced by fail2ban with the IP
to be blocked/unblocked).
Then in /usr/local/sbin/fail2ban_action.sh you write whatever you need to
add or delete an IP from the filter.
In my case it is:
$ cat /usr/local/sbin/fail2ban_action.sh
#!/bin/sh
# nftables, set = fail2ban
nft $1 element inet filter fail2ban { $2 } 2>&1
exit 0
$
If the firewall were remote instead of local, I would just change the
nft invocation to "ssh firewall nft ..."
Once set, you only need to adapt your /etc/fail2ban/jail.local to use
--
banaction = local_action
--
(or whatever name you choose for the action .conf file)
and of course, if not done already, enable the [sasl] module, like:
--
[sasl]
enabled = true
port = smtp,smtps,submission
filter= postfix-sasl
logpath = /var/log/mail.log
--
Hope that helps!
Good luck.
Re: Dictionary attacks
On 03 Nov 2019, at 11:03, lists wrote: > https://www.sshguard.net/ > This is a simpler alternative to fail2ban. It has hooks for postfix and > dovecot. Yep, that’s what I use. It doesn’t have all the options of Fail2Ban, but that’s fine, it does what I need most. (I have used fail2ban also) > The only disadvantage is SSHGuard isn't in my repo. You have to build it. > > That said, I just use it for ssh. I use Anvil settings in postfix to slow > down the occasional skid. Less is more. The desired email gets through. I > don't see much in the way of dictionary attacks on my postfix. Lots of failed logins get banned. That’s fine with me. -- Well there are certain sections of New York, Major, that I wouldn't advise you to try to invade
Re: Dictionary attacks
On 2019-11-03 14:21, Bernardo Reino wrote: > On Sun, 3 Nov 2019, Phil Stracchino wrote: >> I've been thinking about setting up exactly such a thing myself. Trying >> to figure out how to make fail2ban talk to a Shorewall firewall on a >> different box is just too much of a pain for such a fundamentally simple >> task. It's like trying to set up a CNC mill when all you actually want >> to do is file 2mm off a strike plate. > > If you can do it locally, you can do it remotely (via ssh), like: > > ssh remote-box whatever_local_shorewall_command I assumed that was the approach to use, but I found fail2ban's configuration and documentation opaque and confusing, and couldn't find a good how-to that explained how to set it up. It was enough of a headache that I decided my time was probably better spent building something simple and lightweight purpose-built to do exactly what I want it to than in trying to figure out the right subset of many complex configuration options for a tool designed to do a whole lot of things I don't actually need it to do. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Dictionary attacks
On Sun, 3 Nov 2019, John Schmerold wrote:
On 11/2/2019 9:42 PM, Wietse Venema wrote:
John Schmerold:
What is the best way to protect against dictionary attacks in Postfix?
Reportedly, fail2ban (no first-hand experience, because I have no
SASL clients).
Wietse
I am using Postfix as a filter in front of O365/cpanel/Google apps, we are
seeing a few dictionary attacks, I will experiment with fail2ban.
One site (Mergy.org), recommends adding this to
/etc/fail2ban/filters.d/postfix:
^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4.1.1 .*
Recipient address rejected: unverified address: unknown user:.*$
We'll see how it goes.
fail2ban includes (at least in debian buster) a suitable rule in
postfix-sasl.conf, viz.:
failregex = ^%(__prefix_line)swarning: [-._\w]+\[\]: SASL
((?i)LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(:[
A-Za-z0-9+/:]
*={0,2})?\s*$
(all in one line).
It works fine to block random bots trying to authenticate as a user
(whether the user exists or not).
Re: Dictionary attacks
On Sun, 3 Nov 2019, Phil Stracchino wrote: On 2019-11-03 05:24, Allen Coates wrote: On 03/11/2019 02:42, Wietse Venema wrote: John Schmerold: What is the best way to protect against dictionary attacks in Postfix? Reportedly, fail2ban (no first-hand experience, because I have no SASL clients). Wietse I run a home-brewed fail2ban look-alike; I find it almost as useful as postscreen. I've been thinking about setting up exactly such a thing myself. Trying to figure out how to make fail2ban talk to a Shorewall firewall on a different box is just too much of a pain for such a fundamentally simple task. It's like trying to set up a CNC mill when all you actually want to do is file 2mm off a strike plate. If you can do it locally, you can do it remotely (via ssh), like: ssh remote-box whatever_local_shorewall_command with fail2ban it's very easy to add customized actions for block/unblock.
Re: Dictionary attacks
> On Nov 3, 2019, at 12:04 PM, Phil Stracchino wrote: > > On 2019-11-03 05:24, Allen Coates wrote: >> >> >> On 03/11/2019 02:42, Wietse Venema wrote: >>> John Schmerold: >>>> What is the best way to protect against dictionary attacks in Postfix? >>> >>> Reportedly, fail2ban (no first-hand experience, because I have no >>> SASL clients). >>> >>> Wietse >>> >> >> I run a home-brewed fail2ban look-alike; I find it almost as useful as >> postscreen. > > I've been thinking about setting up exactly such a thing myself. Trying > to figure out how to make fail2ban talk to a Shorewall firewall on a > different box is just too much of a pain for such a fundamentally simple > task. It's like trying to set up a CNC mill when all you actually want > to do is file 2mm off a strike plate. Yes. And recently there was a change that broke old rules (this was for pf, not sure about other firewalls), and it was annoying. I also find the memory use kind of ludicrous for small/VPS hosts - 150MB for a table of banned IPs? Also it was more than happy to start with a good exit code when it failed to manipulate the firewall, which kind of scared the bejesus out of me and sent me investigating a pile of servers to see if that was happening elsewhere. I wish there were more alternatives out there, although the maintenance burden of dealing with arbitrary logfile changes is probably a pain. It’s crazy how the open source world has gone from railing against the Microsoft monoculture issue to creating their own (unintentionally but still…). Charles > > > -- > Phil Stracchino > Babylon Communications > ph...@caerllewys.net > p...@co.ordinate.org > Landline: +1.603.293.8485 > Mobile: +1.603.998.6958
Re: Dictionary attacks
https://www.sshguard.net/ This is a simpler alternative to fail2ban. It has hooks for postfix and dovecot. The only disadvantage is SSHGuard isn't in my repo. You have to build it. That said, I just use it for ssh. I use Anvil settings in postfix to slow down the occasional skid. Less is more. The desired email gets through. I don't see much in the way of dictionary attacks on my postfix. Original Message From: ph...@caerllewys.net Sent: November 3, 2019 9:04 AM To: postfix-users@postfix.org Subject: Re: Dictionary attacks On 2019-11-03 05:24, Allen Coates wrote: > > > On 03/11/2019 02:42, Wietse Venema wrote: >> John Schmerold: >>> What is the best way to protect against dictionary attacks in Postfix? >> >> Reportedly, fail2ban (no first-hand experience, because I have no >> SASL clients). >> >> Wietse >> > > I run a home-brewed fail2ban look-alike; I find it almost as useful as > postscreen. I've been thinking about setting up exactly such a thing myself. Trying to figure out how to make fail2ban talk to a Shorewall firewall on a different box is just too much of a pain for such a fundamentally simple task. It's like trying to set up a CNC mill when all you actually want to do is file 2mm off a strike plate. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Dictionary attacks
On 2019-11-03 05:24, Allen Coates wrote: > > > On 03/11/2019 02:42, Wietse Venema wrote: >> John Schmerold: >>> What is the best way to protect against dictionary attacks in Postfix? >> >> Reportedly, fail2ban (no first-hand experience, because I have no >> SASL clients). >> >> Wietse >> > > I run a home-brewed fail2ban look-alike; I find it almost as useful as > postscreen. I've been thinking about setting up exactly such a thing myself. Trying to figure out how to make fail2ban talk to a Shorewall firewall on a different box is just too much of a pain for such a fundamentally simple task. It's like trying to set up a CNC mill when all you actually want to do is file 2mm off a strike plate. -- Phil Stracchino Babylon Communications ph...@caerllewys.net p...@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958
Re: Dictionary attacks
On 11/2/2019 9:42 PM, Wietse Venema wrote: John Schmerold: What is the best way to protect against dictionary attacks in Postfix? Reportedly, fail2ban (no first-hand experience, because I have no SASL clients). Wietse I am using Postfix as a filter in front of O365/cpanel/Google apps, we are seeing a few dictionary attacks, I will experiment with fail2ban. One site (Mergy.org), recommends adding this to /etc/fail2ban/filters.d/postfix: ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4.1.1 .* Recipient address rejected: unverified address: unknown user:.*$ We'll see how it goes.
Re: Dictionary attacks
On 03 Nov 2019, at 06:06, Wietse Venema wrote: > Wietse Venema: >> John Schmerold: >>> What is the best way to protect against dictionary attacks in Postfix? >> >> Reportedly, fail2ban (no first-hand experience, because I have no >> SASL clients). > > Also, Postfix can rate-limit auth commands, on the assumption that > good users don't make lots of repeated login attempts. > > Wietse > > htp://www.postfix.org/postconf.5.html#smtpd_client_auth_rate_limit > > smtpd_client_auth_rate_limit (default: 0) >The maximal number of AUTH commands that any client is allowed >to send to this service per time unit, regardless of whether >or not Postfix actually accepts those commands. The time unit >is specified with the anvil_rate_time_unit configuration >parameter. That defaults to 60s so setting this to 3 would rate limit to three attempts per minute. That’s good to know. That might be useful, though I am not sure I am seeing very fast auth attempts. Still, it certainly can’t hurt.
Re: Dictionary attacks
Wietse Venema: > John Schmerold: > > What is the best way to protect against dictionary attacks in Postfix? > > Reportedly, fail2ban (no first-hand experience, because I have no > SASL clients). Also, Postfix can rate-limit auth commands, on the assumption that good users don't make lots of repeated login attempts. Wietse htp://www.postfix.org/postconf.5.html#smtpd_client_auth_rate_limit smtpd_client_auth_rate_limit (default: 0) The maximal number of AUTH commands that any client is allowed to send to this service per time unit, regardless of whether or not Postfix actually accepts those commands. The time unit is specified with the anvil_rate_time_unit configuration parameter. By default, there is no limit on the number AUTH commands that a client may send. To disable this feature, specify a limit of 0. WARNING: The purpose of this feature is to limit abuse. It must not be used to regulate legitimate mail traffic. This feature is available in Postfix 3.1 and later.
Re: Dictionary attacks
On 03/11/2019 02:42, Wietse Venema wrote: > John Schmerold: >> What is the best way to protect against dictionary attacks in Postfix? > > Reportedly, fail2ban (no first-hand experience, because I have no > SASL clients). > > Wietse > I run a home-brewed fail2ban look-alike; I find it almost as useful as postscreen. Another mailling list suggests an ACL based on IP netblocks, to define a "service area" where incoming AUTH connections are permitted. Allen C
Re: Dictionary attacks
John Schmerold: > What is the best way to protect against dictionary attacks in Postfix? Reportedly, fail2ban (no first-hand experience, because I have no SASL clients). Wietse
Dictionary attacks
What is the best way to protect against dictionary attacks in Postfix?
Exim has a rcpt_fail_count variable I use to drop connections with the
attacker:
drop condition = ${if > {${eval:$rcpt_fail_count}}{3}{yes}{no}}
log_message = Dictionary Attack Rejected (Began blocking after
$rcpt_fail_count recipients failed). Ratelimit incremented.
ratelimit = 0 / 2h / strict / per_conn
message = Number of failed recipients exceeded. Come back
in a few hours.
I am switching from Exim to Postfix and looking for a mechanism to block
these attacks.
--
John Schmerold
Katy Computer Systems, Inc
https://katycomputer.com
St Louis
Re: SASL and AUTH dictionary attacks
Thanks, Viktor, for clarifying all this. Very helpful :-) Forrest On 6/12/15 12:31 PM, Viktor Dukhovni wrote: On Fri, Jun 12, 2015 at 12:07:15PM -0400, Forrest wrote: My server advertises (EHLO): 250-PIPELINING 250-SIZE [ omitted ] 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME No SASL AUTH there. Hm. Interesting, thanks for pointing that obvious thing out :) I have the following: # SASL smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = mydomain.com smtpd_sasl_path = smtpd And likely also: smtpd_tls_auth_only = yes which disables SASL AUTH for cleartext connections, and perhaps even master.cf overrides that disable it for port 25, if you don't need SASL support there at all. With regard to logging, perhaps you're correct that Sendmail wasn't as verbose. But, it did log things and I don't recall seeing these issues before. There is no "issue". You're just confusing yourself. * Botnets are trying SASL logins (as they surely did before), mostly without TLS. * Your server refuses SASL logins in cleartext, so there's no dictionary attack. * Postfix has more informative logs than Sendmail. This is a feature, not a bug. * That information can raise questions that would not be asked were the logs less informative. If you think clearly about what the logs mean, there's nothing to do or worry about. Attempts to dictionary attack weak passwords are refused, by virtue of the fact that all SASL AUTH attempts are refused. Case closed. Just make sure the "attackers" in question are not legitimate users trying to use port 25 in cleartext for submission.
Re: SASL and AUTH dictionary attacks
On 12 Jun 2015, at 11:05, Forrest wrote: Since upgrading to Postfix, my system is seeing a lot of this activity. My prior config was Sendmail 8 with Cyrus SASL which did not. This is a pure coincidence. I administer multiple mail servers running Postfix. CommunigatePro, and Sendmail, and ALL have seen order of magnitude (or 2) increases in AUTH brute force attacks from apparent botnets in the past 3 months. I doubt your upgrade influenced the attack rate against a CGP server in Switzerland handling an obscure set of small business domains. :) My favorite theory is that the growing stream of publicly available data on password frequency and big sets of username+password combos (i.e. breach dumps) being sold around the "dark" net has combined with steady improvement in spam blocking to push botnet operators into this tactic to find trusted mail submission paths. In my own case, well over half of the spam aimed at my most-spammed address that Postfix has accepted for delivery in 2015 shows solid evidence of being sent through a compromised account on a legitimate mail system. That's a thin trickle of messages (<1/day) because thousands of times every day Postfix tells a spammer to keep his spam for that address. My guess from this log is that AUTH is taking place unencrypted, which may be the cause? AUTH is being *attempted* unencrypted. Which isn't ever going to work because... My server advertises (EHLO): 250-PIPELINING 250-SIZE [ omitted ] 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME Try sending an AUTH command after that. Note the response. If Postfix doesn't advertise AUTH it is because you are in a state where AUTH intentionally is disabled and cannot possibly work. It is generally a bad idea to offer AUTH over unencrypted sessions anyway, so that's good. While I'm digging through the config (being somewhat a postfix newbie), might someone comment on how I can discourage this type of activity? You really can't. All you can do is block it after you detect it. Nothing will stop a bot that knows only how to do one thing from doing it until its operator tells it to stop. The operators are not really very bright to begin with, so they try really useless stuff, but they aren't being stupid by being indiscriminate about targeting: hitting everything with a SMTP listener isn't a waste of THEIR resources, it is a waste of HIJACKED resources. Being selective about targets would just run the risk of missing unexpected weaknesses. Historically there have been MTAs that have optionally not advertised AUTH without actually disabling it; as long as both banners and EHLO feature replies MIGHT be lying about the nature of an MTA, a bot operator might as well assume that it might have any of the weaknesses ever seen in any MTA ever. Consider how this is consistent with the tactic of brute-force password guessing. I'm trying to understand what the bots and script kiddies are seeing, that wasn't there before, that is advertising capability to do this. You are assuming too much thinking on the part of the bots and their operators. Remember, this is an industry where the most successful and widespread spambot has been getting caught by greeting pauses for a decade but still fast-talks with a perfectly-identifying invalid EHLO on zombie hordes of simultaneous connections. 36 hours ago, a botbox on a Ukraine DSL link tried opening 2 rounds of ~200 parallel connections to my personal (<10 humans, 8 domains, untold bajillions of valid local addresses...) mail server's submission port about a minute apart and tried to do clear text AUTH on each one despite the fact that the first 6 in each batch got a "530 5.7.0 Must issue a STARTTLS command first" reply and the rest all got whatever Postfix says to clients that it reports as "Connection rate limit exceeded". This morning it was a rather less aggressive Russian machine. In both cases no TLS was attempted, they just spewed AUTH commands that failed plus 2 bogus commands that Postfix only logged as "unknown". Postfix never asked Dovecot about any of the AUTH attempts for the simple reason that Postfix is configured not to allow AUTH without TLS: "smtpd_tls_auth_only = yes" For most of the past month, that overworked machine has been defending itself from port 25 bot attacks by a fail2ban-like trick of feeding syslog 'mail' messages into a script that blocks all further packets from miscreant IPs. That tactic reduces the overall connection burden and log noise of the port 25 attacks, but I'm still seeing as many new sources per day as I was before I started that and many of the blocked IPs keep coming back for weeks after their last successful connection. Doing that on port 587 would be trickier (no postscreen, legitimate reasons for humans doing AUTH there, etc.) but it might be worthwhile given the recent boom in password-guessing attacks. Such attacks are a part of the lat
Re: SASL and AUTH dictionary attacks
On Fri, Jun 12, 2015 at 12:07:15PM -0400, Forrest wrote: > >>My server advertises (EHLO): > >> > >>250-PIPELINING > >>250-SIZE [ omitted ] > >>250-ETRN > >>250-STARTTLS > >>250-ENHANCEDSTATUSCODES > >>250 8BITMIME > > > >No SASL AUTH there. > > Hm. Interesting, thanks for pointing that obvious thing out :) I have the > following: > > # SASL > smtpd_sasl_auth_enable = yes > smtpd_sasl_security_options = noanonymous > smtpd_sasl_local_domain = mydomain.com > smtpd_sasl_path = smtpd And likely also: smtpd_tls_auth_only = yes which disables SASL AUTH for cleartext connections, and perhaps even master.cf overrides that disable it for port 25, if you don't need SASL support there at all. > With regard to logging, perhaps you're correct that Sendmail wasn't as > verbose. But, it did log things and I don't recall seeing these issues > before. There is no "issue". You're just confusing yourself. * Botnets are trying SASL logins (as they surely did before), mostly without TLS. * Your server refuses SASL logins in cleartext, so there's no dictionary attack. * Postfix has more informative logs than Sendmail. This is a feature, not a bug. * That information can raise questions that would not be asked were the logs less informative. If you think clearly about what the logs mean, there's nothing to do or worry about. Attempts to dictionary attack weak passwords are refused, by virtue of the fact that all SASL AUTH attempts are refused. Case closed. Just make sure the "attackers" in question are not legitimate users trying to use port 25 in cleartext for submission. -- Viktor.
Re: SASL and AUTH dictionary attacks
On 6/12/15 11:50 AM, Viktor Dukhovni wrote: On Fri, Jun 12, 2015 at 11:05:42AM -0400, Forrest wrote: My prior config was Sendmail 8 with Cyrus SASL which did not. My guess from this log is that AUTH is taking place unencrypted, which may be the cause? Surely dictionary attacks on SASL were also launched against Sendmail... Was there nothing of the sort in your Sendmail logs? If so perhaps this is a difference in logging rather than actual activity. My server advertises (EHLO): 250-PIPELINING 250-SIZE [ omitted ] 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME No SASL AUTH there. Hm. Interesting, thanks for pointing that obvious thing out :) I have the following: # SASL smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = mydomain.com smtpd_sasl_path = smtpd I'm presently using Cyrus SASL 2.x, which I'd been using with Sendmail 8.x. With regard to logging, perhaps you're correct that Sendmail wasn't as verbose. But, it did log things and I don't recall seeing these issues before. Thanks
Re: SASL and AUTH dictionary attacks
On Fri, Jun 12, 2015 at 11:05:42AM -0400, Forrest wrote: > My prior config was Sendmail 8 with Cyrus SASL which did not. My guess > from this log is that AUTH is taking place unencrypted, which may be the > cause? Surely dictionary attacks on SASL were also launched against Sendmail... Was there nothing of the sort in your Sendmail logs? If so perhaps this is a difference in logging rather than actual activity. > My server advertises (EHLO): > > 250-PIPELINING > 250-SIZE [ omitted ] > 250-ETRN > 250-STARTTLS > 250-ENHANCEDSTATUSCODES > 250 8BITMIME No SASL AUTH there. > Jun 11 15:31:19 mail postfix/smtpd[26189]: connect from > static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] > Jun 11 15:31:19 mail postfix/smtpd[26189]: lost connection after AUTH from > static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] This is not a dictionary attack, as SASL is disabled without TLS, and what you're seeing is that the client gives up after Postfix rejects the AUTH command (based on non-support for AUTH rather than an incorrect password guess). Which means you're just paying a bit too much attention to the logging, where previously Sendmail might not have logged the last command before the disconnect. There's nothing to fix. (Unless you have legitimate SASL users on port 25 who did not get the memo about moving to port 587 with STARTTLS or 465 with wrappermode). -- Viktor.
SASL and AUTH dictionary attacks
Since upgrading to Postfix, my system is seeing a lot of this activity. My prior config was Sendmail 8 with Cyrus SASL which did not. My guess from this log is that AUTH is taking place unencrypted, which may be the cause? My server advertises (EHLO): 250-PIPELINING 250-SIZE [ omitted ] 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME While I'm digging through the config (being somewhat a postfix newbie), might someone comment on how I can discourage this type of activity? I'm trying to understand what the bots and script kiddies are seeing, that wasn't there before, that is advertising capability to do this. Thanks. Jun 11 15:31:19 mail postfix/smtpd[26189]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:19 mail postfix/smtpd[26189]: lost connection after AUTH from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:19 mail postfix/smtpd[26189]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:31:19 mail postfix/smtpd[26189]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:19 mail postfix/smtpd[26189]: lost connection after AUTH from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:19 mail postfix/smtpd[26189]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:31:20 mail postfix/smtpd[26189]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:22 mail postfix/smtpd[26189]: lost connection after AUTH from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:22 mail postfix/smtpd[26189]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:31:24 mail postfix/smtpd[26198]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:27 mail postfix/smtpd[26198]: lost connection after AUTH from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:27 mail postfix/smtpd[26198]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:31:28 mail postfix/smtpd[26189]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:30 mail postfix/smtpd[26189]: lost connection after AUTH from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:30 mail postfix/smtpd[26189]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:31:31 mail postfix/smtpd[26198]: connect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] Jun 11 15:31:31 mail postfix/smtpd[26198]: warning: Connection rate limit exceeded: 6 from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] for service smtp Jun 11 15:31:31 mail postfix/smtpd[26198]: disconnect from static-71-250-232-194.nwrknj.east.verizon.net[71.250.232.194] ehlo=1 auth=0/1 commands=1/2 Jun 11 15:34:53 mail postfix/anvil[26191]: statistics: max connection rate 6/60s for (smtp:71.250.232.194) at Jun 11 15:31:31 Jun 11 15:34:53 mail postfix/anvil[26191]: statistics: max connection count 1 for (smtp:71.250.232.194) at Jun 11 15:31:19
Re: SASL AUTH dictionary attacks
Am 10.06.2015 um 00:19 schrieb Scott Lambert: I've been looking for, but haven't found, yet, a postfix option that would delay x seconds after a failed auth attempt. We still use fail2ban, but the botnets are just too large. This can be set within Dovecot when using Dovecot for SASL authentication. /etc/dovecot/conf.d/10-auth.conf auth_failure_delay = 5 secs -- Alex JOST
Re: SASL AUTH dictionary attacks
On 6/9/15 6:19 PM, Scott Lambert wrote: On Tue, Jun 09, 2015 at 07:23:43PM +, Viktor Dukhovni wrote: On Tue, Jun 09, 2015 at 02:26:20PM -0400, Forrest wrote: So that log entry might be for the submission port, unless you've configured it along the lines above. I believe this is already set in my master.cf, which is: smtp inet n - n - - smtpd submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=may In that case, consider disabling SASL auth by default (main.cf), and enabling it only for the submission service. That should eliminate all the port 25 SASL attacks. This is something I've recently had to do to allow mail from "the world" while firewalling off everything except "nearby" to authenticate via the submission port. The bruteforcers were overwhelming my authentication database. I just added "-o smtpd_sasl_auth_enable=no" to the smtp entry in master.cf. This led to a lot of support calls from users with outlook set to use port 25 for submission. I've been looking for, but haven't found, yet, a postfix option that would delay x seconds after a failed auth attempt. We still use fail2ban, but the botnets are just too large. In this scenario, it would make sense to have a throttle option /in/ Postfix (as opposed to an external tool). Or whatever other clever mechanisms to help deal with the bots and script kiddies.
Re: SASL AUTH dictionary attacks
Now they're hitting me here: Jun 9 23:49:13 mail postfix/smtpd[17263]: connect from unknown[71.19.249.5] Jun 9 23:49:13 mail postfix/smtpd[17263]: lost connection after AUTH from unknown[71.19.249.5] Jun 9 23:49:13 mail postfix/smtpd[17263]: disconnect from unknown[71.19.249.5] ehlo=1 auth=0/1 commands=1/2 Prior to this, with Sendmail 8.x, I hadn't seen this for a long time. My configuration was basically similar (if you can call it that). Postfix is throttling these, at least: Jun 9 23:49:14 mail postfix/smtpd[17263]: warning: Connection rate limit exceeded: 9 from unknown[71.19.249.5] for service smtp Thanks, Forrest
Re: SASL AUTH dictionary attacks
On Tue, Jun 09, 2015 at 07:23:43PM +, Viktor Dukhovni wrote: > On Tue, Jun 09, 2015 at 02:26:20PM -0400, Forrest wrote: > > > >So that log entry might be for the submission port, unless you've > > >configured it along the lines above. > > > > I believe this is already set in my master.cf, which is: > > > > smtp inet n - n - - smtpd > > submission inet n - n - - smtpd > > -o syslog_name=postfix/submission > > -o smtpd_tls_security_level=may > > In that case, consider disabling SASL auth by default (main.cf), > and enabling it only for the submission service. That should > eliminate all the port 25 SASL attacks. This is something I've recently had to do to allow mail from "the world" while firewalling off everything except "nearby" to authenticate via the submission port. The bruteforcers were overwhelming my authentication database. I just added "-o smtpd_sasl_auth_enable=no" to the smtp entry in master.cf. This led to a lot of support calls from users with outlook set to use port 25 for submission. I've been looking for, but haven't found, yet, a postfix option that would delay x seconds after a failed auth attempt. We still use fail2ban, but the botnets are just too large. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org
Re: SASL AUTH dictionary attacks
On Tue, Jun 09, 2015 at 02:26:20PM -0400, Forrest wrote: > >So that log entry might be for the submission port, unless you've > >configured it along the lines above. > > I believe this is already set in my master.cf, which is: > > smtp inet n - n - - smtpd > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_tls_security_level=may In that case, consider disabling SASL auth by default (main.cf), and enabling it only for the submission service. That should eliminate all the port 25 SASL attacks. -- Viktor.
Re: SASL AUTH dictionary attacks
On 6/9/15 1:38 PM, Viktor Dukhovni wrote: On Tue, Jun 09, 2015 at 01:23:47PM -0400, Forrest wrote: postfix/smtpd[12345]: warning: unknown[212.156.86.90]: SASL LOGIN authentication failed: authentication failure so I presume that's port 25, as I have submission running as another configuration in master.cf. By default the logs don't distinguish between SMTP serverices listening on different ports. You need to override "syslog_name" in master.cf to get service-specific logging. The commented-out submission entry in recent stock master.cf files starts with: #submission inet n - n - - smtpd # -o syslog_name=postfix/submission So that log entry might be for the submission port, unless you've configured it along the lines above. I believe this is already set in my master.cf, which is: smtp inet n - n - - smtpd submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=may
Re: SASL AUTH dictionary attacks
On Tue, Jun 09, 2015 at 01:23:47PM -0400, Forrest wrote: > postfix/smtpd[12345]: warning: unknown[212.156.86.90]: SASL LOGIN > authentication failed: authentication failure > > so I presume that's port 25, as I have submission running as another > configuration in master.cf. By default the logs don't distinguish between SMTP serverices listening on different ports. You need to override "syslog_name" in master.cf to get service-specific logging. The commented-out submission entry in recent stock master.cf files starts with: #submission inet n - n - - smtpd # -o syslog_name=postfix/submission So that log entry might be for the submission port, unless you've configured it along the lines above. -- Viktor.
Re: SASL AUTH dictionary attacks
On 6/9/15 1:02 PM, Viktor Dukhovni wrote: On Tue, Jun 09, 2015 at 12:54:51PM -0400, Forrest wrote: I recently updated my system from Sendmail to Postfix 3.0.1. Since that time, I've been targeted with several SASL dictionary attacks; activity I've not seen in this number before. Restricting SASL to TLS might help... http://www.postfix.org/SASL_README.html#server_sasl_authc smtpd_tls_auth_only = yes if the attacks are primarily over non-TLS connections. You might also restrict SASL to port 587 and not enable it on port 25. Thank you. I will eventually get the grasp of Postix (this is how we learn). I put that setting in. The logs only show entries like: postfix/smtpd[12345]: warning: unknown[212.156.86.90]: SASL LOGIN authentication failed: authentication failure so I presume that's port 25, as I have submission running as another configuration in master.cf. Thanks.
Re: SASL AUTH dictionary attacks
On Tue, Jun 09, 2015 at 12:54:51PM -0400, Forrest wrote: > I recently updated my system from Sendmail to Postfix 3.0.1. Since that > time, I've been targeted with several SASL dictionary attacks; activity I've > not seen in this number before. Restricting SASL to TLS might help... http://www.postfix.org/SASL_README.html#server_sasl_authc smtpd_tls_auth_only = yes if the attacks are primarily over non-TLS connections. You might also restrict SASL to port 587 and not enable it on port 25. > Reading around elsewhere, I wonder if the script kiddies are looking for > Postfix in the banner (which I've since removed), going after a presumed > vulnerability? The "vulnerability" in question is weak (easily guessed) passwords. It seems unlikely that such attacks specifically target Postfix, or that they care about the ESMTP banner. -- Viktor.
SASL AUTH dictionary attacks
I recently updated my system from Sendmail to Postfix 3.0.1. Since that time, I've been targeted with several SASL dictionary attacks; activity I've not seen in this number before. Reading around elsewhere, I wonder if the script kiddies are looking for Postfix in the banner (which I've since removed), going after a presumed vulnerability? I've seen items like Fail2Ban and so forth. I don't know that it would be appropriate for Postfix to temporarily ban IPs or throttle these types of failures. There may be some settings I've not yet become aware of that I could tweak to either discourage this or make it very difficult. Thanks.
