Date: Mon, 14 May 2001 04:25:28 -0400 (EDT) From: "Dan Mahoney, System Admin" <danm@prime.gushi.org> To: Ted Mittelstaedt <tedm@toybox.placo.com> Cc: questions@freebsd.org Subject: RE: _M_onitoring named Message-ID: <Pine.BSF.4.21.0105140400060.95126-100000@prime.gushi.org> In-Reply-To: <009201c0dc4a$e4ace2c0$1401a8c0@tedm.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 May 2001, Ted Mittelstaedt wrote: Ted, I'm quite in agreement with you, as I run a server farm full of cobalt Raq3s that were compromised (I'd say out of 40 or so machines, 10 were hit hard, with annoyances seen on another 4 or 5). I've stayed on top of the BIND patches religiously, simply because this daemon is both necessary and known to be commonly problematic. While I didn't suspect an exploit had occured (unless it was a new DOS exploit that was less common than the current worm nonsense), I did learn more about the lion worm (I'm running 8.2,3-RELEASE, and for the most part taking every other precaution I can, aside from giving named its own volume, which I don't see the need for...yet. For the record, this death of a daemon is not super-often. I would say maybe three times in as many weeks, and its always been discovered RELATIVELY quickly. The odd thing is that it happens to several nameservers at once. Running different versions of freeBSD. Hell, at different ISPs even. And when it happens to several nameservers, service is effectively cut off. (motivation to keep your expire directive high!) I think my problem may be in what you say however. Here are my questions for you... How do I increase maxusers? I know there was a corresponding sysctl value for it. I think what *might* be happening is when a whole lot of zone transfers happen, something dies there. On one of my BSD servers I have: sysctl -w kern.maxfiles=8192 # Files=40 in my rc.local, and the only other clue I can offer is that a crontab which restarts an eggdrop (monitors an internal IRC server we use for support) reports "out of space" (No I have no idea which space). Also on one machine I see this regularly in the logs: limit files set to fdlimit (1024) (not on the same server that has the above line). I would love to know how to increase this, as I've tried in login.conf, and it's entirely possible that this may be related to the problem, as there are over 500 zones on this one nameserver, and that, coupled with all the system filesopen at any one time...) But then, wouldn't something like an overload of that type show up elsewhere? I've resorted to putting ndc restart in a crontab, every 15 minutes, which makes it easier for sub-users to tweak their own DNS, as they no longer need access to the "kill" command. (note that this is the shell script ndc, not the c-ndc that comes with named). > I happen to run (and no, I'm not going to tell you the IP > number or what or where it is and no you can't discover it > via querying my various published domains) a nameserver that > is fairly busy and is running on ancient, archaic, holey > bind code. Is it scheduled to be updated? Certainly. Have > I gotten to it yet? No. Would I be that concerned if someone > broke into the system _right now_? no, not particularly since > there's nothing on that system that's valuable, and it happens > to be one of several secondary DNS servers > > The point is, is that archaic, holey bind code has NOT > "occassionally" died, with the regularity that Dan's has > seemed to do. This nameserver is open to the public same > as any other nameserver on the Internet and even since all the > "chinese hacks" crap has been released I've been eagerly > waiting to see it start going down or otherwise show evidence > of lots of crack attacks - because this is what all the > security facists have been telling the world. You might say that > I'm keeping it running as a sort of a "canary in the coal mine", > as bait to attract crackers. > > However, I have been very disappointed to note no real increase in > trouble from this server. Sure every once in a few months it might > go offline for no reason, but it was doing that long before any of these > advisories came out. > > The conclusion I have drawn from this is that most of the stories > of crashing nameservers do not, in fact, have anything to do with > crack attacks, but rather with improper nameserver configuration, or > bugs in the nameserver code itself. Sure, no doubt there has been > a lot of nameservers cracked into, but I think that if you looked you > would find a gigantic number - probably the majority still - of nameservers > on the Internet are running archaic, holey code and I see no evidence that > the Internet has melted down as a result. > > Before all the "chinese hacks" against bind were released, there were > plenty of complaints out there by people saying their nameservers were > crashing for no reason. These generally were answered on the appropriate > mailing lists by rather dull and unexciting pointers like "look at > this wrong setting you have or that wrong setting you have" and when people > got those responses they buckled down to work and solved the problems. > > Today, the most commmon response I see to nameserver problems is > "oh, your nameserver MUST have been hacked". This is an exciting, sexy > answer that just about anyone can give. It requires no real understanding > of DNS by either the giver or the receiver. I guess I'm just getting sick > and tired of hearing it because my own experience is that most likely the > problem is that the DNS server has, in fact, NOT been cracked, and > that the problem is something more subtle. > > Ted Mittelstaedt tedm@toybox.placo.com > Author of: The FreeBSD Corporate Networker's Guide > Book website: http://www.freebsd-corp-net-guide.com > > > >-----Original Message----- > >From: owner-freebsd-questions@FreeBSD.ORG > >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of John Baxter > >Sent: Sunday, May 13, 2001 9:55 PM > >To: Ted Mittelstaedt > >Cc: Dan Mahoney, System Admin; Kris Kennaway; questions@FreeBSD.ORG > >Subject: Re: onitoring named > > > > > >you should visit cert.org and search for 'lion worm'. > >it is a chinese hack kit. > > > > > > > > > >Ted Mittelstaedt wrote: > >> > >> You might check into the system ram that the named process is > >> using for it's cache. You may be overflowing an internal table > >> or so. What are your MAXUSERS set to in the kernel and do you > >> have any other kernel variables defined? > >> > >> Ted Mittelstaedt tedm@toybox.placo.com > >> Author of: The FreeBSD Corporate Networker's Guide > >> Book website: http://www.freebsd-corp-net-guide.com > >> > >> >-----Original Message----- > >> >From: owner-freebsd-questions@FreeBSD.ORG > >> >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Dan Mahoney, > >> >System Admin > >> >Sent: Saturday, May 12, 2001 9:49 AM > >> >To: Kris Kennaway > >> >Cc: questions@FreeBSD.ORG > >> >Subject: Re: onitoring named > >> > > >> > > >> >On Fri, 11 May 2001, Kris Kennaway wrote: > >> > > >> >> On Sat, May 12, 2001 at 01:17:56AM -0400, Dan Mahoney, System > >> >Admin wrote: > >> >> > Hi all. I noticed recently that I've had a high occurence of > >> >named dying > >> >> > on various machines. What would I put in a crontab to restart > >> >it only if > >> >> > it's not running? I'm not sure how to format the if statement. > >> > > >> >Okay, on a freeBSD 3.2-Release server I found an implementation of NDC > >> >that was written as a (buggy, but easily fixed) shell script. I have > >> >installed this on my 4.2 boxen as "shndc", and run it from a > >crontab every > >> >20 minutes. > >> > > >> >My nameservers are both very secure dedicated machines that, other than > >> >webmin (boss's requirement) run nothing but DNS service. Occasionally I > >> >see them die on signal 11, more often with no explanation at all. These > >> >are the latest version, running in the most secure fashion I > >can get info > >> >on. (chrooted as an unprivileged user, with quotas). Has > >anyone else had > >> >problems with named dying? > >> > > >> >-Dan > >> > > >> >> > >> >> Aren't you at all worried WHY they're dying? I bet you're running > >> >> older versions than 8.2.3-RELEASE and you're suffering the effects of > >> >> (attempted, possibly successful) root penetration. > >> >> > >> >> Kris > >> >> > >> > > >> >-- > >> > > >> >I am now a lesbian. I don't like men, but thank you for writing. > >> > > >> >-Reply to my response to a personal ad, May 30th, 1998. > >> > > >> > > >> >--------Dan Mahoney-------- > >> >Techie, Sysadmin, WebGeek > >> >Gushi on efnet/undernet IRC > >> >ICQ: 13735144 AIM: LarpGM > >> >Web: http://prime.gushi.org > >> >finger danm@prime.gushi.org > >> >for pgp public key and tel# > >> >--------------------------- > >> > > >> > > >> > > >> >To Unsubscribe: send mail to majordomo@FreeBSD.org > >> >with "unsubscribe freebsd-questions" in the body of the message > >> > > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org > >> with "unsubscribe freebsd-questions" in the body of the message > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-questions" in the body of the message > > > -- "Happy, Sad, Happy, Sad, Happy, Sad, Happy, Intruiged! I've never been so in touch with my emotions!" -AndrAIa as Hexadecimal, Reboot Episode 3.2.3 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Web: http://prime.gushi.org finger danm@prime.gushi.org for pgp public key and tel# --------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105140400060.95126-100000>