[tproxy] tproxy side effect - expansion of worm attack

elyasaf elyasaf at icomsw.com
Wed May 27 13:28:15 CEST 2009


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?



More information about the tproxy mailing list