September 1996 - Test - lists.nanog.org

Re: SYN flood messages flooding my mailbox
by Paul Ferguson 18 Sep '96

18 Sep '96

At 05:30 PM 9/18/96 -0400, Curtis Villamizar wrote: > >Hierarchical authorization would require that registries recognize >IANA as the numbering authority and install top level objects based on >IANA top level delegations. This would require a strong tie between >numbering allocations and routing registry. Right now any bozo can >come along and claim a quarter or half the number space. > Obviously, this needs serious consideration. :-/ - paul

1 0

Re: A modest proposal
by Kelly J. Cooper 18 Sep '96

18 Sep '96

On Sep 17, 8:04pm, Robert E. Seastrom wrote: * * From: Dalvenjah FoxFire <dalvenjah(a)dal.net> * * I haven't used any myself, but apparently there are several software * packages out there with a pretty graphical front end, complete with * Hollywood-style "Click to destroy machine" buttons and menus. * *Uh huh, right. If you ever actually see anything like this, lemme know. Ok, RS. One piece of software is called UpYours! and it's a mailbombing tool built by a group called "Global kOS" to run over Windows95. It's got a lovely interface including buttons for "BOMB" "ULTRA" and "STOP" with an input window for "Countdown" start & stop times, a choice of edited or randomized source names, randomized (from a configurable list) mailers to route the bomb through, your message (should you choose to enter one) and a few other variables. You can mailbomb someone directly or subscribe them to as many mailing lists as you set up. It can supposedly spam newsgroups as well. I think they were working on something to implement IP spoofing in the mix as well but I haven't heard whether that went through. If it does, it'll be unfortunate because the primary way we were backtracking was having sites being used as remailers turn on various types of accounting to match time stamps with sources. It was released in June to the particular consternation of those sites whose mailers or mailing lists were used as defaults in the code. It has been implied that this was the tool used to hit a number of well-known reporters, the White House, Congress and several other people, places and things a month or two so ago. It only runs on Windows95 and it crashes a lot and there's more hype than substance but it is comparitively simple to set up and configure and can be used to abuse anyone from a dial-up account. This tool is just the one "GUI-fied" piece of attack software that I've dealt with. I'm fairly sure there are others - simple to set up, simple to configure, available for any idiot to use. Kelly J. -- Kelly J. Cooper Network Operations Security BBN Planet Corporation phone 800-632-7638 150 Cambridge Park Drive fax 617-873-6351 Cambridge, MA 02140 http://www.bbnplanet.com

2 1

Re: router syn/syn-ack/ack alarming...
by Vadim Antonov 18 Sep '96

18 Sep '96

Guy T Almes <almes(a)advanced.org> wrote: > The case for ratio-based techniques is stronger as a means for a NOC >to detect a strange situation and investigate it than as a means to >automatically shut down an interface. Both uses are not exclusive. The automatic reaction is simply much faster than by any NOC. I.e. the attack is stalled before it can harm anyone. > Note that, given your 'opposite direction' idea, I could shut down >service on campus 'A' by [1] logging into any host on campus 'A', >[2] launching an attack that might not be harmful in itself but which >would trigger the auto shutdown you advocate, and then [3] sitting >back and watch all of campus 'A' get shut down with the presumptive >blame focused on them. That will give them an incentive to improve security on their hosts. It is very much like leaving your car with keys in ignition lock in a dark corner of N.Y. Chances are good that it'll be stolen and used to commit a crime, and that you'll have to spend quite a lot of time sorting things out. It does not mean that the police shouldn't stop getaway cars. In my opinion, people whose carelessness is instrumental to crime should be at least inconvinienced. Otherwise they will unwittingly assist criminals until the hell freezes over. > It's still a denial of service attack. The problem is not with >detecting the ratio imbalance, but with simple deterministic response >to it. That determinism could be used by an attacker. The scenario you provided moves the burden of being responsible from the target (who may have did everything they could to secure their network) to whomever happened to be a lazy s.o.b. of sysadmin. Right now there's nearly zero penalty for being irresponsible, particularly if you're a big U. I know sysadmins of really big and prestigeous U. who made a conscise choice of being totally irresponsible -- to the point of actually leaving totally unprotected machine on their LAN to steer hackers off their other hosts. I bet being shut a couple of times would very quickly change that :) >In sum, I like the idea of detecting the problem and rapidly tracing >it, but I'm skeptical about a totally automated response to it given >our current low level of experience with it. We can borrow experience from utilities which employ automatic shut-offs of every possible kind for years. Yes, they do create problems; but on overall balance it appears to be a very robust approach to preservation of the whole system's integrity. I really like the idea of the network being able to defend itself without dragging engineers out of beds in the middle of the night :) That will certainly remove a lot of incentive for hacker wannabes who appear to have only one goal in their lives -- to make life of operators miserable. --vadim

