<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">

<channel>
<title>Windows File Sharing: Facing The Mystery in Security</title>
<link>http://www.dslreports.com/forum/r13108896</link>
<description></description>
<language>en</language>
<pubDate>Wed, 02 Dec 2009 13:47:53 EDT</pubDate>
<lastBuildDate>Wed, 02 Dec 2009 13:47:53 EDT</lastBuildDate>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126311</link>
<description><![CDATA[<A HREF="/useremail/u/755055"><b>OZO</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>Secondly, the reason you can only resolve via FQDN may be because you haven't set a DNS suffix under your computer and/or network properties.</DIV>Exactly. I added the suffix and now I'm using good old short names ;). Thanks.<br><br> bcastner <A HREF="/useremail/u/693977"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A> - thank you for the info. It'd be nice if they finally redesign the NetBIOS support. It's definitely needed...<br><SMALL>--<br>Keep it simple, it'll become complex by itself...</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126311</guid>
<pubDate>Sat, 09 Apr 2005 04:07:14 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126236</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : Great stuff, thanks bcastner.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126236</guid>
<pubDate>Sat, 09 Apr 2005 03:35:59 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126177</link>
<description><![CDATA[<A HREF="/useremail/u/693977"><b>bcastner</b></A> : "So, if I want to see computers in My Network Places and use short names (I presume that the last one is probably somehow configurable by DNS) I have to enable NetBIOS and therefore open local ports 137/UDP, 138/UDP, 139/TCP."<br><br>If you want the Network Places enumeration, you need Netbios.  This is planned to change in Longhorn with the "Castle" feature, as it will offer a different enumeration method for known network resources:<br><br>Castle<br>What This Feature Does:<br>The "castle" feature allows users to have the networking functionality of the domain, including roaming the user's profile, machine trust and having a consistent user identity throughout the network. The main difference with Castle is that users do not have to setup a dedicated machine, such as a domain controller, to maintain the trust and identity relationship. It also makes it easy to share and access files on those computers. Each computer on the same subnet can discover and join an existing castle. Or, the user can create a Castle. To join an existing castle, you must know the login credentials of an administrator account already part of the castle. Only non-blank passwords can grant access. This helps ensure only authorized computers join the castle (use of strong passwords for administrator accounts is highly recommended). When a computer joins a castle, the accounts on that computer will be added to the list of accounts accessible from any computer in the castle. User specific data (e.g. their password, access rights, and preferences) will be replicated on each computer in the castle and kept in sync. In addition, the newly joined computer will inherit and respect all policies from the Castle.<br><br>Information Collected, Processed, or Transmitted:<br>To help standalone computers find the available castles on the subnet, the machines in the Castle send a broadcast a beacon containing the Castle's name. Be aware that if you share a subnet with other people (e.g. your neighbor when using a cable modem without a hardware router/firewall) they may be able to see the name of your castles. In this case only choose castle names you are comfortable sharing with others. When joining a castle, the credentials you enter will be sent using security technology (NTLM) to other computers in the castle.<br><br>Use of the Information:<br>Broadcasting the name of each castle makes it easy to discover what castles are available on the subnet. When joining a castle, the credentials help ensure only authorized computers join the castle.<br><br>Choice/Control:<br>The user must initiate joining a castle using the user interface provided. Whether the user's computer is able to join a castle depends on whether an administrator of a computer already part of the castle has provided the user with the appropriate credentials. When a castle is formed, a beacon containing the castle name will be broadcast. In this release there is no easy way to disable the beacon. A mechanism to disable the beacon will be added in a future release.<br><br>Important Information:<br>The Internet Connection Firewall (ICF) is enabled by default in this software. Therefore, if you create a Castle, it will send out the beacon, but because ICF is enabled, other computers running this software that have the firewall enabled won't see the beacon. <br><br><br>&raquo;<A HREF="http://www.microsoft.com/windows/longhorn/privacy.mspx" >www.microsoft.com/windows/longho&middot;&middot;&middot;acy.mspx</A>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126177</guid>
<pubDate>Sat, 09 Apr 2005 03:17:31 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126157</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : Ok, first off, you don't need WINS if you're going this route. WINS is for NetBIOS names only. Going down this path means that you are going with DNS and DNS <EM>only</EM> for name resolution. I wouldn't suggest trying to mix them.<br><br>Secondly, the reason you can only resolve via FQDN may be because you haven't set a DNS suffix under your computer and/or network properties. It's possible in the latter case to make it so that any single host name you attempt has suffixes attached to them.<br><br>For example, if you're trying to get to "romulus", but you can't unless you enter "romulus.my.lan", you need to enter "my.lan" into your domain suffixes in your DNS settings. This will automatically append "my.lan" to any single name that you attempt to resolve if the single name doesn't work.<br><br>The computers not showing up in "My Network Places" I am not sure about; perhaps someone else can speak to that one.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126157</guid>
<pubDate>Sat, 09 Apr 2005 03:11:13 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126101</link>
<description><![CDATA[<A HREF="/useremail/u/755055"><b>OZO</b></A> : Tried to disable NetBIOS on LAN. All SMB communications are via port 445/TCP/UDP only. Local DNS is running. DHCP is enabled and provides with IP address of that local DNS. WINS is configured and running (there is no actual help to resolve computer names noticed).<br><br>As the result - there is no entries in <I>My Network Places</I>. I can't ping computers by their short names like <TT>ping mycomp</TT>, but it's possible to address them by using FQDN - <TT>ping mycomp.localdomain</TT>. All computers are accessible by their FQDN (long names) only. I can map computer local shares by applying long names as well (no browsing facilitating the mapping is supported though).<br><br>So, if I want to see computers in <I>My Network Places</I> and use short names (I presume that the last one is probably somehow configurable by DNS) I have to enable NetBIOS and therefore open local ports 137/UDP, 138/UDP, 139/TCP.<br><SMALL>--<br>Keep it simple, it'll become complex by itself...</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126101</guid>
<pubDate>Sat, 09 Apr 2005 02:54:24 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13126073</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  B <A HREF="/useremail/u/229804"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>Here's what I think we're discussing -- &raquo;<A HREF="http://grc.com/su-rebinding9x.htm" >grc.com/su-rebinding9x.htm</A></DIV>I don't see anything there that says that you can have a dual-homed system exist with File/Print Sharing bound to TCP/IP on <EM>one</EM> interface while it's unbound from the other at the same time.<br><br>That's the crucial piece I'm looking to confirm one way or another.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13126073</guid>
<pubDate>Sat, 09 Apr 2005 02:46:43 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13121228</link>
<description><![CDATA[<A HREF="/useremail/u/229804"><b>B</b></A> : You're talkin' to it.  ;)<br><br>Edit: Here's what I think we're discussing -- &raquo;<A HREF="http://grc.com/su-rebinding9x.htm" >grc.com/su-rebinding9x.htm</A><br><br>-- B]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13121228</guid>
<pubDate>Fri, 08 Apr 2005 15:02:54 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13121210</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  B <A HREF="/useremail/u/229804"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>3.  As Gibson DID eventually admit/describe, one CAN unbind   sharing from a particular adapter in Win9x; the tricky part is that Windows will warn you that the network settings are incomplete (and things may disappear from the control panel) but you have to click OK anyway.  I thought he left up that info at GRC.com.</DIV>Can you help me find documentation that he said this? I remember it as well, but I can't find any info on it. Also, you don't have a 98 box lying around that you can test it on do you? I want to confirm this important point as much as possible.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13121210</guid>
<pubDate>Fri, 08 Apr 2005 15:01:03 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13121155</link>
<description><![CDATA[<A HREF="/useremail/u/229804"><b>B</b></A> : That's just the stupid "Simple File Sharing".  You can get rid of it.<br><br>One explanation is at &raquo;<A HREF="http://www.practicallynetworked.com/sharing/xp/filesharing.htm" >www.practicallynetworked.com/sha&middot;&middot;&middot;ring.htm</A><br><br>-- B<br><SMALL>--<br>In a realm outside causality and function</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13121155</guid>
<pubDate>Fri, 08 Apr 2005 14:54:11 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13120930</link>
<description><![CDATA[<A HREF="/useremail/u/526806"><b>louist</b></A> : I'd like to add a question to this thread:<br><br>In Win 2000 Pro, you can specifically control permissions  controlling who can and conversely who cannot access a shared folder or sub folder under NTFS formatted Stores.<br><br>In XP Pro, you apparently can only share with all client machine accounts(who are allowed to log on to your machine) or not share with anyone.<br><br>Does anyone know why Microsoft removed this useful feature on XP pro?  alternately does anyone know how to  more granularly control which accounts can access which folders in shares?<br><SMALL>--<br>regards,Lou</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13120930</guid>
<pubDate>Fri, 08 Apr 2005 14:26:42 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13120745</link>
<description><![CDATA[<A HREF="/useremail/u/229804"><b>B</b></A> : <br>What a great thread.  Nice work,  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>!<br><br>Some minor points...<br><br>1.  You omit mention of IPX/SPX as a valid alternative to either NetBIOS over TCP/IP or NetBEUI.  I think I may actually be happy about this, as the more obscure (and yes, unsupported) it remains, the more secure I can be in deploying it for local sharing.<br><br>2.  As mentioned above, there's no issue of ports with NetBEUI, because, of course, it's NOT an IP-based transport protocol.  (I may have this askew.)<br><br>3.  As Gibson DID eventually admit/describe, one CAN unbind   sharing from a particular adapter in Win9x; the tricky part is that Windows will warn you that the network settings are incomplete (and things may disappear from the control panel) but you have to click OK anyway.  I thought he left up that info at GRC.com.<br><br>4.  I think any medium to large network administrator (regardless of his or her girth) would simply laugh when advised that the "direct hosted" SMB transport and ad-blocking hosts file was keeping a user from disabling the DNS client.  Because of course that network would be useless without the client.<br><br>What people do on their own small and SOHO networks is another story.  I think the "right" answer for those folks is to simply uses static IP addressing, and <B>add the IP addresses of each local SOHO PC to each machine's HOSTS files</B>.  If they are competent enough to manage a few thousand HOSTS file entries, they can certainly deal with 5 or 10 static IP addresses on their LAN.<br><br>It seems like a workable compromise to me.<br><br>-- B<br><SMALL>--<br>In a realm outside causality and function</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13120745</guid>
<pubDate>Fri, 08 Apr 2005 14:05:33 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13120697</link>
<description><![CDATA[<A HREF="/useremail/u/615773"><b>hpguru</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><div class="bquote"><SMALL>said by  hpguru <A HREF="/useremail/u/615773"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>I agree. If you fill up your hosts file by misusing it...<br> </DIV>What! You mean the IP address of doubleclick.net isn't really 127.0.0.1?? :D<br> </DIV>Inconceivable.<br> </DIV>Nah! It's Default (cough) Deny. :uhh:<br><SMALL>--<br><B><A HREF="http://www.hosts-file.net/">Get hpHOSTS!</A> Member <A HREF="http://a-sap.org/">ASAP</A></B></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13120697</guid>
<pubDate>Fri, 08 Apr 2005 13:59:32 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13120617</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  hpguru <A HREF="/useremail/u/615773"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>I agree. If you fill up your hosts file by misusing it...<br> </DIV>What! You mean the IP address of doubleclick.net isn't really 127.0.0.1?? :D<br> </DIV>Inconceivable.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13120617</guid>
<pubDate>Fri, 08 Apr 2005 13:49:33 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119902</link>
<description><![CDATA[<A HREF="/useremail/u/809112"><b>reaver221</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR><div class="bquote"><SMALL>said by  reaver221 <A HREF="/useremail/u/809112"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>Made even nicer by frequent trashing of Steve Gibson. ;)<br> </DIV>Was it really trashing? The guy is decently stout in my book, and he's a way better programmer than I am. His only crime in my mind is being a sensationalist.<br> </DIV>You've got a point there.<br><br>i don't know... I tend to interpret just about any mention of Steve in a negative light :x]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119902</guid>
<pubDate>Fri, 08 Apr 2005 12:20:19 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119796</link>
<description><![CDATA[<A HREF="/useremail/u/663732"><b>cacroll</b></A> : <div class="bquote"><SMALL>said by  hpguru <A HREF="/useremail/u/615773"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR>What! You mean the IP address of doubleclick.net isn't really 127.0.0.1?? :D<br> </DIV>It sure should be.  As I said in a late night post this week, they ought to rename their service to DoubleTalk.  :) :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119796</guid>
<pubDate>Fri, 08 Apr 2005 12:04:12 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119704</link>
<description><![CDATA[<A HREF="/useremail/u/615773"><b>hpguru</b></A> : <div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>I agree. If you fill up your hosts file by misusing it...<br> </DIV>What! You mean the IP address of doubleclick.net isn't really 127.0.0.1?? :D<br><SMALL>--<br><B><A HREF="http://www.hosts-file.net/">Get hpHOSTS!</A> Member <A HREF="http://a-sap.org/">ASAP</A></B></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119704</guid>
<pubDate>Fri, 08 Apr 2005 11:54:14 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119660</link>
<description><![CDATA[<A HREF="/useremail/u/663732"><b>cacroll</b></A> : An interesting concept.  I'll enjoy watching this develop.<br><br>Is there an RSS feed for Proxicus, as there are for some other SF projects?]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119660</guid>
<pubDate>Fri, 08 Apr 2005 11:50:03 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119448</link>
<description><![CDATA[<A HREF="/useremail/u/663732"><b>cacroll</b></A> : It's a kludge, yes.  But it's a fairly popular kludge.  HPGuru, for instance, produces his Hosts file as a community effort.  Both the HPGuru and MVPS Hosts files are listed in the Security Updates sticky article in this forum.<br><br>It has advantages, too.<br>-  Applies to any operating system.<br>-  Applies without any additional software to install, or any bindings, or LSP/Winsock, changed.<br><br>In short, I don't think that it's a kludge that will go away very soon.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119448</guid>
<pubDate>Fri, 08 Apr 2005 11:26:01 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119361</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  reaver221 <A HREF="/useremail/u/809112"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>Made even nicer by frequent trashing of Steve Gibson. ;)<br> </DIV>Was it really trashing? The guy is decently stout in my book, and he's a way better programmer than I am. His only crime in my mind is being a sensationalist.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119361</guid>
<pubDate>Fri, 08 Apr 2005 11:11:57 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119342</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  cacroll <A HREF="/useremail/u/663732"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>Daniel,<br><br>There is one downside to the SMB native hosting that may be a problem.<br><br>Some folks here, like myself, may use a Hosts based setup for blocking access to malicious websites.<br>&raquo;<A HREF="http://www.hosts-file.net/downloads.html" >www.hosts-file.net/downloads.html</A><br>&raquo;<A HREF="http://www.mvps.org/winhelp2002/hosts.htm" >www.mvps.org/winhelp2002/hosts.htm</A></DIV>Ah, yes. Well, I'm working on a solution for you. :)<br><br>&raquo;<A HREF="http://www.sourceforge.net/projects/proxicus" >www.sourceforge.net/projects/proxicus</A><br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119342</guid>
<pubDate>Fri, 08 Apr 2005 11:09:30 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119162</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : I agree. If you fill up your hosts file by misusing it as a security tool, and useful system features stop working correctly, that's an argument against misusing the hosts file, not an argument against using the other system features.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119162</guid>
<pubDate>Fri, 08 Apr 2005 10:46:00 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13119137</link>
<description><![CDATA[<A HREF="/useremail/u/809112"><b>reaver221</b></A> : <div class="bquote"><SMALL>said by  cacroll <A HREF="/useremail/u/663732"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR>Unfortunately, using SMB direct hosting requires the DNS Client service to be running for name resolution.  No name resolution = no file sharing, on a peer - peer network.</DIV>Is it really that unfortunate? HOSTS-based blocking is a kludge, and a messy one at that. I mean, if things go to hell when you cache your HOSTS file... that's a problem, and as I see it, it means that a new ad-blocking method is needed, if anything<br><br>And Daniel -- very nice article. Made even nicer by frequent trashing of Steve Gibson. ;)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13119137</guid>
<pubDate>Fri, 08 Apr 2005 10:43:06 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13118861</link>
<description><![CDATA[<A HREF="/useremail/u/663732"><b>cacroll</b></A> : Daniel,<br><br>There is one downside to the SMB native hosting that may be a problem.<br><br>Some folks here, like myself, may use a Hosts based setup for blocking access to malicious websites.<br>&raquo;<A HREF="http://www.hosts-file.net/downloads.html" >www.hosts-file.net/downloads.html</A><br>&raquo;<A HREF="http://www.mvps.org/winhelp2002/hosts.htm" >www.mvps.org/winhelp2002/hosts.htm</A><br><br>Those who use either of these files have possibly noted, as I have, that performance on your computer will practically halt whenever the system caches the hosts file, and have discovered that turning off the DNS Client service is necessary in this case.<br><br>Unfortunately, using SMB direct hosting requires the DNS Client service to be running for name resolution.  No name resolution = no file sharing, on a peer - peer network.<br><br>Chuck]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13118861</guid>
<pubDate>Fri, 08 Apr 2005 09:58:00 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13118411</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR>There doesn't seem to be a <EM>huge</EM> security gain by using the "direct hosting" method for SMB functionality, but it's almost guaranteed to be <EM>at least</EM> as secure. And yes, it's definitely faster.</DIV>My guess is that the point of 'native' SMB was to make one more step to the phasing out of NETBIOS naming -- everything to use DNS ("Internet") naming instead. It's an operational pain in the rear to have two distinct naming systems.<br><br>It gets sort of blurred in the way that DNS uses NETBIOS as a last resort for name resolution, and NETBIOS uses DNS as a last resort for name resolution, but fundamentally, SMB-139 uses NETBIOS names, and SMB-445 uses DNS names.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13118411</guid>
<pubDate>Fri, 08 Apr 2005 08:46:51 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13117614</link>
<description><![CDATA[<A HREF="/useremail/u/413587"><b>nirvansk815</b></A> : <BLOCKQUOTE><SMALL>You can disable NBT for these platforms and still maintain virtually identical functionality using this "direct hosting" paradigm.</SMALL></BLOCKQUOTE><br><SMALL>--<br>There's so much to be thankful for...How can anyone be sad?</SMALL><div class="borderless"><TABLE WIDTH=95% align=center border=0 CELLPADDING=4"><TR><TD ALIGN=CENTER VALIGN=CENTER BGCOLOR=#FFFFFF nwrap COLSPAN=3 WIDTH=100%><A HREF="/speak/slideshow/13117614?c=804372&ret=L2ZvcnVtL3IxMzEwODg5Ni54bWw%3D"><IMG TITLE="41400 bytes" BORDER=0 WIDTH=404 HEIGHT=488 SRC="/r0/download/804372~63f52a6bdc5c7293e1ad65c0360c4d15/untitled.JPG"></A><br>Settings</TD></TABLE></div>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13117614</guid>
<pubDate>Fri, 08 Apr 2005 03:19:39 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13117564</link>
<description><![CDATA[<A HREF="/useremail/u/0"><b>anon</b></A> : It's a good article.  I kind of got the gist of the binding issue a couple of years back from here:<br><br>&raquo;<A HREF="http://cable-dsl.home.att.net/netbios.htm" >cable-dsl.home.att.net/netbios.htm</A><br><br>Also, I wouldn't suggest using the somewhat obscure UNIX jargon "daemon" as a clarifying point when discussing a Windows issue.  If you were just as far as the Task Manger and Control Panel -> Network Connections, the average Windows user would call use "process."]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13117564</guid>
<pubDate>Fri, 08 Apr 2005 03:04:32 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13117559</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : There doesn't seem to be a <EM>huge</EM> security gain by using the "direct hosting" method for SMB functionality, but it's almost guaranteed to be <EM>at least</EM> as secure. And yes, it's definitely faster.<br><br>Overall, however, there are a myriad of security enhancements in 2000/XP compared to the 9x family of operating systems. I wouldn't even compare them; the later generations win hands down.<br><br>Cheers.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13117559</guid>
<pubDate>Fri, 08 Apr 2005 03:02:53 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13117469</link>
<description><![CDATA[<A HREF="/useremail/u/413587"><b>nirvansk815</b></A> : Maybe I'm missing the point; (if so please direct me) <br><br>which way is: 1.) more secure? 2.) the faster performer?<br><br>Thanks.<br><SMALL>--<br>There's so much to be thankful for...How can anyone be sad?</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13117469</guid>
<pubDate>Fri, 08 Apr 2005 02:32:19 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111882</link>
<description><![CDATA[<A HREF="/useremail/u/653770"><b>TheWiseGuy</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>It is my understanding that you <EM>can</EM> 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.<br><br>Thanks for the comment; I'll definitely confirm this. <br> </DIV>I'll be very interested in the results. I have never tested this myself, I know that port 139 does listen on all interfaces but I don't think that proves that Sharing is bound to the external adapter. I read Steve's info years ago and always figured it was correct, but testing it certainly is the correct way to go.<br><SMALL>--<br>Dog and Butterfly</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111882</guid>
<pubDate>Thu, 07 Apr 2005 14:31:09 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111645</link>
<description><![CDATA[<A HREF="/useremail/u/650726"><b>funkym0nk3y</b></A> : that snakefoot site is awesome, bookmarked!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111645</guid>
<pubDate>Thu, 07 Apr 2005 13:52:02 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111592</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : Sure - it's hardly an innvoative piece of work!]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111592</guid>
<pubDate>Thu, 07 Apr 2005 13:43:36 EDT</pubDate>
</item>

<item>
<title>Re: A few historical notes</title>
<link>http://www.dslreports.com/forum/remark,13111418</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  notdedyet <A HREF="/useremail/u/192703"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>This has all the hallmarks of a "keeper" article and so, for future reference, I'd like to suggest just a few changes in the historical section.<br><br>First, NetBIOS was protocol independent. It could - and did - run over multiple protocols. While NetBEUI was the most common as it was supplied by Microsoft, other vender's protocols could be used just as well. For example, Digital sold a product called PATHWORKS which would run NetBIOS sessions over DECnet, TCP/IP, or NetBEUI on Windows 3.x systems. With the advent of Windows 9x, the PATHWORKS product contained a DECnet stack that could be bound to NetBIOS in the same way as Microsoft's TCP/IP and NetBEUI stacks could.<br> </DIV>Interesting. I wouldn't want to go into that much detail due to scope issues, but I wouldn't mind mentioning a bit more about NetBIOS's support for other protocols.  Thanks.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111418</guid>
<pubDate>Thu, 07 Apr 2005 13:20:37 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111402</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  psloss <A HREF="/useremail/u/590688"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>I think Dave's explanation about the sequencing of the SYNs, though, is worth noting.</DIV>Agreed.<br><br>Dave, can I include that in the piece?<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111402</guid>
<pubDate>Thu, 07 Apr 2005 13:18:35 EDT</pubDate>
</item>

<item>
<title>A few historical notes</title>
<link>http://www.dslreports.com/forum/remark,13111383</link>
<description><![CDATA[<A HREF="/useremail/u/192703"><b>notdedyet</b></A> : This has all the hallmarks of a "keeper" article and so, for future reference, I'd like to suggest just a few changes in the historical section.<br><br>First, NetBIOS was protocol independent. It could - and did - run over multiple protocols. While NetBEUI was the most common as it was supplied by Microsoft, other vender's protocols could be used just as well. For example, Digital sold a product called PATHWORKS which would run NetBIOS sessions over DECnet, TCP/IP, or NetBEUI on Windows 3.x systems. With the advent of Windows 9x, the PATHWORKS product contained a DECnet stack that could be bound to NetBIOS in the same way as Microsoft's TCP/IP and NetBEUI stacks could.<br><SMALL>--<br>In theory there is no difference between theory and practice, but in practice ... there is!</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111383</guid>
<pubDate>Thu, 07 Apr 2005 13:16:12 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111314</link>
<description><![CDATA[<A HREF="/useremail/u/590688"><b>psloss</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>I do.<br><br><div class="bquote"><SMALL>said by  Microsoft <A HREF="/useremail/u/922608"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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.<br><br>&raquo;<A HREF="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q204279" >support.microsoft.com/default.as&middot;&middot;&middot;;Q204279</A><br></DIV> </DIV>Cool.  Thanks.  I think Dave's explanation about the sequencing of the SYNs, though, is worth noting.<br><br>Philip Sloss<br><SMALL>--<br>Feedback? e-mail: stuff@lupwa.org</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111314</guid>
<pubDate>Thu, 07 Apr 2005 13:06:21 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111286</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : For anyone intersted, I'm cleaning up the piece as needed in its original location on <A HREF="http://dmiessler.com/archives/253">my blog</A>. Once I'm happy with it I'll likely try and seed it out to a couple of sites to see if they're interested. Thanks so much for the commentary, by the way. This was my first forum on the Internet, and I've never left for good reason.<br><br>Any other corrections, comments, or topics you guys think should be addressed?<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111286</guid>
<pubDate>Thu, 07 Apr 2005 13:02:26 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111220</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>One more thing:<br><br>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.</DIV>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...<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111220</guid>
<pubDate>Thu, 07 Apr 2005 12:51:32 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111200</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  psloss <A HREF="/useremail/u/590688"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><EM>Old vs. New</EM><br><br>When connecting to a Windows 2000/XP machine that has both NetBIOS over TCP <EM>and</EM> direct hosting enabled (from a client machine that's also using them), <EM>both</EM> 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.</DIV>Do you have a cite for this?</DIV>I do.<br><br><div class="bquote"><SMALL>said by  Microsoft <A HREF="/useremail/u/922608"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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.<br><br>&raquo;<A HREF="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q204279" >support.microsoft.com/default.as&middot;&middot;&middot;;Q204279</A><br></DIV><br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111200</guid>
<pubDate>Thu, 07 Apr 2005 12:48:48 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111180</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>A good summary. I have a couple of technical nits to pick, thoguh.<br><div class="bquote">NetBIOS using these ports was benign enough initially because they were bound to a protocol called Netbeui.</DIV>A little confusion here. <br><br>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.</DIV>Heh, that's not a "little confusion", that's gross error. :) Thanks for catching that; it was late. <br><br>Netbeui is in fact "portless", just like AH, ESP, and most other protocols aside from 06 and 17. <br><br><div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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.</DIV>Very true, and I covered port 135's role when I described each port. Perhaps I should make the distinction a bit clearer, however.<br><br><div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>As far as I am aware, RPC endpoint mapping does not use port 445.</DIV>I think it does, actually. Take for example this advisory by CERT where they advocate the following:<br><br><div class="bquote"><SMALL>said by CERT:</SMALL><br><br>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).<br><br>&raquo;<A HREF="http://www.kb.cert.org/vuls/id/547820" >www.kb.cert.org/vuls/id/547820</A></DIV>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.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111180</guid>
<pubDate>Thu, 07 Apr 2005 12:46:21 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13111060</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  TheWiseGuy <A HREF="/useremail/u/653770"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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.</DIV>And I could be wrong as well, but I don't think I am. <br><br>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. <br><br>It is my understanding that you <EM>can</EM> 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.<br><br>Thanks for the comment; I'll definitely confirm this. <br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13111060</guid>
<pubDate>Thu, 07 Apr 2005 12:25:32 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110970</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  Mele20 <A HREF="/useremail/u/403861"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>This article doesn't address file sharing between XP and 98SE boxes.</DIV>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, <EM>both types of connectivity are attempted</EM>. <br><br><EM>That's how the old shares with the new.</EM><br><br>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 <EM>and</EM> to the NBT ports. Since the 98 box is not listening on 445, it will respond via the old method and communication will ensue.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110970</guid>
<pubDate>Thu, 07 Apr 2005 12:13:19 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110880</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : <div class="bquote"><SMALL>said by  ghost16825 <A HREF="/useremail/u/864682"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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) <B>a running service with open ports</B> as a consequence  - which by itself implies that they will <B>inevitably be vulnerable</B> to buffer overflows from certain created input.</DIV>Definitely. The focus here, however, was to say on the networking side of things with a <EM>slant</EM> 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.<br><br>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.<br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110880</guid>
<pubDate>Thu, 07 Apr 2005 12:00:13 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110870</link>
<description><![CDATA[<A HREF="/useremail/u/693977"><b>bcastner</b></A> : psloss,<br><br>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.<br>Thank you.<br><br>But the User Account tool only determines whether a "Guest" can do a local logon.  This status does not affect remote access.<br><br>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, &raquo;<A HREF="http://support.microsoft.com/kb/q266280/" >support.microsoft.com/kb/q266280/</A>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110870</guid>
<pubDate>Thu, 07 Apr 2005 11:59:05 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110806</link>
<description><![CDATA[<A HREF="/useremail/u/693977"><b>bcastner</b></A> : In the intererents of completeness, the ForceGuest key is one distinguishing feature between XP Home and XP Pro.<br><br>Under XP Pro:<br>. Start Button -> My Computer <br>. In the menu of My Computer select "Tools" -> "Folder Options" <br>. In "Folder Options" select the "View" fan <br>. Uncheck the setting "Use Simple File Sharing (Recommended)"<br><br>This change should be reflected in this registry key: <br>[HKEY_LOCAK_MACHINE \SYSTEM \CurrentControlSet \Control \Lsa]<br>ForceGuest = 0<br><br>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.<br><br>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:  &raquo;<A HREF="http://www.microsoft.com/windows/longhorn/privacy.mspx" >www.microsoft.com/windows/longho&middot;&middot;&middot;acy.mspx</A>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110806</guid>
<pubDate>Thu, 07 Apr 2005 11:52:48 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110735</link>
<description><![CDATA[<A HREF="/useremail/u/590688"><b>psloss</b></A> : <div class="bquote"><SMALL>said by  bcastner <A HREF="/useremail/u/693977"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>This has nothing to do with whether the "Guest" account is enabled, but <B>Group</B> Guest.  Your decision to enable the Guest account is a decision about a local console logon, not remote access.</DIV>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.<br><br>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")<br><br>Philip Sloss<br><SMALL>--<br>Feedback? e-mail: stuff@lupwa.org</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110735</guid>
<pubDate>Thu, 07 Apr 2005 11:43:27 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110609</link>
<description><![CDATA[<A HREF="/useremail/u/590688"><b>psloss</b></A> : <div class="bquote"><SMALL>said by  dave <A HREF="/useremail/u/156437"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>(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).</DIV>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.<br><br>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.<br><br>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...<br><br>(Edit: spelling)<br><br>Philip Sloss<br><SMALL>--<br>Feedback? e-mail: stuff@lupwa.org<br><br></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110609</guid>
<pubDate>Thu, 07 Apr 2005 11:24:17 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110577</link>
<description><![CDATA[<A HREF="/useremail/u/693977"><b>bcastner</b></A> : 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."<br><br>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.<br><br>This has nothing to do with whether the "Guest" account is enabled, but <B>Group</B> Guest.  Your decision to enable the Guest account is a decision about a local console logon, not remote access.<br><br>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:<br><br>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.<br><br><B>To disable SMB use of Netbios port 139 (Forces use of port 445):</B><br><br>. On the Start menu, point to Settings, and then click Network and Dial-up Connections <br>. Right-click Internet facing connection, and then click Properties. <br>. Select Internet Protocol TCP/IP and select Properties <br>. Click Advanced and select the WINS tab <br>. Tick Disable NetBIOS over TCP/IP and click Ok <br><br><B>To disable SMB use of port 445 with this DWORD (Forces use of port 139): </B><br><br>[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters]<br>SMBDeviceEnabled = 0 <br><br><B>To disable SMB use of port 139 and 445 (Disables nbt.sys driver): </B><br><br>Right-click My Computer on the desktop, and then click Manage. <br>Expand System Tools, and then select Device Manager. <br>Right-click Device Manager, point to View, and then click Show hidden devices. <br>Expand Non-Plug and Play Drivers. <br>Right-click NetBios over Tcpip, and then click Disable. <br>To disable SMB completely: <br>On the Start menu, point to Settings, and then click Network and Dial-up Connections <br>Right-click Internet facing connection, and then click Properties. <br>Select Client for Microsoft Networks, and then click Uninstall. <br>Follow the uninstall steps. <br>Select File and Printer Sharing for Microsoft Networks, and then click Uninstall. <br>Follow the uninstall steps. <br><br>(My thanks to "Snakefoot" and his remarkable site:  &raquo;<A HREF="http://snakefoot.fateback.com/tweak/winnt/sharing.html#SMB_NETBIOS" >snakefoot.fateback.com/tweak/win&middot;&middot;&middot;_NETBIOS</A> )<br><br> ]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110577</guid>
<pubDate>Thu, 07 Apr 2005 11:18:24 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13110077</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : One more thing:<br><br>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13110077</guid>
<pubDate>Thu, 07 Apr 2005 10:09:44 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109994</link>
<description><![CDATA[<A HREF="/useremail/u/937228"><b>altermatt</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR> 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 </DIV>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. <br><br>Great explanation, and, though not addressing it in much detail, another good argument for NetBEUI. :)]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109994</guid>
<pubDate>Thu, 07 Apr 2005 09:55:12 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109979</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : <div class="bquote"><SMALL>said by  psloss <A HREF="/useremail/u/590688"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><BR><BR>Do you have a cite for this? </DIV>I just tried this with Ethereal running (Win2000 to Win2000).<br><br>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.<br><br>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.<br><br>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.<br><br>(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).]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109979</guid>
<pubDate>Thu, 07 Apr 2005 09:53:49 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109891</link>
<description><![CDATA[<A HREF="/useremail/u/590688"><b>psloss</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br><EM>Old vs. New</EM><br><br>When connecting to a Windows 2000/XP machine that has both NetBIOS over TCP <EM>and</EM> direct hosting enabled (from a client machine that's also using them), <EM>both</EM> 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.</DIV>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.<br><br>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.<br><br>(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.)<br><br>It would also be interesting to see what the Samba SMB client does...<br><br>Also, the relationship between MSRPC and SMB/CIFS isn't precise -- but I think Dave is already addressing that.<br><br>Philip Sloss<br><SMALL>--<br>Feedback? e-mail: stuff@lupwa.org</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109891</guid>
<pubDate>Thu, 07 Apr 2005 09:39:32 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109742</link>
<description><![CDATA[<A HREF="/useremail/u/156437"><b>dave</b></A> : A good summary. I have a couple of technical nits to pick, thoguh.<br><div class="bquote">NetBIOS using these ports was benign enough initially because they were bound to a protocol called Netbeui.</DIV>A little confusion here. <br><br>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.<br><br>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.<br><br>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.<br><br><div class="bquote">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.</DIV>As far as I am aware, RPC endpoint mapping does not use port 445.<br><br>Port 445 is "CIFS (nee SMB) over Native TCP", replacing "CIFS over Netbios over TCP" -- ports 137/138/139.<br><br>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.<br><br>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.<br><br>I don't know much about RPC but I know a little about SMB/CIFS.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109742</guid>
<pubDate>Thu, 07 Apr 2005 09:16:03 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109585</link>
<description><![CDATA[<A HREF="/useremail/u/653770"><b>TheWiseGuy</b></A> : <div class="bquote"><SMALL>said by  Daniel <A HREF="/useremail/u/168087"><IMG SRC="http://i.dslr.net/bb/profile.gif" ALT="See Profile" BORDER=0 WIDTH=16 HEIGHT=11></A>:</SMALL><br><br>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 <EM>internal</EM> adapter(s) so that you could benefit from file sharing on the internal, trusted network while having it disabled for the untrusted one(s).<br> </DIV>Can this be done on a Win9x or before box?<br><br>Is Steve Gibson incorrect on this?<br><div class="bquote"><SMALL>said by Steve Gibson:</SMALL><br><br>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!</DIV>&raquo;<A HREF="http://grc.com/su-rebinding9x.htm" >grc.com/su-rebinding9x.htm</A> <br><br>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.<br><SMALL>--<br>Dog and Butterfly</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109585</guid>
<pubDate>Thu, 07 Apr 2005 08:43:24 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109449</link>
<description><![CDATA[<A HREF="/useremail/u/403861"><b>Mele20</b></A> : 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.<br><SMALL>--<br>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</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109449</guid>
<pubDate>Thu, 07 Apr 2005 08:02:26 EDT</pubDate>
</item>

<item>
<title>Re: Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13109232</link>
<description><![CDATA[<A HREF="/useremail/u/864682"><b>ghost16825</b></A> : 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) <B>a running service with open ports</B> as a consequence  - which by itself implies that they will <B>inevitably be vulnerable</B> 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.<br><SMALL>--<br>Admin of the Kerio 2x-like open source project:<BR><A HREF="http://sourceforge.net/projects/kerio/">http://sourceforge.net/projects/kerio/</A><BR><A HREF="http://kerio.sourceforge.net/">http://kerio.sourceforge.net/</A><BR></SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13109232</guid>
<pubDate>Thu, 07 Apr 2005 06:32:24 EDT</pubDate>
</item>

<item>
<title>Windows File Sharing: Facing The Mystery</title>
<link>http://www.dslreports.com/forum/remark,13108896</link>
<description><![CDATA[<A HREF="/useremail/u/168087"><b>Daniel</b></A> : 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.<br><br>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 <A HREF="http://www.grc.com">his website</A> 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:<br><UL>&#8226;What's the difference between using Windows 9x and Windows 2000/XP file sharing?</LI>&#8226;Which port(s) handle(s) file transfers on Windows 2000/XP systems?</LI>&#8226;Does Windows XP use NetBIOS to transfer files?</LI>&#8226;If you disable NetBIOS over TCP/IP on a 2000/XP box, can people still connect to your shares?</LI>&#8226;What happens if you block access to port TCP/139 on an XP machine?</LI></UL>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 <EM>how and why</EM> makes all the difference when it comes to making sound security decisions.<br><br><B>Windows 9x - The Old Way</B><br><br>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.<br><br><EM>NetBIOS</EM><br><br>The beginning starts with a protocol called <A HREF="http://en.wikipedia.org/wiki/Netbios">NetBIOS</A>. 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 <EM>not</EM> 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.<br><br>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:<br><UL>&#8226;<EM>TCP/135 - RPC</EM>: This port is potentially quite dangerous due to what "RPC" actually stands for.  <A HREF="http://en.wikipedia.org/wiki/RPC">Remote Procedure Calls</A> 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.</LI>&#8226;<EM>UDP/137 - Netbios Name Service</EM>: This port is used to attain name resolution for Netbios. Think of it as Netbios's version of <A HREF="http://en.wikipedia.org/wiki/Dns">DNS</A> or <A HREF="http://en.wikipedia.org/wiki/Address_Resolution_Protocol">ARP</A>. 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.</LI>&#8226;<EM>UDP/138 - NetBIOS Datagram Service</EM>: This port primarily allows the SMB browser service to populate the browse lists seen when using "Network Neighborhood".</LI>&#8226;<EM>TCP/139 - NetBIOS Session Service</EM>: 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.</LI></UL>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.<br><br><EM>NetBIOS over TCP/IP</EM><br><br>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.<br><br>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.<br><br><EM>File and Print Sharing</EM><br><br>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.<br><br>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.<br><br>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.<br><br><EM>Countermeasures</EM><br><br>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 <EM>internal</EM> adapter(s) so that you could benefit from file sharing on the internal, trusted network while having it disabled for the untrusted one(s).<br><br>The bits about disabling the Client For Microsoft Networks and such were simply over the top. Aptly enough, the "<B>Client</B> For Microsoft Networks" is nothing more than a <EM>client</EM> <SMALL>(hence the name)</SMALL>. Disabling it had nothing to do with whether or not the <EM>server</EM> portion of File Sharing was enabled (File and Print Sharing). <br><br><B>Windows 2000/XP - The New Way</B><br><br>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.<br><br>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 <EM>directly</EM> 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. <br><br>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.<br><br><EM>Old vs. New</EM><br><br>When connecting to a Windows 2000/XP machine that has both NetBIOS over TCP <EM>and</EM> direct hosting enabled (from a client machine that's also using them), <EM>both</EM> 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.<br><br><B>Summary</B><br><br>Ok, now that we've covered a few different topics here, let's touch on some key points:<UL>&#8226;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.</LI>&#8226;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).</LI>&#8226;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.</LI>&#8226;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.</LI>&#8226;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.</LI></UL>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 <A HREF="mailto:daniel@dmiessler.com">daniel@dmiessler.com</A>.<br><br><SMALL>Edit: Corrections Made Per The Thread Below</SMALL><br><SMALL>--<br><A HREF="http://dmiessler.com">dmiessler.com</A> - grep understanding knowledge</SMALL>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/remark,13108896</guid>
<pubDate>Thu, 07 Apr 2005 03:43:26 EDT</pubDate>
</item>

</channel>
</rss>
