- Test - lists.nanog.org

Re: DoS attack.
by Tony Li 18 Jun '98

18 Jun '98

brad(a)poofy.tbn.tm (brad) writes: > If you only feel confident cutting and pasting the configuration > into your router, here is the config line: > > no ip routing ;-) Thanks, I needed that. Tony

1 0

Re: Smurf Amp Nets
by Richard Thomas 18 Jun '98

18 Jun '98

-----Original Message----- From: Jon Lewis <jlewis(a)inorganic5.fdt.net> To: Oystein Homelien <oystein(a)homelien.no> Cc: Andrew Herdman <andrew(a)whine.com>; nanog(a)merit.net <nanog(a)merit.net> Date: Wednesday, June 17, 1998 7:51 PM Subject: Re: Smurf Amp Nets >On Thu, 18 Jun 1998, Oystein Homelien wrote: > >> You need to push the "probe=" parameter to the cgi as well. What you are >> doing above is merely looking up already-registered networks in the SAR >> database. Again, you are NOT probing the networks through the SAR by >> running the above lynx command! >> >> To do what you want, you must use URLs of this form: >> >> http://www.powertech.no/smurf/probe.cgi?network=1.2.3.4&probe=PROBE > >ack! I somehow missed that when pasting the URL from Netscape into my >editor. Here's an updated version. Chris Bongaarts <cab(a)tc.umn.edu> sent >the 172.16/12 regex I was too lazy to include before. > >#!/usr/bin/perl > >while (<STDIN>) { > ($net,$junk)=split /:/,$_,2; > if (($net=~/\d+\.\d+.\d+/) && > !($net=~/^(0\.)|(10\.)|(192\.168)|(172\.((1[6-9])|(2[0-9])|(3[01]))\.)|(255\ .255\.255)/)){ > system("lynx -dump 'http://www.powertech.no/smurf/probe.cgi?network=$net&probe=PROBE'"); > } > elsif ($net=~/---/) { > die "\ndone.\n"; > } >} > >I'm using this to make sure all the nets I recently posted about are >registered. Based on the times reported by SAR, I think I'll be adding a >bunch of new nets to it. Might want to add a delay considering the amount of bandwidth they will be receiving if they tried to send out all those probes at once. In a previous message it was stated that a probe uses 4x64bytes, plus amplification by the broadcasts. I just took the SAR offline for about 4 minutes while trying running a SMALL portion of my bcasts through your script on my 28.8k modem, and it didn't even come close to completing that portion. That fact aside you won't get very accurate results if the SAR is so flooded it can't receive the replies. I would suggest they use ping -s 1 or -s 8 if the timing information is desired.

2 1

Re: GRE packets
by Sean Donelan 18 Jun '98

18 Jun '98

>Moreover, if IPSEC is in use, you can't even sniff. With IPSEC you infer things from traffic analysis. Or if you don't feel like doing grevious harm to IPSEC, you block the traffic and wait to see who complains. Many telephone companies do this type of blocking to control fraud on international calls. Your calling card will suddenly just stop working. You'll call up your communications provider, and while usually acting totally clueless, they'll re-enable your calling card. Most of the time, the spikes in traffic are fairly obvious. People share the 'secret' with their friends and like hogs at the trough they can never use it just a little. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

DoS attack.
by brad 18 Jun '98

18 Jun '98

Our network is currently experiencing DoS attacks originating from many providers (both national and local). It seems that we are seeing spurious and bursty packets coming across our network with headers that seem to contain 6 octet layer 2 source followed by four octet layer 3 source. Normally we see minimal or non-existant traffic on our network (the broadcast network) but in this case, packets of questionable integrity are lining up in our queues and our banyan-batcher doesn't have enough fabric to deal with it. Our senior network engineer (Frank Rizzo) charged me to enlist the network operating community to help fight the spread of these debilitating attacks across the internet. Please help us if you can. Here is a sample of the command (much like no ip directed-broadcast stops 'smurf' attacks) rotsb(config)#no ip routing rotsb(config)#^Z rotsb#wr m Building configuration... [OK] rotsb# If you only feel confident cutting and pasting the configuration into your router, here is the config line: no ip routing Thank you all for helping to make the internet a better place for small isps like me. B. Bork

1 0

GRE packets
by Eric Germann 18 Jun '98

18 Jun '98

Anyone have a definitive list or info on network operators who definately allow or definately disallow GRE packets across their networks. Sorry for the semi-operational content :) Eric ============================================================================= Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider "Linux.. the choice of a gnutered generation." - brad(a)poofy.tbn.tm

4 4

Re: GRE packets
by Sean Donelan 18 Jun '98

18 Jun '98

