- Test - lists.nanog.org

NetSCARF Workshop Oct. 23
by William B. Norton 11 Sep '96

11 Sep '96

Hi all - The Merit Network Statistics Collection And Reporting Facility (NetSCARF) Project will be hosting a free workshop in the afternoon on the day *before* NANOG. We will provide an overview of the (1.x and October release 2.0) technology (see agenda below), future release plans, and open the floor to feedback and discussion about how you would like to see the product evolve. The NetSCARF SCION software package is a public domain network statistics collection and reporting package that uses SNMPv1 or SNMPv2u to collect stats from network devices and reports the network performance on the web. Release 2 is scheduled to be released early October and features automated stats compression and an updated OpStats client and server. For this first workshop, we have openings for the first fifty (50) that register at http://www.merit.edu/~netscarf. If you get a chance, read the Connexions NetSCARF article on our web page before the workshop. The second workshop will be held in January or February 1997 and include a discussion of the 3.0 release. If you have any questions, please feel free to e-mail me at wbn(a)merit.edu or call at 313.936.2656. Thanks, Bill ======================================================================== NetSCARF Workshop - October 23, 1996 1-5PM ------------------------------------------ Welcome, Model and Rationale - Bill NSFNET Operations 3 Graphs of proven utility Proposal to RAC Architecture Overview - Andy NetSCARF Model - abstractions, functionality divisions, etc. Scollect Component - Bill SNMP Overview Scollect Task Storage of Stats: Rtdata Tree Scook Component - Tom Motivation behind aggregating data (statistics on file sizes, etc.) The four aggregate files e-mail report New compression process OpStats Model - Andy Components of the RFC ScServer Component - Adam ScClient, Scache Component - Kevin How the client can be extended How Existing Reports are generated NetSCARF Futures - Discussions - all Our visions, customer visions ---------------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 936-2656

1 0

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

11 Sep '96

Alec, I agree but if the NAS has the ability of raising a flag if a malicious user (done with the user of a filter at the edge) tried to create havoc, it would make your life much easier in not only tracking, but possibly taking legal action. 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[4]: SYN floods (was: does history repeat itself?) Author: "Alec H. Peterson" <chuckie(a)panix.com> at Internet Date: 9/10/96 5:05 PM Pat Calhoun writes: > > Alexis, > > However if you are filtering on your outbound router to the net, > there is still the possbility that a malicious user could spoof > addresses as long as they belong to your address space. By moving the > filter out to the edge (when you have the equipment) this eliminates > that problem as well. This is true, but if it is a valid host, the invalid SYNs will do nothing, because the source host will send a RST and the almost-connection will be torn down. And if it isn't a valid host, it will still be _much_ easier to track, because you know in general where it's coming from. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie(a)panix.com | Panix Public Access Internet and UNIX| |Network Administrator/Architect | New York City, NY | +------------------------------------+--------------------------------------+

1 0

Re: SYN floods continue
by Sean Donelan 11 Sep '96

11 Sep '96

>Until this problem becomes gigantic enough that it affects large networks >such as MCI, Sprint, UUNet, etc. I don't predict much will be done. History is such a strange beast. I believe one of Sprint's engineers called for this type of filtering several years ago. AT&T's WorldNet advertises something called "source address assurance" on their network. ANS did some filtering at one point, but I was never very clear what exactly they were checking. I don't think you can blame the lack of action solely on the large networks. Raise your hands, how many little providers didn't have outbound filters/access-lists on their networks before you were attacked? How many didn't have inbound filters/access-lists on their customer networks? The Mobile IP folks complained this would prevent their work last time this came up. Since then firewalls have led to the increased use of tunnelling for Mobile IP, so this may not be as much of a concern now. This might be a nice addition to RtConfig. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

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

11 Sep '96

At 02:12 PM 9/10/96 -0400, Alec H. Peterson wrote: >> >>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. > >Could be, although I'd want to see this before I bet the farm on it. >I'm not sure how efficient crisco's filtering algorithm is... > I have found that 2500's do not have the processor for even basic filtering when sitting in front of several hundred modems. 4700's on the other hand (and 7200's) have the ability to handle the job with little difficulty. Justin Newton Internet Architect Erol's Internet Services

4 3

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