We have a Centos 6 VPS that was recently migrated to a new machine within the same web hosting company. It's running WHM/cPanel and has csf/lfd installed. csf is set up with mostly vanilla config. I'm no iptables expert, csf has not let me down before. If a port isn't in the TCP_IN list, it should be blocked on the firewall by iptables.

My problem is that I can telnet to port 3306 from an external host, yet I think iptables ought to be blocking 3306 because of csf's rules. We are now failing a security check because of this open port. (this output is obfuscated to protect the innocent: www.ourhost.com is the host with the firewall problem)

[root@nickfenwick log]# telnet www.ourhost.com 3306
Trying 158.255.45.107...
Connected to www.ourhost.com.
Escape character is '^]'.
HHost 'nickfenwick.com' is not allowed to connect to this MySQL serverConnection closed by foreign host.

So the connection is established, and MySQL refuses the connection due to its configuration. I need the network connection to be refused at the firewall level, before it reaches MySQL.

Using WHM's csf web UI I can see 'Firewall Configuration' includes a fairly sensible TCP_IN line:

1 Answer
1

I am not sure what the LOGDROPIN or acctboth are defining, but here is how I would go about it.

If you don't need MySQL to accept remote connections, I would first change the MySQL configuration to bind to 127.0.0.1 rather than 0.0.0.0 or your IP address. This will limit all mysql access to local host, and I believe is the default for new MySQL installations. (This does not answer your IPTABLES question, but should probably be done anyway.)

To trace your IPTABLES problem, I would suggest using IPTABLES TRACE functionality which will tell you exactly which rules are being traversed. There is a nifty packet flow diagram. From this you can see that the raw table has built-in OUTPUT and PREROUTING chains. This also assumes that you are using a > 2.6.23 kernel, or have compiled your own with the appropriate options.

to have the kernel to trace the mysql connections. You should be able to see which specific rules the packets traversed in the logs. If this box already has traffic across this port, you might want to also filter for your ip address in the above rules to show less noise.

Thanks jpgeek, I followed your directions and made some progress, but ultimately the output was too confusing and I'm not paid for this work, I'm paid to make our PCI scan pass :) To resolve our issue, I created a rule at the top of our INPUT chain (-I to Insert rather than -A to Append) iptables -I INPUT -p tcp --dport 3306 -j DROP .. this closed the port and our PCI scan passed. I wish I had the time to investigate more properly, and might come back to this if something else falls over or (quite likely) csf overwrites the rules at some point.
– NeekNov 9 '12 at 3:08