UPDATE: I double-checked and in fact was able to stop port 445 from binding at all under Windows 2000 using the following Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters under this key remove the default value "\Device\" from the TransportBindName REG_SZ value. upon reboot, port 445 is gone completely, both TCP and UDP. I tried a while ago to replace \Device\ with the device name of a single network interface in my multi-homed Windows box and that did not appear to work, SMB still grabbed port 445 TCP and UDP on 0.0.0.0 rather than the IP address bound to the network interface whose \Device\ virtual name I entered into the TransportBindName. Perhaps you can only disable port 445/SMB entirely, there may be no way to disable it selectively. However, port 1025 is still being bound by SYSTEM ... I have no idea why. Sincerely, Jason Coombs jasonc@science.org -----Original Message----- From: Jason Coombs [mailto:jasonc@science.org] Sent: Thursday, August 29, 2002 11:52 AM To: vuln-dev@security-focus.com Subject: SUMMARY: SMB overflow attacks SUMMARY: There does not appear to be any way to get Windows 2000 to stop binding to port 445 at this time. It's possible in Windows NT, but then again SMB was an after-thought for NT (Service Pack 3 or 4, I don't remember which) and the NT kernel doesn't bind port 445 as aggressively. -- My original question is summarized below. I'm not satisfied with simply filtering ports, I want Windows to stop binding to ports that I don't want it to use at all for anything. There's no reason for my box to bind and listen to ANY ports if it provides no services: -- >On a related subject, I've been struggling for weeks to turn off port 445 >completely. It's not happening. The port is bound by the System process on >both TCP and UDP, and System also binds to and listens on a port above 1024 >for some unknown reason. -- Good answers (not necessarily RIGHT answers, however... The first two answers below are the most interesting. Thanks to all who replied. I'll do another SUMMARY in the future when more answers are found): -- Actually a simple google search brought me to this website..this shud definitely solve ur problem! http://www.uksecurityonline.com/husdg/windowsnt/close445.htm -- is IIS running ? - if IIS is running you cannot disable port 445 (Direct Host). otherwise you have to uninstall nbt.sys my computer->manage->device manager->view->show hidden devices->non plugn play device->netbios over tcpip->uninstall. -- Well it so happens that in win2k (also win XP), the ms people added the additional possibility to run SMB(Server Message Blocks) directly over the TCP/IP without having to use the NBT(Netbios over TCP/IP) layer.Now this uses the TCP port 445. Normally, if the system has NBT enabled, it shall try to connect to the server at both port 139 and 445 simultaneously. If there is a response from port 445, it sends a RST to port 139, and continues it's SMB session to port 445 only (this is what's happening in ur case) similarly,if there is no response from port 445, it will continue it's SMB session to port 139 only,(ie. if it gets a response from there). If there is no response from either of the ports, the session will fail completely. but i guess that it doesnot solve the problem of disabling the port 445...well why don't u try to use a firewall and define the services in it? And about the system binding to a port>1024 ..The only reason i can tell u is that ports 0-1024 are called as the "Well-Known ports" and are allotted to specific applications only.so the system binds only to ports >1024 -- 445 is the new NetBIOS [0], and just as easy to get rid of (i.e. you don't, you block it at the firewall). I assume from your post that you've already tried the old NetBIOS trick of binding it to the loopback NIC? I wish they'd at least have an option to bind all the random uncontrollable junk to 127.0.0.1 rather than 0.0.0.0... [0] Quite literally. MS took all the NetBIOS stuff they knew about and moved it to 445, leaving the stuff they didn't know about to wither at 13x. -- Well it so happens that ports 0-1024 are called the "Well-Known ports" as these ports are being used by some "Well known application" or the other.So this is the reason why the system always binds to ports >1024. About the port 445 all i can tell u for now is that this port is being used for the following: microsoft-ds 445/tcp Microsoft-DS microsoft-ds 445/udp Microsoft-DS -- AFAIK you can disable Port 445 by disabling the "NetBios over TCP/IP" Device in the W2K Device Manager. -- I *suppose* you could bind two netcat listeners (tcp and udp) to 445? I seem to recall from the original netcatNT readme that you could "effectively disable sharing" or something like that by binding to the 13x port. worth a try if nothing else.. -- Microsoft added the ability to run SMB directly over TCP/IP, without the extra layer of NBT. This is what happens on port 445. There does not seem to be a way to stop Windows from binding to port 445. Taken from Microsoft Knowledge Base article Q253959 "The NetbiosSmb device, used for direct-hosted SMB traffic, is global and cannot be unbound from a particular network adapter. This behavior is by design." -- Nothing you can do about 445. The theory is that it can be "disabled" by shutting down the server and workstation services, which are what actually services that port. Unfortunately, this does not actually have the effect of closing the port for either UDP or TCP connections. I'm sure you've already reached these conclusions though. :) Microsoft has stated in several KB articles that this is "by design" without choosing to reveal more about why that is so. The ability to filter the port allows you to mitigate the risk, but what they have really taken away is the ability to selectively bind the SMB direct host services to a specific adapter. Clearly Microsoft's thinking is that their port filtering is enough of a control in this sort of case. While I tend to be more of a "why bind if you don't need it, only to filter later," the truth is it doesn't matter one way or the other. The end result is the same. In this case, it seems Microsoft opted to significantly simplify interface configuration as well as service/binding complexity in favor of letting you filter extensively. --
