Proposal : ADDING networkfirewall_test

[ebouillard]

This publication is made by Sopra Steria France.
The following tests were initially authored by French Ministry of Army (DGA-MI).

The auditdline_test is used to check the living rules of the auditd service.
The networkfirewall_test is used to check the living filtering rules of the network firewall on a UNIX system.

Related issue : #111

[wmunyan]

@ebouillard at a first, quick look, this looks pretty good! One change I'd ask you to make would be to move the specification of the EntityItemPacketDirectionType and EntityItemFilteringActionType out of the unix-definition-schema and into the unix-system-characteristics-schema.

I'll take a deeper look into the elements and functionality as well and hopefully have some more feedback for you soon! Thanks for the proposal!

[solind]

Hi @ebouillard,

I've cursorily examined your submission. First, I would like to thank you for this contribution. We absolutely want and value the input of individuals such as yourself, and welcome these kinds of contributions. The new auditctl-based test looks pretty good to me, and I will try to implement it in the next week or so if possible (which will give me the opportunity to dig much deeper), but the unix:networkfirewall test needs some work.

Placing a test in the Unix schema means it probably applies to FreeBSD, macOS, AIX, Solaris, HP-UX and Linux. Although the problem of querying for firewall rules is certainly generic enough, there is no consistently-available software firewall management mechanism available across all those platforms (at least, not that I am aware of). For example, I know of the iptables command on Linux, but on Solaris packet filtering is implemented in the files /etc/ipf/ipf.conf and /etc/ipf/ipf6.conf, on AIX there is the lsfilt command and on macOS there is the socketfilterfw command (which is altogether quite different from the others). And while these would represent the typical mechanisms for software firewall management on those platforms, I believe there are also others that are available. A typical OVAL test does not consolidate functions with diverse implementations across different platforms, but rather, is tied to a particular utility. The closest approximation to this idea would be the unix:dnscache test, except that in that case, every Unix platform supports essentially the same dig command.

So, I think it would make more sense to define, e.g., a linux:iptables test, an aix:packetfilter test, etc.

Additionally, some of the annotations look to have been copied and pasted, as they refer to auditctl entities. Also as @wmunyan noted, the EntityItemPacketDirectionType and EntityItemFilteringActionType types belong in a system-characteristics schema, not a definitions schema.

[evgenyz]

I would say that splitting these two proposals into two separate issues (and PRs) would be helpful for understanding and fruitful discussion about each of these cases.

I agree with David regarding the firewall test. In Linux, for example, there are at least iptables and nftables. Also there is an ongoing effort to unify firewalling with bpf (https://lwn.net/Articles/747551/).

[ebouillard]

Thanks everyone for your feedback.
I will move the specification of the EntityItemPacketDirectionType and EntityItemFilteringActionType out of the unix-definition-schema and I will into the unix-system-characteristics-schema.

@solind I have a member of my team who is currently working on the implementation of the auditctl-based test. I will ask him to join the discussion if you want to discuss about this implementation.

[gdidot]

Hello, I am currently working on an openscap implementation of auditdline.
We can discuss this implentation if you have any question, or any feedback.

[matejak]

@ebouillard please split the auditdline_* propositions to a separate PR, so we could discuss each proposal separately. David already started with the firewall, so let's keep this one to the firewall.
Audit configuration and runtime checking is a complex subject, and we really appreciate your proposal which aims to make OVAL a better tool to examine this kind of system setting.

[ebouillard]

Hi everyone,

I just created a new issue/PR couple for auditdline_test as requested by @matejak.
If anyone wants to discuss about auditdline_test, please refer to :
#114
#115

[evgenyz]

So, the PR in the OpenSCAP repo (OpenSCAP/openscap#1724) sheds some light on the goals and implementation details that are not present in this proposal.

First of all it is for nftables only, which means that the name should be changed to nft (or nftables) and the affinity of this test should be linux not unix.

The implementation does use popen("nft -j -nn list ruleset", "r"); to dump the runtime configuration in JSON format and then parse it. This approach is appalling for me for multiple reasons. Most important are:

• there are a couple of libraries to work with runtime configuration libnftnl and libmnl, there is no need to dump anything;
• there is the yamlfilecontent test for working with YAML and JSON files (since JSON is a subset of YAML).

Also, the real nft configuration file is not JSON:

table inet dev {
    chain input {
        ct state new tcp dport 443 \
                meter flood size 128000 { ip saddr timeout 10s limit rate over 10/second } \
                add @blackhole { ip saddr timeout 1m }
        ip saddr @blackhole counter drop
    }
}

It would be interesting to have the ability to work with the offline configuration in addition to the test with libnftnl and libmnl. But that again hit the problem of absence of runtime/offline differentiation in OVAL tests.

[adammontville]

@ebouillard can you follow up on this PR so that we may take some action? If we don't reach a resolution within 14 days (we're resetting the consensus period clock), then we'll close this PR.

[ebouillard]

@evgenyz thank you for your feedback.
This test is intended to be generic (the original idea is to retrieve generic firewall informations).
nftable implementation in OpenSCAP PR is just meant to be an quick example.
It could have been implemented with another mechanism such as iptables.
In that way, the test has been authored to be a unix test and not a linux one.

[evgenyz]

@ebouillard Well, iptables is still Linux-only. And it should have a dedicated test for it, at least because there would not be much code shared.

[ebouillard]

@evgenyz Ok so the guideline regarding schema implementation is to make simple tests related to a specific technology like iptable/nftable (just an example), even if the same informations could be retrieved with these two ?

[evgenyz]

@evgenyz Ok so the guideline regarding schema implementation is to make simple tests related to a specific technology like iptable/nftable (just an example), even if the same informations could be retrieved with these two ?

Yep, pretty much. It would make it easier for different scanners to implement tests selectively and also to make these tests as simple as possible.

[ebouillard]

@evgenyz I think we should close this PR. This test is too far from what is currently implemented in OVAL.