- NANOG - lists.nanog.org

Summary: Operational question: Building filters from IRRdbs
by Alex Bligh 13 Jan '99

13 Jan '99

As promised, an anonymized summary: I asked: >* Does anyone actually do build filters without running > their own complete database mirror, i.e. do they rely real > time on a database working. If so, which one? > >* Does anyone let this config their routers automatically? To peers > customers, transits, or all three? Or do you rely on humans to > reinstall the lists once autogenerated? > >* If it's just a fact of life that occasionally this thing turns up duff > data, and if people are in general doing automatic installation, what > data validation heuristics are used? A good few responses. 1. I was foolishly using version 4 which relies on RPSL servers which are not yet in production, rather than version 3 which uses RIPE-183. Currently all users who mentioned it use version 3 tools, and whois.ra.net as a serer, except one who uses RIPE and 'internal databases'. Noone mentioned running a mirror server. 2. Everybody claimed they sanity checked the output from peval, either manually, or automatically. Substantial changes in length were mentioned as indicators to 'pass to manual processing'. Some respondants also suggested that when automatically updating routers, substantial config-length changes were also detected, and caused a passing to manual processing. Some reasonable algorithmic detail was documented, which differed substantially between respondants. Amusingly there were also differences between two staff members of the same ISP. 3. In general, filtering was restricted to customers or customer-like entities. Some respondants suggested they used the same technology for small peers or ones they couldn't trust. 4. Noone suggested their techniques (including whatever level of human validation) were sufficiently fallible to cause increased chance of 'fact of life' breakages. Thanks to all who responded. -- Alex Bligh GX Networks (formerly Xara Networks)

1 0

Re: Huge smurf attack
by Dean Anderson 12 Jan '99

12 Jan '99

At 05:10 PM 1/12/1999 -0500, rzewski(a)us.ibm.com wrote: >Ugh. When you compare the length of time Kevin Mitnick has been unfairly >imprisoned without a trial (see the clock on www.2600.com) with the length >of time SMURF attacks have been going on, you surely are 100% incorrect. Just read the page on Mitnick. I've been getting most of my info from the media, too. Apparently, I was very misled about Mitnick. While breaking into computers is wrong, so is violating his right to a quick and speedy trial. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

source filtering
by Jared Mauch 12 Jan '99

12 Jan '99

I'm interested in what providers actually do source filtering of their customers. Including: 1) Using access-lists to filter your customers 2) Using the "ip verifiy unicast reverse-path" Cisco feature (it's in 11.1CC images when you use CEF, so I don't get a flood of e-mails) 3) Using other router vendors and features you have to filter source addresses. I'd like to summarize this all and start a quest to fix providers that don't source filter (as people quest against spam, and against smurfable network blocks). - jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

7 10

RE: InterNIC problems with Contact modifications.
by ryan＠sbserver.net 12 Jan '99

12 Jan '99

I have been getting problems with interNIC on mods and new domains. Something must be wrong over there? They appear to be having major template problems. Anyone have any answers? -Ryan -----Original Message----- From: John Fraizer [mailto:John.Fraizer@EnterZone.Net] Sent: Tuesday, January 12, 1999 1:01 PM To: nanog(a)merit.edu Subject: InterNIC problems with Contact modifications. Is anyone else experiencing problems updating contact information at the internic? I have been attempting for two weeks now to update information on three contacts. The templates I'm sending in clearly say "Modify" on line 0a and in the subject line. They keep being returned with a message like so: Greetings, The contact shown below has already been registered. You can view the related information at the URL http://rs.internic.net/cgi-bin/whois by typing the contact's last name, first name in the WHOIS query form. If the information in WHOIS is incorrect or you would like to choose a password or use PGP, please submit a modification for your contact record by completing the form at the URL: http://rs.internic.net/cgi-bin/itts/handle InterNIC Registration Services email hostmaster(a)internic.net I'm just about ready to drive to VA and see if I can convince them in person just how frustrated I am with their incompetence. ------------------------------------------------------------------ ML.ORG is gone. Check out http://www.EZ-IP.Net - It's *FREE* ------------------------------------------------------------------ Get your *FREE* Parked Domain account at http://www.EZ-Hosting.Com ------------------------------------------------------------------ John Fraizer | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:John.Fraizer@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation PGP Key fingerprint = 7DB6 1CA2 DAA6 43DA 3AAF 44CD 258C 3D7E B425 81A8

1 0

Re: Solution: Re: Huge smurf attack
by Dean Anderson 12 Jan '99

12 Jan '99

At 12:39 PM 1/12/1999 -0800, Dan Hollis wrote: >On Tue, 12 Jan 1999, Dean Anderson wrote: >> And yes, some customers may in fact want or need directed broadcasts on. > >Leaking rfc1918 onto the public internet is not acceptable, directed >broadcasts enabled or not. Agreed. We block anything sourced from rfc1918 outbound, among other things. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: source filtering
by Havard.Eidnes＠runit.sintef.no 12 Jan '99

12 Jan '99

> > 2) Using the "ip verifiy unicast reverse-path" Cisco feature > > (it's in 11.1CC images when you use CEF, so I don't get a flood > > of e-mails) > > I'm sure far more people would source filter if Cisco put this > in CPE routers. If I'm not terribly mistaken that'll happen (or has happened, depending on your view) with 12.0. Note that in 12.0, Cisco defaults to "no ip directed-broadcast", a good thing IMHO. - Håvard

