On Tue, 19 Nov 2024 17:10:24 +0000, Michael Tremer wrote:
Hi Michael, thank for your response, I was beginning to think there was little interest in this topic.
See below...
Hello Rob,
Good to hear from you again.
On 9 Nov 2024, at 14:00, Rob Brewer ipfire-devel@grantura.co.uk wrote:
As a contributor to the SANS ISC, I email my IPTABLES logs hourly to the Dshield database, however the default IPFire IPTABLES logs are incomplete since packets dropped by Locationblock are not logged to syslog.
This is correct.
As a workaround I edit the locationblock function of rules.pl to add a IPTABLES rule to log the dropped packets. This edit does not of course survive any Core-Updates that upgrade rules.pl and the edit needs to be re-applied.
In addition, unless the Locationblock packets are logged to syslog the data displayed in the Firewall logs sections are incomplete as the packets dropped by Location Block are not displayed.
I understand that the original intension of the Location Block feature was to reduce the amount of log messages on installations running on extremely cheap flash storage. I suspect that these installations are now almost zero especially since IPFire no longer supports 32 bit versions.
The obvious solution to this to make Location Block logging selectable as a firewall option and my quick look at making a patches for this would seem to be fairly simple task to rules.pl and and optionsfw.cgi.
I would be happy to provide the necessary patches should this be acceptable.
I think a couple of things have changed since we introduced this feature and we have also learned a couple of lessons here:
- Yes it is true that this was introduced to keep the logs smaller, but
not necessarily to avoid using storage, mainly to keep them readable by a human. I was always a bit doubtful about this and believe that apart from this, there is no more value in a general location blocking feature. The firewall will drop those packets anyway.
IPFire does a very good job in protecting the internal network from unwanted probes from the WAN, and I agree that for most users, location block does not enhance this protection.
As I run a mail server, I use locationblock as part of my filtering to prevent bad actors from accessing my mail server and I think would be useful for anyone who are running servers on their networks.
I don't like blocking traffic, but I have witnessed over the last few years a substantial rise in abuse from certain countries from where I would never expect to receive emails and locationblock works very well for me in filtering out those unwanted connections.
I currently have 21 countries blocked including XD Hostile networks. All of these blocked countries have been seen to support abusive networks.
It would be possible to generate individual rules for these networks which in some cases I do with Banish, but it is sometimes easier just to drop the whole country.
- People seem to misunderstand this feature: The block as many countries
as they can click on and think that this makes things “more secure”, which of course it doesn’t.
I think this is education and I suspect that very few of these people are running servers on their system and need location block.
- What I personally like as a feature is to apply location filters to
individual rules. That allows to apply rate limits in a few places and easily select some larger groups of potentially less interesting traffic.
I agree and is similar to what I am doing for ports 25 and 587 although with location block.
- Back when this was introduced there was also a lot less use of botnets
as we know them now. Pretty much all recent DoS attacks I remember have been coming from all over the world because systems where compromised wherever they were. This renders the filter absolutely useless.
For this, I am currently testing a dynamic block list on my system which adds an entry to an ipset when an ip address exceeds a threshold in the previous 24 hours. Currently there are about 7000 entries in this set which have been detected over the previous month. Not for everyone because it needs a Whitelist to prevent some 'push' technologies such as Facebook and to protect from bulk inputs such as mailing lists. I also blacklist a large number of ip addresses which are associated with port scanners.
This would work well as a botnet filter but it needs an understanding of the blocking process, so it would not be suitable for everyone.
- Infrastructure is becoming more centralised. Some people attempt to
block the US and pretty much nothing works any more. Well…
:)
Therefore I am happy to rethink this feature - personally I would even remove it entirely, but I don’t like to handle the stress about this now.
No I think you should keep it. Locationblock is very useful, but needs to be used in a considered way. I could live without it but its availability makes my life easier. Also being updated on a weekly basis makes keeping track of abusers easier.
I think this should log now. I don’t think there is any legitimate reason to disable firewall logging at all. This is the paper trail that you want when debugging anything or doing forensics on an attack. Certainly bad flash is not a valid reason for me.
I have started generating some patches to make 'locationblock logging' as a selectable feature and could post them here in the next day or so if of any use.
In fact I think that IPFire's logging environment, which was inherited from IPCop needs a re-visit.
I was pleased to see that a while back there was a discussion of replacing sylogd with rsyslogd which I think would be a very useful upgrade and enable kernel messages, like on most current linux systems, to be logged to alternative log files instead of everything ending up in /var/log/ messages.
The replacement with rsyslgd could also inhibit the "last message repeated x times" in syslog and which are ignored by IPFire's Log menu and causes erroneous results in the 'Count' values.
I would be happy to hear some more opinions on this from the list.
-Michael
I hope these comments are useful and would be pleased to help where I can.
Rob