On Monday 20 February 2006 11:51 pm, Susan had this to say in microsoft.public.windowsxp.general:
I don't understand why you're getting into a panic over this thing? So it's listening on a port. There is obviously no foreign address connected to that port so is of no consequence. Don't you have more important things in life to worry about, such as global warming, or world poverty or the warmongering Bush administration?
First off, the "port 445"-thing is an open TCP port signifying that Windows services for file, print and authentication services are active. TCP is the protocol, which is a layer in what is commonly called "TCP/IP protocol stack". This is a protocol for communicating between computer systems, basically.
Yes to those, assuming the windows networking protocol (whatever it's called, been a long day...) is bound to the interfaces. It is rather uncommon to bind the protocol to firewire cards by default, and even if it were bound there, it wouldnt become a security issue until someone connected a firewire-wire to the port.
No, usb provides connectivity for things like flash memory (the "usb pen"-ish thingies), network cards, and more, but there is no TCP/IP protocol stack on the USB interface.
There might be such a protocol stack on a ethernet or wireless ethernet card, _connected_ to the USB bus, but they would show up in Windows as regular network interfaces anyways.
Bluetooth is increasingly used, but I'm not familiar with the protocols commonly used. If you don't use bluetooth, it is safe to disable. If you use it, take comfort in the fact that it's range is very limited, and disable it when done using it...
No, there's no TCP/IP protocol stack on the IDE card.
Possibly, but very unlikely. Use same precations as with Bluetooth.
What it means is that it's listening to every network interface that has a suitable (TCP/IP) protocol stack associated with it.
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)
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?
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.
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:
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.
formatting link
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?
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,
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.
Close the UDP port 137 & port 138 Control Panel, Network, File & Printer Sharing, deselect both options.
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
Close port 1025 (scheduler service)
formatting link
Close port 1026 (mtaskp)
formatting link
Close port 1900 (ssdp) HKLM\Software\Microsoft\DirectPlayNATHelp\DPNHUPnP\UPnPMode Type: REG_DWORD Value: 2 (ie disabled) As per:
formatting link
Close all ports greater than 3000 (alg)
Close TCP port 5000 UPNP Control Panel, Add/Remove Software, Universal Plug & Play, Remove, OK.
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.
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.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.