FYI Travelin' Man 3 and iptables still letting IPs that are not allowed through.

[jeff.h]

So now that I have Travelin' Man 3 installed on all my boxes (thanks for creating that BTW Ward) I am not getting anywhere near the amount of fail2ban notices banning IPs that are trying to do nefarious things over SSH. However, I am still getting notices about IPs that are not in the strict allow list trying to I assume brute force their way in via SSH.

I have removed all carrier entries other than the two that I actually use. I also only have my admin machine's FQDN and two other specific static IPs allowed.

How are attempts from IPs that are not allowed getting past IP tables?

 

[wardmundy]

I'd have to see a sanitized /etc/sysconfig/iptables file to figure that out.

 

[jeff.h]

I should also mention that I did a dns lookup on the FQDNs that I use and none of them resolve to the same IPs that have been getting through.

 

[wardmundy]

jeff.h Everything looked fine in iptables file. Looks like IPtables may not be working at all. Can you post the results of running: iptables -nL

And results of running the command: iptables-restart

 

[jeff.h]

root@XXXXX:~ $ iptables-restart
iptables: Setting chains to policy ACCEPT: nat mangle filte[ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
iptables: Applying firewall rules: [ OK ]
No IPtables problems found.

 

[jeff.h]

I believe that it is working to a point because I was unable to reach the pbx gui, webmin or SSH from an IP outside the whitelist.

 

[wardmundy]

Just curious. Can you access SSH from a friend's remote computer and get in, too??

 

[jeff.h]

I cannot.

 

[wardmundy]

Then it's got to have a match on the remote IP address in some way. Sorry. That's the best I can do.

 

[jeff.h]

Is it possible that its getting hit so fast that iptables can't keep up?

 

[wardmundy]

Nope. Until there's a match, the traffic doesn't get in. It is not a table scan like fail2ban.

 

[jeff.h]

Hmmmm... I wonder if it's somehow spoofing an IP from one of the carriers to get past iptables. But, if it did that, how would it appear as a different IP to the system when trying to SSH and ultimately get banned by fail2ban?

I use Flowroute and DID Logic so I am sure their IPs are public enough. I could try eliminating their entries from the table one at a time and see when it stops.

 

[wardmundy]

Are you using a block of IP addresses perhaps?? Only other way I would think this could happen is if someone inside a company had network admin privs to manipulate addresses.

 

[jeff.h]

Nope. Just single IPs and they are in entirely different IP ranges (different class As too) from what is making it through to fail2ban.

 

[Hyksos]

Based on the little info you have posted it's impossible to know what is going, if something is going on.

It could be that fail2ban is processing old ssh logs dating back to when you didn't have such a strict iptables ruleset.
You should clear the logs, clear fail2ban and then see for yourself if your ssh log still logs entries that should not get through iptables.

 

[jeff.h]

Ok. So.. in /var/log/fail2ban.log I see....

2014-02-20 03:06:35,068 fail2ban.actions: WARNING [ssh-iptables] Ban 178.18.17.115
2014-02-20 03:06:35,885 fail2ban.actions: WARNING [ssh-iptables] Ban 61.147.113.77

but in /var/log/secure there are no entries for anything anywhere near the same time.

Feb 19 22:56:02 XXXX sshd[2751]: pam_unix(sshd:session): session closed for user root
Feb 20 07:41:19 XXXX sshd[3093]: Did not receive identification string from ::1