[SLL] Good Netfilter/BIND stumper -- more details

[Brad Willson]

Brad Willson wrote:
> Glenn Stone wrote:
>   
>> On Wed, Jan 02, 2008 at 01:13:10PM -0800, Mark D. Foster wrote:
>>   
>>     
>>> Brad Willson wrote:
>>>     
>>>       
>>>> Neither fqdn or dotted quad work for dig...both fail with
>>>>
>>>> ; <<>> DiG 9.4.2 <<>> @ns google.com
>>>> ; (1 server found)
>>>> ;; global options:  printcmd
>>>> ;; connection timed out; no servers could be reached
>>>>
>>>> As for ping -n 64.233.167.99
>>>> PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data.
>>>> 64 bytes from 64.233.167.99: icmp_seq=1 ttl=239 time=50.7 ms
>>>> 64 bytes from 64.233.167.99: icmp_seq=2 ttl=239 time=49.7 ms
>>>> 64 bytes from 64.233.167.99: icmp_seq=3 ttl=239 time=49.7 ms
>>>> 64 bytes from 64.233.167.99: icmp_seq=4 ttl=239 time=49.6 ms
>>>>
>>>> So...my nameserver is broken? (I'm running on 4h of sleep in the past
>>>> many hours)
>>>>
>>>>   
>>>>       
>>>>         
>>> Not necessarily. I'll bet your DNS resolution works fine when you turn
>>> iptables off.
>>> Looking back at your iptables rules...
>>>
>>>     
>>>       
>>>> -A INPUT -j REJECT --reject-with icmp-host-prohibited (at the end of the
>>>> chain followed by COMMIT)
>>>>       
>>>>         
>>> This rule essentially blocks anything not permitted above it, including your DNS replies.
>>> It's a good security practice to  use this "default deny" stance.
>>> Anyway, try adding something like this above that last rule...
>>> -A INPUT -p udp -m udp --source w.x.y.z/32 -j ACCEPT
>>> where w.x.y.z is the ip address of your nameserver.
>>>     
>>>       
>> Better is 
>>
>> -A INPUT -p udp -m udp -s my.name.server.here --sport 53 -d 0/0 -j ACCEPT
>> -A INPUT -p tcp -m tcp -s my.name.server.here --sport 53 -d 0/0 -j ACCEPT
>>
>> Don't allow just anything to come through from the nameserver, that's asking
>> for it.  
>>
>> The other thing one often does is allow any SYN packet from inside, and then
>> allow ESTABLISHED, RELATED; this will let your inside-the-firewall hosts
>> initiate connections but not be servers.  And if you've got the FTP
>> conntrack module loaded, it'll handle that fun and games as well.  
>>
>> -- Glenn
>>   
>>     
> Thank you Glenn and Mark!
>
> Alas, there is still no DNS joy.  I tried both incantations, both with
> the same results....
>
> dig @192.168.3.3
>
> ; <<>> DiG 9.4.2 <<>> @192.168.3.3
> ; (1 server found)
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
>
> And to answer Mark's question, yes there is a
>
> -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 
>
> near the top of the init file.
>
> Mark asked in another email if it was a bridging firewall, it is not. 
> The real<->virtual mappings are handled by ipvsadm as part of
> heartbeat/ldirectord.
>
>   
Argh!!! For the want of a nail!!!!

I just checked out the 'working' nameserver with nmap -sU and lo, the
results mirror the 'non-working' server.  iptables -vnL show all kinds
of traffic in and out of tcp/udp 53. 

Brad

-- 
Brad Willson, Sr. Computer Specialist
UW GeneTests, UW Box: 358735
EM: bwil150n at u.washington.edu
W: 206.221.4674, C: 425.891.2732
http://www.genetests.org