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@balabit.hu] Sent: Monday, June 08, 2009 12:40 PM To: elyasaf Cc: tproxy@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