Results 1 to 6 of 6
Hello, I was trying to modify /etc/hosts.deny on CentOS5 to block China and various other IP ranges. After I put in the changes though, the CPU usage climbed to 30.0 ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 06-06-2012 #1Just Joined!
- Join Date
- Jun 2012
- Location
- New York
- Posts
- 3
CentOS5 high CPU usage after modifying hosts.deny
Hello, I was trying to modify /etc/hosts.deny on CentOS5 to block China and various other IP ranges. After I put in the changes though, the CPU usage climbed to 30.0 on my dual core server. There were about 10 sendmail instances all using high CPU, and also the sshd instances went to high CPU usage. In fact, I couldn't even log in remotely by sshd, it just wouldn't respond, I had to use the serial recovery console.
Is that just too much processing required for hosts.deny in this case? Or is my file messed up somehow? The file is pretty long so here is a link porcupine73.com/files/hosts.deny.txt (when I click manage attachments here I just get a blank window).
I really want to block these IP ranges since I'm getting slammed with spam and hacking attempts from some of them. My host allows rules to be entered into a Cisco firewall but with their interface it would take me years to enter all those.
Trying to put them into iptables makes me nervous. Maybe I should just block them in the Apache httpd configuration? At least that would block the spammers. Thanks.
- 06-06-2012 #2
You should block these IPs early, userspace might take too many resources.
Best via the cisco firewall,
but iptables on the server might also work.
The iptables commands should be pretty easy, as you essentially just drop any connection from the listed sources.
One approach might be to write a small perly/python/ruby script to process your existing hosts.deny list:
- parse it
- filter for shadowed IPs/networks: (e.g.: if 1.2.0.0/16 would be blocked, then there is no need for a rule for 1.2.3.0/8 )
- remove whitelisted IPs/networks (e.g.: your own networks would be in there, so that you never block yourself)
- output valid iptables commandsYou must always face the curtain with a bow.
- 06-06-2012 #3Just Joined!
- Join Date
- Jun 2012
- Location
- New York
- Posts
- 3
Thank you for the information. After thinking about it, I think the next thing I will try is making them into rules for the Apache httpd config. I do have the Cisco firewalls set up to allow only me ssh access, and port 80 access to everyone. So web requests is pretty much the only thing the rest of the world can try. Hopefully that won't slow down httpd too much but I test it out anyway. I would like to enter all those rules into the Cisco tables, but my host's interface forces you to enter each on by hand and click save, they won't let you import any lists.
- 06-06-2012 #4
Apache is also in userspace..
From the information given, I -again- would suggest to block at kernellevel (iptables) or even before on the cisco.You must always face the curtain with a bow.
- 06-06-2012 #5Just Joined!
- Join Date
- Jun 2012
- Location
- New York
- Posts
- 3
Great, thanks again. I did like you said about making a script to write it into an iptables script. That seems to be working fine. No noticeable increase in CPU or memory usage. So that looks good. Thanks!
I would have liked to made it into Cisco rules but like I say the host doesn't allow uploading those to the Cisco. They have this web interface where I'd have to enter each one individually and click save. That would take weeks to complete probably.
- 09-15-2012 #6Just Joined!
- Join Date
- Sep 2012
- Posts
- 1
We are seeing a high CPU hit on sshd after multiple failed login attempts. We have sniffed the network and can see no active connections but up to 10 sshd sessions get initiated before it starts refusing connections. The first one goes to 99% processor utilization and each successive instance cuts that in half (50%/50%, then 33%/33%/33%, then 25%/25%/25%/25%). The load never exceeds one.
The mac OSX had a similar problem about 3-4 years ago, and so I was investigating that. Yes, if you have a physical firewall, great, but not everyone does and this particular customer of ours does not. It' might be related to hosts.deny, but we are not sure. If we manually kill the 8-10 sshd processes everything returns to normal until the next login attempt.
We are still investigating.
David


Reply With Quote
