- Test - lists.nanog.org

SYN? GIF at 11? Nahhh...
by Michael Dillon 12 Sep '96

12 Sep '96

> This is as big a reason as any for providers to start filtering their > _outgoing_ traffic so that only addresses which could have originated in > your network can pass out of your network. And if you don't do this, very soon your provider will yank your connection and sue *YOU* for damages if not fraud. Think about it... The company who gets allocated 192.0.2/8 pays Sprint for access to the net. You pay MCI for access for the net. One of your customers launches a SYN storm and your provider identifies a certain number of packets leaving your network with 192.0.2/8 addresses which are part of the attack. Sprint gets a court order to see those records after the attack is tracked down to your network. Sprint sues you and has the police lay fraud charges against you because your network was illegally impersonating a Sprint customers network and as a result, your packets transitted a route through Sprint's infrastructure that neither you nor MCI were supposed to use. Could it happen? If that's what it takes to prevent GIF at 11 then, yes it could happen. You see there is a fundamental law of the universe that as you approach GIF at 11 the fabric of the universe stretches and distorts in a chaotic fractal manner such that you can never actually reach the point where GIF at 11 occurs. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael(a)memra.com

1 0

Re: SYN floods continueg
by Avi Freedman 11 Sep '96

11 Sep '96

> Could you provide sample CISCO syntax ACL filters to perform the above? > I'm not clear how you filter out these kind of attacks. > Thanks, > > --curtis This is actually an incoming filter... 'sho access-list 102' shows you counts on hits for each line; pretty interesting, actually. Each line says permit any kind of ip data from anywhere, from any IP address, to the network specified. For an outgoing filter you'd reverse it so it looked like 'acc 102 permit ip <our-net> <inverted-mask> any'. no acc 102 acc 102 permit ip any 198.138.103.0 0.0.0.255 acc 102 permit ip any 205.199.164.0 0.0.0.255 acc 102 permit ip any 204.193.157.0 0.0.0.255 acc 102 permit ip any 199.171.193.0 0.0.0.255 acc 102 permit ip any 199.67.58.0 0.0.0.255 acc 102 permit ip any 205.160.86.0 0.0.0.255 acc 102 permit ip any 192.135.189.0 0.0.0.255 acc 102 permit ip any 198.133.170.0 0.0.0.255 ! not all of these are /16s, I was just lazy yesterday ! eventually the 0.0.0.255.255s should become more specific acc 102 permit ip any 206.42.0.0 0.0.255.255 acc 102 permit ip any 137.239.0.0 0.0.255.255 acc 102 permit ip any 198.69.0.0 0.0.255.255 acc 102 permit ip any 206.161.0.0 0.0.255.255 acc 102 permit ip any 205.164.128.0 0.0.255.255 acc 102 permit ip any 170.115.0.0 0.0.255.255 acc 102 permit ip any 207.106.0.0 0.0.255.255 acc 102 permit ip any 199.234.208.0 0.0.255.255 acc 102 permit ip any 207.8.128.0 0.0.255.255 acc 102 permit ip any 192.157.69.47 0.0.0.0 acc 102 permit ip any 192.41.177.87 0.0.0.0 ! acc 102 permit ip any 198.32.136.82 0.0.0.0 acc 102 deny ip any any Avi

3 3

Re: SYN floods continue (fwd)
by Michael Dillon 11 Sep '96

11 Sep '96

Is this practical on a global scale? ---------- Forwarded message ---------- Date: Wed, 11 Sep 96 14:06:05 CDT From: Andrew Molitor <amolitor(a)anubis.network.com> To: firewalls(a)greatcircle.com, michael(a)memra.com Subject: Re: SYN floods continue (fwd) With fine NSC routers all over the place, one could insert a RR option into all the SYN packets flowing through them. The enclosed filter fragment will insert a RR option capable of recording the first 7 routers after this one that the packet goes through. It won't work on all our stuff, and (realistically) is enclosed for reference only. I can dream, though, eh? A little additional checking could be added to make it hard or impossible to spoof this by inserting your own RR option at the source. Basically, if you're deploying this, you strip out options on packets arriving from 'little leaf nodes that might be bad guys' before you add yours in. It would be relatively trivial to add this to, say, the freely available IP filtering in Linux. The performance hit in the core routers would only be taken for SYN packets, which are some modest percentage (less that 10?) of all packets. They'd feel it, but would probably not topple right over. With this option present, the problem or tracing it back to the source begins to look like backtracing usenet headers -- it's not easy, but it often/usually provides some useful information. It also would require lots of co-operation among ISPs. Andrew filter syn_tracking not ip_protocol in (6) break; # Get outta here if it's not TCP not ip_fo in (0) break; # or if the header's not here not tl_byte (13) mask 0x02 in (0x02) break; # if SYN not set, get out ip_option_present 0x07 break; # Get out if RR option already here # Otherwise insert a 7 hop RR option. stamp_option 0x071f0400000000000000000000000000000000000000000000000000000000; end

2 1

Re: SYN floods continueg
by Avi Freedman 11 Sep '96

11 Sep '96

> On Wed, 11 Sep 1996, Avi Freedman wrote: > > and another provider in Philly was attacked for 4-6 hours on news ports > > (pretty ineffective). > > Hi. Why was this ineffective? > > Thanks, > Chris Caputo > President, Altopia Corporation Because most providers only let their customers connect to their nnrp/nntp servers. And you can easily build a filter which allows just port-119 connects from your news peers and denies all others... Of course, that wouldn't work as well for alt.net (you guys) if you're still selling off-site nnrp access to hundreds of people. Avi

1 0

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