Add UFW default policy rules with OVAL checks (CIS 3.3.x)

[israel-villar]

Add three new rules for UFW firewall default policies:

• ufw_default_incoming_rule: ensure DEFAULT_INPUT_POLICY is DROP or REJECT in /etc/default/ufw
• ufw_default_outgoing_rule: ensure DEFAULT_OUTPUT_POLICY is DROP or REJECT in /etc/default/ufw
• ufw_disabled_routed: ensure DEFAULT_FORWARD_POLICY is DROP or REJECT in /etc/default/ufw

All three rules use OVAL checks that read /etc/default/ufw directly, avoiding the SCE approach which fails silently when /tmp is mounted noexec (required by CIS 1.1.2.4). Map the new rules to the ufw component.

Description:

• Add three new rules for UFW firewall default policies:
  • ufw_default_incoming_rule: ensure DEFAULT_INPUT_POLICY is DROP
    or REJECT in /etc/default/ufw
  • ufw_default_outgoing_rule: ensure DEFAULT_OUTPUT_POLICY is DROP
    or REJECT in /etc/default/ufw
  • ufw_disabled_routed: ensure DEFAULT_FORWARD_POLICY is DROP or
    REJECT in /etc/default/ufw
• All three rules use OVAL checks that read /etc/default/ufw directly.
• Map the new rules to the ufw component.

Rationale:

• A default deny policy on incoming, outgoing and forwarded connections
  ensures only explicitly allowed traffic is permitted, reducing the
  attack surface.
• SCE scripts fail silently when /tmp is mounted noexec (required by
  CIS 1.1.2.4). The OVAL approach reads the UFW configuration file
  directly and is not affected by mount options.

Review Hints:

• New rule directories under linux_os/guide/system/network/network-ufw/.
• ufw_default_outgoing_rule was created directly with OVAL (no SCE),
  consistent with the OVAL checks added for check_ufw_active,
  ufw_default_incoming_rule and ufw_disabled_routed.
• Build to verify: ./build_product debian13 --datastream-only
• Build ubuntu2404 to verify no regression:
  ./build_product ubuntu2404 --datastream-only

[openshift-ci]

Hi @israel-villar. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.