On Thu, Feb 11, 2021 at 10:16 AM Phil Sutter <phil(a)nwl.cc> wrote:
Hi,
On Thu, Jun 04, 2020 at 09:20:49AM -0400, Richard Guy Briggs wrote:
> iptables, ip6tables, arptables and ebtables table registration,
> replacement and unregistration configuration events are logged for the
> native (legacy) iptables setsockopt api, but not for the
> nftables netlink api which is used by the nft-variant of iptables in
> addition to nftables itself.
>
> Add calls to log the configuration actions in the nftables netlink api.
As discussed offline already, these audit notifications are pretty hefty
performance-wise. In an internal report, 300% restore time of a ruleset
containing 70k set elements is measured.
If you're going to reference offline/off-list discussions in a post to
a public list, perhaps the original discussion shouldn't have been
off-list ;) If you don't involve us in the discussion, we have to
waste a lot of time getting caught up.
If I'm not mistaken, iptables emits a single audit log per table,
ipset
doesn't support audit at all. So I wonder how much audit logging is
required at all (for certification or whatever reason). How much
granularity is desired?
That's a question for the people who track these certification
requirements, which is thankfully not me at the moment. Unless
somebody else wants to speak up, Steve Grubb is probably the only
person who tracks that sort of stuff and comments here.
I believe the netfilter auditing was mostly a nice-to-have bit of
functionality to help add to the completeness of the audit logs, but I
could very easily be mistaken. Richard put together those patches, he
can probably provide the background/motivation for the effort.
I personally would notify once per transaction. This is easy and
quick.
Once per table or chain should be acceptable, as well. At the very
least, we should not have to notify once per each element. This is the
last resort of fast ruleset adjustments. If we lose it, people are
better off with ipset IMHO.
Unlike nft monitor, auditd is not designed to be disabled "at will". So
turning it off for performance-critical workloads is no option.
Patches are always welcome, but it might be wise to get to the bottom
of the certification requirements first.
--
paul moore
www.paul-moore.com