July 1997 - Test - lists.nanog.org

known networks for broadcast ping attacks
by Edward Henigin 12 Aug '97

12 Aug '97

Here's a list of KNOWN NETWORKS that are being used to ping flood other networks. If one of your networks is in here, FILTER BROADCAST PINGS NOW FROM ENTERING YOUR NETWORK. YOUR NETWORK IS BEING USED TO ATTACK OTHER NETWORKS. In my original e-mail, I noted that I suspected that there was a list of known networks that could be used to attack other networks. It appears my suspicion has been validated. This is from source code for 'smurf.c', which is used to generate the ICMP broadcast pings, as I described in an earlier e-mail to this mailing list. -----Forwarded message----- /* * * smurf.c by TFreak [21:52 - 07/28/97] * * spoofs icmp packets from a host to various broadcast addresses resulting * in multiple replies to that host from a single packet. * * mad head to: * nyt, soldier, autopsy, legendnet, #c0de, irq for being my guinea pig, * MissSatan for swallowing, napster for pimping my sister, the guy that * invented vaseline, fyber for trying, knowy, old school #havok, kain * cos he rox my sox, zuez, toxik, robocod, Bug_Lord, and everyone else * that i might have missed (you know who you are). * * mad anal to: * #madcrew/#conflict for not cashing in their cluepons, EFnet IRCOps * because they plain suck, Rolex for being a twit, everyone that * trades warez, Caren for being a lesbian hoe, AcidKill for being her * partner, #cha0s, sedriss for having an ego in inverse proportion to * his penis and anyone that can't pee standing up. * * disclaimer: * I cannot and will not be held responsible nor legally bound for the * malicious activities of individuals who come into possession of this * program and refuse to provide help or support of any kind and do NOT * condone use of this program to deny service to anyone or any machine. * This is for educational use only. Please Don't abuse this. * */ [.. code deleted... EJH ] /* add your own broadcast ips, just make sure to end with NULL */ char *bcastaddr[] = { "206.154.141.255", "165.154.1.255", "205.139.4.255", "198.3.101.255", "204.71.177.255", "255.255.255.255", "207.137.200.255", "192.41.177.255", "206.13.28.255", "144.228.20.255", "206.137.184.255", "192.41.177.255", "206.154.141.255", "165.154.1.255", "206.13.28.255", "129.16.1.0", "198.32.186.255", "205.206.120.255", "206.186.21.255", "204.212.36.255" "149.142.13.255", "208.132.231.255", "129.82.103.255", "130.63.236.255" "130.113.64.255", "198.53.145.255", "205.211.8.255", "204.186.99.255", "208.131.162.255", "130.132.143.255", "128.135.181.255", "204.162.96.0", "205.180.58.255", "206.86.0.255", "128.2.72.255", "199.227.0.255", "199.103.128.255", "208.218.130.255", "208.150.60.255", "206.26.128.255", "199.0.65.255", "207.69.200.255", "207.228.64.255", "204.247.0.255", NULL }; [.. code deleted... EJH ] -----End of forwarded message-----

16 26

Non-ISP companies multi-homing?
by netops 04 Aug '97

04 Aug '97

Does anyone know of any non-ISP companies that have decided to multi-home? Is this a major trend for non-ISP companies running mission-critical applications on the Internet? So far, I only know of a couple, with PointCast being one of them. Thanks, Lincoln Silver FlyCast Communications

12 11

Re: how to protect name servers against cache corruption
by Thomas H. Ptacek 01 Aug '97

01 Aug '97

> 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(a)enteract.com] ---------------- "If you're so special, why aren't you dead?"

10 16

how to protect name servers against cache corruption
by Paul A Vixie 01 Aug '97

01 Aug '97

a BIND 4.9.6 or 8.1.1 server is immune. so, you could upgrade. to so do, see http://www.isc.org/isc/ which will lead you to ftp://ftp.isc.org/isc/. (the root name servers are all running modern software at this point.) alternic's corruption works by locating authoritative name servers via the "NS RR"'s published in various zones. if you run these as authoritative- only (recursion disabled) then they will never fetch any data from anywhere. (the root name servers are configured this way, for example.) the downside is that you can't list such nameservers in your "resolv.conf" files or PC equivilents (Control Panel\\Networking\\TCP IP Settings, or some such rot.) this means you need more name servers if you separate recursive from non- recursive.

18 49

Re: disabling directed broadcasts
by rja＠corp.home.net 31 Jul '97

31 Jul '97

On Jul 30 21:16, Edward Henigin wrote: } Subject: disabling forwarding of directed broadcasts % this does work as you'd expect (it prevents the cisco % from framing an IP broadcast packet into an ethernet broadcast % frame) BUT unfortunately it can break Windows networking, as well % as BOOTP/DHCP, depending on how you're set up. BOOTP/DHCP does NOT need directed broadcast forwarding enabled to work properly. The "helper-address" function and the DHCP RELAY code take care of BOOTP/DHCP traffic. Implementations of BOOTP/DHCP don't require enabling forwarding of directed broadcast packets. I've verified this experimentally in a previous life. I also have (past) experience with a network running MS/NetBIOS cruft through routers with forwarding of directed broadcasts DISABLED. It worked fine. If there is some corner case I've missed that requires forwarding of directed broadcast packets, it would be useful for that specific case to be enumerated _in detail, in public_. Ran rja(a)home.net

2 1

Re: thats stupid
by Paul G. Donner 31 Jul '97

31 Jul '97

Does this, among a million other things I've seen on this list lately, belong on this list? At 05:49 PM 7/29/97 +0000, Pam Evon wrote: >dear nasa.com,my name is glen.i like tecnology type things.i like to >go to nasa.gov to see the new pathfinder pictures.but its a bit >confusing to see the differince between nasa.com and >nasa.gov.kix.country 92.9 told people to go to nasa.gov to see the >pathfinder pictures and not to go to nasa.com because they have >pictures of women having sex and naked women.yours truly glen. > > > > > >ps. e-mail me at pevon(a)cyberstreet.com >thank you > >

1 0

[FYI] Broadcasts at NAPs
by Lyndon Levesley 31 Jul '97

31 Jul '97

This ICMP discussion reminded me that we've been logging broadcasts for a while at ME to see what percentage of traffic they represented and what it was (the wrong way round to track back thru ICMP DoS attacks). If anyone's interested, the results are : 192.41.177.255 (254376 matches) 255.255.255.255 (1694830 matches) any other dest. (1047899270 matches) which is 0.18% of the total accounted for by broadcasts. Bad, of course, but not as bad as I thought. I guess the bigger the provider the smaller percentage of total (that 1billion is total input on our FDDI since I applied the list, rather than total packets on the LAN) I'm assuming that a billion packets is enough to be a representative sample. A bit of a breakdown from the logs : Split of broadcasts is ICMP 12% UDP 88% (actually, there were 5 packets for protocol 9 (private IGP?) but that's neither here nor there) Port breakdown (based on a smaller sample to save resources) ICMP ---- I won't name names (I'll contact people later on probably) but 99.2% of the ICMP traffic comes from one provider (two routers) and is directed at 255.255.255.255. That should be fairly easy to stop. Is there any good reason for a router to ping the broadcast address of a NAP ? UDP --- PORT: 53 PACKETS: 5 PORT: 67 PACKETS: 5364 PORT: 123 PACKETS: 9950 PORT: 161 PACKETS: 12 PORT: 513 PACKETS: 6635 PORT: 520 PACKETS: 19486 PORT: 5841 PACKETS: 4344 -------------------------------- 45796 53 = DNS (badly configured cisco, but temporary so that's OK) 67 = BOOTPS (!) (probably misconfigured cisco again ;) 123 = NTP (ditto!) 161 = SNMP (?? - god knows why this would happen) 513 = who? 520 = routed ( oh dear) 5841 = ??? (is this CDP?) The upshot would seem to be that even with loads of misconfigured/ clueless stuff going on, random traffic is so insignificant that it wouldn't affect the performance of the NAP infrastructure. Cheers, Lyndon -- Penis Envy is a total Phallusy.

2 2

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