- Test - lists.nanog.org

Re: customers and web servers and level one naps
by Justin W. Newton 11 Sep '96

11 Sep '96

At 03:03 PM 9/10/96 -0700, Michael Dillon wrote: >On Tue, 10 Sep 1996, Justin W. Newton wrote: > >> >Therefore, you should only connect trusted pieces of equipment to a >> >level-2 media unless it is being used as a point-to-point media. Lets use >> >Ethernet as an example. If you connect a customer web server to an >> >Ethernet then they can sniff any traffic that goes by and possibly do >> >nasty things like spoofing. Even if they would never do such a thing they >> >may be hacked by somebody who would do such a thing. So it is not a good >> >idea to share a level 2 media in this way. >> >> The MAE's are switches. Unless you are sending super secret BROADCAST >> traffic the security implications you are mentioning are non-existant. > >What about people hacking MAC addresses or screwing around with ARP and >BOOTP? He was asking about attaching a customer web server to the exchange >so presumably anything could be done on that box. The same can be done with some routers. Justin Newton Internet Architect Erol's Internet Services

1 0

Re[2]: SYN floods continue
by pcalhoun＠usr.com 11 Sep '96

11 Sep '96

At the expense of sounding very redudant, filtering at the edge will allow Mobility to work within your network since you do not need to filter on the outbound router based on a source address which belongs to your address space (and clearly in the case of mobility, the station has an address which belongs to his home network). 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: SYN floods continue Author: Sean Donelan <SEAN(a)SDG.DRA.COM> at Internet Date: 9/11/96 8:18 AM >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

There can be security at Level 2
by Mike Trest 11 Sep '96

11 Sep '96

I have recently read these statement on this list: >>[snip] There is no security at level 2. >Yes there is rudimentary security at L2. It's called MAC-based filtering, Full IP filtering (to port level) is in use today at OC3 and OC12 at the edges of some relatively large ATM clouds. [Yea, I know its IP over ATM, but please do not waste energy on that flame-track.] It works with lots of ACL lists and multiple interfaces simultaneously. In one application it is working in conjunction with wire speed per-VC encryption to boot! I will provide a vendor contact via EMAIL to any who request. ..mike.. Mike Trest, ATMNET Voice: 619 643-1805 5440 Morehouse Drive Fax: 619 643-1801 San Diego, CA USA 92121 Pager: 619 960-9070

1 0

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 10 Sep '96

10 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