- Test - lists.nanog.org

Re: [nsp] known networks for broadcast ping attacks
by Jeffrey S. Curtis 31 Jul '97

31 Jul '97

Alex Bligh writes: }Urm, 192.41.177.255 is the MAE-East LAN ?! Are you saying attacks are }being mounted from here or people are attacking this LAN (not }sure which is more worrying) If I'm interpreting the code comments correctly, what this silly "smurf" thing does is take a victim's IP address and generate an ICMP_ECHO_REQUEST with the victim's IP address as the source and an IP address from the array as the destination, and generate lots of such packets (per each destination). That way, the victim supposedly receives lots of ICMP_ECHO_REPLY packets - moreso than from, say, the 28.8kbps dialup line from which the attack is taking place. So basically this is just a simple DoS attack on bandwidth, supposedly multiplied by the fact that it uses broadcast addresses as the "proxy" attacker rather than unicast addresses. However, I don't know about everyone else, but my routers respond to such attempted directed-broadcast pings from their own unicast address, so it really isn't multiplying anything. And furthermore, if more people implemented source address filtering, it would be less of a problem - if it really is a problem at all. (And to answer the proverbial "how do I configure my router for that" in advance, the answer is that, at least on my boxes, the not-allowing- broadcast-pings-through-as-broadcasts-onto-the-target-media thing is on by default. Source address filtering, however, is not.) Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

4 4

Re: how to protect name servers against cache corruption (fwd)
by Thomas H. Ptacek 31 Jul '97

31 Jul '97

> Yes. But that something shouldn't include sending _anything_ off the > machine, which is what you suggested. If I didn't send a query to > begin with, I sure in hell ought not to "re-send one" because I got a I think you are confused here. Let me clarify. I want the A record for HOME.NETSCAPE.COM. I send a query for it to NS.MCI.NET, with the query ID "10". Immediately thereafter, I receive 15 responses, forged to appear to come from NS.MCI.NET, with IDs ranging from "20" to "65500". None of them can possibly be valid, and there's no legitimate reason that I should be receiving these responses. I (nameserver) therefore make the determination that I am under attack. At this point, I can either log the fact and ignore what's happening, in which case the attacker will simply continue to send forged responses until one of them happens to bear the query ID "10", or I can decide "hey, I'm going to ignore even a valid response from NS.MCI.NET at this point, because I have no way to tell that it isn't forged". The problem with this is that it allows a trivial denial of service attack. I'm Karl Kashpureff, and I want to prevent anyone at Netcom from being able to resolve WWW.NETSOL.COM. All I do is send a consistant stream of forged responses from the listed authority servers for NETSOL.COM to 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. What I'm saying probably makes the ID guessing attack look much simpler than it really is. This is because, in the real world, there are actual authority servers that actually receive the sent query. Even in the absence of countermeasures such as the one outlined above, brute-force ID guessing attacks are extremely difficult, since the correct ID needs to be guessed prior to the receipt of a legitimate answer by a real server. The 4.9.6 resolution to the ID-guessing problem contributes randomized query IDs to this. In the presence of randomized query IDs, and in the absence of attacks on the legitimate authority servers, it's probably reasonable to assume that DNS is reliable in the face of an attack, due to the extremely low likelihood of guessing the right one out of sixty-five thousand IDs before a valid response. However, in the presence of an attack on the legitimate authorities, we have a real problem. If I can cause all the listed authorities for a domain to cease responding to queries, I can set myself up for a completely successful spoofing attack on the records they're answering for. There's a real issue here involving the fact that, right now, /any/ denial of service attack in BIND (and we've just seen one of them posted to Bugtraq) potentially allows for the compromise of nameserver caches. A proposed countermeasure for this involves something I've taken to referring to as "DNS cookies". The goal is to ensure that the listed authority servers are capable of answering questions; that is, we'd like to know if an attacker will have to beat out a legitimate server in a brute force attack (in which case the attack will be difficult to carry out), or whether the attacker will always be successful, since the authorities can't assert the right information. The idea is to send a random nonrecursive query to the authority server being queried, in addition to (in a seperate packet) the real query. Using a second query as a cookie allows us a massive random number space; we can safely assume that the receipt of an answer for the random "cookie" query means that the listed server is alive and answering. This method would only be used when it's determined that the nameserver is under attack, and should therefore add minimal load to the DNS system. In place, the attack changes from something with deterministic chances of success (I /will/ eventually hit on the right ID) to something with a very slim probability of success (I'll eventually hit the right ID, but the likelihood of doing so before the real server answers is minimal). So, there's another piece of input. There are other ideas, too. ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf(a)enteract.com] ---------------- "If you're so special, why aren't you dead?"

1 0

Re: [nsp] known networks for broadcast ping attacks
by Sean Donelan 31 Jul '97

31 Jul '97

>Well, I've been filtering ICMP for quite a while at my border routers, >and other than the occasional braindead sendmail configuration, and >the fact that Solaris ping can't handle the "Administratively prohibited" >return from the IOS filter rule, I've yet to see a major downside. Under certain conditions filtering all ICMP messages will break Path MTU discovery. Check your router vendor's documentation for information about filtering types of ICMP messages. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Internic does it again
by Matthew James Gering 30 Jul '97

