Please help interpret Sygate Personal Firewall traffic log (ndisuio.sys)

I was trying to understand what my WinXP PC is doing with respect to security issues.

To you, an expert, it's "obvious" that there is no foreign address connected to that port - but to me, a social worker, it wasn't obvious at all that an IP address of 0.0.0.0 actually refered to any network interface on my machine that had the TCP/IP protocol stack bound to it (thanks to experts Dom & Volker Birk & Eirik Seim).

The good news is we blocked port 1900 & 445 respectively by modifying: HKLM\\Software\\Microsoft\\DirectPlayNATHelp\\DPNHUPnP\\UPnPMode HKLM\\System\\CurrentControlSet\\Services\\NetBT\\Parameters\\TransportBindName

But, while these steps may are obvious to all you experts, they are not anywhere near obvious to me - so I much appreciate the help!

Now when I run netstat, TCP/IP ports 1900 & 445 are no longer listening! c:\\> netstat -abn | find "1900" c:\\> netstat -abn | find "445"

I wish I knew how to block ports using just the Sygate Personal Firewall or the Dlink NAT router because then one method would work for all ports instead of finding the cryptic (to me) registry key that kills the port.

I'll try to keep looking, asking, answering, and learning! Susan

Thank you for the explanation of 0.0.0.0:0 (it sure was confusing to me that something that looked like a blank IP address actually referred to a network interface).

Now that I've eliminated dozens of services and closed up a few ports by judicious (if cryptic) modifications of the Windows XP registry (see thread above for detaqils), and even eliminated the eacfilt.sys problem which nobody on the Intenet who had that problem seems to have accomplished according to the google record, I am sorry to say I am *still* left with trying to better understand the original issue which combines three things:

- Port 1900

- ndisuio.sys

- Upnp

Even though I turned off port 1900 and UpnP, I still see:

NDIS User mode I/O driver (ndisuio.sys) has received a Multicast packet from the remote machine [192.168.0.10]. Do you want to allow this program to access the network?

File Version : 5.1.2600.2180 File Description : NDIS User mode I/O Driver (ndisuio.sys) File Path : C:\\WINDOWS\\system32\\DRIVERS\\ndisuio.sys Connection origin : remote initiated Protocol : UDP Local Address : 239.255.255.250 Local Port : 1900 (SSDP - Simple Service Discovery Protocol) Remote Name : Remote Address : 192.168.0.10 Remote Port : 1900 Ethernet packet details: Ethernet II (Packet Length: 294) Destination: ff-ff-ff-ff-ff-ff Source: 00-80-c8-a0-43-9b Type: IP (0x0800) Internet Protocol Version: 4 Header Length: 20 bytes Flags: .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset:0 Time to live: 127 Protocol: 0x11 (UDP - User Datagram Protocol) Header checksum: 0x3a5c (Correct) Source: 192.168.0.10 Destination: 239.255.255.250 User Datagram Protocol Source port: 1900 Destination port: 1900 Length: 8 Checksum: 0x26bc (Correct) Data (260 Bytes)

Binary dump of the packet:

0000: FF FF FF FF FF FF 00 80 : C8 A0 43 9B 08 00 45 00 | ..........i...E. 0010: 01 18 2D F7 00 00 7F 11 : 5C 3A C0 A8 00 01 EF FF | ..-.....\\:...... 0020: FF FA 07 6C 07 6C 01 04 : BC 26 4E 4F 54 49 46 59 | ...l.l...&NOTIFY 0030: 20 2A 20 48 54 54 50 2F : 31 2E 31 0D 0A 48 4F 53 | * HTTP/1.1..HOS 0040: 54 3A 32 33 39 2E 32 35 : 35 2E 32 35 35 2E 32 35 | T:239.255.255.25 0050: 30 3A 31 39 30 30 0D 0A : 43 41 43 48 45 2D 43 4F | 0:1900..CACHE-CO 0060: 4E 54 52 4F 4C 3A 6D 61 : 78 2D 61 67 65 3D 31 32 | NTROL:max-age=12 0070: 30 0D 0A 4C 4F 43 41 54 : 49 4F 4E 3A 68 74 74 70 | 0..LOCATION:http 0080: 3A 2F 2F 31 39 32 2E 31 : 36 38 2E 30 2E 41 3A 35 | :/192.168.0.10:5 0090: 36 37 38 2F 69 67 64 2E : 78 6D 6C 0D 0A 4E 54 3A | 678/igd.xml..NT: 00A0: 75 70 6E 70 3A 72 6F 6F : 74 64 65 76 69 63 65 0D | upnp:rootdevice. 00B0: 0A 4E 54 53 3A 73 73 64 : 70 3A 61 6C 69 76 65 0D | .NTS:ssdp:alive. 00C0: 0A 53 45 52 56 45 52 3A : 45 6D 62 65 64 64 65 64 | .SERVER:Embedded 00D0: 20 55 50 6E 50 2F 31 2E : 30 0D 0A 55 53 4E 3A 75 | UPnP/1.0..USN:u 00E0: 75 69 64 3A 75 70 6E 70 : 2D 49 6E 74 65 72 6E 65 | uid:upnp-Interne 00F0: 74 47 61 74 65 77 61 79 : 44 65 76 69 63 65 2D 31 | tGatewayDevice-1 0100: 5F 30 2D 31 32 33 34 35 : 36 37 38 39 30 30 30 30 | _0-1234567890000 0110: 31 3A 3A 75 70 6E 70 3A : 72 6F 6F 74 64 65 76 69 | 1::upnp:rootdevi 0120: 63 65 0D 0A 0D 0A : | ce....

