Whilst observing a WHM/cPanel’s log file using
tail -f /var/log/messages you might observe 1000s of events, sometimes every few seconds, similar to the following:
Oct 21 11:30:42 mail kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=0c:c4:7a:77:23:56:74:8e:f8:22:9e:00:08:00 SRC=188.8.131.52 DST=x.y.z.a LEN=40 TOS=0x00 PREC=0x00 TTL=240 ID=34550 PROTO=TCP SPT=32767 DPT=18081 WINDOW=1024 RES=0x00 SYN URGP=0
Oct 21 11:30:43 mail kernel: Firewall: *TCP_IN Blocked* IN=eno1 OUT= MAC=0c:c4:7a:77:23:56:74:8e:f8:22:9e:00:08:00 SRC=184.108.40.206 DST=x.y.z.a LEN=52 TOS=0x00 PREC=0x00 TTL=111 ID=40333 DF PROTO=TCP SPT=56754 DPT=14372 WINDOW=64240 RES=0x00 SYN URGP=0
What’s happening is although you probably have your entire system protected under the
csf firewall, failed attacks are being logged. In the examples above script kiddies are trying to enter
DPT destination port
These messages become useless if your log files are overrun with them.
A Paranoid DROP_NOLOG Configuration
CSF makes provision for not logging dropped packets. The default
/etc/csf/csf.conf file even has this comment and a few default ports that are not logged:
# Commonly blocked ports that you do not want logging as they tend to just fill # up the log file. These ports are specifically blocked (applied to TCP and UDP # protocols) for incoming connections DROP_NOLOG = "23,67,68,111,113,135:139,445,500,513,520"
However, on a busy server, the above list is hopelessly inadequate. The solution is to block everything, except of course, the ports that your cPanel need to operate. If you follow the procedure below, be extra mindful that you do not inadvertently exclude the custom SSH port that you have chosen!
WARNING: Do not attempt this procedure if you don’t know your SSH port.
The above list was compiled by using the official firewall reference document listed below. If you have a more specific configuration where you do not allow all the ports as per the reference, then you can exclude even more. The tricky part of compiling the above list is that WHM hasn’t compiled their list in perfect numerical order, they threw a
2703 in there.
Once you’re happy with your DROP_NOLOG configuration, remember to do
How to Configure Your Firewall for cPanel Services
1 thought on “Excessive logging of TCP_IN Blocked messages on a WHM server”
Please bear in mind the note above the DROP_LOGGING On/Off option in the CSF Firewall Configuration web interface:
Enable logging of dropped connections to blocked ports to syslog, usually
/var/log/messages. This option needs to be enabled to use Port Scan Tracking
So it seems that preventing logging of these failed attempts will defeat its port scanning prevention, I’m guessing it uses the logfile contents to detect multiple failed attempts from an attacked in order to add them to the firewall block list.