Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: TCP Split Handshake and Nmap
From: David Fifield <david () bamsoftware com>
Date: Tue, 8 Jun 2010 19:25:42 -0600

On Wed, Jun 09, 2010 at 12:58:38AM +0100, jah wrote:
On 08/06/2010 18:26, David Fifield wrote:
On Fri, Jun 04, 2010 at 04:22:55PM +0100, jah wrote:
The attached patch does very little work since the split handshake SYN
passes the existing checks for dest port matching a probe source port;
it adds a test for the SYN flag right after the test for SYN|ACK for SYN
+         } else if (USI->scantype == SYN_SCAN && tcp->th_flags == TH_SYN) {

Just one thing I would change here:

+         } else if (USI->scantype == SYN_SCAN && (tcp->th_flags & TH_SYN) == TH_SYN) {

That way it will work with a SYN|URG or SYN|PSH or something else silly.
Putting this test after the SYN|ACK test lets SYN|ACK continue giving
the correct reason code.

If we're going make the rule catch all resposes with the SYN bit set
(and optionally other bits), except for SYN|ACK, perhaps the reason
string should be changed also because "split-hanshake-syn" wouldn't then
convey the full information.  We could instead leave the reason string
as it is and print a message to the effect that a response received was
evidence of a split handshake and print the tcp flag value.  Or we could
do both and make the reason string 'syn-other' or something.

We could also add a flags member to struct port_reason to record the
flags, and then print them out separately after the reason, like we do
when handling the TTL and IP address reason information.

David Fifield
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]