Re: Proposed firewall initscript changes

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3958 bytes --]

Hi,

> On 7 Apr 2020, at 16:42, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> in order to improve security and following best current practices, I would
> like to propose these changes to the firewall initscript:

Okay, let’s go through them one by one...

> 
> (a) Accept packets on lo interface only if source and destinations are within 127.0.0.0/8
> As far as I am concerned, no other traffic should every appear on the loopback
> interface, which is why I consider dropping it to be a safe measure.
> 
> This would probably look like:
> 
>> iptables -A LOOPBACK -o lo -s 127.0.0.0/8 -d 127.0.0.0/8 -j ACCEPT

Yes, you can do that. There should be no change here.

Do you want to add rules that immediately drop everything else or let this go through the remaining ruleset?

> (b) Do not limit conntrack RELATED rule to ICMP
> Provided the conntrack people know what they are doing (if they were not, we'd have
> bigger problems anyway :-) ), I do not think limiting conntrack RELATED rule to
> ICMP traffic only makes sense: If conntrack decides a TCP/UDP/... packet is related
> to a connection already established, it has a good reason to do so.
> 
> This would probably look like:
> 
>> iptables -A CONNTRACK -m conntrack --ctstate RELATED -j ACCEPT

I do not really see what else would match here except ICMP.

The helpers for other protocols will match RELATED further below.

The reason why we filter for ICMP here is only performance so that we won’t do a conntrack table lookup for a connection we are not very likely to find in there.

> @Jonatan, Arne, Michael: Perhaps this also allows us to filter DHCP traffic less insecure.
> https://serverfault.com/questions/191390/iptables-and-dhcp-questions/810655#810655
> might be of interest, but unfortunately I am unable to test it against my ISP.

I do not expect the connection tracking to handle this, but I am happy to be proven wrong.

> (A few days ago I bumped into https://blog.cloudflare.com/conntrack-tales-one-thousand-and-one-flows/,
> which might be interesting as well.)
> 
> 
> (c) Introduce "Martians" and block them on RED
> If an IPFire machine obtained a public IPv4 address on its RED interface, there is
> no legitimate reason for packets from RFC 1918 and other special use or private
> space to show up (refer to #12031).

Agreed.

> These are called "Martians" (proposal for the German translation: "Marsianer"). Since
> some systems will have private IP addresses in use for RED, we cannot enable this
> feature by default, but suggest it for PPPoE dialin and similar.

Definitely not!

> To my knowledge, these IP networks are Martians:
> 
> 0.0.0.0/8
> 10.0.0.0/8
> 100.64.0.0/10
> 127.0.0.0/8
> 169.254.0.0/16
> 172.16.0.0/12
> 192.0.0.0/24
> 192.0.2.0/24
> 192.168.0.0/16
> 198.18.0.0/15
> 198.51.100.0/24
> 203.0.113.0/24
> 224.0.0.0/4
> 240.0.0.0/4

Multicast probably should not be in here because of IPTV applications.

> I therefore propose to
> (c.1) implement a switch on the firewall options page for logging Martians since some
> users will see quite a lot of them

I think this will be helpful to find any network issues. You simply should not see those packets on a public link.

> (c.2) implement a switch on the firewall options page that drops traffic from or to
> these networks on RED,

Yes. I would only log when this is enabled. What is the point on logging these by default?

> (c.3) refer to it on the RED dialin page and

Why?

> (c.4) update the firewall hit graph code so it shows Martian traffic in a different colour.

Okay. But it might be difficult to make the message clear.

And I suppose that plenty of sh*t ISPs will have loads of those packets going on, so that it will be very noisy.

Best,
-Michael

> 
> 
> Opinions/objections/comments/...?
> 
> Thanks, and best regards,
> Peter Müller
>