RE: RST's and ACK's and stealth scans

["Franz, Matt" <Matt_Franz () tds com>]

If this helps, here's the logs from tcpdump for a normal (full connect)
tcp scan, syn, and fin scan. Fyodor's nmap was used for all the scans.
All scans were conducted from 192.168.0.2 against 192.168.0.3 (both
running Linux 2.0.33)

NORMAL SCAN
PORT 21 (Open)
09:43:44 192.168.0.2.4218 > 192.168.0.3.21: S 3335535104:3335535104(0) 
09:43:44 192.168.0.3.21 > 192.168.0.2.4218: S 2861817356:2861817356(0)
ack 3335535105
09:43:44 192.168.0.2.4218 > 192.168.0.3.21: . ack 2861817357
PORT 22 (Closed)
09:43:44 192.168.0.2.4219 > 192.168.0.3.22: S 1070105363:1070105363(0)
09:43:44 192.168.0.3.22 > 192.168.0.2.4219: R 0:0(0) ack 1070105364

SYN SCAN
PORT 21 (Open)
10:22:45.030552 192.168.0.2.49724 > 192.168.0.3.21: S
2421827136:2421827136(0)
10:22:45.030552 192.168.0.3.21 > 192.168.0.2.49724: S
4046313668:4046313668(0) ack 2421827137
10:22:45.030552 192.168.0.2.49724 > 192.168.0.3.21: R
2421827137:2421827137(0)
PORT 22 (Closed)
10:22:45.050552 192.168.0.2.49724 > 192.168.0.3.22: S
2418821749:2418821749(0)
10:22:45.050552 192.168.0.3.22 > 192.168.0.2.49724: R 0:0(0) ack
2418821750

FIN SCAN
Port 20 (Closed)
10:50:02  192.168.0.2.49724 > 192.168.0.3.20: F 685252904:685252904(0) 
10:50:02  192.168.0.3.20 > 192.168.0.2.49724: R 0:0(0) ack 685252904
Port 21 (Open)
10:50:02  192.168.0.2.49724 > 192.168.0.3.21: F 1469493665:1469493665(0)
10:50:02  192.168.0.2.49724 > 192.168.0.3.21: F 131594363:131594363(0)
10:50:02  192.168.0.2.49724 > 192.168.0.3.21: F 2601183149:2601183149(0)


> ----------
> From:         HSKarim[SMTP:HSKarim () aol com]
> Sent:         Sunday, May 03, 1998 8:48 PM
> To:   smb () research att com
> Cc:   firewalls () GreatCircle COM; firewall-wizards () nfr net
> Subject:      Re: RST's and ACK's and stealth scans
>
> In a message dated 98-05-02 23:59:31 EDT, smb () research att com writes:
>
> << [...snip...]
>  Once a connection is set up (that is, has transitioned to ESTABLISHED
>  state), all packets will carry the ACK bit.  They must also carry an
>  acceptable sequence number.  These provisions both apply to RST
> messages,
>  too.  In this case, though, a RST means that the other side has
> aborted
>  the connection for some reason.
>  [...snip...]
>  
>  What flavor RST your firewall should send depends on the connection
>  state; if it gets it wrong, the remote side probably won't listen.
>  That's definitely the case for a bare RST on an established
> connection.
>  
>  For more details, see RFC 793 and/or a good text on TCP, such as
>  Stevens' ``TCP/IP Illustrated, Volume I''.
>   >>
> Steve...
>
> I checked RFC 793... but my issues are.... If I am under a stealth
> scan...
> that is, if someone sent packets that appeared to be a part of another
> connection (by virtue of the ACK bit being set) but weren't really...
> what
> should I expect to see coming from my firewall in the following cases:
>
> Scenario... Attacker is coming from Host A and Im at HOST B. Nothing
> is
> listening on any port. The Initial TCP sequence is some arbitrary
> number (lets
> say 1234)
>
> HOST A sends SYN --------------------->HOST B 
> HOST B Should send RST without ACK
>
> HOST A sends ACK  --------------------->HOST B 
> HOST B Should send what ?
>
> HOST A sends SYN/ACK --------------------->HOST B 
> HOST B Should send RST with ACK .... (Right? But, what ACK'ed it? No
> services
> running)
>
> HOST A sends FIN --------------------->HOST B 
> HOST B Should send what ?
>
> HOST A sends FIN/ACK --------------------->HOST B 
> HOST B Should send what ?
>
> Once again... I'm just trying to get clarification as to whether RST
> should
> ALWAYS be accompanied by ACK's or not. And if they are accompanied by
> ACK's is
> it a valid conclusion that  there was a TCP service listening? 
>
> Thanks for all of the responses thus far...
> Hassan Karim