On 2020/03/21 06:17, Stefan Hartmann wrote:
Thank you Florian and Frank for your suggestions. Yes, I found it now
also in the man page under "RAW PAYLOAD EXPRESSION".
I tested step for step:
ip daddr $IP4_IF2 meta l4proto {udp, tcp} @th,16,16 {69, 23} accept
ip daddr $IP4_IF2 meta l4proto . @th,16,16 {udp . 69, tcp . 23} accept
ip daddr $IP4_IF2 meta l4proto . @th,16,16 @CONCATENATED_SET_3 accept
and verified with netcat - it is functional in this way.
Thanks for confirming that the above work.
And incidentally thank you for prompting me to look up character length
limits on set names and other nftables objects. After cutting my
firewall teeth using ipchains I'm leery of longish identifiers. AFAICT
limits were/are:
ipchains: 8 characters (!)
https://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html
iptables: 29 characters
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/x_tables.h
#define XT_EXTENSION_MAXNAMELEN 29
nftables: 256 characters
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/nf_tables.h
#define NFT_NAME_MAXLEN 256
#define NFT_TABLE_MAXNAMELEN NFT_NAME_MAXLEN
#define NFT_CHAIN_MAXNAMELEN NFT_NAME_MAXLEN
#define NFT_SET_MAXNAMELEN NFT_NAME_MAXLEN
#define NFT_OBJ_MAXNAMELEN NFT_NAME_MAXLEN
Could there be issues with conntrack, nat, etc with this approach?
I will test it in the next days.
I wouldn't expect so, but please report back.
Firstly I will start with separate UDP and TCP service groups.
Sounds reasonable to me.
Nb. I use separate ipv4 and ipv6 tables, because they are really
different protocols. In my experience the mixing leads often to
overlooked security flaws - I am working as pentester occasionally.
Thanks for your observation.
Cheers,
Frank