2 1

Re: syn attack and source routing
by Vadim Antonov 18 Sep '96

18 Sep '96

Paul Vixie wrote: >I guarantee you that if ICMP TRACEROUTE appears, at least one widely used >router, for at least one year of its aggregate future history, will respond >inaccurately to it. Possibly there will even be knobs on the router to help >network administrators configure "appropriate" responses to ICMP TRACEROUTE. Heh. If you want to fool somebody, you can do that with any kind of probing technology. The problem with inaccurate responces is usually because of badly written specifications (when different "interpretations" are possible) or outright bugs in software (which should be fixed). >Vadim called "traceroute" a "UDP kludge" and so it is, but it lets me see >what packets would do, which is a LOT more useful than seeing what a router >wants me to see. No, it doesn't. How many boxes out there respond not with address of the interface the packet come from but rather with address of any random interface? I've seen very weird addresses in traceroutes quite often. And if i want you to see strange things in traceroute i can do that easily. In fact, Andrew did that once as an April Fool joke. >Perhaps this can be well enough specified in an I-D. Experience says not. Everything can be screwed up. This is not an excuse to do nothing. --vadim

1 0

Re: syn attack and source routing
by Vadim Antonov 18 Sep '96

18 Sep '96

John Hawkinson <jhawk(a)bbnplanet.com> wrote: >I doubt it. As I said, anyone who's affected can cure themselves. Some people do not wait to be affected. > Lately I feel like I'm the single person on the planet who actually > uses LSRR for stuff. I do use loose source telnet on the average > of once a week... Really? What for? How is it more useful than recursive telnetting? > Why not to implement something saner like traceroute servers? >You go implement your traceroute servers everywhere I need them >and THEN come back and ask me to shut it off and I'll consider it. I can implement traceroute server in my software, not a big deal. I can't force others to do so. We need a "rough whatever" to actually get rid of the kludge. >I'm not convinced it makes more sense. As I said to smd in response to >his similar comments, the beauty of the current traceroute is that >it's hard for idiots to turn it off. Very few other solutions have >this wonderful property. The beauty of MS-DOS was that no stupid os was meddling with its stupid memory protection with really smart programs which wanted to play with hardware as they wish (and yes, it was hard for idiots to forget a login password, as there was none). The result is well known. The most popular O.S. on the planet does not have any security to speak of; and half of circuitry in the most popular hardware platform is devoted to backwards compatibility to ensure that those programs will still work (not that it succeeds in that particularly well). And, yeah, hundreds of thousands of people are happily employed making those smart programs to work together. Or did you forget the last time you patched CONFIG.SYS? Can we do without that rite of passage? Sorry, the way traceroute works now is a horrible kludge. It makes network less safe than it can be. It is not reliable (what happens if the UDP port is in use?) Trivial packet filtering screws it up. It breaks down in case of load balancing over multiple paths. It does not provide much useful information (for example, the ICMP TRACEROUTE could return precise timestamps, link utilization stats and names of igress and egress interfaces). There's a lot of room for improvement. The way to fix that is not to disable it now, but rather to make people to agree that there's a problem, and that the problem needs to be fixed. There are several ways to fix it. --vadim

1 0

Re: SYN flood messages flooding my mailbox
by Paul Ferguson 18 Sep '96

18 Sep '96

At 04:15 PM 9/17/96 -0400, Curtis Villamizar wrote: > >Of course, if by "known route" you mean known because it is in the >IRR, and the IRR is known to be reliable, then I accept your argument >but caution that the IRR is not always reliable, but this is yet >another reason to make it more reliable. > Curtis, This is also a valid argument for *not* relying on the IRR for security issues. - paul

