My mouse, on the other hand, makes a very audible *click* each time I use it, and while providing a pleasant tactile feedback, it keeps my girlfriend awake during my late-night work sessions.
But seriously, are you living in a studio apartment or something? Add this to the long list of reasons that the computer should not be placed in the bedroom (I say this of course lounging on my bed with my laptop, but hey, I'm a bachelor, I'm allowed to do these things).
And attitude like that is precisely what will keep Linux from the desktop.
No, attitude like that is precisely what will keep proprietary crap like Lindows off the desktop.
Some people want it to be easy, people like you will slam something like Lindows that makes it easy.
There's nothing wrong with easy. Hell, I even want it to be easy. But that's why I use Windows. When I want proprietary insecure crap I go straight to the source - Microsoft.
Well, the PIX might work that way (on a global level), but if so, that's a design flaw in the PIX. It's perfectly possible and reasonable for a firewall to count SYNs per second on a per-host basis, and that would avoid losing an entire subnet when a single host is under attack.
However, firewalls with that kind of capacity aren't terribly expensive. (50k packets/s)
50K connections/second was what they were able to handle (and the more I think about it, it seems like it was definately a firewall that was getting hit). Could they have bought a more expensive firewall? Sure. They probably have, by now. But I wouldn't call someone incompetent for not buying such a firewall off the bat.
But, if the firewall was puking about the syn-flood that would also mean that it would be slow to establish connections to the ftp server?
Probably not. If the firewall is built properly it's not going to let an attack on one server affect others.
I believe most vendors use a common connection table for all inside hosts. (Wouldn't be practical for a seperate connection table for every inside ip)
Most firewalls only implement SYN protection when a host is being hit by more than a certain threshold of SYNs per second. See this, for instance.
NetScreen devices can impose a limit on the number of SYN packets per second permitted to pass through the firewall. When that threshold is reached, the NetScreen device starts proxying incoming SYN packets, sending out SYN/ACK responses for the host and storing the incomplete connections in a connection queue.
So until the FTP server started getting attacked, the firewall would pass the SYNs right through.
It seems to me that SCO did have a firewall, and that firewall's SYN protection was limited to 50,000 connections per second. That would explain why the rest of the subnet remained up. And it also explains why the backscatter kept coming after the server was taken down.
"
The issue is not the bandwidth," explains Abhay Joshi, Top Layer's manager of ISP relations. "Each SYN packet could be 50 bytes, so 2 Mbps of SYN flood would be about 10,000 packets per second.
Also, it was interesting to note that the Foundry firewall they tested happened to go up to 50,000 packets per second, which is approximately the same as what SCO was seeing (at least, what the backscatter was implying, and the backscatter would only show SYNs which were being handled). It also says that their hardened servers could only handle 10,000 packets per second, so SCO probably was using a firewall with SYN flood protection.
Could SCO have opted for the Top Layer firewall which could handle 750,000 SYN attack packets per second. Sure, they could have, but it surely would have cost a fortune and been overkill.
My point is that most companies have some sort of firewall protecting their servers. PIX and many many others do protect against SYN attacks.
If the attack is devoting a lot more more processing power and bandwidth to the attack than your firewall, you're not going to be able to stop it.
If they are properly connected, (and the firewall has the processing/memory available to ward off the syn attack. It would make sense to buy a firewall capable of handing your link speed) then the only thing to bring you down is to generate so much data it simply floods your link to the internet.
I'd like to see a firewall that can handle a 50,000 packet per second distributed SYN attack using spoofed addresses, all the while holding enough state information so that only legitimate connections are passed through. Then I'd like you to tell me the price of such a firewall.
By the way, merely saturating your link to the internet wouldn't be enough. The internet can handle dropped packets. You'd have to hit it with many many times the capability of the link. And even then, some percentage of requests would get through, they'd just be slow.
To have the server bogged down by a SYN attack when the link is still operational is fairly poor administration. You are losing service when you don't otherwise have to.
You never have to lose service. The question is how much do you want to spend to protect yourself against such a rare case. Maybe it was poor administration. Maybe it wasn't. The fact that one machine was brought down without the whole subnet going down is a good thing, though. In fact, any decent firewall which is administered correctly is going to make sure that happens.
They spoof the destination IP and change it to the IP of the target to be attacked and all those webservers (usually ~40,000) respond at once to the host, essentially knocking it offline.
That wouldn't really be a SYN attack, as the response packets would have SYN and ACK set. It would also be much easier to protect against, as these bogus SYN/ACK packets could be dropped. But most importantly, there wouldn't be any backscatter, and certainly not the backscatter that CAIDA was seeing.
So you can use even a secure (but not 100% properly configured) server to launch an attack with...
Improperly configured so as to be able to launch an attack isn't secure. But, I'm really not sure how you could configure a machine not to respond to HTTP requests, anyway. Fortunately, as I mentioned above, this type of attack is much easier to ignore than a true SYN attack.
I guess I quoted too much for your little mind to handle. "(1) IN GENERAL- This Act supersedes any statute, regulation, or rule of a State or political subdivision of a State that expressly regulates the use of electronic mail to send commercial messages, except to the extent that any such statute, regulation, or rule prohibits falsity or deception in any portion of a commercial electronic mail message or information attached thereto."
As I said, "The federal law doesn't supercede state laws regarding fraudulent or deceptive spam."
No, I don't know what you meant. You are implying that there's a way to stop a SYN flood which doesn't saturate your bandwidth, but that's simply not true. Put your 500 Mhz Celeron on a 100 Mbit LAN with 5 Ghz Celerons, and it'll take a whole lot less than 100Mbits to saturate your machine.
So quite obviously the www server was not protected from syn's nor was the link fully eaten up by these packets. Since the ftp server was responsive until it became a target, as well as the fact that these reports mention that the amount of traffic significantly increased when the ftp attack was launched.
OK, so if I hook my computer up to my cablemodem, and turn on syncookies, then the only way you can kill my server with a SYN flood is to kill my entire subnet?
Of course not.
You don't have to saturate a link to saturate a server. And any router not written by a moron isn't going to let traffic going to a single host saturate the entire bandwidth of the subnet.
OK, so how do you protect yourself from 20Mbps of legitimate-looking traffic?
With syncookies.
That's great. Where can I download these magical "syncookies," and how can I hook them up to my email address? Sounds like they'd be useful for stopping spam..
SYN cookies only stop the asynchronous nature of a SYN attack. If the attacking machines have far greater CPU and bandwidth available to them, and they are able to spoof random IPs and send them from multiple different routes, there is absolutely nothing a machine can do to stop it.
The "solutions" to SYN floods eliminate the asychronous nature of the attack. Originally, whenever you got a SYN, you would put an entry into a table. When the table filled, you couldn't accept new connections until the old ones timed out. This allowed one to easily shut down a fast machine on a fast connection with a slow machine on a slow connection.
Along come syncookies. When the SYN table fills, connections are still accepted. The only side effect is that some TCP windowing features are no longer available. But if the attacking machines have far greater CPU and bandwidth available to them, and they are able to spoof random IPs and send them from multiple different routes, there is absolutely nothing a machine can do to stop it.
Again, I'm sure there's going to be a lot of discussions and lawsuits over whether that funky looking character you drew is actually an X, or if it's a Y.
Wastes bandwidth sending the replies back, and wastes resources on the host making and sending the replies. Once you've determined a DoS is underway, drop the offending packets and be done with them.
The whole point of a DDOS is that you can't recognize which packets are the offending ones. Sure, at some point a human is going to look at the situation and say, OK, we're going to shut down this machine until the DDOS has subsided, but it would be stupid to shut down a machine automatically whenever you're getting attacked.
Wasting bandwidth is irrelevant if you're going to shut down the machine anyway.
If they say that their entire DS3 was saturated why was it that I could reach ftp.sco.com during the attack?
First of all, they didn't say their entire DS3 was saturated. They said the bandwidth of the attack was enough to saturate a DS3.
Secondly, why not? When you're downloading 100 different files at the same time you can still use the internet, right? Packets will get dropped, but the internet can handle packets getting dropped. See, there's this thing called TCP which is a protocol on top of the IP layer and handles connections when packets are being dropped.
The "each way" would indicate the syns were being replied to (dumb), but they still would have clogged the pipe.
How is it dumb to reply to syns? Would suggest a server just shut itself down whenever someone syn-floods it?
My question is how this is possible without killing the bandwidth other servers on the subnet, namely ftp.sco.com and others?
Maybe the router for the subnet has a bigger connection to the net than to the subnet? So while yes, many packets will be dropped, many will go through, as well. Of course, the web machine itself would be saturated with so many SYN packets, very little useful traffic would be sent in return.
Add in a little intelligence, and maybe the router is bandwidth limiting the packets going to the machine being attacked. Again, that would shut down the single machine, but not the subnet.
Maybe it works in Canada, but here in the good old Sue S of A it would be a farce. Wasn't it bad enough watching the "scrutineers" in Florida arguing over whether the chad was hanging or pregnant or dimpled or swinging? You think it's going to be any different arguing over whether that's an X or a checkmark or a Y? Sure, technology has its errors, but at least its errors tend to be fairly distributed among parties. At least, if the technology is implemented properly.
Slashdot Mirror
Hopefully they'll publish their IP addresses, so we don't have to worry about this situation.
My mouse, on the other hand, makes a very audible *click* each time I use it, and while providing a pleasant tactile feedback, it keeps my girlfriend awake during my late-night work sessions.
You could always do like the prince did: marry her and put the mouse in a museum.
But seriously, are you living in a studio apartment or something? Add this to the long list of reasons that the computer should not be placed in the bedroom (I say this of course lounging on my bed with my laptop, but hey, I'm a bachelor, I'm allowed to do these things).
And attitude like that is precisely what will keep Linux from the desktop.
No, attitude like that is precisely what will keep proprietary crap like Lindows off the desktop.
Some people want it to be easy, people like you will slam something like Lindows that makes it easy.
There's nothing wrong with easy. Hell, I even want it to be easy. But that's why I use Windows. When I want proprietary insecure crap I go straight to the source - Microsoft.
Of course. They even admitted they were wrong.
RTFL and write your congresspeople.
Already have, and already have.
Well, the PIX might work that way (on a global level), but if so, that's a design flaw in the PIX. It's perfectly possible and reasonable for a firewall to count SYNs per second on a per-host basis, and that would avoid losing an entire subnet when a single host is under attack.
However, firewalls with that kind of capacity aren't terribly expensive. (50k packets/s)
50K connections/second was what they were able to handle (and the more I think about it, it seems like it was definately a firewall that was getting hit). Could they have bought a more expensive firewall? Sure. They probably have, by now. But I wouldn't call someone incompetent for not buying such a firewall off the bat.
But, if the firewall was puking about the syn-flood that would also mean that it would be slow to establish connections to the ftp server?
Probably not. If the firewall is built properly it's not going to let an attack on one server affect others.
I believe most vendors use a common connection table for all inside hosts. (Wouldn't be practical for a seperate connection table for every inside ip)
Most firewalls only implement SYN protection when a host is being hit by more than a certain threshold of SYNs per second. See this, for instance.
So until the FTP server started getting attacked, the firewall would pass the SYNs right through.
It seems to me that SCO did have a firewall, and that firewall's SYN protection was limited to 50,000 connections per second. That would explain why the rest of the subnet remained up. And it also explains why the backscatter kept coming after the server was taken down.
It would make sense to buy a firewall capable of handing your link speed
Take a look at this link.
Also, it was interesting to note that the Foundry firewall they tested happened to go up to 50,000 packets per second, which is approximately the same as what SCO was seeing (at least, what the backscatter was implying, and the backscatter would only show SYNs which were being handled). It also says that their hardened servers could only handle 10,000 packets per second, so SCO probably was using a firewall with SYN flood protection.
Could SCO have opted for the Top Layer firewall which could handle 750,000 SYN attack packets per second. Sure, they could have, but it surely would have cost a fortune and been overkill.
My point is that most companies have some sort of firewall protecting their servers. PIX and many many others do protect against SYN attacks.
If the attack is devoting a lot more more processing power and bandwidth to the attack than your firewall, you're not going to be able to stop it.
If they are properly connected, (and the firewall has the processing/memory available to ward off the syn attack. It would make sense to buy a firewall capable of handing your link speed) then the only thing to bring you down is to generate so much data it simply floods your link to the internet.
I'd like to see a firewall that can handle a 50,000 packet per second distributed SYN attack using spoofed addresses, all the while holding enough state information so that only legitimate connections are passed through. Then I'd like you to tell me the price of such a firewall.
By the way, merely saturating your link to the internet wouldn't be enough. The internet can handle dropped packets. You'd have to hit it with many many times the capability of the link. And even then, some percentage of requests would get through, they'd just be slow.
To have the server bogged down by a SYN attack when the link is still operational is fairly poor administration. You are losing service when you don't otherwise have to.
You never have to lose service. The question is how much do you want to spend to protect yourself against such a rare case. Maybe it was poor administration. Maybe it wasn't. The fact that one machine was brought down without the whole subnet going down is a good thing, though. In fact, any decent firewall which is administered correctly is going to make sure that happens.
Shutdown the machine, no, implement a rule to ignore SYN packets after DDOS begins yes.
If you ignore SYN packets, you can't receive incoming connections. You might as well shut down the machine.
They spoof the destination IP and change it to the IP of the target to be attacked and all those webservers (usually ~40,000) respond at once to the host, essentially knocking it offline.
That wouldn't really be a SYN attack, as the response packets would have SYN and ACK set. It would also be much easier to protect against, as these bogus SYN/ACK packets could be dropped. But most importantly, there wouldn't be any backscatter, and certainly not the backscatter that CAIDA was seeing.
So you can use even a secure (but not 100% properly configured) server to launch an attack with...
Improperly configured so as to be able to launch an attack isn't secure. But, I'm really not sure how you could configure a machine not to respond to HTTP requests, anyway. Fortunately, as I mentioned above, this type of attack is much easier to ignore than a true SYN attack.
I guess I quoted too much for your little mind to handle. "(1) IN GENERAL- This Act supersedes any statute, regulation, or rule of a State or political subdivision of a State that expressly regulates the use of electronic mail to send commercial messages, except to the extent that any such statute, regulation, or rule prohibits falsity or deception in any portion of a commercial electronic mail message or information attached thereto."
As I said, "The federal law doesn't supercede state laws regarding fraudulent or deceptive spam."
Overall IMHO the way to deal with this sort of attack is QOS/bandwidth throttling.
Doesn't work if the IP addresses are spoofed.
No, I don't know what you meant. You are implying that there's a way to stop a SYN flood which doesn't saturate your bandwidth, but that's simply not true. Put your 500 Mhz Celeron on a 100 Mbit LAN with 5 Ghz Celerons, and it'll take a whole lot less than 100Mbits to saturate your machine.
So quite obviously the www server was not protected from syn's nor was the link fully eaten up by these packets. Since the ftp server was responsive until it became a target, as well as the fact that these reports mention that the amount of traffic significantly increased when the ftp attack was launched.
OK, so if I hook my computer up to my cablemodem, and turn on syncookies, then the only way you can kill my server with a SYN flood is to kill my entire subnet?
Of course not.
You don't have to saturate a link to saturate a server. And any router not written by a moron isn't going to let traffic going to a single host saturate the entire bandwidth of the subnet.
Dropped SYNs? The whole point of a SYN attack is to try to get you to drop SYNs. Dropping SYNs wouldn't be a very good solution, now would it?
With syncookies.
That's great. Where can I download these magical "syncookies," and how can I hook them up to my email address? Sounds like they'd be useful for stopping spam..
SYN cookies only stop the asynchronous nature of a SYN attack. If the attacking machines have far greater CPU and bandwidth available to them, and they are able to spoof random IPs and send them from multiple different routes, there is absolutely nothing a machine can do to stop it.
The "solutions" to SYN floods eliminate the asychronous nature of the attack. Originally, whenever you got a SYN, you would put an entry into a table. When the table filled, you couldn't accept new connections until the old ones timed out. This allowed one to easily shut down a fast machine on a fast connection with a slow machine on a slow connection.
Along come syncookies. When the SYN table fills, connections are still accepted. The only side effect is that some TCP windowing features are no longer available. But if the attacking machines have far greater CPU and bandwidth available to them, and they are able to spoof random IPs and send them from multiple different routes, there is absolutely nothing a machine can do to stop it.
Why on earth did SCO respond to 700 million syn packets?
That's what computers are supposed to do when they receive a syn packet, respond.
and the bandwith usage would be half.
Which is kind of useless on the vast majority of layer 1 equipment, which have separate lines for sending and receiving data.
If it's not an X it's a spoiled ballot. Period.
Again, I'm sure there's going to be a lot of discussions and lawsuits over whether that funky looking character you drew is actually an X, or if it's a Y.
Wastes bandwidth sending the replies back, and wastes resources on the host making and sending the replies. Once you've determined a DoS is underway, drop the offending packets and be done with them.
The whole point of a DDOS is that you can't recognize which packets are the offending ones. Sure, at some point a human is going to look at the situation and say, OK, we're going to shut down this machine until the DDOS has subsided, but it would be stupid to shut down a machine automatically whenever you're getting attacked.
Wasting bandwidth is irrelevant if you're going to shut down the machine anyway.
If they say that their entire DS3 was saturated why was it that I could reach ftp.sco.com during the attack?
First of all, they didn't say their entire DS3 was saturated. They said the bandwidth of the attack was enough to saturate a DS3.
Secondly, why not? When you're downloading 100 different files at the same time you can still use the internet, right? Packets will get dropped, but the internet can handle packets getting dropped. See, there's this thing called TCP which is a protocol on top of the IP layer and handles connections when packets are being dropped.
The "each way" would indicate the syns were being replied to (dumb), but they still would have clogged the pipe.
How is it dumb to reply to syns? Would suggest a server just shut itself down whenever someone syn-floods it?
My question is how this is possible without killing the bandwidth other servers on the subnet, namely ftp.sco.com and others?
Maybe the router for the subnet has a bigger connection to the net than to the subnet? So while yes, many packets will be dropped, many will go through, as well. Of course, the web machine itself would be saturated with so many SYN packets, very little useful traffic would be sent in return.
Add in a little intelligence, and maybe the router is bandwidth limiting the packets going to the machine being attacked. Again, that would shut down the single machine, but not the subnet.
Maybe it works in Canada, but here in the good old Sue S of A it would be a farce. Wasn't it bad enough watching the "scrutineers" in Florida arguing over whether the chad was hanging or pregnant or dimpled or swinging? You think it's going to be any different arguing over whether that's an X or a checkmark or a Y? Sure, technology has its errors, but at least its errors tend to be fairly distributed among parties. At least, if the technology is implemented properly.