Mysql – Translating IPTables rule to UFW

firewalliptablesMySQLopenswanufw

we are using an Ubuntu 12.04 x64 LTS VPS. Firewall being used is UFW.
I have setup a Varnish + LEMP setup. along with other things, including an Openswan IPSEC VPN from our office to the VPS data center. A second in house Ubuntu box is to act as MySQL slave and fetch data from the VPS through the VPN.

Master's ppp0 is seen as 10.1.2.1 from the slave, they ping etc.

I have done the various required tasks but I can't get the client (slave) MySQL (nor telnet 10.1.2.1 3306) to access the master through the VPN unless I issue this fairly obvious IPTables command:

iptables -A INPUT -s 10.1.2.0/24 -p tcp --dport 3306 -j ACCEPT

I willingly forced the accepted input to come from the last octet.
With this rule everything works just fine!

However I want to translate this command to UFW syntax so to keep everything in one place.

Now I admit being inexperienced with UFW, I prepared rules like:

ufw allow proto tcp from 10.1.2.0/24 port mysql

and 2-3 variations involving specifying 3306 instead of mysql, specifying a target IP (MySQL's my.cnf at the moment is configured as 0.0.0.0) and similar but I just don't seem to be able to replicate the simple iptables rule in a functional way.

Anyone could kindly give me a suggestion that is not to dump UFW?

Thanks in advance.

Best Answer

The command

ufw allow proto tcp from 10.1.2.0/24 port mysql

adds the following to iptables

iptables -L ufw-user-input -vn
Chain ufw-user-input (1 references)
   pkts bytes target   prot opt in    out  source       destination

    0   0     ACCEPT   tcp  --   *     *   10.1.2.0/24  0.0.0.0/0    tcp spt:3306

note the spt this says the source port of the packet needs to be 3306. You need to tell UFW to allow packets with a destination of port 3306.

ufw allow proto tcp from 10.1.2.0/24 to any port mysql

which adds a rule like this

iptables -L ufw-user-input -vn
Chain ufw-user-input (1 references)
   pkts bytes target   prot opt in    out  source       destination

    0   0     ACCEPT   tcp  --   *     *   10.1.2.0/24  0.0.0.0/0    tcp dpt:3306

which will allow packets destined to port 3306 from 10.1.2.0/24.

Related Solutions

Iptables – ftp tls firewalled :(

In Passive mode, when the client wants to get a file from the server or send a file to the server, the FTP server will pick a random port and send that port to the FTP client.

When you're not using encryption, a properly configured firewall (using the ip_conntrack_ftp helper kernel module, which may be what you're missing for non-TLS connections) would "listen in" on the connection and mark these connections as RELATED. With encryption the firewall can't listen in.

The quick and dirty solution to this is to configure the FTP server to choose a small range of ports for passive connections, and then allow access to all of these ports. For instance, in vsftpd:

pasv_min_port=12000
pasv_max_port=12049

Then in iptables:

iptables -A INPUT -p tcp -m tcp -i eth0 --dport 12000:12049 -j ACCEPT

Allowing anyone to access these ports opens one possible exploit: if someone were to be scanning them over and over they might get lucky and be able to "beat" the real user to the data port and grab the file. Ideally your FTP server would check and make sure the connection is coming from the same place as the original connection, but thanks to things like "FXP" (transferring files from one server to another server by convincing one to make an active connection to the other's passive data port) some servers don't check the connection by default. You should check your configuration file and see if there is an option to disable FXP, and use it. (vsftpd calls this "promiscuous" and is disabled by default.)

Iptables ESTABLISHED,RELATED chain problems

Netfilter has dropped the connection from the state table. One of the timeouts in /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_* has expired. I'm guessing it is nf_conntrack_tcp_timeout_last_ack.

Here is a scenario: Your web server sends a final packet with some data and fin set. The client goes comatose for 30 seconds. Netfilter removes the entry from the state table. The client wakes up and sends a fin ack that is not part of a tracked connection anymore.

I see this all the time on web servers. It is client problem.

If you want to verify that you could record the state table (/proc/net/nf_conntrack) and correlate that with the firewall log.

Edit: I had the direction reversed but the concept applies. In this case his server is making outgoing https connections so it is actually the client and the remote web server may be slow to respond.

The rule

/sbin/iptables -A INPUT -p tcp -m state --state NEW --dport 443 -j ACCEPT

has nothing to do with it. It is about DST port 443 and this is SPT 443.

Best Answer

Related Solutions

Iptables – ftp tls firewalled :(

Iptables ESTABLISHED,RELATED chain problems

Related Topic