Hello,
On 15 Oct 2021, at 10:16, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
Hello,
On 13 Oct 2021, at 17:21, Peter Müller peter.mueller@ipfire.org wrote:
Hello Michael,
thanks for your reply.
Thank you.
Do we want to make this is a more convenient option somewhere in the UI in the future?
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")
Okay. I like this, but in existing setups this will break a lot.
It depends. Perhaps it might be a good idea to split this feature up:
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 addresses on all interfaces.
This might not be as easily enforceable as you want it unless you change fundamental behaviour of the system which might break things.
Martians on RED are different, and I would hesitate from enabling this by default on new installations, since it causes trouble if IPFire is used for internal segmentation (which I guess we have a lot of installations in companies) or behind existing routers, or ISPs doing things like DS-lite.
What do you think of this proposal?
What is the point of this feature then if it isn’t enabled on the interface where it makes the most sense?
Just because this is going to be difficult doesn’t mean we should lose our goal.
I have no idea what to expect from this being a default on new setups.
(b) publicly routable yet unallocated IP networks ("bogons")
I don’t think this would break much and I would be interested to have statistics on this since we would not expect many firewall hits.
Since the location database is updated weekly by default, very new BGP announcements will probably cause hits here. On the other hand, network operators usually do not 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 sending any production traffic.
People who will have issues with this will likely have broken their location database that it won’t update any more.
(c) and IP networks having the LOC_NETWORK_FLAG_DROP flag set on the RED interface.
Mentally I am putting this into the same category as bogons (“I am never going to communicate to this network”).
I can relate to that, but still would make a difference here, in case people do not want their internet access to be filtered by an opinionated source. So, a dedicated switch for this makes sense to me.
I believe this won’t break anything either.
Me neither.
I think it is wise to split this up, since some people might need (a), but 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.
(a) is something we (I) can implement straight away. As soon as this patch has been merged,
(a) will need a lot of exceptions:
- Networks that are locally connected (GREEN, BLUE, ORANGE, RED)
But only on their respective interface, right? GREEN traffic should not appear on BLUE.
Correct.
- All VPNs (OpenVPN, IPsec, H2N and N2N)
- All static routes
- Maybe some SNAT/DNAT rules?
These will have to be auto-generated and not bother the admins.
ACK.
Maybe it would be better to solve this in another way than using iptables.
You are thinking about routing here, aren't you? I like it, but we would have 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 sorry. Just stupid. But of course we can add exemptions.
(c) is no longer an issue, too. (b) is currently blocked due to bug #12691.
We could generally work on this and only release it after #12691 is fixed. It is not a blocker for development. Just for release.
ACK.
Thanks, and best regards, Peter Müller
And of course there will be a blog article about this. \o/
Let’s get this on the list first and then think about that.
-Michael
Thanks, and best regards, Peter Müller
-Michael
Reviewed-by: Michael Tremer michael.tremer@ipfire.org
On 10 Oct 2021, at 18:13, Peter Müller peter.mueller@ipfire.org wrote:
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.
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).
Signed-off-by: Peter Müller peter.mueller@ipfire.org
config/cfgroot/location-functions.pl | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/config/cfgroot/location-functions.pl b/config/cfgroot/location-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 info@ipfire.org # +# Copyright (C) 2007-2021 IPFire Team info@ipfire.org # # # # 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 = ( "A1" => "Anonymous Proxy", "A2" => "Satellite Provider", "A3" => "Worldwide Anycast Instance",
- "XD" => "Hostile networks safe to drop",
);
# Hash which contains possible network flags and their mapped location codes. @@ -36,10 +37,11 @@ my %network_flags = ( "LOC_NETWORK_FLAG_ANONYMOUS_PROXY" => "A1", "LOC_NETWORK_FLAG_SATELLITE_PROVIDER" => "A2", "LOC_NETWORK_FLAG_ANYCAST" => "A3",
- "LOC_NETWORK_FLAG_DROP" => "XD",
);
# Array which contains special country codes. -my @special_locations = ( "A1", "A2", "A3" ); +my @special_locations = ( "A1", "A2", "A3", "XD" );
# Directory where the libloc database and keyfile lives. our $location_dir = "/var/lib/location/"; -- 2.26.2