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: Wed, 20 Nov 2024 15:21:28 +0000
Message-ID: <FF98E46D-DC51-48CD-A324-A99B75E6AD17@ipfire.org>
In-Reply-To: <vhkol0$3ugod$2@tuscan4.grantura.co.uk>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5767146034056784783=="
List-Id: <development.lists.ipfire.org>

--===============5767146034056784783==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hello,

> On 20 Nov 2024, at 13:36, Rob Brewer <ipfire-devel(a)grantura.co.uk> wrote:
>=20
> On Tue, 19 Nov 2024 17:10:24 +0000, Michael Tremer wrote:
>=20
> Hi Michael, thank for your response, I was beginning to think there was=20
> little interest in this topic.

I was traveling and so have a little bit of a back log as usual :)

I can=E2=80=99t speak for the others, though.

>=20
> See below...
>=20
>> Hello Rob,
>>=20
>> Good to hear from you again.
>>=20
>>> 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
>>> the Dshield database, however the default IPFire IPTABLES logs are
>>> incomplete since packets dropped by Locationblock are not logged to
>>> syslog.
>>=20
>> This is correct.
>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> I would be happy to provide the necessary patches should this be
>>> acceptable.
>>=20
>> I think a couple of things have changed since we introduced this feature
>> and we have also learned a couple of lessons here:
>>=20
>> * 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.
>>=20
>=20
> IPFire does a very good job in protecting the internal network from=20
> unwanted probes from the WAN, and I agree that for most users, location=20
> block does not enhance this protection.
>=20
> As I run a mail server, I use locationblock as part of my filtering to=20
> prevent bad actors from accessing my mail server and I think would be=20
> useful for anyone who are running servers on their networks.
>=20
> I don't like blocking traffic, but I have witnessed over the last few=20
> years a substantial rise in abuse from certain countries from where I=20
> would never expect to receive emails and locationblock works very well for =

> me in filtering out those unwanted connections.=20
>=20
> I currently have 21 countries blocked including XD Hostile networks. All=20
> of these blocked countries have been seen to support abusive networks.
>=20
> 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=20
> the whole country.

Easy yes. I am just not sure what we are actually getting out of this.

I don=E2=80=99t like to become political on this list and so I won=E2=80=99t,=
 but I know that some people hold the following beliefs:

* There are =E2=80=9Cbad=E2=80=9D countries out there. In the western world t=
hose are Russia, China, and more that fall into this kind of =E2=80=9Ccategor=
y=E2=80=9D. Nothing is going to stop them to open up an account on AWS and su=
ddenly they have access to resources anywhere in the world and so actually, i=
f those players were up to anything =E2=80=9Cbad=E2=80=9D, they can come out =
of any IP space they want. There is also Tor which allows this.

* Looking at actual data, the bullet proof ISPs that annoy us are not that fa=
r away. They are hosted in Europe and very prominently so in the Netherlands =
- a =E2=80=9Cgood=E2=80=9D country.

This is just an example to explain that we all have our idea of the world in =
our head, but the Internet doesn=E2=80=99t know these borders. Geopolitics is=
 complicated and I don=E2=80=99t think that this is a tool that helps to figh=
t this kind of problem. I hope this is clear what I am trying to say.

I personally trust in Spamhaus which is feeding data into our =E2=80=9CHostil=
e Networks=E2=80=9D blocker and they are looking at the actual traffic that t=
hey see from those subnets that they are blocking. They have a clear set of r=
ules and they don=E2=80=99t look just at the country and say =E2=80=9Cah yes,=
 the bad guys again=E2=80=9D.

I have stated this recently in the RPZ discussion that I feel that we are lac=
king good sources for this kind of data. For blocking anything. Loads of peop=
le believe =E2=80=9Cmore is more=E2=80=9D and to be fair=E2=80=A6 once you ge=
t to blocking 90% of the internet you probably have blocked 90% of the noise.=
 However this won=E2=80=99t do anything for targeted attacks. I personally wo=
uld rather have more quality here.

>> * 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.
>>=20
>=20
> I think this is education and I suspect that very few of these people are=20
> running servers on their system and need location block.

