OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
TIA
John Hinton
John Hinton wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
how do you mean?
opening port 53 in is still enough ... the outbound port is what is randomized
not sure what kind of problems you are encountering
Johnny Hughes wrote:
John Hinton wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
how do you mean?
opening port 53 in is still enough ... the outbound port is what is randomized
not sure what kind of problems you are encountering
I'm trying to pass the test on DNSstuff.com.
These are my firewall rules for bind
Accept If protocol is TCP and destination port is 53 and state of connection is NEW Accept If protocol is UDP and destination port is 53 and state of connection is NEW
from my gui or
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT
from iptables.
I have upgraded bind, but when I remove this line from a config file, bind will not restart.
query-source address * port 53;
From what I read, the above line is supposed to be removed. My tests from outside states that I am vulnerable to cache injections.
"*Based on the results, a DNS server is vulnerable if:* The IPs /AND/ the Query source ports match or the query IDs match. Matching query source ports or query IDs make it easier to spoof fake results to the DNS server, poisoning its cache."
The IDs in the testing change, but the port stays the same.
I read where the firewall rules need to be fixed due to this change, but firewalls have never been my strong point. I have a pretty darned good understanding of bind..... but firewalls, not so much.
John
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
John Hinton wrote:
Johnny Hughes wrote:
John Hinton wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
how do you mean?
opening port 53 in is still enough ... the outbound port is what is randomized
not sure what kind of problems you are encountering
I'm trying to pass the test on DNSstuff.com.
These are my firewall rules for bind
Accept If protocol is TCP and destination port is 53 and state of connection is NEW Accept If protocol is UDP and destination port is 53 and state of connection is NEW
from my gui or
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT
from iptables.
I have upgraded bind, but when I remove this line from a config file, bind will not restart.
query-source address * port 53;
From what I read, the above line is supposed to be removed. My tests from outside states that I am vulnerable to cache injections.
"*Based on the results, a DNS server is vulnerable if:* The IPs /AND/ the Query source ports match or the query IDs match. Matching query source ports or query IDs make it easier to spoof fake results to the DNS server, poisoning its cache."
The IDs in the testing change, but the port stays the same.
I read where the firewall rules need to be fixed due to this change, but firewalls have never been my strong point. I have a pretty darned good understanding of bind..... but firewalls, not so much.
John
Do I just ask really hard questions or are my questions just not clear? There has to be others on this list that are running nameservers via CentOS. This seems to be a nasty issue that we who are running bind need to get right.
John Hinton
John Hinton wrote:
Do I just ask really hard questions or are my questions just not clear? There has to be others on this list that are running nameservers via CentOS. This seems to be a nasty issue that we who are running bind need to get right.
And the fix is really stupid for those running name servers behind firewalls.
I can't say I'm an expert on this particular issue but from what I've read it seems like the attack depends on being able to send queries to the name server in question in order to predict the IDs that the system is generating.
The way my DNS is setup at home is that I have 2 "external" name servers that do not allow recursion for domains that they are not responsible for other than for a couple trusted IPs(all of which are local). My main caching name server is internal to my network and cannot be directly queried from the internet. As such I think my exposure is pretty low. All of my name servers are setup to force their source port to be 53, I really really don't like the idea of opening up tens of thousands of ports back to my name servers.
So I suspect, if your caching name servers are only vulnerable if they can be sent queries from the attacker. If your internal network is trusted then I think your fairly safe as long as you don't allow access to the caching name servers externally. And of course run dedicated name servers for authoritative hosting.
I plan to have a similar setup at my company, the external authoritative servers are not behind a firewall(F5 Global traffic managers), the internal ones are not accessible outside the network. DNS cache poisoning is the least of my worries if an attacker has access to the internal network.
nate
nate wrote:
John Hinton wrote:
Do I just ask really hard questions or are my questions just not clear? There has to be others on this list that are running nameservers via CentOS. This seems to be a nasty issue that we who are running bind need to get right.
And the fix is really stupid for those running name servers behind firewalls.
I can't say I'm an expert on this particular issue but from what I've read it seems like the attack depends on being able to send queries to the name server in question in order to predict the IDs that the system is generating.
The way my DNS is setup at home is that I have 2 "external" name servers that do not allow recursion for domains that they are not responsible for other than for a couple trusted IPs(all of which are local). My main caching name server is internal to my network and cannot be directly queried from the internet. As such I think my exposure is pretty low. All of my name servers are setup to force their source port to be 53, I really really don't like the idea of opening up tens of thousands of ports back to my name servers.
So I suspect, if your caching name servers are only vulnerable if they can be sent queries from the attacker. If your internal network is trusted then I think your fairly safe as long as you don't allow access to the caching name servers externally. And of course run dedicated name servers for authoritative hosting.
I plan to have a similar setup at my company, the external authoritative servers are not behind a firewall(F5 Global traffic managers), the internal ones are not accessible outside the network. DNS cache poisoning is the least of my worries if an attacker has access to the internal network.
nate
I'm running caching nameservers on almost all of my systems and then also three nameservers. All are available publicly. I too had hard coded bind to port 53. I also had specifically opened port 53 through the firewall. But now, it appears that using only port 53 is a bad thing. From what I read, both the port and the ID need to change to be secure (even this is just security through obscurity). It's sounding like I'll need to open a port range, but I don't know what a 'good practice' will be.
I read through the redhat notes, googled and read all over the place. All I seem to find is to remove the named.conf line that forces bind through port 53 and then statements like 'your firewall will need to be adjusted accordingly', with no good suggestions for how to do this.
So, I'm faced with turning off the firewall to show good external testing on bind.... sort of like unlocking every window and door to a house, in order try to keep someone from trying to open just one.
John Hinton
Correct me if I'm wrong but from my understanding doesn't the new BIND randomize outgoing source ports only? - If so then if you have your firewall to allow established connections you should be all set.
P.A > -----Original Message----- P.A > From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On P.A > Behalf Of John Hinton P.A > Sent: Wednesday, July 23, 2008 12:41 PM P.A > To: CentOS mailing list P.A > Subject: Re: [CentOS] Bind Firewall Rules P.A > P.A > nate wrote: P.A > > John Hinton wrote: P.A > > P.A > >> Do I just ask really hard questions or are my questions just not P.A > clear? P.A > >> There has to be others on this list that are running nameservers P.A > via P.A > >> CentOS. This seems to be a nasty issue that we who are running bind P.A > need P.A > >> to get right. P.A > >> P.A > > P.A > > And the fix is really stupid for those running name servers behind P.A > firewalls. P.A > > P.A > > I can't say I'm an expert on this particular issue but from what P.A > I've P.A > > read it seems like the attack depends on being able to send queries P.A > to P.A > > the name server in question in order to predict the IDs that the P.A > system P.A > > is generating. P.A > > P.A > > The way my DNS is setup at home is that I have 2 "external" name P.A > servers P.A > > that do not allow recursion for domains that they are not P.A > responsible P.A > > for other than for a couple trusted IPs(all of which are local). My P.A > > main caching name server is internal to my network and cannot be P.A > directly P.A > > queried from the internet. As such I think my exposure is pretty P.A > low. P.A > > All of my name servers are setup to force their source port to be P.A > 53, P.A > > I really really don't like the idea of opening up tens of thousands P.A > of P.A > > ports back to my name servers. P.A > > P.A > > So I suspect, if your caching name servers are only vulnerable if P.A > they P.A > > can be sent queries from the attacker. If your internal network is P.A > > trusted then I think your fairly safe as long as you don't allow P.A > > access to the caching name servers externally. And of course run P.A > > dedicated name servers for authoritative hosting. P.A > > P.A > > I plan to have a similar setup at my company, the external P.A > authoritative P.A > > servers are not behind a firewall(F5 Global traffic managers), the P.A > > internal ones are not accessible outside the network. DNS cache P.A > > poisoning is the least of my worries if an attacker has access to P.A > the P.A > > internal network. P.A > > P.A > > nate P.A > > P.A > > P.A > I'm running caching nameservers on almost all of my systems and then P.A > also three nameservers. All are available publicly. I too had hard P.A > coded P.A > bind to port 53. I also had specifically opened port 53 through the P.A > firewall. But now, it appears that using only port 53 is a bad thing. P.A > From what I read, both the port and the ID need to change to be P.A > secure P.A > (even this is just security through obscurity). It's sounding like P.A > I'll P.A > need to open a port range, but I don't know what a 'good practice' P.A > will be. P.A > P.A > I read through the redhat notes, googled and read all over the place. P.A > All I seem to find is to remove the named.conf line that forces bind P.A > through port 53 and then statements like 'your firewall will need to P.A > be P.A > adjusted accordingly', with no good suggestions for how to do this. P.A > P.A > So, I'm faced with turning off the firewall to show good external P.A > testing on bind.... sort of like unlocking every window and door to a P.A > house, in order try to keep someone from trying to open just one. P.A > P.A > John Hinton P.A > _______________________________________________ P.A > CentOS mailing list P.A > CentOS@centos.org P.A > http://lists.centos.org/mailman/listinfo/centos
Paul A wrote:
Correct me if I'm wrong but from my understanding doesn't the new BIND randomize outgoing source ports only? - If so then if you have your firewall to allow established connections you should be all set.
That's a good point, just tested it out on my firewall, removed the port 53 option from named.conf and restarted bind and can still query it internally and externally for it's authoritative domains.
Perhaps my firewall is just less strict than it used to be(migrated from freebsd to openbsd about a year ago). I don't recall what the ruleset used to look like. I do recall having to enable that option years ago else I couldn't query through the firewall.
Still I think caching name servers should be more protected whenever possible, as this "fix" isn't really a fix it just makes it a bit harder to determine what the id is.
nate
Paul A wrote:
Correct me if I'm wrong but from my understanding doesn't the new BIND randomize outgoing source ports only? - If so then if you have your firewall to allow established connections you should be all set.
Maybe I'm just missing something... I have
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
I'm not very good with firewall rules, but I assume these are the three that are important?
I also read within the named.conf file, lines such as
query-source address * port 53;
need to be removed.
Yet when I remove that line, bind will not restart. This is the only place in my named.conf file where port 53 is referenced.
Testing from the outside world, shows that only port 53 is being used on their returns and I'm getting injection potential warnings. This is from dnsstuff.com. What they say is that both the query source port and the ID need to change. Obviously, I have the query source port set to 53.
Somehow, I need to get past this port issue.
John Hinton
P.A > -----Original Message----- P.A > From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On P.A > Behalf Of John Hinton P.A > Sent: Wednesday, July 23, 2008 12:41 PM P.A > To: CentOS mailing list P.A > Subject: Re: [CentOS] Bind Firewall Rules P.A > P.A > nate wrote: P.A > > John Hinton wrote: P.A > > P.A > >> Do I just ask really hard questions or are my questions just not P.A > clear? P.A > >> There has to be others on this list that are running nameservers P.A > via P.A > >> CentOS. This seems to be a nasty issue that we who are running bind P.A > need P.A > >> to get right. P.A > >> P.A > > P.A > > And the fix is really stupid for those running name servers behind P.A > firewalls. P.A > > P.A > > I can't say I'm an expert on this particular issue but from what P.A > I've P.A > > read it seems like the attack depends on being able to send queries P.A > to P.A > > the name server in question in order to predict the IDs that the P.A > system P.A > > is generating. P.A > > P.A > > The way my DNS is setup at home is that I have 2 "external" name P.A > servers P.A > > that do not allow recursion for domains that they are not P.A > responsible P.A > > for other than for a couple trusted IPs(all of which are local). My P.A > > main caching name server is internal to my network and cannot be P.A > directly P.A > > queried from the internet. As such I think my exposure is pretty P.A > low. P.A > > All of my name servers are setup to force their source port to be P.A > 53, P.A > > I really really don't like the idea of opening up tens of thousands P.A > of P.A > > ports back to my name servers. P.A > > P.A > > So I suspect, if your caching name servers are only vulnerable if P.A > they P.A > > can be sent queries from the attacker. If your internal network is P.A > > trusted then I think your fairly safe as long as you don't allow P.A > > access to the caching name servers externally. And of course run P.A > > dedicated name servers for authoritative hosting. P.A > > P.A > > I plan to have a similar setup at my company, the external P.A > authoritative P.A > > servers are not behind a firewall(F5 Global traffic managers), the P.A > > internal ones are not accessible outside the network. DNS cache P.A > > poisoning is the least of my worries if an attacker has access to P.A > the P.A > > internal network. P.A > > P.A > > nate P.A > > P.A > > P.A > I'm running caching nameservers on almost all of my systems and then P.A > also three nameservers. All are available publicly. I too had hard P.A > coded P.A > bind to port 53. I also had specifically opened port 53 through the P.A > firewall. But now, it appears that using only port 53 is a bad thing. P.A > From what I read, both the port and the ID need to change to be P.A > secure P.A > (even this is just security through obscurity). It's sounding like P.A > I'll P.A > need to open a port range, but I don't know what a 'good practice' P.A > will be. P.A > P.A > I read through the redhat notes, googled and read all over the place. P.A > All I seem to find is to remove the named.conf line that forces bind P.A > through port 53 and then statements like 'your firewall will need to P.A > be P.A > adjusted accordingly', with no good suggestions for how to do this. P.A > P.A > So, I'm faced with turning off the firewall to show good external P.A > testing on bind.... sort of like unlocking every window and door to a P.A > house, in order try to keep someone from trying to open just one. P.A > P.A > John Hinton P.A > _______________________________________________ P.A > CentOS mailing list P.A > CentOS@centos.org P.A > http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John,
Maybe I'm just missing something... I have
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
I'm not very good with firewall rules, but I assume these are the three that are important?
I find shorewall is a fantastic front-end to iptables. Options such as "shorewall safe-restart" - (which prevents the new rules being permanently applied by asking you for confirmation after they've been applied. If you don't respond then it reverts back to the old ruleset).
It's saved me a lot of hassle :)
Regards,
Andy
On Mon, Jul 21, 2008 at 6:37 AM, John Hinton webmaster@ew3d.com wrote:
Johnny Hughes wrote:
John Hinton wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
how do you mean?
opening port 53 in is still enough ... the outbound port is what is randomized
not sure what kind of problems you are encountering
I'm trying to pass the test on DNSstuff.com.
These are my firewall rules for bind
Accept If protocol is TCP and destination port is 53 and state of connection is NEW Accept If protocol is UDP and destination port is 53 and state of connection is NEW
from my gui or
-A RH-Firewall-1-INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT -A RH-Firewall-1-INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT
from iptables.
I have upgraded bind, but when I remove this line from a config file, bind will not restart.
query-source address * port 53;
From what I read, the above line is supposed to be removed. My tests from outside states that I am vulnerable to cache injections.
I don't think your problem is with your firewall.. its with something in the bind configs that is causieng bind not to work without the query-source line. What errors are you seeing?
"*Based on the results, a DNS server is vulnerable if:* The IPs /AND/ the Query source ports match or the query IDs match. Matching query source ports or query IDs make it easier to spoof fake results to the DNS server, poisoning its cache."
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
On Wed, 2008-07-23 at 17:37 -0500, Lanny Marcus wrote:
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
---- always seemed to be a bad idea to me.
If the point is to use a supported/maintained package system like Red Hat or CentOS, security updates are always applied through.
When you go off packaging, you then become responsible for the software from installation to maintenance.
If you're going to use djbdns, why bother using CentOS?
Craig
On Wed, Jul 23, 2008 at 5:59 PM, Craig White craigwhite@azapple.com wrote:
On Wed, 2008-07-23 at 17:37 -0500, Lanny Marcus wrote:
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
always seemed to be a bad idea to me.
If the point is to use a supported/maintained package system like Red Hat or CentOS, security updates are always applied through.
When you go off packaging, you then become responsible for the software from installation to maintenance.
If you're going to use djbdns, why bother using CentOS?
Craig: What you wrote makes a lot of sense! Lanny
On Wed, 2008-07-23 at 17:37 -0500, Lanny Marcus wrote:
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
Having watched that over *many* years, it has had a lot of non-technical issues surrounding it. There still remains a lot of antipathy towards it. I won't detail any of it here, it's available all over the web.
I refused to use it when it first came out and I still find no compelling reason to move to it from well documented and supported packages, even if they do have problems.
<snip sig stuff>
On Wed, Jul 23, 2008, Lanny Marcus wrote:
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
We have been using djbdns for years on a variety of Linux platforms and FreeBSD, largely because (a) security, (b) performance, and (c) ease of use. Not everybody likes Dan Bernstein, but I figure he's somewhat of a curmudgeon who designs good software.
As for not having it supported on CentOS, I really don't care about that as the majority of the server software we use is built under the OpenPKG.org portable packaging system, independent of the underlying OS vendor's packaging system.
Bill
Bill Campbell wrote:
On Wed, Jul 23, 2008, Lanny Marcus wrote:
On Sat, Jul 19, 2008 at 2:27 PM, John Hinton webmaster@ew3d.com wrote:
OK, so does anybody have a good firewall rule solution for what we're supposed to be doing with bind these days? Obviously port 53 is no longer enough.
Consider using djbdns instead of BIND. It sounds like an excellent alternative to BIND.
We have been using djbdns for years on a variety of Linux platforms and FreeBSD, largely because (a) security, (b) performance, and (c) ease of use. Not everybody likes Dan Bernstein, but I figure he's somewhat of a curmudgeon who designs good software.
I know Dan personally, and think I was there during some of the big blowups (well the ones I was there for were big...). He definitely had/has a problem with 'the in crowd', and decided to put his money where his mouth was. I think most have benefited from this. Including the 'in crowd'.
But I also know Vixie etal quite well and I stay with BIND.
Each to their own machinzations, IMNSHO.
As for not having it supported on CentOS, I really don't care about that as the majority of the server software we use is built under the OpenPKG.org portable packaging system, independent of the underlying OS vendor's packaging system.
Bill
-
andylockran -
Bill Campbell -
Craig White -
John Hinton -
Johnny Hughes -
Lanny Marcus -
nate -
Paul A -
Robert Moskowitz -
Stephen John Smoogen -
William L. Maltby