how-to block ads
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: 
4 edits |  Windows File Sharing: Facing The Mystery
For one reason or another, there is quite a bit of confusion surrounding the technologies that allow File Sharing to take place on a Windows machine. The hodgepodge of terms ranging from NetBIOS, NBT, and SMB serve to confuse not only junior admins, but many more experienced professionals as well. We've all been there when a newcomer to IT has asked difficult questions like, "If I disable x, but leave y, will I still be able to do z?" Most times the professional being asked will try and either change the subject or exit the room as quickly as possible so as to avoid showing their ignorance.
Of course, nearly everyone is familiar with one main concept -- the well-worn and widely known view that Windows file sharing services are potentially very dangerous. Steve Gibson and his website can be credited mostly for this becoming largely common knowledge. Unfortunately, however, the fact that "it's bad" is about the extent of most people's knowledge of the subject. As a friendly test, see if you know the answers to the questions below:
•What's the difference between using Windows 9x and Windows 2000/XP file sharing?•Which port(s) handle(s) file transfers on Windows 2000/XP systems?•Does Windows XP use NetBIOS to transfer files?•If you disable NetBIOS over TCP/IP on a 2000/XP box, can people still connect to your shares?•What happens if you block access to port TCP/139 on an XP machine? These should be simple questions for anyone who deals with Windows in an administrator role, but unfortunately they are not. In fact, I'd be willing to bet that less than a quarter of Windows admins can confidently answer all five questions. In this short article, I intend to get readers up to speed on the basics of this highly critical area of knowledge. Often times, knowing the how and why makes all the difference when it comes to making sound security decisions.
Windows 9x - The Old Way
As with many disciplines, the best way to start is with a bit of history. Before going into how file sharing is handled on the current generation of Windows operating systems, let's take a look at how it was handled previously.
NetBIOS
The beginning starts with a protocol called NetBIOS. Originally pushed by IBM, it was put together for the purpose of sharing information between a very limited number of machines on a LAN. Early on, NetBIOS ran on a number of protocols, to include DECnet, and it's important to note that it was not designed to scale to large organizations. Unfortunately, once Microsoft released its products based on it, and computers became a crucial part of the business world, NetBIOS became the backbone of file sharing on business networks everywhere.
In Windows 9x (Windows 95, 98, and ME), the primary ports for sharing resources were 135, 137, 138, and 139. Below we take a look at each:
•TCP/135 - RPC: This port is potentially quite dangerous due to what "RPC" actually stands for. Remote Procedure Calls are requests from one machine to another for service. The RPC service acts as something of a facilitator, or go-between, between the client making the request and the machine being asked for service, i.e. a request is made to this "end-point mapper service" and then a port is allocated dynamically to the service being requested. This is similar to the RPC functionality found in the Unix world, and although it's not technically a "file sharing" port, it ties heavily into Windows networking in general.•UDP/137 - Netbios Name Service: This port is used to attain name resolution for Netbios. Think of it as Netbios's version of DNS or ARP. It's simply a way to use something you have, make a query, and get something you want in return. For NetBIOS it's from a NetBIOS name to an IP, for DNS it's a DNS name to IP, and for ARP it's from IP to hardware address.•UDP/138 - NetBIOS Datagram Service: This port primarily allows the SMB browser service to populate the browse lists seen when using "Network Neighborhood".•TCP/139 - NetBIOS Session Service: This is perhaps the most known Windows port of all, as it is used to transfer files over TCP. This is both the port that NULL Sessions are established over and the port that file and printer sharing takes place on. If you are considering restricting access to ports on your Windows machine, this one needs to be on the top of the list. NetBIOS was benign enough initially because they were bound to a protocol called Netbeui. NetBIOS was somewhat harmless when it ran over Netbeui because the protocol is limited to local networks. It couldn't cross routers, and therefore couldn't cross the Internet. For this reason, any problems associated with file sharing while running Netbeui were relatively limited.
NetBIOS over TCP/IP
This all changed when Microsoft started binding NetBIOS to TCP/IP -- a system referred to as NBT. What this did was take a potentially dangerous but hobbled system (NetBIOS) and gave it wings. Now, instead of just having to worry about someone in the next cube gaining information about your system and/or connecting to your file shares, you now have to worry about someone in New Jersey, Russia, or China doing the same thing.
Essentially, if the interface that connected you to the Internet had both TCP/IP and File and Print sharing on it, and you didn't have a decent password configured, you were in line to get scanned and pillaged at will by anyone on the Internet.
File and Print Sharing
Ok, so what's File and Print Sharing? Where does that fit in? Good question. File and Print Sharing is little more than a service that enables file/folder and print shares to be made available to clients. It's that simple. Think of it as a daemon that runs on a machine -- similar to a web or mail server.
Remember, daemons aren't useful unless requests can make it to them. That's where SMB over TCP (or in the 9x world -- NetBIOS over Netbeui or TCP/IP) come in. They are the means of getting requests over the network to the "server" machine, i.e. the box that has a folder or a printer shared out.
Basically, two things are needed in order for there to be a successful file transfer, 1) a transport allowing a client to make it to the machine in question, and 2) the machine to be listening for requests while it has shares available. It's important to understand these two pieces of the puzzle and where each technology fits.
Countermeasures
Steve Gibson's site, while quite informative, sensationalized the risk to some degree. All one needed to do to keep from sharing files over the Internet is unbind File and Print sharing from the TCP/IP protocol within network properties for the adapter that faces the outside. This could be done while leaving the binding intact for the internal adapter(s) so that you could benefit from file sharing on the internal, trusted network while having it disabled for the untrusted one(s).
The bits about disabling the Client For Microsoft Networks and such were simply over the top. Aptly enough, the "Client For Microsoft Networks" is nothing more than a client (hence the name). Disabling it had nothing to do with whether or not the server portion of File Sharing was enabled (File and Print Sharing).
Windows 2000/XP - The New Way
For most of us, Windows 9x is thankfully ancient history. The vast majority of us deal with Windows 2000 and XP these days, and the way these versions of Windows handle File Sharing is significantly different.
First off, the big difference that many notice is the use of port TCP/445 vs. the ports in the 130 range. This change was part of a new Microsoft paradigm designed to eliminate the dependency on NetBIOS. In fact, one can completely disable NetBIOS over TCP/IP on a Windows 2000/XP machine since these new operating systems (via TCP/445) have SMB riding directly on top of TCP rather than on NetBIOS. Microsoft calls this the "direct hosting" of SMB. This enhancement allowed for a few benefits, such as less clutter in the protocol stack, a lack of NetBIOS broadcasts, and the ability standardize on DNS entirely for name resolution.
As can be expected, most of the functions taken care of by ports 135-139 when NetBIOS was used are now taken care of by the single port 445. This means that not only file and print sharing take place over 445, but also network browsing functionality and RPC.
Old vs. New
When connecting to a Windows 2000/XP machine that has both NetBIOS over TCP and direct hosting enabled (from a client machine that's also using them), both types of connectivity will be attempted. The service responding first will be accepted and continued, i.e. if NetBIOS responds first then an RST will be sent to TCP/445, and vice versa.
Summary
Ok, now that we've covered a few different topics here, let's touch on some key points:•File and Print Sharing is a completely different beast than NetBIOS or NetBIOS over TCP/IP. To be clear, you can disable the latter and still use the former if you have it bound to a protocol such as Netbeui. If you disable File and Print Sharing, however, then it doesn't matter what transport gets you to the box, you still won't be able to access shares on it.•Windows 9x used NetBIOS (via ports 137, 138, and 139) to resolve resource names and facilitate connecting to them -- whether that was via the local network only (Netbeui) or WAN-wide (NBT).•Windows 2000/XP supports the NetBIOS system as well, but prefers the new method which uses TCP/445 to implement SMB directly over TCP. You can disable NBT for these platforms and still maintain virtually identical functionality using this "direct hosting" paradigm.•One of the major advantages of going to the "direct hosting" system instead of NetBIOS is the standardization on DNS for name resolution. Resolving resource names using NetBIOS names was chatty (broadcast-based) and lacked scalability. DNS is a universally accepted, hierarchical standard that scales all the way to networks the size of the Internet.•Due to the consolidation of many of the NetBIOS functions into a single port (445), this port is critical to many Windows 2000/XP operations. It's imperative that access to this port is limited to trusted hosts and/or networks. Well, that about sums it up. The goal here was to either refresh or bring up to speed anyone who deals with Windows networking on a daily basis. In the event that I've made an error, or you'd just like to comment, please feel free to contact me at daniel@dmiessler.com.
Edit: Corrections Made Per The Thread Below
--
dmiessler.com - grep understanding knowledge | |
ghost16825
Use security metrics
Premium
join:2003-08-26
| Great article. But just one point I'd like to make which I didn't see. Sure, Steve Gibson sensationalises things and has little in the way of helpful factual information. But the main reason why these services are dangerous, is usually not for their file enumeration ability nor their file sharing capabilities. It's the fact that they are (often by default) a running service with open ports as a consequence - which by itself implies that they will inevitably be vulnerable to buffer overflows from certain created input. Plus the fact that these services are difficult to "turn off" completely on Windows machines. And this goes for almost any service with remote functionality, including those on UNIX machines. (Unix has had its share of RPC security issues). Most security issues arise not because of the functionality or abuse of the functionality itself, but from input bounds-checking issues which allow buffer overflows and consequently malware to be executed remotely.
--
Admin of the Kerio 2x-like open source project:
http://sourceforge.net/projects/kerio/
http://kerio.sourceforge.net/
| |
Mele20
Premium
join:2001-06-05
Hilo, HI
| reply to Daniel
This article doesn't address file sharing between XP and 98SE boxes. Why not? I believe that is just as risky as the old 98 way. Most folks (home users at least) want to share between an old machine and a new one each running different OSes. I had to make my 98SE box totally vulnerable in order to share with the XP box. I had all bound to Netbeui but had to abandon that. This is an important issue but ignored in this article. Plus, I don't agree that Steve Gibson has sensationalized this issue. He is right on target. Much more so that the author of this article. I forgot once, after I made my 98SE box vulnerable, and used dial up instead of my usual cable modem behind a router connection. It took about 30 seconds for the 98SE box to be infected. So, I don't agree that Steve Gibson is a hysteric. I'll continue to read his site instead of articles like this one.
--
The first and foremost function of our jurors is to protect private citizens from a tyrannical and intrusive government...Jurors are the last line of defense for liberty. Thomas Jefferson 1789 | |
TheWiseGuy
Dog And Butterfly
Premium,MVM
join:2002-07-04
Yonkers, NY
| reply to Daniel
said by Daniel  :Steve Gibson's site, while quite informative, sensationalize the risk to systems in a big way. All one needed to do to keep from sharing files over the Internet is unbind File and Print sharing from the TCP/IP protocol within network properties for the adapter that faces the outside. This could be done while leaving the binding intact for the internal adapter(s) so that you could benefit from file sharing on the internal, trusted network while having it disabled for the untrusted one(s). Can this be done on a Win9x or before box?
Is Steve Gibson incorrect on this?
said by Steve Gibson:
After a reboot, the information-leaking port 139 will finally be closed . . . but ONLY IF every service is unbound from every instance of the TCP/IP protocol. If ANY one of the services remains bound to ANY instance of the TCP/IP protocol (i.e. TCP/IP for ANY adapter), then unsafe NetBIOS services will be available for ALL hardware adapters! »grc.com/su-rebinding9x.htm
I could be wrong but I believe he is correct, that on a Win9x or before box, it is impossible to only bind NetBios to the Internal Adapter, that on a Win9x box it is all or nothing.
--
Dog and Butterfly | |
dave
Premium,MVM
join:2000-05-04
not in ohio
 ·Verizon Online DSL
3 edits | reply to Daniel
A good summary. I have a couple of technical nits to pick, thoguh.
NetBIOS using these ports was benign enough initially because they were bound to a protocol called Netbeui. A little confusion here.
You listed some TCP and UDP ports. Netbeui does not use TCP or UDP ports. When MS Networking (SMB) is using Netbeui, no TCP or UDP ports are involved.
Netbeui identifies endpoints by 'netbios name', not by TCP or UDP port. E.g., the name of the SMB server is the machine name, padded to 16 bytes with spaces. The name of the SMB client is the machine name, padded to 15 bytes with spaces, followed by a zero byte. The name of the messenger service is the machine name, padded to 15 bytes with spaces, followed by a byte with value 3.
Also, I wouldn't describe port 135 as being used by Windows File Sharing at all. It's the RPC endpoint mapper, which does not use Windows File Sharing protocols. RPC is not SMB.
As can be expected, most of the functions taken care of by ports 135-139 when NetBIOS was used are now taken care of by the single port 445. This means that not only file and print sharing take place over 445, but also network browsing functionality and RPC. As far as I am aware, RPC endpoint mapping does not use port 445.
Port 445 is "CIFS (nee SMB) over Native TCP", replacing "CIFS over Netbios over TCP" -- ports 137/138/139.
There might be some confusion because RPC traffic itself can be carried over named pipes, which are simply files as far as SMB is concerned. i.e., to talk using RPC, you open a pipe using file-access methods over (pick 1) a netbeui session to the smb server, a netbios-over-TCP connection to TCP/139, or a TCP connection to TCP/445.
RPC traffic can also be carried over 'plain TCP', which typically requires you to talk to the port mapper to find out which port to use.
I don't know much about RPC but I know a little about SMB/CIFS. | |
psloss
Premium,MVM
join:2002-02-24
Alpharetta, GA
| reply to Daniel
said by Daniel :Old vs. NewWhen connecting to a Windows 2000/XP machine that has both NetBIOS over TCP and direct hosting enabled (from a client machine that's also using them), both types of connectivity will be attempted. The service responding first will be accepted and continued, i.e. if NetBIOS responds first then an RST will be sent to TCP/445, and vice versa. Do you have a cite for this? I've seen this anecdotally, but whenever I've looked at this in a home (workgroup) environment, the CIFS client has always selected tcp/445 over tcp/139.
And again anecdotally, I can't recall seeing any of the infected systems spreading malware via Windows remote logins choosing tcp/139 over tcp/445.
(Note that in Microsoft's implementation -- NT 5.0 and up -- one can disable either 445 or 139; tcp/445 via the SMBDeviceEnabled Registry value in the NBT driver SCM parameters, and tcp/139 via the network adapter TCP/IP properties.)
It would also be interesting to see what the Samba SMB client does...
Also, the relationship between MSRPC and SMB/CIFS isn't precise -- but I think Dave is already addressing that.
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org | |
dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL
| said by psloss :Do you have a cite for this? I just tried this with Ethereal running (Win2000 to Win2000).
If I connect to a machine I have never connected to ever before, then I see a SYN to TCP/445 immediately followed by a SYN to TCP/139. Eventually, the second connection gets reset.
If I connect to a machine that I connect to often, then only the 445 connection is sent, so there's some memory in the system.
I imagine the odds are that 445 will be chosen, since (a) the 445 connection request is fractionally ahead of the 139 connection request on the wire, (b) smb-over-native involves one less layer than smb-over-nbt, so maybe the turnaround time is a little less.
(I didn't pay close attention to looking at how far the 445 connection setup had to proceed -- there are several SMBs needed for complete connection setup after the TCP connection is ready -- before the 139 connection was abandoned). | |
altermatt
Premium
join:2004-01-22
White Plains, NY
·Verizon Online DSL
| reply to Daniel
said by Daniel : Due to the consolidation of many of the NetBIOS functions into a single port (445), this port is critical to many Windows 2000/XP operations. It's imperative that access to this port is limited to trusted hosts and/or networks Indeed, using NetBEUI instead of NetBIOS/TcpIP has allowed me to stop all ports from listening except 445; that is still showing as stealthed behind my router/ZAP combination. But would like some further tips on "limiting [access to 445] to trusted hosts and/or networks." Just to make sure.
Great explanation, and, though not addressing it in much detail, another good argument for NetBEUI.  | |
dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL
| reply to Daniel
One more thing:
You forgot to mention that file-sharing requests are all subject to access control -- i.e., generally speaking, you need to log in before you can get access.
This is frequently overlooked in the "OMFG!!!! I have an open port!!!!!" view of the world. That doesn't mean that it's wise to expose TCP/445 to the greater Internet, but it does mean that there is layered protection.
In the obsolete Win9x implementation (and optionally in Samba), you have 'share level' authentication. A password is associated with the share, and if you know the password, you get access.
In Windows NT and most other modern implementations, you have 'user level' authentication. Accessors must know a username and password that is valid on the server, and (in implementations with decent authorization mechanisms), they get exactly the access that is due to the named user.
There is another wrinkle to user-level authentication, and that is 'guest access'. Windows may choose to allow unknown users to log in as user Guest for network accesses. This is generally a bad thing in my opinion. The Guest account is disabled by default in Win2000 and XP Pro, and you should only enable it if you understand the security ramifications. Rumour says it's on by default in XP Home. | |
bcastner
Premium,VIP,MVM
join:2002-09-25
Chevy Chase, MD
clubs:
·Verizon Online DSL
| reply to Daniel
Dave above makes some great comments, so let me ammend slightly one section above" "There is another wrinkle to user-level authentication, and that is 'guest access'. Windows may choose to allow unknown users to log in as user Guest for network accesses. This is generally a bad thing in my opinion. The Guest account is disabled by default in Win2000 and XP Pro, and you should only enable it if you understand the security ramifications. Rumour says it's on by default in XP Home."
It is no rumour, XP Home is enabled only for the "Simple File sharing" model, XP Pro is by default but can be changed in the Folder, View option of the GUI.
This has nothing to do with whether the "Guest" account is enabled, but Group Guest. Your decision to enable the Guest account is a decision about a local console logon, not remote access.
There was raised by others a concern about how port 139 versus 445 were handled. At the moment essentially the client needing a session makes requests on both, and maintains any session on the first to reply. You can influence this:
By standard both port 139 and 445 are open to get the highest degree of compatibility. A client will try to request on both ports and continue the communication on the port which responds first.
To disable SMB use of Netbios port 139 (Forces use of port 445):
. On the Start menu, point to Settings, and then click Network and Dial-up Connections
. Right-click Internet facing connection, and then click Properties.
. Select Internet Protocol TCP/IP and select Properties
. Click Advanced and select the WINS tab
. Tick Disable NetBIOS over TCP/IP and click Ok
To disable SMB use of port 445 with this DWORD (Forces use of port 139):
[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters]
SMBDeviceEnabled = 0
To disable SMB use of port 139 and 445 (Disables nbt.sys driver):
Right-click My Computer on the desktop, and then click Manage.
Expand System Tools, and then select Device Manager.
Right-click Device Manager, point to View, and then click Show hidden devices.
Expand Non-Plug and Play Drivers.
Right-click NetBios over Tcpip, and then click Disable.
To disable SMB completely:
On the Start menu, point to Settings, and then click Network and Dial-up Connections
Right-click Internet facing connection, and then click Properties.
Select Client for Microsoft Networks, and then click Uninstall.
Follow the uninstall steps.
Select File and Printer Sharing for Microsoft Networks, and then click Uninstall.
Follow the uninstall steps.
(My thanks to "Snakefoot" and his remarkable site: »snakefoot.fateback.com/tweak/win···_NETBIOS )
| |
psloss
Premium,MVM
join:2002-02-24
Alpharetta, GA
1 edit | reply to dave
said by dave :(I didn't pay close attention to looking at how far the 445 connection setup had to proceed -- there are several SMBs needed for complete connection setup after the TCP connection is ready -- before the 139 connection was abandoned). In the Microsoft server-side implementations I tested, my recollection (which is going on 18 months or thereabouts, so it's fuzzy) is that the 139 connection gets reset even before the negotiate protocol SMB appeared (chronologically) in the Ethereal logs.
But I'd have to go snag the old logs to see for sure what they show; for now, it's easy enough to fire up Ethereal to take a look at a current domain and/or workgroup setup.
And it should be fairly simple to hack something together to send a SYN on 139 before 445...I'll have to try that in some spare time...
(Edit: spelling)
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org
| |
psloss
Premium,MVM
join:2002-02-24
Alpharetta, GA
| reply to bcastner
said by bcastner :This has nothing to do with whether the "Guest" account is enabled, but Group Guest. Your decision to enable the Guest account is a decision about a local console logon, not remote access. I assume you mean the group "Guests" (plural), right? The distinction being that both are "well known" SIDs, where "Guest" has an RID of 501 and "Guests" has an RID of 514.
Also, aren't there two "types" of disabling for the Guest account in XP? One from the "User Accounts" control panel applet and the other being the way that accounts have always been enabled/disabled in NT? (viz: "net user Guest active:no")
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org | |
bcastner
Premium,VIP,MVM
join:2002-09-25
Chevy Chase, MD
clubs:
·Verizon Online DSL
| reply to Daniel
In the intererents of completeness, the ForceGuest key is one distinguishing feature between XP Home and XP Pro.
Under XP Pro:
. Start Button -> My Computer
. In the menu of My Computer select "Tools" -> "Folder Options"
. In "Folder Options" select the "View" fan
. Uncheck the setting "Use Simple File Sharing (Recommended)"
This change should be reflected in this registry key:
[HKEY_LOCAK_MACHINE \SYSTEM \CurrentControlSet \Control \Lsa]
ForceGuest = 0
Now it is a EULA violation to mess with the registry key under XP Home, and as you are lacking a lot of the utilities available with XP Pro, likely unwise. And likely unreliable. And most assuredly unsupported.
My own personal wish is that under Longhorn all of this "Simple File Sharing" nonsense is removed. My own wish list has always included the hope for a small DNS or even WINS server for small Workgroup-based LANs. As an MS-MVP I have fought for something other than what we have under NT 5 at present. Take an early look at the Longhorn notion of a "Castle". There is not a lot of publicly available information on this at the moment, but scroll down briefly at: »www.microsoft.com/windows/longho···acy.mspx | |
bcastner
Premium,VIP,MVM
join:2002-09-25
Chevy Chase, MD
clubs:
·Verizon Online DSL
2 edits | reply to Daniel
psloss,
Yes, Group Guests, user account Guest. The SID and matching RID are what matter. The authentication will occur not under native user account Guests but by the Group account permissions.
Thank you.
But the User Account tool only determines whether a "Guest" can do a local logon. This status does not affect remote access.
Under the NT 5 security model it is a question of how an anonymous logon is handled from a remote client. If your ACL-->to-->ACE "rights" force all authentication to be by username and password, or if this is tried first and an anonymous "Guest" authentication is then permitted, or "Guest" is permitted in all cases. See, for example, »support.microsoft.com/kb/q266280/ | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to ghost16825
said by ghost16825 :Great article. But just one point I'd like to make which I didn't see. Sure, Steve Gibson sensationalises things and has little in the way of helpful factual information. But the main reason why these services are dangerous, is usually not for their file enumeration ability nor their file sharing capabilities. It's the fact that they are (often by default) a running service with open ports as a consequence - which by itself implies that they will inevitably be vulnerable to buffer overflows from certain created input. Definitely. The focus here, however, was to say on the networking side of things with a slant towards security. In other words, I wanted to discuss the file sharing technologies themselves and not go into the much larger subject of securing a Windows machine in a more general sense.
I was going to go down that path, but it would have become much more than a couple hours woth of article in a hurry. I wrote most of this while watching some little Panda movie on T.V. with my girlfriend. That wouldn't be possible if I had expanded the scope any. Thanks for the comments though; I see what you mean.
--
dmiessler.com - grep understanding knowledge | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to Mele20
said by Mele20 :This article doesn't address file sharing between XP and 98SE boxes. I think it does. There are essentially two systems for doing file sharing -- the 9x way, and the "direct hosting" way. As mentioned in the piece, if you have both enabled on the client and you try to contact another box for service, both types of connectivity are attempted.
That's how the old shares with the new.
If it's an XP box trying to share with a 98 machine, for example, and the XP box has NBT enabled, the XP box will send requests both to port 445 and to the NBT ports. Since the 98 box is not listening on 445, it will respond via the old method and communication will ensue.
--
dmiessler.com - grep understanding knowledge | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to TheWiseGuy
said by TheWiseGuy :I could be wrong but I believe he is correct, that on a Win9x or before box, it is impossible to only bind NetBios to the Internal Adapter, that on a Win9x box it is all or nothing. And I could be wrong as well, but I don't think I am.
Remember the issue is that a very specific scenario has to exist in order to share files over the Internet. You need TCP/IP bound to File and Print Sharing for the Internet-facing adapter. If you only have TCP/IP installed, but it's not bound to TCP/IP on that adapter, it fails.
It is my understanding that you can break bindings on the external adapter while keeping them intact on the internal one. This warrants more testing, however, as I haven't done this in quite some time.
Thanks for the comment; I'll definitely confirm this.
--
dmiessler.com - grep understanding knowledge | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to dave
said by dave :A good summary. I have a couple of technical nits to pick, thoguh. NetBIOS using these ports was benign enough initially because they were bound to a protocol called Netbeui. A little confusion here. You listed some TCP and UDP ports. Netbeui does not use TCP or UDP ports. When MS Networking (SMB) is using Netbeui, no TCP or UDP ports are involved. Heh, that's not a "little confusion", that's gross error. Thanks for catching that; it was late.
Netbeui is in fact "portless", just like AH, ESP, and most other protocols aside from 06 and 17.
said by dave :Also, I wouldn't describe port 135 as being used by Windows File Sharing at all. It's the RPC endpoint mapper, which does not use Windows File Sharing protocols. RPC is not SMB. Very true, and I covered port 135's role when I described each port. Perhaps I should make the distinction a bit clearer, however.
said by dave :As far as I am aware, RPC endpoint mapping does not use port 445. I think it does, actually. Take for example this advisory by CERT where they advocate the following:
said by CERT:Using a network or host-based firewall, block RPC network traffic (ports 135/tcp, 139/tcp, 445/tcp, 593/tcp and 135/udp, 137/udp, 138/udp, 445/udp). » www.kb.cert.org/vuls/id/547820 Thanks so much for your comments, Dave, and everyone else's too. This forum just rocks because of the ability for people to bring content here and get it looked at without the negativity associated with many other venues.
--
dmiessler.com - grep understanding knowledge | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to psloss
said by psloss :said by Daniel :Old vs. NewWhen connecting to a Windows 2000/XP machine that has both NetBIOS over TCP and direct hosting enabled (from a client machine that's also using them), both types of connectivity will be attempted. The service responding first will be accepted and continued, i.e. if NetBIOS responds first then an RST will be sent to TCP/445, and vice versa. Do you have a cite for this? I do.
said by Microsoft :If both the direct hosted and NBT interfaces are enabled, both methods are tried at the same time and the first to respond is used. This allows Windows to function properly with operating systems that do not support direct hosting of SMB traffic. » support.microsoft.com/default.as···;Q204279
--
dmiessler.com - grep understanding knowledge | |
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to dave
said by dave :One more thing: You forgot to mention that file-sharing requests are all subject to access control -- i.e., generally speaking, you need to log in before you can get access. True, but again, I wanted to limit my scope. Because once I mentioned that credentials were often required I'd have had to mention the fact that NULL Sessions are often possible in default configurations. It was a path I didn't want to take. A good idea though...
--
dmiessler.com - grep understanding knowledge | |
|
