iptables blocking port 53 unexpectedly on a dual NIC Fedora install
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
iptables blocking port 53 unexpectedly on a dual NIC Fedora install
On a Fedora 12 box with two NICs, I am trying to achieve this behavior:
All ports should be open on eth0 (which is on the LAN side)
Only ports 80 and 22 should be open on eth1 (which is the WAN side - although there's some port forwarding magic elsewhere).
Here's my /var/sysconfig/iptables:
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
The symptom is that when I run BIND on this box, LAN clients attempting to access through eth0 (using port 53) get timeouts. However, if I stop iptables, clients succeed as expected.
I thought the line "-A INPUT -i eth0 -j ACCEPT" would accept any an all traffic through eth0. Any ideas what I'm doing wrong, or how to troubleshoot?
You should not use REJECT for all traffic that does not match, as it opens you up for DOS. At least rate-limit it using the rate module.
Try removing the INPUT -j REJECT rule, so iptables should be allowing everything through everywhere and see if you still get the timeouts.
If that doesn't work help enable the rule again and run 'tcpdump -i eth0 port 53' and post the output.
One trick I use when debugging iptables is to make a specific rule what what I think the traffic should match, and then run 'watch' on 'iptables -vnL'. This will give you a realtime update on what rules are matching.
Set up some rules to match for our BIND traffic:
Watch the counters on the left.
watch --interval 0 'iptables -vnL | grep -v "0 0"'
('grep -v' removes any lines that match '0 0' which is an iptables rule with no matches yet. You might not need that unless you have lots of rules)
Last edited by SuperJediWombat!; 04-24-2010 at 08:18 PM.
Thanks, SJW, particularly for the technique to watch which rules are triggering in real time. That's a very slick trick!
I added the rule you suggested to accept udp on port 53 and it triggers correctly. I still have no idea why the rule to accept all input on interface eth0 almost never triggers (I have seen it trigger once, but not in response to anything I did). Any ideas on what's wrong with that rule would be appreciated. I understood the rules are evaluated in order, and the interface check precedes the upd/port-53 check, so why doesn't the interface rule fire?
It will only trigger for new traffic because you have a rule at the top accepting all established/related traffic. So the first packet in a stream from eth0 should match the rule, then all other packets will match established/related.
With the rule accepting port 53 in place, does the DNS still timeout?
nameserver 192.168.1.203 # the LAN address of my BIND server
nameserver 208.67.222.222 # OpenDNS primary DNS
nameserver 208.67.220.220 # OpenDNS secondary DNS
or, on another group of machines, this:
nameserer 192.168.1.254 # The LAN address of my router, also a DHCP server
The DHCP server has the local address (...203) as the primary DNS and has OpenDNS as a secondary.
In order to close 53 to the public, I changed the rule for port 53 to specify the LAN interface (eth0):
-A INPUT -p udp -i eth0 --dport 53 -j ACCEPT
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.