On Sun, 18 Sep 2005 09:11:18 -0400, Lars M. Hansen
<badnews@hansenonline.net> wrote:
>On 13 Sep 2005 22:34:59 +0200, Volker Birk spoketh
>
>>Jim Scott <mr.jimscott@xvirgin.net> wrote:
>>> > jameshanley39@yahoo.co.uk wrote:
>>> >> so, i'm wondering 'what would VB do?'
>>> > VB would do a netstat -ano or a lsof -i and check, what's offered.
>>> > This is best anyway. ;-)
>>> What would he be looking out for?
>>
>>He'd looking out for processes listen()ing, and not listen()ing on
>>localhost 127.0.0.1.
>>
>>Yours,
>>VB.
>
>Actually, anything listening on 127.0.0.1 would be harmless anyways, as
>it would only accept local (host) connections.
>
>The things to look out for are anything listening on 0.0.0.0 or the
>actual IP address of the machine.
Netstat "listening" isn't always accurate. Below is a paste from a
article by Marchand:
http://www.hsc.fr./ressources/breves/min_srv_res_win.en.html
*************************************
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.
***************************************
I've seen misleading netstat -an reports myself on Win 2K Pro where it
seems that some port numbered >1023 might be "open" but port scanning
web sites report it as closed.
Art
http://home.epix.net/~artnpeg
Received on Thu Sep 29 20:09:06 2005