Date: Mon, 23 Aug 1999 13:53:40 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: nate@mt.sri.com (Nate Williams) Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPFW/DNS rules Message-ID: <199908232053.NAA36241@gndrsh.dnsmgr.net> In-Reply-To: <199908232024.OAA01685@mt.sri.com> from Nate Williams at "Aug 23, 1999 02:24:01 pm"
index | next in thread | previous in thread | raw e-mail
> > > 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.
Go compile up the latest bind release, do what someone else said about
turning this into a non-caching readonly server, I forget what option
that is, etc.
> (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....)
That makes it easier...
>
> > > 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.
DNS queries and replies are usually done using udp, if and only if a udp
query fails well a client even try a tcp query. You can savely block
tcp queries, there just shouldn't really be any.
>
> 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...)
The protocol is documented in a fist full of RFC's, that and the source
are the best bet. I don't see why you need to dig much deeper than the
fact the DNS talks on udp and tcp port 53 if setup with listen-on and
query-source.
> > > (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
^^^^^^^^ You didn't pay attention to this very
important point about what these rules DO. I also said later on how to
change them to do what you wanted.
> > 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.
You missed the clause above about ``only log things'', change that
rule from ``allow log'' to ``deny log'' and it does just what you
wanted.
>
> > 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. :)
A.B.C.D is YOUR DNS server, you are in control of how secure it is.
> > 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.
I'm ignoreing this, you didn't read very carefully.
>
> > 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.
You have no idea what my other 400 rules do. All those other UDP ports
are handled some place else. If you wanted a full firewall rule set,
well, that'll be $100/hr...
> 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. :(
>
Some where right about here was this:
To make this work for you change ``allow log'' to ``deny'' or ``deny log''.
Now go back to my original mail, make that change on the rules and see
how you like them.
> > 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.
I think that statement is false, but without a look at your rules I
can't tell you. I am a transit AS, I just can't go abritarily shutting
down services, so I do the next best thing, I allow things I expect
to go without any logging, but anything else gets logged. These rules
are actually built by a huge script that uses tons of variables and
100's of IP address to concoct the minimum rule set to allow what I
could care less about and watch EVERYTHING else.
> However, I don't like what I have, and was hoping someone could tell me
> how to lock things down better.
Turn the box off? :-) :-)
> Any good books on this?
Not really, other than the standard refernces to Building Firewalls,
the fwtk documentation.
--
Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908232053.NAA36241>