netfilter buglog - Jun 2013 - [Bug 696] Extra tcp options for REJECT --reject-with tcp-reset-both / tcp-reset-destination

https://bugzilla.netfilter.org/show_bug.cgi?id=696

--- Comment #3 from Alessandro Vesely <vesely at tana.it> 2013-06-21
15:50:56 CEST ---
(In reply to comment #2)
> you have to put this REJECT rule before any RELATED/ESTABLISHED
> conntrack ctstate match rules (which is suboptimal).
No, I can use conntrack -D to have the connection unESTABLISHED.

In general, it is polite to send a tcp-reset to both peers.  However,
people often reset connections because the remote peer is a malicious
client, so it is popular to omit sending the tcp-reset as a form of revenge.

Still, people like to reset their own side, so as to avoid wasting
resources.  The usual workaround is to do that in OUTPUT, for example:

   iptables -A INPUT -m conntrack --ctstate NEW -p tcp ! --syn\
      -j DROP

and

   iptables -A OUTPUT -m conntrack --ctstate NEW -p tcp ! --syn\
      -j REJECT --reject-with tcp-reset

It is better to send the local tcp-reset as soon as the decision to
reset the connection is made.
> And if you really want to reset an existing connection with a tcp reset,
you
> need to track the sequence number of the remote side so you can craft a
reset
> packet which isn't simply ignored by the client due to an out of range
> sequence (ack).
>
> So overall, it is difficult to understand the motivation for this request.
> And even more difficult would be actually implementing it.
That's the difficulty that userspace programs such as tcpkill, killcx,
cutter, snort, and similar have to face.  The kernel manages the seq and
ack_seq counters itself, so it doesn't have to try:  It issues a reset,
rather than injecting it.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.