From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Proposed firewall initscript changes
Date: Tue, 07 Apr 2020 17:42:37 +0200
Message-ID: <5fa5b119-114c-04a9-5c0c-0e4fcf20401b@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4989571777903061182=="
List-Id: <development.lists.ipfire.org>

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

Hello *,

in order to improve security and following best current practices, I would
like to propose these changes to the firewall initscript:

(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


(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 r=
elated
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

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

(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, the=
re is
no legitimate reason for packets from RFC 1918 and other special use or priva=
te
space to show up (refer to #12031).

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.

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

I therefore propose to
(c.1) implement a switch on the firewall options page for logging Martians si=
nce some
users will see quite a lot of them
(c.2) implement a switch on the firewall options page that drops traffic from=
 or to
these networks on RED,
(c.3) refer to it on the RED dialin page and
(c.4) update the firewall hit graph code so it shows Martian traffic in a dif=
ferent colour.


Opinions/objections/comments/...?

Thanks, and best regards,
Peter M=C3=BCller


--===============4989571777903061182==--