30 Jul '97

>Because of the pending IPO, the InterNIC is in a 90 day quiet period. Even >if they have hired a PR person/group/agency, that entity couldn't really do >their job until after the IPO. I believe that this is an SEC regulation. Bullshit. We are all customers of InterNIC, they are providing service under contract with us. They have a right, and we have a right to demand that they keep us informed on any issues that may affect that services. This is a vendor/client issue, not a vendor/public issue. If they are forced to email their customer base directly instead of posting on appropriate forums during that 90 days then fine, but it is definitely something that should and needs to be done. Matt

1 0

Re: [nsp] known networks for broadcast ping attacks
by Jeffrey S. Curtis 30 Jul '97

30 Jul '97

Jay R. Ashworth writes: }Ought IP stack implementations not to refuse to reply to ECHO_REQUEST }packets with destination address which are broadcast addresses? Why? It's a useful tool. }Ok, yes, I know that CIDR makes this harder, but knowing which nets }fall on non-octet boundaries is non-obvious, too, and this particular }attack wasn't trying... It's not hard - a host knows its own subnet mask and therefore can calculate its broadcast address trivially (my IP address logical-AND my subnet mask, plus all ones in the zero-portion of the mask). }.255 is _always_ a broadcast address, no? Wrong - consider what happens on nets whose subnet mask is less than 24 bits long (I have many such nets). 10.1.1.255 is a unicast host address if the mask is /23, or /22, or... Jeff -- Jeffrey S. Curtis | Internetwork Manager Argonne National Laboratory | Email: curtis(a)anl.gov 9700 South Cass Avenue, ECT-221 | Voice: 630/252-1789 Argonne, IL 60439 | Fax: 630/252-9689

2 1

Re: [nsp] known networks for broadcast ping attacks
by shields＠crosslink.net 30 Jul '97

30 Jul '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > Ought IP stack implementations not to refuse to reply to ECHO_REQUEST > packets with destination address which are broadcast addresses? Apparently some management packages search out hosts using broadcast pings. Not the best decision IMO. This was discussed a couple of days ago on bugtraq and I posted a Linux patch to cause it not to answer broadcast pings. *** How do you configure your router for that? no ip directed-broadcast. -- Shields, CrossLink.

1 0

TLD .ES screw up
by Miguel A. Sanz. RedIRIS/CSIC 30 Jul '97

30 Jul '97

