fail2baniptables
How does fail2ban protect against SSH DDoS attacks? What does it do in the case of a DDoS attack? And how does it determine if it is a DDoS?
I am asking only about DDoS attacks.
(I assume it really can protect against DDoS because articles like How to Secure SSH server from Brute-Force and DDOS with Fail2ban (Ubuntu).)
Question #1: When the documentation says "log it to the system log once, then immediately reject it and forget about it" what do they mean by forget about it?
Means that the message will show up in the logs, but only once, so your log won't get polluted with a continuous stream of messages every time the rule is triggered.
Question #2: Forget about it forever?
No not forever. There is a time period associated with how frequently these messages will occur in the logs.
Question #3: Is there a blacklist that iptables check?
No there is no blacklist that iptables "checks". It's dumb in the sense that it will only filter what you tell it to, and will allow only what you tell it to allow through.
Question #4: If an IP is rejected but then tried another connection an hour later, will there be another 3 attempts from that IP?
It depends on what's the over arching timeout. If additional attempts occur and the original timeout hasn't elapsed from the initial attempts, then no there should be no additional messaging in the logs, nor allowed connections. If that timeout has elapsed however, then yes you'll see additional messaging about these follow-on attempts.
I'd encourage you to take a look at the documentation for the Iptable's recent module for additional details on how it works.
Port Scanning
The length of time that an IP remains on the "badguy" list would be governed by a structuring of your rules like this:
iptables -A INPUT -i $OUTS -m recent --name badguys --update --seconds 3600 -j DROP
iptables ...
.
.
.
iptables -A INPUT -t filter -i $OUTS -j DROP -m recent --set --name badguys
The first rule would check to see if an incoming packet was already on the "badguy" list. If it were, then the clock would get "reset" by the --update switch and the badguy's IP would remain on this list for up to 1 hour (3600 seconds). Each subsequent attempt would reset this 1 hour window!
NOTE: With the rules structured like so, offenders would have to be completely silent for one hour in order to be able to communicate with us again
SSH
For SSH connections the tactic is slightly different. The timeout associated with IP's getting on our "badguy" list is still 1 hour, and still gets reset upon every reconnect within that 1 hour window.
For SSH we need to count each --syn connection. This is a TCP SYN packet, in the TCP 3 way handshake that occurs. By counting these we can "track" each connection attempt. If you try to connect to us more than say 2 times in a 30 second window, we drop you.
To get these IP's that continuously try to connect in the "badguy" list we can incorporate another rule that adds them if they attempt to connect to us say 6 times within a 5 minute window (300 seconds).
Here are the corresponding rules - their order is critical!:
iptables -N BADGUY
iptables -t filter -I BADGUY -m recent --set --name badguys
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --set
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 300 --hitcount 6 -j BADGUY
iptables -A INPUT -i $OUTS -p tcp --syn --dport ssh -m recent --name ssh --rcheck --seconds 30 --hitcount 2 -j DROP
NOTE: You can see the "badguy" list under /proc/net/ipt_recent. There should be a file there with the name of the list, badguys.
Question #5: If it is the case then this is not blocking but slowing down the attacks as long as iptables doesn't have some blacklist count?
I think you'll find that in general there are 3 ways to deal with connection attempts from iptable's perspective.
#3 is where most of the complexity comes from in setting up iptables and/or firewalls in general. Since much of the traffic on the internet is OK, to a point, and it's when that traffic exhibits "obsessive" behavior, in the sense that a single IP tries to connect to your server's port X number of times where it becomes an issue.
First off. This is (perhaps) not an answer but perhaps better then a comment (and a bit long for it).
Find your statement:
Actually, it can scan files without any time on any line and it will still work.
conflicting with the documentation. What do you mean by work?
The manual#filters (v 0.8) states:
If you're creating your own failregex expressions, here are some things you should know:
[...]
In order for a log line to match your failregex, it actually has to match in two parts: the beginning of the line has to match a timestamp pattern or regex, and the remainder of the line has to match your failregex. If the failregex is anchored with a leading ^, then the anchor refers to the start of the remainder of the line, after the timestamp and intervening whitespace.
The pattern or regex to match the time stamp is currently not documented, and not available for users to read or set. See Debian bug #491253. This is a problem if your log has a timestamp format that fail2ban doesn't expect, since it will then fail to match any lines. Because of this, you should test any new failregex against a sample log line, as in the examples below, to be sure that it will match. If fail2ban doesn't recognize your log timestamp, then you have two options: either reconfigure your daemon to log with a timestamp in a more common format, such as in the example log line above; or file a bug report asking to have your timestamp format included.
Note here that log files can be configured to include time stamps as well as the format of the time stamps. (That include dmesg as mentioned in comment.)
Also see this thread, Message #14 and #19 in particular:
Note that you can also test with commands like:
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf
$ fail2ban-regex ' [1.2.3.4] authentication failed' '\[<HOST>\] authentication failed'
Running tests
=============
Use failregex line : \[<HOST>\] authentication failed
Use single line : [1.2.3.4] authentication failed
Results
=======
Failregex: 0 total
Ignoreregex: 0 total
Date template hits:
Lines: 1 lines, 0 ignored, 0 matched, 1 missed
|- Missed line(s):
| [1.2.3.4] authentication failed
`-
$ fail2ban-regex 'Jul 18 12:13:01 [1.2.3.4] authentication failed' '\[<HOST>\] authentication failed'
Running tests
=============
Use failregex line : \[<HOST>\] authentication failed
Use single line : Jul 18 12:13:01 [1.2.3.4] authentication failed
Results
=======
Failregex: 1 total
|- #) [# of hits] regular expression
| 1) [1] \[<HOST>\] authentication failed
`-
Ignoreregex: 0 total
Date template hits:
|- [# of hits] date format
| [1] MONTH Day Hour:Minute:Second
`-
Lines: 1 lines, 0 ignored, 1 matched, 0 missed
It is quite difficult to evaluate the reaction time. Fail2ban waits 1 second before checking for new logs to be scanned. This should be fine in most cases. However, it is possible to get more login failures than specified by maxretry.
In that regard also see this thread: Re: Bug#481265: fail2ban: Poll interval is not configurable.
But under optional but recommended software one find Gamin.
Gamin is a file alteration monitor. Gamin greatly benefits from a "inotify"-enabled kernel. Thus, active polling is no longer required to get the file modifications.
If Gamin is installed and backend in jail.conf is set to auto (or gamin) - Gamin will be used.
Best Answer
It's hard to "protect" against DDoS attacks, but one can mitigate them by avoiding useless costly computation.
fail2ban can limit the number of attempts that each participant in the DDoS attack can do. Once blacklisted, attempts will be blocked before starting any costly cryptography. Instead of letting your SSH server perform useless computations, the firewall will apply simple rules to reject clients. Clients will still use your network bandwidth, and a bit of CPU time, but far less than the SSH server would.