From: Jean-Baptiste Marchand (Jean-Baptiste.Marchand@hsc.fr)
Date: Tue Oct 21 2003 - 17:27:48 EDT
* James Bowman <jim@drexel.edu> [21/10/03 - 20:26]:
> Question is - "is it possible that Nessus and Netstat were reading an
> established connection or were these real listeners?"
Nessus can not be confused because Nessus scans the machine for opened
ports and only reports ports really opened (i.e, for TCP, ports which
will accept a TCP connection).
What you've just realized is that netstat incorrectly reports TCP
sockets in the LISTENING state.
I've described the problem in my Windows network services minimization
paper:
http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html
which contains the following section:
-----------------------------------------------------------------------
The netstat command does not exactly report TCP and UDP ports states.
Instead, it reports state of TDI transport addresses and connection
endpoints, whereas only TDI connection endpoints represent TCP or UDP
sockets.
In particular, when a Windows system establishes an outgoing TCP
connection (active open), the local port used as source is reported as
in the LISTENING state.
In the following example, the local system has established a TCP
connection from source port 1367 to destination port 22 of a remote
system.
The netstat command output, filtered to show only lines containing port
number 1367 is:
C:\WINDOWS>netstat -anp tcp | find ":1367"
TCP 0.0.0.0:1367 0.0.0.0:0 LISTENING
TCP 192.70.106.142:1367 192.70.106.76:22 ESTABLISHED
The second line shows the established connection, from local port 1367
to remote port 22. However, the first line is incorrect because it
reports local port 1367 in the LISTENING state, whereas no TCP server is
available on this port.
Thus, for each outgoing TCP connection, an additional line will appear
in netstat output, showing a TCP port in LISTENING state. It is
important to make the difference between an opened TCP port and one
incorrectly reported by netstat in the LISTENING state.
Note: this bug has been fixed in Windows Server 2003.
-----------------------------------------------------------------------
Note that the bug is in the API used by netstat and not netstat itself.
Thus, any program that use the same API (GetTcpTable()) is also affected
by the same bug.
Jean-Baptiste Marchand
-- Jean-Baptiste.Marchand@hsc.fr HSC - http://www.hsc.fr/ --------------------------------------------------------------------------- FREE Whitepaper: Better Management for Network Security Looking for a better way to manage your IP security? Learn how Solsoft can help you: - Ensure robust IP security through policy-based management - Make firewall, VPN, and NAT rules interoperable across heterogeneous networks - Quickly respond to network events from a central console Download our FREE whitepaper at: http://www.securityfocus.com/sponsor/Solsoft_pen-test_031015 ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:41 EDT