February 2001 - Test - lists.nanog.org

Re: Reasons why BIND isn't being upgraded
by Simon Waters 03 Feb '01

03 Feb '01

> From: Paul Vixie <vixie(a)mfnx.net> > Simon(a)wretched.demon.co.uk (Simon Waters) writes: > > > I remain unconvinced that showing the version string helps much. > hiding it doesn't help at all. people who want to know if you're vulnerable > and to what have tools to find out. No - they or their tools then have to try known exploits sequentially to find out if I'm vulnerable - which is completely different to just asking for a version string. In some cases the failed exploits will be logged, or cause a crash. Thus perhaps allowing DoS but saving someone altering the DNS contents, or perhaps giving the owner time to respond. > hiding it DOES however make it harder for people (including network owners) > to do surveys. Network owners can run "named -v", or get an audit program that does it for them. BIND is not alone most major Internet software (My mail program does for starter... at the moment anyway) is only too keen to tell you who it is in tedious detail, I think they should report what protocols they support (although this could be a give away as well). BTW I'm not saying "lie" about the version string as someone seemed to think, I'm saying just don't give it to anyone who asks. If someone phoned you up out of the blue, and said "Hi, I'm Simon, what version DNS server are you running?" you'd probably hang up or ask why I want to know, you wouldn't just say 8.2.3 and hang up, so why let your most sensitive servers do something you wouldn't. > From: Jim Mercer <jim(a)reptiles.org> > > yeah, i'm pissed with isc and that vixie guy too. > > after all, i paid them 0's and 0's of dollars to come up with a timely > fix to the security hole, and what do they do? I'm hoping HP pay them a reasonable amount out of what my clients pay HP, but HP probably squandered it paying Jean to write all that wireless network card code for Linux *8-) -- Business http://www.eighth-layer.com/ Personal http://www.wretched.demon.co.uk/

1 0

Re: [NANOG] Re: Reasons why BIND isn't being upgraded
by Sean Donelan 02 Feb '01

02 Feb '01

On Fri, 02 February 2001, Pim van Riezen wrote: > On Thu, 1 Feb 2001, Eric A. Hall wrote: > > The real culprit in this story is the script-generator. It should have > > been cranking out standard-compliant zone files from day one. > > Absolutely. The guilty party for that script has long left the > organization. This is real world, where people have to deal with other > people's messes :). Don't worry, someday people will say the same thing about the messes you leave behind.

1 0

RE: Reasons why BIND isn't being upgraded
by Karyn Ulriksen 02 Feb '01

02 Feb '01

For several services, we keep a table of inhouse daemon/versions to real daemons/versions. We haven't done this on bind yet, but thinking about it now. We starting using it on FTP services a few years ago. That way we know what version of wu-ftpd or apache (or whatever) we are running on a server, but the script kiddies don't off the bat. Some of it *is* customized, but we have version identifiers for those customized versions as well. It's not that big of a hassle to keep track of the map - just a simple hash to manage. Best of both worlds. K > -----Original Message----- > From: Patrick Greenwell [mailto:patrick@cybernothing.org] > Sent: Friday, February 02, 2001 11:14 AM > To: Bill Woodcock > Cc: nanog(a)merit.edu > Subject: Re: Reasons why BIND isn't being upgraded > > > > On Fri, 2 Feb 2001, Bill Woodcock wrote: > > > On Fri, 2 Feb 2001, Patrick Greenwell wrote: > > > By the same token one might argue that atempting to > hide vunerabilities > > > to those paying you for "early warnings" doesn't help at all. > > > > Not at all... If you're trying to hide a vulnerability by > lying about > > your version number, that presupposes generally-held knowledge of an > > association between a vulnerability and a version number. > > > > "Early warning" is specifically a means of delaying the general > > availability of knowledge of that association. > > Which leaves those that have not been informed of such vunerabilities > acutely vunerable. > > Script kiddies may be stupid, but the people writing the > program that they > utilize generally aren't. > > Without rehashing the whole "open-disclosure" vs. "non-disclosure" > arguments related to security issues in software, or the historically > extreme inadequacies of CERT in offering timely notification of ANY > security-related issues, it's very disappointing to see ISC > resort to a > fee-based, non-public-disclosure-at-the-time-of-discovery, NDA'd and > "we'll update people via CERT" method of dealing with the > community they > have served for so long. > > I would have hoped by now that lists such as Bugtraq would > have adequately > exhibited the folly of such methodologies. > > Obviously that is not the case. > > >

1 0

RE: [NANOG] RE: [NANOG] Re: Reasons why BIND isn't being upgraded
by Roeland Meyer 02 Feb '01

02 Feb '01

