linux-kernel - Re: [PATCH] netfilter: xt_esp: add support for ESP match in NAT Traversal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 27 Jun 2022 19:22:05 +0200
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Wei Han <lailitty@...mail.com>
Cc:     kadlec@...filter.org, fw@...len.de, davem@...emloft.net,
        edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] netfilter: xt_esp: add support for ESP match in NAT
 Traversal

On Fri, Jun 24, 2022 at 08:05:30PM +0800, Wei Han wrote:
> On Thu, Jun 23, 2022 at 09:36:41PM +0200, Pablo Neira Ayuso wrote:
[...]
> > > +		} else {
> > > +			return false;
> > > +		}
> > > +	} else if (proto == IPPROTO_ESP) {
> > > +		//not NAT-T
> > > +		eh = skb_header_pointer(skb, par->thoff, sizeof(_esp), &_esp);
> > > +		if (!eh) {
> > > +			/* We've been asked to examine this packet, and we
> > > +			 * can't.  Hence, no choice but to drop.
> > > +			 */
> > > +			pr_debug("Dropping evil ESP tinygram.\n");
> > > +			par->hotdrop = true;
> > > +			return false;
> > > +		}
> > 
> > This is loose, the user does not have a way to restrict to either
> > ESP over UDP or native ESP. I don't think this is going to look nice
> > from iptables syntax perspective to restrict either one or another
> > mode.
> >
>   This match original purpose is check the ESP packet's SPI value, so I
>   think the user maybe not need to pay attention that the packet is 
>   ESP over UDP or native ESP just get SPI and check it, this patch is 
>   only want to add support for get SPI in ESP over UDP.And the iptables rules like:
>   "iptables -A INPUT -m esp --espspi 0x12345678 -j ACCEPT"

This rule would be now allowing UDP traffic to go through, even if the
user does not need it. An explicit policy entry to allow NAT-T would
be preferred.

There is another issue, although I suppose there is a standard UDP
port for this, user might decide to select a different one, in that
case, this would break. And I don't see an easy way to allow user to
select the UDP port in the iptables case.