netdev - Re: [tproxy] udp + tproxy

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-next>] [day] [month] [year] [list]

Message-Id: <1226518030.10667.68.camel@bzorp.balabit>
Date:	Wed, 12 Nov 2008 20:27:10 +0100
From:	Balazs Scheidler <bazsi@...abit.hu>
To:	KOVACS Krisztian <hidden@....bme.hu>
Cc:	Andrey Luzgin <andrey@...msw.com>, tproxy@...ts.balabit.hu,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [tproxy] udp + tproxy

On Wed, 2008-11-12 at 19:59 +0100, KOVACS Krisztian wrote:
> Hi,
> 
> On sze, nov 12, 2008 at 11:40:30 +0000, Andrey Luzgin wrote:
> > Hello,
> > 
> > While I can see example of using udp on tproxy2 onto the
> > redirect-udp-recv.c
> > file, I can't find equivalent on tproxy4.
> > 
> > For getting the original destination IP, I just use setsockopt
> > IP_PKTINFO:
> > setsockopt(sd, SOL_IP, IP_PKTINFO , &flags, sizeof(flags));
> > 
> > But I don't know how to get the original destination port:
> > 
> > a) I manually defined IP_RECVORIGADDRS  to be 11273 as I find on
> > tproxy2:
> > setsockopt(sd, SOL_IP, IP_RECVORIGADDRS , &flags, sizeof(flags));
> > but the setsockopt failed.
> > 
> > b) the getsockname give me the server listening port.
> 
> 
> Since tproxy 4 (unlike tproxy 2) doesn't modify the incoming packets in
> any way you should be able to get the correct destination address by
> simply calling recvfrom() and using the source address returned by the
> kernel.
> 

This is not true, recvfrom() returns the client address and does not
return the original destination. There was a hack in 2.2 kernels, that
it could return the targeted address in the 2nd half of the "struct
sockaddr_in" structure.

But that hack was crude. 

I can only see two options to proceed with full udp proxying: accept()
support for UDP, or a recvmsg() ancillary data (IP_RECVORIGADDRS) as
above.

I'll see whether I can come up with a patch for the latter.

In Zorp we're using accept() for UDP sockets, but I doubt it could be
integrated to mainline, the other option is doable, although potentially
racy.

-- 
Bazsi


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html