RST packets

RST packets

[Jan Engelhardt]

Hi,


a simple question, though I could not clearly read it from the TCP RFC...
do RST packets always have ACK set?


Jan Engelhardt
-- 

Re: RST packets

[Rob Sterenborg]

> Hi,
>
>
> a simple question, though I could not clearly read it from the TCP RFC...
> do RST packets always have ACK set?

It seems that isn't so :

(http://www.knowplace.org/netfilter/ip_overview.html)

Resetting a connection

The four-way handshake is not the only way to tear down an established TCP
connection. Sometimes, if either hosts need to tear down the connection
quickly (timeout, port or host unreachable, etc.), a RST (Reset) packet is
sent. Note that since a RST packet is not necessarily always part of a TCP
connection, it can be sent by itself. RST packets that are part of a TCP
connection is usually accompanied by the ACK flag as well.

Note that RST packets are not acknowledged.



Gr,
Rob

Re: RST packets

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 18 Jul 2005, Jan Engelhardt wrote:

> Hi,
>
>
> a simple question, though I could not clearly read it from the TCP RFC...
> do RST packets always have ACK set?
>
>


Past discussions on this, if I recall have stated, that the RFC is unclear 
if they should or should not, and thus it is implimentation specific.  In 
other words prepare for both.

Thanks,

Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFC29s0st+vzJSwZikRAhFhAJ9VrBg8udgLE/rjWj69PZI+xj/J1QCg21bk
Nv2IJV8hI5/AhxnInjSMq5Y=
=OiGE
-----END PGP SIGNATURE-----

Re: RST packets

[Jozsef Kadlecsik]

Hi,

On Mon, 18 Jul 2005, Jan Engelhardt wrote:

> a simple question, though I could not clearly read it from the TCP RFC...
> do RST packets always have ACK set?

No, see RFC793 page 64:

SEGMENT ARRIVES
...
If the state is LISTEN then

      first check for an RST

        An incoming RST should be ignored.  Return.

      second check for an ACK

        Any acknowledgment is bad if it arrives on a connection still in
        the LISTEN state.  An acceptable reset segment should be formed
        for any arriving ACK-bearing segment.  The RST should be
        formatted as follows:

          <SEQ=SEG.ACK><CTL=RST>

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: RST packets

[Grant Taylor]

>
>
>a simple question, though I could not clearly read it from the TCP RFC...
>do RST packets always have ACK set?
>
If memory serves me right the appearance of the ACK flag in a packet 
with the RST flag is based on the packet that the packet with the RST 
flag is setting.  In other words if the packet that is being reset has 
the ACK flag set then the ACK flag will not be set in the packet with 
the RST flag.  Conversely if the packet that is being reset does not 
have the ACK flag set then the ACK flag will be set in the packet with 
the RST flag.  Translation I think it is an XOR issue.

Note:  This was based on many hours of reading and following RFCs and 
other things.  This was the simplest summarization that I could find at 
the time.  I think I have a different reply to this mail list talking 
about using the recent match extension to test for stray RST packets, I 
could look back and see what I can find in my notes if you would like me to.



Grant. . . .

Re: RST packets

[Jan Engelhardt]

Hi,


>http://www.knowplace.org/netfilter/ip_overview.html

|Sometimes, if either hosts need to tear down the connection quickly (timeout, 
|port or host unreachable, etc.), a RST (Reset) packet is sent. Note that 
|since a RST packet is not necessarily always part of a TCP connection, it can be 
|sent by itself. RST packets that are part of a TCP connection is usually 
|accompanied by the ACK flag as well.

What would be the use of RST if it is not part of a connection?
Is it...vv?
  A and B are connected
  A crashes
  B tries to send
  A sends RST,!ACK



Jan Engelhardt
-- 

Re: RST packets

[Rob Sterenborg]

> |Sometimes, if either hosts need to tear down the connection quickly
> (timeout,
> |port or host unreachable, etc.), a RST (Reset) packet is sent. Note that
> |since a RST packet is not necessarily always part of a TCP connection, it
> can be
> |sent by itself. RST packets that are part of a TCP connection is usually
> |accompanied by the ACK flag as well.
>
> What would be the use of RST if it is not part of a connection?
> Is it...vv?
>   A and B are connected
>   A crashes
>   B tries to send
>   A sends RST,!ACK

Your scenario seems clear to me.. ;-)

