From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Logging Locationblock packets
Date: Tue, 19 Nov 2024 17:10:24 +0000
Message-ID: <D97BD312-5042-4B23-9182-16097756412D@ipfire.org>
In-Reply-To: <vgnptp$2pbe3$1@tuscan4.grantura.co.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2417018776330121412=="
List-Id: <development.lists.ipfire.org>

--===============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 <ipfire-devel(a)grantura.co.uk> 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==--