LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   iptables blocking port 53 unexpectedly on a dual NIC Fedora install (http://www.linuxquestions.org/questions/linux-security-4/iptables-blocking-port-53-unexpectedly-on-a-dual-nic-fedora-install-804009/)

jbbenni 04-24-2010 06:57 PM

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?

SuperJediWombat! 04-24-2010 08:10 PM

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

iptables -I INPUT -p udp --dport 53 -j ACCEPT
iptables -I OUTPUT -p udp --sport 53 -j ACCEPT

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)

jbbenni 04-25-2010 09:19 AM

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?

SuperJediWombat! 04-26-2010 01:56 AM

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?

jbbenni 04-26-2010 09:01 AM

Very helpful, again. With the rule for port 53 in place, the client timeouts are eliminated. Thank you!

SuperJediWombat! 04-26-2010 07:16 PM

That rule was mostly for debugging, at the moment it is allowing 53 in from your external interface as well.

Can you post this from some of your clients:
Code:

cat /etc/resolve.conf

jbbenni 04-27-2010 07:21 AM

cat /etc/resolv.conf shows this:

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

Make sense?


All times are GMT -5. The time now is 03:29 PM.