Does blocking an IP with IP Tables protect you from a DOS (not DDOS) attack?

Question

I am fairly new to network security, and I just learned about the Fail2Ban framework you can use for automated exploit detection/prevention. It says that you can protect yourself from DOS attacks by setting up a rule that will automatically block their IP by adding it to IPTables after a configured number of attempts in a configured amount of time. My question is, if all you are doing is rejecting their requests, then they still have access to try to send information on that port. Can they not still overload your server with requests?

I've done some research on this, and the only potential reason I could find is that with a DOS attack, they are restricted by their upload bandwidth which is almost guaranteed to be smaller than your download bandwidth, so even if they are trying to hit you as hard as they can with requests, if you block their IP and aren't doing any processing on the information then they are really throwing pebbles at a brick wall there. Is this correct? What other reasons would this you be protected from DOS with this method?

Answer 1

My question is, if all you are doing is rejecting their requests, then they still have access to try to send information on that port. Can they not still overload your server with requests?

Yes, a subset of attackers can. If their bandwidth is greater than yours, or if they find a way to use your bandwidth faster than theirs to offset the difference, you are starved of bandwidth and legitimate traffic cannot get through.

This is actually true at any time attacker_effective_bandwidth + legitimate_bandwidth > server_bandwidth, so it isn't solely dependent on the attacker's resources, but also on the degree to which you over-provision.

Note also that fail2ban is focused on access attempts and exploits that you log or monitor. Some denial of service attacks rely on communications that may not be logged (ICMP echo requests, for example), and might not trigger fail2ban.

if you block their IP and aren't doing any processing on the information then they are really throwing pebbles at a brick wall there. Is this correct?

It is only correct if the resource you are preserving is CPU, and if fail2ban will observe /trigger based on all traffic that causes CPU usage. Dropping packets does take a measurable amount of CPU, but it is much smaller than trying to do anything else with them.

What other reasons would this you be protected from DOS with this method?

I don't understand this question, but I think that fail2ban is one tool you might use, and a reasonable one. However, you should consider adding other tools if the cost of your site going down is greater than the cost of acquiring and maintaining the tools required to prevent it.

Answer 2

To answer your question, yes blocking the IP of an attacker DoS'ing your server is an effective mitigation. This is for two basic reasons:

Reason #1: Hypothetically, if the attacker is going with an basic flood based attack with the intention being to overwhelm the server with bandwidth (say uploading files?) blocking their IP will significantly reduce the bandwidth of their attack to the point it should not have any impact on your server (as long as your server isn't a hamster running on a wheel powering a Raspberry Pi).

It should be noted, #1 is a rare attack strategy for a DoS attack since realistically, a single attacking node will not have the bandwidth capabilities to crash a server by flooding it with requests. The more common case is

Reason #2: Application level DoS attacks are much more effective. For example, lets say your website has a login page that conducts server side cryptographic hashing of the supplied password. A smart attacker could attempt to crash the server by focusing their DoS attack on that login request, making the server compute hundreds or thousands of simultaneous logins when the typical load is much lighter. In this case, the Fail2Ban framework you described should work perfectly as it would filter away the attackers fake login requests.

The entire mitigation tactic can be circumvented by frequently rotating a spoofed IP address at the attacker's note but that becomes an odd DDoS/DoS hybrid and you specifically asked about old fashion DoS. Therefore, the answer stands. Simply blocking the attacking IP should be an adequate defense.

Answer 3

What's probably most important here is that in regard to the mitigation, it's almost useless to tell apart DoS and DDoS attacks these days. No real world denial-of-service attack happens from a single fixed IP source anymore.

The only obvious exception is when an attacker generates a specially crafted packet to exploit a vulnerability with DoS potential (e.g. a null pointer dereference somewhere in a packet handling code; here's an example of such vulnerability). But blocking a source IP address which runs an exploit isn't really a good way to mitigate that; patching a vulnerable system is.

In theory, it would be easier to handle a simple DoS attack than a distributed one. However, as those are too easy to mitigate, they are mostly extinct nowadays, and the tool you're asking about (Fail2Ban) isn't there to help against extinct attacks, it's written with real world application in mind.

Taking this into account, blocking an IP address (either with Fail2Ban or manually) only makes sense if two conditions are met at the same time:

1. The DDoS attack which is ongoing affects only the performance of the server itself (or anything behind it, like a database server behind a Web application), but not the network transport in front of it;
2. It can be verified somehow that all the source IP addresses involved in attack are not spoofed. E.g. a DDoS attack targets a handshake-based network service (where you can negotiate some secret towards a client and verify that the client has actually received the secret), and passes the basic handshake successfully. I can come up with another example, but the description above pretty much sums up the most frequent scenario.

Regarding a typical HTTPS server, you can use IP range blocking against, for example, TCP connection flood, SSL/TLS handshake flood, POST flood, Slowloris, and so on (it's rather hard to classify Layer 7 attacks beyond simple floods), which all in most cases satisfy both requirements.

Note that though, say, a sufficiently large POST flood could in fact affect the network transport in front of your server, IP blocking can still help you with that, because it prevents underlying TCP connections from being established, and a malicious bot won't be able to subsequently send a large POST body towards your server. This effectively limits the remaining malicious incoming traffic to a low rate SYN flood which is in most cases easy to handle.

Moreover, the main effect which an HTTP-based flood will cause on your network transport is due to outbound traffic generated by your server in response (which in today's HTTP may be about 11-12 times more than the inbound one), and blocking the IP sources of an HTTP flood eliminates this as well due to the reasons outlined above.

At the same time IP blocking is mostly useless against attacks like ICMP flood, SYN flood, UDP flood, and others which do not satisfy at least the requirement #2; and against amplification attacks which are, under most conditions, so powerful in terms of inbound traffic that they do not satisfy the requirement #1.

Note that the fact that a source IP address in a, say, SYN flood can't be verified doesn't necessarily mean it is spoofed. However, blocking a potentially spoofed IP address range may result in your service being unreachable for legitimate users. In fact, it may be an attacker's intent to trick you into starting to automatically (e.g. via the said Fail2Ban tool) block source IP addresses of a packet-based flood while there are only few sources present in the traffic, and then to spoof important IP address ranges, such as the IP ranges of largest ISPs in your country, or even the whole global IPv4 address range of ~4 billion addresses which, at an arbitrary flood rate of 100 Mbit per second, could all be enumerated in roughly an hour — I've actually seen that in my life a few times.