RE: Curing the BIND pain

[Michael . Dillon]

>Michael - one of the things that I am sure of is that this
>life and in fact things on this earth are moving targets.
>And what I see you saying here is "leave us alone - I want
>it to stay the way it was"... Am I wrong and if so how?

Uhh, do I have to say it again?

If you want to change the world, create new protocols or build an working
group on some topic or other, you really shouldn't try to do it on NANOG
because it just ain't gonna work. 

What I want is irrelevant. NANOG is what it is and it isn't going to 
change much unless and until it fails to meet the needs of its "members".

--Michael Dillon

RE: Curing the BIND pain

[todd glassey]

Michael - one of the things that I am sure of is that this
life and in fact things on this earth are moving targets.
And what I see you saying here is "leave us alone - I want
it to stay the way it was"... Am I wrong and if so how?

Todd


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2003 8:46 AM
To: [EMAIL PROTECTED]
Subject: RE: Curing the BIND pain



> and then send it to the IETF's DNS WG's as a request.

>Tell them what you need to accomplish and not how to do it,
>and they will build a protocol to satisfy this request

Really!?

"They" will build a protocol for us!?!?!?

And just who do you think the IETF are, hmmm?

Reminds me of the Pogo cartoonist Walt Kelly who said, "We
have met the
enemy and he is us!". May I suggest that all this advice
about what "we"
should be doing is rather out of place on the NANOG list.
This list is to
discuss Internet operational stuff that impacts North
American Network
Operators. Operational stuff is usually technical and it
usually is here
and now rather than some indeterminate point in the future.
This isn't the
rules of NANOG, it's just the way things are around here.
Anything that
falls too far outside of this core focus just doesn't get
the list fired
up enough to do anything beyond talk and complaining.

If you want to change the world, create new protocols or
build an working
group on some topic or other, you really shouldn't try to do
it on NANOG
because it just ain't gonna work. You may think that NANOG
is in a rut and
that's quite true but it is a comfortable rut and one that
provides enough
benefit to the NANOG participants to keep it going more or
less the same
way as it has for years.

There definitely is room in the world for all of the things
that have been
discussed recently, it's just that NANOG isn't a
particularly fruitful
place to discuss them because you won't find enough recruits
here to form
a critical mass. If you truly are serious about some of
these things then
you will take the discussion off the NANOG list and make a
serious effort
to create a working group with a real action plan. Anything
else is just
posturing and we've seen it all before. It does not impress
us.

Thanks,

--Michael Dillon

P.S. No, I'm not the NANOG police; I'm just stating my
opinion.

RE: Curing the BIND pain

[Michael . Dillon]

> and then send it to the IETF's DNS WG's as a request. 

>Tell them what you need to accomplish and not how to do it,
>and they will build a protocol to satisfy this request

Really!?

"They" will build a protocol for us!?!?!?

And just who do you think the IETF are, hmmm?

Reminds me of the Pogo cartoonist Walt Kelly who said, "We have met the 
enemy and he is us!". May I suggest that all this advice about what "we" 
should be doing is rather out of place on the NANOG list. This list is to 
discuss Internet operational stuff that impacts North American Network 
Operators. Operational stuff is usually technical and it usually is here 
and now rather than some indeterminate point in the future. This isn't the 
rules of NANOG, it's just the way things are around here. Anything that 
falls too far outside of this core focus just doesn't get the list fired 
up enough to do anything beyond talk and complaining.

If you want to change the world, create new protocols or build an working 
group on some topic or other, you really shouldn't try to do it on NANOG 
because it just ain't gonna work. You may think that NANOG is in a rut and 
that's quite true but it is a comfortable rut and one that provides enough 
benefit to the NANOG participants to keep it going more or less the same 
way as it has for years.

There definitely is room in the world for all of the things that have been 
discussed recently, it's just that NANOG isn't a particularly fruitful 
place to discuss them because you won't find enough recruits here to form 
a critical mass. If you truly are serious about some of these things then 
you will take the discussion off the NANOG list and make a serious effort 
to create a working group with a real action plan. Anything else is just 
posturing and we've seen it all before. It does not impress us.

Thanks,

--Michael Dillon

P.S. No, I'm not the NANOG police; I'm just stating my opinion.