If A crashes, to A there is no connection anymore.
If B sends data to A and A thinks no SYN/ACK has occurred for that
connection, IMHO A should send RST without ACK because according to A
there _is_ no connection to send ACK for.
Anyway, I didn't test it but it would make sense to me.


Gr,
Rob

Re: RST packets

[Jörg Harmuth]

Jan Engelhardt schrieb:

> What would be the use of RST if it is not part of a connection?
> Is it...vv?
>   A and B are connected
>   A crashes
>   B tries to send
>   A sends RST,!ACK

Yes, half-open connections. The other purpose is to recover from
duplicate SYNs, where SYN2 arrives before SYN1, which could confuse
TCPs. See figure 9 in RFC793, p. 32ff for a discussion of RST generation
and processing.

Have a nice time,

Joerg

RST packets

[Peter Marshall]

I am having a problem now where I am getting RST packets being blocked from
my internal network heading out to the external network.  It looks like RST
packets are used to stop a TCP connection when there is a problem.

The setup is like this:
I have a web box in my dmz that people connect to.  A mod-jk connection is
made through my firewall, and the responses are allowed back with the
standard ESTABLISHED,RELATED allow on the Forward chain.

I guess I was wondering why I was getting a bunch of RST packets and also,
why the firewall was blocking them.  Would they not be part of the
ESTABLISED-RELATED chain ?

Here are the relevant rules.
$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s $WEB_BOX_IP -I eth1 -j web-int
$IPT -A web-int -d 192.168.202.168 -p tcp --dport 8009:8020 -j ACCEPT

I do have a chain for int-web ... which is used to connect to a webserver
running on it ..(and it rejects everything else).  This is the chain that
the RST packet is making it too and is then getting rejected.  However, I
did not think that the packet should reach this chain as it is related (or
establised) to the web-int connection ...

Any suggestions would be greatly appreciated.  My network set up is a DMZ
between two firewalls.  The web box is in the DMZ.  The "int" in my chains
is my internal network.  the internal network is separated form the DMZ by a
firewall.

Peter Marshall

Re: RST packets

[Peter Marshall]

I have been looking on the web about this now all day .. still nothing .. is
there anyone out there who has experienced this problem ????  Any help would
be greatly appreciated.

Thanks again,
Peter Marshall

----- Original Message ----- 
From: "Peter Marshall" <peter.marshall@caris.com>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, August 11, 2004 6:00 PM
Subject: RST packets


I am having a problem now where I am getting RST packets being blocked from
my internal network heading out to the external network.  It looks like RST
packets are used to stop a TCP connection when there is a problem.

The setup is like this:
I have a web box in my dmz that people connect to.  A mod-jk connection is
made through my firewall, and the responses are allowed back with the
standard ESTABLISHED,RELATED allow on the Forward chain.

I guess I was wondering why I was getting a bunch of RST packets and also,
why the firewall was blocking them.  Would they not be part of the
ESTABLISED-RELATED chain ?

Here are the relevant rules.
$IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

$IPT -A FORWARD -s $WEB_BOX_IP -I eth1 -j web-int
$IPT -A web-int -d 192.168.202.168 -p tcp --dport 8009:8020 -j ACCEPT

I do have a chain for int-web ... which is used to connect to a webserver
running on it ..(and it rejects everything else).  This is the chain that
the RST packet is making it too and is then getting rejected.  However, I
did not think that the packet should reach this chain as it is related (or
establised) to the web-int connection ...

Any suggestions would be greatly appreciated.  My network set up is a DMZ
between two firewalls.  The web box is in the DMZ.  The "int" in my chains
is my internal network.  the internal network is separated form the DMZ by a
firewall.

Peter Marshall

Re: RST packets

[Chris Brenton]

On Thu, 2004-08-12 at 12:58, Peter Marshall wrote:
>
> I am having a problem now where I am getting RST packets being blocked from
> my internal network heading out to the external network.  It looks like RST
> packets are used to stop a TCP connection when there is a problem.

Per chance do you have a tcpdump trace of the activity? RST's are
usually an indication of one or two problems:
1) One end of the session has stopped responding
2) Connection attempt to a closed port

There are other reasons, but these are the most common. You may want to
investigate why you are seeing the RSTs packets in the first place.
Sounds like the problem might be broken communications.

> The setup is like this:
> I have a web box in my dmz that people connect to.  A mod-jk connection is
> made through my firewall, and the responses are allowed back with the
> standard ESTABLISHED,RELATED allow on the Forward chain.

