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:HSKarimat_private] > Sent: Sunday, May 03, 1998 8:48 PM > To: smbat_private > Cc: firewallsat_private; firewall-wizardsat_private > Subject: Re: RST's and ACK's and stealth scans > > In a message dated 98-05-02 23:59:31 EDT, smbat_private 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 >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 12:58:38 PDT