detection of the third tcp packet in a tcp connection setup

detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

Hi,

Does anyone have a good solution to catch the third (ACK) packet
in a tcp connection setup?

Ramin

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 7:27 pm, Ramin Alidousti wrote:

> Hi,
>
> Does anyone have a good solution to catch the third (ACK) packet
> in a tcp connection setup?

What do you mean by 'catch' it ?

I mean, I could say "wait till you see a SYN/ACK, and then grab the next 
one", or "look for a SYN, and then take the next one in the same direction", 
but I'm thinking that neither of those is probably the answer you want ?

Tell us what you want to do with the packet and it might make the question a 
little easier.

 

Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 7:27 pm, Ramin Alidousti wrote:

> Hi,
>
> Does anyone have a good solution to catch the third (ACK) packet
> in a tcp connection setup?

Is the --ctstatus connection tracking extension any use ?   The value 
SEEN_REPLY will tell you when the second packet's come in, and ASSURED will 
match the third packet....

 

Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Patrick Schaaf]

Hi Ramin,

> Does anyone have a good solution to catch the third (ACK) packet
> in a tcp connection setup?

Maybe you could use the CONNMARK patch, found in patch-o-matic?
Mark the conntrack one way for the first packet of a new connection,
and later match on that mark, changing it to something else when that
match hits.

Thanks for a nice idea from the "how do I bend iptables into a
programming language" department. :-)

best regards
  Patrick

Re: detection of the third tcp packet in a tcp connection setup

[Maciej Soltysiak]

> Does anyone have a good solution to catch the third (ACK) packet
> in a tcp connection setup?

# iptables -A INPUT -p tcp --tcp-flags ACK ACK -m recent --rcheck
  --seconds 60 -j LOG --log-prefix "3rd is ack: "

# iptables -A INPUT -p tcp -m state --state NEW --syn -m recent --set -j
  LOG --log-prefix "1st is syn: "

Would not it work?
First SYN packet triggers the recent module in the second rule.
Second (your) syn/ack goes on your OUTPUT.
Third ACK triggers the first rule.

I am not using recent, and i just made that up from the description.

But it seems reasonably.

Or does it?

Regards,
Maciej

Re: detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

On Thu, Jun 27, 2002 at 08:53:19PM +0200, Patrick Schaaf wrote:

> Hi Ramin,

Hi Patrick,

> 
> > Does anyone have a good solution to catch the third (ACK) packet
> > in a tcp connection setup?
> 
> Maybe you could use the CONNMARK patch, found in patch-o-matic?
> Mark the conntrack one way for the first packet of a new connection,
> and later match on that mark, changing it to something else when that
> match hits.

Hmm, OK, interesting. I was thinking to play with Stephen's excellent
module (recent) to acomplish this but I just wanted to have all the
options open. I'll definitely dig into this solution as well :-)

> Thanks for a nice idea from the "how do I bend iptables into a
> programming language" department. :-)

Well, you know, I'm not a kernel guy; not that I can't be one
but I'd leave it to the gurus we have out there. I'm just trying
to gather enough available building blocks to do my things easily :-)

Ramin

> best regards
>   Patrick

Re: detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

On Thu, Jun 27, 2002 at 07:52:54PM +0100, Antony Stone wrote:

> On Thursday 27 June 2002 7:27 pm, Ramin Alidousti wrote:
> 
> > Hi,
> >
> > Does anyone have a good solution to catch the third (ACK) packet
> > in a tcp connection setup?
> 
> Is the --ctstatus connection tracking extension any use ?   The value 
> SEEN_REPLY will tell you when the second packet's come in, and ASSURED will 
> match the third packet....

Thanks, Antony and also Maciej and Patrick. Let all the solutions come :-)

Ramin

> Antony.

RE: detection of the third tcp packet in a tcp connection setup

[Joe Patterson]

catching the third packet is easy.  The hard part is to both catch the third
packet and *not* catch all of the rest of the ack packets.

