Firewall questions I promised you.

[Rick Stevens]

Bruce McDonald wrote:
> Hello Rick

Hi.

[snip]

>>>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!"
> 
> 
> The script is based on the one in the Linux Firewalls 2nd edition which
> covers a lot and is commented.  There are at least 10 user chains created
> to streamline the number of rules checked for a packet.  Granted, it is
> really only needed for a busy router, but I wouldn't mind the help for my
> processor.

I just think it's a bit of overkill for a normal box.  If you're a
router, these would be appropriate.

> The author of the book also takes the block everything and allow only what
> you want or need, which probably takes more rules.  He also likes to
> specifically state trusted computers if you can.

"block all" is the best thing to do and yes, if you use a lot of
services, punching in the "holes" can be take a lot of rules.  You also
run the risk of hitting a sticking point as you have.

[snip]

>>>###############################################################
>>># DNS Fowarding Name Server or client requests
> 
> 
>>I'm assuming the below is the "remote-dns-server-query" chain.
> 
> 
> Yes
> 
> 
>>>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.
> 
> 
> Another good assumption.
> 
> 
>>># 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.
> 
> 
> Connection tracking would be for the caching name server requests over tcp,
> I think.

And that's fine if you're doing stuff like zone transfers or DDNS for
DHCP.  However, in the listings you've posted you have no "-j ACCEPT"
for DNS over UDP and that's what's blocking your DNS.  95% of all DNS
traffic is UDP.

>>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.
> 
> 
> 
> Thank you for your assistance and guidance, it is much appreciated.

No problem.  The trick is to keep in mind what services use TCP and
which use UDP.  In the DNS case, it uses both: forward and reverse
lookups are done via UDP, zone transfers and updates for dynamic DNS
are done via TCP.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-        Brain:  The organ with which we think that we think.        -
----------------------------------------------------------------------