[conspire] (forw) Re: Cabal

[Rick Moen]

----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Thu, 7 Jul 2011 17:39:25 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Dave Pearce <daveryu at yahoo.com>
Subject: Re: Cabal
Organization: If you lived here, you'd be $HOME already.

Further thoughts on the main point:

Quoting Dave Pearce (daveryu at yahoo.com):

> I should explain further.  This model will be a test to learn on as I
> have no experience with servers yet.  I wish to store files on it that
> I can access remotely from anywhere.  Data files (such as homework
> that I've left more than once on the main computer without realizing
> it until I got to school), music files (to access my music collection
> from a distance - good practice on moving files if nothing else), and
> ultimately moving/altering patient files from a database when I
> graduate. 

I appreciated your kind words about my explanations having a high
success rate of explaining things in ways you understand.  One tries.
The most difficult part of that, actually, is remembering which bizarre,
non-intuitive practices one has gotten _so_ used to, over 35+ years on
public computer networks, that they have become second nature, and you
forget they're alien to newcomers.

Which brings me to the point of this mail:  The Things We Do (and Don't
Do) Because of Internet Security Issues.

You have an MS-Windows machine in the office.  It uses file and print
service over the office LAN.  Want to reach a remote printer?  No problem:
Someone advertises it onto Network Neighbourhood using Windows File and
Print Sharing (technically, SMB-type network services), and you browse
for it and select it as your default printer over the LAN.

In the late 1980s and early 1990s, many companies suddenly direct-connected
their offices to the global Internet.  Immediately, out on the Internet,
their private file shares, networked fax machines, and networked
printers became visible from the entire globe.  Hilarity ensued.  Turns
out that the sorts of resource-sharing network protocols commonly used
in offices for, e.g., browsable file and print services were engineered
for a kinder and friendlier world than the global Internet.  (Did
businesses learn their lesson and retire/replace those too-trusting
network protocols?  Nope.  Instead, we got the Cult of the Holy Firewall.)

Any time you expose a machine directly to the Internet, even via
dynamic, at-need connections, even on Dynamic DNS and DHCP, even on
dial-up PPP modem links, you are exposing it to potential attack by some
significant fraction of 7 billion people -- and their canned probing
scripts that figuratively shake your system's doorknobs to see if
they're locked many, many times a day.

By _no_ means is this problem specific to Linux deployments.  In fact,
the owners of literally tens of millions of Windows desktop machines
who, at any given time, are unaware of their boxes having been taken
over by attack scripts running from eastern Europe and zombified to 
send spam and participate in botnet gangwars, really ought to be ashamed
of themselves but are too clueless to care.

To use security jargon, each machine on a network has an 'attack
surface' consisting of the network software stack and any network
services it advertises (for use by remote users and remote client
software) onto the network.  Attackers attempt to find and subvert any
portion of that software or its configuration that gives them a way to
either gain unauthorised access or unauthorised ability to
deface/change/subvert what you are making available to the public.

So, you always have to be mindful of your attack surface, and cautious
about what and how you make things/services available to remote
locations.

You might plan to leave your server running at home, offering network
access, and being able to use your own or other machines from remote
locations to browse your shared server hard drive's folders as if they
were local folders, reaching across the Internet.  You might, for
example, expect to be able to do this from your own or other arbitrary
Windows workstations or laptops, using Windows Explorer and Network
Neighbourhood.  Unfortunately, by itself, without a great deal of extra
configuration and software-installation work on the Windows client
machine itself, Windows expects to use plain, unadorned SMB-type network
protocols.  Which just aren't Internet-safe.

You might ask:  What else is there?  In the old-school Unix world, we've
tended to use _on local LANs_ a protocol called NFS (Network File
Service) for remote mounting of shared file directories.  Unfortunately,
the wags call NFS 'No Friggin' Security', because it, too, isn't
Internet-safe.

If your remote client workstation or laptop is a Linux machine, you have
a lovely workaround that you can use called FISH (FIles over SsH), about
which please see 'FISH Protocol' on
http://linuxmafia.com/faq/Security/fish-protocol.html .  Any
FISH-compliant software can remotely browse and manipulate server-side
files as if they were local, reaching over an encrypted, reliably
secure SSH tunnel to the server.  Thus, all you need to run on the
server is an SSH daemon.  The result is a remarkable Network
Neighbourhood-like browse-and-use experience -- without special security
worries.

Among the FISH-compatible pieces of software on Linux is Konqueror, the
Web browser and local file browser produced by the KDE desktop project.
There are also a number of other really lovely pieces of software that
are FISH-compliant.  Please see my page for details.

Now, please note:  I did not say 'You should plan on using Linux remote
client machine and FISH-compliant file-browsing software only'.  What I
said was that it was _one_ category of solution that can give you the
sort of functionality you probably have in mind.

You might wonder what I personally do.  Personally, what I tend to do 
might be seen as roughing it.  I don't enable full-blown browse-and-use
graphical desktop access to anything on my server.  I tend to SSH into
my server from the command line and do things from the bash command
prompt remotely.  That includes this e-mail, which I'm composing from a
non-graphical console e-mail program running _on_ my server, which I'm
typing into remotely over an SSH session.  If I need to move a file
between my current physical location and my server, I do it using a
command like this:

   scp rick at linuxmafia.com:/tmp/somefilename .

That's scp = secure cp = the SSH simple file-copy-over-the-tunnel
program, saying to copy the remote file /tmp/somefilename over the
SSH tunnel to '.', my current location on the machine in front of me.

Why?  Because that mode of remote communication -- ssh and scp -- always
and everywhere works, regardless of what sort of machine is in front of
me, regardless of where I am, regardless of how slow the connection is.
And everything runs over the encrypted, authenticated SSH service, 
reducing the security risk to what I can deal with and understand.

There are no doubt other ways to do things, that aren't as much like
roughing it.  I'm just saying it Works for Me<tm>.


----- End forwarded message -----