when firewall switched to bridge mode, we want to
have WebUI access to manage the firewall, allow user
setup IP address on the firewall bridge interface through
the UI.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
add firewall bridge mode so it can be used as
layer 2 inline bridge for either DDoS protection
or firewall filter by iptable rules configured in
netfilter filter table forward chain.
Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
We cannot use the PREROUTING/POSTROUTING chains here because Suricata
will fail to track NAT-ed connections.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is because we might still land in the scenario where Suricata
crashes and NFQUEUE will simply ACCEPT all packets which will terminate
the processing of the mangle table.
Therefore the NFQUEUE rule should be the last one so that we never skip
any of the other processing.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This patch changes that we introduce a new mark which allows us to
identify any newly bypassed connections and permanently store the bypass
flag.
We also only restore marks from the connection tracking when a packet
has no marks, yet.
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This should make the IPS more efficient, we should have fewer rules and
the IPS will now sit at the edge of the networking stack as it will see
packets immediately when they come and and just before they leave.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This enables some DoS protection using SYNPROXY which will complete a
SYN handshake with the client before the connection is being forwarded.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This should never cause any problems, but will cause that certain more
complicated featured like SYNPROXY won't work.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- This v3 version now has two if loops allowing logging of incoming drop hostile or
outgoing drop hostile or both or neither.
- Dependent on the choice in optionsfw.cgi this loop will either log or not log the
dropped hostile traffic.
Fixes: bug12981
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
These rules where created to permit any local traffic to the firewall
when using a PPP connection that utilised Ethernet as transport.
This is however nonsensical and a security issue for any other
connection methods that call the RED interface "red0" and use PPP (e.g.
QMI).
Since PPPoE packets do not flow through iptables, these rules can be
dropped safely. We do not know whether PPTP works at all these days.
Fixes: #13088 - firewall: INPUT accepts all packets when using QMI for dial-in
Tested-by: Stefan Schantl <stefan.schantl@ipfire.org>
Tested-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
They were mistakenly placed after the IPS chains in commit
7b529f5417, but should be placed after the
connection tracking and before the IPS.
Fixes: #12815
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
The current setup can fail and block all traffic on RED if the RETURN
rules could not be created.
This can happen when the kernel fails to load the ipset module, as it is
the case after upgrading to a new kernel. Restarting the firewall will
cause that the system is being cut off the internet.
This design now changes that if those rules cannot be created, the
DROP_HOSTILE feature is just inactive, but it would not disrupt any
traffic.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Daniel Weismüller <daniel.weismueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Bumping across one of our scripts with very long trailing whitespaces, I
thought it might be a good idea to clean these up. Doing so, some
missing or inconsistent licence headers were fixed.
There is no need in shipping all these files en bloc, as their
functionality won't change.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
In theory, logging of dropped packets classified by conntrack as being
INVALID should never be disabled, since one wants to have a paper trail
of what his/her firewall is doing.
However, conntrack seems to drop a lot of (at the first glance
legitimate) packets, hence bloating the logs, making spotting the
important firewall hits more difficult.
This patch therefore adds the option to disable logging of packets being
dropped by conntrack due to INVALID state.
Please note:
- This patch does not add this category to the firewall hits graph.
- The variables in this patch ("LOGDROPCTINVALID") should make it clear
that it is about toggling _logging_, not the actual _dropping_. Other
variables are still in need of being renamed to clarify this, which
will be done in a dedicated patch.
- Also, the changes made to update.sh need to take place in
config/rootfiles/core/164/update.sh for "master", since this patch has
been developed against "next". Kindly cherry-pick the necessary
changes.
Partially fixes: #12778
Reported-by: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
If the firewall is talking to itself using one of its private IP
addresses (e.g. the primary green interface IP address), it will use the
loopback interface.
This is due to the local routing table which will be looked up first:
[root@ipfire ~]# ip rule
0: from all lookup local
128: from all lookup 220
220: from all lookup 220
32765: from all lookup static
32766: from all lookup main
32767: from all lookup default
It contains:
[root@ipfire ~]# ip route show table local
local 8x.1x.1x.1x dev ppp0 proto kernel scope host src 8x.1x.1x.1x
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 192.168.x.1 dev green0 proto kernel scope host src 192.168.x.1
broadcast 192.168.x.255 dev green0 proto kernel scope link src 192.168.x.1
Any lookup for the green IP address will show this:
local 192.168.x.1 dev lo table local src 192.168.x.1 uid 0
cache <local>
A test ping shows this in tcpdump:
[root@ipfire ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:24:22.864293 lo In IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 10420, seq 1, length 64
17:24:22.864422 lo In IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 10420, seq 1, length 64
17:24:29.162021 lo In IP 192.168.x.1 > 192.168.x.1: ICMP echo request, id 1555, seq 1, length 64
17:24:29.162201 lo In IP 192.168.x.1 > 192.168.x.1: ICMP echo reply, id 1555, seq 1, length 64
For this reason, we will have to accept any source and destination IP
address on the loopback interface, which is what this patch does.
We can however, continue to check whether we received any packets with
the loopback address on any other interface.
This regression was introduced in commit a36cd34e.
Fixes: #12776 - New spoofed or martian filter block
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
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>
