Misconceptions about DOS & DDOS

Quote:

---

Originally posted here by instronics
Syn-Flood-Protections: iptables -A FORWARD -p tcp --syn -m limit 1/s -j ACCEPT

---

Limiting all syns will kill low-latency connections on any application that needs multiple connections at a time (like say, web surfing).

Quote:

---

and protection against 'ping-of-death':
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit 1/s -j ACCEPT

---

Which won't do jack against a "ping of death" since it's a raw packet flood style DoS. It doesn't care if it gets a response, it will still clog your incoming pipe.

Quote:

---

Yes, offcourse there are many other types. I just gave 2 examples here, but there are also defense mechanisms for many various other types of DoS, which cannot all be controlled by the end target. I just wanted to point out that a firewall is NOT useless against DoS. It is still a very important tool in security.

---

Firewalls are useless against packet floods. Packet floods are one type of Denial of Service attack. Firewalls *CAN* mitigate the effects of SYN floods and similar attacks that rely on protocol or resource issues.

The biggest thing that can be done to stifle DDoS attacks is if all ISPs were required to implement egress filtering. In that case, it could be narrowed down to the ISP block and filtered off. Unfortunately nobody thought of this ten years ago when the Internet (in its current form anyway) began its rise to popularity, so it was never done, and getting everyone on board to do so now would be a rather monumental task.