There are some distinguishing characteristics... it is the first packet sent
by the client that is in state ESTABLISHED.  it should have ACK set and no
other flags.  the tcp data length should be zero.

Probably Patrick's idea of the CONNMARK patch is best.  Mark the connection
when you see a syn-ack in state established.  Then when you see an ack
packet that is marked, you unmark the connection and do with it what you
wish.  Actually, unmark is probably the wrong term.  As I understand it, all
packets have a mark, it's just 0x0 unless it's been specifically set.  So,
mark it as some arbitrary value when you see the syn-ack established, and
then mark it as 0 when you see established with the arbitrary mark value.
That should work.  Probably the best solution you're likely to get.

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Ramin Alidousti
> Sent: Thursday, June 27, 2002 2:28 PM
> To: netfilter@lists.samba.org
> Subject: detection of the third tcp packet in a tcp connection setup
>
>
> Hi,
>
> Does anyone have a good solution to catch the third (ACK) packet
> in a tcp connection setup?
>
> Ramin
>
>
>

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 8:10 pm, Joe Patterson wrote:

> catching the third packet is easy.  The hard part is to both catch the
> third packet and *not* catch all of the rest of the ack packets.
>
> There are some distinguishing characteristics... it is the first packet
> sent by the client that is in state ESTABLISHED.  it should have ACK set
> and no other flags.  the tcp data length should be zero.

Isn't that in itself a bit of a giveaway ?   I can't think of a reason why a 
zero-length packet should ever occur in the remainder of the data stream... ?

There's a -m length --length <min>:<max> match somewhere, but I'm not sure if 
it's in the standard build or p-o-m

 

Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

On Thu, Jun 27, 2002 at 09:44:07PM +0200, Patrick Schaaf wrote:

> > > There are some distinguishing characteristics... it is the first packet
> > > sent by the client that is in state ESTABLISHED.  it should have ACK set
> > > and no other flags.  the tcp data length should be zero.
> > 
> > Isn't that in itself a bit of a giveaway ?   I can't think of a reason why a 
> > zero-length packet should ever occur in the remainder of the data stream... ?
> 
> How to TCP keepalive packets look like? Also, isn't it possible that the
> third packet already carries data, in the general (read TCP protocol as
> it is written) case? You probably won't get that with the normal socket
> interface from userlevel, but does TCP forbid it? I don't think so.

Correct. And besides when you receive data and have nothing to send
you'll ack with a zero-length packet.

Ramin

> 
> best regards
>   Patrick

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 8:44 pm, Patrick Schaaf wrote:

> > > There are some distinguishing characteristics... it is the first packet
> > > sent by the client that is in state ESTABLISHED.  it should have ACK
> > > set and no other flags.  the tcp data length should be zero.
> >
> > Isn't that in itself a bit of a giveaway ?   I can't think of a reason
> > why a zero-length packet should ever occur in the remainder of the data
> > stream... ?
>
> How to TCP keepalive packets look like?

Hmmm.   Don't know.   Hadn't thought about those...

> Also, isn't it possible that the third packet already carries data, in the
> general (read TCP protocol as it is written) case?

Well, I'd always thought that this was allowed, yes, but I've also been told 
by several different people (who play with real-world networks all the time) 
that it never happens in practice - you get:

SYN (no data)
SYN/ACK (no data)
ACK (no data)
ACK (data)
ACK (data)
etc.....

> You probably won't get that with the normal socket
> interface from userlevel, but does TCP forbid it? I don't think so.

Fair point, but if Ramin's working on a real network, maybe a solution which 
works is okay, even if there's a theoretical situation when it wouldn't.

Ramin, by the way, what are you trying to do this for ?

 

Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Patrick Schaaf]

> > There are some distinguishing characteristics... it is the first packet
> > sent by the client that is in state ESTABLISHED.  it should have ACK set
> > and no other flags.  the tcp data length should be zero.
> 
> Isn't that in itself a bit of a giveaway ?   I can't think of a reason why a 
> zero-length packet should ever occur in the remainder of the data stream... ?