> From: Pim van Riezen [mailto:pi@vuurwerk.nl] > Sent: Friday, February 02, 2001 3:59 AM > > On Fri, 2 Feb 2001, Roeland Meyer wrote: > > > > Pete Elke's point about preproduction testing could perhaps be > > > turned from a combative tone to the constructive without loss of > > > information. > > > > Isn't that why NSI is running a stealth master root server > ... so they _are > > able_ to do pre-production testing of zone files? In the > past few years, > > there were a lot of root server outages that would have > been prevented by > > that practice. > > To be honest, yes it wuold've saved me some extra frustration if I had > known there would be such issues. Yes, a test situation is > ideal to get > these changes figured out. I just counted on it to be a > trivial upgrade > and it wasn't. Repeat after me; There is no such thing as a trivial upgrade.

1 0

Re: Reasons why BIND isn't being upgraded
by Simon Waters 02 Feb '01

02 Feb '01

Apologies for the delay - but I read the list in digest and this is my first post. I have done a slightly bigger survey of BIND version strings as of 16:00GMT Thursday February 1st, taking the nameservers for Keynote40 Business to Consumer sites and a selection of the domainnames from the front page of www.persiankitty.com. Of 440 DNS servers surveyed; 35% are reporting strings that clearly indicate use of 8.2.3 or better (Hardly anyone is revealed to be using 9.0 or 9.1). 35% are reporting strings that strongly suggest they are susceptable to known BIND bugs (Some are rather old versions of BIND are out there). These figures charitably assume that; people who don't reveal version strings are not afflicted by BIND bugs. Bind variants that have source code modifications aren't affected - they probably are, but I said we were being charitable. So in answer to the question - are people too busy to upgrade BIND - clearly 35% of admins found time to do it already. Those who had upgraded to 8.2.2-P7 to avoid the previous DoS bugs should have had nothing more to do than replace the binaries and test at 8.2.3, so I think the time excuse is a bit thin. Interestingly the sexsites were only marginally behind the Keynote40 sites, in terms of DNS versions. So perhaps your credit card number is nearly as safe as your share portfolio. Of the strings returned the most humorous was "SIN" from a sexsite. The most constructive administrator entry was the admin e-mail address (But since this is in the SOA resource record and RFC2142 (you do have all the RFC2142 mail addresses don't you?!) I'm not awarding any prizes). The ISC.ORG web site recommends leaving the BIND version string unchanged to assist in troubleshooting. I remain unconvinced that showing the version string helps much. Certainly any site with 7x24 hour technical support should consider putting a relevant contact phone number IMHO - such that anyone trying to diagnose a genuine problem can get help, whilst nosey crackers can revert back to social engineering. (E-mail addresses may not be a good choice if your DNS or their DNS is playing up?!). Whilst you can add a "bind" zone of type Chaos and overwrite the default behaviour, as given in an earlier post. Later versions of BIND let you drop the version string in the options section, which is a lot less typing, and a lot easier to understand. An extract of my BIND 9.1rc1 named.conf is given below, clearly my server is only listening to the loopback address, but you'd be amazed how many times it has been queried in the last couple of weeks whilst I got the scripts sorted. options { directory "/etc/namedb"; // Working directory pid-file "named.pid"; // Put pid file in working dir listen-on { 127.0.0.1; }; // private server for performance listen-on-v6 { none; } ; // No version 6 IP version "Contact +44(0)1395 232769"; // Don't release version number }; version ""; doesn't do what I expected at 9.1rc1..... The survey mentioned above will form part of a bigger report, which was inspired by the Microsoft debacle (Aren't those Akamai DNS servers weird, oh and all Microsoft's e-mail relays have sequential IP addresses - what planet are they on), so I will be checking which domains have all their DNS servers (for which glue records exist) in the same network (Based on 'NetName' - better ideas welcome from routing experts - can I easily get IP to ASN?). If I have time I may include mail servers and relays as well as DNS servers, of course if all your DNS servers are on one network having off network mail relays won't help much when you muck up the routing. HTH Simon

7 11

More MSFT woes.
by Jeff Mcadams 02 Feb '01

02 Feb '01

http://dailynews.yahoo.com/h/ap/20010202/tc/email_microsoft_1.html Seems like an email test got out of hand. Saying it doesn't reflect any problem with Exchange. I would tend to question that...a backlog of mail should be able to be processed more quickly than that I would think...though I don't really know the severity of the situation, so I'll give them the benefit of the doubt for now. FWIW, to the best of my knowledge, there is no relation between myself and the Scott McAdams quoted. (McAdams really isn't all that common of a name though, so I guess its possible) -- Jeff McAdams Email: jeffm(a)iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

2 1

XO Routing Issues in Maryland
by Omachonu Ogali 02 Feb '01

02 Feb '01

