From: Jerry Shenk (jshenk@decommunications.com)
Date: Wed Jan 14 2004 - 16:32:13 EST
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
Hi,
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
it.
I favor option (d), because of the presense of ports match that match
(3) discussed below.
Note:
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
-- Paul Johnston Internet Security Specialist Westpoint Limited Albion Wharf, 19 Albion Street, Manchester, M1 5LN England Tel: +44 (0)161 237 1028 Fax: +44 (0)161 237 1031 email: paul@westpoint.ltd.uk web: www.westpoint.ltd.uk ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ ---- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:45 EDT