Misconceptions about DOS & DDOS

There seems to be a misconception that a Dos or DDos can be blocked with a firewall, and its just bugged me to no end. So I hope this will clear things up a bit.

Tiger Shark
There are two type of DoS. There's the kind that confuse, crash or overwhelm the target with packets that are malformed or conatin data/instructions designed to do that and the kind where you "fill the pipe" with so much traffic that nothing valuable can occur until the "flood" has stopped.

The first can be stopped by patches or systems that recognize the attempt and intercept the traffic or by sgutting down the affected service thus allowing other services to continue. The second type you are helpless to prevent. You need, at a minimum your ISP to drop the packets if he can. If not, grab a beer and hope they give up before you have to drive home....

The second is a flood type DoS that fills the pipe in which you are still up the river without the proverbial paddle because the traffic in your pipe is blocking valid requests anyway so the firewall dropping the invalid ones is of no help.

Tedob1
dropped or not[packets] they're still traffic on the pipe. you get enough of them and your going to be deprived of service. not as easiely as hogging the server's resources but a DoS just the same


Slarty
The action you need to take depends on the type of DoS attack

If it's a web application / web server DoS attack, it needs fully formed TCP connections to be effective - therefore it cannot use spoofed IPs, so you should record the IPs and block them at your firewall. Also you can use some web sevrer plugin modules like mod_security or its IIS equivalents to identify DoS attempts and block them, also some lame bandwidth DoS attempts.

If it's a synflood, just turn syn cookies on on your web servers or redirectors, job done.

If it's a bandwidth DoS, that is the hardest problem, it will be using spoofed source IPs set randomly, so you can't block the IPs at an upstream firewall. The DoSers will be using a TCP packet type which is part of legitimate traffic, so you can't block it upstream by flags or port numbers either.

Of course a local firewall has absolutely no effect on a bandwidth DoS, because the bandwidth is exhausted before it even gets there.

Your best bet is to work with your upstream providers, and get them to work with their peers to identify the routes used by the DoS traffic, and attempt to narrow it down to a given area, and if it's a truly distributed attack, there may be little they can do.

One option is to get your upstream provider to install some kind of QoS to somehow limit this traffic, to give established legitimate connections higher priority, or to set up a stateful firewall upstream, but again, this is dependent on how much resources your upstream provider have to throw at the problem.

Quote:

---

a firewall is supposed to be able to take care of a DoS attack

---

No, it isn't.
Slarty


Credit given to original author. Some words were changed or added in my decision on what to put here. More may be added later as I find it. Or feel free to add your own.

w00t

Darksnake very nice. BTW I thought if you performed a DoS attack on a firewall it would make it completely useless? Computernerd22

Quote:

---

Originally posted here by Computernerd22
Darksnake very nice. BTW I thought if you performed a DoS attack on a firewall it would make it completely useless? Computernerd22

---

So did I. I read somewhere that the firewall will recognize a DoS attack and pick out the offending IP and block/ignore all traffic from that source. True that it puts a strain on the firewall....but while the firewall is working overtime, I thought everything else was supposed to function normally. (Just b/c I read it somewhere doesn't mean it's true...) So how is this not true? I read the "mini-tutorial" but I still didn't quite find the answer to that.

A firewall will stop a DoS attack from affecting your machine so to speak, but it (the DoS) will deny others from using any service provided by your machine. Syncookies are nice and all, but if all the bandwith is being used by the DoS... You're SOL.

I always thought that if a firewall could detect that multiple if not an enormous amount of SYN packet's (or any for that matter, or better yet an unusual amount) that it would be able to deny that IP from attacking? For instance, if I was being DoSed and I saw on my IP continued TCP SYN packet probe's/attack's from a certain IP, then I would drop the connection and block the IP (let alone report it to the ISP, but that's another story).

I have to agree though that a firewall typically isn't supposed to take care of a DoS attack although when you think about a firewall and you know it's main goal is to moniter/maintain incoming and outgoing traffic, you think about a DoS attack and the traffic sent/recieved.

Quote:

---

(the DoS) will deny others from using any service provided by your machine.

---

Yeah, this is also what I thought to be true as well. Thus the name "Denial of Service" those that use the particular service (be it a webserver, etc) wouldn't be able to. Anyways, very good information DarkSnake.

If the attack pattern is to crash a specific type of service or subvert it, a firewall can prevent a DoS attack.
Put if DoS attack objective is "fill the pipe", nothing can be done at client side. Just ISP can help on that case.
BTW, DoS attacks "fill the pipe" arent common, because is hard to get a "zombie" big enough to have a huge BW to attack someone. Nowadays, the common attack is reflect DDoS or a bot DDos.

Best resource i have seen on dos/ddos http://staff.washington.edu/dittrich/misc/ddos/ If ya got a better link please post it :)

A typical firewall wont take care of a Dos attack But there are certain hardware firewalls that will but the are expensive and are not very effective. As for software firewalls i dont know.

Ok, I admit it, I was generalising.

A DoS attack, by its nature, consists of traffic attacking a legitimate service that is intended for the public or authorised users. Therefore you can't simply block traffic to that service, as that would DoS yourself.

SOME DoS attacks (the easy to prevent kind) work by sending malformed stuff, or trying to overload stuff at the application level. These can be prevented or mitigated by a sufficiently clever firewall (for instance that does content filtering). Also, as these attacks require valid TCP connections (or some kind of bidirectional traffic), the attacker cannot spoof their IP. Even in the case of fairly large scale DDoS, if the attackers are not spoofing, you can filter them all, or create some sufficiently clever scripts to dynamically create rules without affecting most legit users.

