Maybe it might have been a good idea to wait on posting this until a bit more info came in? Or is this part of the show? I'm preheating the microwave now to prep some popcorn.
Not so much a hoax, I think it's a few AT&T employees trying to curb a DDoS using their best judgement with whatever means they have available. But in a half-assed sort of way that backfires if it pisses people off.
Well that makes no sense. AT&T should be taking no action unless somebody from 4chan calls them up and asks them to block the perceived source of the DDoS.. if that's what's happening. The whole thing sounds goofy. Maybe somebody at Slashdot is looking for a scoop which might backfire against him if it turns out to be fake. Credibility is a fickle mistress...or something like that...
Well that makes no sense. AT&T should be taking no action unless somebody from 4chan calls them up and asks them to block the perceived source of the DDoS..
Sounds like you don't understand what's going on - please educate yourself.
4chan is being SYN flooded, various ISPs were getting a lot of collateral traffic from the resulting ACKs going back to spoofed IPs. Since those ISPs had nothing to do with either the attacker or 4chan, there was nothing they could do but pull the plug on the source of the collateral ACKs (4chan). i.e. the ISPs who blocked 4chan weren't trying to protect 4chan from an attack, they were protecting their own networks from the fallout
there was nothing they could do but pull the plug on the source of the collateral ACKs
You were doing so great until this bit. Or I hadn't realised that one of the biggest ISPs in the USA lacked the capability to do something as simple [derkeiler.com] as filtering out unwanted ACKs.
You were certainly right about there being a knee-jerk reaction, pity it appears to be yours.
You were doing so great until this bit. Or I hadn't realised that one of the biggest ISPs in the USA lacked the capability to do something as simple [derkeiler.com] as filtering out unwanted ACKs.
That discussion appears to address 2 separate problems, both in infeasible ways:
1. Rejecting unsolicited ACKs - "SYN+ACK -> (check if your network requested it) -> (if yes) -> then -> ALLOW -> else (REJECT)": It doesn't really expand on a method of doing this, but usually you would use connection tracking, whereby you remember the state of all connections running through the router. This is a pretty resource intensive setup and is nigh on unworkable in networks with asymmetric or non-determin
It doesn't really expand on a method of doing this, but usually you would use connection tracking, whereby you remember the state of all connections running through the router. This is a pretty resource intensive setup and is nigh on unworkable in networks with asymmetric or non-deterministic routing. I.e. it isn't something that I would expect an ISP as big as AT&T to be able to implement, especially at the drop of a hat. Sure, it's easy enough to do on your home network, but it just ain't going to work at the ISP level without some *serious* effort.
It doesn't expand because there is nothing to expand on unless you're filtering all packets rather than only those that have been identified as potentially spurious traffic. Yes, you block potentially legitimate SYN+ACK packets but considering this is a web host we're talking about.. when is the server going to be initiating connections? The point is, it is still blocking all the unwanted traffic through that link while still allowing people to access the site. Issues about asymmetric routing are more appli
It doesn't expand because there is nothing to expand on unless you're filtering all packets rather than only those that have been identified as potentially spurious traffic.
Huh? Presumably by "potentially spurious traffic" you mean any SYN+ACK packets coming from the server that is being attacked? How are you going to identify which of those are legit and which aren't? You _do_ need to expand on this because frankly it is not clear how you would do this, given the problems I have already explained.
Yes, you block potentially legitimate SYN+ACK packets but considering this is a web host we're talking about.. when is the server going to be initiating connections?
The server is unlikely to be initiating connections. However, that is irrelevant since blocking SYN+ACK packets that the server sent would stop it *accepting* connections, not ma
Huh? Presumably by "potentially spurious traffic" you mean any SYN+ACK packets coming from the server that is being attacked? How are you going to identify which of those are legit and which aren't? You _do_ need to expand on this because frankly it is not clear how you would do this, given the problems I have already explained.
I would suggest you read about Stateful Packet Inspection [wikipedia.org], I am quite at a loss to know why you are not already aware that it is a standard feature in firewalls these days. As for how do you recognise which packets to apply a rule to, you could start by the method you used to identify packets to block.. eg the host and destination. Depending on the attack pattern you could narrow the scope from there.
The server is unlikely to be initiating connections. However, that is irrelevant since blocking SYN+ACK packets that the server sent would stop it *accepting* connections, not making them (and is exactly what the ISPs have been doing which you are complaining about!)
Admittedly I got SYN+ACK the wrong way round but the point stands that they should be using some sort of con
I would suggest you read about Stateful Packet Inspection [wikipedia.org], I am quite at a loss to know why you are not already aware that it is a standard feature in firewalls these days.
I am aware - I already mentioned it (aka connection tracking). I also already pointed out why it is completely infeasible to do this. Please go back and read the previous posts in the thread.
Admittedly I got SYN+ACK the wrong way round but the point stands that they should be using some sort of connection tracking to make it irrelevant.
Again, please go back and read the previous posts in the thread - I already explicitly explained to you why connection tracking is not feasible. You are proposing solutions and ignoring all the reasons why they are unworkable, even when clearly explained to you.
The method to identify these could even be the same they used for blocking the SYN+ACK packets (IE, manually).
Manually? are you crazy? Unwired said they were gettin
"Security is mostly a superstition. It does not exist in nature... Life is
either a daring adventure or nothing."
-- Helen Keller
"Could this all be a hoax...?" (Score:1)
Maybe it might have been a good idea to wait on posting this until a bit more info came in? Or is this part of the show? I'm preheating the microwave now to prep some popcorn.
Re: (Score:0)
Not so much a hoax, I think it's a few AT&T employees trying to curb a DDoS using their best judgement with whatever means they have available. But in a half-assed sort of way that backfires if it pisses people off.
Re: (Score:1)
Well that makes no sense. AT&T should be taking no action unless somebody from 4chan calls them up and asks them to block the perceived source of the DDoS.. if that's what's happening. The whole thing sounds goofy. Maybe somebody at Slashdot is looking for a scoop which might backfire against him if it turns out to be fake. Credibility is a fickle mistress...or something like that...
Re: (Score:5, Insightful)
Well that makes no sense. AT&T should be taking no action unless somebody from 4chan calls them up and asks them to block the perceived source of the DDoS..
Sounds like you don't understand what's going on - please educate yourself.
4chan is being SYN flooded, various ISPs were getting a lot of collateral traffic from the resulting ACKs going back to spoofed IPs. Since those ISPs had nothing to do with either the attacker or 4chan, there was nothing they could do but pull the plug on the source of the collateral ACKs (4chan). i.e. the ISPs who blocked 4chan weren't trying to protect 4chan from an attack, they were protecting their own networks from the fallout
Re:"Could this all be a hoax...?" (Score:2)
there was nothing they could do but pull the plug on the source of the collateral ACKs
You were doing so great until this bit. Or I hadn't realised that one of the biggest ISPs in the USA lacked the capability to do something as simple [derkeiler.com] as filtering out unwanted ACKs.
You were certainly right about there being a knee-jerk reaction, pity it appears to be yours.
Re: (Score:3, Insightful)
You were doing so great until this bit. Or I hadn't realised that one of the biggest ISPs in the USA lacked the capability to do something as simple [derkeiler.com] as filtering out unwanted ACKs.
That discussion appears to address 2 separate problems, both in infeasible ways:
1. Rejecting unsolicited ACKs - "SYN+ACK -> (check if your network requested it) -> (if yes) -> then -> ALLOW -> else (REJECT)":
It doesn't really expand on a method of doing this, but usually you would use connection tracking, whereby you remember the state of all connections running through the router. This is a pretty resource intensive setup and is nigh on unworkable in networks with asymmetric or non-determin
Re: (Score:2)
It doesn't really expand on a method of doing this, but usually you would use connection tracking, whereby you remember the state of all connections running through the router. This is a pretty resource intensive setup and is nigh on unworkable in networks with asymmetric or non-deterministic routing. I.e. it isn't something that I would expect an ISP as big as AT&T to be able to implement, especially at the drop of a hat. Sure, it's easy enough to do on your home network, but it just ain't going to work at the ISP level without some *serious* effort.
It doesn't expand because there is nothing to expand on unless you're filtering all packets rather than only those that have been identified as potentially spurious traffic. Yes, you block potentially legitimate SYN+ACK packets but considering this is a web host we're talking about.. when is the server going to be initiating connections? The point is, it is still blocking all the unwanted traffic through that link while still allowing people to access the site. Issues about asymmetric routing are more appli
Re: (Score:2)
It doesn't expand because there is nothing to expand on unless you're filtering all packets rather than only those that have been identified as potentially spurious traffic.
Huh? Presumably by "potentially spurious traffic" you mean any SYN+ACK packets coming from the server that is being attacked? How are you going to identify which of those are legit and which aren't? You _do_ need to expand on this because frankly it is not clear how you would do this, given the problems I have already explained.
Yes, you block potentially legitimate SYN+ACK packets but considering this is a web host we're talking about.. when is the server going to be initiating connections?
The server is unlikely to be initiating connections. However, that is irrelevant since blocking SYN+ACK packets that the server sent would stop it *accepting* connections, not ma
Re: (Score:2)
Huh? Presumably by "potentially spurious traffic" you mean any SYN+ACK packets coming from the server that is being attacked? How are you going to identify which of those are legit and which aren't? You _do_ need to expand on this because frankly it is not clear how you would do this, given the problems I have already explained.
I would suggest you read about Stateful Packet Inspection [wikipedia.org], I am quite at a loss to know why you are not already aware that it is a standard feature in firewalls these days. As for how do you recognise which packets to apply a rule to, you could start by the method you used to identify packets to block.. eg the host and destination. Depending on the attack pattern you could narrow the scope from there.
The server is unlikely to be initiating connections. However, that is irrelevant since blocking SYN+ACK packets that the server sent would stop it *accepting* connections, not making them (and is exactly what the ISPs have been doing which you are complaining about!)
Admittedly I got SYN+ACK the wrong way round but the point stands that they should be using some sort of con
Re: (Score:2)
I would suggest you read about Stateful Packet Inspection [wikipedia.org], I am quite at a loss to know why you are not already aware that it is a standard feature in firewalls these days.
I am aware - I already mentioned it (aka connection tracking). I also already pointed out why it is completely infeasible to do this. Please go back and read the previous posts in the thread.
Admittedly I got SYN+ACK the wrong way round but the point stands that they should be using some sort of connection tracking to make it irrelevant.
Again, please go back and read the previous posts in the thread - I already explicitly explained to you why connection tracking is not feasible. You are proposing solutions and ignoring all the reasons why they are unworkable, even when clearly explained to you.
The method to identify these could even be the same they used for blocking the SYN+ACK packets (IE, manually).
Manually? are you crazy? Unwired said they were gettin