Home page logo

pen-test logo Penetration Testing mailing list archives

RE: SummaryL Some unusual network features
From: "Jerry Shenk" <jshenk () decommunications com>
Date: Wed, 14 Jan 2004 16:32:13 -0500

You can do a lot with passive OS fingerprinting with p0f.  It's recently
been upgraded to so the config file that comes with it now has a lot
more stuff in it.  It's not quite complete but it can ID quite a bit.
You can also look through the database manually and see if you can match
things up when you have two or three OS' related to the same IP address
(which is what it looks like you have).

-----Original Message-----
From: Paul Johnston [mailto:paul () westpoint ltd uk] 
Sent: Wednesday, January 14, 2004 11:48 AM
To: pen-test () securityfocus com
Subject: SummaryL Some unusual network features


Thanks for everyone's responses to my questions. You've confirmed my 
original theories, and given some interesting new ideas. I'd be 
particularly interested in options for OS fingerprinting these devices. 
Neither nmap nor xprobe could do this; as all that is exposed are some 
open TCP ports. Could tools like p0f and ring help with this?

Summary of responses:

1) Ports that "hang open" i.e. you can connect, send data ok, but the
other end never sends any data and never closes the connection.

Could be:
a) TCP Discard service
b) Tarpit
c) Bespoke application that only responds to valid packets. I will try 
to do some further investigation of this.
d) A firewall or some device with incorrect config and no device behind

I favor option (d), because of the presense of ports match that match 
(3) discussed below.

There is no banner, and neither nmap -sV, amap nor find_service.nes 
could identify the port.
This is not merely a filtered port; you definitily do get a SYN-ACK back

from it.

2) HTTP ports that function normally when you issue some methods, but on
other methods (including the imaginary method "SILLY") cause the
connection to "hang open" like in (1).

Almost everyone seems to agree that this is some kind of application 
layer filter - be it a proxy, IPS, etc. I would favor the IPS theory, 
because I'd expect a proxy to return an error like "504 Bad Gateway" or 
something, not make the connection hang.

Note: it is unlikely this is a homegrown application as hmap identifies 
it as IIS5, and I've found hmap very reliable for identifying IIS.

3) Ports where the TTL is different on the SYN reply to the rest of the
connection. ipid's also imply that different hosts are handling the SYN
and the rest of the connection.

This is most likely some kind of SYN proxy, or "TCP intercept" in Cisco 
speak. Given this, I expect that (1) is where the router has SYN proxy 
enabled, but the back-end device no longer exists.

Thanks again for your input,

Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul () westpoint ltd uk
web: www.westpoint.ltd.uk



  By Date           By Thread  

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