Re: Best way to kill a live TCP connection?

[Alessandro Vesely <vesely@tana.it>]

On 18/Jan/11 19:45, Gáspár Lajos wrote:
> Do you know the conntrack tool?
> 
> conntrack -D...

Yes, I'm sorry I didn't leave more context in place.  The thread was
about deleting connections as above and have iptables kill them as a
side effect.

>> I tried using connmark, as in
>>
>>     iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn\
>>        -j CONNMARK --or-mark 8
>> and
>>     iptables -A OUTPUT -m connmark --mark 8/8 -p tcp ! --syn\
>>        -j REJECT --reject-with tcp-reset
>>
>> However, the latter rule never matched.  Is it the wrong table?
>
> Do you have more connmark rules? Maybe something interferencing whit
> these rules...

Not connmark --which I'm unfamiliar with-- but there was a sanity
check that I overlooked.  Your question has put me on the right track.
 Thanks!

Now, having fixed that, terminating connections this way apparently
works perfectly: issuing "conntrack -D -s x.x.x.x", the local end of
each connection to x.x.x.x is reset, thereby saving server's
resources, while malicious clients are left idling alone.

This seems about the best I can get.  However, this method still has
two minor defects:

First, after I have determined that the client is malicious I have to
let in one more packet.  This could be avoided using the
tcp-reset-destination iptables enhancement that I proposed.

Second, if such further packet never arrives, the server has to wait
until timeout.  I think I'd need the seq/ack numbers of the last
packet in order to avoid this.  They must be somewhere in the system,
don't they?  (Or would it help to send spoofed packets to remote
clients at the time their maliciousess is determined, as other
methods* do?)

Further thoughts?

-- 
[*] see killcx or cutter, mentioned upthread.