- Test - lists.nanog.org

Re: The SWAMP
by Bradley Dunn 11 Sep '96

11 Sep '96

> From: Eric Ziegast <ziegast(a)zee.im.gte.com> > To: nanog(a)merit.edu; namedroppers(a)internic.net > Subject: Re: The SWAMP > Date: Monday, September 09, 1996 7:47 PM > In cron: > > # pick a random time once a week > 31 10 * * 4 /usr/sbin/update-root > # some other time during the week > 23 20 * * 6 /usr/sbin/named.restart > > The shell script (off the top of my head): > > #!/bin/sh > tmp=/tmp/rs$$ > trap "rm -f $tmp" 1 2 3 14 15 > chdir /etc/namedb > ncftp -a -d 600 -g 5 ftp.root-servers.net:/named.root > if [ ! -r named.root ]; then > Mail -s "Could not get root nameserver list" hostmaster > fi > diff root.cache root-servers > $tmp > if [ -s $tmp ]; then > mv named.root root.cache # fails if couldn't download > Mail -s "Root server update" hostmaster < $tmp > fi > rm -f $tmp I don't like "automatic" updates. Sure it is convenient, but for something as mission-critical as name service, I would hesitate to automatically trust whatever happens to be at ftp.root-servers.net:/named.root on any given day. I would want to review it first. Plus, on most BSDish systems /etc/crontab is world readable by default. A cracker would know the exact time to attempt to hijack the FTP session and insert: . IN NS you.got.hacked.net. you.got.hacked.net. IN A 10.1.2.3 -BD

4 3

Re: Re[2]: SYN floods (was: does history repeat itself?)
by Sharif Torpis 10 Sep '96

10 Sep '96

On Sep 10, 2:07pm, Alexis Rosen wrote: > Subject: Re: Re[2]: SYN floods (was: does history repeat itself?) > > Also true. As I said before, I don't know about the Ascends, but I do know > that the Xylogics boxes we use have the capability but probably not the > capacity. When all ports are connected at 28.8, CPU usage can hover in > the high 80% range. Adding filters would probably be a bad idea. > > That's why I was talking about filtering at a router just upstream from > the dial-access box. > > FWIW, even with a thousand very busy modems, I'm pretty sure that even a > small cisco is up to the job. They just don't generate all that much traffic. > >-- End of excerpt from Alexis Rosen The Ascends can also do this but I agree that you wouldn't want to filter at the NAS. Logistical reasons are reason enough to filter at an upstream router where the dialup traffic is aggregated. -- Sharif Torpis (storpis(a)pbi.net) \ | / P A C I F I C Pacific Bell Internet -->*<-- B E L L Network Engineering / | \ I N T E R N E T San Francisco, CA USA

2 1

SYN attack at Panix and elsewheres; responses to earlier mail
by Alexis Rosen 10 Sep '96

10 Sep '96

Somehow I thought I could get away with not reading this list, since Alec was reading it. Dunno what I was thinking. :-) Now I've joined... Thanks to Avi and Perry for speaking so acurately for me over the last few days. They've said most of what I would have, and saved me a lot of time when I couldn't afford it. I've scanned the back mail about SYN attacks and I have a few comments. Justin asked about CPU usage on dialup servers. I have no idea what the Ascends are like, but I suspect that within a single POP it's probably OK to do your filtering at your core router(s), for those core routers that connect things like MAXes to your backbone. Unless you have a lot of customers with their own IPs, you can get away with filtering against your own IP numbers (or whatever subnet you've allocated to the box(es) connecting to the core router) on the outbound access-list for the upstream port or ports on that core box. (Actually, it probably wouldn't be considered a "core" router but rather an intermediate aggregator, if you have enough MAXes or Annexes or whatever. But that's irrelevant.) Of course, you can still lose: If you have a bunch of MAXes all on an ethernet and you filter at a cisco that feeds them into your backbone, any customer on one can attack any other customer on any other of those boxes. But that's MUCH less dangerous than having no filters at all, and a whole lot easier to track down (you know the attack is local to the victim). Someone else (sorry, I don't remember who) asked how the SYN floods can be tracked down. It's late so I'll skip some details for now (I can fill in the blanks later if necessary), but there are two ways I can think of. I figured out the first Friday night while trying to get a handle on what was happening to us. You can trace the packets backwards, one router at a time, by using "debug packet ip <a.l.> detail". The a.l. permits attacking packets (like "access-list 198 permit tcp any host <blah> eq smtp" and "access-list 198 deny ip any any") and nothing else. This will show you all the offending packets *AND* the physical interfaces they arrived on and were sent to. The one fly in the ointment is that ciscos don't "see" all the packets that go through them. To make the cisco see the packet, so it can provide the debug output for it, it to filter *against* it on one of the interfaces. So you create another a.l. which is the exact opposite of the debug a.l. and apply it to the interface the packet is exiting. Once you know the physical port the packet came from, you know the next router (if it's a T1/T3) or at least the broadcast net it's on; usually that net will be very small, only 2-4 hosts, and you can try each one to pick up the trail. Of course if you trace it back to a gigaswitch or something like that you may have some trouble; maybe the best way to deal with this is to brute- force it: look for the packet on everything that sends data into the switch that the packet is exiting. There's probably a better way, but I haven't thought of it... The other technique is something Avi came up with. It involves playing games with static routes to Null0 for the attacked host on routers which may be carrying the attacking packets. But if you do this you have to make *damn* sure you don't redistribute that static route (at least) into your IGP... There's also a way to use route announcements to get a similar effect but you have to be peering with a lot of people at someplace like MAE-E to use it usefully. I'll let Avi provide details rather than mangle this myself, given the hour. Of course both techniques are quite labor-intensive. That's why we can't afford a reactive attitude to these sorts of attacks. I want to echo Avi and Perry's call for customer packet filtering on border routers. If you still think that waiting for an attack and then tracking down the perp is a good idea, I suggest that you shut down half your site for four days and see how your customers like it. If anyone wants I'd be happy to shut their site down for them. Free service. :-) Anyway, sorry for the lousy sentence structure and singular/plural disagreements. It's been a LONG week without much sleep. /a

