> -----Original Message-----
> From: Carl E. Mankinen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 06, 2001 6:40 AM
> To: Eliyah Lovkoff
> Cc: [EMAIL PROTECTED]
> Subject: Re: FIN_WAIT_2
> 
> 
> ACK, SYN, FIN, RST, PSH - all flags/parts of TCP session 
> setup/teardown etc.
> Read the book TCP/IP Illustrated from Stevens/Wright, it's 
> recommended and well worth it.

TCP/IP Illustrated is an awesome book. RFC 793 is also a good read (yes, I
know I keep recommending RFCs - I think I have some sort of sickness).

[...]
> If you send a packet with a FIN set, but not having first 
> established a session thru the threeway handshake....the 
> firewall will see
> this as a packet belonging to a session that was not 
> established properly and drop it under rule 0. Some tcp/ip 
> stacks might
> actually respond to the FIN

It's correct to send a RST in response to a spurious FIN. The finer points
of RST generation came up quite a bit in the recent ECN thread on fw-wiz, so
that's probably worth a peek if anyone is interested. The FIN scan basically
works by asserting that FIN-> followed by RST<- is a host and a FIN->
followed by an ICMP<- is a firewalled port. FIN scanning is not useful for
mapping open / closed ports on hosts.

[...]
> Anyone want to correct me, I am sure I have oversimplified this....

Seemed pretty accurate to me. One thing that is worth clarifying in terms of
the original question, though - FIN_WAIT states can't happen as a result of
a scan. You can only get into FIN_WAIT (1 or 2) if you have sent the FIN
yourself. Receiving a FIN takes you straight into  CLOSE_WAIT. You can find
a lovely ASCII-art (YUCK) flowchart in RFC 793 on page 22.

In other words, if this is a scan then it was a connect() scan, because
that's the only one that creates a valid TCB for the firewall to decide to
close. It's quite possible that the h4x0r is trying all the nmap scan types,
one after the other.

Cheers,

--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520  PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to