>> Perhaps to combat this, unless I'm missing something, one could justifiably >> deploy GRE filters with source & destination addresses of the exchange >> subnets. > >What's the point of this? Wouldn't it make more sense to just run a >sniffer on the exchange fabric looking for such GRE tunnels and then >kick the offending parties out of the exchange? Seems to me this has >happened at least once at LINX. It is a bit tricky figuring out exactly who can do the sniffing. There are a lot of parties, and agreements, and handshakes floating around any exchange point. In the USA, a number of communications laws were written in the days of Ma Bell. There was only one system, one network, one operator. While the Ma Bell exception is huge, an operator can do almost (but not quite) anything to protect its rights or property, it is unclear exactly how it applies at a 'exchange-point' between multiple operators. I feel sorry for the first FBI agent who has to serve a court order at 1919 Gallows Road. Interesting enough, at other multi-carrier meet-points, e.g. border crossing and trans-oceanic cable headends, there is often a very oddly worded warning/no trespassing sign about Presidential war powers and national defense installations. But back to the current issue, Internet exchange points between network providers. Can only the exchange point operator use the Ma Bell exception? Can the exchange point operator do this only with the consent of one or more of the attached carriers? Can an individual carrier monitor addressed to them? What about broadcast traffic? Some providers have gone so far as prohibit any modification to the infrastructure, but it is unclear exactly what this means. Is it yet another one of the useless paragraphs in the agreements? Most providers don't seem to show the same concern when someone points 'default' at them, bringing the full arsenal of debugging and monitoring tools to bear on tracking the source. OC3-MON anyone? I tend to view GRE tunnels like any other traffic. A tunnel to/from any of my customers is like any other traffic to/from those customers. However, a tunnel between two end-points, neither of which is on my network, is a form of third-party transit traffic and gets blocked when I figure out the new way they are doing it. I know, in theory you can encapsulate anything in anything. But even IP inside USENET still has the transitive property, which is what concerns folks. But like many problems on the Internet, it is often easier just to block it than try to track down the source. If it is an honest issue, the source will usually contact you in a while. And sometimes you can figure out a better way of doing it. More often, you hear about the source moving on to do the same thing to another provider until they block it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Government scrutiny is headed our way
by owen＠DeLong.SJ.CA.US 18 Jun '98

18 Jun '98

> > For those who don't bother filtering "because it's too hard or too > > complicated", if you don't want or can't afford to put the work into tight > > ingress filtering on all interfaces, it's really easy to just say "our IP > > blocks are A, B, and C. Allow input with source addresses in A, B, or C, > > deny everything else." That will at least protect the rest of the > > internet from your lusers. > > Right. That's what we do on the dial plant today, because there isn't a > syntax available on our RAS hardware which says "allow anything with this > RADIUS assigned or dynamic address block (depending on the account) and deny > everything else". So we have to relax the filters to be "allow anything from > netblocks A, B, and C, block everything else" since the syntax we really > want isn't available. > I believe RADIUS has a facility for setting ifilt and ofilt based on the particular user based on the Framed-Filter-ID. So, for dynamic users, you could set a filter that allows the Dynamic IP range of that NAS for single-host users. For network users, you could either use blocks like are listed now, or you could set up a filter per user through the choicenet features (Livingston). At the very least, with a rational allocation policy, it should be possible to limit the filters to some subset of Every IP we own. > We do that for all dial and ISDN inbound connections today, and have been > for a long time. > Some people don't. That's the problem. > Still, that's good enough. You can't launch a DOS attack against ANOTHER > provider from our plant this way. We also have directed broadcasts shut > off network-wide, so attempts to bounce pingstorms off our internal plant > (even to internal targets) don't work either. > > That's the 95th percentile solution, and is a hell of a lot more than most > other ISPs do. Most don't do ANY filtering of any kind. I've tested this > against accounts on other providers, and most will happily forward packets > with ANY source address from dial customers. > Exactly. > I understand the CPU problems filtering ingress on a DS-3 to a customer, > for example, if the box has a bunch of other interfaces. But in that case > you should insist (contractually) that the *CUSTOMER* router have the > filters on ITS interface which talks to you, and TEST it from time to time. > Actually, with Cisco's running the newer Fast Drop code, filtering on a DS-3 is not that big a deal. Especially when you consider that this can be done with a simple access-list. Owen

1 0

Smurf Amp Nets
by Andrew Herdman 17 Jun '98

17 Jun '98