1 0

Re: Work Work Work
by Scott Stansbury 10 Sep '96

10 Sep '96

-> > For those not at the last IEPG mtg, this was discussed with the trade off -> > being 13 host routes vs coordinating root cache updates for 20-30 million -> > end nodes. -> -> Luckily, as Havard points out, this seems to work now. Don't folk have real -> work to do? -> Unfortunately, this doesn't work now. Our name servers get tens of thousands of hits a day for a former root, c.nyser.net, a machine that hasn't existed for quite some time. Scott... *************************** Scott Stansbury NYSERNet, Inc. 125 Elwood Davis Road Syracuse, NY 13212-4311 315-453-2912 Ext. 253 scotts(a)nysernet.org ****************************

8 8

Re: The SWAMP
by Nick Hilliard 10 Sep '96

10 Sep '96

> How about allocating some "good sounding" IP addresses for them, > (like 1.0.0.x/32) and hard-wiring them into resolver code? Would > save quite a lot of configuration headaches for newbies. Hardwiring anything like this into a system like DNS sounds like a really bad idea if only for the simple reason that DNS is not just used on the Internet, but also within private networks. Having hardwiring IP numbers in this case would cause headaches of unimaginable proportions. Nick

5 4

MAE-East still no generator
by Nathan Stratton 10 Sep '96

10 Sep '96

Check out the nice graph of MAE-East for that last 5 days. When are they going to get a generator installed? Why can't you pay for a generator when you are charging +30 people $5,700 a month? Nathan Stratton CEO, NetRail, Inc. Tracking the future today! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales(a)netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- "Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own." Matthew 6:34

20 43

Re: The SWAMP
by Vadim Antonov 09 Sep '96

09 Sep '96

Nick Hilliard <nick(a)eunet.ie> wrote: > How about allocating some "good sounding" IP addresses for them, > (like 1.0.0.x/32) and hard-wiring them into resolver code? Would > save quite a lot of configuration headaches for newbies. >Hardwiring anything like this into a system like DNS sounds like a really >bad idea if only for the simple reason that DNS is not just used on the >Internet, but also within private networks. Having hardwiring IP numbers in >this case would cause headaches of unimaginable proportions. Er. This is _root zone_. You either have access to it, or not. Those are completely separated name spaces. If you have an intranet you may want to have internal routes for local roots. A *lot* less headache when all namseservers on all machines work out-of-box without system administrator running in circles changing addresses. Anyway, i would rather have an override for root NS addresses, instead of required configuration. How many root caches out there are configured with all correct addresses? My estimate is below 20%. --vadim PS. Thanks to those who pointed that it is not resolver but rather cacheing NS.

1 0

Re[4]: SYN floods (was: does history repeat itself?)
by pcalhoun＠usr.com 09 Sep '96

09 Sep '96

Justin, I understand and share your concern. Unfortunately I cannot tell you since I have no idea what you use. In our case, we test them with unrealistic loads (all ports running ttcp) which is much more than a typical user will ever do. Adding such a filter is quite minimal in our case since our algorithms are pretty tight. Pat R. Calhoun e-mail: pcalhoun(a)usr.com Project Engineer - Lan Access R&D phone: (847) 933-5181 US Robotics Access Corp. ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: SYN floods (was: does history repeat itself?) Author: "Justin W. Newton" <justin(a)erols.com> at Internet Date: 9/9/96 3:30 PM At 01:19 PM 9/9/96 -0500, Pat Calhoun wrote: >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Description: cc:Mail note part > > Perry, > > This is actually quite simple to implement on Dial Access Routers, > and obviously this is the best place to add the filtering. How much spare processor do a lot of the dial access servers have left on them? I am somewhat concerned about the amount of processor left on my dial access servers. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: Re[2]: SYN floods (was: does history repeat itself?)
by Justin W. Newton 09 Sep '96

09 Sep '96

At 01:19 PM 9/9/96 -0500, Pat Calhoun wrote: >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Description: cc:Mail note part > > Perry, > > This is actually quite simple to implement on Dial Access Routers, > and obviously this is the best place to add the filtering. How much spare processor do a lot of the dial access servers have left on them? I am somewhat concerned about the amount of processor left on my dial access servers. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: The SWAMP
by Vadim Antonov 09 Sep '96

09 Sep '96

Geoff Huston <gih(a)aarnet.edu.au> wrote: >My humble suggestion is forced non-local proxy aggregation. That is unfortunately more easily said than done. I can recite PSI's blocks if you wake me up in the night... --vadim

1 0