Date: Mon, 23 Aug 1999 14:24:01 -0600 From: Nate Williams <nate@mt.sri.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: nate@mt.sri.com (Nate Williams), freebsd-security@FreeBSD.ORG Subject: Re: IPFW/DNS rules Message-ID: <199908232024.OAA01685@mt.sri.com> In-Reply-To: <199908232012.NAA36075@gndrsh.dnsmgr.net> References: <199908231935.NAA01122@mt.sri.com> <199908232012.NAA36075@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have a public DNS server that I need people to be able to query, but
> > is there anything I can do to avoid anyone doing anything 'nasty' to it.
>
> Not a whole lot you can do here, other than keep on top of the latest
> versions of bind from ISC.
*sigh* Guess Bind is really in the same category as sendmail then.
Unfortunately, BIND has it's hooks all over the system, including the C
library. Can I just install the named and not worry about anything
else, leaving the system the same? The box in question is running
2.2.8, and I *really* don't want to upgrade it if I can avoid it.
(Note, this is a dedicated box w/out any accounts on it, so I don't care
about non-external breakins. You can't get into it w/out SSH logins
anyway....)
> > Also, I need to open up access to it to those hosts that secondary me,
> > as well as those I secondary for.
>
> That one is easy, 2 things to do. First, list those who are secondaries
> for zones on this box in the named.conf options {allow_transfer{ip
> list}};
....
> Second since xfers are done via TCP setup rules to allow only your secondaries
> to ``setup'' connections to your primary, and allow your server to
> ``setup'' connections to the servers it secondaries for.
Can I setup firewall rules for this as well? Do normal queries require
TCP connections? I'd like to be able to 'shutoff' TCP access to the box
except from my secondaries if at all possible.
Is there anywhere I can find the protocol information aside from using
the source? Any good BIND books? (I've got the O'Reilly TCP book, but
it's way out of date and not much help anymore...)
> > (I also want to make sure that none of my internal hosts 'leak' DNS
> > stuff, but that they also all go through the DNS server in order to find
> > hosts...)
> >
> > I've got some rules in place, but if someone has gotten DNS firewall
> > rules I'd be grateful to see them.
>
> These rules only log things, they are not meant to stop things, all logs
> are carefully investigated (IP's blacked out to protect the parties and
> myself, A.B.C.D is the inside DNS, W.X.Y.Z is the outside DNS, the other
> 400 rules that don't deal with DNS blacked out as well :-)):
>
> ipfw add 10000 allow tcp from any to any established
> ipfw add 10530 allow tcp from A.B.C.D to W.X.Y.Z 53 setup
So far so good. You're limiting your firewall to only connect to a
primary/secondary.
> ipfw add 10539 allow log tcp from any to any 53
This seems insecure to me. Any external host can connect to port 53 on
your internal hosts. Also, internal hosts can 'leak' information out
externally.
> ipfw add 40530 allow udp from any to A.B.C.D 53
Fairly secure, as long as BIND on A.B.C.D is secure, which we hafta
assume at some point. :)
> ipfw add 40530 allow udp from A.B.C.D 53 to any
> ipfw add 40539 allow log udp from any to any 53
This is *NOT* secure, just like the TCP port.
> ipfw add 40539 allow log udp from any 53 to any
This is also insecure, in that it allows anyone to use source port 53 to
connect to *any* UDP port in your network.
Am I being paranoid? You betcha. A number of machines at work in
another division were compromised recently, including one running a
commercial firewall. Do I feel safe? Pretty much, but when things like
this happen, you like to go through your system and crank everything
down a couple more notches. :(
> Also the above rules don't include the inside DNS doing zone transfers
> from outside DNS boxes. Add another 10530 rule:
> ipfw add 10530 allow tcp from OUTSIDE to INSIDE 53 setup
Yep.
> Hope that helps...
They look like mine except that my are even more paranoid than yours.
However, I don't like what I have, and was hoping someone could tell me
how to lock things down better.
Any good books on this?
Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908232024.OAA01685>