1

While reading DOS detection and prevention http://staffweb.cms.gre.ac.uk/~lg47/publications/LoukasOke-DoSSurveyComputerJournal.pdf I've asked myself: Even if a firewall detects a DOS attack and begins to filter it out, doesn't the detection and filtering (by IP etc.) still require a resource to respond to the attack (in terms of dismissing the request)?

I understand that the resources required to blocking an attack are magnitudes smaller than really handling the attacks but are there scenarios where a DOS can still succeed on occupying a resource in a way that the filtering of the attack still causes a DOS?

5

As long as the DOS attack can consume more resources (network bandwidth, compute power etc) than the target can supply, then it will succeed, despite being identified.

Filtering is very difficult - you require a lot of bandwidth, and a way to separate good from bad traffic. If you filter everything, then you cause a DOS on yourself anyway.

This is why a DDoS has such an impact. It is possible to launch orders of magnitude more traffic than the target can cope with. The only solution in these cases is to use a DDoS mitigation partner - and even there, there is always some impact as they enable rerouting, configure scrubbing rules, tune these rules etc., and as before, if the DDoS gets big enough it will also knock the mitigation provider off the Internet.

0

To what extend can a DOS attack succeed even if it was detected?

If a DOS attack isn't detectable, it didn't succeed.

For a DOS attack to succeed, the defender needs to be overwhelmed, even though they know what's happening.

The more the defender's cost per packet exceeds the attacker's cost per packet, the more likely it is that the defender will be overwhelmed.

The aim of DOS filtering is to discard the DOS packets cheaply - to reduce the cost of receiving the packet to something close to the cost of sending the packet.

It's quite possible that filtering may fail to prevent the DOS succeeding. If, for example, the DOS chews up all your bandwidth, it will succeed.

But the only way that filtering is likely to cause the attack to succeed is if filtering is significantly more expensive than just letting the DOS packets hit your infrastructure. That's not impossible, but it's unlikely.

If filtering is only slightly more expensive than not filtering, which will typically be the case if filtering doesn't work, then it probably won't make any difference during an attack. Any attack that succeeds would probably have succeeded anyway, especially as the firewall is almost always a different box to the one hosting the service under attack.

Where filtering can hurt is with normal traffic. If the cost of filtering is significant, compared to the normal cost of processing, and if there isn't a lot of spare capacity, then filtering can turn a load of healthy traffic into a self-denial of service.

2
  • The only way that filtering will cause a DOS attack to succeed is if the filtering is more expensive than just letting the packets through. It's quiet possible that filtering will fail to prevent a DOS attack, because the filtering itself gets overwhelmed. Technically, I concede it's possible that your webserver could handle a load that your firewall could not, but only if you have a very big webserver and a very small firewall. Even if your firewall passes the DOS packets, the extra effort of filtering is very unlikely to be the difference between success and failure. May 10 '17 at 12:09
  • More expensive, yes. That's possible. If the filtering doesn't work, then it's going to add effort for no value. But unless your filtering is orders of magnitude more expensive than serving the packet, anything that can flood the firewall can flood whatever appliance is behind it. You're only worse off if the firewall fails when the webserver (or whatever) wouldn't have failed. May 10 '17 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.