Robert Weaver writes:
> I have a client who wants to do a project that involves having
> users upload some extremely sensitive data via the web. They are
> very concerned about the security of this information, not only
> keeping the information confidential but also reassuring their
> clients (for whom they are doing the project) that there is no
> possibility the information will be compromised. [...]?> The problem
> is what happens to the data after it reaches the server.
>
> Their current ISP is fairly disorganized and conversations with
> them has only convinced my client that they will never be
> comfortable setting this project up where they have their normal web
> pages.
Hm... sounds lke you have some fairly stringent (although not
entirely unreasonable given the circumstances) security requirements.
My first comment is that there are a lot of ISPs and IPPs out there.
I have no idea whether any offer "secure" hosting (i.e. more secure
than normal). I doubt you'll find them advertising it if they do -
it'd just make them a target. You may have to narrow your list down
and contact them to find out. I have no doubt you'll pay a pretty
penny for a high-security server and for *real* security you'll no
doubt have to deal with some constraints imposed by the security.
The guys at www.bravenewworlds.com are not cheap, but are
probably a better bet than your average McISP when it comes to keeping
their systems and and network secure. They also might be able to help
you implement my next suggestion (though I haven't asked them about
it), which is to use public key encryption on the server to keep the
data safe and secure until it's downloaded.
Public key encryption, of which the most well-known example is
PGP, is where you have two keys, public and private. Using special
"one-way" mathematical functions that I can't explain, let alone
understand :-), the public key can be used encrypt but not to decrypt.
The private key is necessary to decrypt. You can hand out your public
key to all and sundry so they can send you private messages, or use it
in a less secure context (like the web server) to encrypt data. Keep
your private key private and use it to decrypt the data once you hvae
it on a more secure system. A variant on this technology is used in
SSL.
There's still a window of vulnerability, since the web server
itself could be subverted and the program that ordinarily takes the
information could be replaced by one that mailed it off to somewhere.
But the window is much smaller, and the data submitted up to that
point is safe from prying eyes. There are other precautions you can
take against such subversion, for example a program like Tripwire.
Tripwire is a security program from the COAST project (I don't
know if there are any commercial versions available, but the source is
available from the COAST ftp archive). You run Tripwire against the
files in your system to produce something like a checksum. A Checksum
is a unique number derived from the data in a file; checksums are
normally used to be sure that a chunk of data survived transmission
intact. Checksums, however, can be faked - a checksum doesn't
guarantee that the data in two files is identical, but it's extremely
unlikely that two different sets of data would produce the same
checksum number.
Used properly, neither Tripwire nor the checksum values should be
stored on the computer. Ideally they'd be stored in an un-mounted,
physically disconnected drive. Then you periodically (daily or maybe
even hourly if you're *really* paranoid) connect, mount, run, compare
the numbers, unmount and disconnect. Or, rather, to really, really be
paranoid, you unmount the data drive and plug it into the system (not
connected to the network) that has Tripwire. This avoids any
possibility of your system being compromised and a wily intruder
actually subverting the process of your running Tripwire. This is,
needless to say, unlikely, but then again, security is a matter of
degrees.
Needless to say, this is all a big pain in the ass. Tripwire
should be run regularly to determine if your program files
(particularly if your program files are binaries, not scripts) have
been subverted. If you have a Linux system of your own and you're
competent with it, you should be able to figure out things and keep
the Tripwire software and logs on your box, connecting to the web
server and uploading them (or downloading the files you're keeping
track of, whichever is smaller and easier) and checking.
(Come to think of it, you could get a rudimentary level of
Tripwire-like security by simply re-uploading fresh copies of your
software. Of course, you quickly run into trade-off issues. If it
were just the perl scripts in your CGI-bin directory, for example,
that'll go pretty fast, but you have no idea whether the Perl
interpreter was subverted, not to mention the webserver, which might
be subverted and set up to run a different interpreter or a different
script altogether).
Which brings us to the next issue, which is how do *you* get
secure access to the web server.
Security isn't about not allowing access to things, it's about
allowing controlled acess. Otherwise, the best firewall in the world
would be a brick. If you manage to find an ISP and convince them to
take these elaborate precautions for you, they're not about to turn
around and let you log in over the internet in the clear. You need to
get to your server in such a way that your packets can't be sniffed by
somebody else somewhere along the way, either in *your* local network
(or your dialup ISP's network) or in the local network where the web
server is hosted. Enter Secure Shell (ssh) and SecureCRT.
Secure Shell is a program for securely logging into a Unix
system. It uses some of the techniques I discussed above to create an
encrypted "tunnel" through which the two programs (one on your box and
one on the web server) can send and receive information. This is
somewhat like SSL, but I won't even begin to try to explain how it
works.
The important point to realize is that besides allowing encrypted
telnet sessions, Secure Shell can be set up to allow encrypted
connections of all sorts. It's fairly common for people to use Secure
Shell to allow secure FTP via "port forwarding", for example. I know
a guy who set up a secure shell tunnel from his home linux box to his
work linux box and routed his work pop server through it. That way he
could run his favorite mail client at home and just point it at the
standard email port and get a secure connection to his work mailbox.
SecureCRT is a commercial product (with a 30 day demo avaialble
for downloading) that will provide Secure Shell capabilities on an
MS-Windows OS. It also provides excellent vt100 emulation. Well
worth the $30 for a license.
I guess you can see there's a lot involved in maintaining a
high-security site. I haven't even touched on the extensive network
and system security measures that are necessary, and things get even
more work-intensive when you have a large user population in your
local network or even worse, on the same box (you'd be better off
colocating your own box so you can avoid worrying about other users as
much). Still, if you find a reasonably careful ISP/IPP and take some
extra measures as I've described, you can attain a much better than
average level of security with some diligence and planning.
Steven J. Owens
[EMAIL PROTECTED]
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
