Handling Reflective Ddos andTCP fractional window increment?

Networking/Security Forums -> Networking

Author: manoj9372 PostPosted: Sun Sep 19, 2010 7:07 pm    Post subject: Handling Reflective Ddos andTCP fractional window increment?
    ----
I am having some doubts regarding Reflective Ddos and TCP fractional window increment technique

first here is my doubts regarding Reflective Ddos

100% of us knows Ddos ,but have u ever faced Reflective Ddos attacks?

'I heared the attacker used some compromised servers(aka zombies) and constantly send's a large number of garbage packets with spoofed ip's and attacks a target,and also in return the target web-server also attacks(!?) via responding to the spoofed ip's,In this case what can we do to stop this attack?

even if the firewall admins started to block ip's,it leads to serious disaster right?

because if suppose the attacker uses the spoofed ip's starting from 1.1.1.1-254.254.254.254 means ,will it take take down the target server even tough it is having firewall protection?

Also if they started to ban ip's,they have to ban the entire internet right ?!!

Also i want to know,does any body here faced such massive reflective Ddos attacks?

Also indirectly the target web-server also attacking via responding to the spoofed ip's

Also how can we secure our-self against such massive sophisticated Ddos?


Now here are my questions about TCP fractional window increment?

I am studying about some mechanisms to reduce the congestion and improve the speed in ad hoc networks

In this i have seen a concept named "TCP fractional window increment" which is used for reducing congestion and improving the speed of the data transfer,

But when ever i tried to study about this mechanism,i ended up with getting some freaky math calculation's,which is realy freaking me,I want to understand the basics about this mechanism,if any body got a good link for understanding this mechanism please link me (Please no freaky math calculation's)

Also if you already know about this mechanism please explain here in simple words or link me some good articles for understanding the "TCP fractional window increment" mechanism


Hope i will get some help .......

Author: WeaverLocation: WI, USA PostPosted: Wed Sep 22, 2010 9:41 am    Post subject:
    ----
Denial of service attacks come in different flavors. Some are easier to stop than others.

Application layer denial of service attacks (not distributed) that are not "saturating your pipes" can generally be stopped with rules on your own edge firewall.

Application layer distributed denial of service attacks can also be stopped with rules on your own firewall if your pipe is large enough to handle the distributed attack.

Distributed denial of service attacks (exploiting application layer (L7), TCP (L4), or IP/ICMP (L3)) that are too large for your pipes cannot be addressed on your edge firewall or edge router. They will require you to work with your upstream provider[s] (good luck if you are just a little guy) to ACL drop the traffic based on L7, L4, or L3 semantics.

Reflective distributed denial of service attacks will also require your upstream provider to ACL drop traffic, however defining that traffic to drop is where the problem sits. As you have noted, the source traffic from the zombie to the reflector is spoofed with the source IP being that of the victim. In this regard the victim is seeing the legitimate source IP of the reflected traffic. However, ACL dropping traffic from a seemingly endless number of IP's is a chore and dangerous.

A method I thought of (may be implemented by some providers) to combat Reflective DDoS is to enable stateful packet inspection (SPI) and firewalling *at* the upstream provider. Note that this is slightly different than simple ACL drops as concepts like TCP state and ICMP tracking are all part of SPI.

The reflective DDoS techniques that I am aware of generally exploit the rules and semantics of TCP and ICMP.

Your own edge firewall will drop the reflected TCP/ICMP traffic (assuming your edge firewall is performing SPI). The problem is that the reflected traffic has already saturated your pipe by the time it gets to your firewall.

By moving (adding to be exact) SPI (not NAT, PAT, or any mangling) to the upstream provider it is possible to take advantage of SPI and drop the traffic before it gets to your pipe.

The problem here is of course upstream provider willingness and capability.

-Weaver

Author: Sgt_BLocation: Chicago, IL US PostPosted: Wed Sep 22, 2010 2:18 pm    Post subject:
    ----
Adding SPI to the upstream provider sounds like a good idea, and in theory it is. However, the cost in terms of processing and memory to track all those connections would be substantial. Not impossible, but it would require providers to increase hardware capabilities for the sole purpose of security. That costs lotsa money and they ain't gonna do it any time soon. Wink

Providers generally "defend against DDoS" through a technique called Black Hole filtering. The victim calls their provider and tells them they're under attack along with the target IP. The provider then flags that /32 address as no-export in BGP or adds a static route to nowhere for that /32 address. This way, all traffic destined to that host gets dropped as there is no route to it.

Obviously this blasts the good traffic too, so the victim has to change their IP address and adjust DNS to recover from the attack. Recovery can have mixed results though so...nothings perfect. Wink

Author: WeaverLocation: WI, USA PostPosted: Wed Sep 22, 2010 11:13 pm    Post subject:
    ----
Sgt_B wrote:
Adding SPI to the upstream provider sounds like a good idea, and in theory it is. However, the cost in terms of processing and memory to track all those connections would be substantial. Not impossible, but it would require providers to increase hardware capabilities for the sole purpose of security. That costs lotsa money and they ain't gonna do it any time soon. Wink


Agreed, maintaining state tables at the provider is costly (for all the reasons mentioned) -- if the provider is maintaining state for all traffic traversing their systems.

However, I propose upstream provider SPI as a tool to be used to deal with these situations, not the status quo. It is to be enabled on an as needed basis for only the relevant portions of the victim's netblock. This would not require chunks of the victim's netblock to be black hole routed or "no-export'd" back to eBGP peers. (Would "no-export" on a /32 even be accepted or would it itself be filtered?)

