In message <9405241504 .
AA11084 @
sword .
eng .
pyramid .
com>, Paul Daw writes:
> We are currently using a firewall configuration that consists of the
> TCP wrapper and SOCKS, and we have done all of the right things with
> regard to packet forwarding, disabling of unnecessary services, etc.
>
> On occasion, engineers and customer support folk from our site go out
> into the big bad world, and want to get back into the network via the
> Internet connection. There are some obvious advantages to this - cost,
> convenience and speed being the most significant. This activity is
> usually done from a customer site that is connected to the Internet.
>
> Brent's suggestion was to go ahead and allow this (i.e. enable the specific
> IP address from the internet to get through the wrapper to telnetd,) using
> a one time password, smart card or challenge response system to protect the
> family jewels. This seems like a good first step, but after sitting around
> drinking beer and eating pizza with the other security paranoids in the
> sysadm group here, we saw a second potential problem.
>
> Since these people are at customer sites, there is a real potential for
> local eavesdropping. While the one-time-password scheme protects the
> firewall from intrusion, it doesn't protect all of the internal
> machines that the user might log into once he is on the gateway, and
> those passwords will still be sent in the clear. The Internet gateway
> isn't the only way in, and there is a possibility that the passwords
> used on internal machines might also be used on modem servers and the
> like.
I never (well almost never) set up a real telnet capability onto the
firewall. Set up the tcp wrapper with a twist option that opens a
telnet connection to the authentication machine on the inner net (you
can probably use the TIS plug-gw (I think that is the tool) for
this). Then the single use password authentication is done on an
internal machine. Once that is done, use rlogin (you do allow
rsh/rlogin for all internal machines right?) to get from machine to
machine. Also, what I have also done is the following:
Internet -> gateway -> internal machine @ port 2300
I use the tcp wrapper on internal machines so that any telnet/rlogin
connections from the gateway cause the internet connection to be
severed. The connection at port X (2300 in this example) is the only
safe conduit for telnet from the outside to the inside anything else
triggers the network shutdown. This trick won't get crackers that
really know what they are doing since they will sit on the firewall
and wait for somebody to open a real connection and watch the ports
etc that are used to create a safe conduit (or they will just look
around the configuration files and dope it out for themselves), but it
will trip up less sophisticated crackers. While counting on obscurity
to provide security is a bad idea, there is nothing to say that a
little obscurity won't make your chances a bit better.
Also for the new skey from crimelab.com I have a set of patches for
the replacement login program that will drop into skey request mode if
the password is "secret". This way I can always get an skey
authentication even if I am coming from a host that normally wouldn't
require an skey authentication. This assumes that the engineers that
you have coming in across the internet will volutarily choose to use
skey instead of regular passwords.
(As an aside, you should probably consider requiring single use
passwords when logging into any machine from an "external" connection,
terminal servers, with modems, modems directly on a computer
etc. Harden the perimeter so that all sessions on your computers start
with a single use password authentication. People can hop from
computer to computer uinside your perimeter using rsh/rlogin or telnet
with regular passwords if they want (modulo evesdropping problems) but
to get a foothold on one of your computers they must provide the
proper single use key.)
> It seems like the only safe way to do this is to actually give the
> remote user an encrypted telnet capability so that even the clear
> passwords aren't sniffable at the remote site. Given this, I have
> two questions:
>
> 1) Am I *too* paranoid about all of this? Are we going too far?
No. Passwords that are used internally should never go over the
net. Have the single use password authentication connect through the
firewall host so the authentication occurs on a "trusted" (rsh/rlogin)
machine on the internal net. You can also require double
authetication, once on the firewall and once on the internal machine,
although this get tedious to use if you make lots of short
connections.
> 2) If not, what are the restrictions for running encrypted telnet
> in other countries? Should we be concerned about this?
I don't think this is an option. As a sysadmin I wouldn't let you
install some random binary on any system I administered. Also who is
to say that the box for which you have the encrypted-telnet binary is
allowed to connect to the outside world?
-- John
John Rouillard
Senior Systems Consultant (SERL Project) University of Massachusetts at Boston
rouilj @
cs .
umb .
edu (preferred) Boston, MA, (617) 287-6480
==============================================================================
My employers don't acknowledge my existence much less my opinions.
References:
|
|
