Re: how to protect name servers against cache corruption
What, exactly, does Bind 8.1 do?
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. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "If you're so special, why aren't you dead?"
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... ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
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 Alex
At 3:54 AM -0400 7/31/97, Alexander O. Yuriev wrote:
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? ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
[ On Thu, July 31, 1997 at 09:15:03 (-0700), Michael Dillon wrote: ]
Subject: Re: how to protect name servers against cache corruption
At 3:54 AM -0400 7/31/97, Alexander O. Yuriev wrote:
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. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
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. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
On Thu, 31 Jul 1997, Michael Dillon wrote:
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?
Michael, 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? Aleph Ostrich One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
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?
apparently not. i have yet to be impressed by the depth of understanding of security in general or of dns in particular shown on the bugtraq list. that list has a lot of hanger-on wanna-be fear-uncertainty-doubt types and the folks who actually have a clue seem to mostly just lurk. i am still waiting for a demonstration of this bug, with or without a patch. "send code."
On Thu, 31 Jul 1997, Paul A Vixie wrote:
apparently not. i have yet to be impressed by the depth of understanding of security in general or of dns in particular shown on the bugtraq list. that list has a lot of hanger-on wanna-be fear-uncertainty-doubt types and the folks who actually have a clue seem to mostly just lurk.
Thats an opinion. Guess the other 12K subscribers disagree. No offence Paul but seeing that you a history of not fixing security related bugs when they where told to you months in advance (remember cron?) I dont put much weight on your opinion of BugTraq.
i am still waiting for a demonstration of this bug, with or without a patch.
"send code."
send money Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
Yo Michael! On Thu, 31 Jul 1997, Michael Dillon wrote:
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?
WHy make the good guys job harder? Am I only supposed ti find out about this stuff when my network crashes? Forwarned is forearmed! As it is now, I usually find out about this stuff only after a hacker leaves his "kit" behind. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 2680 Bayshore Pkwy, #202 Mountain View, CA 94043-1009 gem@rellim.com Tel:+1(415)964-1186 Fax:+1(415)964-1176
On Wed, 30 Jul 1997, Michael Dillon wrote:
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? [not posted to NANOG, non-operational] Rob Nelson rnelson@internoc.com
At 10:32 AM -0500 7/31/97, Robert T. Nelson wrote:
On Wed, 30 Jul 1997, Michael Dillon wrote:
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. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
In article <v03102808b0067e79fed4@[10.11.12.33]>, you wrote:
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
... and discussions of problems NOT solved by these releases? What of discussion of problems that CAN'T be solved by new releases of BIND? ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));
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
... and discussions of problems NOT solved by these releases?
What of discussion of problems that CAN'T be solved by new releases of BIND?
usenet:comp.protocols.dns.bind mailto:namedroppers@internic.net mailto:bind-bugs@isc.org
At 6:07 AM +0000 8/1/97, tqbf@smtp.enteract.com wrote:
In article <v03102808b0067e79fed4@[10.11.12.33]>, you wrote:
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
... and discussions of problems NOT solved by these releases?
What of discussion of problems that CAN'T be solved by new releases of BIND?
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. ******************************************************** Michael Dillon voice: +1-415-482-2840 Senior Systems Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net "The People You Know. The People You Trust." ********************************************************
participants (10)
-
Aleph One -
Alexander O. Yuriev -
Gary E. Miller -
Michael Dillon -
Paul A Vixie -
randy＠psg.com -
Robert T. Nelson -
Thomas H. Ptacek -
tqbf＠smtp.enteract.com -
woods＠most.weird.com