4

I modify my /etc/hosts.allow file as

sshd : 192.168.0.0/255.255.255.0 : allow
sshd : xxx.xxx.xxx.* : allow
sshd : ALL : deny

(where the xxx represent my actual IP address numbers and the wildcard * represents the full range 0-255) then restart sshd and Apache web server. I watch over the following week as IP addresses from foreign countries continue to appear in /etc/csf/csf.deny.

116.31.116.15 # lfd: (sshd) Failed SSH login from 116.31.116.15 (CN/China/-): 5 in the last 300 secs ...

Is my expectation correct that denied IP addresses in the hosts.allow file should not even be presented with a login screen to attempt to login, and thus the entries in the csf.deny log prove my hosts.allow file isn't doing what I want?

Or, am I being misled by the generic error message (5 in the last 300 secs) because in reality those IP addresses have not actually attempted to enter a user and password 5 times?

My goal is prevent non-approved IP addresses from being able to even enter a username and password. How can I tell that I'm achieving this or not?

What should I expect the csf.deny file to show when their IP is in fact denied?

3

csf.deny is used by ConfigServer Firewall, and IPs listed there will not be allowed to connect to the server at all.

If an IP is in csf.deny file, it means it is blocked in the server firewall on all ports, and will not be presented with any login screen on any of the services, as it will never establish connections with the server.

5 in the last 300 seconds, means that they failed the authentication process, which got them blacklisted in CSF. It can be that they inputted wrong credentials, or that they didn't get the login prompt at all, if only SSH keys are allowed.

putting IP in hosts.allow will allow it to connect to the service you specified there, but they still need to enter the correct credentials to connect to the server.

IPs that are not listed as allowed should be presented with following message:

ssh_exchange_identification: Connection closed by remote host

This will, I believe, be treated as failed login if they try to connect to SSH, any they will end up in csf.deny if they hit the failed login limit. They will establish connection to SSH port, but will fail to authenticate themselves due to deny rule, and CSF will see it as failed login.

Better option on blocking SSH for non-listed IPs would be to completely block it in CSF, as described in the end of this post.

In addition to csf.deny, important files are also csf.allow, and csf.ignore.

csf.allow will allow connections from the listed IP on any source port, to any destination port.

csf.ignore will ignore any failed actions from listed IP, it will not be subjected to limits on failed logins, or connections.

you can remove the IP from csf.deny with csf -dr IP and whitelist it in csf.allow with csf -a IP

If you want to completely block SSH for non-preapproved IPs, and want to avoid your csf.deny growing due to failed SSH logins, you can completely block SSH port, 22 if you haven't changed it, by removing it from the TCP_IN line in csf.config.

After you change anything in csf.config, you need to restart CSF with csf -r to reload the config file.

This will block port 22 for all the IPs, except IPs listed in csf.allow.

By removing port 22 from TCP_IN in csf.config, and putting your IPs in csf.allow, you will allow only those IPs to connect to port 22, any other IP will not be presented with any SSH login, but will receive timed out message when trying to connect to SSH.

If you put only the IP in csf.allow, it will be allowed to all ports, but you can specify a single port only with advanced port+ip filtering.

Putting this in csf.allow will allow connections to port 22 from the IP, even if port 22 is not allowed in csf.config.

tcp:in:d=22:s=x.x.x.x
  • Thanks @rAlen, very informative. I had various people attempt to login using the original posting settings and they weren't presented with a login screen. Is that consistent with your understanding, or is it system dependent or other scenario that some folks can attempt to login with name and pwd and others not. Sounds like the csf.allow technique while blocking port 22 in is the right way to go. Will need to study it more. – user46688 Jan 6 '17 at 6:43
  • IPs not allowed should get ssh_exchange_identification: Connection closed by remote host, but will end in csf.deny I believe, I clarified my post further. – rAlen Jan 6 '17 at 6:45
  • Yes, that is what they observed (connection closed by remote host, without being allowed to enter a pwd). But their IP did not appear in csf.deny, even after more than 5 attempts. Which got me wondering why I was seeing other IPs appear in csf.deny. What other scenario could result in that? Wouldn't everyone be presented with the same process and end result? – user46688 Jan 6 '17 at 6: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.