How to TCP keepalive packets look like? Also, isn't it possible that the
third packet already carries data, in the general (read TCP protocol as
it is written) case? You probably won't get that with the normal socket
interface from userlevel, but does TCP forbid it? I don't think so.

best regards
  Patrick

Re: detection of the third tcp packet in a tcp connection setup

[Maciej Soltysiak]

> > How to TCP keepalive packets look like? Also, isn't it possible that the
> > third packet already carries data, in the general (read TCP protocol as
> > it is written) case? You probably won't get that with the normal socket
> > interface from userlevel, but does TCP forbid it? I don't think so.
> 
> Correct. And besides when you receive data and have nothing to send
> you'll ack with a zero-length packet.
I agree.

But that reminds me something.
I had a problem once (not solved) with a novell server that used to send
TCP packets with 2 bytes of data, then 52, then 2, then 52.
It never sent packets filled to the MSS size as negotiated at the
beginning.

That caused the pop3 traffic to go terribly slow, and finally the server
decided to close the connection due to timeout of not sending a mail
message in time.

I tcpdumped the session, and did not see any, in my opinion, valid cause,
like advertising a smaller tcp window.

Also some (but not all) modem connection to the server had full 576 byte
packets

Any ideas on the cause?

Regards,
Maciej Soltysiak

RE: detection of the third tcp packet in a tcp connection setup

[Joe Patterson]

Nope.  If you've got data flowing in one direction, then you should have a
steady stream of packets with tcp data and (I believe) PSH,ACK set flowing
one way, and a steady stream of packets with ACK set and zero tcp data
length flowing the other way.  But I could be wrong....  Actually, no, just
checked it with a sniffer, and I couldn't be wrong.  :)  Other than order I
don't see any way to distinguish the first ack from the 100th.

Now, you could say that if the tcp data length is greater than zero, then
the packet is either *not* valid, or is *not* the third packet (although
there was at one point a proposed tcp-like protocol that had data in the
third packet, to keep down latency on short duration sessions, but I believe
it's still considered evil in tcp-land).

But even then, the length match wouldn't necessarily help.  I believe
(although not sure) that the length match matches the length of the entire
ip packet, and I further believe that it would be entirely valid to pad the
end of the third packet in a tcp handshake with a bunch of NOOP options,
thereby making the ip packet larger than you would expect for a tcp packet
with no data.  It's still somewhat usefull, but not reliable.

That kind of touches on an idea I had a while back, to log packets going to,
for example, port 25 with a length greater than a tcp packet with no options
and no data, but less than a tcp packet with no options and a few (2?  3?)
bytes of data.  You *might* be able to use this to notice people who are
telnetting to an smtp port and typing in commands by hand.  Certainly not
reliable, but possibly interesting nonetheless.

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Antony Stone
> Sent: Thursday, June 27, 2002 3:31 PM
> To: netfilter@lists.samba.org
> Subject: Re: detection of the third tcp packet in a tcp connection setup
>
>
> On Thursday 27 June 2002 8:10 pm, Joe Patterson wrote:
>
> > catching the third packet is easy.  The hard part is to both catch the
> > third packet and *not* catch all of the rest of the ack packets.
> >
> > There are some distinguishing characteristics... it is the first packet
> > sent by the client that is in state ESTABLISHED.  it should have ACK set
> > and no other flags.  the tcp data length should be zero.
>
> Isn't that in itself a bit of a giveaway ?   I can't think of a
> reason why a
> zero-length packet should ever occur in the remainder of the data
> stream... ?
>
> There's a -m length --length <min>:<max> match somewhere, but I'm
> not sure if
> it's in the standard build or p-o-m
>
>
>
> Antony.
>
>
>

Re: detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

On Thu, Jun 27, 2002 at 08:44:03PM +0100, Antony Stone wrote:

> On Thursday 27 June 2002 8:44 pm, Patrick Schaaf wrote:
> 
> > > > There are some distinguishing characteristics... it is the first packet
> > > > sent by the client that is in state ESTABLISHED.  it should have ACK
> > > > set and no other flags.  the tcp data length should be zero.
> > >
> > > Isn't that in itself a bit of a giveaway ?   I can't think of a reason
> > > why a zero-length packet should ever occur in the remainder of the data
> > > stream... ?
> >
> > How to TCP keepalive packets look like?
> 
> Hmmm.   Don't know.   Hadn't thought about those...
> 
> > Also, isn't it possible that the third packet already carries data, in the
> > general (read TCP protocol as it is written) case?
> 
> Well, I'd always thought that this was allowed, yes, but I've also been told 
> by several different people (who play with real-world networks all the time) 
> that it never happens in practice - you get:
> 

If I'm not wrong you can always send data even in SYN and SYN/ACK.
Like Patrick said the default options in the socket interface might
not do it but I thought I saw some tweaking in one of Richard Steven's
(god bless his soul) books to push traffic in SYN packets.

Ramin

> SYN (no data)
> SYN/ACK (no data)
> ACK (no data)
> ACK (data)
> ACK (data)
> etc.....

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 8:57 pm, Ramin Alidousti wrote:

> If I'm not wrong you can always send data even in SYN and SYN/ACK.
> Like Patrick said the default options in the socket interface might
> not do it but I thought I saw some tweaking in one of Richard Steven's
> (god bless his soul) books to push traffic in SYN packets.

Is that an interesting way to get round packet filtering firewalls ?

Send enough data (eg an http request) in a SYN packet so that the application 
does the dirty work for you, even if the packet filter isn't going to allow 
the connection to get ESTABLISHED ?

Or do you have to fiddle with the receiving socket too in order for it to 
cope with this ?

 

Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Patrick Schaaf]

