- Test - lists.nanog.org

This list
by Al Smith 31 Jul '97

31 Jul '97

I thought this list was created to be used in mind for reporting problems with the internet as well as failure's and cuts. Not to be a bitch board for people to complain. -Al Smith p.s. This is the only bitch you will see from me.

2 1

nic.ddn.mil
by sk8r steve 31 Jul '97

31 Jul '97

Is it me or is the .mil nic now messed up?

1 0

This list -
by Chris Yarnell 31 Jul '97

31 Jul '97

Hi, Is it me, or has the quality of the posts on this list gone further south than at any other time in recent history? <sigh> ---- Chris Yarnell - cyarnell(a)nasa.gov - 415-604-0726 NASA Network Information Center & GLOBE - NASA Ames Research Center

1 0

Re: [nsp] known networks for broadcast ping attacks
by Joe Provo - Network Architect 31 Jul '97

31 Jul '97

jra(a)scfn.thpl.lib.fl.us wrote: >On Wed, Jul 30, 1997 at 10:15:24PM -0700, Joe Rhett wrote: >> > .255 is _always_ a broadcast address, no? >> >> Uh, no. If the bit mask is smaller than /24, any given .255 address could >> be legitimate. > >RFC 917 and RFC 922 (admittedly old) suggest strongly that this isn't a >good idea; I'm still searching to find the reference I remember that >specifically deprecates it. This isn't a problem, nor is it recent/CIDR-specific. Given a /16 ('class B') that everyone and their brother had not even 5 years ago and a flat network, X.Y.n.255 isn't only a valid address for all values of "n", but is in real live use today. The only reason it wouldn't be "a good idea" is because we network folks have to be able to react and change things as needed, and there's less pain in skipping a few addresses so you stay on the "clean" bit boundaries then painting yourself into a corner WRT possible future subnetting and needing to renumber folks. I would say also because "vendors can be counted on to make nasty assumptions", but I can't think of any off the top of my head that, given the right address/mask pair, would make the wrong assumption (except those known to err in favour of being classful). >I guess it matters, since I'm not aware of routers that allow the >specification of filter rule addresses with /netsizes. I don't follow the significance of your statrement. There's no true difference between specifying masks by noting the bitsize or writing out the actual masks in octets; consider the former "reasonable-to-humans shorthand" and the latter akin to long division. Aside from that, it's an IP world, where specific implementation is meaningless... but off the top of my head, Compatible Systems boxes us /xx notation in their filters. Cheers, -- Joe Provo, Network Architect 800.763.8111 x3006 Network Operations Center Fax 508.229.2375 UltraNet Communications, Inc. <jprovo(a)ultra.net>

1 0

Re: TLD .ES screw up
by Eric Germann 31 Jul '97

31 Jul '97

At 06:01 PM 7/30/97 +0200, Miguel A. Sanz. RedIRIS/CSIC wrote: >So my questions now: > >Does any one know a direct way to reach the InterNIC technical staff to solve >this kind of urgent problems? > Flaming them on NANOG seems to work, but you get singed in the process also. Try markk(a)internic.net. He seemed helpful. From him: "Hostmaster receives at least 20K pieces of mail a day. If you have an operational issue of this nature, feel free to send it to action(a)internic.net. The people who are responsible for monitoring the roots also read that box." Let us know how [un]responsive action(a)internic.net is! >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? > Apparently they're still drafting those. >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> > > ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

3 2

Re: [nsp] known networks for broadcast ping attacks
by prue＠ISI.EDU 31 Jul '97

31 Jul '97

A cheap solution for routers who are not expected to forward LAN broadcast packets is to put a host route in the router to route packets to the broadcast address to null0. This reduces the per packet overhead of an access list and silently discards these bad packets. Walt

2 1

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

31 Jul '97

Ok i would like to clear this all up. First off, That is not my sig. The time this was sent i was out of the office, my computer was locked down, and there was only my BOSS in the office. The rest of the night we were at TGIF eating. Reid left and then 2-wayed me that "I" was dead because of this email that I had sent. The Sig, TIME and all wrong. The person who did this was probably pissed at my email earlier about how smurf.c got out. So once again to clear this up, this was not me and hope that I havent offended anyone here! If you have any questions, please email me back and not to the list...its about time i install pgp! :) --- a very pissed off Steve Nash Systems Engineer / Security Administrator Lightning Internet Services LLC snash(a)lightning.net http://www.lightning.net On 31 Jul 1997, Michael Shields wrote: > In the future please be careful not to leave your terminal logged in. > > > > > Sorry if my previous posts confused some people [regarding ICMP]. Let me > > just state right now that I wanted all of NANOG to know how 31337 I am for > > knowing the author of a ping flooder. This certainly puts me in the category > > of "in the know"!@#. Also, I figured I would dispell my vast knowledge and > > experience regarding ICMP; since I know none of you here have any idea at > > all what that is. What would you all do if I wasn't here to mentor you all? > > > > For those that aren't lucky enough to know -- I go by MayTrickZ on IRC, and > > I have t0mbs of knowledge regarding the WaR3Z underground. What I know could > > fill the pages of a comic book so beware!@# > > > > MayTrickz "Has anyone seen my IRC server?" d00d > > > > +!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#!@#+ > > | Every ISP on the NET needs a WaReZ d00d, for LIGHTNING, I'm it! | > > | Steve Nash, snash(a)lightning.net MayTrickZ@IRC + > > +!#$!#@$!#@$!#@$!#$!@#!@#$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@$!@+ > > > > -- > Shields, CrossLink. >

1 0

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