(GH-1097) Bumping back required puppet version (#1098)
Prior to this commit, due to a mistake, there was a reversion to the
previously implemented bump to minimum required puppet version, which
was part of the CVE update.
This commit aims to address issue 1097 in Github which brings to light
the need for this puppet bump to be restored to 6.24
jordanbreen28 [Tue, 29 Nov 2022 12:28:58 +0000 (12:28 +0000)]
(1093) - Fix unresolved fact error
Prior to this commit, work was carried out on this module to update all instances of the now deprecated Facter::Util::Resolution, and replace all with its newer and supported counterpart Facter::Core::Execution.
However, these do not behave exactly the same. Facter::Util::Resolution initially ran a which to locate the binary before executing, preventing any errors from occuring. The newer Facter::Core::Execution method did not do this, instead it attempted to execut>
This commit aims to introduce an "on_fail:false" flag to each execute statement, so that a failed execute will return false (boolean) as oppose to an error, which can then be used for further logic.
package "iptables" has been replaced by "iptables-nft" on EL9
There are some pointers given by dnf about "iptables", but these confuse
Puppet into aborting with the error message:
```console
Error: /Stage[main]/Firewall::Linux/Package[iptables]: Could not evaluate: no implicit conversion of Array into Hash
```
Fedora had a similar patch in commit 486e4b5779f5069e which I think
fixed the bug https://tickets.puppetlabs.com/browse/MODULES-11147 but
the same issue rared its head here on AlmaLinux 9.0.
The RPM for iptables-legacy states:
> This package contains the legacy tools which are obsoleted by
> nft-variants in iptables-nft package for backwards compatibility reasons.
> If you need to set up firewalls and/or IP masquerading, you should not install
> this package but either nftables or iptables-nft instead.
Prior to this commit, and as part of the codebase hardening project, we
sanitised some commands in the module. However, this sanitisation
method requires that users have at least puppet version 6.24.0 and
onwards to be effective.
This commit aims to resolve that requirement by raising the required
puppet version in the metadata.json file.
Prior to this commit, and after the work perform in CONT-256, there were
a few commands in the module that were not properly sanitised according
to our current standards.
This PR aims to implement some changes that ensure no malformed commands
are passed through to the system. Primarily, the commands targeted were
the ones related to Open3 and exec.
jordanbreen28 [Thu, 13 Oct 2022 12:39:26 +0000 (13:39 +0100)]
(CONT-173) - Updating deprecated facter instances
Prior to this PR, this module contained instances of Facter::Util::Resolution.exec and Facter::Util::Resolution.which, which are deprecated.
This PR aims to replace these exec helpers with their supported Facter::Core::Execution counterparts.
This PR:
Replaced all Facter::Util::Resolution instances with corresponding Facter::Core::Execution exec helpers
The existing code passes `:proto`, which `string_to_port` casts to a
string, gets "proto", compares that to the possibilities "udp" or "tcp",
and when neither, falls back to using "tcp".
This patch passes the actual proto value to the function, in case there is
a UDP specific service in your /etc/services (uncommon, but it happens).
It looks like Puppet will evaluate the properties in declared order,
so I had to move `newproperty(:proto)` up so `@resource[:proto]` was
available in the code for `sport`, `dport` and `port`.
Why confirming that this fix worked as intended it was shown that in fixing the original issue a second one had been uncovered.
This should fix the second one without infringing on the first fix.
Issues have arisen with the --random-fully value on certain RedHat versions.
It seem's as if the logic put in around `--random` and `--random-fully` are no longer working.
This change should resolve the issue and tighten the logic around the `known_boolean` values.
Craig Gumbley [Tue, 22 Feb 2022 12:23:35 +0000 (12:23 +0000)]
(SEC-944) Configurable duplicate behaviour
Here we add a new parameter that determines how the puppet run will
behave if a duplicate system rule is encountered. The default is to
warn and continue.
Craig Gumbley [Tue, 22 Feb 2022 12:33:01 +0000 (12:33 +0000)]
(SEC-944) Identify duplicate system rules
In certain situations it is possible for an unmanaged rule to exist on
the target system that has the same comment as the rule specified in
the manifest.
When this condition is true puppet will ignore the the unmanaged rule
and continue to apply the rule in the manifest. This is because the
firewall module uses the comment field in IPT as it's namevar and
therefore expects it to be a unique identifier. In the case of IPT this
is not true given that you can have multiple rules with the same
comment.
This commit adds a check that will identify system rules that have their
comment field set to the same value as a rule in the manifest. If we
enter a situation where any of the duplicate counts are greater than 1
then we will respond with a configurable action. The behaviour of this
can be configured via the onduplicaterulebehaviour parameter.
Code Review / puppet-modules / puppetlabs-firewall.git / log