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"
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908232053.NAA36241>