Audit ipset changes?

Audit ipset changes?

[Andreas Hasenack]

[-- Attachment #1.1: Type: text/plain, Size: 277 bytes --]

Hi,

is there a way to audit ipset changes?

The closest I got was to log the specific "socket(AF_NETLINK, SOCK_RAW,
NETLINK_NETFILTER)" call that ipset makes, but that obviously also triggers
read-only operations like "ipset list", and any other app that opens suck a
socket.

[-- Attachment #1.2: Type: text/html, Size: 669 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Audit ipset changes?

[Richard Guy Briggs]

On 2021-02-26 15:21, Andreas Hasenack wrote:
> Hi,

Hi Andreas,

> is there a way to audit ipset changes?
> 
> The closest I got was to log the specific "socket(AF_NETLINK, SOCK_RAW,
> NETLINK_NETFILTER)" call that ipset makes, but that obviously also triggers
> read-only operations like "ipset list", and any other app that opens suck a
> socket.

Issue ghak124 (https://github.com/linux-audit/audit-kernel/issues/124)
introduced auditing for nftables modifications.  It turns out it was far
too verbose but may have listed these actions for the iptables-nft
variant.  That is about to be trimmed but should still catch any
changes for nftables.

What parameters do you wish to have logged?  At a quick look, I'm
guessing table doesn't make sense since a set could be used by any
registered table?  But the set name would, followed by protocol family,
number of items changed, and the operation name?

How much life does iptables have to it?  Given that this command can
change the configuration of iptables (and ipv6tables, ebtables,...) it
would seem this this should be logged.

Steve?


- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

Re: Audit ipset changes?

[Andreas Hasenack]

[-- Attachment #1.1: Type: text/plain, Size: 1653 bytes --]

Hello,

On Sat, Feb 27, 2021 at 6:19 PM Richard Guy Briggs <rgb@redhat.com> wrote:

> On 2021-02-26 15:21, Andreas Hasenack wrote:
> Issue ghak124 (https://github.com/linux-audit/audit-kernel/issues/124)
> introduced auditing for nftables modifications.  It turns out it was far
> too verbose but may have listed these actions for the iptables-nft
> variant.  That is about to be trimmed but should still catch any
> changes for nftables.
>
> What parameters do you wish to have logged?  At a quick look, I'm
> guessing table doesn't make sense since a set could be used by any
> registered table?  But the set name would, followed by protocol family,
> number of items changed, and the operation name?
>

I'm not sure if there are regulatory requirements about what has to be
logged in this case, but yeah, what caught my eye is that a firewall rule
can effectively be changed by just changing the ipset it references, and
that change didn't trigger a NETFILTER_CFG audit message. This is with
iptables, not nftables. I don't know if it's handled differently with
nftables.

>
> How much life does iptables have to it?  Given that this command can
>

You mean for how long will people still be using iptables? I'm not sure,
but I personally bet in a few more years.



> change the configuration of iptables (and ipv6tables, ebtables,...) it
> would seem this this should be logged.
>

That was my thinking, but I thought about a log of its own, not part of
iptables. To be honest I haven't checked yet what changes in NETFILTER_CFG
with nftables, if anything. I know custom rules catching setsockopt won't
catch nftables changes, but that's about it.

[-- Attachment #1.2: Type: text/html, Size: 2777 bytes --]

[-- Attachment #2: Type: text/plain, Size: 106 bytes --]

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit