Slashdot Mirror
Solution To DoS Attacks
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.
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.
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.
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.
Ignore the "p2p is theft" trolls, they're just uninformed
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?
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
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
Looking for a Python IRC bot?
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.
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)
... it works.
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
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!
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,
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
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.
"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...)
--
--
The real Captain Derivative has a Slashdot ID.
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.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
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).
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.
Mas vale cholo, que mal acompañado.
Connected has got some reasonably accessable articles.
Special Relativity: The person in the other queue thinks yours is moving faster.
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.
"If Stupidity got us into this mess, then why can't it get us out?" -- Will Rogers
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.
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!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
This is particularly important for DSL/cable users - remember the 911 Worm!
sulli
sulli
RTFJ.
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.
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
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)
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 for a much better discussion of TCP cookies.
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.
Why didn't they just say forty-too then? A much nicer number.
One simple suggestion: read more books. I'd recommend the late (and sorely missed) Richard W. Steven'sTCP/IP Illustrated, Volume I: The Protocols as a starting point. It's a great book, and really easy to follow. It's $70 that will really help you understand stuff.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
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.
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