From: SMTP%"everhart@mail09.mitre.org" 22-JAN-1998 17:25:28.40 To: everhart@GCE.Com (everhart@gce.com) CC: Subj: FWD: Re: possible port number solution? --===_tgate3_44053_96623011_=== Content-Type: text/plain; charset="us-ascii" ----- Forwarded message follows ----- X-Sender: lkcl@cb1-gw.cb1.com Date: Wed, 21 Jan 98 13:09:07 -0500 Reply-To: Common Internet File System From: Luke Kenneth Casson Leighton Subject: Re: possible port number solution? To: In-Reply-To: <9801210904.ZM5927@indy.thursby.com> On Wed, 21 Jan 1998, Paul W. Nelson wrote: > This whole thing is turning absurd. Andrew claims that no port but 139 is > acceptable for CIFS, while there are numerous people saying why 139 wont work. ok, here is as complete a summary of the issues as i can make, as i understand them, so far. it's from several angles, some of which are repeated. the aim is that you could do a flow-diagram, tracing through the various problems, picking an acceptable solution. my preference trace through and solve _all_ the problems. @begin-software-engineering-lecture microsoft's failure to release the draft-cifs-v1-0.1 with enough time to spare probably means that _we're_ going to have to put up with the consequences of their actions. implementing something as a means to understanding the problem is good: it's called prototyping. you're supposed to throw away prototypes. you're supposed to allow sufficient time to re-implement. at the very worst, allow sufficient time to shuffle the prototype into some sort of reasonable first-release version (preferably late beta. or suffer the consequences. @end-suck-eggs-lecture (...or is it?) problem 1: exploitation (security) for non-139: exploitable in a bad way (spoofing) con non-139: exploitable in a good way (write your own cifs-over-tcp server) for 139: can't exploit it - netbios services already running on 139. con 139: 139 runs netbios. therefore it's usually blocked (period). solution - for non-139: block non-139. difficulties for firewalls if it's > 1024. con non-139: don't block, but make sure there is cifs security verification so that good/bad exploitation is detected. need this to be *completely* specified. properly. fully. useably. this is likely to be too complex, or just not going to happen (spec or implementation). for 139: no fix needed. introduces problem of backwards-compatibility which you can detect. microsoft doesn't want to re-use port 139 at all, but i'm sure that something could be written into their kernel to redirect extended netbios session requests to a different process. so _that_'s not a problem. con 139: replace NetBIOS daemon with a CIFS-only daemon. persuade admins to unblock port 139, but you still have old NetBIOS machines to deal with. problem 2: blocking of NetBIOS (137-139) by administrators for non-139: good. gets round the blocks, at some sites (cifs-tcp only). con non-139: not good (for unix) to have a port > 1024. ok (just for this issue?) to have a port < 1024. for 139: blocking NetBIOS also blocks CIFS, which is probably a good idea! con 139: can't enable 139 without enabling NetBIOS apps as well. fix - for non-139: no fix needed, but introduces a new problem if you want to block CIFS (period). con non-139: gives admins _another_ port number to have to block! causes problems with other services and with firewall rules, if it's > 1024. for 139: replace the NetBIOS kernel with a CIFS-tcp-only one. have a detection mechanism built into the CIFS client to detect first new and then old protocol (new first, so as to reduce the round-trip count over the internet for cifs-tcp-only). con 139: some kernels may not be replaceable, so make sure the latest version of CIFS can still be run over port 139. problem 3: CIFS-over-tcp versus CIFS-over-NetBIOS for non-139: you can leave port 139 for netbios, cifs-over-tcp for non-139. supporting both ports is a bit of a pain. con non-139: you have a firewall-blocking issue: you need to block both 139 and non-139 if you want to stop cifs. for 139: port 139 gets blocked by admins who don't want NetBIOS. con 139: you need to modify the netbios kernel if running cifs-over- both tcp and netbios. this may not be possible. fix - for non-139: an implementation issue. thunk down onto sockets, where the cifs-netbios or cifs-tcp issue is irrelevant because it's properly abstracted. con non-139: convince administrators that CIFS-over-tcp is secure enough to let through a firewall. firewall admin problems if port is > 1024. for 139: firewall admins must add rules to allow new cifs-tcp-on-139 servers through but not old netbios servers through, or use a port 139 cifs proxy server (e.g inca technologies cifs proxy server) con 139: run *either* cifs on 139 *or* netbios on 139. client auto-detects. these are as many issues as i can think of. it's all very silly. my vote is for: cifs-over-tcp _and/or_ cifs-over-netbios on port 139, as a configureable option. advice to microsoft: default installation of nt server: cifs-over-tcp with *no* netbios support. option in nt server-backwards-compatibility-with nt 4.0 (which you have to do for nt 3.5/4.0 domains anyway) to offer two sub-options: re-enable netbios or enable both cifs-over-tcp _and_ cifs-over_netbios. but always on port 139. > One question though: Has there been any thorough security analysis done and > presented on this list? I haven't seen anything comprehensive. we're file server people, not security people. i agree that cifs needs a security review. one that even microsoft must accept, that will emphasise (how many more times must we go through this. until the internet is destroyed, or we're all microborg-we-are-one-all-will-be-assimilated?) that protocol review _before_ implementation by peers is really important, unless you want egg on your face. microsoft-omelette, anyone? luke ---------------------------------------------------------------- Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp contains important info including how to unsubscribe. Save time, search the archives at http://discuss.microsoft.com/archives/index.html ----- End of forwarded message ----- --===_tgate3_44053_96623011_===-- ================== RFC 822 Headers ================== Return-Path: everhart@mail09.mitre.org Received: by norlmn.gce.com (UCX X4.2-14, OpenVMS E7.1-1H1 Alpha); Thu, 22 Jan 1998 17:18:30 -0500 Received: from mbunix.mitre.org (mbunix.mitre.org [129.83.20.100]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id HAA19288 for ; Thu, 22 Jan 1998 07:40:49 -0500 (EST) Received: from TGATE3 (tgate3.mitre.org [129.83.20.27]) by mbunix.mitre.org (8.8.8/8.8.8/mitre.0) with ESMTP id HAA25711 for ; Thu, 22 Jan 1998 07:44:26 -0500 (EST) Received: from mail09.mitre.org (unverified [129.83.20.43]) by tgate3.mitre.org (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 22 Jan 1998 07:43:31 -0500 Received: by mail09.mitre.org; (5.65v3.2/1.1.8.2/22Jun94-0628PM) id AA14998; Thu, 22 Jan 1998 07:43:27 -0500 Subject: FWD: Re: possible port number solution? From: everhart@mail09.mitre.org (Glenn C. Everhart) To: everhart@GCE.Com (everhart@gce.com) Message-Id: <980122074326.31233@mail09.mitre.org.0> Date: Thu, 22 Jan 98 07:43:27 -0500 X-Mailer: MailWorks 2.0-4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_tgate3_44053_96623011_==="