IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since corosync rules are now only created when a corosync.conf file is
present, a static corosync.conf has been added and will be loaded for
testing.
New test rules have been introduced to check corosync rules relating to
different rings/links.
Includes hostnames in config to trigger resolving codepaths.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
"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>
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.
[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929527
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929976
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
commit 255698f651 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>
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>
this could be confusing, if someone adds code which uses $net->{ip}
it may work for the case were ipfilter is off but not else (which may
not get tested), so keep the original $net intact and copy the scalar
value..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
IPCC has no knowledge about FUSE based links, but we used
'local/host.fw' here, where local is always a link to
'nodes/<LOCAL-NODENAME>/', this works only when using the common file
system interface provided by FUSE, but not if we're talking directly
with our memdb file store through IPCC..
So use a nodename based path here, to avoid getting just empty
strings for host.fw.
fixes commit 0dbef53046
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
increment header and decrement payload size by the extensions size. the
length calculation is different for some extensions. in our case only
IPPROTO_FRAGMENT requires a different size calculation than the rest. in
addition 'proto' is now set in the loop when advancing from an
extension header. it moves on to the next extension or protocol now
instead of looping on the same 'proto' while advancing the payload.
Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
This allows us to profit from the IPCC pmxcfs restart mechanisms,
which will block this call for the grace period (~10 seconds) and
transparently try to reconnect to the IPCC interface of pmxcfs, if a
restart is detected..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
the removed methods where only used by those we merged their code
into.
Opening the FH in the generic parser safes a bit of repetition too..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is part of the project 'stop the parameter rabbit hole madness'
and tries to make reading the firewall code a little bit easier.
Here we remove passing $verbose from 44 method signatures, while it
was used in 4 of those methods, a ration of 1/11 is simply not
acceptable for such a thing as a verbosity flag..
Remove it, and just make it a global variable with a setter for now.
Verbose is not modified in any API call, only in a Service
environment callablle by CLI, so we are save to do so.
If we decide to add some sort of firewall instance (i.e., a blessed
$self "object") with some state we could also move it there, but
making it global now doesn't hurt.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
be more consistent with the buildsystems of our other packages.
compared old to new with diffoscope, no real changes (besides
different SOURCE file, as base check commits differ)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
'ACCEPT' was plain wrong here and broken and disables ALL firewalling
for a Container, at least when used in a Security Group.
fixes 857f62c833
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reported-by: Tom Weber <pve@junkyard.4t2.com>
it does not hurt and can be be used to see high frequeny occurences
of certain rules which hit.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This allows a user to log traffic filtered by a self defined firewall rule.
Therefore the API is extended to include a 'log' option allow to specify the
log level for each rule individually.
The 'log' option can also be specified in the fw config. In order to reduce the
log amount, logging is limited to 1 entry per second.
For now the rule has to be created or edited via the pvesh API call or via the
firewall config in order to set the log level.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
We need the not matching DROP outside the main tapchain,
in a specific proto chain, and a ACCEPT in the main tap chain.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
This implemented arp filtering if ipfilter is enable
https://bugzilla.proxmox.com/show_bug.cgi?id=2125
They are another filters possible (ipv4,rarp),
i don't known if we need them.
Signed-off-by: Alexandre Derumier <aderumier@odiso.com>
For log consistency and parsing, we already have a space after "policy DROP: "
but not REJECT
ex:
DROP
135 6 tap135i1-IN 05/Feb/2019:10:59:55 +0100 policy DROP: IN=.....
REJECT
232 6 tap232i1-IN 05/Feb/2019:10:59:28 +0100 policy REJECT:IN=....
This adds the nf_conntrack_allow_invalid host firewall option to allow to disable
the dropping of invalid packets from the connection tracker point of view.
This is needed for some rare setups with asymmetrical multi-path routing.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>