I have never heard of a big upstream player offering SPI capability (but that surely doesn't mean it is not possible). SPI in this regard should be viewed as a tool; a tool that has been thoroughly tested over the years.

-Weaver

Author: Sgt_BLocation: Chicago, IL US PostPosted: Thu Sep 23, 2010 1:32 am    Post subject:
    ----
Weaver wrote:
Would "no-export" on a /32 even be accepted or would it itself be filtered?

Well black hole routing is internal to the provider, so the no-export is used so that blackholed prefixes aren't exported outside of the provider's network.

I get what you're saying now with regards to using SPI when experiencing an attack, but I think the problem has already been handled by unicast Reverse Path Forwarding (uRPF).

Essentially, when enabled, the router will validate whether source traffic entered on the same interface that egress traffic would leave the router. This allows it to determine with a decent degree of accuracy whether the IP was spoofed. This allows the router to check traffic based on its routing table and not a stored state table (i.e., its faster and cheaper). This reduces the impact of the DDoS while allowing legitimate traffic.

I could blab a bit, but someone smarter than me on the subject already wrote some good articles on the subject of blackholing and uRPF. They're a great read for anyone interested in the subject.

Its a 4-part series, the uRPF stuff is in part 4.
http://pierky.wordpress.com/2009/05/31/gns3-lab-remote-triggered-black-holing/

Author: capiLocation: Portugal PostPosted: Thu Sep 23, 2010 6:50 am    Post subject:
    ----
Sgt_B wrote:
Essentially, when enabled, the router will validate whether source traffic entered on the same interface that egress traffic would leave the router. This allows it to determine with a decent degree of accuracy whether the IP was spoofed. This allows the router to check traffic based on its routing table and not a stored state table (i.e., its faster and cheaper). This reduces the impact of the DDoS while allowing legitimate traffic.

This sounds like RFC3704: Ingress Filtering for Multihomed Networks (Linux's rp_filter sysctl); am I right?

The thing is, while that does of course protect from spoofed IPs from your local peers, the problem in my opinion is that you will still have many cases in which you can't tell between spoofed IPs and the legitimate ones -- because you're either not peered at a high enough level, or not peered at a low enough level, or you're just not peered with enough people.

If you're a Tier 3 ISP, you're too low in the food chain. As far as you know, the Internet is that stretch of fiber coming from the Tier 2; at best a couple of them. The customer can complain all he wants, but you just can't tell the difference between packets coming from Beijing using IPs that belong to Singapore... or IPs that belong to the US, for that matter. Your egress route is the same for all of them. If you're multi-homed you'll have a higher granularity, but it's still going to be dividing the world in 2 or 3 parts, with a lot of it overlapping.

If you're a Tier 1, you're too high up. You're going to have a hard time differentiating between all the smaller regional guys twice removed from you.

Of course, if you're somewhere in the middle, you might just be in a very good position to filter... Even more so if you happen to be an IXP Wink


Sgt_B wrote:
Its a 4-part series, the uRPF stuff is in part 4.
http://pierky.wordpress.com/2009/05/31/gns3-lab-remote-triggered-black-holing/

That seems like a very interesting read... Thank you!

Author: Sgt_BLocation: Chicago, IL US PostPosted: Thu Sep 23, 2010 3:41 pm    Post subject:
    ----
Hey capi,

Yeah this thing was a combination of RFCs 3704 and 3882. Its got its own draft now too, RTBH w/ uRPF
As you've illustrated, this solution has some weaknesses in it depending on who implements this (and implements it correctly) along with where they are on the Internet. Labs and theory prove this works wonders, but the reality is very different as illustrated in the recent attacks on the MPAA and RIAA.

There are probably better ideas out there to prevent this, maybe global implementation of some type of ingress filtering based on 3704, or maybe its tactical deployment of SPI. For better or worse though, like black hole filtering is "good enough" for the big providers out there.

Author: capiLocation: Portugal PostPosted: Thu Sep 23, 2010 5:04 pm    Post subject:
    ----
Oh, I wasn't saying I had a better idea, or even that this one was bad. I was just trying to see if I had missed something, because it seemed to me that it might be rather difficult to implement effectively in practice.

I'll be sure to read that draft! I'm not familiar with RFC 3882, or much in the way of real-world BGP for that matter. Time to get with the reading, thanks for the info! Smile

Author: alt.don PostPosted: Fri Sep 24, 2010 12:28 am    Post subject:
    ----
This has been an interesting topic to follow. I believe it is not just a matter of having the ISP's properly filter traffic on their routers (having SPI at a provider level is unrealistic) but also in having the corporate network properly configure their edge router. By this I mean don't allow BOGON ranges in, properly configure your egress traffic and so on. A DoS and especially a DDoS is a difficult beast to deal with in real time. You need this to be a coordinated response at the provider level. There has been some progress on this front, but there is still huge room for improvement.

Author: Sgt_BLocation: Chicago, IL US PostPosted: Mon Sep 27, 2010 5:07 pm    Post subject:
    ----
In this day and age, I think it the responsibility of the provider to black hole bogons. There's no reason not too. The added overhead would be minimal, and implementation is trivial. Team Cymru even has a route server advertising bogons so it super easy to black hole those prefixes.

But providers traditionally do bare minimum so what I think on the subject doesn't mean too much. Wink



Networking/Security Forums -> Networking


output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Page 1 of 1

Powered by phpBB 2.0.x © 2001 phpBB Group