Re: SummaryL Some unusual network features

["Don Parker" <dparker () rigelksecurity com>]

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


---------------------------------------------------------------------------
----------------------------------------------------------------------------



---------------------------------------------------------------------------
----------------------------------------------------------------------------