Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
The Internet

Solution To DoS Attacks 139

Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding. The idea is that no information is retained by the server after the initial SYN is received. The server's resources aren't used until the ACK is received from the client (which must have a real address to receive the reply from the server). The SYN/ACK back from the server is encrypted to prevent "ACK flooding." It can be implemented in a way that is transparent to clients, so only servers need alteration. I'm skeptical (and this only solved one kind of DoS), but it's worth looking at.
This discussion has been archived. No new comments can be posted.

Solution to DoS Attacks

Comments Filter:
  • How does it prune?

    The newest? That would stop new connections.
    The oldest? That would discard slow connections before they fully connect.

    Of course, the router approach might work, but I think this new way is interesting.
  • I'm sorry... I try hard not to let the libertarian, anti-government urges take over, but there IS a line we should not cross. I DO NOT want the government legislating how I must configure my servers. Not ANY government. It's a technical problem, best solved by technical resources.

    Please.

    Because what OTHER mandates might the legislators throw into the same bill?

    -- Michael Chermside

  • True. However, this is acceptable. I see this happen rather often browsing the web.

    Technically, the problem is the client's to deal with. The client should have a timeout. This sort of situation can occur naturally with a transient network fault.

    Also concider the effect of a lost SYN_ACK. The client will timeout and resent it's SYN. The server is likely to send back a different SYN_ACK as it has no state on the original SYN.

    Use of syncookies can cause some very odd problems. This is why it has to be explicitly activated by the administrator. Compiling it into the kernel does not turn it on.
  • Carnivore? Last time I checked, that was an e-mail sniffer. I'm not sure how that's going to stop a DoS attack unless the hax0rs who precipitated it are sending each other emails like:

    From: hax0r d00d
    To: tr0llb0y
    Subject: I ki113d yah00!
    "W00h00! I just d0wn3d yah00 from x.x.x.x,
    y.y.y.y, z.z.z.z and, oh yeah a.a.a.a. I am so
    3133t!"

  • Speaking of DoS, was Yahoo down again all of yesterday (Sunday)?

    I could get the home page up, but I couldn't check my Yahoo mail accounts, read the news or do a search.

    At the same time, however, I could browse other websites freely from my Winbloze 95 machine and from my two Linux boxes.

    I haven't heard anything in the news about Yahoo being down this weekend, tho, so I'm wondering if my ISP just screwed up again.

  • Not to degrade your most funny conspiracy theory in any way, I present mine: This story posted by CmdrTaco. We all know he's installed Linux once or twice, at least that's what I have read out here. Could any geek resist finding out what "SYN Cookies" are while cruising the menuconfig options? I think not. Well, at least I could not. And given the inevitability that CmdrTaco already knew about SYN Cookies, we of course trust that he would not be trolling. This leaves only one conclusion: CmdrTaco's account has been hijacked by the trolls and they are now trolling from the front page! Get out while you still can!
  • DOS != DoS;
    DOS = "Disk Operatin System";
    DoS = "Denial of Service";
    -------------------------
  • by SuperDuG ( 134989 ) <<kt.celce> <ta> <eb>> on Monday September 25, 2000 @04:52AM (#756711) Homepage Journal
    I was just thinking that preventing Dos's is not only impossible but a way of life that we've had to learn to accept. With lack of security and common sense running wild on the internet today it seems that we have to learn to make sacrifices.

    I use to pop on EFnet any time I got a chance but it seems that Dos attacks have made EFnet either unreachable or lagged to the point of disbelief.

    Then we have the slashdot effect. In essence this is 'like' a dos attack millions of unique connections made to a server at the exact same time... the only way to prevent this ... load balanced servers a ton of bandwidth ... or you could just not tell slashdot :-).

    Hypothetical situation ... Rob decides that some little lamer keeps emailing him from his little ISDN box in the middle of bumsville iowa. Rob then decides to publish an article about a free downloadable opensource dvd player and makes the link point towards the box of the lamer. Now it's not Rob's fault for accidentelly typing the wrong url and you can't say it was a conspiracy ... so one of the most advanced strategic dos attacks would have to be ... Freedom of the press.

  • Hey, maybe /. is really just a huge version of Eliza and you're the only real user. And the /. effect is obviously faked just to annoy you. Of course, any resemblance to a real DDOS attack is merely a coincidence. Don't you love conspiracy theorists?
  • by daw ( 7006 ) on Monday September 25, 2000 @04:54AM (#756713)
    It was originally invented as part of Karn's key exchange protocol, yes, though the general idea of having a handshake without the server having to keep state (by encoding the state as a "cookie" sent to the client and then verifying and reconstituting the state from the cookie when the client sends it back) is useful for non-encrypted TCP as well (but you need to use cryptographic methods to verify the integrity of the cookie of course). Like I said it's in the Linux kernel.

    The whole reason you don't want to use an array like you describe is that it requires that the server dedicate resources -- an array entry -- to a connection before the client's location is verified by the three-way handshake. This is exactly why syn floods work, by filling up the queue with bogus connection requests that never complete.

    Dan Bernstein also has an old old web page in which he describes this idea in the context of IPV4:

    http://cr.yp.to/syncookies.html [cr.yp.to]

    ... but I still think Phil Karn is the real inventor.

  • by jemfinch ( 94833 ) on Monday September 25, 2000 @04:55AM (#756714) Homepage
    Considering he's the inventor of this *exact* idea -- that the server not retain information until the ACK (and that it do so by hashing various qualities of the initial SYN into an initial sequence number for the responding SYN+ACK.

    It's a great concept. Read more about how it was created at http://cr.yp.to/syncookies.html .

    Really, I'd like to see this implemented in the BSDs. Currently, they still create a pcb on the SYN and just drop random ones (during a SYN flood, random ones are most likely to be fake anyway) if there are too many (more than 4096, iirc). SYN cookies are a much better solution. I'm curious why they haven't been implemented already.

    Jeremy
  • You know, this has crossed my mind several times, but i think slashdot is just a front to 'legally' commit DOS attacks against unwitting websites, hence the slashdot effect :-)
  • I thought that if people widely adopted the use of ipv6 that most of these problems would go away.
  • Does 95/98/ME/2K have vulnerabilities to SYN floods or has Microsoft patched this too?
    Anyone have any links to it?
  • Some instructions will cause fewer changes within a processor than others. When you change the value coming out of a transistor, you have a change in the current consumption for that transistor. By reducing the type of operations performed, you can easily change the heat dissipation of your CPU.

    For instance, if you hit heavily over a large area of cache memory (in particular, caches get hot) and change data, you will see greater heat dissipation than if you run a tight loop that (for instance) assigns a variable to its current value. If you don't believe me, try sticking your thumb on an idle 486 versus one running seti at home. Better yet, read the LM75/78/whatever temperature sensor on your brand spanking new machine. You bet it changes with load.

  • Cisco 7xxx series routers have this feature of delaying a connection until the final ACK is recieved, and then passing the connection on to the host behind the router. It's called TCPGuard and it's very similiar to what the author describes. Old News.
  • That's the wrong approach. The Internet infrastructure itself should never let forged SYN packets out to begin with.

    If we design our protocols to deal with such screwy cases, we are sacrificing a lot of performance. The initial roundtrip for TCP is one of the things that makes TCP such a lousy protocol for the web, as well as for many other "reliable datagram" applications. If the initial packet not only contained the identity of the source but also data (e.g., the request), TCP could be nearly as efficient as UDP for many applications.

    If you want some kind of method that establishes that a remote host exists, at least don't do it on every packet. Instead, exchange some cryptographic tokens with only the first connection and then allow the remote host to use those tokens for communication without a roundtrip for future communications.

  • Why did this get modded down? He/she has a point.

    ``The trouble is that systems like Carnivore could be used to prevent wide-scale DDoS attacks by isolating affected computers quickly enough to prevent the infection to spread.''

    Say you're a website who is receiving a boat load of packets from a certain region. If a "Carnivore-like" system (read: a switch set up just outside the ISP) is in place, the ISP can be temporarily cut off until that IP range ceases it's attack. Considering how lax most ISP are about their security, this is not really that bad of an idea.

    Of course there is two problems that would need to be considered:

    Cutting off innocent users - there's no real nice way around that unless we block on an individual IP basis, but even in that case you can't tell who the bad guys are and who are the innocent users just trying to connect to the server.

    Who's going to be in charge of this thing - one company/organization cannot be in charge of the whole thing. Obviously it would have to be split up into regions, kinda like the telephone companies.

    Yes, there is no one nice solution for DoS attacks, I will admit that, and what I've just posted is obviously not the best. However like any other good security practice, perhaps something like this - in conjunction with other procedures - would actually make a decent solution.

    --

  • you want proof? try IRC once in a while. EFNet is *constantly* being DoS'd. these packet kiddies do this to the irc servers so they will delink and they can rape a channel. lots, and i mean lots, of efnet servers have died and/or delinked forever from efnet due to DoS.

    it may sound petty, but something someone needs to start doing is advertising the fact DoS'ing *does* effect more than just the attacker and victim. its really all about educating the kiddies before they find the point-click apps for doing this stuff. make them aware there is more out there and better alternatives to destruction.
  • MAXTOR's setup disk for their hard drives boots Caldera DR DOS 7.02. DOS LIVES!!! I used it just this weekend. Couldn't make it do what I wanted, so I just went back to good old gnu/linux fdisk.
  • by daw ( 7006 ) on Monday September 25, 2000 @04:29AM (#756724)
    This idea -- invented by Phil Karn for IPV6 and known as Photuris cookies there -- was long ago implemented in IPV4 to prevent SYN floods. It's descried in several RFCs and it's available in the Linux Kernel as the "SYN cookies" option.
  • The very structure of the net means that it will always be vulnerable to DDoS attacks of one kind or another. And with a typically lax attitude on the part of sys admins who'd rather play Quake than get the latest patches for security holes, hackers are always going to find machines to 0wn and use.

    The trouble is that systems like Carnivore could be used to prevent wide-scale DDoS attacks by isolating affected computers quickly enough to prevent the infection to spread. And as more and more critical applications move online (financial information, long-distance surgery etc.) the costs of a DDoS attack will grow and grow. Unlike the first Flood, the after effects of a successful DDoS could last for a lot longer than forty days and nights.

  • I run a public mirror server in my spare time. It's under frequent, if not constant attack. When the latest Mandrake release came out (something I mirror) I was attacked with some sort of FTP connection flood multiple times (we're talking 250+/sec). RedHat hadn't jacked me around. I mirrored 6.5GBs of their shit for over a year and they never got me listed as a mirror, even after countless email requests. Bastards. I canned their stuff two nights ago. My point is, if I was a RH mirror right now I would be bombarded with attacks with their 7.0 release coming out. A co-worker of mine had the i386 ISO on his personal linux box and was letting people download it locally. We discovered that his box had been hacked and the ISO had been replaced with one that installed a buttload of backdoors and a hacked up kernel and init to hide their activety. Nice.

  • Discussion of this idea has been taking place on the news.grc.com forums [grc.com]

    The similarity to SYN cookies [cr.yp.to] has been pointed out to Steve Gibson.

    michael

  • we put this into the linux kernel in early 2.1. the define is CONFIG_SYN_COOKIES and it also needs a sysctl/proc option to be enabled (net.ipv4.tcp_syncookies)

    basically, you make your syn a function of the session's data (local and remote port, hostname, and syn) and some secret. then when the ACK returns with your SYN (and all the original data), you can inverse the function to see if it matches.

    if you make this function a cryptographically strong one-way hash and use a good secret, the cookie is fairly undeterministic

    in linux, we do this exactly:
    our_initial_syn = one_way_hash(src.port, dst.port, src.host, dst.host, secret) + src.initial.syn;

    by adding on, and not using as an argument, the initial syn, we can keep our syns properly spaced. the secret is a counter that is incremented every minute. this acts as a method for checking for old acks, too.

    the TSB is not created until the final ack is received. the MSS is encoded in 3-bits in our syn (so our syn is 2^28 bits secure). no TSBs until ACK means no queue size ... it works.

    see http://cr.yp.to/syncookies.html for the initial discussion of implementation.

    robert m love
    my initials at tech9 dot net
  • How do we know that you aren't a fabrication? You could be some kind of bot. We have no proof that you actually are a human typing your statements. :)
  • arriving at a certain rate? For example suppose I have 10,000 packets a second from say 182.111.12.10 or something like that. Now it's not that logical that something could be naturally pumping out that kind of data so you simply force the number of possible requests that you even bother to deal with down to a predetermined level.
  • Because of the way the TCP protocol is designed, you can't do this without breaking interoperability with existing clients.

    Without going into exhaustive detail, every TCP connection starts with 3 packets:

    SYN (client->server)
    SYN/ACK (server->client)
    ACK (client->server)

    If the ACK packet gets dropped (occasional packet loss is a fact of life in the Internet), and the application protocol is such that the server speaks first (which is the case for many protocols including SMTP, FTP, and SSH), the connection hangs.. the client expects the server to say something, and the server never says anything because it doesn't have any connection state saved from the SYN!

  • Most systems have to be usefriendly for the masses of idiots out there. And teh more userfriendly the less protective it will be. This is why security will never be enough.
  • I think they've (maybe) partially solved the current problem, but I don't know enough about it to be sure. However, I think this particular solution opens up a whole new big can 'o worms. If they do some encryption in the SYN/ACK part of the hand shake, that'll take up a wee bit of processing power. Multiply that response by the hundreds of thousands of times that a DDOS attack would elicit, and you've now got a server running at 100% CPU load. The server, as with a regular DDOS attack, is now toasted until the attack stops.

    At least before, it was just bandwidth. Sure, nasty. But this about a server room with 60-70 rackmounts all running at 100% CPU. That'll be hot. Too hot. I worked for a little while at a Hydro company, and they spent about 60 grand on cooling for a single server room, and that'd only work up until all the servers were running at about 60% capacity. After that, we figured at about two hours before the fire suppression systems would fire.

    Mind you, with load-balancing and such, it might only be a few computers which would run at 100%, because since a connection was never completed, none of the other servers ever did anything. But, still, the DDOS attack would succeed. And I'd rather it just take away all my bandwidth then (possibly) costing thousands of dollars in damages.

    Dave
    'Round the firewall,
    Out the modem,
    Through the router,
    Down the wire,
  • Well he obviously assumed that the majority of sites targed for DoS attacks use NT servers, hence the assumption of regular reboots.

    After all if you were you were going to take down some major corporate site would you go after one running Apache or a Windows boxen ?
  • I may just not be following the article correctly, however the encryption of the IP address may make the system open to yet another DoS.

    Straight from the article:
    " Authentication of the Client's IP, prior to the committment of any connection resources, provides all of the benefits of Connection Management Deferral with none of the liabilities."

    If I follow this right, the encrypted data in the ACK packet will be decrypted before anything else. So a flood of ACK packets would still work since the system would go through the process of decrypting each packet, eating up CPU time, ect... before it checks to see if the source address is an address it wants to talk with.

    Still, spoofed IP packets will still work. The only thing keeping them from not working is the ability for the attacker to get the SSN value (since the attacker would specify the CSN itself). However, as TCP/IP fingerprinting techniques have shown, older Microsoft products just start at 1 every time. So getting the SSN isn't that hard.

    Even still, with random SSN values, spoofed packets could still work, however the attacker and the spoofed client would need to be on the same network so the attacking machine can sniff the SSN value and respond before the spoofed client has a chance to respond with an RST command. It makes the investigation of such attacks a little easier, but still not foolproof.

    And hell, if an attacker doesn't even care about his real IP address being discovered, SYN attacks could still work.



    -
    "There is no off position on the genius switch." --Dave Letterman
    -

  • SYN leads to death, only repentance to the Lord can save you and give you eternal life. The Lord is quite clear on this.

    Exodus 29:36 - and every day you shall offer a bull as a SYN offering for atonement. Also you shall offer a SYN offering for the altar, when you make atonement for it, and shall anoint it, to consecrate it.

    Have you sacrificed a bull today??
    -
  • by Animats ( 122034 ) on Monday September 25, 2000 @09:08AM (#756737) Homepage
    This isn't original. We've seen "SYN cookie" schemes for a while. There's also the approach of keeping a table of recently received SYN packets, but not committing the connection resources until SYN-ACK time, which is less vulnerable to cryptographic attacks than the "cookie" approach.

    Background: IP source addresses aren't validated by most ISPs, and thus can be spoofed. Attackers can't accomplish much by spoofing source IP addresses because the reply won't come back to them, so it's sort of futile. However, sending a SYN packet to a server causes the host to allocate the resources for a connection (typically a few K of RAM, including connection buffers), and those resources stay tied up for a minute or two even if there's no further traffic. So sending junk SYN packets with forged IP addresses can tie up server resources. Some solution had to be found that reduced the amount of resources that can be tied up this way.

    That's the main form of attack that works with one-way communication. Attacks that involve two-way communication are easier to trace and squelch. It's also possible to apply some notion of fairness on a host basis, which prevents attacking hosts from consuming more than their share of resources. These changes move denial of service attacks down from "devastating" to "annoying".

    Incidentally, if you have a server on a small pipe to the Internet, make sure that the upstream router at the choke point has fair queuing (a standard feature in Cisco routers) turned on for your line. This will tend to mute traffic-overload types of denial of service attacks. With fair queuing, it doesn't matter how big a pipe the attacker has; only how many hosts with unique IP addresses they have.

    The solution to distributed denial of service attacks, by the way, is to spread a few honeypots around so that attackers trolling for candidate zombies will hit one and be discovered.

  • If the ACK packet gets dropped (occasional packet loss is a fact of life in the Internet), and the application protocol is such that the server speaks first (which is the case for many protocols including SMTP, FTP, and SSH), the connection hangs.. the client expects the server to say something, and the server never says anything because it doesn't have any connection state saved from the SYN!

    But since SYN cookies aren't supposed to actually be used until the queue is nearly (or completely) full, That problem won't show up until a point where the server would otherwise just quit accepting connections at all. IMHO, a failure mode where some connections hang beats one where no connections happen at all. The problem could probably be solved on the client side by re-sending the ACK after a timeout if no other traffic happens. That will either get it a connection or a RST.

  • "Security for the DoD Transmission Control Protocol" (by Whitfield Diffie).

    Published at the "Crypto '85 Proceedings", pp.108.

    (It's probably @ www.springer.de)
  • And, not to mention the fact that they'll be using an encrypted version of the client's IP address as part of the sequence number.

    Only for the initial sequence number. After that, it can just use random increment.

  • After that, we figured at about two hours before the fire suppression systems would fire.

    If their fire supression system can't distinguish between a fire and an overheated room, they've got bigger problems. For one, the servers should go into thermal shutdown LONG before reaching combustable temperature. Also, most fire supression systems use two types of smoke detectors to determine when to act (A photocell type and an ionization type) The first to trigger sounds the alarm, the second initiates the countdown to discharge (usually with a change in the alarm tone or cadence). If heat is really that much of a problem there I would suggest that after 60 grand on cooling and at least 200 grand on servers, another grand for a system to interrupt power when the room hits 120 F would be a good investment for them.

  • And how do you know which ones to ignore? The whole point of SYN cookies is to be able to make that distinction (in a way that avoids the resource load of maintaining server side connection state before the traditional SYN-ACK).

    If you just randomly drop a certain percentage of packets, the DOS attack has simply succeeded. Indeed this will happen on its own when the server's TCP stack and/or interceding equipment is overloaded - the point of the attack.
  • how could it serve out pages as fast as hell if the load average is 130? Unless you had 130 processors in the machine or something.
  • If they can in fact say for a certainty that they have tested that many then they can by significant figures say that.
  • I know I had a nightmare of a time trying to fake that 14.00 load average when I got Slashdotted. The things I won't do in the name of neato conspiracies.
  • by Captain Derivative ( 182945 ) on Monday September 25, 2000 @05:10AM (#756746)

    "To me it seems completely bogus to base your design on the assumption that you will reboot frequently."

    In related news, Microsoft announced today that the forced-weekly-reboot feature of Windows 2000 + IIS allows for greater security, because it forces the system to generate a new key. A Microsoft spokesperson criticized the use of Linux for web servers as "Irresponsible -- why, you're using the same key for 817 days! With our system, you'd be hard pressed to get the system to use the same key for more than five days straight!"

    (or maybe not...)


    --

  • Just disable any SYN/ACK and SYN from external sources which do not correspond to a preset state. Shouldn't that work? For ICMP DoS Attacks you can just dissable ICMP on all ports. Sure you can't conventionally ping anything, but instead you could write a little script that determines latency of HTTP object requests. Just my $.02(USD) or $.03(AUSD)
  • the guy's a troll. and he gets a 3? sheesh.

    -
    "There is no off position on the genius switch." --Dave Letterman
    -
  • Personally the shutting down of a few cheesy sites that just exploit consumers isn't a big loss for me in the least. What real practical end would this try to shoot for.
  • So your server doesn't lock up from having too many half-open connections. But someone can still fill up the pipe. It's still a DOS if nobody can connect to your server, regardless of the actual state of your server.
  • Why are Linux SYN cookies not enabled by default? This seems like a useful feature, but it's somewhat hidden.


  • Remember that unlike the phone system (where the initiating client pays for the call to another hardline (and other cell phones in MOST OF THE WORLD (hint, hint, fcc!)), the Internet world is, face it, paid for by the servers.

    The servers need the fat pipe because they are the ones that need to be publicly available. And pipe don't come cheap. A T1 is $1k per month, and is well out of the range of the average humanoid. (Make 6 figures and that's a different story.) A T3 is something like, what? $10k? $30k? A month??

    The DoS is the skript punks' newest idiot-proof attack schema, just as cgi-bin probing and (for the higher-end boxen) passwd cracking.
  • I don't get it what's the problem. Just ignore them somehow.

    Somehow? Could you be more specific?

    What the problem with exceeding the speed of light? Just go faster, somehow.
    What's the big deal about having cheap energy? Just use fusion, somehow.
    Who cares about NP complete? Just figure out the shortest route, somehow.

    There - I've solved three important problems in one slashdot posting, and it's not even lunch time.

    -Pete

  • Then we have the slashdot effect. In essence this is 'like' a dos attack millions of unique connections made to a server at the exact same time... the only way to prevent this ... load balanced servers a ton of bandwidth ... or you could just not tell slashdot :-).

    Wouldn't that be security through obscurity? (:
  • I would think that apache can force only so many requests to be processed in a given time frame. That would prevent your mentioned 14.0 load average.

    My personal question that I havn't had answered yet is how does load average correlate to the actual load that machine is experiencing.
  • I don't get it what's the problem. Just ignore them somehow.
  • by Lion-O ( 81320 ) on Monday September 25, 2000 @05:17AM (#756758)
    The article starts off promising (IMHO) but it all boils down, as usual, to that very specific factor which needs to be changed yet, in the real world, never will be changed. I quote:

    The elimination of Denial of Service (DoS) vulnerability requires that the Server defers any per-connection resource commitment until the Client's remote IP address has been "authenticated". Surprisingly, the existing TCP protocol can accommodate these changes at the Server, without requiring any alteration in the Client's operation.

    Correct me if I'm wrong but DoS attacks can be stopped at this very moment. The only thing we need to do is to make sure that those servers, which need to be altered anyway according to this article, get some tighter security. In many (most?) cases the servers used for DoS attacks don't have very much prevention to attacks (break in attempts) and aren't very well monitored... So what makes you think you can prevent it by implementing this modification while other, earlier, solutions failed due to the ignorance of most server operators?

    Anyway; I'm not a tcp/ip crack myself but as far as I can tell this looks very promising. If you can manage to pour this into a form which can be easily implemented by your regular careless administrator (the primary target anyway) then it could be a very good think IMO. Any solid attempts to stop the fl00d crap deserves all the attention it can get IMO. I wonder... MS seems to be good at altering allready settled protocols like kerberos and such. If they are truly focused on end user protection and such then I'm really curious how long it will take them to implement modifications like this into their NT server. It would surely put them a bit higher on the lists of truly innovating people IMHO (credit where credits due).

  • Well if you're spoofing the packet and the source address then you may as well change the address each time, making it harder for the server to tell if all of those packets are really coming from the same place. If you also vary the time between the transmission of each spoofed packet, and make sure your sequencing numbers aren't obviously produced by the same machine, then there's not much of a pattern for a production server to find. Keep in mind that a commercial server may be taking a thousand "honest" hits every few seconds as well as trying to weed out the bad ones.
  • And, not to mention the fact that they'll be using an encrypted version of the client's IP address as part of the sequence number. So, not only does every connection use a wee bit of CPU, but every *packet* does too, since it'll either have to encrypt the client's IP for each packet(which is actually what the author suggests), or keep a cache of some sort.
    'Round the firewall,
    Out the modem,
    Through the router,
    Down the wire,
  • Eventually you can break down the problem into easier and easier steps and explain then in some form of cracking howto or whatnot and it just becomes follow the instructions.
  • Anyone can just come up with theoretical solutions to prevent these kind of things. If anything gets implemented, though, then that's news.
    ---
  • I've never had one, but then again, I don't work at a high-profile site that's really a target. However, I did get hit by that bug in BIND. So hackers are out there...
  • You seem to be confusing the unwitting sources of the DoS attack with the target. Tighter security can prevent servers from getting cracked and used to initite DoS attacks, but security won't help the target. This article is about how potential targets of DoS attacks can prevent one form of attack.
  • by b0z ( 191086 ) on Monday September 25, 2000 @05:25AM (#756765) Homepage Journal
    Ok...look at who the majority of people doing these DoS attacks are. Normally they are teenage boys who's hormones are going wild. This is not always the case but it is a safe bet that it is true over 50% of the time. So...here is the solution to prevent these kids from doing DoS attacks:

    1) Legalize drugs.
    2) Legalize prostitution.
    3) Create a welfare type program for those who do not get enough sex or need to do drugs in order to not use the computer.

    That should take care of just about all the problems in society. You're welcome.

    It's a joke, laugh.

  • Steve Gibson of grc.com claims to have come up with a way of preventing DoS attacks by spoofed SYN flooding.

    Gendarmerie Royale du Canada ? ;-)

  • alright...curve it around...
  • <i>Who runs that old operating system now-a-days anyways??</i>
    <p>
    90% of the luser who use computers, opps, i ment to say windows...
  • by Lozzer ( 141543 ) on Monday September 25, 2000 @06:07AM (#756769) Journal

    Connected [cam.ac.uk] has got some reasonably accessable articles.

  • Undernet and Dalnet are corperately ran for th emost part ... and they're protected and moderated more-so too ... but the reason dalnet and undernet are still up is sheer bandwidth and server numbers ... undernet has some 70 servers and dal has a few less ... while EF has around 15 working right now ... there's just not the bandwidth ... not to mention ... dos attacks have taken out ebay yahoo and other huge sites ... so who knows what will happen.
  • Oh hell, we should have mandatory IQ testing to remain alive.

    I'll ignore the frightening message implied by your suggestion, and remark only that mandatory I.Q. tests already exist of the kind you describe. They're called "speeding Mack trucks", "matches & gasoline tanks" and "oversize, open windows on the 70th floor", plus ten thousand other names.

  • Everyone's already pointed out the flaws of his so-called G.E.N.E.S.I.S. plan, so I'll not delve into that. I'd just like to take a minute to describe an even more effective anti-DOS countermeasure that I invented back in '94 (patent pending).

    Rather than encrypting the state within the SYN/ACK, my design never actually sends the SYN/ACK to DOS attackers, since it automatically detects a spoofed SYN sent by the attacker. It does this in a complicated, yet non-CPU crunching process involving an algorithm I specifically designed called U.N.C.L.E. For all of you laymen, that stands for
    Unplug the
    Network
    Cable from your
    Local
    Ethernet adapter.

    Use of this algorithm can be licensed from me for the low cost of $1,000 per machine it is used on.
  • you're not getting the whole DOS problem. Denial Of Service happens when you flood a server, and it get's so slow trying to swim through the shit you throw at it that the real requests take ages to be processed (if the server doesn't go down completely). So you can't just ignore them, somehow. You must acknowledge them, even if it's just to see that ou're geting X packets a second from Y IP. So you must look at all the packets. Server busy. DOS.

    This is regardless of another problem. define "normal" and "excessive" packet transmission. What about backbones and other large bandwidth connections? are you going to ignore a major router because you get too many packets from it? That's how the internet works...
  • ...is making things more complex than is necessary. Mark me off topic if you want, but I've seen this attitude a lot on slashdot and sometimes it's valid, but often it's not. You don't have to know mechanics to drive a car. You don't have to understand physics to fly an airplane. And you don't necessarily have to know how to program in order to use a computer

    Geeks are - by concept - VERY, VERY afraid of that creepy creature called 'the dumb user'. It makes Windows to become used by 94% of computer people, it makes excessively unpowered dumbed-down interfaces to appear, it lowers all standards. It is just like bad television: it happens when there is a lot of popular demand for it. Or would you call 'Survivors' a good program?

    Of curse, there must be some balance. we can't expect everybody to use emacs. But still, we also can't put limits on power users.

    following your analogy, I think it would be like that: Yes, you shouldn't learn mechanics to drive a car, but most people don't want to learn to drive and sometimes not even the transit law, they want the car to do just everything for them.


    Patola (Cláudio Sampaio) - Solvo IT
    IBM CATE
    SAIR GNU/Linux Certified

  • Then we have the slashdot effect. In essence this is 'like' a dos attack millions of unique connections made to a server at the exact same time... the only way to prevent this ... load balanced servers a ton of bandwidth ... or you could just not tell slashdot :-).

    Perhaps a mirroring system could be set up. Any site that gets posted on slashdot, is mirrored on the slashdot servers. A percentage of connections get sent to the real site(when someone tries to click the link), and a percentage remain on the slashdot mirror thereby relieving the host of the huge impact of the slashdot effect. Or some of it anyway.

    Just a thought. :-)


    -----
    "People who bite the hand that feeds them usually lick the boot that kicks them"
  • "Forty" was often used in the original languages of the region to poetically denote a big number.


    This style was also reawakened by the modern rapper to denote large amounts of Malt Liquor. Usually Old English 800 or Colt 45.

    Back on topic. The parent of this message suggested using Carnivore like engines to stop DOS types of attacks. If you mean a bridge like engine to filter traffic, this becomes dangerous because of the false positives generated by legitimate traffic matching attack signatures. With more and more big pipes going to normal users, how do you propose to distinguish between real traffic and malicious traffic? If you were referring to government sponsored engines like Carnivore, obviously the plot simply thickens.

    Also, I find it interesting the posts regarding this article are split between "this system will never work," and "Linux has had this for years in the form of SYN Cookies." So which is it slashdot? Naysayer touting how smart they are or blind Linux zealotry?

  • The processor in your server is always executing (roughly) that same number of instructions. If utilization is less than 100% the processor will be executing idle instructions.

    Ever heard of HLT?

    The utilization of the processors in your server will not affect the temperature of the room that it is in to any great extent. Especially with proper ventilation.

    Got any proof of this? It's certainly contrary to what every overclocker knows.

    The problem with SYN floods is not really the bandwith, it is the fact that the servers maintain arrays of connection states for all connections and these arrays will overflow with nonexistent connects if you just keep sending SYN's. If all you wanted to do was use bandwith, you could just send random packets (even to non-existant addresses).

    True.

    you are probably a troll

    Hmm. By saying that, doesn't it make YOU a troll?
    --------
    "I already have all the latest software."

  • there are a few reasons ... one of the main reasons is that connection reporting falters with syn cookies enabled. since there are no TSBs until the connection is made (in other words, there is nothing stored about a connection during the connection process) the only way to log the events is via filtering with something like tcpdump. during a heavy syn flood, the sniffer may drop packets. not a big deal, in my opinion. the Configure.help for CONFIG_SYN_COOKIES mentions this.

    originally it was a concern that syn cookies would impose a noticable performance hit, but currently linux uses a hash to generate the initial syn anyhow, so isnt a big deal.

    there are some other technical issues, although linux's implementation is supposed to be void of most (all?) of them. see my previously posted link for the e-mail discussion of the implementation, where the issues are discussed. the "new" proposal actually has some issues our's does not. Alan Cox posted to linux-kernel earlier mentioning some flaw. a year earlier, a magnitude better -- linux :>

    currently, the config option defaults to off and even when enabled, the sysctl defauls to off (you need to "echo 1 > /proc/sys/net/ipv4/tcp_syncookies" to enable them).

    i think i agree, because it is an extra feature that should default to off (or just be a standard nontoggleable part of the OS) .. but if you do enable it, the sysctl (a Good Thing) should default to on, imo.

    robert m love
    my initials at tech9 dot net
  • Does McDonalds have "More than 99,287,322,398 Hamburgers Sold" posted on all their stores?

    Of course they don't. They don't say how many hamburgers they've sold. It simply says something like "More than 92 billion sold". 92 billion what? As it turns out, that's patties, not hamburgers. A Quarter Pounder counts as one. A Big Mac counts as two. And so on and so forth.

    Just another useless tidbit with which to impress your friends. =-)
  • C'mon now.
    What kind of intelligence would you test? Verbal? Spatial? Mathematical? Motor coordination? Musical ability?

    Most of the programs out there are used by business people or artists who really don't have the same time or abilities that most geeks do, but they do have other very valid skills and abilities. And after all, tools are supposed to be as easy to use as possible.
    One of the key tenants of object oriented programming is data hiding. Programming in assembly when you don't have to is not a virtue and neither is making things more complex than is necessary. Mark me off topic if you want, but I've seen this attitude a lot on slashdot and sometimes it's valid, but often it's not. You don't have to know mechanics to drive a car. You don't have to understand physics to fly an airplane. And you don't necessarily have to know how to program in order to use a computer.

    Hell, once you think about it, we wouldn't be in this predicament if it weren't for all those dang blasted 'intelligent people.' Heck no, we'd be out on the farm drinking our whiskey, shooting injuns and bopping our first cousins. And by golly, we'd like it. Of course, I can't say the same for my first cousin.



  • I would have liked to have read it.. but either I'm having routing problems at my ISP or it's been /.ed.
  • DDOS still can exist, and is commonly used, wether or not the alledged attacks actually took place when they did.
  • I thought the idea was to do random drops beyond a certain threshold. The idea is that above that dropping connections should only punish the bogus, flooded connections. Since the majority of new connections are bogus, the majority dropped should be bogus, too.

    Think of it in terms of a bar that checks IDs -- if 200 underage people show up and stand in line with 10 of age people. If you turn away automatically one out of five people to ensure you can get someone in the door, the probability that you're turning away underage people should be much higher since there's that many more of them. It doesn't matter where they come from, so spoofing isn't a factor.

    Is there a reason why this wouldn't work? I can see where its not perfect -- you still could get dropped even if you're not spoofing, but the odds should be against that happening.

    I don't know how well it would work with sites that already run near the limit of their SYN-processing capacity -- the DoS may turn out to be to flood them just enough to turn on connection dropping and then stop right away, getting a lot of new, good connections to drop. The trick would be to be able to detect the presence/absence of a flooding condition very quickly and react approrpriately.

  • sorry, meant to post that with my main account
  • The oldest? That would discard slow connections before they fully connect.
    While this is true assuming you have the bandwidth It will work in most cases. However as long as you send enough packets to a network you can make it unuseable even if the router/server dosen't auctually crash. Although if you know your gated-foo well enough you can easily set it up to reserve routes for the internal network and dial in to the network. From there you could start analizing the attack and hopefully track down the script kiddies.
  • Sounds like a great idea but reengineering TCP/IP and updating every computer on the net with the new protocol is just not very feasible.

    There's gotta be a way to implement hardware that can detect a DoS, and ignore it. In other words DoS proof NIC's or Routers even.
  • Steve Gibson is loosing his touch I think. His origonal great product was Spinrite, but it's pretty much useless now as it can't access any new drives at low enough a level to be effective.

    I think you're being too hard on Steve. His company is doing a service to the Windows-users of the world...even if this DoS solution is mostly a translation of an existing Unix solution.

    Spinrite: It was valuable because of design limits in drives that are no longer a problem;

    MFM and some drives (IDE/SCSI) made when MFM was still being sold didn't autocorrect defects.

    Tracks would drift over time due to temperature changes (any drive).

    Drives were expensive so correcting track drift and defects is a good way to keep from spending more money.

    While defects still crop up, and temperature changes do cause tracks to drift, most modern hardware automatically corrects this at the physical level. The logicial level is the only part that is still exposed to the system, and Spinright can't use it. This means that for every drive they'd have to find out how to access the physical part of the drive ... and when they get there most drives don't need it!

  • Steve's Shields Up tool is an excellent way to find out if your Windows PC is open to common attacks from the internet. I tried it before I got a personal firewall and all sorts of things were exposed ... once I got ZoneAlarm, most common attacks didn't work.

    This is particularly important for DSL/cable users - remember the 911 Worm!

    sulli

  • Just don't run DOS! Who runs that old operating system now-a-days anyways??

    Sorry, I had to do it.

  • ...to all the DEA agents who would be out of work.

    I have a better solution: mandatory castration for all males, lock their nuts up in a safe, preserve them cryogenically (the nuts, not the boys), and when they turn 25 or 30, they can have their nuts back.

    Oh, and for the sake of the religious zealots out there, require that the guys be married already to get their nuts back. And if they want a divorce, they have to have their nuts removed again, and they still have to wait a couple months before they can have their divorce.

    This should cut down on gang activity, road rage, unintended pregnancy, rape, "sports scholarships", and with any luck, we'd force some lawyers and politicians to get real jobs.
  • 1985 called... They want their assembler code back!
    --
    This guy does some cool stuff... but man, why does it all have to be in assembler. C is readable and damn fast these days.
  • Yes.

    In other words, false dichotomy, bad assumption.
    Major corporate sites tend to use Apache. Apache can run on Windows boxen.

    So yes, you would target a system running Apache and/or Windows.
  • Correct me if I'm wrong but DoS attacks can be stopped at this very moment. The only thing we need to do is to make sure that those servers, which need to be altered anyway according to this article, get some tighter security. In many (most?) cases the servers used for DoS attacks don't have very much prevention to attacks (break in attempts) and aren't very well monitored... So what makes you think you can prevent it by implementing this modification while other, earlier, solutions failed due to the ignorance of most server operators?

    You're comparing different things. In the case of security, an admin implements better security so OTHERS don't get DoSed. In the second, the admin makes the changes so that HIS server doesn't suffer so badly from a DoS.

    The first isn't likely to work because there are so many clueless out there, and many low priority servers that tend to sit wide open and forgotten. The second is much more likely to happen since most people do care if their important servers get DoSed, and will try to avoid it.

    If the feature makes it's way into various OSes and defaults to on, it will be even more widespread.

  • This is pointless, why burden the server with extra crap when it can be done at the router. All you need is a cisco router with 12.0 enterprise code. You can set limits on how many half open connections you allow at a time. Then when that limit is reached it will prune them back to a pre-determined number. Or you can use a " transparent proxy " of sorts that does the same thing on the same router. It will take the syn on behalf of the server, send the syn ack, and if it is legit, put them back together. Both of these processes are totally transparent to both the server and client. Just my 2 cents
  • by BitKat ( 14840 ) on Monday September 25, 2000 @04:38AM (#756821) Homepage
    I don't need to tell anyone what the weakness will be when this scheme uses a fixed key. So, they say they want to generate a new key each time the system restarts (sic!). Last time I booted my server it had been up for 817 days. To me it seems completely bogus to base your design on the assumption that you will reboot frequently. (Or, for that matter, on any assumption at all)
  • by mayoff ( 29924 ) on Monday September 25, 2000 @04:38AM (#756823) Homepage
    This guy's "innovations" aren't new; IPV4 SYN cookies were invented by Eric Schenk and Dan Bernstein back in 1996. Not only that, but GRC's solution (as described on that page) doesn't address MSS or even discuss TCP options. See http://cr.yp.to/syncookies.html [cr.yp.to] for a much better discussion of TCP cookies.
  • by jjr ( 6873 )
    This is seems to just protect on the transport level this wil not help people running bind or sendmail that is a bug in it I am not saying this is not cool because it is. What I like about the solution is does require the any change to the client
  • I think Arrowpoint (now Cisco) claims patents over some of this idea (though how it is or is not the Bernstien/IPv6 idea I don't know).

    What they claim to do is respond to the SYN, and forget about it. Then, they initiate a session when the SYNACK comes through. The interesting part is that they're not the host. They just initiate the session and then do some basic setup if it's one of the protocols (e.g. HTTP) that they know. Cool stuff, actually, as you can have complex load-balancing rules based on information which something like a LocalDirector would not know (e.g. URL, browser, HTTP version, etc).

    I like the Arrowpoint, but it's important to know it's limitations. If you get one, don't get carried away thinking it's a router. It's not. It will "forward" packets to its VLANs in a way that make it look like a router, but that a router does not make.
  • . "Forty" was often used in the original languages of the region to poetically denote a big number.

    Why didn't they just say forty-too then? A much nicer number.

  • by Emil Brink ( 69213 ) on Monday September 25, 2000 @04:41AM (#756837) Homepage
    One simple suggestion: read more books. I'd recommend the late (and sorely missed) Richard W. Steven'sTCP/IP Illustrated, Volume I: The Protocols [fatbrain.com] as a starting point. It's a great book, and really easy to follow. It's $70 that will really help you understand stuff.
  • by Anonymous Coward
    The BOFH solved this more elegantly. Check out the newest episode at The Register
    (www.theregister.co.uk)

    The basic idea, is not to provide service. Then there can be no denial of service.
  • This was a useful idea a couple years ago (SYN cookies) when SYN attacks meant some kid was throwing a few hundred SYNs/sec at you. Now the attack du jour is to have a few hundred hosts spew traffic at a site. If people are throwing 45mbit/sec of traffic at your 1.5mbit/sec link, it really doesn't matter what you do on your end. You're clogged. Game over.
  • by pixelbeat ( 31557 ) <P@draigBrady.com> on Monday September 25, 2000 @04:45AM (#756841) Homepage
    Steve Gibson is loosing his touch I think.
    His origonal great product was Spinrite, but
    it's pretty much useless now as it can't access
    any new drives at low enough a level to be
    effective.

    So he has resorted to screen savers/ TCP
    connection monitors/ FUD

In every hierarchy the cream rises until it sours. -- Dr. Laurence J. Peter

Working...