From: Don Parker (dparker@rigelksecurity.com)
Date: Wed Jan 14 2004 - 17:14:59 EST
Well I am unsure as to the exact intent of your question here. If you get any stimulus
back at all from said computer ie: syn/ack then you can make an educated guess as to
it's o/s. If you believe you may be dealing with a Cisco router then simply follow up
with a scan of this IP address. Cisco routers by default will listen on port 1900 (I
believe). HTH
Cheers
-------------------------------------------
Don Parker, GCIA
Intrusion Detection Specialist
Rigel Kent Security & Advisory Services Inc
www.rigelksecurity.com
ph :613.249.8340
fax:613.249.8319
--------------------------------------------
On Jan 14, Paul Johnston <paul@westpoint.ltd.uk> wrote:
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