> Other than order I don't see any way to distinguish the first ack from
> the 100th.

If perfect recognition is neccessary, a suitable in-kernel module would
be able to remember there are sequence numbers from the SYNs (conntrack
already does that), and pinpoint that ACK by looking at its sequence
numbers, seeing that they are next to the one from the SYNs.

> Now, you could say that if the tcp data length is greater than zero, then
> the packet is either *not* valid, or is *not* the third packet (although
> there was at one point a proposed tcp-like protocol that had data in the
> third packet, to keep down latency on short duration sessions, but I believe
> it's still considered evil in tcp-land).

That was called T/TCP, there were some problems hindering wide deploying,
if I remember correctly - and it would have permitted sending data already
along with the SYN packets, the third ACK having also a FIN, and thus
a full request/response connection in three packets.

best regards
  Patrick

Re: detection of the third tcp packet in a tcp connection setup

[Ramin Alidousti]

On Thu, Jun 27, 2002 at 09:06:54PM +0100, Antony Stone wrote:

> On Thursday 27 June 2002 8:57 pm, Ramin Alidousti wrote:
> 
> > If I'm not wrong you can always send data even in SYN and SYN/ACK.
> > Like Patrick said the default options in the socket interface might
> > not do it but I thought I saw some tweaking in one of Richard Steven's
> > (god bless his soul) books to push traffic in SYN packets.
> 
> Is that an interesting way to get round packet filtering firewalls ?

Why? The fw would either block the SYN (in case of DENY) or let the
SYN and any subsequent packet through...

> Send enough data (eg an http request) in a SYN packet so that the application 
> does the dirty work for you, even if the packet filter isn't going to allow 
> the connection to get ESTABLISHED ?

Again, if the SYN gets through, it's very likely that the connection
will get ESTABLISHED.

> Or do you have to fiddle with the receiving socket too in order for it to 
> cope with this ?

Good question. dunno.

Ramin

> Antony.

Re: detection of the third tcp packet in a tcp connection setup

[Antony Stone]

On Thursday 27 June 2002 9:31 pm, Ramin Alidousti wrote:

> On Thu, Jun 27, 2002 at 09:06:54PM +0100, Antony Stone wrote:

> > On Thursday 27 June 2002 8:57 pm, Ramin Alidousti wrote:
> > > If I'm not wrong you can always send data even in SYN and SYN/ACK.
> > > Like Patrick said the default options in the socket interface might
> > > not do it but I thought I saw some tweaking in one of Richard Steven's
> > > (god bless his soul) books to push traffic in SYN packets.
> >
> > Is that an interesting way to get round packet filtering firewalls ?
>
> Why? The fw would either block the SYN (in case of DENY) or let the
> SYN and any subsequent packet through...

Okay.   I'm having a bad evening.   That's the second stupid thing I've said 
in this thread.   I think my brain's gone awol.....

I hope it's back on-line tomorrow.

 

Antony.

RE: detection of the third tcp packet in a tcp connection setup

[James Mello]

TCP keep alive will send an ack with no payload for the previous octet
in the stream....


    -- Cheers
    -- James

> -----Original Message-----
> From: netfilter-admin@lists.samba.org 
> [mailto:netfilter-admin@lists.samba.org] On Behalf Of Antony Stone
> Sent: Thursday, June 27, 2002 12:31 PM
> To: netfilter@lists.samba.org
> Subject: Re: detection of the third tcp packet in a tcp 
> connection setup
> 
> 
> On Thursday 27 June 2002 8:10 pm, Joe Patterson wrote:
> 
> > catching the third packet is easy.  The hard part is to 
> both catch the 
> > third packet and *not* catch all of the rest of the ack packets.
> >
> > There are some distinguishing characteristics... it is the first 
> > packet sent by the client that is in state ESTABLISHED.  it should 
> > have ACK set and no other flags.  the tcp data length 
> should be zero.
> 
> Isn't that in itself a bit of a giveaway ?   I can't think of 
> a reason why a 
> zero-length packet should ever occur in the remainder of the 
> data stream... ?
> 
> There's a -m length --length <min>:<max> match somewhere, but 
> I'm not sure if 
> it's in the standard build or p-o-m
> 
>  
> 
> Antony.
> 
> 

Re: detection of the third tcp packet in a tcp connection setup

[Matthew G. Marsh]

On Thu, 27 Jun 2002, Maciej Soltysiak wrote:

> > > How to TCP keepalive packets look like? Also, isn't it possible that the
> > > third packet already carries data, in the general (read TCP protocol as
> > > it is written) case? You probably won't get that with the normal socket
> > > interface from userlevel, but does TCP forbid it? I don't think so.
> >
> > Correct. And besides when you receive data and have nothing to send
> > you'll ack with a zero-length packet.
> I agree.
>
> But that reminds me something.
> I had a problem once (not solved) with a novell server that used to send
> TCP packets with 2 bytes of data, then 52, then 2, then 52.
> It never sent packets filled to the MSS size as negotiated at the
> beginning.

Ummm - was this a 3.x or 4.x server (reason I ask is that I had a 3.x
server do this and I had to force the LIP option ON as well as fix an
intermediate router)? In 4.x this is fixed with a combo of the LIP and
some of the WAN link options (I forget which - have to go look).

> That caused the pop3 traffic to go terribly slow, and finally the server
> decided to close the connection due to timeout of not sending a mail
> message in time.

Yep - in my case it was actually the FTP session that did this...

> I tcpdumped the session, and did not see any, in my opinion, valid cause,
> like advertising a smaller tcp window.
>
> Also some (but not all) modem connection to the server had full 576 byte
> packets
>
> Any ideas on the cause?
>
> Regards,
> Maciej Soltysiak
>
>
>

--------------------------------------------------
Matthew G. Marsh,  President
Paktronix Systems LLC
1506 North 59th Street
Omaha  NE  68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW:  http://www.paktronix.com
--------------------------------------------------