What errors (if any) are you seeing in mod_jk.log? 

> I guess I was wondering why I was getting a bunch of RST packets and also,
> why the firewall was blocking them.  Would they not be part of the
> ESTABLISED-RELATED chain ?

If a valid session has been established, the first issued RST will be
considered part of that session. Netfilter does work this way as I have
confirmed through many a traces. The only reason I can think of for
Netfilter to block the RST is that it does not have a state entry for
the traffic.

> Here are the relevant rules.
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> $IPT -A FORWARD -s $WEB_BOX_IP -I eth1 -j web-int
> $IPT -A web-int -d 192.168.202.168 -p tcp --dport 8009:8020 -j ACCEPT

I assume there are other rules as I *think* mod-jk starts off on 80/TCP.
Also, I thought ports all the way down to 8005 were valid? Check me on
this as its been a while.

> I do have a chain for int-web ... which is used to connect to a webserver
> running on it ..(and it rejects everything else).  This is the chain that
> the RST packet is making it too and is then getting rejected.  However, I
> did not think that the packet should reach this chain as it is related (or
> establised) to the web-int connection ...

This is a pretty clear indication that there is no state entry for the
packet. Again, a trace would help to diagnose this.

> Any suggestions would be greatly appreciated.  My network set up is a DMZ
> between two firewalls.  The web box is in the DMZ. 

Not a big fan of this setup as whacking the Web server permits an
attacker to sniff all your inbound and outbound traffic. Greatly prefer
to add a third NIC to the firewall and isolate the system. Just a
personal preference.

HTH,
Chris

Re: RST packets

[Peter Marshall]

Thanks for the suggestions ... I will have a look at the mod_jk logs ....

Peter

----- Original Message ----- 
From: "Chris Brenton" <cbrenton@chrisbrenton.org>
To: "Peter Marshall" <peter.marshall@caris.com>
Cc: "netfilter" <netfilter@lists.netfilter.org>
Sent: Friday, August 13, 2004 12:17 PM
Subject: Re: RST packets


On Thu, 2004-08-12 at 12:58, Peter Marshall wrote:
>
> I am having a problem now where I am getting RST packets being blocked
from
> my internal network heading out to the external network.  It looks like
RST
> packets are used to stop a TCP connection when there is a problem.

Per chance do you have a tcpdump trace of the activity? RST's are
usually an indication of one or two problems:
1) One end of the session has stopped responding
2) Connection attempt to a closed port

There are other reasons, but these are the most common. You may want to
investigate why you are seeing the RSTs packets in the first place.
Sounds like the problem might be broken communications.

> The setup is like this:
> I have a web box in my dmz that people connect to.  A mod-jk connection is
> made through my firewall, and the responses are allowed back with the
> standard ESTABLISHED,RELATED allow on the Forward chain.

What errors (if any) are you seeing in mod_jk.log?

> I guess I was wondering why I was getting a bunch of RST packets and also,
> why the firewall was blocking them.  Would they not be part of the
> ESTABLISED-RELATED chain ?

If a valid session has been established, the first issued RST will be
considered part of that session. Netfilter does work this way as I have
confirmed through many a traces. The only reason I can think of for
Netfilter to block the RST is that it does not have a state entry for
the traffic.

> Here are the relevant rules.
> $IPT -A FORWARD -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT
>
> $IPT -A FORWARD -s $WEB_BOX_IP -I eth1 -j web-int
> $IPT -A web-int -d 192.168.202.168 -p tcp --dport 8009:8020 -j ACCEPT

I assume there are other rules as I *think* mod-jk starts off on 80/TCP.
Also, I thought ports all the way down to 8005 were valid? Check me on
this as its been a while.

> I do have a chain for int-web ... which is used to connect to a webserver
> running on it ..(and it rejects everything else).  This is the chain that
> the RST packet is making it too and is then getting rejected.  However, I
> did not think that the packet should reach this chain as it is related (or
> establised) to the web-int connection ...

This is a pretty clear indication that there is no state entry for the
packet. Again, a trace would help to diagnose this.

> Any suggestions would be greatly appreciated.  My network set up is a DMZ
> between two firewalls.  The web box is in the DMZ.

Not a big fan of this setup as whacking the Web server permits an
attacker to sniff all your inbound and outbound traffic. Greatly prefer
to add a third NIC to the firewall and isolate the system. Just a
personal preference.

HTH,
Chris