RE: Curing the BIND pain

[todd glassey]

Might I suggest that you put together a group of you - four
or five should do fine, and draw up a list of all the things
that you want changed in "super BIND" or whatever you want
to call it, pass it through the group for a public airing
and then send it to the IETF's DNS WG's as a request. If you
are not getting what you need to operate your networks, then
a commitment to proactive responses requires this, or
something like it.

Tell them what you need to accomplish and not how to do it,
and they will build a protocol to satisfy this request
whether they redesign or morph BIND. It will also do wonders
for both organizations politically.

Just a thought.

Todd

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of
Nathan J. Mehl
Sent: Thursday, March 27, 2003 6:25 AM
To: [EMAIL PROTECTED]
Subject: Re: Curing the BIND pain



In the immortal words of [EMAIL PROTECTED]
([EMAIL PROTECTED]):
>
> I suggest that an appropriate technique would be for the
BIND server to
> originate traffic on it's local subnet that would look
suspicious and
> possibly trigger intrusion alarms.

Good lord.

I'm a little stuck for a proper analogy for this.  A car
that
"helpfully" starts emitting noxious smoke to let you know
that it's
time for a tune-up?  A refridgerator that drips bleach into
your
vegetable drawers to remind you to replace the coolant?  An
answering
machine that replaces the outgoing message with a stream of
profanities to alert callers that the incoming message tape
is full?

If people are so concerned about BIND's security that
they're willing
to seriously consider implementing ideas like this, why are
they not
willing to either consider replacing BIND with DNS software
that is
secure by design (*cough* *cough*), or paying the ISC to
produce a
properly secured BIND?

The solution to the Ford Pinto problem was not to recommend
that
people duct-tape sofa cushions and homemade warning lights
to the back
bumper.

-n


<[EMAIL PROTECTED]>
"Thus do `Snuff Movies' take their place with
`Political-Correctness,' `Sex
Addiction,' and `Postmodernism' as Godzillas of bogus moral
panic, always
threatening to crush the nation in their jaws, but never
quite willing to take
the final step of biting down.
(--www.suck.com)
<http://blank.org/memory/>--
--

Re: Curing the BIND pain

[Crist J. Clark]

Nathan J. Mehl wrote:
> In the immortal words of [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> > 
> > I suggest that an appropriate technique would be for the BIND server to 
> > originate traffic on it's local subnet that would look suspicious and 
> > possibly trigger intrusion alarms. 
>
> Good lord.
>
> I'm a little stuck for a proper analogy for this.  A car that
> "helpfully" starts emitting noxious smoke to let you know that it's
> time for a tune-up?

A car whose breaks start to squeal annoyingly telling you they're
about to wear out?

> An answering
> machine that replaces the outgoing message with a stream of
> profanities to alert callers that the incoming message tape is full?

Cash register tape that turns an ugly pink or green towards the end of
the roll?

Cell phones, pagers, and fifty zillion other electronic devices that
beep or buzz endlessly when the battery starts to run low?

Not that I agree that making BIND self-destruct or send off alarms is
a particularly workable idea. Even if someone comes up with a
beautiful system for this, it's probably all moot. How many vendors
of binary distributions aren't just going to rip the code back out
(BIND being freely modifiable open source)? Doing so reduces the
number of confused and panicked calls from clients when BIND does
whatever weird things it is programmed to, and also would reduce the
pressure for instant patches whenever BIND self-destructs. What vendor
in their right mind would leave it in?
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]

Re: Curing the BIND pain

[Andy Dills]

On Thu, 27 Mar 2003 [EMAIL PROTECTED] wrote:

> I suggest that an appropriate technique would be for the BIND server to
> originate traffic on it's local subnet that would look suspicious and
> possibly trigger intrusion alarms. Send out some packets to the broadcast
> address. Do some portscanning of all addresses on the subnet. Find any
> open port 80 and retrieve a URL containing
> BIND/server/at/10.7.7.1/has/security/vulnerability, find any open port 25
> and send email to postmaster containing the same message, etc.

Better yet, why not just have it print to console "BIND INSECURE, UPGRADE,
SHUTTING DOWN THE SERVER NOW" and then halt? Far more likely to get
noticed.

