0

I just installed fail2ban in NetinVM (a constellation of virtual machines inside a VM)

so far so good, I install in a specific machine (10.5.1.13) where ssh is on 2222 (all on root)

From other machine (10.5.1.11) I repetitively ssh to that first one with wrong password.

fail2ban recognise the "attack" and said to ban the ip

fail2ban> status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 1
|  |- Total failed: 20
|  `- File list:    /var/log/auth.log
`- Actions
   |- Currently banned: 2
   |- Total banned: 2
   `- Banned IP list:   10.5.1.11

as I take a look into iptables:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-sshd   tcp  --  anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-sshd (1 references)
target     prot opt source               destination         
REJECT     all  --  dmzb.example.net     anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

this REJECT rule is added, and resolution of dmzb.emaple.net seems proper:

$ ping dmzb.example.net
PING dmzb.example.net (10.5.1.11) 56(84) bytes of data.
64 bytes from dmzb.example.net (10.5.1.11): icmp_seq=1 ttl=64 time=0.940 ms

and resolve the domain added into the iptables correctly to the "attacker" IP

nevertheless, I can still proceed with ssh trials from the "attacker" machine, getting the password request, and even entering if I put correct password.

update: as suggested, tried 

$ iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
f2b-sshd   tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain f2b-sshd (1 references)
target     prot opt source               destination         
REJECT     all  --  10.5.1.11            0.0.0.0/0            reject-with icmp-port-unreachable
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

ip seems the correct one, still, banning is not being applied.

pGrnd2
  • 15
  • 4
  • I'll bet rDNS doesn't round-trip correctly. This is why you should always run `iptables -L -n`. – womble Apr 20 '19 at 23:02
  • it seems to be not the case. 'iptables -L -n' shows the right IP to be banned, but it does not banned it in deed – pGrnd2 Apr 20 '19 at 23:58
  • [Trace the packets through netfilter](https://serverfault.com/questions/122157/debugger-for-iptables), that'll show what's going wrong. – womble Apr 21 '19 at 01:29
  • Better look at ipset storage of fail2ban block list. In this case the iptables rule set won't be changed and all blocked ip addresses will be stored inside ipset list. – Anton Danilov Apr 21 '19 at 08:51
  • thats the trick , as ssh port is manully setup to 2222, fail2ban does not recognize the port properly and it needs to be added manually on the jail.local file under the proper rule – pGrnd2 Apr 21 '19 at 09:32

1 Answers1

1

Inside your rule set you bind the fail2ban checking with port 22, but in the description you have written, that your ssh actually listens the port 2222. To check it start from iptables-save -c or iptables -L -n -v. Check the counters of the corresponded rules. Also, the tcpdump is also very helpful tool in your case.

Anton Danilov
  • 4,874
  • 2
  • 11
  • 20
  • 1
    thats the trick , as ssh port is manully setup to 2222, fail2ban does not recognize the port properly and it needs to be added manually on the jail.local file under the proper rule – pGrnd2 Apr 21 '19 at 09:33