From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] location-functions.pl: Recognise XD / LOC_NETWORK_FLAG_DROP Date: Fri, 15 Oct 2021 15:49:56 +0100 Message-ID: <11B33E43-95BE-46D5-BC5E-C83B52A2F71E@ipfire.org> In-Reply-To: <2f53321a-079f-7371-7a36-3ee9961c5221@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4408743060355488928==" List-Id: --===============4408743060355488928== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 15 Oct 2021, at 10:16, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, >=20 >> Hello, >>=20 >>> On 13 Oct 2021, at 17:21, Peter M=C3=BCller = wrote: >>>=20 >>> Hello Michael, >>>=20 >>> thanks for your reply. >>>=20 >>>> Thank you. >>>>=20 >>>> Do we want to make this is a more convenient option somewhere in the UI = in the future? >>>=20 >>> Yes. My imagination of bug #12031 is to have three new checkboxes on the = firewall options CGI >>> to drop all traffic from and to >>> (a) IP networks not being globally routable ("martians") >>=20 >> Okay. I like this, but in existing setups this will break a lot. >=20 > It depends. Perhaps it might be a good idea to split this feature up: >=20 > Martians belonging to networks used by IPFire (GREEN, BLUE, ORANGE, etc.), = yet arriving > on different interfaces, are spoofing attempts. Dropping these should cause= relatively little > harm, unless users run completely crappy setups. Static routes? The firewall also responds with ARP replies for all its IP add= resses on all interfaces. This might not be as easily enforceable as you want it unless you change fund= amental behaviour of the system which might break things. > Martians on RED are different, and I would hesitate from enabling this by d= efault on new > installations, since it causes trouble if IPFire is used for internal segme= ntation (which > I guess we have a lot of installations in companies) or behind existing rou= ters, or ISPs > doing things like DS-lite. >=20 > What do you think of this proposal? What is the point of this feature then if it isn=E2=80=99t enabled on the int= erface where it makes the most sense? Just because this is going to be difficult doesn=E2=80=99t mean we should los= e our goal. >=20 >> I have no idea what to expect from this being a default on new setups. >>=20 >>> (b) publicly routable yet unallocated IP networks ("bogons") >>=20 >> I don=E2=80=99t think this would break much and I would be interested to h= ave statistics on this since we would not expect many firewall hits. >=20 > Since the location database is updated weekly by default, very new BGP anno= uncements will > probably cause hits here. On the other hand, network operators usually do n= ot set up their > AS and expect to gain a lot of traffic an hour after. No, it is a well-known practise to announce prefixes for a while before sendi= ng any production traffic. >> People who will have issues with this will likely have broken their locati= on database that it won=E2=80=99t update any more. >>=20 >>> (c) and IP networks having the LOC_NETWORK_FLAG_DROP flag set >>> on the RED interface. >>=20 >> Mentally I am putting this into the same category as bogons (=E2=80=9CI am= never going to communicate to this network=E2=80=9D). >=20 > I can relate to that, but still would make a difference here, in case peopl= e do not want > their internet access to be filtered by an opinionated source. So, a dedica= ted switch for > this makes sense to me. >=20 >> I believe this won=E2=80=99t break anything either. >=20 > Me neither. >=20 >>=20 >>> I think it is wise to split this up, since some people might need (a), bu= t not (b) - Arne >>> told me yesterday some mobile ISPs use public IP space internally -, and = might not want >>> to enable (c) for whatever reason. One size never fits all. >>=20 >>> (a) is something we (I) can implement straight away. As soon as this patc= h has been merged, >>=20 >>=20 >> (a) will need a lot of exceptions: >>=20 >> * Networks that are locally connected (GREEN, BLUE, ORANGE, RED) >=20 > But only on their respective interface, right? GREEN traffic should not app= ear on BLUE. Correct. >> * All VPNs (OpenVPN, IPsec, H2N and N2N) >> * All static routes >> * Maybe some SNAT/DNAT rules? >>=20 >> These will have to be auto-generated and not bother the admins. >=20 > ACK. >=20 >> Maybe it would be better to solve this in another way than using iptables. >=20 > You are thinking about routing here, aren't you? I like it, but we would ha= ve no logging > possibility then, which makes troubleshooting tedious. tcpdump will be your friend. >> (b) If ISPs use unallocated address space they are on their own. I am sorr= y. Just stupid. But of course we can add exemptions. >>=20 >>> (c) is no longer an issue, too. (b) is currently blocked due to bug #1269= 1. >>=20 >> We could generally work on this and only release it after #12691 is fixed.= It is not a blocker for development. Just for release. >=20 > ACK. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >>=20 >>> And of course there will be a blog article about this. \o/ >>=20 >> Let=E2=80=99s get this on the list first and then think about that. >>=20 >> -Michael >>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller >>>=20 >>>>=20 >>>> -Michael >>>>=20 >>>> Reviewed-by: Michael Tremer >>>>=20 >>>>> On 10 Oct 2021, at 18:13, Peter M=C3=BCller wrote: >>>>>=20 >>>>> This enables creating firewall rules using the special country code "XD" >>>>> for hostile networks safe to drop and ipinfo.cgi to display a meaningful >>>>> text for IP addresses having this flag set. >>>>>=20 >>>>> At the moment, the "LOC_NETWORK_FLAG_DROP" is not yet populated, but >>>>> will be in the future (as soon as libloc 0.9.9 is released and running >>>>> in production). >>>>>=20 >>>>> Signed-off-by: Peter M=C3=BCller >>>>> --- >>>>> config/cfgroot/location-functions.pl | 6 ++++-- >>>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>>>>=20 >>>>> diff --git a/config/cfgroot/location-functions.pl b/config/cfgroot/loca= tion-functions.pl >>>>> index fb97eb589..4d44ce24d 100644 >>>>> --- a/config/cfgroot/location-functions.pl >>>>> +++ b/config/cfgroot/location-functions.pl >>>>> @@ -2,7 +2,7 @@ >>>>> #######################################################################= ######## >>>>> # = # >>>>> # IPFire.org - A linux based firewall = # >>>>> -# Copyright (C) 2007-2020 IPFire Team = # >>>>> +# Copyright (C) 2007-2021 IPFire Team = # >>>>> # = # >>>>> # This program is free software: you can redistribute it and/or modify = # >>>>> # it under the terms of the GNU General Public License as published by = # >>>>> @@ -29,6 +29,7 @@ my %not_iso_3166_location =3D ( >>>>> "A1" =3D> "Anonymous Proxy", >>>>> "A2" =3D> "Satellite Provider", >>>>> "A3" =3D> "Worldwide Anycast Instance", >>>>> + "XD" =3D> "Hostile networks safe to drop", >>>>> ); >>>>>=20 >>>>> # Hash which contains possible network flags and their mapped location = codes. >>>>> @@ -36,10 +37,11 @@ my %network_flags =3D ( >>>>> "LOC_NETWORK_FLAG_ANONYMOUS_PROXY" =3D> "A1", >>>>> "LOC_NETWORK_FLAG_SATELLITE_PROVIDER" =3D> "A2", >>>>> "LOC_NETWORK_FLAG_ANYCAST" =3D> "A3", >>>>> + "LOC_NETWORK_FLAG_DROP" =3D> "XD", >>>>> ); >>>>>=20 >>>>> # Array which contains special country codes. >>>>> -my @special_locations =3D ( "A1", "A2", "A3" ); >>>>> +my @special_locations =3D ( "A1", "A2", "A3", "XD" ); >>>>>=20 >>>>> # Directory where the libloc database and keyfile lives. >>>>> our $location_dir =3D "/var/lib/location/"; >>>>> --=20 >>>>> 2.26.2 --===============4408743060355488928==--