|
Moderator note: The instructions in this thread will do nothing to protect you from a DDoS attack. The only way to prevent an attack is to avoid your IP address becoming public. |
On September 04 2012 05:41 LunaSea wrote:Show nested quote +On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for.
|
On September 04 2012 05:46 Pumplekin wrote:Sadly, while you are using technical words, I don't think you really know exactly what they mean. I'd suggest stopping digging a bigger hole for yourself and be thankful TL is a relatively nice and friendly place
1) - Look at the code. 2) - Come back latter
When your best advice is : "be nice to your ISP", I don't think you can consider yourself qualified. Nice contribution btw.
|
On September 04 2012 05:47 pmp10 wrote:Show nested quote +On September 04 2012 05:41 LunaSea wrote:On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for.
The TCP window is a buffer. Nice try mister professional.
And your router definetly gets A LOT of packets in a DDoS situation.
|
On September 04 2012 05:51 LunaSea wrote:Show nested quote +On September 04 2012 05:46 Pumplekin wrote:Sadly, while you are using technical words, I don't think you really know exactly what they mean. I'd suggest stopping digging a bigger hole for yourself and be thankful TL is a relatively nice and friendly place 1) - Look at the code. 2) - Come back latter When your best advice is : "be nice to your ISP", I don't think you can consider yourself qualified. Nice contribution btw.
I've seen this before in so many threads. People post long OP's about an issue and how to solve it yet when they're shot down by people with more knowledge they get very defensive.
I'm sorry but this isn't a solution to the problem, dude.
On September 04 2012 05:51 LunaSea wrote:Show nested quote +On September 04 2012 05:47 pmp10 wrote:On September 04 2012 05:41 LunaSea wrote:On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for. The TCP window is a buffer. Nice try mister professional. And your router definetly gets A LOT of packets in a DDoS situation.
He's talking about the transmit buffers on network equipment, not TCP bufffers. Your TCP window won't even get much of anything as equipment ISP side will drop packets before they even reach the router.
|
I don't really get the point of this solution, any normal "home" router will block wan requests by default. All you do is setup a whitelist so all other requests are discarded. ...correct?
You say normally the router will inspect the complete packet and test against any protocol but there is no point in that. (and no router does that <.<) Unless you started the session the firewall should just bock the packet, so you won't need to do more than to check the session table. tl;dr spi?
|
Not really sure how this helps the actual problem...
|
On September 04 2012 05:56 Nightwatch wrote: I don't really get the point of this solution, any normal "home" router will block wan requests by default. All you do is setup a whitelist so all other requests are discarded. ...correct?
You say normally the router will inspect the complete packet and test against any protocol but there is no point in that. (and no router does that <.<) Unless you started the session the firewall should just bock the packet, so you won't need to do more than to check the session table. tl;dr; spi?
Yup, it won't be in the NAT table, so it will go in the bin by default. ACL'ing it MAY save a tiny bit of CPU (it might not, it depends on how the CPE is designed).
If you are talking IPv6, or a non-NAT'ing connection, things would be different, but I think we can safely assume almost everyone is using IPv4 and NAT on the CPE (and mostly I have been in this thread).
I'm also starting to suspect this may be a massive troll thread. At least I'm hoping it is
|
On September 04 2012 05:56 Nightwatch wrote: I don't really get the point of this solution, any normal "home" router will block wan requests by default. All you do is setup a whitelist so all other requests are discarded. ...correct?
You say normally the router will inspect the complete packet and test against any protocol but there is no point in that. (and no router does that <.<) Unless you started the session the firewall should just bock the packet, so you won't need to do more than to check the session table. tl;dr; spi?
Yes, but how does the firewall know if this packet isn't starting a session ? The router has to look at the packet and see if this is a valid packet that is actually starting a session in one of the supported protocols.
|
On September 04 2012 05:51 LunaSea wrote:Show nested quote +On September 04 2012 05:47 pmp10 wrote:On September 04 2012 05:41 LunaSea wrote:On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for. The TCP window is a buffer. Nice try mister professional. Pretty sure it isn't. Last I recall buffer was a kind of a memory while a window a part of TCP packet but maybe things have changed.
|
On September 04 2012 06:01 LunaSea wrote:Show nested quote +On September 04 2012 05:56 Nightwatch wrote: I don't really get the point of this solution, any normal "home" router will block wan requests by default. All you do is setup a whitelist so all other requests are discarded. ...correct?
You say normally the router will inspect the complete packet and test against any protocol but there is no point in that. (and no router does that <.<) Unless you started the session the firewall should just bock the packet, so you won't need to do more than to check the session table. tl;dr; spi? Yes, but how does the firewall know if this packet isn't starting a session ? The router has to look at the packet and see if this is a valid packet that is actually starting a session in one of the supported protocols.
Simple, you don't start a new session from outside of the network.
|
By default (without any port forwarding, DMZ setup, or UPNP or anything like that), a typical home CPE will not allow anything to setup an inbound connection. It will simply look at the NAT table, check if an entry matches, if it does it will NAT and forward it, if it doesn't, it will discard it. Port Forwarding, DMZ's + UPNP basically are just other methods of setting up NAT rules.
Still, your ISP's access kit has a full TX buffer, and you still haven't fixed that.
|
On September 04 2012 06:06 pmp10 wrote:+ Show Spoiler +On September 04 2012 05:51 LunaSea wrote:Show nested quote +On September 04 2012 05:47 pmp10 wrote:On September 04 2012 05:41 LunaSea wrote:On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for. The TCP window is a buffer. Nice try mister professional. Pretty sure it isn't. Last I recall buffer was a kind of a memory while a window a part of TCP packet but maybe things have changed.
The simplest way of considering the window size is that it indicates the size of the device's receive buffer for the particular connection.
-- http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm
plz ...
|
I think the arguments may be easily settled if somebody would run a test.
|
I will admit I only skimmed this thread (since it seems like if somebody solved DDoS attacks they would be getting a lot more traction than a random thread on TL), but from what I gather the OP is assuming that an ISP will send an infinite amount of data to your router and filtering out bad IP addresses at your router level will solve the problem since then you only accept "x" amount of data?
|
On September 04 2012 06:13 trGKakarot wrote: I will admit I only skimmed this thread (since it seems like if somebody solved DDoS attacks they would be getting a lot more traction than a random thread on TL), but from what I gather the OP is assuming that an ISP will send an infinite amount of data to your router and filtering out bad IP addresses at your router level will solve the problem since then you only accept "x" amount of data?
Yes, except it's not your ISP sending the data originally, but a bunch of hacked computers rented by a random kid.
|
Sorry to say it this staight, but what the OP says is definitely wrong to a large degree. There's no way you can defend against DDoS by filtering packets on your router. The network bandwidth will still be blocked no matter if you filter or not, it makes almost no difference. The only thing that saves you is hiding your IP address.
|
TCP windowing is part of how TCP does flow control. You can find plenty of good guides to it on the internet, and this is reasonable starting point (http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/).
There is quite a lot to know about TCP really, I'm far from an expert in the real ins and outs of it, it is a surprisingly deep topic for something that mostly "just works" (although I'm more than happy to answer any questions up to my knowledge level).
|
On September 04 2012 06:15 LunaSea wrote:Show nested quote +On September 04 2012 06:13 trGKakarot wrote: I will admit I only skimmed this thread (since it seems like if somebody solved DDoS attacks they would be getting a lot more traction than a random thread on TL), but from what I gather the OP is assuming that an ISP will send an infinite amount of data to your router and filtering out bad IP addresses at your router level will solve the problem since then you only accept "x" amount of data? Yes, except it's not your ISP sending the data originally, but a bunch of hacked computers rented by a random kid.
Right, but you are only connected to the outside world through your ISP (unless they are somehow on your intranet, which means you have a bigger problem).
Maybe I am missing something...
|
On September 04 2012 06:17 trGKakarot wrote:Show nested quote +On September 04 2012 06:15 LunaSea wrote:On September 04 2012 06:13 trGKakarot wrote: I will admit I only skimmed this thread (since it seems like if somebody solved DDoS attacks they would be getting a lot more traction than a random thread on TL), but from what I gather the OP is assuming that an ISP will send an infinite amount of data to your router and filtering out bad IP addresses at your router level will solve the problem since then you only accept "x" amount of data? Yes, except it's not your ISP sending the data originally, but a bunch of hacked computers rented by a random kid. Right, but you are only connected to the outside world through your ISP (unless they are somehow on your intranet, which means you have a bigger problem). Maybe I am missing something...
Yes but what I meant is this :
A --> sends a packet to B --> who forwards it to C
Where :
A is the attacker, B your ISP, and C is you.
A is the one the packets originate from and B only forwards it to the destination indicated in the packet.
|
On September 04 2012 06:10 LunaSea wrote:Show nested quote +On September 04 2012 06:06 pmp10 wrote:+ Show Spoiler +On September 04 2012 05:51 LunaSea wrote:Show nested quote +On September 04 2012 05:47 pmp10 wrote:On September 04 2012 05:41 LunaSea wrote:On September 04 2012 05:38 pmp10 wrote: Wait - so all you did was make a switch to a white-list ACL to save CPU cycles of a router? That's essentially worthless - router CPUs are not overburdened during an DDoS attack. The network resources are. Yes that's why you have a white-list, so that your tcp window won't be full of corrupted packets. Your tcp connection (window?) will receive only what gets through the ISP/buffers ect. So essentially not much - certainly very little of what you are hoping for. The TCP window is a buffer. Nice try mister professional. Pretty sure it isn't. Last I recall buffer was a kind of a memory while a window a part of TCP packet but maybe things have changed. Show nested quote +The simplest way of considering the window size is that it indicates the size of the device's receive buffer for the particular connection. -- http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htmplz ... Please look up those terms somewhere more reputable, Gross oversimplification and completely mismatched definitions won't help your education. Buffer is about as much a TCP window as operating system is a RAM. TCP window can set buffer size but they are completely different things.
|
|
|
|