@trialotto I think you are a bit confused as to how CSF country blocking actually works. If you block a country using CSF then the login failure daemon downloads that countries netblocks then adds them to ipset. From that point on it
does not have to be logged first in order to block an IP address from that country.
@danami,
In essence, you literally managed to restart a very, very, very old discussion.
Nevertheless, it is good to be clear about things that matter to any sysadmin, especially when those things are related to server security.
First, let's state some facts :
- LFD is packaged with CSF,
- CSF is
free software,
- CSF is developed by Way to the Web Ltd (a.k.a. ConfigServer) and they also developed LFD to enhance / improve CSF,
- Juggernaut Security & Firewall is actually a (nice) shell around CSF and is
not free,
- CSF and LFD both work independently - two "separate systems" in one package that offer combined strength,
- LFD allows for
country blocks and even
custom lists - in the CSF + LFD environment, a country block is essentially a custom list,
- LFD is a daemon - as a daemon it works all the time, but it will
only periodically scan logs and only logs that are specified in the config files,
- LFD is essentially not different from Fail2Ban with respect to
log scanning - both scan (specific) logs
periodically,
and there is
one major difference between LFD and Fail2Ban : LFD often requires restarts, whereas Fail2Ban does not in identical or similar cases.
It has to be emphasized that any change to CSF and/or LFD will not have any effect, if CSF and/or LFD will not be restarted.
In my humble opinion, that can be problematic - automated/scripted restarts are not always the case and, even more important, CSF + LFD sometimes fails to restart in specific situations, with one of those situations being the overload of logs and firewall during heavy (often distributed) attacks.*
Sure, you are right that country netblocks can be added and be effectively blocked by the firewall - if and only if CSF
and LFD are properly restarted.
However, you seem to fail to notice that the country netblocks added by CSF/LFD are not always up-to-date and, even worse, are not adequate in the sense that all IPs from a specific netblock are being blocked,
including those IPs from which genuine traffic is originating.
Imagine that....... IPs associated with Plesk are Russian IPs or blocked IPs in general and you suddenly do not get updated!
Imagine that....... IPs associated with Chinese netblocks are fully blocked, whilst your customers do need to contact their Chinese suppliers!
I am sorry, but blocking country netblocks is
wrong in every way ........ if you want to protect your server with radical measures, just shut it down permanently.
However, if you want to filter out the bad apples ...... just use a log monitor......... and accept that specific entries associated with bad/malicious traffic first have to occur before the IPs associated with that bad/malicious traffic can be blocked.
Sure, to some extent LFD (as a stand-alone daemon, which is possible) works more efficient than Fail2Ban, but Fail2Ban can be fine-tuned to a higher degree than LFD - this
is important when using Nginx as a proxy, for reasons that I will not explain here.
In conclusion, my answer to your post is : yes, you are right within the very abstract and minimal context that you use to discuss this topic.
However, the context should be a little more complex and should also include the facts that
- Nginx can do the same and better
and more efficient : just add country netblocks or specific CIDR ranges in the Nginx conf,
- Fail2Ban can be made more performant by fine-tuning rules : this will reduce the performance penalty that is associated with Python-based Fail2Ban,
- Fail2Ban + Nginx can be an
excellent combination : a perfect combination will offload the firewall,
making the firewall more effective as such,
- a
golden rule applies : malicious traffic should be stopped at the lowest entry level (not at the firewall level - this too late : it should not enter the server), **
-
optimization rules apply : malicious traffic for the server
or the web server should be treated differently (they both require separate countermeasures), ***
and the above is just a simple summary to indicate that this topic should not focus on CSF or LFD alone - there is much more than meets the eye!
In essence, I prefer any Nginx based solution over any firewall based solution - Nginx is more robust and able to prevent
or withstand heavy attacks when being properly configured, whereas the average firewall (iptables) is likely to fail or even shutdown the whole server under similar heavy attacks. ****
It is a matter of preference and a matter of knowledge - as such, it is a matter of capability to
compare CSF/LFD/iptables with Nginx/Fail2Ban/iptables.
I know that you prefer CSF/LFD/iptables - that is fine.
I know that I prefer Nginx/Fail2Ban (highly modificated)/iptables - that should also be fine.
I hope that you can at least agree with that.
I also hope that you will allow the other Plesk forum members to make up their own mind.
Kind regards.......
* You can test that by simulating a heavy DDoS on your own (test) server, while trying to reconfigure CSF/LFD on that (test) server - it will be problematic.
** This is beyond the scope of this topic. In essence, the firewall level is not the lowest level at which traffic can be blocked.
*** As a golden rule of thumb, the server should be protected primarily by the firewall, whereas the web server should ideally be protected by a proxy (like Nginx for example) with a configuration that is suitable to block all malicious traffic aiming for the web server - this simply implies that the firewall does not have to contain a huge number of firewall rules that are only related to the web server : if the web server is under (heavy) attack, the lean-mean-and-efficient set of firewall rules will still be able to protect the server as such, since it is not likely that the firewall gets flooded by web server related firewall rules. Ideally, the proxy config should be updated dynamically to be able to defend the web server - for that reason, Fail2Ban is optimal : it can be tweaked to write/change the config files of Nginx (and a simple script can then be used to reload the Nginx config files, if and when adjusted by Fail2Ban).
**** In general, this applies. However, the situation described is more in the light of a heavy attack on the web server, to obscure an attack on the server. This is a quite common tactic, as such a reason to make a clear distinction between "web server protection" (via proxy/Nginx config) and "server protection" (via the firewall or other countermeasures on lower entry levels).
Facebook
Twitter
