For some reason, this module is not present after the very first boot of
an IPFire installation.
Fixes: #12767
Reported-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Similar to the Location block, this chain logs and drops all traffic
from and to networks known to pose technical threats to IPFire users.
Doing so in a dedicated chain makes sense for transparency reasons, as
we won't interfer with other firewall rules or the Location block, so it
is always clear why a packet from or to such a network has been dropped.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
There is no legitimate reason why traffic from our own IP address on RED
should ever appear incoming on that interface.
This prevents attackers from impersonating IPFire itself, and is only
cleared/reset if the RED interface is brought up. Therefore, an attacker
cannot bypass this by foring a dial-up or DHCP connection to break down.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Traffic from and to 127.0.0.0/8 must only appear on the loopback
interface, never on any other interface. This ensures offending packets
are logged, and the loopback interface cannot be abused for processing
traffic from and to any other networks.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Inbound Tor traffic conflicts with Location block as inbound connections
have to be accepted from many parts of the world. To solve this,
inbound Tor traffic has to be accepted before jumping into Location block
chain.
Note this affects Tor relay operators only.
Rolled forward as ongoing from
https://patchwork.ipfire.org/project/ipfire/patch/f8ee2e1d-b642-8c63-1f8a-4f24c354cd90@ipfire.org/,
note the documentation in the wiki needs to be updated once this landed
in production.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
In case of faulty connection tracking, this ensures such packets are
logged, to make analysing network incidents less troublesome. Since
NewNotSYN is handled before, where logging can be turned off for systems
running on weak flash devices, the amount of log messages emitted here
should be neglectible.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
NFQUEUE does not let the packet continue where it was processed, but
inserts it back into iptables at the start. That is why we need an
extra IPSBYPASS chain which has the following tasks:
* Make the BYPASS bit permanent for the entire connection
* Clear the REPEAT bit
The latter is more of cosmetic nature so that we can identify packets
that have come from suricata again and those which have bypassed the IPS
straight away.
The IPS_* chain will now only be sent traffic to, when none of the two
relevant bits has been set. Otherwise the packet has already been
processed by suricata in the first pass or suricata has decided to
bypass the connection.
This massively reduces load on the IPS which allows many common
connections (TLS connections with downloads) to bypass the IPS bringing
us back to line speed.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Tested-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This change is necessary because we are using the right-hand two bytes
for storing the QoS classes.
All IPsec traffic will now be skipped and never classified by the QoS.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
In order to use the highest two bits for surciata bypass, we will need
to make sure that whenever we compare any other marks, we do not care
about anything else.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
These include rootfiles, firewall menue entries that have been
unmaintained for a long time, and firewall chains which were never used
in recent time.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
If this module is not being loaded, the kernel will mark any
GRE connection as INVALID in connection tracking, which will
be then silently dropped by a firewall rule.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Due to strange NFQUEUE behaviour, traffic to remote VPN (IPsec or
OpenVPN) destinations was emitted to the internet (ppp0 or red0
interface) directly if the IPS was enabled but crashed during operation.
This patch places the IPSECBLOCK and OVPNBLOCK chains before the
ones responsible for forwarding traffic into the IPS.
Thanks to Michael for his debugging effort.
Partially fixes#12257
Cc: Michael Tremer <michael.tremer@ipfire.org>
Cc: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Allowing outgoing DNS traffic (destination port 53, both TCP
and UDP) to the root servers is BCP for some reasons. First,
RFC 5011 assumes resolvers are able to fetch new trust ancors
from the root servers for a certain time period in order to
do key rollovers.
Second, Unbound shows some side effects if it cannot do trust
anchor signaling (see RFC 8145) or fetch the current trust anchor,
resulting in SERVFAILs for arbitrary requests a few minutes.
There is little security implication of allowing DNS traffic
to the root servers: An attacker might abuse this for exfiltrating
data via DNS queries, but is unable to infiltrate data unless
he gains control over at least one root server instance. If
there is no firewall ruleset in place which prohibits any other
DNS traffic than to chosen DNS servers, this patch will not
have security implications at all.
The second version of this patch does not use unnecessary xargs-
call nor changes anything else not related to this issue.
Fixes#12183
Cc: Michael Tremer <michael.tremer@ipfire.org>
Suggested-by: Horace Michael <horace.michael@gmx.com>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Previous setting was to log 10 packets per minute for each
event logging is turned on. This made debugging much harder,
as the limit was rather strict and chances of dropping a
packet without logging it were good.
This patch changes the log rate limit to 10 packets per
second per event, to avoid DoS attacks against the log file.
I plan to drop log rate limit entirely in future changes,
if a better solution for this attack vector is available.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Cc: Tim FitzGeorge <ipfr@tfitzgeorge.me.uk>
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
When the Captive portal is enabled, the needed firewall rules are applied. But when restarting IPFire,
the rules are not applied because there is no call to do so.
Added call to captivectrl in the initscrip 'firewall'.
Fixes: #12015
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Create and use seperate iptables chain called IPS_INPUT, IPS_FORWARD and IPS_OUTPUT
to be more flexible which kind of traffic should be passed to suricata.
Reference #12062
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
If Tor is operating in relay mode, it has to open a lot of outgoing
TCP connections. These should be separated from any other outgoing
connections, as allowing _all_ outgoing traffic will be unwanted and
risky in most cases.
Thereof, Tor will be running as a dedicated user (see second patch),
allowing usage of user-based IPtables rulesets.
Partially fixes#11779.
Singed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is a more general name for a script that will be extended
soon to do more than just add blocking rules.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When loading the initscript of the firewall the neccessary chains for
the captive portalneed to be created.
Signed-off-by: Alexander Marx <alexander.marx@ipfire.org>