2 1

Re: router syn/syn-ack/ack alarming...
by Vadim Antonov 18 Sep '96

18 Sep '96

Guy T Almes <almes(a)advanced.org> wrote: > - source address filtering and > - syn/synack/ack ratio detection >are *complementary* approaches, both of which have promise. Absolutely. > Due to asymmetric routes and other reasons, neither seems very promising >within core routers. There's also an issue of performance -- you don't want to burden core routers with flitering. However, on customer access circuits it is quite feasible. >Syn/synack/ack ratio detection is complementary, since it >could help detect an attack near the destination host. I actually thought about using it at incoming traffic. I.e. not to allow garbadge in the backbone in the first place. On incoming traffic the disbalance may simply trigger an alarm. > I am also a bit skeptical about the idea of automatically shutting down >an interface upon noticing anomolies in the ratios, but that does not >detract from the value of ratio anomoly detection as a valuable network >management technique. I think there's no problem with automatic cut-offs in case of obviously invalid traffic patterns. Practically all traffic on customer access circuits is symmetrical. The automatic shut-off has the advantage of isolating the problem (be it an attacker or a workstation going berserk) immediately, where doing it manually after alarms were tripped may take several hours, which is clearly unacceptable for most people who use Internet to do business. Performing statictical monitoring of input traffic by multihomed customers may be a matter of service contract -- in the same place as requirements to ensure sanity of routing information originated by the same customer. --vadim

1 0

http://www.fc.net/phrack/files/p48/p48-13.html
by Ry Jones (ECA) 18 Sep '96

18 Sep '96

The much-spoken-about code. -- Ry Jones: a-ryj(a)microsoft.com MSN WAN tools group, NRA, Nascar, NT, Linux, C >"The opinions expressed in this message are my own personal views and do not >reflect the official views of Microsoft Corporation."

1 0

Re: New Denial of Service Attack on Panix
by Leonid Egoshin 18 Sep '96

18 Sep '96

>From: David Miller <david(a)sparks.net> > >> I suggest to check not only ratio (assymetric routing !), >> but high number of SYNs to single host. > >I think this is pretty useless. > >If you could get all the end-user ISP's (leaf nodes) to upgrade the OS on >their router, you could have a default behavior of BLOCKING the problem >SYN's in the first place. > There are the number of customers who are serviced by 2 or more providers and who can't support full routing table in it's routers. This customers setup some default route to one of it's provider, and in this case you would have ratio SYNs/SYN-ACK > 1 in one line. >SYN attacks which aren't from random src addresses aren't really a >problem. > I am not shure. Do you like if you are blocked for access to some popular server due to hacker cracked some host in your network ? - Leonid Yegoshin, LY22 P.S. BTW, it is very simple to generate the flow of SYN-ACKs via router which count SYN/SYN-ACK ratio (in reverse path, of course).

1 0

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

18 Sep '96

read my message again, john. i said i don't like the prospect of removing lsrr. i use it. i hate running across backbones that have it disabled. i wasn't campaigning to remove it. i was asking how dangerous it could be because i honestly didn't know. i didn't mean to alarm anyone or imply that i would be turning off lsrr. :) -brett > From: John Hawkinson <jhawk(a)bbnplanet.com> > Subject: Re: syn attack and source routing > > Return-Path: <jhawk(a)bbnplanet.com> > In-Reply-To: <199609181640.JAA01450(a)batcave.genuity.net> from "Brett D. Watson" > *** at Sep 18, 96 09:40:02 am > X-Mailer: ELM [version 2.4 PL23] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > > i should have been more specific. i don't like the idea (at all) of > > breaking traceroute -g either. i guess in a more general sense i > > should ask "just how dangerous *is* having backbone-wide/internet-wide > > loose source routing enabled?". > > As Curtis explained, "not very". > > Worst case, those folks feeling victimized can (and do!) simply shut > it off. > > This is a very different case from that of SYN flooding, where the > victims are powerless to stop it. > > Please don't take our LSRR away from us, it is very useful. > Campaigning to remove something just because you suspect it might be > bad is really not nice -- it will result in random clueless people > believeing you when perchance they should not :-) > > --jhawk

1 0