There is one and only one sensible solution for syn floods - syn cookies. All operating systems of any usefuless support them, so just turn them on if you suspect syn flooding (or even if you don't, the cost is minimal).

Rate-limiting incoming SYNs is a VERY bad idea, as it will lag your web servers significantly. In fact, it could also make a synflood DoS worse, because the SYNs which are permitted are more likely to be the DoS ones than legit ones.

Just use syn cookies - they are a 100% effective solution to SYN floods (and useless against any other type of DoS of course).

Slarty

Quote:

---

Limiting all syns will kill low-latency connections on any application that needs multiple connections at a time (like say, web surfing).

---

It depends on the rules you set. If as an action, in response to the syn flood, you just start dropping the source IP(s), it is helpful. An example:

Quote:

---

connections over the Internet are initiated via a procedure called the three-part handshake. In this process, the requesting machine sends a packet requesting connection. The target machine responds with an acknowledgment. The requesting machine then returns its own acknowledgment and a connection is established.

In a syn_flooder attack, the requesting (cracker's) machine sends a series of connection requests but fails to acknowledge the target's response. Because the target never receives that acknowledgment, it waits. If this process is repeated many times, it renders the target's ports useless because the target is still waiting for the response. These connection requests are dealt with sequentially; eventually, the target will abandon waiting for each such acknowledgment. Nevertheless, if it receives tens or even hundreds of these requests, the port will remain engaged until it has processed--and discarded--each request.
NOTE: The term syn_flooder is derived from the activity undertaken by such tools. The TCP/IP three-way handshake is initiated when one machine sends another a SYN packet. In a typical flooding attack, a series of these packets are forwarded to a target, purporting to be from an address that is nonexistent. The target machine therefore cannot resolve the host. In any event, by sending a flurry of these SYN packets, one is flooding the target with requests that cannot be fulfilled.

---

Taken from : The book 'Maximum Security', Chapter 4, in the case of Panix.com

This sort of attack can be countermeasured at the firewall level. That way it doesnt affect the service (The listening server). You can add a timer to it, to say just drop everything for 2 mins or so. There are many things you can play with here. Offcourse there is the issue of 'clogging' up bandwidth etc.. which will result in worse downtime, but then again, many flood attacks are different. The example i used in the iptables rule was orientated towards protecting the service, not the pipe.

Quote:

---

Firewalls are useless against packet floods.

---

Well, not 100% useless :D

Quote:

---

Which won't do jack against a "ping of death" since it's a raw packet flood style DoS. It doesn't care if it gets a response, it will still clog your incoming pipe.

---

Hmm, here again it depends. (I think so atleast). The only comment to this that i have (please do correct me if im wrong), i remember a very long time ago, i saw a 'ping of death' tool, which was orientated at a destination port. Again here, apart from the 'clogging', i run it as a test succesfully using a simple dialup connection against an ISDN connection. I could not have 'clogged' the target, since my pipe was way too weak, but it still crashed the target box (yeah yeah, it was a win 98, so you could say that nowadays its pretty useless), but then again, the firewall 'could', if the limit is set to 1 packet per second, and the firewall by default allows the target port to be accessed using ICMP (dont ask me why someone would allow it, some just do), then the firewall could just start dropping, which is sort of effective.

Again, please do correct me where if im wrong. I know that nowadays, most DoS attacks, target the bandwidth whereas the firewall would not do too much..., but the firewall remains effective if the attack is orientated towards the target service. If as a countermeasure just dropping the source IPs is not an option (Spoofing might confuse the firewall here), then maybe to just Drop all connections to the target port for a time limit, which in some situations is not the ideal solution either, since downtime does equal loss in money. Choose your poison. ;)

Cheers.

Quote:

---

Originally posted here by slarty
Rate-limiting incoming SYNs is a VERY bad idea, as it will lag your web servers significantly. In fact, it could also make a synflood DoS worse, because the SYNs which are permitted are more likely to be the DoS ones than legit ones.

---

That's not quite how the Netfilter limit module operates. It applies the rule on a per source IP basis, so in this case, it will limit all traffic equally. It is still a bad idea, for similar reasons, but I felt it still needed clarification. :)

Quote:

---

Originally posted here by instronics
This sort of attack can be countermeasured at the firewall level. That way it doesnt affect the service (The listening server). You can add a timer to it, to say just drop everything for 2 mins or so. There are many things you can play with here.

---

Was it necessary to repeat that? I was merely pointing it out for the benefit of others who upon reading your post might come to believe that a firewall will stop Denial of Service attacks. It works against only one form of attack, one that has become uncommon due to other technologies.

Quote:

---

Hmm, here again it depends. (I think so atleast). The only comment to this that i have (please do correct me if im wrong), i remember a very long time ago, i saw a 'ping of death' tool, which was orientated at a destination port.

---

Actually, the original "Ping of Death" was simply an ICMP Echo Request packet with greater than 65535 bytes of data. On some systems this would hardlock them (Linux 2.0, NT, Win95, etc). Nowadays I most commonly hear it in reference to ICMP DoS attempts.

Quote:

---

Again here, apart from the 'clogging', i run it as a test succesfully using a simple dialup connection against an ISDN connection. I could not have 'clogged' the target, since my pipe was way too weak, but it still crashed the target box (yeah yeah, it was a win 98, so you could say that nowadays its pretty useless)

---

I doubt it was Win98, as Microsoft patched the issue in Win95, and I believe didn't re-release it as a bug in 98.

Quote:

---

but then again, the firewall 'could', if the limit is set to 1 packet per second, and the firewall by default allows the target port to be accessed using ICMP (dont ask me why someone would allow it, some just do), then the firewall could just start dropping, which is sort of effective.

---

Actually, a firewall would not have helped this sort of attack at all. Ping was used because most ping utilities had the capability of resizing the packets (in windows this is the -l option I believe). The issue was not protocol specific, but rather with fragmented IP packets. UDP or TCP could have been just as capably put to use for the "Ping of Death".

Quote:

---

Again, please do correct me where if im wrong. I know that nowadays, most DoS attacks, target the bandwidth whereas the firewall would not do too much..., but the firewall remains effective if the attack is orientated towards the target service. If as a countermeasure just dropping the source IPs is not an option (Spoofing might confuse the firewall here), then maybe to just Drop all connections to the target port for a time limit, which in some situations is not the ideal solution either, since downtime does equal loss in money. Choose your poison. ;)

---

Firewalls have their purpose, and that is controlling access to the hosts it is defending. However you accomplish this is certainly a valid way of firewalling. Given the limited capacity with which firewalls can mitigate DoS attacks, it is definitely worth putting them to use where they will work, but it is definitely not a good idea to discard incident response action because one has a firewall.

I stand corrected. Thanks for your info provided. I will have alot of catching up todo.

Cheers everyone :)

chsh said

Quote:

---

The biggest thing that can be done to stifle DDoS attacks is if all ISPs were required to implement egress filtering.

---

Just thought that needed repeating :brickwall