[tproxy] tproxy side effect - expansion of worm attack

[elyasaf]

Thank your for your response

We thought about something like read one accept from the accept QUEUE
(without real accept), return the accept parameters to the users space, and
then move it to the end of the QUEUE
Meanwhile, in the users space we try to connect to the server-side
And then in the next epoll round, we will get the accept again

Br, 

elyasaf
-----Original Message-----
From: Balazs Scheidler [mailto:bazsi at balabit.hu] 
Sent: Monday, June 08, 2009 12:40 PM
To: elyasaf
Cc: tproxy at lists.balabit.hu
Subject: Re: [tproxy] tproxy side effect - expansion of worm attack

On Wed, 2009-05-27 at 14:28 +0300, elyasaf wrote:
> tproxy side effect - expansion of worms attacks:
>  
> We have identified a serious "social" side effect in tproxy that results
> significant performances lose. The scenario is as follows:
> We have proxy machines that each one serve about ten thousand internet
users
> with unique IP. Since we are listening beside the outgoing traffic also to
> the ingoing traffic on all the ports:
> ${iptables} -t mangle -A ROUTINE -p tcp -j TPROXY --on-port 3144 --on-ip
> 0.0.0.0 --tproxy-mark 0x1/0xffffffff
>  
> Now each worm that tries to access the computers behind our network,
thinks
> that the remote port is open and our customers are vulnerable, will try
more
> attacks and as result increase significantly the load of the servers (in
> some hours more than 50% of all the new connections are worms one!)
>  
> Technically (without considering some flood protections on the iptables,
> that result sometimes unexpected behavior) we cannot see how to avoid that
> since we accept the connection from the internet, in case there is user
> server behind it and in case that not because we can't know which
> destination ip and port is accessed before accepting the new connection.
>  
> BTW, similar kind of problems arise on outgoing connections where some
> applications that run on the customers desktops get confused where the
> connection to the remote server succeeds  but no real server really
> listening.
>  
> It's looks like that we have conceptual problem here, possible workaround
> can be to "know" somehow the remote address details before accepting the
> connection. Can someone please say if this kind of thing exists and if not
> is there chance to implement that thing from the perspective of the tproxy
> patch.
>  
> br,
> elyasaf
>  
>  
> Do you think that there should be an option to implement the accept
fucntion
> without SYN-ACK?
> And only after a SYN-ACK is received from the server side send the SYN-ACK
> to the client?

It would probably be possible, however current tproxy does not do
anything like that. I remember seeing a patch that implemented this
about 8 years ago.

It might also be possible to QUEUE out the SYN packets, decide if they
should be accepted (by checking the internal port) and inject them back
once you know it'll be processed.

I'm not sure whether QUEUE can be used in the mangle table though.

-- 
Bazsi