From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Logging Locationblock packets Date: Wed, 20 Nov 2024 15:13:01 +0100 Message-ID: <6eeaba1a-ac38-4b24-91fb-17f93b4c5500@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0966682753214190077==" List-Id: --===============0966682753214190077== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Rob & Michael, On 20/11/2024 14:36, Rob Brewer wrote: > 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. I think people have either been away on vacation or very busy hence the slowe= r response time. > See below... > >> Hello Rob, >> >> Good to hear from you again. >> >>> On 9 Nov 2024, at 14:00, Rob Brewer >>> 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 =E2=80=9Cmore secure= =E2=80=9D, >> which of course it doesn=E2=80=99t. >> > 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=E2=80=A6 >> > :) > >> Therefore I am happy to rethink this feature - personally I would even >> remove it entirely, but I don=E2=80=99t like to handle the stress about th= is >> 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=E2=80=99t 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. > =20 > 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. I had added this topic onto the agenda for the next video conf call but if it= gets resolved on the mailing list that is also fine and I will then, at that= point, remove it from the agenda. I don't use Location Blocking on my production system at all. Virtually every= thing is blocked as standard. I just have port 80 open for Lets Encrypt and a= s they use multiple servers from multiple ASN's to validate you have to not u= se Location Blocking otherwise you can end up blocking the update process. Th= ey will not provide a list of the IP's of their servers. Therefore from my point of view I have no issue with logging being able to be= turned on for Location Blocking as I don't use it anyway. Regards, Adolf. >> -Michael > I hope these comments are useful and would be pleased to help where I can. > > > Rob --===============0966682753214190077==--