netdev - Re: [tproxy,regression] tproxy broken in 2.6.32

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20091129203508.GB18259@sch.bme.hu>
Date:	Sun, 29 Nov 2009 21:35:08 +0100
From:	KOVACS Krisztian <hidden@....bme.hu>
To:	jamal <hadi@...erus.ca>
Cc:	KOVACS Krisztian <hidden@....bme.hu>,
	Patrick McHardy <kaber@...sh.net>,
	KOVACS Krisztian <hidden@...abit.hu>,
	Andreas Schultz <aschultz@...p10.net>, tproxy@...ts.balabit.hu,
	netdev@...r.kernel.org
Subject: Re: [tproxy,regression] tproxy broken in 2.6.32

Hi,

On szo, nov 28, 2009 at 02:44:02 -0500, jamal wrote:
> > The source address *is* unicast. 
> 
> Sorry - I meant the route type is unicast. The fact that an address is
> unicast or not is already dealt with by the time you get to source
> address validation (in ip_input())
> 
> > The problem is that the routing setup is
> > asymmetrical, as Patrick has already mentioned: we're using a mark to
> > force certain packets (those that have matching sockets on the host) being
> > delivered locally.
> >
> > In the other direction, reply packets won't be marked by the iptables
> > rules and thus will be routed on egress just fine. 
> 
> In that case i dont understand the reluctance to use unicast routes.
> Maybe you can explain and put me at ease because i see youve put extra
> effort to use local addresses. 

The short answer is: it doesn't work with unicast routes.

The story is that we really do want to deliver these packets locally, as
if the destination IP address was locally configured on the host. The only
way I know of to get the packet to ip_local_deliver() is by using a local
route.

(Now that you mentioned this I've actually gave it a try. Changing 'local'
in the route to 'unicast' doesn't work at all: incoming packets get
dropped because forwarding is not enabled on the ingress interface.)

-- 
KOVACS Krisztian
--
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