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
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:

TCP_IN: 20,21,22,25,53,80,110,143,222,443,465,587,993,995,2077,2078,2082,2083,2086,2087,2095,2096,8080

(lets ignore that I could trim that a little for now, my concern is that 3306 is not listed in that list)

When csf is restarted it logs the usual slew of output as it sets up iptables rules, for example what looks like it blocking all traffic and then allowing specific ports like SSH on 22:

DROP  all opt -- in * out *  ->  
ACCEPT  tcp opt -- in !lo out *  ->  state NEW tcp dpt:22 

I can see that iptables is running, service iptables status returns a long list of firewall rules.

Here is my Chain INPUT section from service iptables status, hopefully that's enough to show how the firewall is configured.

Table: filter
Chain INPUT (policy DROP)
num  target     prot opt source               destination         
1    acctboth   all  --             
2    ACCEPT     tcp  --           tcp dpt:53 
3    ACCEPT     udp  --           udp dpt:53 
4    ACCEPT     tcp  --           tcp spt:53 
5    ACCEPT     udp  --           udp spt:53 
6    ACCEPT     tcp  --               tcp dpt:53 
7    ACCEPT     udp  --               udp dpt:53 
8    ACCEPT     tcp  --               tcp spt:53 
9    ACCEPT     udp  --               udp spt:53 
10   ACCEPT     tcp  --               tcp dpt:53 
11   ACCEPT     udp  --               udp dpt:53 
12   ACCEPT     tcp  --               tcp spt:53 
13   ACCEPT     udp  --               udp spt:53 
14   LOCALINPUT  all  --             
15   ACCEPT     all  --             
16   INVALID    tcp  --             
17   ACCEPT     all  --             state RELATED,ESTABLISHED 
18   ACCEPT     tcp  --             state NEW tcp dpt:20 
19   ACCEPT     tcp  --             state NEW tcp dpt:21 
20   ACCEPT     tcp  --             state NEW tcp dpt:22 
21   ACCEPT     tcp  --             state NEW tcp dpt:25 
22   ACCEPT     tcp  --             state NEW tcp dpt:53 
23   ACCEPT     tcp  --             state NEW tcp dpt:80 
24   ACCEPT     tcp  --             state NEW tcp dpt:110 
25   ACCEPT     tcp  --             state NEW tcp dpt:143 
26   ACCEPT     tcp  --             state NEW tcp dpt:222 
27   ACCEPT     tcp  --             state NEW tcp dpt:443 
28   ACCEPT     tcp  --             state NEW tcp dpt:465 
29   ACCEPT     tcp  --             state NEW tcp dpt:587 
30   ACCEPT     tcp  --             state NEW tcp dpt:993 
31   ACCEPT     tcp  --             state NEW tcp dpt:995 
32   ACCEPT     tcp  --             state NEW tcp dpt:2077 
33   ACCEPT     tcp  --             state NEW tcp dpt:2078 
34   ACCEPT     tcp  --             state NEW tcp dpt:2082 
35   ACCEPT     tcp  --             state NEW tcp dpt:2083 
36   ACCEPT     tcp  --             state NEW tcp dpt:2086 
37   ACCEPT     tcp  --             state NEW tcp dpt:2087 
38   ACCEPT     tcp  --             state NEW tcp dpt:2095 
39   ACCEPT     tcp  --             state NEW tcp dpt:2096 
40   ACCEPT     tcp  --             state NEW tcp dpt:8080 
41   ACCEPT     udp  --             state NEW udp dpt:20 
42   ACCEPT     udp  --             state NEW udp dpt:21 
43   ACCEPT     udp  --             state NEW udp dpt:53 
44   ACCEPT     udp  --             state NEW udp dpt:222 
45   ACCEPT     udp  --             state NEW udp dpt:8080 
46   ACCEPT     icmp --             icmp type 8 
47   ACCEPT     icmp --             icmp type 0 
48   ACCEPT     icmp --             icmp type 11 
49   ACCEPT     icmp --             icmp type 3 
50   LOGDROPIN  all  --             

What's the next thing to check?

closed as off-topic by Michael Hampton Dec 23 '18 at 19:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.


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

  1. If you don't need MySQL to accept remote connections, I would first change the MySQL configuration to bind to rather than 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.)

  2. 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.

You would add something like:

iptables -t raw -A OUTPUT -p tcp --dport 3306 -j TRACE
iptables -t raw -A PREROUTING -p --dport 3306 tcp  -j TRACE

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.

Also, here is an excellent post on tracing iptables.

Hope this helps!

  • 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. – Neek Nov 9 '12 at 3:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.