[KLUG Members] Re: remote laptop over internet?

[Bryan J. Smith]

"Michael W. Holdeman" wrote:
> No ssh is setup at this time, I'll be upgrading the server to
> Suse 7.2 proffesional soon, and wish to include all that is
> necessary to acomplish this task.
> I have heard that NFS exporting is VERY risky, and insecure?

As usual, someone interjects some unintentional "FUD" with the
neverending phrase, "I have heard."  Michael, I am *NOT* singling
you out -- so don't feel bad.  While there have been some security
issues with RPC (portmapper), NIS (ypserver, yppasswd, ypbind) and
NFS (various services), there are nothing new to network filesystem
and related services ("Windows Networking" has _more_holes_ -- even
if you use Samba on your server!!!)>  This "unfamilarity" is
_very_commonplace_ in LUGs.  Even the main author of "Samba
Unleashed" showed has shown his gross NFS naivity on several
occassions (and from what I can tell, you know more than him ;-).

With that said, let's look into this further ...

_Any_ network filesystem, SMB, NFS, AFS, CODA, etc... or internal
authentication system, CIFS, NIS[+], LDAP, Kerberos, etc... should
be considered _possibly_insecure_ and steps should be taken to
minimize access to them.  Limiting their influence to behind a
firewall is the first step, and minimizing password transfer or
password equivalent transfer is another, solid move (e.g., with
Kerberos).  Lastly, encrypting your transfers, like with Samba-SSL
(which doesn't work with native Windows clients, and Windows doesn't
offer fully encrypted sessions -- just Kerberos ticketing with
Win2K+) or NFS v4 (which is still in implementation phase) is yet
another good move.

So, at this time, you're taking "a chance" with _any_ network
filesystems on _any_ LAN.  Of course, you're doing the same with
ident, lpd, and a host of other, often "necessary" services on a
LAN.

BTW, for those that think CIFS (which is the part of SMB that
handles authentication in "Windows Networking") is "more secure"
than NIS, _think_again_!  Before Win2K/Kerberos, "encrypted
passwords" in CIFS were sent as _full_password_equivalents_ (every
Windows password is converted to a 32-byte "password equivalent"
which is used instead, but is, for all intents and purposes, "clear
text" to the services) -- i.e. you had the _exact_password_string_
necessary to unlock any SMB resource (even if you didn't know the
seeding password itself).  If you leave Win2K/XP in "legacy,
compatibility mode" (i.e. you don't have a 100% Win2K/XP network
;-), you _still_ have this problem.  At least most UNICIES, and most
NIS implementations, use a MD5 hash, which is a two-key system
(which means you still had to either know the password, or brute
force it).  And NIS+ improves upon this, although it introduces some
various incompatibilities and issues with many UNIX clients (i.e.
NIS+ isn't exactly "backward compatible" in many respects -- hence
why most Linux distros only ship with an NIS server and client).

> even with sh??

Er, how?  SSH tunnels all traffic over the SSH port, so any
"external holes" will be limited to SSH itself (assuming you have a
solid firewall and only port 22 is opened to your LAN/remote
access).  So portmapper/NFS "issues" are limited.

-- TheBS

-- 
Bryan "TheBS" Smith  mailto:b.j.smith@ieee.org  chat:thebs413
Absolute Value Systems, Inc.        http://www.linux-wlan.org
SmithConcepts, Inc.              http://www.SmithConcepts.com