I can't delete ndisio.sys (I tried, it just comes back). I block these requests automatically in Sygate Personal Firewall.

But, what is all that stuff in this log above trying to tell me?

And, is there a way to block this stuff at the Dlink NAT router so it never even gets to my Windows XP PC?

Less confused than when I started but still confused a bit, Susan

The Ethernet source is that of the router, yet the IP source is that of the computer. This is just multicast traffic from the computer which has been propagated back to the computer by the AP/switch. It is not from the Internet.

Have you removed gateway discovery from add/remove windows components? Have you yet to disable the uPNP features of the router?

You're right.

Did you read Torsten's site on

? This is Torsten's main topic there.

Yes.

Yours, VB.

To better understand TCP/IP networking, you could read the TCP/IP entry of Wikipedia, and you could read Craig Hunt's excellent book "TCP/IP", published ny O'Reilly.

You could just start the Windows-Firewall. That will do.

Nice to hear ;-)

Yours, VB.

Actually, the above may be a bit erroneous. It's difficult to say.

I have not read Hunt's work, but I find Richard Stevens' books, and especially the "illustrated" series, to still be very good even more than a decade after their first print:

for instance.

If only more people had that attitude :)

After researching further the meaning of the 0.0.0.0 designation, I found the following web site which seems invaluable for newbies such as I am to better understand the cryptic nature of the netstat -an command.

I post it here so that the many others who read this may benefit.

This web page delves into the specifics of the result interpretation, for example, it says for 'ESTABLISHED' connections, you need the remote port to identify what has connected to the remote site. For those 'LISTENING', you need the local port to identify what is listening there. Each outbound TCP connection also causes a LISTENING entry on the same port. Most UDP listening ports are duplicates from a listening TCP port. Ignore them unless they don't have a TCP twin. TIME_WAIT entries are not important. If it says 0.0.0.0 on the Local Address column, it means that port is listening on all 'network interfaces' (i.e. your computer, your modem(s) and your network card(s)). If it says 127.0.0.1 on the Local Address column, it means that port is ONLY listening for connections from your PC itself, not from the Internet or network. No danger there. If it displays your online IP on the Local Address column, it means that port is ONLY listening for connections from the Internet. If it displays your local network IP on the Local Address column, it means that port is ONLY listening for connections from the local network. Most browsers use multiple connections to fetch webpages to speed up the process. etcetera.

Torsten's site points to useful information for me and others. For example, I was unaware WEP wireless encryption was cracked long ago!

Torsten seems to recommend Windows XP users close specific ports. I have not closed all of these yet, as I'm compiling how to do so.

Is this the best approach to close dangerous ports on Windows XP?

1. Close TCP port 135 (rpc, dcom, rpcss, epmap, messenger, scheduler, etc) Set HKLM\Software\Microsoft\OLE\EnableDCOM = N Set HKLM\Software\Microsoft\OLE\EnableRemoteConnect = N Delete C:\WINDOWS\SYSTEM\RPCSS.EXE. Start,Run,dcomcnfg.exe,applications,
2. Close the NetBios trio TCP port 137, port 138, & port 139
   formatting link
   Control Panel, Performance and Maintenance,Administrative Tools, Messenger, Right-click and select Properties. Select the Stop button, choose Startup Type, and then pick Disable.
3. Close the UDP port 137 & port 138 Control Panel, Network, File & Printer Sharing, deselect both options.
4. Close port 445 (SMB, microsoft-ds file & print sharing) Delete the value for HKLM\System\CurrentControlSet\Services\NetBT\Parameters\ TransportBindName = (blank out this value)
   formatting link
   's_port_445_in_w2k_xp_2003.htm Control Panel, Dial-Up & Network Connctions, Advanced, Bindings, unbind File & Printer Sharing from the TCP/IP protocol
   formatting link
5. Close port 1025 (scheduler service)
   formatting link
6. Close port 1026 (mtaskp)
   formatting link
7. Close port 1900 (ssdp) HKLM\Software\Microsoft\DirectPlayNATHelp\DPNHUPnP\UPnPMode Type: REG_DWORD Value: 2 (ie disabled) As per:
   formatting link
8. Close all ports greater than 3000 (alg)
9. Close TCP port 5000 UPNP Control Panel, Add/Remove Software, Universal Plug & Play, Remove, OK.
10. Close ports greater than 3000 (alg)

I'm still working on how to close these ports in WinXP so consider this unfinished work. But first, I need some sleep tonight.

?Security is not a destination - it is a mindset?

[ quotes from url: ]

[snip]

I believe that bug is fixed in more recent versions of Windows. I rarely use Windows, but I try to keep up with its networking capabilities...

Does this mean netstat do not see the difference? Or will Windows actually listen to both? Any Windows gurus around? :)

Unless there are many of them, which could indicate misbehaving applications, operating system bugs, or attackers. But it would have to be a pretty stupid attacker, because (a) they are easily spotted, and (b) there's no reason to leave the connection like that.

TIME_WAIT is a state most TCP connections go through when closing, and part of the so-called four way handshake that is considered the polite way of closing a connection. The handshake is simple, say computers Alice and Bob has a connection. Alice says "I want to hang up, goodbye!", Bob responds with "Ok! But now I want to hang up as well!", and then finally Alice responding "Ok!".

If Alice fails to send that last "Ok!", Bob's end of the connection might stay in the TIME_WAIT state for several minutes before it times out.

Yes. For a programmer, this is the right thing. But for a technician, which does not hack herself/himself, maybe Hunt's books are a very good idea.

Yes. Indeed.

Yours, VB.