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.
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!"
Don't Panic...
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.
Fire and Meat. Yummy.
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!
cat
DOS != DoS;
DOS = "Disk Operatin System";
DoS = "Denial of Service";
-------------------------
-------------------------
Who is General Protection Fault, and what he does in my Computer ?
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?
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.
Respond to s
Does 95/98/ME/2K have vulnerabilities to SYN floods or has Microsoft patched this too?
Anyone have any links to it?
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.
/ \
\ / ASCII ribbon campaign for peace
x
/ \
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.
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.
``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.
zenray
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.
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
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.
Respond to s
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.
Upeo
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.)
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 ?
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??
-
I've had enough abrasive sigs. Kittens are cute and fuzzy.
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.
"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 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.
Respond to s
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.
---
Slashdot: News For Zealots. Stuff That's Hypocritical.
"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.
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)
Sigh.
---
Slashdot: News For Zealots. Stuff That's Hypocritical.
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.
Respond to s
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)
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 used to be someone else. Now I'm someone better.
Real life is underrated.
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
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.
Respond to s
I don't get it what's the problem. Just ignore them somehow.
Respond to s
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).
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.
Respond to s
Anyone can just come up with theoretical solutions to prevent these kind of things. If anything gets implemented, though, then that's news.
---
GetSystemMetrics(SM_SECURE) == FALSE
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...
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.
Gendarmerie Royale du Canada ? ;-)
alright...curve it around...
You can't destroy the Earth, that's where I keep all my stuff!
Who runs that old operating system now-a-days anyways??
<p>
90% of the luser who use computers, opps, i ment to say windows...
MarNuke
Connected has got some reasonably accessable articles.
Special Relativity: The person in the other queue thinks yours is moving faster.
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 truly excellent pizza parlor is a delight unto the heavens. Treasure the sauce and the toppings!
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
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
Patola (Claudio Sampaio)
Unix System Administrator
"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?
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.
___
It's the end of my comment as I know it and I feel fine.
I would have liked to have read it.. but either I'm having routing problems at my ISP or it's been /.ed.
-- Soruk
DDOS still can exist, and is commonly used, wether or not the alledged attacks actually took place when they did.
http://siokaos.org/
sorry, meant to post that with my main account
-- the most controversial site on the Web
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.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
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.
I'm certain that there will be a way of getting a new key generated without restarting probably the same way you kill/restart inetd after you edit it.
An Education is the Font of All Liberty
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.
Well, if you want to be pedantic, most of the bible cannot (or should not) be taken literally. First, the stories were passed on by word-of-mouth for thousands of years, transcribed by the hands of monks for centuries, and translated numerous times over the course of history.
Also, we don't know how long a "year" was, so saying Noah was 600 when he got on The Arc and 601 when he got off, doesn't really tell us anything. (see above about word-of-mouth.)
This is particularly important for DSL/cable users - remember the 911 Worm!
sulli
sulli
RTFJ.
Being an IRC Operator on EFnet, DDoS, or any type of DoS, is tossed around pretty frequently.
.. we can hope. Will it happen? Doubtable until someone decides to nail the government with one of these.
Being a network without services, EFnet is vulnerable to channel takeovers by 'removing' all channel members, or in some cases channel operators. Mostly this is done through the use of a DoS attack. Also, personal grudges between people may result in attacks as well, or an IRC operator may get attacked for placing a server-side ban on someone. Basically, it's the high-school bully principle extending to the online chat world. With what I do online, I experience and/or see the effects of such attacks almost daily.
As for the DDoS validity in the posts below, DDoS -is- real. Whether or not these large companies got attacked is up for speculation of any sort, as logs can be faked and it becomes a case of one persons word against another; it's hard to have concrete evidence in such a matter. However, again, seeing the effects of these attacks, and having been involved in the 'clean up' or preventitive aspects of these attacks, I have seen DDoS in action. I have even been logged into a machine which was (one of) the sources of such an attack. The vulnerabilities in IPv4 are real, whether or not the attacks on the major sites were. (Besides, why would they fake such a thing?)
What bothers me, is that this had been going on for a long while before hitting the media. When small companies or individuals undergo a denial of service, no one lifts a finger. As soon as a multi-million dollar company is involved, they call in the cavalry.
In my opinion, it should be legislated that internet service providers be responsible for the machines on their network or their client network. If the provider is notified about a possible server used in an attack, and it can be verified, it should be made *illegal* to keep that machine on their network. Perhaps even legislate the use of egress filters to prevent spoofed attacks
www.arrogant.org - food for your brain
"script kiddies" are everywhere. Most of them are too stupid (inexperienced???) to know what they are doing. Just pick an address range and scan it... Sometimes you don't realize how much damage you can do.
:-) And yes, I've unintentionally fubar'ed things in my explorations.
For the record, I've never been a script-kiddie... I always write my own
How frequently do these attacks occur? Apart from a few high profile ones a few months ago, I haven't heard anything about them....
Where is the proof last year's DDOS attacks were real ? All we had was, at the beginning, some reports according to which yahoo.com had been unreachable for a few minutes, which was denied by yahoo, and then that famous media storm... But still no proof a DDOS did really take place.
-- javaDragon is an instance of JavaDragon.
I am not 100% sure (coz I am too lazy to read the whole article), but this sounds very much like the "SYN cookie" solution now available in the Linux kernel. See this article for a discussion of the principles behind.
This method of defense against a SYN flood is a feature implemented by the PIX firewall. The feature is called Floodguard, and is in all PIX IOS versions beyond 4.2(x). The biggest drawback is that the PIX sits behind a router that may or may not be vunerable to this attack.
HTH
Marv
it is better to light a flame thrower than curse the darkness. -Terry Pratchett Men at Arms
Simple ingress/egress filtering based on the address space for the connected network.
Do not let addresses out that are fake, nor let any of your own addresses in. Basically 10 minutes worth of work by any half brained sysadmin would totally solve the problem.
If the attack cannot originate, then there is no attack.
Ok, if someone does not care about being identified, then they would do it from an 0wn3d host, but there would be a better chance of the "problem" being fixed if the addresses getting in/out of a network are a known commodity......
This space intentionally blank
dnnrly
If you really want your machine to be immune to DoS attacks, get rid of your Net access/NIC card, and install DOS.
You can't have a Denial of Service attack if there's no Service to Deny in the first place, fool.
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.
The drawbacks of your CISCO/router approach include 1) lots of state at the router 2) even if protecting the server behind the router from load, it will start discarding incoming legitimate connects, which makes the server's lack of load rather moot since nobody can get to it anyway.
Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
Now I take the ACK packet I sniffed and feed it to about 100? DDoS scripts at cracked machines on the web.
Because the key does not change and because I supply the ACK packet, ALL these incoming packets are valid, and they can come from anywhere.
Unless a cache is maintained and duplicates are tossed, each of these ACKs should establish a valid connection on the server.
I am not familiar with TCP/IP internals (and I would guess this is hardware specific) but I would expect these validated connections to be worse (more persistant) than broken attempts.
Probably something I missed here but I can't see it.
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.
Just thought I'd waste more moderation points by throwing in more offtopic info. "Forty" was often used in the original languages of the region to poetically denote a big number. That's why it repeats so often. You get "forty days and forty nights". You get Christ going into the desert for forty days and you get the isrealites wandering for forty years. It isn't meant to be taken as literally the exact number 40.
As an interesting sidenote, the Chinese use ten-thousand in much the same way all throw the Tao Te Ching.
The cake is a pie
Have you ever seen the 5 minute short Twilight Zone episode with the IQ testing? It's very chilling...
...A mom and a dad are preparing their child for the intelligence test in what appears to be the future with a "1984 Big Brother" feel. The kid is all happy and says he'll do just fine because it's an easy test. The parents look nervous and you get the idea that they are not confident that he will pass. Then the parents find out that their smart child scored high. Good, right?
[Cue scary incidental music]
The parents then break down and cry as we, the viewers, learn that this society kills children that score too high, presumably to keep the people suppressed.
--
dman123 forever!
--
dman123 forever!
Filtering out the -1s and 0s since 1999.
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.
It's called evolution.
:-)
Havn't you seen the annual Darwin awards?
Apparently nobody else was as bothered as I was by the paren mismatch in the post. But to me, it's worse than fingernails on a blackboard.
I would have liked to have read it.. but either I'm having routing problems at my ISP or it's been /.ed.
They're getting a slashDOS? Kinda ironic...
___
__
Do ya feel happy-go-lucky, punk?
Honestly, why take such measures against hackers? They can have a fool-proof way of preventing DoS hacks, but some brilliant, pissed-off computer genius will find a way around it, then tell the 31337 Crowd how to do it, and now a new problem has arised...
I guess its best to make it so some dumb 31337 B1FF can't do it, but I don't think we need to take super-desparate measures...
-- "Microsoft can never die! They make the best damn joysticks around!"
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
... the difference that this version is patented and there's fuck all you can do about it.
-- the most controversial site on the Web
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.
...., that is a DoS defense
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
Why didn't they just say forty-too then? A much nicer number.
- what the hell has been happening to EFNet?
Indeed. Alot of the problems appear to be political. And the over inflated egos of the operators don't help matters.There are now, what, two open servers? Most of the server require ident to connect even though ident is 150% worthless in proving an identity. And at least one of those servers doesn't have an inverse DNS record so it's impossible to connect to it (>15s for DNS to error out but the server has stopped waiting for the ident response and closes the connection.)
- DoS attacks on the servers
Yes, there have been and are attacks on the EFNet servers. This is simply children being, well, children. The IRC protocol was never designed to survive in the present-day, hostile Internet. It's a tree structured bandwidth whore. And it looks like very few people are actively maintaining that spooge. (None of the stat pages about EFNet are being updated correctly. None of the maillist archives are up-to-date or even work correctly. Etc.)Because of the threat potential of hosting an EFNet server, most ISPs don't want to run one. Plus the administrative overhead, the bandwidth, and the political mess involved in being part of EFNet...
- can't this sort of thing be tracked?
Yes, it can. However, it takes time and the cooperation of many people often in different time zones and even different countries to trace back to the source. And when you do find the source, you have to find the ass who broke into the box somewhere in outer mongolia... Then what do you do when you actually find the 13year-old idiot in Utah who did all of this? Or some teen in China? Sorry; a lot of this shit simply cannot be prosecuted. And then there's nothing to prevent them from doing it again. - ... These packet monkeys
...
Maybe, but it's effective. Parts of EFNet are knocked around everyday. I would attribute some of this to children taking over channels. You don't see this in other IRC networks because they handle transient network problems better and some have nick and channel servers to maintain control. EFNet is still the "lawless wild west" of IRC networks. (The Ops like it this way -- power trip and all that sorta stuff; plus it limits the amount of stuff they have to care about.)insightful
Showing or having insight; perceptive: "The major contribution of this new biography . . . is its insightful discussion of the Christian dimension of Dostoyevsky's life and art" (Maria Carlson).
heres where that came from, gunch!
That guy has insight, its not funny.. what a bunch of poppycock!
click here to incinerate homeless people
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.
Instead I think we should require mandatory IQ testing in order to use a computer. Oh hell, we should have mandatory IQ testing to remain alive.
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