[4388] in cryptography@c2.net mail archive
Re: references to password sniffer incident
daemon@ATHENA.MIT.EDU (Jurgen Botz)
Thu Mar 25 13:53:32 1999
To: cryptography@c2.net
In-Reply-To: Your message of "23 Mar 1999 18:39:49 EST."
<sjmyakng4hm.fsf@datkins.ihtfp.org>
Date: Thu, 25 Mar 1999 08:35:35 -0800
From: Jurgen Botz <jurgen@botz.org>
I'm going to go off on a bit of a tangent here... this is really
a security issue, not a crypto issue, but I think it's something
that we'd all do well to think about.
Derek Atkins wrote:
> sniffible, none of my passwords were. I happen to be one of the
> lucky few who has made it through the politics of large companies to
> "open up the firewall". Yes, corporate IT people see something even
> as secure as SSH as 'opening the firewall'.
I'm one of those corporate IT people and I let Ssh in through our
firewall, but I'm not very happy about it. With Ssh, other secure
tunneling protocols, or IPSec tunneling I'm providing a secure
communications channel for some machine on the outside to access a
wide range of network services inside our network. The problem is
that I know nothing about this outside machine... this may be a
Windows machine with a fixed IP# (say on a cable modem) which is wide
open, running a half-dozen totally unsecured services, and infected
with Back-Orifice to boot. An attacker can now easily get into this
machine and install a little IP forwarder on it and he has a perfect
little gateway into my network!
Yes, I could demand that all my remote users be running NT4.0SP4 with
some additional security patches and have all their services turned
off (or better still, Linux or *BSD configured by my network
engineers), but how am I going to enforce this? Simply put it's
administratively impossible... the machines of the remote users are
beyond my control and must be assumed to be completely insecure.
The approach I'm hoping to take (for lack of a better alternative) is
to give people IPSec access but to try to ensure that at any time that
they are tunneling into our network their machine is not reachable by
any means /except/ through the tunnel. Establishing the tunnel will
require authentication with a hardware token (this is what we're
currently doing for Ssh, too... I've learned the hard way that I can't
trust people to use strong passphrases even after practically pleading
with them to do so). The result will be that at least their machine
can't become an outright gateway into our network, although it might
still be used as a springboard by an attacker aware of the mechanisms.
Compromises, compromises.
Anyway, my point is that as we all make progress in developing secure
means of communication, of course we want to use these means to make
life more convenient... we have IPsec, so of course we want direct
remote access to our network filesystems, etc., not just a terminal
session! But we just because the communications channel is secured
does not mean the end-points are, so we are opening ourselves up to
many new avenues of attack.
Phil Karn wrote:
> The real problem with SSH, IPSEC, encrypted Telnet and the like is
> that they're much too *decentralized* for their taste.
Yes, that's exactly right...
> And that directly threatens their power base.
Some IS managers may be concerned with maintaining their power base,
but many of us /love/ decentralization as a means of pushing
responsibility back out to the users and thereby making our own lives
easier. Believe me, there's nothing I like better than telling a user
"DIY" because we've taken the steps to decentralize that particular
task and empowered them to do so. The problem in this case is that
the decentralization pushes the responsiblity for maintaining
/security/ back out to the user (the owner of the endpoint) and the
reality is that the users just can't be trusted with this. I mean if
my users were the members of this list it might be a different
story... (maybe!)... but they are people who are far too busy to worry
about such details as whether or not they left an unsecured Frontpage
server running on their laptop or whether it might be dangerous to
accept that active-X control their browser just offered to automatically
download.
Once again; cryptography is helping us secure the communications
channels and the authentication mechanisms at the end-points, and so
we rely on them more heavily, lulled by a possibly false sense of
security. We must not lose sight of the fact that as we use these
mechanisms to decentralize more we are potentially expanding the
chains around our networks to include many very weak links in the form
of end-points whose security depends on humans who are sure that it
isn't their job to worry about security.
- J=FCrgen
