From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Logging Locationblock packets Date: Wed, 20 Nov 2024 15:21:28 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5767146034056784783==" List-Id: --===============5767146034056784783== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 20 Nov 2024, at 13:36, Rob Brewer 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 >>> 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==--