September 1996 - Test - lists.nanog.org

Re: SYN floods continue
by Justin W. Newton 11 Sep '96

11 Sep '96

At 06:43 PM 9/11/96 +0000, Larry J. Plato wrote: >If you can write a SYN flooder you can trivialy add the call to >to generate a random source address.... > >IMHO this is not a win. Right, but if I am only allowing addresses which I own to leave my network, and everyone else does the same, someone could only forge source addresses which come from inside my network if they are dialed in to me. This makes he narrowing down process much easier. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: SYN floods continue
by Vadim Antonov 11 Sep '96

11 Sep '96

Alex Rudnev wrote: Hi, Alex! >BTW. Some time ago (when we used PC based routers and had all sources) we >discussed the same problem. One of the best solutions to prevent many kinds of >hacker's weapons is to allow customer send packets with SRC address ONLY >if this (SRC) address have routing via the same interface. This control is possible >only for one-homed customer but is effective enougph to prevent TCP spoofing, >many SYN, PING, UDP etc attacks and does allow ISP to determine the source of >any internet attack. I stated many times that it would be desireable default behaviour for routers to never accept packets with source addresses for which it doesn't have route back thru the same interface. That prohibits IP src spoofing (and asymmetrical paths). When asymmetrical routing is what it desired that safeguard could be disabled on per-interface basis. In most networks asymmetrical routing is an indication of a bug in an IGP configuration, so early detection of the configuration problems would be an additional benefit. --vadim

1 0

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