0

Someone keeps trying to login in my dovecot server. I have added a ufw deny rule for a network since he keeps picking different addresses from the same small network, but these deny rules don’t seam to have any effect. It’s only when I specify an IP address that the rule has apparently an effect.

I changed the listening port of the dovecot server, but he finds the new port and keeps trying to login.

The network that I want to filter is 185.211.245.128 - 185.211.245.255.

I have postfix and ssh ports open, but he focus on dovecot.

These are the rules I have set in ufw

Anywhere                   DENY        185.211.245.128/25
Anywhere                   DENY        185.211.245.0/24
Anywhere                   DENY        185.211.245.170
996                        DENY        185.211.245.170
996/tcp                    ALLOW       Anywhere

Only the last deny had effect. I have now connection attempts from another address from this network.

I added the network deny rules with the following command:

# ufw deny from 185.211.245.128/25

Why is ufw not taking these deny rules into account ?

Update 1: I rebooted and got an hour relief, but I get connection attempts again. iptables look correct:

Chain ufw-user-input (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    3   180 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:xxx
   32  1672 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
   19  1092 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   22  1268 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:587
    7   424 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:465
    0     0 DROP       all  --  *      *       141.98.80.16         0.0.0.0/0           
    0     0 DROP       all  --  *      *       5.79.252.176         0.0.0.0/0           
    0     0 DROP       all  --  *      *       5.53.119.178         0.0.0.0/0           
    5   200 DROP       all  --  *      *       185.211.245.128/25   0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.0/24     0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.170      0.0.0.0/0           
    0     0 DROP       tcp  --  *      *       185.211.245.170      0.0.0.0/0            tcp dpt:996
    0     0 DROP       udp  --  *      *       185.211.245.170      0.0.0.0/0            udp dpt:996
    0     0 DROP       all  --  *      *       168.228.151.234      0.0.0.0/0           
    0     0 DROP       all  --  *      *       185.211.245.198      0.0.0.0/0           
   34  2160 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:996

Apparently 5 packets were rejected by rule deny 185.211.245.128/25. But I now have again connections from 185.211.245.170.

This is what I see in auth.log. I rebooted before 12:00.

Feb 18 12:37:28 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:37:31 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:37:58 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 12:38:00 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:12 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:14 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:33 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170
Feb 18 13:11:36 srv01 auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=xxx rhost=185.211.245.170

It looks like iptables is not properly working or could be circumvented.

The dovecot process is listening on 0.0.0.0:996 and :::996.

Update 2: even stranger. Looking in the ufw.log, I see that connection attempts from my home to the server at port 996 were rejected during this night. But I did manage to access my imap server at that same port yesterday evening. Something is really fishy.

Update 3: I had fail2ban running. Since I stopped fail2ban, which result in removing the rules in iptables, no more failed connection attempts are reported in auth.log. It might be fail2ban who generated them, while I thought it was dovecot. In iptables, I see a slowly increasing number of packet drops for rule 185.211.245.128/25. Which is what I expect. It seam that fail2ban interfered with iptables, or just that the logging was incorrect. But after 4 hours, and just after posting this update, I got four new connection attempts.

Update4: I made some progress. The login attempts are blocked when the drop rules are put before all allow rule. It looks as if the attacker benefit from other allow rules to circumvent the deny rule. How this is possible is still unclear. If this interpretation is correct, ufw has a hole which is a security problem !

The deny rules, must apparently come first. I can ensure it myself, but a naive use of ufw could expose the host. I would suggest that ufw always insert the deny rules in front of any allow rules as a precaution measure.

  • which ports is dovecot listening to? You have many -j ACCEPT rules before your -j DROP rules, so it could be hitting those. You should put the DROP ones that don't specify port up above the ACCEPT rules. And your iptables output doesn't show the final drop all rule, so I don't know if that's a problem either. – Peter Feb 18 at 14:14
  • @Peter, I investigated the iptables rules and the drop rule for all is there, after after the allow rules. The rest of iptables is the default for ufw. The relevant part is the one I show above and the rules are in the correct order. The port xxx, is my none-standard ssh port. nmap doesn’t show it, as well as the dovecot port. I stopped fail2ban in case it interfered. – chmike Feb 18 at 14:23
1

Reload the service sudo ufw reload and sudo service iptables restart, Remember to allow ssh if you are on a server.

  • I don’t have a service iptables. I’m running on Debian. – chmike Feb 18 at 9:42
  • ufw reload would do it. nmap ip to inspect the open ports as well – saviour123 Feb 18 at 9:46
  • still not working – chmike Feb 18 at 9:51
  • The rules are in iptables in the right order. I don’t understand. – chmike Feb 18 at 10:06
1

Firstly, UFW is very basic, and I find it quite terrible. It seems to be designed to be very easy, but for some reason, people that design such things think that easy means to confuse you and make it hard to learn anything instead of just doing what you ask even if it means sometimes locking yourself out or blocking off the wrong networks. You should probably use something better, like shorewall.

And second, I suggest whenever you use the vague and limited UFW user interface, also check with iptables -nvL to get a clear and complete description of what the running iptables config actually is. Seeing that output, I'm sure your problem will be clear (if not to you, to me), but not sure if you can then find a UFW command to produce the correct iptables settings (I never troubleshoot UFW that far... I just replace it with shorewall if there is ever any issue at all).

  • Rules look OK. I rebooted, and now it's been an hour without seeing connection attempts. – chmike Feb 18 at 10:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.