Does anyone know if XO reported an outage or any sort of issue affecting their Maryland POP? traceroute to ns.nova.org (209.31.144.41), 30 hops max, 40 byte packets 1 nac-gw.colo1.psn1.informationwave.net (207.99.106.1) 4.761 ms 1.728 ms 1.084 ms 2 s4-1.core1.whi.nac.net (209.123.11.153) 2.337 ms 1.758 ms 1.971 ms 3 global-crossing.transit.nac.net (207.99.10.2) 3.311 ms 2.919 ms 4.027 ms 4 s3-0-1-45M.br1.NYC2.gblx.net (206.132.29.161) 5.706 ms 4.632 ms 5.805 ms 5 pos2-2-155M.cr1.NYC2.gblx.net (208.51.66.17) 3.996 ms 3.228 ms 3.327 ms 6 pos10-3-622M.cr1.IAD3.gblx.net (208.48.234.221) 11.108 ms 12.834 ms 13.095 ms 7 208.49.231.10 (208.49.231.10) 10.930 ms 10.802 ms 11.984 ms 8 a2-0d821.core2.was-dc.us.xo.com (208.36.132.33) 11.646 ms 11.641 ms 12.177 ms 9 p1-0.tran1.nyc-ny.us.xo.com (64.0.0.42) 14.262 ms 15.195 ms 17.064 ms 10 p0-0.tran1.nwk-nj.us.xo.com (64.0.0.50) 16.675 ms 15.872 ms 16.306 ms 11 ge10-0.tran2.nwk-nj.us.xo.com (64.220.1.34) 17.255 ms 17.606 ms 16.016 ms 12 p0-0.tran2.chi-il.us.xo.com (64.0.0.45) 81.048 ms 83.928 ms 80.970 ms 13 ge4-0-0.core2.chi-il.us.xo.com (64.220.0.199) 81.309 ms 83.400 ms 80.947 ms 14 e31-1.bcr01.chi-il.us.cnc.net (207.88.48.68) 87.273 ms 82.624 ms 82.016 ms 15 206.83.91.154 (206.83.91.154) 112.163 ms 112.481 ms 118.052 ms 16 e31-23.bcr01.per-md.us.xo.com (209.220.97.102) 115.039 ms 118.966 ms 116.221 ms 17 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 114.528 ms 115.861 ms 115.369 ms 18 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 113.670 ms 113.359 ms 116.677 ms 19 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 113.869 ms 111.134 ms 114.139 ms 20 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 116.745 ms 116.585 ms 114.489 ms 21 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 113.891 ms 115.539 ms 113.167 ms 22 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 116.336 ms 115.490 ms 115.565 ms 23 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 117.069 ms 115.492 ms 116.245 ms 24 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 114.055 ms 116.477 ms 118.461 ms 25 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 116.595 ms 117.359 ms 116.917 ms 26 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 118.080 ms 115.674 ms 118.444 ms 27 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 116.193 ms 140.078 ms 120.025 ms 28 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 118.713 ms 117.849 ms 116.288 ms 29 f81-3.bcx01.per-md.us.xo.com (206.83.93.66) 118.428 ms 119.300 ms 122.720 ms 30 f81-17.bcr01.per-md.us.xo.com (206.83.93.65) 119.031 ms 117.408 ms 118.763 ms -- Omachonu Ogali missnglnk(a)informationwave.net http://www.informationwave.net

1 0

Not a good day now stuff from here is on BBC
by Henry R. Linneweh 02 Feb '01

02 Feb '01

Major net security holes identified http://news.bbc.co.uk/hi/english/sci/tech/newsid_1142000/1142572.stm -- Thank you; |--------------------------------| | Thinking is a learned process. | | ICANN member @large | | Gigabit over IP, ieee 802.17 | | working group | | Resilient Packet Transport | |--------------------------------| Henry R. Linneweh

8 8

Re: [NANOG] Re: Reasons why BIND isn't being upgraded
by Sean Donelan 02 Feb '01

02 Feb '01

On Thu, 01 February 2001, Paul Vixie wrote: > pi(a)vuurwerk.nl (Pim van Riezen) writes: > > bogosity while updating 8.2.2-P7 to 8.2.3: > > > > (1) 8.2.3 Doesn't accept the "(" in the SOA string to be on the next line > > after the IN SOA. Our script-generated zonefiles, about 45000 of them, > > all had this. > > Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 > was simply _wrong_ to accept that syntax. Is there any particular harm from accepting this syntax. It wouldn't be the first time a RFC has been updated to match working code.

4 3

RE: [NANOG] Re: Reasons why BIND isn't being upgraded
by Roeland Meyer 02 Feb '01

02 Feb '01

> From: Joshua Goodall [mailto:joshua@roughtrade.net] > Sent: Friday, February 02, 2001 12:52 AM > I can understand the annoyance felt by a large hosting > provider updating > BIND in an emergency and finding more than just a security > fix. Pim is, I > guess, concerned that similar updates in future may have longer MTTR > impact. Pete Elke's point about preproduction testing could > perhaps be > turned from a combative tone to the constructive without loss of > information. Isn't that why NSI is running a stealth master root server ... so they _are able_ to do pre-production testing of zone files? In the past few years, there were a lot of root server outages that would have been prevented by that practice.

2 1