FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 07-19-2008, 07:27 PM
John Hinton
 
Default Bind Firewall Rules

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-20-2008, 03:48 AM
Craig White
 
Default Bind Firewall Rules

On Sat, 2008-07-19 at 15:27 -0400, 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.
----
are you opening both tcp and udp?

Craig

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-20-2008, 01:07 PM
Johnny Hughes
 
Default Bind Firewall Rules

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-21-2008, 12:37 PM
John Hinton
 
Default Bind Firewall Rules

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




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 03:01 PM
John Hinton
 
Default Bind Firewall Rules

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 03:15 PM
"nate"
 
Default Bind Firewall Rules

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 04:40 PM
John Hinton
 
Default Bind Firewall Rules

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 04:50 PM
"Paul A"
 
Default Bind Firewall Rules

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 05:07 PM
"nate"
 
Default Bind Firewall Rules

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 07-23-2008, 05:12 PM
John Hinton
 
Default Bind Firewall Rules

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



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org