From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Logging Locationblock packets Date: Tue, 19 Nov 2024 17:10:24 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2417018776330121412==" List-Id: --===============2417018776330121412== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Rob, Good to hear from you again. > On 9 Nov 2024, at 14:00, Rob Brewer wrote: >=20 > As a contributor to the SANS ISC, I email my IPTABLES logs hourly to=20 > the=20 > Dshield database, however the default IPFire IPTABLES logs are incomplete=20 > 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=20 > IPTABLES rule to log the dropped packets. This edit does not of course=20 > survive any Core-Updates that upgrade rules.pl and the edit needs to be=20 > re-applied. >=20 > In addition, unless the Locationblock packets are logged to syslog the=20 > data=20 > displayed in the Firewall logs sections are incomplete as the packets=20 > dropped by Location Block are not displayed. >=20 > I understand that the original intension of the Location Block feature=20 > was=20 > to reduce the amount of log messages on installations running on=20 > extremely=20 > cheap flash storage. I suspect that these installations are now almost=20 > zero=20 > especially since IPFire no longer supports 32 bit versions. >=20 > The obvious solution to this to make Location Block logging selectable as=20 > a=20 > firewall option and my quick look at making a patches for this would seem=20 > to=20 > be fairly simple task to rules.pl and and optionsfw.cgi.=20 >=20 > I would be happy to provide the necessary patches should this be=20 > 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 n= ecessarily 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 d= rop those packets anyway. * People seem to misunderstand this feature: The block as many countries as t= hey can click on and think that this makes things =E2=80=9Cmore secure=E2=80= =9D, which of course it doesn=E2=80=99t. * What I personally like as a feature is to apply location filters to individ= ual rules. That allows to apply rate limits in a few places and easily select= some larger groups of potentially less interesting traffic. * Back when this was introduced there was also a lot less use of botnets as w= e know them now. Pretty much all recent DoS attacks I remember have been comi= ng from all over the world because systems where compromised wherever they we= re. This renders the filter absolutely useless. * Infrastructure is becoming more centralised. Some people attempt to block t= he 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 this now. I think this should log now. I don=E2=80=99t think there is any legitimate re= ason to disable firewall logging at all. This is the paper trail that you wan= t when debugging anything or doing forensics on an attack. Certainly bad flas= h is not a valid reason for me. I would be happy to hear some more opinions on this from the list. -Michael --===============2417018776330121412==--