IPFire previously used the "Guardian" script to provide intrusion prevention functionality with Snort intrusion detection software. While it had some limitations, IPFire could automatically react when a IDS rule was trigged by blacklisting an IP address for a period of time. Suricata now provides generally better intrusion prevention. However, it does not allow blacklisting IP addresses. This is a major lost of functionality as it means that an administrator must manually investigate all rules which are triggered in order to protect against malicious IPs. The only protection the new IPS provides is for the rules enabled. In other words, the current implementation allows an attacker to trigger numerous IPS rules with no *automated* response. Please consider re-implementing an automatic IP address blacklist based on triggered rules. I do not know the best way to do this, but wonder if Guardian could be modified to provide this functionality, without changing the existing Suricata IPS implementation. Thanks!
There's a discussion of this issue in the forums, here: https://forum.ipfire.org/viewtopic.php?p=124853#p124853
Hi, since the BZ is not a good place to have a discussion about this, I will give you the short answer and will close the ticket. We won't implement this. This is not how an IPS is supposed to work. The IPS does not "learn" or "remember" where malicious traffic has come from. That is not its job. Dropping all traffic from places that have caused one alarm would be a great opportunity for denial of service. We are living in the times of carrier grade nat. Behind one IP address might be tens of thousands of humans. Blocking by IP address is not a solution in this scenario. Now you could easily say that when there is one bad guy in that crowd, it might be better to block them all. But then you won't be getting many emails after a while if your mail server is behind this and you block a whole data center or something similar. This is basically the same logic as blocking by country. It does not solve the problem. It drops some noise. What would help you better (if you really want to drop by IP address), would be a blacklist. If you want to ban IP addresses that have caused alarms in your setup, just create a firewall rule with a group of banned IP addresses.
Thank you for the response Michael. I raised this loss of existing functionality in the forums a week ago but had no response there. This is functionality which existed until the last update and there is no documentation of it being removed, so why is it unreasonable to raise a bug against it? You have some good arguments but they only apply to some uses of IPFire. (After all the optional Guardian feature used to act the way this issue describes until very recently.) If an IPFire system needs to provide services to the entire internet then I agree that this functionality does not make sense. However if I have an IPFire system hosting a service for a limited audience (say a VPN for a handful of users) and do not care if entire residential ISPs become blocked (the main users of CGNAT today) then why can't this be an optional feature like it was? The point is for this to be an *automated* response (for a short period of time) so that a manual firewall rule for a group of IPs does not have to be created manually by an admin. I'll admit it's an automated response which mainly only works against automated attacks, but don't you agree there is some value in it?
(In reply to dnl from comment #3) > Thank you for the response Michael. > > I raised this loss of existing functionality in the forums a week ago but > had no response there. I do not read the forum much these days. Literally no time. > This is functionality which existed until the last > update and there is no documentation of it being removed, so why is it > unreasonable to raise a bug against it? It is not unreasonable to open that bug. But you are asking to bring back a "feature" that was broken in the first place and could now be replaced with something so much better. The best place would only be to have this conversation on the mailing list, since there is no bug here. There is nothing to track (yet?). The old IDS was replaced because of this. It did not work. > You have some good arguments but they only apply to some uses of IPFire. > (After all the optional Guardian feature used to act the way this issue > describes until very recently.) > If an IPFire system needs to provide services to the entire internet then I > agree that this functionality does not make sense. However if I have an > IPFire system hosting a service for a limited audience (say a VPN for a > handful of users) and do not care if entire residential ISPs become blocked > (the main users of CGNAT today) then why can't this be an optional feature > like it was? I am speaking for the people who are hosting things with IPFire. That is the most likely type of users to use the IPS. Just because you do not care about any problems here, does not mean nobody else does. The way guardian parsed the log files was slow, did not block anything until after it has happened, and then over-blocked things on the network. DNS servers from the local ISP got blocked and so on. The way to do it like that does not make any sense. > The point is for this to be an *automated* response (for a short period of > time) so that a manual firewall rule for a group of IPs does not have to be > created manually by an admin. What you want now is a script that goes through your log files and automatically updates the group of hosts. You can do that of course. This won't increase the security of your network at all - although I can understand that it feels more secure to block more. But attacks on the internet are coming from distributed botnets. Just because one part of a scan has been performed from one IP address does not mean the next one will come from there too. It is rather unlikely. > I'll admit it's an automated response which mainly only works against > automated attacks, but don't you agree there is some value in it? No, I do not think that there is any value in it. It does not stop any attacks like they are common in 2019. It just keeps the firewall busy running packets through a table where they are unlikely to match. It reduces the amount of insight the IPS has - because it won't see those packets any more. And finally there is a significant chance of over-blocking which makes it entirely unusable for people who are hosting web services or something.