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