Re: How TCP handle (RST,SYN) at initial connection establishment

• Previous message: David Gillett: "RE: Proxy & Firewall Implementation"
• In reply to: Lim Boon Ping: "How TCP handle (RST,SYN) at initial connection establishment"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: security-basics@securityfocus.com
Date: Fri, 14 Jan 2005 11:51:26 +0100

On Thursday 13 January 2005 13:20, Lim Boon Ping wrote:
> I need some clarification on how TCP reacts to
> incoming (RST, SYN) during 3-way handshaking process.
> In this case, assumptions are made such that
>
> (1) attacker manages to conquer 1 router in front
> of victim server.
>
> (2) instead of consuming server / bandwidth
> resources by flooding,the attacker would send (RST,
> SYN) or (RST, ACK) or simply RST upon receiving of any
> SYN request towards victim server.
>
> RFC 793, p36, states the following:
>
> "In all states except SYN-SENT, all reset (RST)
> segments are validated by checking their SEQ-fields
> [sequence numbers]. A reset is valid if its sequence
> number is in the window. In the SYN-SENT state (a RST
> received in response to an initial SYN), the RST is
> acceptable if the ACK field acknowledges the SYN."
>
> My questions are:
>
> 1) According to RFC 793, an established TCP connection
> can be reset by sending suitable TCP packets with the
> (RST, SYN). During the connection establishment stage,
> does the client suffer the same risk?

I don't know if this answer your question... I think (RST, SYN) means no ACK.
The "client", during the three-way handshacking, starts in CLOSED state,
crosses the SYN-SENT state and then land in ESTABLISHED state (so I assume
that you're interested only in SYN-SENT state... the client can reach the
SYN-RCV state only for simultaneous open, but this is another story).
In the SYN-SENT state:

" If the state is SYN-SENT then
     first check the ACK bit
        [...]
     second check the RST bit
        If the RST bit is set

          If the ACK was acceptable then signal the user "error:
          connection reset", drop the segment, enter CLOSED state,
          delete TCB, and return. Otherwise (no ACK) drop the segment
          and return." (rfc793, pp.66-67)

So if the client is in SYN-SENT state and receives a (RST, SYN) packet without
an ACK it drops the packet and its state doesn't change.
This beacause the SYN flag is analized only at step four:

" fourth check the SYN bit
        This step should be reached _only_ if the ACK is ok, or there is
        no ACK, and it the segment _did not_ contain a RST." (rfc793, p. 67)

> At SYN-SENT state, what happen if the client receives
> (RST, SYN) spoofed by the attacker with Source
> IP=victim server IP? Assume that in the (RST, SYN)
> packet, the ACK sequence number correctly acknowledges
> the client's SYN, but TCP ACK flag is not set (can it
> be in this way?).

If the ACK bit isn't set the ACK field value isn't checked. As stated before
client state doesn't change.

> 2) At TCP connection establishment, can (RST, ACK) or
> simply RST flooding toward client side will avoid any
> connection request to the victim server?

You can intercept the client first SYN and send to it a spoofed segment with
RST on, ACK on, sequence 0 and ack field equal to client seq.+1. The client
will think that the remote tcp port is closed (no process bound it). This is
what the REJECT target of iptables does if used with option "--reject-with
tcp-reset".
If you're using linux you can add an iptables rule like the following:

iptables -I FORWARD -o <output i/f> -p tcp --destination-port <port# of \
     service you want to disallow access to> -j REJECT --reject-with tcp-reset

>
> =====
> Best regards,
> Boon Ping, Lim

Hope this help, sorry for my bad English,
        Davide.

• Previous message: David Gillett: "RE: Proxy & Firewall Implementation"
• In reply to: Lim Boon Ping: "How TCP handle (RST,SYN) at initial connection establishment"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]