From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Proposed firewall initscript changes Date: Fri, 10 Apr 2020 15:54:35 +0100 Message-ID: In-Reply-To: <5fa5b119-114c-04a9-5c0c-0e4fcf20401b@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3861344016212020522==" List-Id: --===============3861344016212020522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 7 Apr 2020, at 16:42, Peter M=C3=BCller wro= te: >=20 > Hello *, >=20 > in order to improve security and following best current practices, I would > like to propose these changes to the firewall initscript: Okay, let=E2=80=99s go through them one by one... >=20 > (a) Accept packets on lo interface only if source and destinations are with= in 127.0.0.0/8 > As far as I am concerned, no other traffic should every appear on the loopb= ack > interface, which is why I consider dropping it to be a safe measure. >=20 > This would probably look like: >=20 >> 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, w= e'd have > bigger problems anyway :-) ), I do not think limiting conntrack RELATED rul= e 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. >=20 > This would probably look like: >=20 >> 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=E2= =80=99t do a conntrack table lookup for a connection we are not very likely t= o 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 I= SP. 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-o= ne-thousand-and-one-flows/, > which might be interesting as well.) >=20 >=20 > (c) Introduce "Martians" and block them on RED > If an IPFire machine obtained a public IPv4 address on its RED interface, t= here is > no legitimate reason for packets from RFC 1918 and other special use or pri= vate > space to show up (refer to #12031). Agreed. > These are called "Martians" (proposal for the German translation: "Marsiane= r"). Since > some systems will have private IP addresses in use for RED, we cannot enabl= e this > feature by default, but suggest it for PPPoE dialin and similar. Definitely not! > To my knowledge, these IP networks are Martians: >=20 > 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 no= t see those packets on a public link. > (c.2) implement a switch on the firewall options page that drops traffic fr= om or to > these networks on RED, Yes. I would only log when this is enabled. What is the point on logging thes= e 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 d= ifferent 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 >=20 >=20 > Opinions/objections/comments/...? >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 --===============3861344016212020522==--