[tproxy] tproxy side effect - expansion of worm attack

Balazs Scheidler bazsi at balabit.hu
Thu Jun 11 15:22:36 CEST 2009

On Thu, 2009-06-11 at 13:32 +0300, elyasaf wrote:
> 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

This should theoretically be possible, but I'm not sure incoming
connections are ordered though. A quick look on the code in question
seems to indicate that there's indeed a queue, though I think those are
already established connections (e.g. syn-synack-acked)

some more reading of the related queue....

as it seems the incoming SYNs are put in a hashtable, thus those are not
ordered. so if you want to get notification on the incoming connection
before it gets SYNACKed, you won't have an ordering.

If it's not a problem that your client already has an ESTABLISHED
connection when you drop it, then your solution might work.

The advantage of the iptables QUEUE target is that it does not require
core kernel changes, and that you can actually block SYNs being
processed by the kernel as well.

> 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
> > --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.

More information about the tproxy mailing list