A new and improved instance of onlo.htt-consult.com is up and providing DNS service. It is my 1st Centos 6.3 production box.
This is Phase I which included IPv6 working 'right'. Phase II will be to sign my zone and get fully with DNSSEC.
I want to thank people here in answering my questions.
Now on to other projects. I have a couple dozen to tackle.
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.
On 02/20/2013 02:13 PM, Robert Moskowitz wrote:
A new and improved instance of onlo.htt-consult.com is up and providing DNS service. It is my 1st Centos 6.3 production box.
This is Phase I which included IPv6 working 'right'. Phase II will be to sign my zone and get fully with DNSSEC.
I want to thank people here in answering my questions.
Now on to other projects. I have a couple dozen to tackle.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
How about checking logs ?
Eero
On Thursday, February 21, 2013, Robert Moskowitz 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.
On 02/20/2013 02:13 PM, Robert Moskowitz wrote:
A new and improved instance of onlo.htt-consult.com is up and providing DNS service. It is my 1st Centos 6.3 production box.
This is Phase I which included IPv6 working 'right'. Phase II will be to sign my zone and get fully with DNSSEC.
I want to thank people here in answering my questions.
Now on to other projects. I have a couple dozen to tackle.
CentOS mailing list CentOS@centos.org javascript:; http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org javascript:; http://lists.centos.org/mailman/listinfo/centos
On 21 February 2013 01:28, Robert Moskowitz rgm@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...
A quick test would be getenforce Permissive and restarting bind ...
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...
On 02/21/2013 04:30 AM, James Hogarth wrote:
On 21 February 2013 01:28, Robert Moskowitz rgm@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.
Great. I have to make notes on how to test about selinux reporting.
audit2allow is useful to generate custom modules etc too - just don't be to blind in using them ;)
other useful things are semange boolean and so on - centos has a good wiki page on selinux
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.
Apologies on the typo - I was in a hurry ... getenforce will tell you the current status of selinux... setenforce to change it
If you aren't placing things in odd locations (and expecially if not using chroot) I'd expect no selinux errors though and more likely a bind config error
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.
I know what you're talking about now... needed coffee to remind myself... but unless you are limiting iptables on the OUTPUT chain it shouldn't be an issue...
On Thursday 21 February 2013 11:25:44 Robert Moskowitz wrote:
On 02/21/2013 04:30 AM, James Hogarth wrote:
On 21 February 2013 01:28, Robert Moskowitz rgm@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 ...
Hi,
setenforce 0 sets SELinux to permissive setenforce 1 sets it to enmforcing sestatus to check the current status
You can use the following to build a custom SElinux module
# Generate local policy grep http /var/log/audit/audit.log | audit2allow -m myhttp > myhttp.te
# could also use grep http to just get the http AVC
# Compile the module checkmodule -M -m -o local.mod myhttp.te
# Create the package semodule_package -o myhttp.pp -m local.mod
# Load the module into the kernel semodule -i myhttp.pp
Tony
On 02/20/2013 08:28 PM, Robert Moskowitz 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.
In 9.4.1.P1 the allow-query default was changed to localhost; localnet, and I had my own name for the acl for my localnets so I was locking everything out. What tripped me up was the default named.conf had allow-query {localhost;} and I took that to mean that the default was any, not that this blocked out localnet. Sigh. Panic over and back to running with the new box. But that old box will be kept running for the next week.
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.
On 02/20/2013 02:13 PM, Robert Moskowitz wrote:
A new and improved instance of onlo.htt-consult.com is up and providing DNS service. It is my 1st Centos 6.3 production box.
This is Phase I which included IPv6 working 'right'. Phase II will be to sign my zone and get fully with DNSSEC.
I want to thank people here in answering my questions.
Now on to other projects. I have a couple dozen to tackle.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Moskowitz <rgm@...> writes:
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.
<SNIP> Not sure what you mean be "Localhost of course works." Are you using:
dig @localhost any mysubdom.mydom.com
to see if the DNS server is responding?
If not, try dig on your DNS both using @localhost, @int.ernal.ip.addr and @ext.ernal.ip.addr and then try it from other systems on your network.
The first thing to do is to make sure the DNS server responds correctly to queries.
Cheers, Dave
On 02/21/2013 10:16 AM, David G. Miller wrote:
Robert Moskowitz <rgm@...> writes:
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.
<SNIP> Not sure what you mean be "Localhost of course works." Are you using:
dig @localhost any mysubdom.mydom.com
to see if the DNS server is responding?
If not, try dig on your DNS both using @localhost, @int.ernal.ip.addr and @ext.ernal.ip.addr and then try it from other systems on your network.
The first thing to do is to make sure the DNS server responds correctly to queries.
All solved with adding allow-query.
-
David G. Miller -
Eero Volotinen -
James Hogarth -
Robert Moskowitz -
Tony Molloy