Joe Geiser writes:
> I would tend to agree with this statement, using the companies cited....
> The services part is not the
> expensive part either...
> Less than $10,000. What's $10,000 - when it
> could cost millions to reconstruct lost data (how many of these sites
> actually do a backup each night?)
I previously described the fact that five of our standard, business-oriented,
no-real-data-processing-staff-onsite, HP3000 users already have placed their
HP3000s on the internet, with telnet access. I'm impressed by this because
this seems to me to be a faster uptake of a technology than even their
adoption of fax machines 10 years ago.
I also mentioned that I would bet that none of them have configured their
INETDSEC files to allow or disallow anyone. It's not only the kind of thing
that most businesses don't tend to do, it would also be an enormous bother to
keep current. As empirical evidence to further that contention, I've always
been able to get right in, as soon as they've given me their IP addresses --
and they certainly have never asked me my origination IP address.
But Joe also asks, how many of them do nightly backups? I can say with almost
metaphysical certainty that all of them do. These people very well understand
the risks of losing data. And they understand that their equipment, even
though it is primarily HP manufactured, can fail at any moment.
The real risks of losing data are approximately these, with each level being
approximately 1/10 to 1/100 of the threat the level above poses:
o simple equipment failure (particularly discs)
o fire
o flood
o internal deceit
o external deceit
.
.
o direct government intervention
o giant asteroids
(adding in Stan's comments :-).
But to put my money where my mouth is, I spent a part of yesterday ordering a
frame relay circuit, to be connected directly to one of our production
HP3000s. There will no external firewall box, nor will there be any allowed or
disallowed accessors. The architecture will be as simple as I can make it --
and generally duplicative of the way that I believe most small office/remote
office HP3000s will come onto the internet.
The only security that will be present will be the traditional security
capabilities of the HP3000 and a router with network address translation
(NAT). The HP3000 is currently connected to an internal, private address space
LAN (the HP3000's IP address is 192.168.1.1; an unreachable address from the
internet, by definition).
After half a day's investigation, I've settled on a Cisco 2610 router. It
seems appropriate in terms of capabilities [most necessary: NAT capabilities],
midway in price and expandability between the smallest and largest in the
line. (The 2610 also has optional remote access capabilities for eight analog
modem ports, which was Gilles' original question :-).
While I would very much like to have the "after 10 failures, bar the remote IP
accessor, forget the list after a day" algorithm in place, there should still
be sufficient security in place to allow this HP3000 on the internet without
harm. Now don't get me wrong, I know just saying this is a challenge to a good
number of you -- and I expect attacks.
I will post the IP address of the HP3000 when it's up and running. I set an
installation due date of February 1 (December's calendar is completely filled,
so I would prefer to do this in January).
Of interest, Intel promotes a very similar philosophy. On their web pages,
they write:
"Your network security should strike a balance by allowing
users to work productively, safely—both internally and
externally."
And to prove that there are no original ideas, Intel also writes:
"You can keep unwelcome visitors from getting into
your network with a firewall—a special kind of
software that acts as a gateway between your internal
network and the outside world. You can set up a
firewall to restrict access to your network and then
accept or reject files based on the restriction
parameters you choose. Or a firewall can monitor who
is trying to use your system, and keep a log so you'll
know if someone is trying to break in. For example, it
might disconnect someone who has input an incorrect
password five times, and keep a record of the user's
location."
from Intel's URL:
http://www.intel.com/businesscomputing/small/ComputerNetworks/NetworkSecuri
tyArticle.htm
Telnet on the HP3000 is more restrictive now that Intel's recommendataions; it
disconnects you now immediately on your first incorrect password, not waiting
for five missed attempts. Automatically having the remote IP address being put
into a reject list after 10 such failures would slow an attack down to
something much less than a crawl.
I gather someone has already given some thought to this because it now takes
an interminable amount of time for "connection refused by host" message to
come back to the originating telnet client if your IP addressed is barred.
During that time, the client is essentially locked, waiting for some
resolution of its earlier attempt at making a connection to the HP3000.
PASSWORD ENCRYPTION
On a second subject, in response to Ken Sletten's repeating his concerns about
passwords being transmitted in plain text accross a network, several people
wrote me privately about the subject. Surprisingly, every one of the
correspondents proposed putting the encryption into the telnet transport.
While whatever form of encryption is adopted has to be done cooperatively both
in the terminal emulator and MPE itself, I don't believe that telnet is the
place to do it. Rather, it should be in MPE and in the terminal emulator,
without regard to the communication mode (direct wire connect, dial-up, NS/VT,
or telnet).
Indeed, it's easy to perform the encryption in a manner that is completely
compatible with all prior use and traditional to the HP3000.
There are several unused bits in an HP terminal's primary and secondary status
words. At the moment, they're always set to zero. If would be quite easy to
respecify that one of these zeroes should take on the role of stating whether
or not the terminal is capable of encryption, compression, etc. (and of what
type). If that were done, a traditional host/terminal dialog would operate in
this manner:
o The HP3000, either from the MPE FOS, just before an account/group/user
password was to be entered, or from an application, would request terminal
capabilities (an "Esc*s<x>^" is the form of the sequence that initiates a
capabilities request).
o If the terminal emulator responded in the affirmative that encryption
and compression capabilities are present in the emulator, the HP3000 would
then ask for a similar (but newly defined) capabilites request that would
outline the form of encryption and compression algorithms supported by the
emulator.
o The HP3000 would then select the most appropriate form of encryption,
based on what capabilities are available to it and command the terminal
emulator to now transmit all further transmissions under encryption.
o Once a password, or a dialog, has been completed, the HP3000 would then
command the terminal emulator to return to plain text transmissions.
o If, on the other hand, the terminal (including a real terminal) had no
capability to encrypt or compress data transmissions, the HP3000 would
recognize that fact from the returned capability bytes -- and all
communications would occur as they do now, and we'd be no worse off than we
are.
Putting this form of negotiation into the standard terminal dialog is the
right place to do this. Further, it allows encryption & compression
capabilities to be completely independent of the form of the communication
medium (wire, dialup, ns/vt, or telnet). It would work as well in any one of
these as any of the others.
While putting encryption into a terminal communications is something that has
to be done cooperatively, both with the terminal emulator manufacturers and HP
simultaneously, it's something that we would certainly be pleased to do. For
all the reasons that Ken Sletten mentioned, it's going to become an
increasingly pressing issue.
Wirt Atmar
|