Sorry to pollute the list with yet another e-mail about Smurf Amp's, but at this very second, an IRC server that I run is being hammered from these networks. I tried registering them in SAR, got some of them in, but some wouldn't take, and entering all 132 nets manually is kind of cumbersome. *hint hint* I've also assumed they are all /24's (which the 141.161.x.x's are for sure). Anyway here they are. Andrew 0.0.0.0 10.0.4.0 127.0.0.0 129.71.1.0 134.24.34.0 141.161.11.0 141.161.12.0 141.161.180.0 141.161.19.0 141.161.196.0 141.161.2.0 141.161.20.0 141.161.21.0 141.161.54.0 141.161.97.0 141.164.236.0 141.164.240.0 141.164.241.0 141.164.242.0 141.164.243.0 141.198.64.0 142.154.4.0 142.165.3.0 146.188.232.0 161.27.9.0 168.198.52.0 168.216.11.0 168.216.12.0 168.216.13.0 168.216.14.0 168.216.15.0 168.216.9.0 169.130.14.0 172.20.1.0 172.20.2.0 172.20.4.0 172.20.5.0 172.20.50.0 172.31.0.0 192.102.232.0 192.106.1.0 192.168.102.0 192.168.104.0 192.168.250.0 192.206.159.0 192.231.112.0 192.234.72.0 192.40.28.0 192.89.254.0 193.190.196.0 193.76.0.0 193.76.109.0 193.76.81.0 194.211.170.0 194.215.130.0 194.215.133.0 194.244.59.0 198.163.232.0 198.26.182.0 198.3.200.0 198.53.245.0 198.60.120.0 198.68.156.0 199.104.254.0 200.135.13.0 200.23.51.0 200.230.140.0 200.230.142.0 200.230.143.0 200.38.168.0 200.5.128.0 200.5.129.0 202.184.18.0 202.184.25.0 203.150.240.0 204.115.171.0 204.17.178.0 204.208.152.0 204.208.153.0 204.228.161.0 204.229.43.0 204.229.45.0 204.233.137.0 204.242.172.0 204.244.32.0 204.249.16.0 204.26.101.0 204.26.102.0 204.26.103.0 204.26.104.0 204.26.109.0 204.31.135.0 204.64.22.0 204.64.23.0 204.65.223.0 204.70.146.0 204.70.164.0 204.71.242.0 204.96.225.0 205.150.226.0 205.163.217.0 205.172.3.0 205.184.109.0 205.211.168.0 205.218.18.0 205.232.11.0 205.232.119.0 205.232.8.0 206.110.105.0 206.110.253.0 206.110.98.0 206.204.42.0 206.251.0.0 206.251.5.0 206.251.7.0 206.29.111.0 206.34.91.0 207.112.247.0 207.124.139.0 207.34.202.0 207.65.122.0 207.68.0.0 207.99.6.0 208.128.161.0 208.128.185.0 208.133.118.0 208.145.80.0 208.149.198.0 208.192.84.0 209.125.164.0 209.2.160.0 209.22.240.0 209.48.31.0 209.49.144.0 209.49.157.0 209.84.61.0 24.129.20.0 255.255.255.0

4 4

Re: Government scrutiny is headed our way
by howland＠Priss.com 17 Jun '98

17 Jun '98

Karl, *You* may wish to make your life more convenient by bringing government force into your relationship with other network providers, why by what divine right do you get to impose your convenience on others by force? Just go ahead and filter the offenders. When their customers cannot reach your services, or their server customers get contacted by your customers about the policies of their ISP, either they will change their policies or they will loose customers. It is MUCH more effective to guide business policies by the lure of money than by the gun. Each and every network service I have worked for has, once the benefits of cooperation were pointed out to them, changed their tune. Maybe if it were someone advocating force against YOU you wouldn't be quite so pleased at the prospect as when you think the cavalry is coming to rescue YOU. Curt-

6 8

Operational: Need IMMEDIATE cooperation to trace a smurf...
by Dalvenjah FoxFire 17 Jun '98

17 Jun '98

Hi folks, I don't know if this'll work, but I thought I'd try it. One of the networks containing a DALnet server is currently under smurf attack, and has been so since 3:30 AM Pacific Time. I need folks with access to your cores (including MCI, Sprint, and all the other big folks) to sniff in the right places and see if you can't find some ICMP_ECHO_REQUEST packets with the SOURCE address of 209.133.28.*. (You can rest assured that this network isn't sending anything of the sort right now.) I'm hoping we'll get lucky and find this person by chance. If not, oh well, but it's worth a shot. Please e-mail me back (dalvenjah(a)dal.net) or telephone me (619-678-8586) if you find packets of this nature transiting your network. Thank you, -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) May evil beware...and may good dress Founder, the DALnet IRC Network warmly and eat plenty of vegetables. - The Tick e-mail: dalvenjah(a)dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

1 0