A modest proposal
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. 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. allan allan@bellsouth.net And no, I'm not volunteering for anything yet :)
From: Allan Chong <allan@bellsouth.net> 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. This discussion of securing dialup servers is pointless. I guarantee you that the 2000 packet/second SYN attacks we've been seeing are coming from a compromised host on a high speed connection and not from someone's 28.8k dialup connection. The hackers just take over a machine, use it to launch their attacks, and disappear into the jungle if we manage to find the particular machine they're using tonight. Harden your servers, filter on all non-transit ports on your routers, but let's let the how-to-do-filtering-on-terminal-servers discussion die, OK? ---Rob
Robert E. Seastrom wrote:
From: Allan Chong <allan@bellsouth.net>
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.
This discussion of securing dialup servers is pointless. I guarantee you that the 2000 packet/second SYN attacks we've been seeing are coming from a compromised host on a high speed connection and not from someone's 28.8k dialup connection. The hackers just take over a machine, use it to launch their attacks, and disappear into the jungle if we manage to find the particular machine they're using tonight.
Yes, I realize no one is launching directly from dialup, but often, the user is someone originally dialed up and telneted to some box (or through multiple boxes). Tracking the attack back to the compromised machine quickly is worth it in my opinion. Pervasive accounting would at least allow one to systematically track back step by step to the origination. Even then it might be a university cluster (MIT used to give out the root passwords to workstations since everything was kerberized), but the cognoscenti at the university can often take care of the problem given the motivation. Right now the problem seems to be that the attack is totally anonymous and the methodology for tracking back to the source is involved. Hmmmm. If I were a hacker, I would be doing my best to make sure that my route to the victim was taking a path through as many foreign speaking networks as possible. You'd have to speak Swahili and Cantonese :) allan
Allan Chong put this into my mailbox:
This discussion of securing dialup servers is pointless. I guarantee you that the 2000 packet/second SYN attacks we've been seeing are coming from a compromised host on a high speed connection and not from someone's 28.8k dialup connection. The hackers just take over a machine, use it to launch their attacks, and disappear into the jungle if we manage to find the particular machine they're using tonight.
Yes, I realize no one is launching directly from dialup, but often, the user is someone originally dialed up and telneted to some box (or through multiple boxes).
I'd just like to offer some perspective here. The majority of these types are complete idiots - and this is speaking from experience. For some reason or other a lot of these get their start on IRC, and then go from there, and I get to see them in the 'formative stages', as it were. 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. I have indeed seen that the majority of these types believe that it's perfectly possible to ping -f or nuke/SYNflood/whatever a machine from a 14.4k or 28.8k dialup. Granted it may not be as bad as the Panix case, but it's still an incredible nuisance. What I'm trying to say is don't dismiss this as not possible. With the current level of public education about the Internet - "How do I get to that superhighway information thing? I'm interested in Route 25.." - it can and is very possible that people will do things like this from a 28.8k. I've seen it happen. (I'm not trying to say there isn't a range, though - I've gotten several "I'll destroy your machine with my tee3 account!" threats as well.) -dalvenjah Dalvenjah FoxFire, the Teddy Dragon (also known as Sven Nielsen to some :) dalvenjah@dal.net --- dalvenjah on IRC Remember: if you're not on DALnet, you're on the wrong IRC server!! (/serv irc.dal.net 7000 or telnet telnet.dal.net to try it out) -- ____ _ _ _ "I had the dagger in my hand, and he has | _ \ __ _| |_ _____ _ _ (_)__ _| |_the indecency to start dying on his own!" | |_) / _` | \ V / -_) ' \ | / _` | ' \ --Ambassador G'kar, Babylon 5 |____/\__,_|_|\_/\___|_||_|/ \__,_|_||_| FoxFire -- dalvenjah@dal.net -- (SN90) |__/
From: Dalvenjah FoxFire <dalvenjah@dal.net> I'd just like to offer some perspective here. The majority of these types are complete idiots - and this is speaking from experience. For some reason or other a lot of these get their start on IRC, and then go from there, and I get to see them in the 'formative stages', as it were. <ahem> Some of them even put their IRC names in their .signatures (present company excluded of course) :) 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. I have indeed seen that the majority of these types believe that it's perfectly possible to ping -f or nuke/SYNflood/whatever a machine from a 14.4k or 28.8k dialup. Granted it may not be as bad as the Panix case, but it's still an incredible nuisance. The only "nuisance" will be if you notice it; that is actually not very likely. The causal "victim" will be happily oblivious to a pingflood coming from a 14.4k dialup unless he too happens to be on a 14.4k dialup. What I'm trying to say is don't dismiss this as not possible. With the current level of public education about the Internet - "How do I get to that superhighway information thing? I'm interested in Route 25.." - it can and is very possible that people will do things like this from a 28.8k. I've seen it happen. Oh, sure, they'll *try* it, but the results will be boring. they don't get the machine to go "boom", and after a suitable period of trying, they go back to IRC. (I'm not trying to say there isn't a range, though - I've gotten several "I'll destroy your machine with my tee3 account!" threats as well.) You've got a whole lot more to worry about from him -- at least he has the bandwidth to make good on a threat to make your life difficult via brute force. ---Rob
Robert E. Seastrom put this into my mailbox:
<ahem> Some of them even put their IRC names in their .signatures (present company excluded of course) :)
Naturally - it's a marketing ploy };>
Uh huh, right. If you ever actually see anything like this, lemme know.
Okay, perhaps not that. But I *have* seen scripts for an IRC client where one right-clicks on a nickname and selects an option from a pop-up menu. This program then takes in that nickname's address and goes to work, flooding, spoofing, whatever it's intended to do. They may not exist to the Hollywood extent, of course, but it *is* as easy as point and click.
The only "nuisance" will be if you notice it; that is actually not very likely. The causal "victim" will be happily oblivious to a pingflood coming from a 14.4k dialup unless he too happens to be on a 14.4k dialup.
This is a point where I beg to differ. A 14.4k dialup can definitely spawn multiple connections to an IRC server with spoofed source addresses and send as much data as the link can handle (1k/sec) to a single person/channel/ whichever. It can - and does - make the target's IRC session unusable.
You've got a whole lot more to worry about from him -- at least he has the bandwidth to make good on a threat to make your life difficult via brute force.
I know. I'm going to insert my usual spiel about IRC - I know there are a lot of people who believe it's worthless and not worth the time of a provider to worry about, and I'm not going to waste my time explaining why you should change your opinion. I believe, however, that it can be legitimized and am trying to do so - and the first step to doing so is trying to figure out how to stop the people who've given IRC a bad name. I appreciate your cooperation. -dalvenjah Dalvenjah FoxFire, the Teddy Dragon (also known as Sven Nielsen to some :) dalvenjah@dal.net --- dalvenjah on IRC Remember: if you're not on DALnet, you're on the wrong IRC server!! (/serv irc.dal.net 7000 or telnet telnet.dal.net to try it out) -- ____ _ _ _ "I had the dagger in my hand, and he has | _ \ __ _| |_ _____ _ _ (_)__ _| |_the indecency to start dying on his own!" | |_) / _` | \ V / -_) ' \ | / _` | ' \ --Ambassador G'kar, Babylon 5 |____/\__,_|_|\_/\___|_||_|/ \__,_|_||_| FoxFire -- dalvenjah@dal.net -- (SN90) |__/
From: Allan Chong <allan@bellsouth.net> Yes, I realize no one is launching directly from dialup, but often, the user is someone originally dialed up and telneted to some box (or through multiple boxes). Tracking the attack back to the compromised machine quickly is worth it in my opinion. Pervasive accounting would at least allow one to systematically track back step by step to the origination. No, pervasive accounting would only allow you to strengthen your position once you arrived at a conclusion. It does not in any way offer help in arriving at that conclusion. Even then it might be a university cluster (MIT used to give out the root passwords to workstations since everything was kerberized), but the cognoscenti at the university can often take care of the problem given the motivation. Right now the problem seems to be that the attack is totally anonymous and the methodology for tracking back to the source is involved. Not likely to be a university cluster in my experience... some local pranks may be launched from university clusters. Dorm rooms and personal boxes, OTOH, seem to be a favorite for the past couple of years; expect that one to get worse. But yes, the problem is finding out who the perp is, not proving who the actual offender was once you've narrowed yourself down to half a dozen possibilities and enlisted the cooperation of their local sysadmin. In any event, once again I exhort everyone to not waste their time filtering the dialups. Filter your customers, filter your own networks; if you incidentally get most of your dialup servers covered by that umbrella, fine. If not, don't lose too much sleep over it -- if you don't believe me, just config up a linux box with the code of your choice, and try to SYNflood someone over a dialup. Hmmmm. If I were a hacker, I would be doing my best to make sure that my route to the victim was taking a path through as many foreign speaking networks as possible. You'd have to speak Swahili and Cantonese :) Not worth the trouble. The far ends of the earth where not even the network admins speak English are on the ends of wet strings; it isn't worth the aggreivation to telnet through them, and launching a source-routed synflood through them would be self-defeating. ---Rob
On Tue, 17 Sep 1996, Robert E. Seastrom wrote:
In any event, once again I exhort everyone to not waste their time filtering the dialups. Filter your customers, filter your own networks; if you incidentally get most of your dialup servers covered by that umbrella, fine. If not, don't lose too much sleep over it -- if you don't believe me, just config up a linux box with the code of your choice, and try to SYNflood someone over a dialup.
Not worth the trouble. The far ends of the earth where not even the network admins speak English are on the ends of wet strings; it isn't worth the aggreivation to telnet through them, and launching a source-routed synflood through them would be self-defeating.
If it only takes 8 SYN packets to lock up a socket for 75 seconds then effective SYN flood attacks certainly *CAN* be launched from a dialup connection. And if the definition of an effective attack allows for intermittently shutting down a socket then effective attacks certainly *CAN be launched from places like Uruguay, Brazil, Indonesia and so forth. Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com
From: Michael Dillon <michael@memra.com> If it only takes 8 SYN packets to lock up a socket for 75 seconds then effective SYN flood attacks certainly *CAN* be launched from a dialup connection. And if the definition of an effective attack allows for intermittently shutting down a socket then effective attacks certainly *CAN be launched from places like Uruguay, Brazil, Indonesia and so forth. The kids don't have this much finesse; witness the 2000 packet/sec attacks recently seen. Look for trouble where there isn't any (yet) after getting the current problem dealt with, eh? ---Rob
On Tue, 17 Sep 1996 17:21:07 -0700, Michael Dillon <michael@memra.com> wrote: +- |If it only takes 8 SYN packets to lock up a socket for 75 seconds then |effective SYN flood attacks certainly *CAN* be launched from a dialup |connection. And if the definition of an effective attack allows for |intermittently shutting down a socket then effective attacks certainly |*CAN be launched from places like Uruguay, Brazil, Indonesia and so forth. +- i agree that it is possible and this is why it is necessary to harden machines to some degree. this makes me wonder, though: since the rate cited for the attacks against panix are much higher than that, has anyone looked at trends in the inter-packet delay to see if they lend any insight as to the source? so to have a rate high enough to discount all 28.8K or less dialups and some transoceanic links is useful to some small measure. since the talk seems to be centered around specific machines being hosed, i assume that panix's links are not becoming congested. perhaps a change in the packet density during the attack might suggest that an intermediate circuit is becoming congested. if this is the case, then ISPs may be able to look at known high-use corrodors instead of groping around blindly. or, conversely, if there is a steady stream at 2Kpps, that might be enough to allow a smaller provider to discount part of the topology that is not able to support that kind of traffic. i think that Alexis said that the 2nd attack involved something like 7 panix machines--just how much bandwidth is needed to support a 2Kpps attack on 7 machines? -arthur
perhaps a change in the packet density during the attack might suggest that an intermediate circuit is becoming congested. if this is the case, then ISPs may be able to look at known high-use corrodors instead of groping around blindly. or, conversely, if there is a steady stream at 2Kpps, that might be enough to allow a smaller provider to discount part of the topology that is not able to support that kind of traffic.
i think that Alexis said that the 2nd attack involved something like 7 panix machines--just how much bandwidth is needed to support a 2Kpps attack on 7 machines?
-arthur
Without giving too many details, I will say that there was never a 2kpps attack on panix.. Avi
That's what bothers me most - I have a suspicion that Alexis didn't even have to go out of his own domain to look for perpetrators. Then again, I may be wrong. Dima Arthur Hyun writes:
i think that Alexis said that the 2nd attack involved something like 7 panix machines--just how much bandwidth is needed to support a 2Kpps attack on 7 machines?
-arthur
That's what bothers me most - I have a suspicion that Alexis didn't even have to go out of his own domain to look for perpetrators. Then again, I may be wrong.
Dima
Arthur Hyun writes:
i think that Alexis said that the 2nd attack involved something like 7 panix machines--just how much bandwidth is needed to support a 2Kpps attack on 7 machines?
-arthur
Nope, the packets were definitely coming in from the outside (and not out his MCI t1 and in his Sprint t1), but *nothing* like 2kpps. We later got a good fraction of that with a deliberate test attack, though. 2kpps is only 80kbytes/sec, though... Still not straining a t1. Avi
Michael Dillon wrote:
If it only takes 8 SYN packets to lock up a socket for 75 seconds then effective SYN flood attacks certainly *CAN* be launched from a dialup connection. And if the definition of an effective attack allows for intermittently shutting down a socket then effective attacks certainly *CAN be launched from places like Uruguay, Brazil, Indonesia and so forth.
not 8, only 2 SYN packets into the same connection are needed (connection is a single src addr, src port, dest addr dest port 4-tuple) not 75 seconds, ~11 minutes. the essence of the bug is: one timer t_timer[TCPT_KEEP] used for 2 purposes --to hold the 75 second half-open timer --to hold the 2 hour keepalive timer the first SYN packet sets the timer to 75 seconds the second trips the bug and resets the timer to 2 hours so where does the 11 minutes come from? the server (target) send SYN-ACK packets, and retransmits the SYN-ACK until it either gets a response or gives up when TCP_MAXRXTSHIFT is exceeded. the latter take ~11 minutes. the fix is to qualify the settting of hte timer ala: if (TCPS_HAVEESTABLISHED(tp->t_state)) tp->t_timer[TCPT_KEEP] = tcp_keepidle; and to set the timer a each location where the TCP/IP state machine transitions to TCPS_ESTABLISHED. each half-open socket consumes 264 bytes of memory (assuming perfect allocation ;) all BSD derived TCP/IP implementations are/may be susceptible to this bug. that includes AIX, SVR4, and SunOS. stevens TCP/IP illustrated vol 3 p191 explains this much beter than i can jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB
In message <Pine.BSI.3.93.960917171801.21768H-100000@sidhe.memra.com>, Michael Dillon writes:
If it only takes 8 SYN packets to lock up a socket for 75 seconds then effective SYN flood attacks certainly *CAN* be launched from a dialup connection. And if the definition of an effective attack allows for intermittently shutting down a socket then effective attacks certainly *CAN be launched from places like Uruguay, Brazil, Indonesia and so forth.
If you can't fix this so its closer to 60,000 than 8 you're on the wrong side of the firewall. This is where a packet filtering router doesn't do the trick. Curtis
Allan Chong writes:
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. [...] ISPs need to spend the money to make this a reality and keep accounting data for at least several days or a week.
The volume of IP datagrams exceeds the volume of calls worldwide by orders of magnitude. The cost of a router is orders of magnitude lower than the cost of a phone switch. The quantity of data required to log all packets going by is only about a factor of ten less than the total data crossing the network. Imagine the size of the disks involved. In sort, this is not the way to stop SYN attacks. Perry
participants (10)
-
Allan Chong -
Arthur Hyun -
Avi Freedman -
Curtis Villamizar -
Dalvenjah FoxFire -
dvv＠sprint.net -
Jonathan M. Bresler -
Michael Dillon -
Perry E. Metzger -
Robert E. Seastrom