Firewall questions I promised you.

[Rick Stevens]

Bruce McDonald wrote:
> Hello Rick
> 
> On 07-Jun-04, you wrote:
> 
> 
>>Bruce McDonald wrote:
>>
>>>Hello Rick
>>>
>>>On 01-Jun-04, you wrote:
>>>
>>><snip>
>>>
>>>>>My next error is:
>>>>>iptables v1.2.7a: host/network `yahoo.com' not found
>>>>>Try `iptables -h' or 'iptables --help' for more information.
>>>>>
>>>>>I assume this means the firewall is halting packets to or from my DNS
>>>>>server.  
>>>
>>>
>>>>Yup.
> 
> 
> 
>>>Interestingly, it is only halting packets that originate on the Linux
>>>box. The other boxen are comunicating fine now that I have weeded out the
>>>stupid errors I made.
> 
> 
>>Depends on the default policy for your INPUT chain.  If you're using a
>>a policy of DENY and don't specifically permit "--sport 53", yes, it'll
>>block outgoing DNS requests.
> 
> 
> Default policy for all rules is deny.
> 
> I put in the rule:
> iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
> 
> That got the dns requests working on the Linux box.  The established
> connection state filter allows the request return without a corresponding
> INPUT rule.
> 
> I still wonder about the original rules for DNS traffic...
> 
> 
>>>>>I still have to check a little further into this, I do have rules that
>>>>>are supposed to allow the traffic. I will post them for your input once
>>>>>I figure that I don't see anything at all wrong with them.
>>>
>>>
>>>>It rather depends on how strict you want your firewall to be regarding
>>>>DNS.  Without seeing the entire iptables setup, I can't comment on what
>>>>you want to do.  However, somewhere near the top of your list you should
>>>>have something along the lines of:
>>>
>>>
>>>>   iptables -A INPUT -p udp -port 53 -j ACCEPT
>>>
> 
> Without posting the entire ruleset which is over 14 printed pages...

Ye GODS!  That's a bit excessive, isn't it?  "Just because I'm paranoid
doesn't mean they AREN'T out to get me!"

> Here are the DNS rules:
> (Note:  The output chain tests for illegal packets and common scans before
> passing testing to the user chain EXT-output.  Input does the same and
> passes testing to EXT-input)

Are you afraid of some internal port scanner being used to assault
other people?  Just curious.
> ###############################################################
> # DNS Caching Name Server (query to remote, primary server)
> 
> iptables -A EXT-output -p udp --sport 53 --dport 53 \
>          -j local-dns-server-query
> 
> iptables -A EXT-input -p udp --sport 53 --dport 53 \
>          -j remote-dns-server-response
> 
> # DNS Caching Name Server (query to remote server over TCP)
> 
> iptables -A EXT-output -p tcp \
>          --sport $UNPRIVPORTS --dport 53 \
>          -j local-dns-server-query
> 
> iptables -A EXT-input -p tcp ! --syn \
>          --sport 53 --dport $UNPRIVPORTS \
>          -j remote-dns-server-response
> 
> ###############################################################
> # DNS Fowarding Name Server or client requests

I'm assuming the below is the "remote-dns-server-query" chain.

> if [ "$CONNECTION_TRACKING" = "1" ]; then
>     iptables -A local-dns-server-query \
>              -d $NAMESERVER_1 \
>              -m state --state NEW -j ACCEPT
> 
>     iptables -A local-dns-server-query \
>              -d $NAMESERVER_2 \
>              -m state --state NEW -j ACCEPT
> 
>     iptables -A local-dns-server-query \
>              -d $NAMESERVER_3 \
>              -m state --state NEW -j ACCEPT
> 
>     iptables -A local-dns-server-query \
>              -d $NAMESERVER_4 \
>              -m state --state NEW -j ACCEPT
> fi
> 
> iptables -A local-dns-server-query \
>          -d $NAMESERVER_1 -j ACCEPT
> 
> iptables -A local-dns-server-query \
>          -d $NAMESERVER_2 -j ACCEPT
> 
> iptables -A local-dns-server-query \
>          -d $NAMESERVER_3 -j ACCEPT
> 
> iptables -A local-dns-server-query \
>          -d $NAMESERVER_4 -j ACCEPT
> 

And I'm assuming the below is the "remote-dns-server-response" chain.

> # DNS server responses to local requests
> 
> iptables -A remote-dns-server-response \
>          -s $NAMESERVER_1 -j ACCEPT
> 
> iptables -A remote-dns-server-response \
>          -s $NAMESERVER_2 -j ACCEPT
> 
> iptables -A remote-dns-server-response \
>          -s $NAMESERVER_3 -j ACCEPT
> 
> iptables -A remote-dns-server-response \
>          -s $NAMESERVER_4 -j ACCEPT
> 
> 
> ----------------------------------------
> 
> $NAMESERVER_1 is 207.69.188.185
> $NAMESERVER_1 is 207.69.188.186
> $NAMESERVER_1 is 64.105.132.250
> $NAMESERVER_1 is 64.1056.166.122
> $UNPRIVPORTS is 1024:65535
> 
> 
> Do you see anything in these rules that would not let the DNS packets
> through the firewall, or do you still need the whole script to tell?

I suspect I see what the problem is.  You can't do connection tracking
on UDP sessions as there is no session per se.  UDP, by definition, is
"connectionless".  You put out a request and, hopefully, you get a
response.  If not, you move on.  My guess is that the
"remote-dns-server-query" chain is blocking your stuff.

I'd do something really simple.  If you're paranoid, set the default
policy to DENY for both INPUT and OUTPUT, then, for each nameserver:

     iptables -A INPUT -p udp --dport 53 -s $NAMESERVER_n -j ACCEPT
     iptables -A OUTPUT -p udp --sport 53 -d $NAMESERVER_n -j ACCEPT

That would only permit UDP DNS traffic to and from the specified
nameservers.  Don't bother with tracking them--you can't.

For the less paranoid, set the policy for INPUT to DENY and:

     iptables -A INPUT -p udp --dport 53 -j ACCEPT

Your mileage may vary.  Batteries not included.  Void where prohibited.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-  You know you've landed gear-up when it takes full power to taxi.  -
-                                                -- Chuck Yeager     -
----------------------------------------------------------------------