On 02/21/2013 04:30 AM, James Hogarth wrote: > On 21 February 2013 01:28, Robert Moskowitz <rgm at htt-consult.com> wrote: > >> It looks like no system, internal or external could access the DNS on my >> new server. IPTABLES was set for 53 both UDP and TCP. Firewall was OK. >> In fact a local system on the same subnet, thus NOT going through my >> firewall was denied access to the internal domain. Localhost of course >> works. >> >> So it is either the Linux firewall and bind port randomization, or it is >> SELINUX. How do I test to find out which? >> >> Since the new server is on the same IP address as the old, it is >> unplugged from the switch. I can switch back and forth between to two >> boxes, only taking the time for ARP table updates. >> >> So I hope someone can point me to what I have missed. >> > audit2allow -a will tell you if it's selinux ... and specifically what is > wrong... Great. I have to make notes on how to test about selinux reporting. > A quick test would be getenforce Permissive and restarting bind ... I assume that 'getenforce permissive' is a command I can use to change selinux behaviour without rebooting? I basically ran out of time yesterday, and had to get the network up and running. Though over on the bind-user list, I was showed that the meaning of allow-query has changed and that might be my problem. > Incidentally what do you mean by bind port randomization? DNS needs to be > on port 53 as the dest port and iptables rules should not be taking a > source port from systems into account... Nasty DNS attack on static port 53. Now bind will select 4096 high ports to use as its source port on responses. So the query comes in with a destination port of 53 with the client using port 53 (as I recall), but the response goes back with bind using a random source port, not 53. I think I have Kaminsky's (sp!) spoofing attack properly summarized. Cricket Liu was in town last week for a company dog-n-pony and he covered this. This kind of thing I deal with regularly in my job, but right now I am tired and probably confusing this attack with two others that bind has recently had to dodge around.