HOWEVER the trouble starts when they use spoofing. Either they flood your app with useless spoofed requests, for example in the case of a UDP-based server, it uses its own resources trying to respond to these spoofed messages, and ultimately runs out. OR they send traffic where each packet looks legit to a non-stateful firewall, but is actually total rubbish spoofed.

You can't filter this junk out upstream, because it simply isn't easy enough for an upstream to know whether it's real or fake. It doesn't have any identifying characteristics, they typically randomise:

- Packet lengths
- TCP flags and attributes (within believeable values)
- data
- source address
etc

And of course the destination address is some legitimate service, for example a real web server.

So the upstream provider *cannot* filter it by any means, and attempt to achieve a reasonable hit-rate unless they install stateful inspection, which for an upstream provider, could prove very expensive.

I *am* speaking from experience.

Slarty

Quote:

---

Even in the case of fairly large scale DDoS, if the attackers are not spoofing, you can filter them all, or create some sufficiently clever scripts to dynamically create rules without affecting most legit users

---

In the case of a DDoS that's a pretty big job you just gave yourself. Filter them all day if you like.... They are still coming through if the source is picking random IP's to send from. That would be an issue wouldn't it? "If" is a big word..... They don't do that any more unless they are stupid....

Then there RDDoS that spoofs too.... How do you mitigate that?

Not meant to be "offensive" Just want to make sure we all undersatnd the potential... ;)

Quote:

---

Originally posted here by Darksnake
The second is a flood type DoS that fills the pipe in which you are still up the river without the proverbial paddle because the traffic in your pipe is blocking valid requests anyway so the firewall dropping the invalid ones is of no help.

---

Had no thought of that before. Thanks!

Quote:

---

Originally posted here by Tiger Shark
[B]In the case of a DDoS that's a pretty big job you just gave yourself. Filter them all day if you like.... They are still coming through if the source is picking random IP's to send from.

---

No, if they are not spoofing, even DDoSers have only a relatively limited number of IP addresses to use. You won't in practice see more than a couple of hundred, and in any case, you can start using some automated tools to identify them.

Fully-formed TCP connections cannot (easily) be spoofed, so any attack which requires them forces the attacker to use their real IP address (or at least *A* real routable one). So you can block this IP and stop their attack getting through, even if there are hundreds, you're extremely unlikely to take out legit users.

If it's a type of DoS which does spoofing, you stand almost no chance of telling even if it *is* a distributed or localised attack, because you've no idea where the packets are coming from, they tend to randomise source addresses.

The problem is that some protocols use UDP (example: streaming services, game servers, possibly DNS) exclusively, and that generally means they can be DoS'd quite easily using spoofed packets (as the server does not require a handshake with the client before it expends resources on it). And TCP syn_cookies are only for TCP, so unless the application itself has something equivalent to syn_cookies, you're going to be stuffed.

Of course a lot of games,streaming etc, have a parallel TCP channel, and don't set the UDP channel up until they've got a valid TCP connection; this is a good approach as it makes IP spoofing to the app much harder.

Slarty

This is very interesting, as it is an area I have had no involvement in.

What I am curious about is that a few weeks ago several security sites were taken down by DoS attacks. All at the same time, and it lasted several days, not just a few hours? (I think spywareinfo, Tom Coyote etc.)

How was that done?.............hey, they should know all about firewalls and stuff?

It seemed to me that they had to get additional bandwidth/resource to be able to fend off the attacks.


:confused:

I've no idea how these attacks "were done", I've only been describing symptoms I've seen.

But if someone did know, I would advise them not to announce it in a public forum to discourage copycat attacks

Slarty

I take your point Slarty, but I do not see it as a technical issue.

As far as I can see the attacks I referred to were professional, and must have relied on volume/weight of numbers, rather than some "hidden knowledge"? I think that the methodologies have already been discussed here, what I would be really interested in are the defence strategies.

Cheers

you can see some details about classic DoS attack
http://www.grc.com/dos/grcdos.htm
and a DRDos attack
http://www.grc.com/dos/drdos.htm
(Gibson use to be a target. He deserves :) )
Methods of attack are public. Attacks that just wanna to "fill the pipe" are easy to implement.
a) bot system
- attack and install trojan on several adsl-clients - they have 128kb-1mb BW
- command your bots from your pc (or other zombie machine) to flood victim computer
- use crafted packets with random source ip.
- its done. Victim must call ISP to try to block traffic at ISP side. However, if you craft very random packets, ISP will need some time to analyse packets and try to see a "pattern".
b) Broadcast ping
- some dumb companies with several IPs on internet continue to answer broadcast PING
- send a ping to a broadcast address (4+ ips)
- craft echo request packet with victim IP as source address
- its done. Everybody will send echo reply to victim, flooding his link.
- Hard to block.
And there are others. And tools ready to download and use.

If using iptables, there is some form of protection against Denial of Service attacks.

Using the:

-m limit
or
--match-limit

options.

Examples:

Syn-Flood-Protections: iptables -A FORWARD -p tcp --syn -m limit 1/s -j ACCEPT

If this limit is exceeded, then depending on your RULES, the apropriate action will be taken.

Certain portscanning protections:
iptables -A FORWARD -p TCP --tcp-flags SYN,ACK,FIN,RST RST -m limit 1/s -j ACCEPT

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

Here again, its the same thing. If the limit is exceeded, action is taken depending on your rulesets.

These examples are taken from a tutorial in which im in the process of writing. For the deeper meaning of this, wait a few days till im done with it.

Cheers.

//addon
For some info on attacks, have a look at:

http://www.antionline.com/showthread...hreadid=239990

Cheers.

Actually if you are talking types of DoS, you must consider all types....Including DNS poisoning, account deletion and something as simple as cutting power or impeding physical access to a system. Not really what you think of when you say DoS but these are still other types besides the 2 mentioned earlier.....

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. :)

Cheers.

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