From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Proposed firewall initscript changes
Date: Tue, 07 Apr 2020 17:42:37 +0200 [thread overview]
Message-ID: <5fa5b119-114c-04a9-5c0c-0e4fcf20401b@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2601 bytes --]
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 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
@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.
(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).
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 since 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 different colour.
Opinions/objections/comments/...?
Thanks, and best regards,
Peter Müller
next reply other threads:[~2020-04-07 15:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 15:42 Peter Müller [this message]
2020-04-10 14:54 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5fa5b119-114c-04a9-5c0c-0e4fcf20401b@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox