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.
Re:Bye bye DOS (Score:2)
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.
Re:dos attacks (Score:1)
Please.
Because what OTHER mandates might the legislators throw into the same bill?
-- Michael Chermside
Re:this can't work, in general. (Score:2)
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.
Re:DDoS is inherent to the net (Score:1)
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 yesterday? (Score:1)
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.
Re:Where is the proof ? (Score:1)
Re:A better solution (Score:1)
DOS = "Disk Operatin System";
DoS = "Denial of Service";
-------------------------
DoS Vs SlashDot Effect ... (Score:3)
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.
Re:Where is the proof ? (Score:2)
Re:this is an old old idea (Score:5)
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]
I really hope the creditted D. J. Berstein. (Score:3)
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
Slashdot == DOS abusers! (Score:1)
Doen't the ipv6 spec largely prevent DoS attacks? (Score:1)
Microsoft OS's vulnerable? (Score:1)
Anyone have any links to it?
Re:I'm not so sure this is a good idea... (Score:1)
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.
Re:SYN floods (Score:1)
wrong direction (Score:1)
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.
Re:DDoS is inherent to the net (Score:1)
``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.
--
Re:Where is the proof ? (Score:1)
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.
Re:A better solution (Score:1)
this is an old old idea (Score:5)
DDoS is inherent to the net (Score:1)
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.
Re:dos attacks (Score:1)
Re:this is an old old idea (Score:1)
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
this is old news -- already in linux -- details (Score:5)
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
see http://cr.yp.to/syncookies.html for the initial discussion of implementation.
robert m love
my initials at tech9 dot net
Re:Where is the proof ? (Score:1)
Isn't it possible to drop packets if they... (Score:1)
this can't work, in general. (Score:2)
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!
But... (Score:1)
I'm not so sure this is a good idea... (Score:2)
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,
Re:This ain't gonna work (Score:1)
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 ?
Authentication of Address Gives Way to Another DoS (Score:1)
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 (Repent Now) (Score:1)
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??
-
Old news again (Score:3)
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.
Re:this can't work, in general. (Score:2)
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.
EEEEEE! Wrong (This is at least 15 years old!) (Score:1)
Published at the "Crypto '85 Proceedings", pp.108.
(It's probably @ www.springer.de)
Re:I'm not so sure this is a good idea... (Score:2)
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.
Re:I'm not so sure this is a good idea... (Score:2)
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.
Re:Can't they just be ignored or rejected? (Score:1)
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.
Re:Isn't there a way to keep load in check? (Score:1)
About percision of numbers (Score:1)
Re:Where is the proof ? (Score:1)
Re:This ain't gonna work (Score:4)
"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...)
--
What about good old IP-Filter (Score:1)
Re:A better solution (Score:1)
Re:Where is the proof ?TROLL (Score:1)
-
"There is no off position on the genius switch." --Dave Letterman
-
To What end? (Score:1)
Yes but.... (Score:2)
Re:this is old news -- already in linux -- details (Score:2)
DDoS: The phf holes of the present? (Score:1)
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.
Re:Can't they just be ignored or rejected? (Score:1)
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
Re:DoS Vs SlashDot Effect ... (Score:1)
Wouldn't that be security through obscurity? (:
Isn't there a way to keep load in check? (Score:1)
My personal question that I havn't had answered yet is how does load average correlate to the actual load that machine is experiencing.
Can't they just be ignored or rejected? (Score:1)
No go unfortunatly. (Score:3)
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).
Re:Isn't it possible to drop packets if they... (Score:1)
Re:I'm not so sure this is a good idea... (Score:2)
'Round the firewall,
Out the modem,
Through the router,
Down the wire,
That dosn't work well at all to make it hard (Score:1)
Well duh (Score:1)
---
Re:dos attacks (Score:1)
Re:No go unfortunatly. (Score:1)
The *REAL* solution (Score:5)
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.
Funny domain name (Score:1)
Gendarmerie Royale du Canada ? ;-)
Re:Bye bye DOS (Score:1)
Re:A better solution (Score:1)
<p>
90% of the luser who use computers, opps, i ment to say windows...
Re:Learning more? (Score:3)
Connected [cam.ac.uk] has got some reasonably accessable articles.
Re:DoS Vs SlashDot Effect ... (Score:2)
Mandatory IQ Tests (Score:1)
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.
A better solution I invented (Score:2)
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.
Re:Can't they just be ignored or rejected? (Score:1)
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...
Re:This won't solve much. (Score:1)
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
Re:DoS Vs SlashDot Effect ... (Score:1)
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"
Re:DDoS is inherent to the net - OT CORRECTION (Score:1)
"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?
Re:I'm not so sure this is a good idea... (Score:1)
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."
Re:this is old news -- already in linux -- details (Score:1)
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 >
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)
robert m love
my initials at tech9 dot net
Re:How gay is that? (Score:1)
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. =-)
Re:This won't solve much. (Score:1)
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.
Re:the difference is (Score:1)
Re:Where is the proof ? (Score:1)
Re:Isn't it possible to drop packets if they... (Score:2)
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.
Re:the difference is (Score:1)
Re:Bye bye DOS (Score:1)
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.
Another way? (Score:1)
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.
Re:Mr. Gibson (Score:2)
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!
I disagree (Score:2)
This is particularly important for DSL/cable users - remember the 911 Worm!
sulli
A better solution (Score:2)
Sorry, I had to do it.
That just shifts the problem... (Score:2)
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.
Called... (Score:2)
--
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.
Re:This ain't gonna work (Score:2)
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.
Re:No go unfortunatly. (Score:2)
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.
Re:Bye bye DOS (Score:2)
This ain't gonna work (Score:4)
Not new, and not complete (Score:4)
DOS (Score:2)
Arrowpoint? (Score:2)
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.
Re:DDoS is inherent to the net - OT CORRECTION (Score:2)
Why didn't they just say forty-too then? A much nicer number.
Re:Learning more? (Score:3)
BOFH did this better (Score:2)
(www.theregister.co.uk)
The basic idea, is not to provide service. Then there can be no denial of service.
This doesn't protect against "big" attacks... (Score:2)
Mr. Gibson (Score:3)
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