1 0

Re: Huge smurf attack
by Dalvenjah FoxFire 12 Jan '99

12 Jan '99

On Tue, Jan 12, 1999 at 05:12:22PM +0000, Michael Shields put this into my mailbox: > In article <19990111101351.04195(a)dragonlair.dal.net>, > Dalvenjah FoxFire <dalvenjah(a)DAL.NET> wrote: > > Much as I hate to say it, this seems to be one area where industry > > self-regulation has utterly failed. I don't know what would be a better > > solution; I hate to suggest government regulation. But I'm at a loss here. > > Civil liability? Possibly. I don't know of anyone who's tried suing over a smurf attack. If I could afford the lawyer and the court time I'd do it myself. All we really need is one or two good cases to establish some case law; then the rest of us can have some legal precedent to point to and say "If you don't fix your networks, you're screwed." -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "Thy wit is as quick as the greyhound's Founder, the DALnet IRC Network mouth - it catches." e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

2 1

Classfull registration in RAdb.
by batz 12 Jan '99

12 Jan '99

I am currently registering routes for the company I work for and I am wondering whether I should register customers classfull space. In getting a list of our route assignments by comparing global BGP table route origins with ARIN SWIP information, I came across a number of class-B's that belong to customers that are not doing BGP with us. All the blocks are portable space, and I am wondering whether it would be correct to create route objects with our ASN as the "origin:" or to require them to register their space and use our ASN in the "origin:" attribute of the route object. Though I understand responsibility for route registration lies with the maintainer of the block, if they choose not to create a maintainer object, other sites will not get the customers routes from the RAdb if they are generating access-lists using our policy object. If the address space is portable, but they do not have an ASN, who has the authority to regsiter the route object to a particular ASN? Thanks to Gerald Andrew Winters from Merit for his previous assistance in helping me with the policy here. I just thought that I'd bring these issues up in a public forum as they don't seem to be documented. -j -- jamie.reid | Spare Parts for the Human Appliance Chief Reverse Engineer | www.vapour.net Defective Technologies |

2 1

Re: Solution: Re: Huge smurf attack
by danderson＠lycos.com 12 Jan '99

12 Jan '99

I'm not sure what the big issue here is with the smurf attacks. If you set up some kind of access list that disables incoming icmp traffic, then turn directed broadcasts off on the interfaces, that's it. In most cases, you can't even get a packet into my AS unless its bound for dns machines or our website frontends. For those of you using Cisco gear, a simple 'no ip directed broadcast' in the interface subset will turn them off. In my mind, this takes care of all but two scenarios: 1. Your smurf attack is coming from someone within your organization, doing a broadcast while directly connected to the network. In this case, you should be able to get their ip address just by a snoop (at least on a sun box) and then you may processed to visit the offender with the clue-by-four. I once had someone who though that was a good way to inventory the machines on a network. 2. You are using some vendor who doesn't support any way of turning off directed broadcasts. From a statistics point of view, since Cisco has 87.5% of the market, most people won't find this to be a problem. I understand that only certain code revisions carry this ability on Bay gear (I want to say 11 or higher, but I could be wrong and I can't remember the code train). If you've got Torrent or something else, I don't' know but its a safe bet that if the feature isn't supported at all (doesn't matter if it is a default or not) this isn't equipment you want in your AS. Speaking from my standpoint, I sure wouldn't use it. Devin Anderson Network Engineer Lycos, Inc. Brandon Ross <bross(a)mindspring.net> on 01/12/99 02:05:02 AM To: nanog(a)merit.edu cc: (bcc: Devin Anderson/Lycos) Subject: Re: Solution: Re: Huge smurf attack On Mon, 11 Jan 1999, Daniel Senie wrote: > The proper answer to this is to disable directed broadcasts on the > routers themselves. It'd be helpful if routers came out of the box with > this feature disabled by default. Perhaps folks should talk with their > router vendors of choice and ask for this change. I have submitted a > draft into the IETF process to require this change, updating RFC 1812 > (router requirements). I'm happy to say that progress is being made in this area. When a vendor comes to us for the first time, one of things I tell them is that we will not buy their hardware until they ship with directed broadcast disabled by default. We've had a lot of success in this area, we'd have even more if others would do the same. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

4 3

Exodus name servers broke?
by Jon Mansey 12 Jan '99

12 Jan '99

Maybe this is why so many people have trouble reaching hotmail? Try it for youself. Just a tiny little . out of place....... $nslookup www.hp.com ns.exodus.net Server: ns.exodus.net Address: 206.79.230.10 Name: www.hp.com.mydomain.net Served by: - K.GTLD-SERVERS.net 195.8.99.11 net - F.GTLD-SERVERS.net 207.159.77.18 net - A.ROOT-SERVERS.net 198.41.0.4 net - H.ROOT-SERVERS.net 128.63.2.53 net - B.ROOT-SERVERS.net 128.9.0.107 net - C.ROOT-SERVERS.net 192.33.4.12 net - D.ROOT-SERVERS.net 128.8.10.90 net - E.ROOT-SERVERS.net 192.203.230.10 net - I.ROOT-SERVERS.net 192.36.148.17 net - F.ROOT-SERVERS.net 192.5.5.241 net

3 2