* [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
@ 2020-02-05 14:14 ѽ҉ᶬḳ℠
2020-02-05 14:29 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-05 14:14 UTC (permalink / raw)
To: netfilter
Having perused the WIKI [1] I tried to get protocol specific logging
going, but ended up with
* tcp log -> Error: syntax error, unexpected log
* icmpv6 log -> Error: syntax error, unexpected log
Only with an explicit protocol statement logging works
* ip protocol tcp log
* ip6 nexthdr icmpv6 log
Is that to be expected, in lieu of such mention the WIKI? Or is
something missing in the kernel settings?
lsmod | grep log
nf_log_common 16384 2 nf_log_ipv4,nf_log_ipv6
nf_log_ipv4 16384 5
nf_log_ipv6 16384 5
nf_tables 98304135
nft_fib_inet,nf_flow_table_ipv6,nf_flow_table_ipv4,nf_flow_table_inet,nft_reject_ipv6,nft_reject_ipv4,nft_reject_inet,nft_reject_bridge,nft_reject,nft_redir_ipv6,nft_redir_ipv4,nft_redir,nft_quota,nft_numgen,nft_nat,nft_masq_ipv6,nft_masq_ipv4,nft_masq,nft_log,nft_limit,nft_fwd_netdev,nft_flow_offload,nft_fib_ipv6,nft_fib_ipv4,nft_fib,nft_dup_netdev,nft_ct,nft_counter,nft_chain_route_ipv6,nft_chain_route_ipv4,nft_chain_nat_ipv6,nft_chain_nat_ipv4
nfnetlink 16384 4
nfnetlink_log,nf_tables,nf_conntrack_netlink,ip_set
nfnetlink_log 20480 0
nft_log 16384 1
cat /proc/net/netfilter/nf_log
0 NONE (nfnetlink_log)
1 NONE (nfnetlink_log)
2 nf_log_ipv4 (nf_log_ipv4,nfnetlink_log)
3 NONE (nfnetlink_log)
4 NONE (nfnetlink_log)
5 NONE (nfnetlink_log)
6 NONE (nfnetlink_log)
7 NONE (nfnetlink_log)
8 NONE (nfnetlink_log)
9 NONE (nfnetlink_log)
10 nf_log_ipv6 (nf_log_ipv6,nfnetlink_log)
11 NONE (nfnetlink_log)
12 NONE (nfnetlink_log)
Tried with
echo "nf_log_icmp" > /proc/sys/net/netfilter/nf_log/1
but that produces
ash: write error: No such file or directory
despite
stat /proc/sys/net/netfilter/nf_log/1
File: /proc/sys/net/netfilter/nf_log/1
Size: 0 Blocks: 0 IO Block: 1024 regular empty
file
Device: 4h/4d Inode: 260702 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
___
[1] https://wiki.nftables.org/wiki-nftables/index.php/Logging_traffic
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 14:14 [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement? ѽ҉ᶬḳ℠
@ 2020-02-05 14:29 ` Florian Westphal
2020-02-05 14:45 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2020-02-05 14:29 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: netfilter
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> Having perused the WIKI [1] I tried to get protocol specific logging going,
> but ended up with
>
> * tcp log -> Error: syntax error, unexpected log
> * icmpv6 log -> Error: syntax error, unexpected log
>
> Only with an explicit protocol statement logging works
>
> * ip protocol tcp log
> * ip6 nexthdr icmpv6 log
You mean "log" doesn't work? (no "tcp" prefix).
> cat /proc/net/netfilter/nf_log
> 0 NONE (nfnetlink_log)
> 1 NONE (nfnetlink_log)
> 2 nf_log_ipv4 (nf_log_ipv4,nfnetlink_log)
> 3 NONE (nfnetlink_log)
> 4 NONE (nfnetlink_log)
> 5 NONE (nfnetlink_log)
> 6 NONE (nfnetlink_log)
> 7 NONE (nfnetlink_log)
> 8 NONE (nfnetlink_log)
> 9 NONE (nfnetlink_log)
> 10 nf_log_ipv6 (nf_log_ipv6,nfnetlink_log)
> 11 NONE (nfnetlink_log)
> 12 NONE (nfnetlink_log)
This means that ipv4 is logged by nf_log_ipv4 and ipv6 via
nf_log_ipv6. Everything should be working for ipv4, ipv6 and inet
without any further action (provided you want to use printk-based
logging via dmesg rather than nfnetlink).
> Tried with
>
> echo "nf_log_icmp" > /proc/sys/net/netfilter/nf_log/1
There is no layer 4 logger. nf_log_XXX, where XXX is a l3 protocol
family, i.e. nf_log_{ipv4,ipv6,arp,bridge} or nfnetlink_log.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 14:29 ` Florian Westphal
@ 2020-02-05 14:45 ` ѽ҉ᶬḳ℠
2020-02-05 14:48 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-05 14:45 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter
On 05/02/2020 14:29, Florian Westphal wrote:
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> Having perused the WIKI [1] I tried to get protocol specific logging going,
>> but ended up with
>>
>> * tcp log -> Error: syntax error, unexpected log
>> * icmpv6 log -> Error: syntax error, unexpected log
>>
>> Only with an explicit protocol statement logging works
>>
>> * ip protocol tcp log
>> * ip6 nexthdr icmpv6 log
> You mean "log" doesn't work? (no "tcp" prefix).
Yes, logging does not work with
icmpv6 log
and throws the error, whilst
ip6 nexthdr icmpv6 log
works and does not exhibit the error, similar with tcp | udp.
For package filtering it is however not necessary to make such explicit
ip protocol | ip6 nexthdr statements. And since there is no mention of
such (explicit) requirement in the WIKI I raised the question here
because I find it inexplicable that filtering does work one way and
logging another way.
>
>> cat /proc/net/netfilter/nf_log
>> 0 NONE (nfnetlink_log)
>> 1 NONE (nfnetlink_log)
>> 2 nf_log_ipv4 (nf_log_ipv4,nfnetlink_log)
>> 3 NONE (nfnetlink_log)
>> 4 NONE (nfnetlink_log)
>> 5 NONE (nfnetlink_log)
>> 6 NONE (nfnetlink_log)
>> 7 NONE (nfnetlink_log)
>> 8 NONE (nfnetlink_log)
>> 9 NONE (nfnetlink_log)
>> 10 nf_log_ipv6 (nf_log_ipv6,nfnetlink_log)
>> 11 NONE (nfnetlink_log)
>> 12 NONE (nfnetlink_log)
> This means that ipv4 is logged by nf_log_ipv4 and ipv6 via
> nf_log_ipv6. Everything should be working for ipv4, ipv6 and inet
> without any further action (provided you want to use printk-based
> logging via dmesg rather than nfnetlink).
Just installed nfnetlink_log module to see whether it would make a
difference but it did not and it is now removed again.
>> Tried with
>>
>> echo "nf_log_icmp" > /proc/sys/net/netfilter/nf_log/1
> There is no layer 4 logger. nf_log_XXX, where XXX is a l3 protocol
> family, i.e. nf_log_{ipv4,ipv6,arp,bridge} or nfnetlink_log.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 14:45 ` ѽ҉ᶬḳ℠
@ 2020-02-05 14:48 ` Florian Westphal
2020-02-05 15:01 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2020-02-05 14:48 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: Florian Westphal, netfilter
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> On 05/02/2020 14:29, Florian Westphal wrote:
> > ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> > > Having perused the WIKI [1] I tried to get protocol specific logging going,
> > > but ended up with
> > >
> > > * tcp log -> Error: syntax error, unexpected log
> > > * icmpv6 log -> Error: syntax error, unexpected log
> > >
> > > Only with an explicit protocol statement logging works
> > >
> > > * ip protocol tcp log
> > > * ip6 nexthdr icmpv6 log
> > You mean "log" doesn't work? (no "tcp" prefix).
>
> Yes, logging does not work with
>
> icmpv6 log
>
> and throws the error, whilst
>
> ip6 nexthdr icmpv6 log
>
> works and does not exhibit the error, similar with tcp | udp.
>
> For package filtering it is however not necessary to make such explicit ip
> protocol | ip6 nexthdr statements. And since there is no mention of such
> (explicit) requirement in the WIKI I raised the question here because I find
> it inexplicable that filtering does work one way and logging another way.
Not following. "log" is a single statement, it has no prefix keyword.
Why would it be special?
It works just like everyting else.
If you want to log just tcp (regardless of ipv4 or ipv6), then use
"meta l4proto tcp log"
in the inet family. "meta l4proto" gives next header protocol after
the ip or ipv6 header. In case of ipv6, it will skip extension headers,
if any.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 14:48 ` Florian Westphal
@ 2020-02-05 15:01 ` ѽ҉ᶬḳ℠
2020-02-05 15:37 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-05 15:01 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter
On 05/02/2020 14:48, Florian Westphal wrote:
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> On 05/02/2020 14:29, Florian Westphal wrote:
>>> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>>>> Having perused the WIKI [1] I tried to get protocol specific logging going,
>>>> but ended up with
>>>>
>>>> * tcp log -> Error: syntax error, unexpected log
>>>> * icmpv6 log -> Error: syntax error, unexpected log
>>>>
>>>> Only with an explicit protocol statement logging works
>>>>
>>>> * ip protocol tcp log
>>>> * ip6 nexthdr icmpv6 log
>>> You mean "log" doesn't work? (no "tcp" prefix).
>> Yes, logging does not work with
>>
>> icmpv6 log
>>
>> and throws the error, whilst
>>
>> ip6 nexthdr icmpv6 log
>>
>> works and does not exhibit the error, similar with tcp | udp.
>>
>> For package filtering it is however not necessary to make such explicit ip
>> protocol | ip6 nexthdr statements. And since there is no mention of such
>> (explicit) requirement in the WIKI I raised the question here because I find
>> it inexplicable that filtering does work one way and logging another way.
> Not following. "log" is a single statement, it has no prefix keyword.
> Why would it be special?
>
> It works just like everyting else.
> If you want to log just tcp (regardless of ipv4 or ipv6), then use
> "meta l4proto tcp log"
>
> in the inet family. "meta l4proto" gives next header protocol after
> the ip or ipv6 header. In case of ipv6, it will skip extension headers,
> if any.
Citing an example from the WIKI
nft add rule filter input tcp dport 22 ct state new log prefix \"New SSH
connection: \" accept
there is no "ip protocol" stipulated. And neither does it throw an error
and it works as expected (described in the WIKI)
Trying something similar in the inet table
nft add rule inet filter input tcp log
throws
Error: syntax error, unexpected log
However,
* nft add rule inet filter input ip protocol tcp log
* nft add rule inet filter input ip6 nexthdr icmpv6 log
neither throws an error. Hope that makes it clear.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 15:01 ` ѽ҉ᶬḳ℠
@ 2020-02-05 15:37 ` Florian Westphal
2020-02-05 16:13 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 8+ messages in thread
From: Florian Westphal @ 2020-02-05 15:37 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: Florian Westphal, netfilter
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> Citing an example from the WIKI
>
> nft add rule filter input tcp dport 22 ct state new log prefix \"New SSH
> connection: \" accept
>
> there is no "ip protocol" stipulated. And neither does it throw an error and
> it works as expected (described in the WIKI)
Why would there?
tcp dport eq 22
ct state eq new
log prefix \"New SSH ...\"
accept
See?
4 statements, first two statements are equality tests,
3rd statement is log, 4th is the verdict.
> Trying something similar in the inet table
>
> nft add rule inet filter input tcp log
>
> throws
>
> Error: syntax error, unexpected log
Of course, because this is not similar at all.
This is
tcp
log
"tcp" isn't a statement. What should it mean?
> * nft add rule inet filter input ip protocol tcp log
> * nft add rule inet filter input ip6 nexthdr icmpv6 log
>
> neither throws an error. Hope that makes it clear.
Why would it? Its valid.
ip protocol == tcp
log
ip6 nexthdr == icmpv6
log
both are two valid statements.
It might help if you would explain what you are trying to do.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 15:37 ` Florian Westphal
@ 2020-02-05 16:13 ` ѽ҉ᶬḳ℠
2020-02-05 16:21 ` Florian Westphal
0 siblings, 1 reply; 8+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-05 16:13 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter
On 05/02/2020 15:37, Florian Westphal wrote:
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> Citing an example from the WIKI
>>
>> nft add rule filter input tcp dport 22 ct state new log prefix \"New SSH
>> connection: \" accept
>>
>> there is no "ip protocol" stipulated. And neither does it throw an error and
>> it works as expected (described in the WIKI)
> Why would there?
> tcp dport eq 22
> ct state eq new
> log prefix \"New SSH ...\"
> accept
>
> See?
> 4 statements, first two statements are equality tests,
> 3rd statement is log, 4th is the verdict.
>
>> Trying something similar in the inet table
>>
>> nft add rule inet filter input tcp log
>>
>> throws
>>
>> Error: syntax error, unexpected log
> Of course, because this is not similar at all.
> This is
> tcp
> log
>
> "tcp" isn't a statement. What should it mean?
Well, it was supposed to mean to log tcp traffic without being specific
on the header fields.
It dawns to me (belatedly) however that it either needs to be stipulated
as layer protocol (preceding) or else to be expanded (trailing) with a
header field match in order to be considered a valid statement for the
nft parser. Suppose been trying to keep the code as light/shorthand as
possible.
Thanks for the input/pointer.
Not directly related to the subject but curious about concentrating log
flags, level and prefix, is this valid syntax (within context of course):
log flags all level debug prefix
or does it require
log flags all log level debug log prefix
>
>> * nft add rule inet filter input ip protocol tcp log
>> * nft add rule inet filter input ip6 nexthdr icmpv6 log
>>
>> neither throws an error. Hope that makes it clear.
> Why would it? Its valid.
>
> ip protocol == tcp
> log
>
> ip6 nexthdr == icmpv6
> log
>
> both are two valid statements.
>
> It might help if you would explain what you are trying to do.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement?
2020-02-05 16:13 ` ѽ҉ᶬḳ℠
@ 2020-02-05 16:21 ` Florian Westphal
0 siblings, 0 replies; 8+ messages in thread
From: Florian Westphal @ 2020-02-05 16:21 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: Florian Westphal, netfilter
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> Not directly related to the subject but curious about concentrating log
> flags, level and prefix, is this valid syntax (within context of course):
>
> log flags all level debug prefix
>
> or does it require
>
> log flags all log level debug log prefix
The last form specifies multiple log statements,
which is probably not what you want:
log flags all
log level debug
log prefix
Which would log 3 times.
So, first version is what you want/need.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-05 16:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-05 14:14 [nftables v0.9.2 | kernel 4.19.93] logging protocols in inet family table require explicit protocol statement? ѽ҉ᶬḳ℠
2020-02-05 14:29 ` Florian Westphal
2020-02-05 14:45 ` ѽ҉ᶬḳ℠
2020-02-05 14:48 ` Florian Westphal
2020-02-05 15:01 ` ѽ҉ᶬḳ℠
2020-02-05 15:37 ` Florian Westphal
2020-02-05 16:13 ` ѽ҉ᶬḳ℠
2020-02-05 16:21 ` Florian Westphal
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.