SUMMARY: Disabling Port 445 (SMB) Entirely

["Jason Coombs" <jasonc () science org>]

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.

--