Blake,
I got this from another list I'm on-hope this helps-
NFS = NETWORK FILESYSTEM [SERVICE]
It is the primary network sharing file service used by UNIX systems
developed in the early '80s by SUN (which originally stood for
"Sanford University Network" before Sun Microsystems was founded
;-). NFS is a truly "distributed filesystem" (DFS) ** where
directories on a system could be local, on the local LAN, on a
wide-area network, etc... and can be switched at anytime as the
server it is located on is unimportant (and can even be _dynamic_!).
[ ** Side note: Microsoft offers a "DFS" for its Windows
Networking, although it's still not the same. The latest Samba 2.2
release can fully emulate this capability -- at least as good as
non-"Active Directory" networks -- more below. ]
NFS' "near-equivalent" in the Windows world is SMB = System Message
Block -- hence the name "SaMBa" for the UNIX service that provides
the "Windows Networking" equivalent. Where SMB works on a per-user
basis, NFS works on a per system basis. E.g., under NFS, I might
have _all_ user directories under /home. Under the SMB model, I
would normally mount only /home/bob when BOB logs in (and need to
have the scripts to match). Under the NFS model, I just have my
system mount the /home directory from the server once, period ** --
which is important as UNIX is a _true_multiuser_system_. I.e. you
could have _everybody_ logged in at once ;-) and mounting all these
different directories could cause extra overhead!
[ ** Side note: Most UNIX flavors have an "automounter" service
that can mount/unmount filesystems, including NFS, as they are used,
unused for a period of time (or timeout when inaccessable). I won't
get into it here, but some flavors have very powerful automouting
capabilities -- so clients can even "switch servers" when a server
goes down -- all without the user noticing in some cases. ]
Because of this "system-level" instead of "user-level"
authentication, it's obvious that NFS can be a security risk.
Depending on your authentication mechanism, trusting a client with
full root-level access to your server may be a bad move. Using
newer versions of NFS, like v3, various directory services, or
ticketing authentication mechanisms can improve this, although it's
up to the administrator to know what his UNIX NFS client can and
cannot do, and to weild it proficiently.
One thing to remember about NFS is that it is _very_old_ -- as old
as MS-DOS itself! NFS was around before IBM-Microsoft even began
talking about SMB and LAN Manager (which became NT and "Windows
Networking" later on), and was 10 years old when the concept of what
would become "Windows NT" was even being consider at the highest
levels in Microsoft.
This leads me into my next, related service discussion ...
NIS = NETWORK INFORMATION SERVICE
If NFS is the UNIX "equivalent" of the SMB "file service" on
Windows, NIS is the UNIX "equivalent" of the largely undocumented
CIFS (Common Internet Filesystem) "directory service" of Windows
**. NIS, like NFS, is close to 20 years old. NIS was originally
named "Yellow Pages" (which is a registered trademark of British
Telecom, so Sun changed the name) and this still is readily apparent
(programs: ypserv, ypbind, yppasswd, etc...). Part of Sun's
"revised" Open Network Connect(?) (ONC) specification, NIS+ was a
more secure version of NIS that never caught on. Largely because
many UNIX flavors improved upon NIS themselves -- including Sun (see
more on this below).
[ ** Side note: CIFS is actually both the
directory/authentication/controller services and the underlying file
sharing service, basically a "redifinition" of SMB of sorts. Quite
_un_documented and often "conflicting" with SMB for
"proprietariness." But CIFS is more directly comparable to NIS than
NFS for purposes of this discussion, so I will make the NFS is to
SMB as NIS is to CIFS here. ]
NIS, like NFS, has come under some fire in recent years for various
security issues **. Some of this is warranted, but not unexpected
given the age of NIS/NFS. Existing NFS v3 (which actually pre-dates
NT's release) and Internet-focused v4 (which is more recent) address
many of the security concerns file-wise. NIS is slowly losing
marketshare to LDAP (Lightweight Directory Access Protocol -- a
subset of X.500) and/or can be combined with Kerberos ticketing to
improve on some issues.
[ ** Side note: Actually, security issues usually involve not NIS
and NFS themselves, but the underlying RPC (Remote Procedure Call)
services -- usually via "portmapper" -- which NIS/NFS use. Not many
things other than NIS/NFS use RPC, because they are not used for
many things outside of file services. E.g., SMB/CIFS use an very
NIS/NFS-like RPC approach -- which shows that like many things on
the Windows platform, they are modeled after existing UNIX
approaches. ;-P ]
Even when LDAP is used, LDAP doesn't provide various "NIS maps" that
some networks use. E.g., almost any normal UNIX file can be made an
"NIS map" so it is advantages to make some "maps" for common files
in a UNIX network (like TCP-UDP/IP service ports). In such
networks, LDAP is usually used on the "enterprise backbone directory
server" and NIS is used in the "local department" (NIS is usually
combined with relevant DNS "domain names") -- with scripts/services
generating appropriate NIS maps, and real NIS maps doing what LDAP
doesn't address.
Which brings me to my final discussion ...
SECURITY ISSUES WITH AUTHENTICATION
First off, I mentioned Kerberos. Kerberos was actually part of the
MIT Andrew project in the '80s. Andrew also produced an NFS
replacement, the AFS (Andrew Filesystem) which is a nice,
cross-platform, virtualized network file sharing approach. I have
never personally used AFS which, like many MIT projects under the
MIT license, became a largely commercially supported network file
service. But the recent IBM OSS'ing of its AFS code into the
OpenAFS fork makes it a viable network file service to consider once
again. [ That's all I'll say about that -- because AFS is a "whole
new ballgame" that is quite different, and incompatible/separate,
with/from NIS/NFS and CIFS/SMB. ]
Getting back to Kerberos itself, you've probably heard of it because
it is what Microsoft Windows 2000/XP use in their ActiveDirectory
authentication. Microsoft adds some proprietary fields to Kerberos
records, plus they withheld these changes for 2 years, despite their
contractual obligations with MIT/IETF to release them immediately.
But it is believed that the OpenLDAP/Samba projects will soon
reverse engineer support for these "required additions".
Which brings me to my final point, _actual_security_ of non-AD
Windows networks.
There is a _lot_ of FUD (Fear, Uncertainty and Doubt) about SMB
being "more secure" than NFS. Some is intentional with even more
unintentional coming from Linux users themselves. Whether were
talking native NT PDC/BDCs, or Samba servers, this is _utter_bull_.
In a non-AD network, be it NT 3.1 through 4.0 or Win2K/XP in
"compatibility mode" (again, non-AD), supposedly "encrypted
passwords" are actually send as _quite_insecure_ "password
equivalents." I.e., passwords are symmetrically encrypted meaning
you can "sniff" this "password equivalent" off-the-wire and use it
to gain access right into an SMB share because it doesn't care what
the actual password is, just that 32 byte string!
Although the original NIS/NFS services used unencrypted or symmetric
encryption, newer versions of most UNIX password files, pluggable
authentication module (PAM) systems, or other authetication
mechanisms uses a two-key MD5 (or other) cipher key exchange
approach. That means that passwords sent over an NIS or NFS RPC
call are *NOT* sent as "password equivalent" -- they are then used
on the local system to grant access _after_ they are put through a
crypt function (and not a simple "text comparison" like non-AD
CIFS/SMB). As such, sniffing these passwords will not do you any
good unless you already have root access to one of the NIS servers
or clients anyway (although there are a few tips/tricks to getting
that with an "foreign" box introduced on a LAN -- so it's still not
"perfect" ;-).
Since most Linux distributions today use MD5 passwords, assuming you
are using recent portmapper and NIS/NFS services, NIS/NFS is
probably _more_secure_ than native SMB or Samba file sharing, unless
you are using AD. Of course there are a _lot_ of variables and an
incorrectly setup NIS/NFS network (which is easy to do for
"compatibility") could open up "holes" due to NFS' system-level
access (whereas SMB is user-level access). But my point here is
that there is just too much FUD going around that NIS/NFS is not as
secure as CIFS/SMB when it is actually the reverse in many cases!
Plus you have the option of using Kerberos'ized versions of NIS/NFS
to further reduce key exchange (and sniffing opportunities)
altogether.
[ Side note: There is also the FUD that Samba is not as secure as
native NT PDC/BDCs when the "insecurity" is actually the CIFS/SMB
protocol itself! "Encrypted passwords" is a _farce_ in non-AD
networks using CIFS/SMB! So don't believe that FUD either!
"Encrypted passords" = a fixed, verbatim transferred, 32-byte
"password equivalent" with _any_ version of Windows -- _unless_ you
use ActiveDirectory with its Kerberos ticketing. Actually, there is
an SSL'ized version of Samba which, of course, doesn't work with
actual Windows clients, so is useless in many cases. ;-PPP ]
FINAL RULE OF THUMB ...
*ALWAYS* PUT *BOTH* NIS/NFS AND CIFS/SMB SERVERS *BEHIND* A FIREWALL
THAT *DENIES* ANY AND *ALL* ACCESS TO THE PORTS THEY USE! Both are
*NOT* designed to be "public" services -- *NEVER* assume "I'll be
safe" with them on a public network -- let alone mount their
services from publicly accessable servers (even if your servers are
on a protected LAN, the "public" client could be compromised,
leading to a compromised internal server). Heck, I don't even like
home users VPN'ing to an office and accessing them -- who knows
where their home system has been and what might have possibly
compromised their systems (even if they are behind a firewall).
"Blake R. Fowkes" wrote:
> Part 1.1Type: Plain Text (text/plain)
http://www.sunbelt-software.com/ntsysadmin_list_charter.htm