We hate to have to deal with this in public lists, but there seems to be the only way InterNIC reacts to problems these days :-( Top level domain .es was screw up by InterNIC in yesterday's root zone update. They've added an unauthorized NS without our request, knowledge or consent. We've been trying to get InterNIC to solve the problem ASAP (as it is affecting access to nearly 200.000 hosts under .es) sending messages to action(a)internic.net, hostmaster(a)internic.net and a couple of their management staff (see below) without success. We even were ingenuous enough to try to get some techical knowledgeable person on the phone but... first we got redirected to the IANA phone number!, second try (after convincing the operator that InterNIC is also in charge the root zone not only the .com .net .org domains) we had our contact data taken with the promise of a phone back by a technician which hasn't happened yet. So my questions now: Does any one know a direct way to reach the InterNIC technical staff to solve this kind of urgent problems? Shouldn't there be a specific set up of procedures, forms and communication channels between the managers of the root zone and the TLD managers? Any help will be appreciated. Miguel A. Sanz ES-NIC __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN Network Manager ____________ Spanish Academic & Research Network ________________________ --- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> Date: Wed, 30 Jul 1997 15:05:45 +0200 (MET DST) From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> To: "David H. Holtzman" <dholtz(a)internic.net> Subject: (Fwd) EMERGENCY TLD .ES Cc: hostmaster(a)nic.es Please take quick action on this and report back! We will wait a couple more hours before escalating this to IANA and TLD list. Regards, Miguel A. Sanz ES-NIC --- Forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> Date: Wed, 30 Jul 1997 11:49:59 +0200 (MET DST) From: "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> To: hostmaster(a)internic.net Subject: EMERGENCY TLD .ES Cc: cert(a)rediris.es, Mark Kosters <markk(a)internic.net>, hostmaster(a)nic.es Dear hostmaster, I am the technical contact of the top level domain for Spain (".es"). Much to our surprise we discover yesterday that a new unauthorized NS was popping up in everybody's caches for the ".es" zone. At first we thought that a cache infection attack (the kind of Alternic's against InterNIC) was taking place and spread the word that everybody in the country upgrade to the recent versions of BIND. However, some places running BIND-4.9.6 and 8.1.1 were also infected!!! We the went to check InterNIC's database and ... the problem is there!!! InterNIC has made a change in the delegation of the ".es" zone without our request, knowledge or consent. Instead of the authorized nameservers which are: SUN.REDIRIS.ES 130.206.1.2 CHICO.REDIRIS.ES 130.206.1.3 PRADES.CESCA.ES 192.94.163.152 NS.EUNET.ES 193.127.1.11 SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 NS.EU.NET 192.16.202.11 RS0.INTERNIC.NET 198.41.0.5 NS.UU.NET 137.39.1.3 MUNNARI.OZ.AU 128.250.1.21 128.250.22.2 You have now: SUN.REDIRIS.ES 130.206.1.2 CHICO.REDIRIS.ES 130.206.1.3 PRADES.CESCA.ES 192.94.163.152 LINUX2.DYCSA.ES 195.53.97.1 SUNIC.SUNET.SE 192.36.125.2 192.36.148.18 NS.EU.NET 192.16.202.11 RS0.INTERNIC.NET 198.41.0.5 NS.UU.NET 137.39.1.3 For unkown reasons an unauthorized change has been made to the root zone and the InterNIC database. You have placed a bogus NS LINUX2.DYCSA.ES instead of the legal one: NS.EUNET.ES !!! Please CORRECT this as soon as possible and restart the root server. We would also like that you open an investigation about this case to know if this has been caused by some InterNIC's internal error or by an intentional ill will request made by someone. Please keep as inform about your actions to correct this error and of the results of your internal investigation. Regards, Miguel A. Sanz (MAS122) ES-NIC __________________ __ ______________________ /_/ Miguel A. Sanz __ __ Email: miguel.sanz(a)rediris.es RedIRIS/CSIC /_/ RedIRIS /_/ Tel: + 34 1 5855152 Serrano 142 __ Fax: + 34 1 5855146 E-28006 Madrid /_/ SPAIN Network Manager ____________ Spanish Academic & Research Network ________________________ ---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es> ---End of forwarded mail from "Miguel A. Sanz. RedIRIS/CSIC" <miguel.sanz(a)rediris.es>

7 6

Re: Out of Office AutoReply: how to protect name servers against cache corruption
by Systems Engineer 30 Jul '97

30 Jul '97

I believe this was for the rest of the list :) Schwartz, Steven wrote: > To All: > > I am out of the office until August 4th. In my absence, if your > matter > is urrgent please call or e-mail or Steven Leibrock x9496, in the > GSINet group. > > Thanks.... steve -- --- --- --- --- --- --- --- --- --- Steven Nash ph: (516)248-8400ext25 Systems Engineer / Network Security fax: (516)248-8897 Lightning Internet Services LLC email: snash(a)lightning.net http://www.lightning.net --- --- --- --- --- --- --- --- ---

1 0

Re: TLD .ES screw up
by Miguel A. Sanz. RedIRIS/CSIC 30 Jul '97

30 Jul '97

On Jul 30, 20:52, Paul A Vixie wrote: > Subject: Re: TLD .ES screw up > I want to correct a misapprehension. InterNIC does not make changes to > the root zone. The root zone is in the province of the IANA, and only > IANA can explain why this change was made or get it fixed for you. NSI > is just a publication facility for the root zone, they don't edit it. >-- End of excerpt from Paul A Vixie I think you're wrong. Last time we had to change .es delegation one and a half years ago, we had to sent a normal template to hostmaster(a)internic.net But InterNIC also make changes to hosts where domains are delegated which seem to be the cause of this problem. Someone made a wrong "host template" request for one of the secondaries of .es (ns.eunet.es) changing its name and IP address, which had the effect of changing the delegation of the .es zone. For what I understand, InterNIC is admiting hosts templates for domains which are not under .com .org .net, etc. (the TLDs under his management) and placing glue records for them in the DNS. Am I right? If this is such, I don't think this is correct. If someone wants a domain under .com to be delegated in a server under .es they shouldn't place glue records for this nameserver (the same way we don't place glue records for nameservers of .es domains delegated into .com NSs). The only glue records they should have for NSs under .es are the ones in which the TLD .es is being delegated and those should be admited only if included in the TLD delegation (or change of delegation) request. Miguel A. Sanz

2 1

Re: how to protect name servers against cache corruption
by Paul A Vixie 30 Jul '97

30 Jul '97

someone asked me a question in private e-mail that deserves a public answer. > 1) How exactly did Eugene Kashperuff propogate this "RR poisoning" across > the Internet? From NANOG's previous mailings I can deduce that it was along > the lines of dig @victim -t ns www.alternic.net. Where www.alternic.net had > duff A records. yes. > 2) What were/are the symptoms of this attack? www.internic.net resolving to > www.alternic.net? yes. > 3) If it was that easy to do, why hasn't it happened again? because that particular attack only works if you are willing to get caught. since eugene did this as a publicity stunt (which, i understand, has now begun to backfire on him since his victims didn't interpret it that way), he _needed_ to be caught. > 3a) What measures were taken (other than discussion of DNSSEC, or lack of > it) to 'cure' affected servers? upgrade to bind-4.9.6 or bind-8.1.1. > 4) How can I check for cache corruption? "dig @0 www.netsol.com a" and "dig @cache00.ns.uu.net www.netsol.com a" and check for differences. > Apologies if any of the above sound moronic or ill-informed; extracting > facts from reams of "what is a backhoe" mail list is a painfully slow task. > Time for some filters I think... no apologia needed. public explainations of this attack have been poor, even and especially by me. i'm grateful for the opportunity to improve on that.

3 2