fail2ban causing high cpu usage

rcherry
Posts: 62
Member Since:
2007-07-09

From top I can see that fail2ban uses 85% to 98% of cpu. It doesn't drop below 85%. I've closed all ports in iptables except for ICMP responses, DNS responses, if state of connection is related, and if state of connection is established and one UDP port I use for remote management with hamachi. The box is directly on the Internet with no NAT which really isn't an issue because all ports I don't need are blocked including rtp ports and sip. These are established connections by trixbox and so come under the heading of "if state of connection is established".

fail2ban was running and causing no issues until recently when I restarted it after making a change in iptables when I shut down port 80. What would cause fail2ban to use so many cpu cycles?

--

Ronald Cherry



mustardman
Posts: 1289
Member Since:
2006-06-18
It may be trying to write to

It may be trying to write to a file it has no access to. Also check for duplicate iptables entries. There is no check in the fail2ban start script so if you save your iptables config after fail2ban starts it will save the fail2ban entries. The next time you reboot you will have duplicate fail2ban entries in your iptables. I'm looking into a mod of the fail2ban start script to check for duplicates before writing to iptables. Not sure if that would cause high cpu usage though. More likely it's trying to do something it can't. Check your /var/log files for possible clues.



rcherry
Posts: 62
Member Since:
2007-07-09
In jail.conf if I change the

In jail.conf if I change the enabled status of [asterisk-iptables] to false then cpu usage goes back to normal. Haven't figured out why. The logpath is set to /asterisk/full so maybe their is a permissions problem, although why would that just start happening for no reason?

Also in jail.conf there are two entries for ssh, ssh-iptables and ssh-tcpwrappers which report to /var/log/secure. There are recurring entries in /secure every 30 seconds:
Nov 4 10:35:59 trixbox1 sshd[18234]: Did not receive identification string from UNKNOWN
Nov 4 10:36:29 trixbox1 sshd[18269]: Did not receive identification string from UNKNOWN
Nov 4 10:36:59 trixbox1 sshd[18307]: Did not receive identification string from UNKNOWN
Nov 4 10:37:30 trixbox1 sshd[18343]: Did not receive identification string from UNKNOWN
Nov 4 10:38:00 trixbox1 sshd[18381]: Did not receive identification string from UNKNOWN
Nov 4 10:38:30 trixbox1 sshd[18430]: Did not receive identification string from UNKNOWN
Nov 4 10:39:01 trixbox1 sshd[18467]: Did not receive identification string from UNKNOWN
Nov 4 10:39:31 trixbox1 sshd[18509]: Did not receive identification string from UNKNOWN
Nov 4 10:40:02 trixbox1 sshd[18544]: Did not receive identification string from UNKNOWN
Nov 4 10:40:32 trixbox1 sshd[18585]: Did not receive identification string from UNKNOWN

Port 22 is closed in iptables so I don't know why there would be entries there. I use ssh through hamachi for remote admin.

To fix the issue with fail2ban and high cpu usage I created a new file fail2ban_log in /var/log/asterisk/ and since there is no user fail2ban or iptables I made sshd the owner of the file /var/log/asterisk/fail2ban_log. Then changed jail.conf [asterisk-iptables] logpath to reflect the change. This worked but I'm not sure if this is the correct way to fix the problem. When I changed the owner to asterisk, chown asterisk:asterisk fail2ban_log, it made no difference and the cpu usage stayed low. Other processes are writing to /full so why this other problem with fail2ban? To prove the issue I put the logpath back to /var/log/asterisk/full and then restarted fail2ban. Again the cpu usage went to 98% and stayed there. Change the logpath back to /var/log/asterisk/fail2ban_log and cpu usage goes to normal.

--

Ronald Cherry



tyardley
Posts: 209
Member Since:
2007-09-09
More than likely

These entries;
Nov 4 10:39:01 trixbox1 sshd[18467]: Did not receive identification string from UNKNOWN
Nov 4 10:39:31 trixbox1 sshd[18509]: Did not receive identification string from UNKNOWN
Nov 4 10:40:02 trixbox1 sshd[18544]: Did not receive identification string from UNKNOWN
Nov 4 10:40:32 trixbox1 sshd[18585]: Did not receive identification string from UNKNOWN

Are from PBXconfig checking SSH is on. I get these when I change the port from the default to something else. Can't remember which file you have to edit.

Thank you,
Engineer Tim

http://engineertim.com
http://xenforge.org
http://twitter.com/engineertim



rcherry
Posts: 62
Member Since:
2007-07-09
I'm still using the default

I'm still using the default SSH port but through hamachi. Port 22 is closed on the WAN interface.

Which file do I edit to fix this. It is causing problems with fail2ban as the file is read by fail2ban. When the file secure gets too large then fail2ban causes high cpu usage.

Do you mean that pbxconfig.php is checking that SSH is on?

--

Ronald Cherry



rcherry
Posts: 62
Member Since:
2007-07-09
FreePBX scans SSH

Turns out that what was causing the file /var/log/secure to grow so fast is the polling done by FreePBX: http://www.freepbx.org/v2/ticket/3461

If you stay away from the admin page of trixbox where the status of SSH is reported then the file won't grow as fast. Every time FreePBX scans SSH it adds a line to /var/log/secure:
Did not receive identification string from UNKNOWN

--

Ronald Cherry



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.