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. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
