Hi!
I finally had some time to start back on this over the holidays.
I'm a bit lost and would appreciate some guidance.
In the daily logs (logwatch), I'm getting many authentication failures under the heading "pam_unix". I thought I had fail2ban set up to catch all the authentication failures but it looks like I'm missing something.
Some background.
I have fail2ban finally working. I have jails [postfix-sasl], [postfix-auth] (thanks Nick), [cyrus-imap], [openvpn].
I am running postfix and have following mail ports open: 25, 465, 587, 993, 995. imap or pop unsecure are not open.
The only other ports open are the Clear 1875, NTP, OpenVPN, 80 & 443 for the webserver/apache.
Can you give me some suggestions as to what I should be looking at to figure out what jail I am missing to catch and start to block these connection attempts?
Thanks.
I finally had some time to start back on this over the holidays.
I'm a bit lost and would appreciate some guidance.
In the daily logs (logwatch), I'm getting many authentication failures under the heading "pam_unix". I thought I had fail2ban set up to catch all the authentication failures but it looks like I'm missing something.
Some background.
I have fail2ban finally working. I have jails [postfix-sasl], [postfix-auth] (thanks Nick), [cyrus-imap], [openvpn].
I am running postfix and have following mail ports open: 25, 465, 587, 993, 995. imap or pop unsecure are not open.
The only other ports open are the Clear 1875, NTP, OpenVPN, 80 & 443 for the webserver/apache.
Can you give me some suggestions as to what I should be looking at to figure out what jail I am missing to catch and start to block these connection attempts?
Thanks.
--------------------- pam_unix Begin ------------------------
imap:
Authentication Failures:
user1: 322 Time(s)
user2: 294 Time(s)
user3: 57 Time(s)
user4: 51 Time(s)
user5: 20 Time(s)
Invalid Users:
Unknown Account: 3 Time(s)
Unknown Entries:
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=: 3 Time(s)
pop:
Authentication Failures:
user3: 78 Time(s)
user5: 49 Time(s)
user4: 1 Time(s)
smtp:
Authentication Failures:
(0) -> user5: 6 Time(s)
(0) -> user3: 5 Time(s)
(0) -> guest: 2 Time(s)
(0) -> user2: 2 Time(s)
(0) -> root: 2 Time(s)
Invalid Users:
Unknown Account: 121 Time(s)
---------------------- pam_unix End -------------------------
Share this post:
Accepted Answer
Remember that Attack Detector uses f2b so I would not enable things in Attack Detector (which uses configlets in /etc/fail2ban/jail.d and in jail.local at the same time) If you disable one, I am not sure which takes precedence. From the Attack Detector Doc, you can check your f2b blocks with:
When you see a BAN message in the f2b log, check for errors around it and make sure it appears in the relevant f2b jail.
Attacks where the user hops IP's are hard to protect from. I do have a custom jail which bans subnets if the user is sending e-mails from an IP address without a PTR record as these are generally hacked ADSL accounts, but it is not necessarily something you want to do.
As my users only ever use STARTTLS for sending e-mails when on the road I have no reason to accept any authentication on port 25 so I turn it off. I then reduce maxretry to 1 in /etc/fail2ban/jail.d/clearos-postfix-sasl.conf.
For cyrus-imap which methods do you use to pick up e-mails? POP, POPS, IMAP or IMAPS? Close the firewall for any you don't use and also disable them in the webconfig. Other than that it is hard to defend against. In theory I always set up users (my family) while they are connected to the LAN, so I also set maxretry to 1 in /etc/fail2ban/jail.d/clearos-cyrus-imap.conf as authentication should never fail when on the road. I also set bantime to 432000 and findtime to 86400. It is a bit aggressive. I also whitelist my LAN in Attack Detector (check the docs) so, if I make a mess of setting up a PC on the LAN, it does not immediately block me.
for SET in `ipset list -n | grep f2b`; do ipset list $SET -o save | grep ^add | awk '{print $2 " " $3}'; doneWhen you see a BAN message in the f2b log, check for errors around it and make sure it appears in the relevant f2b jail.
Attacks where the user hops IP's are hard to protect from. I do have a custom jail which bans subnets if the user is sending e-mails from an IP address without a PTR record as these are generally hacked ADSL accounts, but it is not necessarily something you want to do.
As my users only ever use STARTTLS for sending e-mails when on the road I have no reason to accept any authentication on port 25 so I turn it off. I then reduce maxretry to 1 in /etc/fail2ban/jail.d/clearos-postfix-sasl.conf.
For cyrus-imap which methods do you use to pick up e-mails? POP, POPS, IMAP or IMAPS? Close the firewall for any you don't use and also disable them in the webconfig. Other than that it is hard to defend against. In theory I always set up users (my family) while they are connected to the LAN, so I also set maxretry to 1 in /etc/fail2ban/jail.d/clearos-cyrus-imap.conf as authentication should never fail when on the road. I also set bantime to 432000 and findtime to 86400. It is a bit aggressive. I also whitelist my LAN in Attack Detector (check the docs) so, if I make a mess of setting up a PC on the LAN, it does not immediately block me.
Responses (18)
-
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
Are the failures for valid users in the pam messages? If so the short answer is don't worry about them. You will probably get them every time a user logs on. For the long answer see https://www.clearos.com/clearfoundation/social/community/pam-unix-authentication-failure and similar threads. I use the file in this post in a different thread. The issue is that the authentication mechanism tries against unix accounts first and reports an error if it fails and then it tries against ldap accounts. All cyrus-imap users are ldap users.
Thanks Nick. That is interesting and seems logical.
I've read through the threads and need to do some background reading. I'll try this on the weekend and see if I can implement the fix.
Out of curiousity, did anyone every fix the issue in the bug report? -
Accepted Answer
Are the failures for valid users in the pam messages? If so the short answer is don't worry about them. You will probably get them every time a user logs on. For the long answer see https://www.clearos.com/clearfoundation/social/community/pam-unix-authentication-failure and similar threads. I use the file in this post in a different thread. The issue is that the authentication mechanism tries against unix accounts first and reports an error if it fails and then it tries against ldap accounts. All cyrus-imap users are ldap users. -
Accepted Answer
Nick Howitt wrote:
So it uses the name imapd for port 993 but cyrus-master for the IMAP and POPS processes. Strange programming! IMAP is listening on localhost only. I've no idea why that would be but let's assume it is correct.
As you are not listening externally on POP/IMAP, I'd assume you logwatch report is grouping POP and POPS together and reporting them as POP. Ditto IMAP and IMAPS, but only you can crosscheck that. A quick grep of failures in the maillog for one day may prove that.
Hi again.
Sorry I've had no time to look at this for a week.
The number of failures is still in the hundreds.
But the grep of failures in maillog shows only 21 for the day on imaps. All failures are captured in fail2ban and the IP addresses are banned.
I'm scratching my head and can't figure out why logwatch is still showing 717 failures over 5 users on the same day.
If the failures aren't in maillog, then where could logwatch be picking up the failures? -
Accepted Answer
So it uses the name imapd for port 993 but cyrus-master for the IMAP and POPS processes. Strange programming! IMAP is listening on localhost only. I've no idea why that would be but let's assume it is correct.
As you are not listening externally on POP/IMAP, I'd assume you logwatch report is grouping POP and POPS together and reporting them as POP. Ditto IMAP and IMAPS, but only you can crosscheck that. A quick grep of failures in the maillog for one day may prove that. -
Accepted Answer
Nick Howitt wrote:
The forum has made a mess of you post. I've managed to get it a bit better looking.
I can see you only have POPS and IMAPS open, so no POP or IMAP. What I don't understand is that POPS does not seem to be listening either. Perhaps I have the command wrong. Does:
show any more information?netstat -npl | egrep '(110|143|993|995)'
if it just shows 993 and 995 then your log reports are probably due to POPS and IMAPS transactions being reported by logwatch as POP/IMAP, but you'll need to check your logs to prove it. If it is the case, then you probably can't do much about it other than reduce the maxretry parameter.
Cool. Thanks again.
Here goes. (I hope it formats OK)
netstat -npl | egrep '(110|143|993|995)'
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 10252/imapd
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 17264/cyrus-master
tcp 0 0 127.0.0.1:143 0.0.0.0:* LISTEN 17264/cyrus-master
tcp6 0 0 :::993 :::* LISTEN 17264/cyrus-master
tcp6 0 0 :::995 :::* LISTEN 17264/cyrus-master
unix 2 [ ACC ] STREAM LISTENING 1056993341 11981/master private/anvil
unix 2 [ ACC ] STREAM LISTENING 1056993293 11981/master private/bounce
unix 2 [ ACC ] STREAM LISTENING 1056993296 11981/master private/defer
unix 2 [ ACC ] STREAM LISTENING 1056993344 11981/master private/scache
unix 2 [ ACC ] STREAM LISTENING 1056993311 11981/master private/proxywrite
unix 2 [ ACC ] STREAM LISTENING 1056993299 11981/master private/trace
unix 2 [ ACC ] STREAM LISTENING 1056993305 11981/master public/flush
unix 2 [ ACC ] STREAM LISTENING 1056993302 11981/master private/verify
unix 2 [ ACC ] STREAM LISTENING 1056993323 11981/master private/error
unix 2 [ ACC ] STREAM LISTENING 1056993326 11981/master private/retry
unix 2 [ ACC ] STREAM LISTENING 1056993314 11981/master private/smtp
unix 2 [ ACC ] STREAM LISTENING 1056993287 11981/master private/tlsmgr
unix 2 [ ACC ] STREAM LISTENING 1056993347 11981/master private/mailprefilter
unix 2 [ ACC ] STREAM LISTENING 1056993361 11981/master private/mailpostfilter
unix 2 [ ACC ] STREAM LISTENING 1056993282 11981/master public/cleanup
unix 2 [ ACC ] STREAM LISTENING 1056993317 11981/master private/relay
unix 2 [ ACC ] STREAM LISTENING 1056993329 11981/master private/discard
unix 2 [ ACC ] STREAM LISTENING 1056993350 11981/master private/smtp-amavis
unix 2 [ ACC ] STREAM LISTENING 1056993290 11981/master private/rewrite
unix 2 [ ACC ] STREAM LISTENING 1056993308 11981/master private/proxymap
unix 2 [ ACC ] STREAM LISTENING 1056993320 11981/master public/showq
unix 2 [ ACC ] STREAM LISTENING 1056993335 11981/master private/virtual
unix 2 [ ACC ] STREAM LISTENING 1056993332 11981/master private/local
unix 2 [ ACC ] STREAM LISTENING 1056993338 11981/master private/lmtp -
Accepted Answer
The forum has made a mess of you post. I've managed to get it a bit better looking.
I can see you only have POPS and IMAPS open, so no POP or IMAP. What I don't understand is that POPS does not seem to be listening either. Perhaps I have the command wrong. Does:
show any more information?netstat -npl | egrep '(110|143|993|995)'
if it just shows 993 and 995 then your log reports are probably due to POPS and IMAPS transactions being reported by logwatch as POP/IMAP, but you'll need to check your logs to prove it. If it is the case, then you probably can't do much about it other than reduce the maxretry parameter. -
Accepted Answer
Thanks for continuing to help, Nick.
Nick Howitt wrote:
What do you get from:netstat -npl | egrep '(pop|imap)'
Here is what I get:
[code type="markup"]netstat -npl | egrep '(pop|imap)'
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 11938/imapd
unix 2 [ ACC ] STREAM LISTENING 506564249 17264/cyrus-master /var/lib/imap/socket/lmtp
and
Nick Howitt wrote:
What do you get from:
iptables -nvL INPUT
iptables -nvL INPUT
Chain INPUT (policy DROP 22844 packets, 2659K bytes)
pkts bytes target prot opt in out source destination
6032 362K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587,220,993,110,995 match-set f2b-postfix-sasl src
294 15288 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465,587 match-set f2b-postfix-auth src
2526 163K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 220,993,110,995 match-set f2b-cyrus-imap src
37546 1986K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate NEW match-set country-list src
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set snortsam_INGRESS src
945 71820 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 state RELATED,ESTABLISHED
26 1088 DROP tcp -- * * !127.0.0.1 0.0.0.0/0 tcp dpt:3128
0 0 DROP all -- * * 101.188.165.241 0.0.0.0/0
0 0 DROP all -- * * 103.107.236.182 0.0.0.0/0
0 0 DROP all -- * * 103.224.182.243 0.0.0.0/0
0 0 DROP all -- * * 104.153.108.74 0.0.0.0/0
0 0 DROP all -- * * 104.194.218.51 0.0.0.0/0
0 0 DROP all -- * * 109.236.32.0/22 0.0.0.0/0
0 0 DROP all -- * * 115.231.220.215 0.0.0.0/0
0 0 DROP all -- * * 122.144.0.0/16 0.0.0.0/0
0 0 DROP all -- * * 124.149.199.6 0.0.0.0/0
0 0 DROP all -- * * 13.113.224.207 0.0.0.0/0
0 0 DROP all -- * * 13.77.46.77 0.0.0.0/0
0 0 DROP all -- * * 13.77.58.33 0.0.0.0/0
0 0 DROP all -- * * 137.226.113.9 0.0.0.0/0
0 0 DROP all -- * * 149.56.149.29 0.0.0.0/0
0 0 DROP all -- * * 163.172.23.6 0.0.0.0/0
0 0 DROP all -- * * 164.160.0.0/16 0.0.0.0/0
0 0 DROP all -- * * 164.52.24.140 0.0.0.0/0
0 0 DROP all -- * * 167.114.15.64/29 0.0.0.0/0
0 0 DROP all -- * * 167.114.189.192/29 0.0.0.0/0
0 0 DROP all -- * * 169.229.3.91 0.0.0.0/0
0 0 DROP all -- * * 172.192.14.51 0.0.0.0/0
0 0 DROP all -- * * 176.57.180.22 0.0.0.0/0
19 772 DROP all -- * * 185.200.118.0/25 0.0.0.0/0
0 0 DROP all -- * * 185.202.103.51 0.0.0.0/0
0 0 DROP all -- * * 185.246.210.0/24 0.0.0.0/0
0 0 DROP all -- * * 185.30.166.0/24 0.0.0.0/0
0 0 DROP all -- * * 187.49.236.185 0.0.0.0/0
0 0 DROP all -- * * 192.102.6.0/23 0.0.0.0/0
0 0 DROP all -- * * 192.99.98.104 0.0.0.0/0
0 0 DROP all -- * * 193.104.68.17 0.0.0.0/0
0 0 DROP all -- * * 193.112.190.175 0.0.0.0/0
0 0 DROP all -- * * 194.74.181.123 0.0.0.0/0
0 0 DROP all -- * * 195.22.22.20 0.0.0.0/0
0 0 DROP all -- * * 200.229.202.176 0.0.0.0/0
0 0 DROP all -- * * 206.128.153.219 0.0.0.0/0
0 0 DROP all -- * * 208.100.26.231 0.0.0.0/0
0 0 DROP all -- * * 213.202.230.144 0.0.0.0/0
0 0 DROP all -- * * 218.75.37.18 0.0.0.0/0
0 0 DROP all -- * * 218.75.40.149 0.0.0.0/0
0 0 DROP all -- * * 23.101.224.255 0.0.0.0/0
0 0 DROP all -- * * 37.187.148.221 0.0.0.0/0
8 320 DROP all -- * * 37.49.224.0/22 0.0.0.0/0
0 0 DROP all -- * * 38.123.205.178 0.0.0.0/0
0 0 DROP all -- * * 38.69.156.147 0.0.0.0/0
0 0 DROP all -- * * 46.161.27.27 0.0.0.0/0
38 1520 DROP all -- * * 46.161.27.0/24 0.0.0.0/0
0 0 DROP all -- * * 46.229.170.197 0.0.0.0/0
0 0 DROP all -- * * 5.101.40.82 0.0.0.0/0
0 0 DROP all -- * * 5.39.218.36 0.0.0.0/0
0 0 DROP all -- * * 54.207.11.46 0.0.0.0/0
0 0 DROP all -- * * 54.233.236.68 0.0.0.0/0
0 0 DROP all -- * * 60.191.38.77 0.0.0.0/0
0 0 DROP all -- * * 63.251.20.151 0.0.0.0/0
3 132 DROP all -- * * 66.240.205.34 0.0.0.0/0
3 132 DROP all -- * * 66.240.236.119 0.0.0.0/0
0 0 DROP all -- * * 69.16.196.163 0.0.0.0/0
0 0 DROP all -- * * 73.65.208.195 0.0.0.0/0
0 0 DROP all -- * * 74.91.122.249 0.0.0.0/0
0 0 DROP all -- * * 77.220.180.235 0.0.0.0/0
0 0 DROP all -- * * 80.82.70.210 0.0.0.0/0
19 825 DROP all -- * * 80.82.77.0/24 0.0.0.0/0
0 0 DROP all -- * * 85.94.204.144/28 0.0.0.0/0
0 0 DROP all -- * * 91.197.232.11 0.0.0.0/0
0 0 DROP all -- * * 92.60.16.0/23 0.0.0.0/0
0 0 DROP all -- * * 93.55.122.185 0.0.0.0/0
297 12331 DROP all -- * * 94.102.48.0/20 0.0.0.0/0
0 0 DROP all -- * * 154.118.32.0/23 0.0.0.0/0
0 0 DROP all -- * * 62.210.77.54 0.0.0.0/0
109 8313 DROP all -- * * 146.88.240.0/20 0.0.0.0/0
0 0 DROP all -- * * 192.241.219.147 0.0.0.0/0
0 0 DROP all -- * * 181.56.0.0/13 0.0.0.0/0
0 0 DROP all -- * * 85.217.192.0/20 0.0.0.0/0
0 0 DROP all -- * * 195.24.192.0/19 0.0.0.0/0
0 0 DROP all -- * * 95.170.72.0/24 0.0.0.0/0
0 0 DROP all -- * * 37.97.254.27 0.0.0.0/0
0 0 DROP all -- * * 185.138.248.0/22 0.0.0.0/0
0 0 DROP all -- * * 194.0.16.0/20 0.0.0.0/0
0 0 DROP all -- * * 185.234.219.63 0.0.0.0/0
0 0 DROP all -- * * 103.37.114.0/24 0.0.0.0/0
42 2520 DROP all -- * * 69.94.128.0/19 0.0.0.0/0
66 2848 DROP all -- * * 172.104.0.0/15 0.0.0.0/0
0 0 DROP all -- * * 195.22.126.0/23 0.0.0.0/0
0 0 DROP all -- * * 83.97.20.0/24 0.0.0.0/0
0 0 DROP all -- * * 142.4.0.0/19 0.0.0.0/0
6 240 DROP all -- * * 162.144.0.0/16 0.0.0.0/0
1 147 DROP all -- * * 91.150.64.0/18 0.0.0.0/0
0 0 DROP all -- * * 198.108.66.0/23 0.0.0.0/0
0 0 DROP all -- * * 185.153.196.0/22 0.0.0.0/0
0 0 DROP all -- * * 174.136.14.0/24 0.0.0.0/0
0 0 DROP all -- * * 109.236.32.0/22 0.0.0.0/0
0 0 DROP all -- * * 193.32.161.0/24 0.0.0.0/0
12 480 DROP all -- * * 61.219.11.0/24 0.0.0.0/0
0 0 DROP all -- * * 195.62.47.0/24 0.0.0.0/0
3 132 DROP all -- * * 66.240.192.138 0.0.0.0/0
0 0 DROP all -- * * 185.100.87.191 0.0.0.0/0
0 0 DROP all -- * * 185.222.211.0/24 0.0.0.0/0
0 0 DROP all -- * * 103.89.88.0/22 0.0.0.0/0
0 0 DROP all -- * * 199.254.28.0/22 0.0.0.0/0
0 0 DROP all -- * * 199.249.112.0/20 0.0.0.0/0
0 0 DROP all -- * * 192.200.202.0/24 0.0.0.0/0
0 0 DROP all -- * * 185.138.250.0/27 0.0.0.0/0
0 0 DROP all -- * * 103.103.196.97 0.0.0.0/0
8868 409K DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
1856 148K DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- ppp0 * 127.0.0.0/8 0.0.0.0/0
7038K 7321M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
37M 60G ACCEPT all -- enp3s2 * 0.0.0.0/0 0.0.0.0/0
2637K 675M ACCEPT all -- p2p1 * 0.0.0.0/0 0.0.0.0/0
4155 121K ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 0
35 2662 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 3
3318 253K ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 8
0 0 ACCEPT icmp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 icmptype 11
0 0 ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:1875
10019 575K ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:80
3599 274K ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:443
12713 1194K ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:993
78 9571 ACCEPT udp -- * * 0.0.0.0/0 76.10.149.238 udp dpt:123
10 427 ACCEPT udp -- * * 0.0.0.0/0 76.10.149.238 udp dpt:1194
491 20451 ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:1194
3042 219K ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:995
16732 18M ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:25
259 18847 ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:587
1236 123K ACCEPT tcp -- * * 0.0.0.0/0 76.10.149.238 tcp dpt:465
118K 17M ACCEPT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
3802K 5428M ACCEPT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED -
Accepted Answer
-
Accepted Answer
Nick Howitt wrote:
Check your mail log to see if your authentication failures are really imaps and pops. I think you are using logwatch for your report. It may group imap and imaps together and so on. If the ports aren't open you should not be getting failures on those ports. Again, similar to SMTP, you can reduce the maxretry in in the f2b configlet.
Nick, thanks again for the suggestion and help.
I'm still trying to figure out why I get so many imap and pop pam authentication errors.
I checked the maillog and I don't see any imap or pop. Everything is imaps and pop3s.
The sasl login authentication error is reduced to about 53 now.
And lines like this are being blocked.
imaps: [9683]: badlogin: dhcp-74-83-c2-1f-4f-5d.cpe.eaglecable.net [69.18.247.123] plain [SASL(-13): authentication failure: Password verification failed]
I've been researching to see if I can get pam to show more detailed debug messages but stuck at the moment. -
Accepted Answer
Check your mail log to see if your authentication failures are really imaps and pops. I think you are using logwatch for your report. It may group imap and imaps together and so on. If the ports aren't open you should not be getting failures on those ports. Again, similar to SMTP, you can reduce the maxretry in in the f2b configlet.
The way ClearOS has postfix set up is that it allows you to relay e-mails on port if:
a) if you are sending from any of the Trusted Networks
b) if you have a valid user/pass and authentication is enabled
You are restricting b) by disabling authentication. Authentication is still allowed on port 465 (SMTPS) and 587 (STARTTLS) and that is set up differently (in master.cf).
I am not sure what else you can do. -
Accepted Answer
Nick Howitt wrote:
Disabling authentication is done through the SMTP webconfig > User Policies > SMTP Authentication.
The warning in post you linked to does not realise you are using STARTTLS on 587 and if you read just below the warning, he turns on STARTTLS on port 465 to get round that very issue noted in the warning.
Thank you Nick. I have disabled SMTP authentication. Honestly, I'm really nervous about this but I'm willing to give it a try. I guess my mental problem with this is that I worry that if there is no authentication, then it's open and hackers can get in.
It appears that I spoke to soon on the pam-unix authentication reduction. While I have 75 IP addresses in the fb2-cyrus-imap BAN list now, I still had 696 imap authentication failures and 49 pop failures. Those ports are closed so I don't understand how someone could be attempting to authenticate against it. I thought that if the port is closed, there is nothing there for anyone to authenticate against and the server wouldn't even acknowledge anything since the port is blocked.
Is there something else that I should be looking at to reduce these authentication attempts?
I'm pretty sure that I've made sure my family have set up their email clients properly but could this be an incorrect email client authentication issue inside the network? -
Accepted Answer
nuke wrote:
Disabling authentication is done through the SMTP webconfig > User Policies > SMTP Authentication.
Nick Howitt wrote:
I have not said close port 25. You need that to receive e-mails from the outside. I said turn off SMTP authentication in the SMTP server. That parameter only acts on port 25. If no one should be authenticating there, there is no point in exposing yourself to user/pass cracking on port 25.
I will need to research this. Is this authentication in the webconfig or something that is set in the postfix.conf? I didn't see anything in webconfig. What I've started to read about it and it looks like there is a bunch to learn on setting up postfix.conf, main.cf and master.cf. I need to be very careful or I'll undo what progress I've made.
From Postfix: disable authentication through port 25
Hmm. Lots to learn.WARNING:
The request does not follow best security practice because you disable TLS (encryption) on your main mail relay port, exposing data sent through that port to third-party listeners and/or in-flight modification. The answer below satisfies the request, but best practice requires STARTTLS for the port 25 connection as well.
Thanks for all your help Nick!
The warning in post you linked to does not realise you are using STARTTLS on 587 and if you read just below the warning, he turns on STARTTLS on port 465 to get round that very issue noted in the warning. -
Accepted Answer
Nick Howitt wrote:
You've cut the WARNING message, but you can get them up to about 3 minutes after a found. This is because the attacker may make a number of almost concurrent connections - you have 2 in your log snippet 0.6s apart. f2b runs periodically (every 2 seconds?) so it is possible for the ban to become active on the first message while the second transaction is in progress. As long as you see no more warnings after a couple of minutes or so from a ban, you should be OK for a ClearOS jail as the ban time is normally 86400s (8h). The normal default is something like 300s.
Today the log looks much different. It's a thing of beauty! INFO: Found xxx.xxx.xxx.xxx then NOTICE: Ban xxx.xxx.xxx.xxx.
Beautiful! I'm sure my logwatch tomorrow morning will look much better again.
Nick Howitt wrote:I have not said close port 25. You need that to receive e-mails from the outside. I said turn off SMTP authentication in the SMTP server. That parameter only acts on port 25. If no one should be authenticating there, there is no point in exposing yourself to user/pass cracking on port 25.
I will need to research this. Is this authentication in the webconfig or something that is set in the postfix.conf? I didn't see anything in webconfig. What I've started to read about it and it looks like there is a bunch to learn on setting up postfix.conf, main.cf and master.cf. I need to be very careful or I'll undo what progress I've made.
From Postfix: disable authentication through port 25
Hmm. Lots to learn.WARNING:
The request does not follow best security practice because you disable TLS (encryption) on your main mail relay port, exposing data sent through that port to third-party listeners and/or in-flight modification. The answer below satisfies the request, but best practice requires STARTTLS for the port 25 connection as well.
Thanks for all your help Nick! -
Accepted Answer
You've cut the WARNING message, but you can get them up to about 3 minutes after a found. This is because the attacker may make a number of almost concurrent connections - you have 2 in your log snippet 0.6s apart. f2b runs periodically (every 2 seconds?) so it is possible for the ban to become active on the first message while the second transaction is in progress. As long as you see no more warnings after a couple of minutes or so from a ban, you should be OK for a ClearOS jail as the ban time is normally 86400s (8h). The normal default is something like 300s.
I have not said close port 25. You need that to receive e-mails from the outside. I said turn off SMTP authentication in the SMTP server. That parameter only acts on port 25. If no one should be authenticating there, there is no point in exposing yourself to user/pass cracking on port 25. -
Accepted Answer
Thanks Nick.
Nick Howitt wrote:
Remember that Attack Detector uses f2b so I would not enable things in Attack Detector (which uses configlets in /etc/fail2ban/jail.d and in jail.local at the same time) If you disable one, I am not sure which takes precedence. From the Attack Detector Doc, you can check your f2b blocks with:
Are you seeing any for f2b-postfix-sasl matching any of your BAN messages or WARNING already banned messages in the f2b log? From you pam snippet, I'd also possibly expect some for f2b-cyrus-imap as well.for SET in `ipset list -n | grep f2b`; do ipset list $SET -o save | grep ^add | awk '{print $2 " " $3}'; done
I think I have both running but for the moment it is working so I don't want to mess with it.
Yes, I have numerous BAN then followed by a WARNING showing the same IP address like this:
I'll monitor the changes I've made today over the next 24 hrs and see if it continues to happen.2021-01-04 06:40:19,149 fail2ban.filter [2148]: INFO [postfix-auth] Found 85.159.218.246 - 2021-01-04 06:40:18
2021-01-04 06:40:19,770 fail2ban.filter [2148]: INFO [postfix-auth] Found 85.159.218.246 - 2021-01-04 06:40:19
2021-01-04 06:40:20,312 fail2ban.actions [2148]: NOTICE [postfix-auth] Ban 85.159.218.246
2021-01-04 06:40:20,392 fail2ban.filter [2148]: INFO [postfix-auth] Found 85.159.218.246 - 2021-01-04 06:40:20
That's cool code. This is what I get.
for SET in `ipset list -n | grep f2b`; do ipset list $SET -o save | grep ^add | awk '{print $2 " " $3}'; done
f2b-postfix-sasl 5.188.206.204
f2b-postfix-sasl 167.179.6.125
f2b-postfix-sasl 78.128.113.69
f2b-postfix-sasl 123.231.121.2
f2b-postfix-sasl 190.10.8.177
f2b-postfix-auth 85.159.218.246
f2b-postfix-auth 193.169.253.48
Nick Howitt wrote:When you see a BAN message in the f2b log, check for errors around it and make sure it appears in the relevant f2b jail.
No errors at the moment.
Nick Howitt wrote:
Attacks where the user hops IP's are hard to protect from. I do have a custom jail which bans subnets if the user is sending e-mails from an IP address without a PTR record as these are generally hacked ADSL accounts, but it is not necessarily something you want to do.
As my users only ever use STARTTLS for sending e-mails when on the road I have no reason to accept any authentication on port 25 so I turn it off. I then reduce maxretry to 1 in /etc/fail2ban/jail.d/clearos-postfix-sasl.conf.
I have the same thing and everyone has certificates so without that people can't get in as far as I understand. I thought I needed port 25 for incoming mails from the internet??
Nick Howitt wrote:For cyrus-imap which methods do you use to pick up e-mails? POP, POPS, IMAP or IMAPS? Close the firewall for any you don't use and also disable them in the webconfig. Other than that it is hard to defend against. In theory I always set up users (my family) while they are connected to the LAN, so I also set maxretry to 1 in /etc/fail2ban/jail.d/clearos-cyrus-imap.conf as authentication should never fail when on the road. I also set bantime to 432000 and findtime to 86400. It is a bit aggressive. I also whitelist my LAN in Attack Detector (check the docs) so, if I make a mess of setting up a PC on the LAN, it does not immediately block me.
We only have POPS and IMAPS enabled. The only ports open are 465, 587, 993, 995.
I have already whitelisted my LAN :-) I've made the changes to the maxretry to 1. We'll see how it goes in the next 24 hours. -
Accepted Answer
Nick Howitt wrote:
You can't block pam_unix messages as they don't have IP addresses, iirc. Check for the equivalent messages in /var/log/maillog. Also have a look in /var/log/fail2ban.log to see if these are being detected.
Do you have the cyrus-imap filter enabled in the Attack Detector.
Thanks so far, Nick.
I have found many of the authorization issue in the "messages" log. I can roughly correlate to the time in the "fail2ban.log" and "maillog".
Yes, the jail [cyrus-imap] is enabled in the Attack Detector. I think it is actually in my jail.local also.
It looks like it's being found but multiple attempts are made each time. Not every login attempt is logged in fail2ban. And I see the buggers are flipping between IP addresses x.x.x.29, x.x.x.228, x.x.x.227 etc. etc. They are doing 4 attempts with each user name. Do I need something in the fail2ban regex that searches for instances within the /24 network address??
I have added the countryblock for Estonia 3-4 days ago. This is where this 185.234.219.0/24 is located. They still appear to be able to get through to one or more of the ports.
I've tried to tune my jail.local with 2 failed attempts within 60 min then ban.
Here is an example from the logs:
messages
Jan 3 03:55:18 server saslauthd[819]: do_auth : auth failure: [user=office] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:18 server saslauthd[819]: do_auth : auth failure: [user=office] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:18 server saslauthd[819]: do_auth : auth failure: [user=office] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:18 server saslauthd[819]: do_auth : auth failure: [user=office] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:35 server saslauthd[816]: do_auth : auth failure: [user=test2] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:35 server saslauthd[816]: do_auth : auth failure: [user=test2] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:35 server saslauthd[816]: do_auth : auth failure: [user=test2] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:35 server saslauthd[816]: do_auth : auth failure: [user=test2] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:36 server saslauthd[815]: do_auth : auth failure: [user=testuser] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:36 server saslauthd[815]: do_auth : auth failure: [user=testuser] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:36 server saslauthd[815]: do_auth : auth failure: [user=testuser] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
Jan 3 03:55:36 server saslauthd[815]: do_auth : auth failure: [user=testuser] [service=smtp] [realm=domain.ca] [mech=pam] [reason=PAM auth error]
maillog
Jan 3 03:55:15 server postfix/smtpd[29681]: connect from unknown[185.234.219.229]
Jan 3 03:55:15 server postfix/smtpd[29681]: Anonymous TLS connection established from unknown[185.234.219.229]: TLSv1.2 with cipher AES128-SHA256 (128/128 bits)
Jan 3 03:55:18 server postfix/smtpd[29681]: warning: unknown[185.234.219.229]: SASL LOGIN authentication failed: authentication failure
Jan 3 03:55:18 server postfix/smtpd[29681]: disconnect from unknown[185.234.219.229]
Jan 3 03:55:32 server postfix/smtpd[29681]: connect from unknown[185.234.219.228]
Jan 3 03:55:32 server postfix/smtpd[29705]: connect from unknown[185.234.219.227]
Jan 3 03:55:33 server postfix/smtpd[29681]: Anonymous TLS connection established from unknown[185.234.219.228]: TLSv1.2 with cipher AES128-SHA256 (128/128 bits)
Jan 3 03:55:33 server postfix/smtpd[29705]: Anonymous TLS connection established from unknown[185.234.219.227]: TLSv1.2 with cipher AES128-SHA256 (128/128 bits)
Jan 3 03:55:33 server postfix/smtpd[29706]: connect from unknown[193.169.253.56]
Jan 3 03:55:34 server postfix/smtpd[29706]: lost connection after AUTH from unknown[193.169.253.56]
Jan 3 03:55:34 server postfix/smtpd[29706]: disconnect from unknown[193.169.253.56]
Jan 3 03:55:35 server postfix/smtpd[29681]: warning: unknown[185.234.219.228]: SASL LOGIN authentication failed: authentication failure
Jan 3 03:55:36 server postfix/smtpd[29705]: warning: unknown[185.234.219.227]: SASL LOGIN authentication failed: authentication failure
Jan 3 03:55:36 server postfix/smtpd[29681]: disconnect from unknown[185.234.219.228]
Jan 3 03:55:36 server postfix/smtpd[29705]: disconnect from unknown[185.234.219.227]
fail2ban.log
2021-01-03 03:55:19,028 fail2ban.filter [27748]: INFO [postfix-sasl] Found 185.234.219.229 - 2021-01-03 03:55:18
2021-01-03 03:55:34,458 fail2ban.filter [27748]: INFO [postfix-auth] Found 193.169.253.56 - 2021-01-03 03:55:34
2021-01-03 03:55:34,728 fail2ban.actions [27748]: WARNING [postfix-auth] 193.169.253.56 already banned
2021-01-03 03:55:36,474 fail2ban.filter [27748]: INFO [postfix-sasl] Found 185.234.219.228 - 2021-01-03 03:55:35
2021-01-03 03:55:36,475 fail2ban.filter [27748]: INFO [postfix-sasl] Found 185.234.219.227 - 2021-01-03 03:55
I've had some difficulties googling for how to setup and tune jails. the fail2ban developer wiki is interesting but doesn't have many examples so it's a challenge to figure out what I might need or do. Is there a resource that you can recommend? -
Accepted Answer
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »