Date: Sat, 25 Jan 2003 20:46:53 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-security@FreeBSD.ORG Subject: Re: Limiting icmp unreach response from 231 to 200 packets per second Message-ID: <20030125204653.Z4807@shell.gsinet.sittig.org> In-Reply-To: <200301232133.h0NLXhvD085858@dc.cis.okstate.edu>; from martin@dc.cis.okstate.edu on Thu, Jan 23, 2003 at 03:33:43PM -0600 References: <200301232133.h0NLXhvD085858@dc.cis.okstate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[ not a personal attack to you, Martin; but a plea to all readers to make up their own minds and tell the blurb from the technical aspects (so not meant to start flame wars) ] On Thu, Jan 23, 2003 at 15:33 -0600, Martin McCormick wrote: > > I run bind in a root jail so I have a little shell script > to restart it correctly so I just kept bringing it back up until > one of our other network folks turned off the port of the > compromised system. The advantage of that is that you can > quickly send the correct commands even when your display is being > trashed with all the distress calls which are a result of having > no dns. > > [ ... ] > > Some years ago, when things weren't as robust as they > have gotten, I used to run a cron job every minute to restart > bind and dhcpd if they should die. I guess I should revive those > scripts and update them to fit the present configuration. You might as well make use of ports/sysutils/daemontools (or http://cr.yp.to/daemontools.html for online docs). This port has some really useful tools to supervise processes and keep logs. Although only djbware by default makes use of their presence (it's not too strict a dependency but more of a proposal; I managed to run qmail without supervise for a few hundred days, i.e. with no crash, the same can be said about tinydns and friends) one quickly gets tempted to wrap his own jobs and services with these handy tools (you can simply plug in existing startup scripts if they stay up as long as the service is running, and there is a tool for automatically backgrounded jobs in the collection). Once you realize how simple these tools can be applied you will never again want to roll your own. Definitely worth a look ... [ I'm happy to help those who are interested in getting started with this software. But since this is OT for -security please ask via PM after reading the pages DJB offers. :) ] > The other advantage to having the startup script is you > can easily tell a coworker to just run that script and bind runs > under the correct UID and GID. While you are there looking into daemontools you may consider evaluating djbdns, too (ports/net/djbdns or http://cr.yp.to/djbdns.html). I guess (OK, I'm more of afraid ...) that most people running bind do so just because they either - simply don't know any better (never heard of alternatives and cannot imagine there might be any) or - have been told that the alternatives are of no use or that there is only one real DNS server and that its name is bind and nothing else (there must be a reason why distributions ship with it and book shelves get filled with literature on it, right?) Only few admins do know about other implementations and still insist in running bind. IMO there are very few (valid) reasons to do so. Remember how much time you spent constantly upgrading your bind software (or maybe even cleaning up after you got compromised) and compare this to how much it takes to switch to djbdns only once. Add the features of djbdns (no server reload upon database updates, automatic serial number handling, user definable new record types should you need those, no way to pass an invalid zonefile to a running server and thus no startup problems or outages for this reason, server startup in the fraction of a second in the face of a few million entries database, chrooted and non privilegedly running by design from day one, split view, cleanly separated auth zone serving and recursive cache resolving, easy to use frontend, highly automatable due to very simple syntax, leightweight on resources, robustly running without slowdowns or resource leaks, no known security problems to date, did I forget something?) and it's hard to see what is missing (i.e. making you stick with bind). DynDNS is the only one I could see and this does not apply to public servers but only to LANs and only if you insist in workstation users administer the dynamic zone. :> So there is no excuse for getting compromised via a bind bug. "But it ships with the distro" asks for the reply "why didn't you keep the MS system which came with your machine then?". "But others do it too and everybody is talking about it" asks for "why don't you run Linux then? it's more popular in the press and thus must better fit your needs". "But I get literature on it everywhere and know a lot of people I can ask when I have problems" asks for "this is what makes an MS system more appropriate for your needs, it is even more widespread and there's a solution provider just around the (every) corner". If one does decide to run FreeBSD then the additional step of installing software not found in the standard distro should not be too much to ask for if services and security improve by this action. To make things clear: I'm not suggesting everyone should blindly switch to djbware. Just like I don't suggest to blindly follow the crowd and keep running the first program to come across and stick with it. But I *strongly* encourage people to look at alternatives and not merely repeat what they have heared from somebody else but instead to evaluate other software and make their own judgement from experience instead of rumours. Keeping the religious stuff aside (that's what I tried in the above paragraphs) one will notice that djbware is worth a look and most of the time better fits its purpose when you don't need all the bells and whistles of bloatware and don't want to be vulnerable to their holes all the additional code brings with it. And of course does this not only apply to standard distros and djbware but every software you use. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. 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?20030125204653.Z4807>