I am personally not here to educate people. I am happy to help out and give m=
y opinion, but I suppose considering that people think as I have outlined abo=
ve, who am I to educate them?

It is just very regretful to me when people are ab-using a feature just to =
=E2=80=9Cfeel more safe=E2=80=9D.

>> * 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.
>=20
> I agree and is similar to what I am doing for ports 25 and 587 although=20
> with location block.
>=20
>>=20
>> * 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.
>=20
> For this, I am currently testing a dynamic block list on my system which=20
> adds an entry to an ipset when an ip address exceeds a threshold in the=20
> previous 24 hours. Currently there are about 7000 entries in this set=20
> which have been detected over the previous month.  Not for everyone=20
> because it needs a Whitelist to prevent some 'push' technologies such as=20
> Facebook and to protect from bulk inputs such as mailing lists. I also=20
> blacklist a large number of ip addresses which are associated with port=20
> scanners.
>=20
> This would work well as a botnet filter but it needs an understanding of=20
> the blocking process, so it would not be suitable for everyone.

We have talked about this on the last team call and came to the conclusion th=
at the whole set of blocking features is a total mess. There are several plac=
es where things can be blocked, they all heavily overlap. Not to be going on =
about Spamhaus again, but the DROP list is in the =E2=80=9CHostile Networks=
=E2=80=9D feature, there is a special country code for it, pretty much every =
IPS ruleset contains it, the IP blocklist feature supports it. Now there are =
people throwing this all into DNS as well. I believe this is all getting a li=
ttle bit out of hand.

I personally would prefer *one* place and we really make this work well.

Some people find the IPS has too much overhead - I am beginning to disagree.

Some people add all sorts of blacklists that are clearly for experimental/res=
earch use and suddenly complain about things not working anymore. It is hard =
to figure out what is actually blocking traffic when there are about five pla=
ces to look for. The result often is to disable the IPS, then something else,=
 and after a while all of this is turned off and the firewall is configured t=
o a bare minimum. We don=E2=80=99t want people to run it like that.

>> * Infrastructure is becoming more centralised. Some people attempt to
>> block the US and pretty much nothing works any more. Well=E2=80=A6
>>=20
>=20
> :)
>=20
>> 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.
>=20
> No I think you should keep it. Locationblock is very useful, but needs=20
> to be used in a considered way. I could live without it but its=20
> availability makes my life easier. Also being updated on a weekly basis=20
> makes keeping track of abusers easier.

We issue a new location database once a day, but the IPFire systems update it=
 only once a week. We deemed that as sufficient as there are not that many ch=
anges from one version to another one.

>> 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.
>>=20
>=20
> I have started generating some patches to make 'locationblock logging' as=20
> a selectable feature and could post them here in the next day or so if of=20
> any use.

What would this basically do? Log it as a simple rule for all, or do you incl=
ude the selected country? I think the latter would make more sense.

What is the rationale to turn this off? Why don=E2=80=99t we turn this on for=
 everybody all of the time?

> In fact I think that IPFire's logging environment, which was inherited=20
> from IPCop needs a re-visit.

Yes. But this is probably not a thing I would be looking at in IPFire 2.

I am also happy to think a little bit more outside of the box and see what we=
 would fundamentally change in the future, but not implement in IPFire 2.

> 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=20
> enable kernel messages, like on most current linux systems, to be logged=20
> to alternative log files instead of everything ending up in /var/log/
> messages.

The currentl syslog server could do that. The problem is more that we don=E2=
=80=99t have good tools to view the logs on the web UI. So there is simply on=
e place where most things go into and we will then filter it out when users u=
se the web UI. This is tremendously slow.

> 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=20
> erroneous results in the 'Count' values.

This might be a setting that we can turn off in the current implementation.

We could also think about moving all firewall hits into /var/log/firewall.log=
 or something. That should free up enough in /var/log/messages to make debugg=
ing easier.

>> I would be happy to hear some more opinions on this from the list.
>>=20
>> -Michael
>=20
> I hope these comments are useful and would be pleased to help where I can.

Of course :)

-Michael

>=20
>=20
> Rob



--===============5767146034056784783==--