- Test - lists.nanog.org

syn attack and source routing
by Brett D. Watson 18 Sep '96

18 Sep '96

i'm surprised there has been no discussion of turning off source routing on major backbones to help alleviate this problem. all of the focus seems to be on the edges of the networks when in fact the attackers are "running right up the middle". i'm not disagreeing that providers need to filter on the edges but the "big guys" are just as responsible as the "little guys". i know what a can of worms this is because source routing is quite useful in tracking down network and routing problems but it seems to me the danger it imposes today outweighs it's usefulness. -brett

2 1

Re: A modest proposal
by Sean Donelan 18 Sep '96

18 Sep '96

>Tracking down hacked machines would be quicker. Sometimes you might >be able to track back to the source where you could pull the ANI >or callerid information out of the radius accounting logs and have >someone knocking on their door. You only have to do this for 1 in 10 >attacks before rumors spread around the hacker community and it stops. I hate to tell you, but ANI and caller-id can be spoofed too. However, I agree that encouraging as much source filtering as possible would be "a good thing." Just as long as people don't get the idea that source filtering would make authentication by source IP address any more secure than authentication by caller-id. Now, if we could just get the phone company to not charge 1,000% markup on caller-id, we'd have it on all our modem lines now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

New Denial of Service Attack on Panix
by Kent W. England 18 Sep '96

18 Sep '96

Dear NANOG/IEPG Folks; As you should know by now from reading the papers, Panix, the first ISP in NYC, has come under a new denial of service attack. The Wall Street Journal quoted Bill Cheswick to the effect that the attack is "unstoppable". Almost, but not quite, true. It's true that there isn't anything that Panix can do on its own to stop this attack. It's true that it would be hard to verify source addresses at MAEs and NAPs. But we could all verify source addresses at the first hop entry points. And get default route and unauthorized transit protection to boot. I'd like to know what the community thinks can be done to deal with an escalation of these attacks should this occur. Are you doing any source address verification now? Are you doing anything to help Panix? Could you? How seriously do you take this threat? If Panix were to go out of business and Bob Metcalfe wrote a column on it, ( :-) do you think we would have to deal with it together then, or can we sit tight and expect it to blow over? After all, it's easy to dump chemicals in the reservoir, but we still drink the water, right? Thanks. --Kent ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe(a)6SigmaNets.com Experienced Internet Consulting ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

20 44

Re: A modest proposal
by Daniel W. McRobb 18 Sep '96

18 Sep '96

