[KLUG Members] Re: remote laptop over internet?

[Michael W. Holdeman]

Thanks for the clarification Bryan. And no personal issues taken!.
This is the type of information I need. 
I think my first course of action will be to resurect the old 486DX machine I 
have lying around and place it into service as teh Gateway/Firewall. That 
gets teh firewall off the file server. Then I'll update teh server to Suse 
7.2 stuff, with ssh. Hence closing all ports but 22 if I understand 
correctly. Since I am a relative newbie to Linux I'll probably need some help 
with this, so when I'm ready I'm sure I'll be back here, begging for answers!


	Mike

On Tuesday 24 July 2001 17:33, you wrote:
> "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