BIND 8.1.1 does not appear to have an easy mechanism to match a query ID
to the question-section details of an open query. Currently, BIND
increments a counter, prints a debugging log line, and drops the packet;
it does not invalidate the open query.
> Netcom's nameservers. They will no longer be able to resolve NETSOL.COM,
> since every query they open up will be immediately invalidated by a fake
> response.
Well, one could make observations about comparisons of IP source
addresses here...
All of the attacks being discussed assume the attacker has the ability to
inject completely forged packets onto the network. All of my suggestions
are given under the assumption that this is a situation that we do not
have a reasonable expectation of being able to prevent in IPv4.
I don't see that the problem you describe affects the people
_answering_. You'd have to nail _every_ _inquirer_. Ok, yes, hitting
This is true. However, remember that this thread occurred in response to
an attack by Eugene Kashpureff, who used a far more primitive attack and
made national news by effectively disabling NSI's home page. I don't think
the operation community wants to think about the implications of someone
with both malice and BRAINS trying to utilize the same security problems.
I don't think
the operation community wants to think about the implications of someone
with both malice and BRAINS trying to utilize the same security problems.
Maybe some of us have thought about it and realized that the best course of
action is to:
a. not talk publicly about this lest the cracker community learn too much
b. harden our networks and systems to survive such a scenario. A couple
of good tips have been pointed out re filtering bogus source routes
and blocking broadcast packets during this thread. Not to mention
upgrading to the latest BIND and running servers non-recursively if
they are only acting as primary/secondary for customer domains.
c. make sure that we have the logging systems in place to trace and identify
the people carrying out such an attack so that the appropriate law
enforcement agencies can deal with them.
Some of us also know that there are some very bright and skilled people
studying information warfare in order to better prepare the armed forces
and civilian security agencies to deal with info warfare attacks. We may as
well let them do their job and we'll do ours.
We are like the designers and operators of an interstate toll highway, not
like the highway patrol.
In fact I think one of your most recent posts quite eloquently pointed out
the difficulty, futility almost, of trying to block such attacks with a
protocol that was never designed to be secure. If we are going to take
heroic measures, would they not be better spent on implementing DNSSEC
rather than shoring up the old DNS protocol? The lesson of the coal mines
in England comes to mind...
Maybe some of us have thought about it and realized that the best course of
action is to:
a. not talk publicly about this lest the cracker community learn too much
[snip]
We are like the designers and operators of an interstate toll highway, not
like the highway patrol.
Michael, do you think it would be a value to have designers of highways
not discuss publicly people sppeding after they are built?
I disagree that we should not talk publicly about flaws in the design of
the network. I think that this information should be as widely
disseminated as possible.
In 1853 Charles Tomlinson wrote a treatise on Locks. This document
describes the reasons that the "good guys" should discuss the construction
(and failings) of locks in public, otherwise only rogues will have the
information. He goes on to further state that rogues will be the first to
*apply* such knowledge.
Furthermore, not discussing security issues, and their implications
publicly leads to hysteria and paranoia throughout the system. Do you
suggest that we gain protection from having uneducated network
administrators?
I don't propose to "make sure" that only good guys know, I just suggest
that it is better to not spread the info publicly when you don't know who
is listening in. Why make the bad guys job easier?
[ On Thu, July 31, 1997 at 09:15:03 (-0700), Michael Dillon wrote: ]
Subject: Re: how to protect name servers against cache corruption
>> a. not talk publicly about this lest the cracker community learn too much
>
>Sure. Now how do you propose to make sure that only good guys know about
>bad things? Mathematically it is impossible. It is a set theory
I don't propose to "make sure" that only good guys know, I just suggest
that it is better to not spread the info publicly when you don't know who
is listening in. Why make the bad guys job easier?
The bad guys already know. They're often the ones who discover the
problems in the first place and even if they aren't you can be sure
they'll find out once the "experts" do.. All that happens when people
try and restrict information about incidents is that the number of
people focusing on the solution is reduced, often drasically to below
the critical mass necessary to solve the problem once and for all.
The only minor gain that can be had from controlling this information is
that egos are less bruised and the truely amateur crackers may not learn
of various faults. This is really only useful for those barn-door sized
problems where any joe could wander through and wreak havoc even without
looking.
Now from an operations point of view it may be best to not give away too
many details before the experts get a look and definitely don't reveal
the impact of a given attack on your organization unless you already
have a good handle on it.
However this group in particular should be making wide and frequent use
of this list and others like it to notify each other (and the experts)
of things they should be looking out for and precautions that should be
taken.
Please do reduce the exposure some of these old myths get though and
debunk them as fully as possible.
Well seeing this has dicussed in detail in BugTraq I would assume
everyone you are worried about has already need it. Now the question is
have the people that need to know seen it?
Maybe some of us have thought about it and realized that the best course of
action is to:
a. not talk publicly about this lest the cracker community learn too much
I disagree that we should not talk publicly about flaws in the design of
the network. I think that this information should be as widely
disseminated as possible.
The way I see it, it is valuable to admit that flaws exist and to make sure
as many people as possible know the best possible solutions to the problem,
in this case installing BIND 4.9.6 or the latest BIND 8. But I don't think
that it serves anyone to discuss the details of how these flaws can be
exploited. Yes, I know that the security experts discuss this stuff in
their own forums and that some crackers are there learning and building
exploit tools. But I feel uncomfortable when the detailled discussion of
exploit techniques spills over into too many other forums.
In 1853 Charles Tomlinson wrote a treatise on Locks. This document
describes the reasons that the "good guys" should discuss the construction
(and failings) of locks in public, otherwise only rogues will have the
information. He goes on to further state that rogues will be the first to
*apply* such knowledge.
No argument here. And thank you for pointing out how we aren't really
breaking as much new ground here as some people think.
Furthermore, not discussing security issues, and their implications
publicly leads to hysteria and paranoia throughout the system. Do you
suggest that we gain protection from having uneducated network
administrators?
Nope. I think it's great to educate network administrators on what they can
do today to protect their networks and I think that a good way to combat
paranoia is to suggest that there is an action available that will increase
your protection. When the public believes that something can be done, i.e.
upgrade BIN, filter bogus source routes, block broadcasts, then they
generally pressure the technical people to get cracking and implement the
solutions. This is not paranoia.
I don't propose to "make sure" that only good guys know, I just suggest
that it is better to not spread the info publicly when you don't know who
is listening in. Why make the bad guys job easier?
The bad guys already know. They're often the ones who discover the
problems in the first place and even if they aren't you can be sure
they'll find out once the "experts" do.
I know. The smart bad guys almost always find these holes before the good
guys. But there are lots of not-so-smart bad guys and these folks are far
more likely to actually use their knowledge maliciously. These people are
not neccessarily plugged in to the same channels of info as the smart bad
guys and these not-so-smart folks are the ones that we can slow down by
being more discreet about what we discuss in public.
All that happens when people
try and restrict information about incidents is that the number of
people focusing on the solution is reduced, often drasically to below
the critical mass necessary to solve the problem once and for all.
My experience is that it only takes one or two smart people to solve this
kind of problem. And I strongly doubt that those people will be on this
list since they are much more likely to be on lists that discuss
theoretical issues.
However this group in particular should be making wide and frequent use
of this list and others like it to notify each other (and the experts)
of things they should be looking out for and precautions that should be
taken.
The experts can be notified in private rather than by shotgunning various
public mailing lists. This list is better used for practical actions that
people can take today.
Well, there are various security lists for these kinds of theoretical
discussions and since it directly concerns BIND, I would think that the
BIND workers mailing list would be appropriate too. But there's not much
point in discussing it here because if there is nothing that network
operators can install or configure to solve the problem then there really
isn't anything we can do at all. We build and run the highways. New asphalt
formulas are of no interest to us until you are able to deliver 120
truckloads next Monday. Then come here and tell us.