> Not enough traffic to be a DoS but enough to show up in various logs in
> case someone is looking at some of them.

If you have somebody looking a firewall or IDS logs, you won't need to be
told to upgrade bind. Besides, plenty of networks who do stay current on
application security would miss a little pretend DOS.

The best solutions I can come up with all revert to the undesired "stop
working" solution, in effect.

My favorite notion, which I didn't even suggest because of Paul's mandate
that the solution not involve breaking bind, would be to return, in
response to every query, the IP address of a special website that says
"THE VERSION OF BIND ON YOUR NAMESERVERS IS VULNERABLE" or whatever, and
include instructions on how to upgrade.

Sure, it will break everything except http, and flood this webserver with
a ridiculous amount of unwanted traffic (bgp anycast with filtering
everything not destined for port 80, to help stem that a little?), but at
least people will know why nothing is working, once they fire up a
browser.

Looming large, of course, is the fact that people would have to upgrade to
get any of this "security upgrade" functionality. So we'd really be only
partially solving a problem in which we won't see any benefit for years to
come, which is usually enough impetus to kill a project these days.

Andy


Andy Dills  301-682-9972
Xecunet, Inc.   www.xecu.net

Dialup * Webhosting * E-Commerce * High-Speed Access

Re: Curing the BIND pain

[Nathan J. Mehl]

In the immortal words of [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> 
> I suggest that an appropriate technique would be for the BIND server to 
> originate traffic on it's local subnet that would look suspicious and 
> possibly trigger intrusion alarms. 

Good lord.

I'm a little stuck for a proper analogy for this.  A car that
"helpfully" starts emitting noxious smoke to let you know that it's
time for a tune-up?  A refridgerator that drips bleach into your
vegetable drawers to remind you to replace the coolant?  An answering
machine that replaces the outgoing message with a stream of
profanities to alert callers that the incoming message tape is full?

If people are so concerned about BIND's security that they're willing
to seriously consider implementing ideas like this, why are they not
willing to either consider replacing BIND with DNS software that is
secure by design (*cough* *cough*), or paying the ISC to produce a
properly secured BIND?  

The solution to the Ford Pinto problem was not to recommend that
people duct-tape sofa cushions and homemade warning lights to the back
bumper.

-n

<[EMAIL PROTECTED]>
"Thus do `Snuff Movies' take their place with `Political-Correctness,' `Sex 
Addiction,' and `Postmodernism' as Godzillas of bogus moral panic, always 
threatening to crush the nation in their jaws, but never quite willing to take 
the final step of biting down.(--www.suck.com)

Curing the BIND pain

[Michael . Dillon]

Let's assume that BIND has a way to know when it is dangerously out of 
date. The mechanism used would be up to ISC and I'll admit that it would 
probably involve some sort of DNS records in an ISC-run domain because 
that's the only way that has a high likelihood of working  given the 
number of firewalls and caching nameservers that may be between a given 
BIND box and ISC. Seems to me that ISC has always maintained that there 
are two version numbers, one 4.x and one 8.x, that are always the oldest 
ones you can run and still be secure against known exploits. So the info 
stored in the ISC DNS server really doesn't need to be more than those two 
version numbers.

OK, now assume that we have a BIND server which has detected that it is 
out of date and at risk of attack. What should it do?

Well, first of all, what would a human being do if if realised that it was 
at risk of attack and they had no means of contacting their friends or the 
police. A child might cry out and an adult might yell for help in case 
someone was near enough to hear. BIND is in a similar situation. It 
doesn't know if there is anyone looking after it but it is hurting, so 
let's make it cry out.

I suggest that an appropriate technique would be for the BIND server to 
originate traffic on it's local subnet that would look suspicious and 
possibly trigger intrusion alarms. Send out some packets to the broadcast 
address. Do some portscanning of all addresses on the subnet. Find any 
open port 80 and retrieve a URL containing 
BIND/server/at/10.7.7.1/has/security/vulnerability, find any open port 25 
and send email to postmaster containing the same message, etc.

Not enough traffic to be a DoS but enough to show up in various logs in 
case someone is looking at some of them.

Even then, this is still a string and sealing wax solution. It's 
situations like this that demonstrate just how primitive our supposedly 
high technology really is. 

--Michael Dillon