we only ever add rules to the filter table, without this we'd add all
rules from other tables (which might have been manually filled by the
admin) to the filter table as well - adding another copy on every
iteration of the firewall update cycle!
note that ebtables-restore seems to flush tables contained in its input,
but leave those alone which are not referenced at all.
The former is simply new and we can control it, so do so instead of
ignoring it, if it seems worth while we can also expose that as
option or do some fancier auto calculation, maybe depending on ipset
size.
The u32 `initval` is a bit different, its not a config in the exact
traditional sense but would allow to recreate an bit to bit
indentical save/restore - but we do not really do that and we cannot
pre-calculate that our self (or at least I'd rather like to avoid
doing that from perl).. So, ignore it actively for now to avoid
false-postivie detection in pending changes.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
fix #2721: remove reject tcp 43 from default drop and reject actions
first, '43' is a typo, it should say '113' (if it really is like
legacy shorewall [0]). this tcp port corresponds to the ident or
authentication service protocol.
second, nowdays this reject is not included in shorewall anymore.
furthermore it would make no sense to reject specifically this
one port.
Stoiko Ivanov [Wed, 26 May 2021 14:51:59 +0000 (16:51 +0200)]
set sysctls on every apply
setting the sysctls needed on every run should not be too costly
(the original implementation used a `system` invocation, which was
far more expensive), and reduce the chances for side-effects.
Thomas Lamprecht [Mon, 24 May 2021 09:15:50 +0000 (11:15 +0200)]
d/rules: cleanup systemd overrides
both, `override_dh_systemd_enable` and `override_dh_systemd_start`
are ignored with current compat level 12, and will become an error in
level >= 13, so drop them and use `override_dh_installsystemd` for
both of the previous uses.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
iptables-restore has a buffer limit of 1024 for paramters [0].
If users end up adding a long list of IPs in the source or dest field
they might reach this limit. The result is that the rule will not be
applied and pve-firewall will show some error in the syslog which will
be "hidden" for most users.
Enforcing a smaller limit ourselves should help to avoid any such
situation. 512 characters should help to not run into any problems that
stem from differences in what counts as character. If people need longer
lists, using IP sets are the better approach anyway.
Mira Limbeck [Mon, 22 Feb 2021 12:00:18 +0000 (13:00 +0100)]
fix #2358: allow --<opt> in firewall rule config files
The docs mention --<opt> as valid syntax for firewall rules, but the
code that parses the .fw files only accepts -<opt>. To make it
consistent with the docs and the API, also accept --<opt>.
In addition allow 'proto' as option, not only '-p'.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Mira Limbeck [Fri, 29 May 2020 12:22:04 +0000 (14:22 +0200)]
introduce new icmp-type parameter
Currently icmp types are handled via 'dport'. This is not documented
anywhere except for a single line of comment in the code. To untangle
the icmp-type handling from the dport handling a new 'icmp-type'
parameter is introduced.
The valid 'icmp-type' values are limited to the names
(icmp[v6]_type_names hash in the code, same as ip[6]tables provides).
Type[/Code] values are not supported.
Support for ipv6-icmp is added to icmp-type parameter handling. This makes it
possible to specify icmpv6 types via the GUI.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Stoiko Ivanov [Tue, 2 Jun 2020 08:06:17 +0000 (10:06 +0200)]
fix #2773: ebtables: keep policy of custom chains
currently all ebtalbes chains are created with a hardcoded policy of ACCEPT.
This patch changes the functionality to store the configured policy of a
chain while reading the 'ebtables-save' output and uses this policy when
creating the command list.
This is only relevant for ebtablers chains not generated by pve-firewall (the
ones having an action of 'ignore' in the status-hash).
Reported on the pve-user list:
https://pve.proxmox.com/pipermail/pve-user/2020-May/171731.html
Minimally tested with the example from the thread.
Mira Limbeck [Wed, 29 Apr 2020 13:45:24 +0000 (15:45 +0200)]
fix wrong icmpv6 types
This removes icmpv6-type 'any' as it is not supported by ip6tables. Also
introduced new icmpv6 types 'beyond-scope', 'failed-policy' and
'reject-route'. These values were taken from 'ip6tables -p icmpv6 -h'.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Mira Limbeck [Wed, 29 Apr 2020 13:45:23 +0000 (15:45 +0200)]
fix iptables-restore failing if icmp-type value > 255
This has to be done in both icmp and icmpv6 cases. Currently if
'ipv6-icmp' is set via the GUI ('icmpv6' is not available there) there
is no icmp-type handling. As this is meant to fix the iptables-restore
failure if an icmp-type > 255 is specified, no ipv6-icmp handling is
introduced.
These error messages are not logged as warnings are ignored. To get
these messages you have to run pve-firewall compile and look at the
output.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
api/ipsets: parse_cidr before checking for duplicates
for example, the config parser drops a trailing /32 for IPv4, so we
should do the same here. otherwise we can have one entry for $IP and
one for $IP/32 with different properties until the next R-M-W cycle
drops one of them again.
Mira Limbeck [Thu, 30 Apr 2020 10:26:41 +0000 (12:26 +0200)]
fix #2686: don't add arp-ip-src filter for dhcp
When the IPFilter setting is enabled and the container has DHCP
configured on an interface no 'arp-ip-src' filter should be added as we
don't have an IP address.
Previously '--arp-ip-src dhcp' was passed to ebtables which led to an error.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
api node: always pass cluster conf to node FW parser
As else the parsing may lead to "false positive" errors, as cluster
wide aliases and other definitions are seemingly missing.
Reproducer:
* add *cluster* alias
* add+enable *host* rule using that alias
* enable FW on DC and node level
* go to Node -> FW -> Options
* check journal/syslog for error like:
> pveproxy[1339680]: /etc/pve/nodes/dev6/host.fw (line 3) - errors in rule parameters: IN ACCEPT -source test123 -p tcp -sport 22 -log nolog
> pveproxy[1339680]: source: no such alias 'test123'
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Currently, a virtio-net + vhost-net can handle between 200-300 kpps for each vm (with 1core/queue=1).
That mean than a vm can easily overloaded with a simple synflood (hping3 --flood -p 80 -S targetip).
Also the conntrack of the host can be saturated easily.
This patch introduce a new option, enable rate limiting of syn/s by src ip (protection_synflood:1).
rate limit can be set with : protection_synflood_rate (default 200 syn/s)
with an extra burst: protection_synflood_rate (default 1000).
It's also possible to reduce conntrack syn timeout: nf_conntrack_tcp_timeout_syn_recv (default 60).
with default values, a src ip can take around (60 * 200 = 12000 conntrack entries).
The iptables rules are done in raw table, before reaching the conntrack.
This protection works fine for non-spoofed src ip.
For spoofed src ip, the only way could be to implement SYNPROXY,
but this only works for routed/nat setup. (The host need to be able to reply
with the src ip the vm)
Some good information about synflood protections
https://2014.rmll.info/slides/356/day_1-1400-Jesper_Brouer-DDoS_protection_using_Netfilter_iptables.pdf
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Thomas Lamprecht [Tue, 22 Oct 2019 09:08:18 +0000 (11:08 +0200)]
increase default nf_conntrack_max to kernel default
for nf_conntrack_max the kernel uses by default the value:
(nf_conntrack_buckets value * 4) and nf_conntrack_buckets
is set to 2^16 for machines with more than 4GB memory, so the
resulting default would be 2^18 == 262144.
As PVE hoists are expected to have more than such a, nowadays rather
small, amount of memory, update the default to match the one which
would be normally used anyway.
Mira Limbeck [Tue, 6 Aug 2019 08:25:14 +0000 (10:25 +0200)]
only add VM chains if VM firewall is enabled
Before if a NIC had the firewall enabled and the MAC filter was active,
a rule was added to the tap device even if the VM firewall was not
enabled. This led to nested machines not being able to reach outside.
Testcase: Host <-> VM <-> CT all on the same bridge. Host and CT could
not reach each other because of the MAC filter.
Now we check if the VM firewall is enabled and only add the MAC and
IP filters then.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
Stefan Reiter [Wed, 3 Jul 2019 12:27:33 +0000 (14:27 +0200)]
Check if corosync.conf exists before calling parser
Calling cfs_read_file with no corosync.conf (i.e. on a standalone node)
returns {} instead of undef. The previous patches assumes undef for this
scenario. To avoid confusing checks all over the place, simply leave the
config as undef if no file exists.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Stefan Reiter [Mon, 1 Jul 2019 15:22:15 +0000 (17:22 +0200)]
Create corosync firewall rules independently of localnet
"localnet" does not necessarily correspond to the correct network for
corosync (e.g. corosync rings/link can be run independently from other PVE
cluster service networks).
This change uses the previously introduced sub 'for_all_corosync_addresses'
to iterate through all nodes in a corosync cluster and generate rules for
all nodes and all their respective ringX_addr's it finds.
The rules are generated as strict as possible, there is a specific rule
for every remote node and every ring/link. Also, communication "between"
different links/rings is not allowed, e.g. a remote ring1_addr cannot
contact a local ring0_addr, and vice versa.
Multicast is always allowed, for backwards compatibility. Note however,
that we no longer filter on the source of inbound multicast packets,
since that would require localnet, and thus introduce the bug we're
trying to fix once again.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
Thomas Lamprecht [Mon, 24 Jun 2019 18:36:09 +0000 (20:36 +0200)]
pve-firewall.service: update-alternative ip-/eb- tables to legacy versions
This is rather a bit of an hack but works for us for now.
we need to use the legacy versions for both due some bugs in the
nftables based versions, i.e., for iptables it's Debian bug #929527 [0]
and for ebtables it's Debian bug #929976 [1]. While the first gained
some response from the maintainer and a solution is in sight it's
currently blocked by Buster release freeze policy. The second one did
not get any response so far.
Thomas Lamprecht [Tue, 28 May 2019 06:06:39 +0000 (08:06 +0200)]
fix CT rule generation with ipfilter set
commit 255698f65192e736708f123d380bbed2aa8c3eac tried to prevent an
error from happening but wasn't to well thought out, perl's operator
precedence was overlooked.
The commit resulted effectively in:
if (my $ip = ($net->{ip} && $vmfw_conf->{options}->{ipfilter})) ...
But intended was:
if (defined(my $ip = $net->{ip}) && $vmfw_conf->{options}->{ipfilter}) ...
First one makes $ip always boolean true (1 in perl) if the if branch
is hit, and the seconds really has then the $ip value in it..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Christian Ebner [Wed, 15 May 2019 15:09:13 +0000 (17:09 +0200)]
Remove redundant logging of packets passing the tap chain.
Incomming and outgoing packets passing the firewall bridge were unneccessarily
logged, leading to double entries.
The first log entry occurred when passing the bridge, the second when the packets
fate was decided (ACCEPT/DROP/REJECT).
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>