> Currently, anyone can program their computer to repeatedly dial a > given business phone line and fill up a company's inbound phone lines, > making a denial of service attack. Why isn't the phone system about > to die because of it? > > The phone company keeps a record of every incoming and outgoing call > on every line, and performs all sorts of analysis on time of day and > carrier, and who gets paid for it. I think that 50% of the cost of > providing phone service is the accounting and billing. However, anytime > one has a problem with obscene callers, war dialers, etc, you call > the police and bingo, the men in blue are knocking on the door of the > perpetrator. The caller could dial from a payphone, etc, but what > you've essentially done is make it more dangerous/expensive to conduct > this activity than what it is worth. People that do this sort of > activity are usually cowards, because they're not bold enough to > park a truck bomb outside the object of their hatred. Up the ante, > and they're out of the game. > > I've been following some of the activity on various IP accounting > schemes and the size of those nifty matrices, but frankly, ISPs need > to spend the money to make this a reality and keep accounting data > for at least several days or a week. > > Now I'm a systems guy rather than a router guy, > so I'm not going to even propose that this take place in the router > or somebody will be lecturing me about silicon switched route > processors or something similar. I used to do it with ip accounting > on a cisco and perl scripts to yank the information off. This is > still a reasonable approach for small sites. It seems to me that a > good workstation setup for accounting on the segments attached to the > interexchange points could do all of this adequately. You'd need a > good freeware software package and preferably a web interface that > could be accessed by the right people at the right time. The web > interface would take 10 times as long to write as the collection > software. Once a few of the large carriers make this a prequisite for > peering, it would be widespread. Unfortunately, it's currently harder to do this from a workstation (at least all that I've seen) than it is from a router. I've yet to see a w/s that'll sniff at better than 4-5K pps sustained, and that's not even accounting for disk I/O and other issues. If someone knows of a w/s that can do this at pps rates in excess of 40,000 pps (even better, 100,000 pps so I don't have to search yet again next year), that won't cost me 4 mortgages, I'd love to hear about it. The only thing I've seen that'll do this to date is the oc3mon stuff, and that currently only works for OC-3 fiber. I'm not so much interested in actually deploying such boxes all over the network, but they sure would be nice to have at hand. I hate to say it (particularly since it's been said over and over, recently by Curtis), but I think the best bet for doing this is a hook in the forwarding code on the routers to capture X bytes of 1:N packets, aggregate a handful of them in memory, then shove them out a private interface. N of 1 would be nice, as would X of a large enough value to hold IP and TCP headers, IP options, and the link encapsulation (128 makes a nice word-boundary value and is what we used on the NSFNET) but I could probably live with N of 50 (again what we used in the NSFNET days, and I traced two SYN floods a few months ago w/ only 1:50 sampling even though very few packets were sent according to the site; they were running tcpdump... unfortunately, the folks owning the peer at the border I tracked it to were unable to help me track it further since they didn't have access to this kind of data). Daniel ~~~~~~

1 0

amusement
by Curtis Villamizar 18 Sep '96

18 Sep '96

***** Off Topic - Delete now if you are humor impaired! ***** Here's a recent incident and an earlier one I just found amusing enough to keep. These are both voice services, not data. I honestly wish I had saved more of these. There have been quite a few and some had some entertaimnent value. Please respect the "Reply-To". This *isn't* worth further discussion. Curtis ps- thought we needed some cheering up. If word gets out about this people might be reluctant to use voice services. ;-) pps- if IP service is as bad as Bell Atlantic Answer Call then people will leave their IP service provider so in a sense that's no joke. ------- Forwarded Messages Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by brookfield.ans.net (8.7.3/8.7.3) with SMTP id IAA06101 for <curtis(a)brookfield.ans.net>; Tue, 17 Sep 1996 08:56:07 -0400 (EDT) Received: by interlock.ans.net id AA06319 (InterLock SMTP Gateway 3.0 for ans-world(a)ans.net) Tue, 17 Sep 1996 08:56:41 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 17 Sep 1996 08:56:41 -0400 Message-Id: <199609171256.AA04835(a)interlock.reston.ans.net> Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 17 Sep 1996 08:56:41 -0400 X-Mailer: InterCon TCP/Connect II 2.1.2 Mime-Version: 1.0 Date: Tue, 17 Sep 1996 08:59:42 -0700 From: "Carol Harvey" <harvey(a)reston.ans.net> To: ans-world(a)ans.net Cc: ans-reston(a)ans.net Subject: Voice Mail Content-Type: Text/Plain; charset=US-ASCII Content-Disposition: Inline There is a system-wide outage of the Bell Atlantic Answer Call (Voice Mail) in the Northern Virginia Area. They are working on the problem and will restore voice mail as soon as possible. The good news is -- we get our own in-house voice mail with our new phone system this Friday. Carol ------- Message 2 Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by brookfield.ans.net (8.7.4/8.7.3) with SMTP id WAA12714 for <curtis(a)brookfield.ans.net>; Tue, 23 Apr 1996 22:54:14 -0400 (EDT) Received: by interlock.ans.net id AA13449 (InterLock SMTP Gateway 3.0 for ans-world(a)ans.net) Tue, 23 Apr 1996 22:53:27 -0400 Message-Id: <199604240253.AA13449(a)interlock.ans.net> Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Tue, 23 Apr 1996 22:53:27 -0400 Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Tue, 23 Apr 1996 22:53:27 -0400 Date: Tue, 23 Apr 96 22:53:25 EDT From: David Bolen <db3l(a)ans.net> To: ans-world(a)ans.net Subject: Elmsford phones: It's alive! @begin(heavy sarcasm) Well, that was fun... @end(heavy sarcasm) Ok, our local PRI to NYNEX has been restored. While the backup analog connections still require the PBX cards that are getting replaced tomorrow, since the primary route (the PRI) has been restored, all phone services should be back to normal. Direct dialing Elmsford extensions is again working, Elmsford users can make 800 number calls, and local calls from Elmsford are going out over the local circuits. For those interested... It turns out that my "lost" NYNEX technician did in fact find some problems in the basement (rather than in the NYNEX shelf in the lab, which only needed a fuse replaced), but it was in gear he wasn't in the right group to "touch". So when he finally showed up again (around 8pm) he informed me he had requested that the "Hi-Tech" group (T1 and data services) dispatch someone. Luckily, they work 24 hours, and are generally on top of things. A pair (lookie - _two_ techs showed up at once to work together, what a concept) got here by about 10:15pm, and everything was up and running again within 20-30 minutes, after replacing some gear in the basement. So it only took me about 55 hours to get an appropriate crew from NYNEX to show up to handle a 20 minute, "obvious" job... I don't know whether to laugh in relief that it's over or cry in despair over what it took.... But we're back up. - -- David ------- End of Forwarded Messages

1 0

Re: A modest proposal
by Sean Donelan 18 Sep '96

18 Sep '96

>Currently, anyone can program their computer to repeatedly dial a >given business phone line and fill up a company's inbound phone lines, >making a denial of service attack. Why isn't the phone system about >to die because of it? Actually the phone system does periodically die from this. Just ask the White House switchboard operators about it. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

router syn/syn-ack/ack alarming...
by Regis Donovan 18 Sep '96

18 Sep '96

um... maybe i'm missing the clue here, but if the router vendors add something that shuts down an interface if the SYN/SYN-ACK/ACK ratio becomes too bad make it *easier* for me if i'm doing a denial of service attack on a host? instead of denying service to a given host, all i have to do is drive the router into alarm mode so it shuts off the interface and then i get to deny service to an entire segment and everything downstream from that segment... here's to better bang for your cracker-kiddie buck... --regis >

5 4

SYN and Solaris
by dvv＠sprint.net 18 Sep '96

18 Sep '96

The values to play with are tcp_conn_req_max (defines the max value for listen queue), tcp_ip_notify_cinterval (makes tcp send another SYN???), tcp_ip_abort_cinterval (aborts connection and frees the slot). Note "c" in "cinterval". I understand these timer values work for both incoming and outgoing connections. Dima

2 1

Re: New Denial of Service Attack on Panix
by Justin W. Newton 18 Sep '96

18 Sep '96

At 02:51 PM 9/17/96 -0400, Dick St.Peters wrote: > >Logging denies will fill up your log anyway. Packets arriving for a >dialup user after he/she hangs up fall through to the default route >back out of the box. They are then _outbound_ packets with source >address off the network and destination address on the network. That depends how your network is setup. Ours would have the route going to Null0, so it wouldn't be shot back out via the default route. This hides any internal instability from being announced to the outside world except in /extreme/ cases. (Like we fall completely off the net). Why would you want the packet transiting back and forth across your T-1 until the TTL expires anyway? Much better to black hole the sucker. Justin Newton Internet Architect Erol's Internet Services

2 1

Re: SYN and Solaris
by Sanjay Dani 18 Sep '96

18 Sep '96

> From: dvv(a)sprint.net (Dima Volodin) > The values to play with are tcp_conn_req_max (defines the max value for > listen queue), tcp_ip_notify_cinterval (makes tcp send another SYN???), > tcp_ip_abort_cinterval (aborts connection and frees the slot). Note "c" > in "cinterval". I understand these timer values work for both incoming > and outgoing connections. On Solaris, the default for tcp_ip_abort_cinterval is 180000 ms (3 mins). You could try reducing it to a few seconds (at the risk of denying service to legit clients connecting over slow links) using #ndd -set /dev/tcp tcp_ip_abort_cinterval <value in ms> This affects ALL tcp conenctions on the system. Solaris also lets you set the parameter for a specific destination port if the SYN attacker does not use a random destination port: #include <netinet/in.h> #include <netinet/tcp.h> .... int value = <whatever>; setsockopt(fd, IPPROTO_TCP, TCP_CONN_ABORT_THERSHOLD, &value); .... Sanjay. PS. This feature may or may not be documented--I got it from a friend at SunSoft.

1 0