[prev in list] [next in list] [prev in thread] [next in thread] 

List:       best-of-security
Subject:    Re: TCP Header Flags
From:       Julian Assange <proff () suburbia ! net>
Date:       1995-08-12 0:18:13
[Download RAW message or body]

Forwarded message:
>From firewalls-owner@GreatCircle.COM Sat Aug 12 09:00:04 1995
Date: Fri, 11 Aug 1995 18:04:41 -29900
From: Nick Simicich <njs@scifi.maid.com>
Subject: Re: TCP Header Flags
To: Carsten Schafer <carsten@group.com>
cc: firewalls@GreatCircle.COM, Carsten Schafer <carsten@group.com>
In-Reply-To: <9508111225.aa03131@rosie.software.group.com>
Message-ID: <Pine.3.89.9508111706.G9157-0100000@scifi.maid.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: firewalls-owner@GreatCircle.COM
Precedence: bulk

On Fri, 11 Aug 1995, Carsten Schafer wrote:

> I have recently been getting lots of packets with the SYN bit set
> and a combination of PUSH, URG and RST.  Our packet filter seems
> to throw away anything with a SYN bit set.  I guess I'm wondering
> which packets are considered connection requests by TCP when the packet
> contains a SYN bit.  Are packets containing the SYN flag and no others
> considered connection requests?  Most of the packets with the other flags
> set seem to be in response to HTTP requests.

The initial request for a TCP connection has the SYN bit set, but not the 
ACK bit.  Every other TCP packet in a connection has the ACK bit set, 
including the response to the initial SYN, which also has the SYN bit 
set.  

So filtration for directional TCP connections usually looks for packets that 
have SYN but not ACK.

Once sequence numbers are agreed on, SYN is no longer sent.

RST, of course, says that either we got a packet for a connection we don't
have a record of, or we don't have that socket at all (not 100% sure on
the latter, offhand - for UDP this returns ICMP Socket Unreachable). 

This means that you can typically probe the topology of a net protected 
by a packet filtering router even if they have filtered ICMP echo and 
port unreachable messages to stop ping and traceroute as well as all 
incoming connections.

By the way, this is quite likely attempts from the HTTPD at the other end 
to connect to your identd so that they can log userids in the http daemon 
logs.  Are the SYNs consistently aimed at the identd (or perhaps finger) 
ports?

Nick Simicich - njs@scifi.emi.net - (last choice) njs@bcrvm1.vnet.ibm.com
http://scifi.emi.net/njs.html -- Stop by and Light Up The World!

[prev in list] [next in list] [prev in thread] [next in thread]