>Subject: Re: 3k attack risks, Encryption, Linemode Telnet
>Date: 9 Mar 1995 08:16:51 GMT
>Organization: Hewlett Packard
 
>Eric Schubert ([log in to unmask]) wrote:
>:   Well, the next question is...how can VT be firewalled?  Does anyone have
>: VT firewalled anywhere?  My guess is that the firewall would require
>: purchase of an HP9000 so that a proxy can come off of this machine using the
>: VT3k software?
 
>- Wouldn't the best firewall be a router?  Sure there are routers one can
>  configure to allow certain services to pass and others to drop dead.
>  Any host that one can log-on is questionable as a firewall.  The
>  assumption is that a hacker can always logon to a system.  What if
>  there is no system?  Just a router that will not accept connections to it
>  from outside world although from inside one could telnet in and manage it.
 
Yes, this is good.  In fact, that is how our HP3000 router is configured.  The
trouble starts when your "inside" network has holes in it.  Put one machine
on the inside network without this router protection (it could be a "harmless"
network printing service), well flush security down the drain.  The hacker
simply breaks into a local machine and uses that machine to attack from the
inside.
 
>  What I'm getting at is that no matter whether there's a 9000 or whatever
>  machine as a firewall, if someone succeeds to logon to it, the security
>  is history at that point.  The machine is in your internal net as well
>  and can now open a connection to any machine.  A 'box' that one cannot
>  logon has the best chance of being a good firewall - it only does IP
>  routing of selected IP fragments.
 
It gets back to a closed network is a secure network (well, secure from the
outside attackers!)  Yes, but what if you WANT to give internet access...Your
choice is to firewall it with a machine that can be closely monitored.  A good
detection program and packet monitors are in order.  Also, if your logon into
the firewall machine uses a one time password scheme, maybe this will secure
it well enough.  I think you are assuming traditional (unchanging) host
password files.
 
>- Firewalling VT would be the same than any other service - just disable
>  connections to port #1537 (with the firewall 'box' whatever that is)
>  and you're done.  Admitted, you cannot do this with just a plain hp3000
>  today - it's all or nothing.  When/if inetd security comes to hp3000, all
>  NS services should make use of it and that ought to be really easy.
>  DSDAD controls all incoming NS servers and thus there's only one central
>  point that needs to change.
 
Eero, you're on the right track.  The first and utmost strategy to security is
to localize and centralize the access points, then cook up good detection
monitors and such.  Another thing.  People tend to argue about security
using absolute terms, and this is where the trouble begins.  There are
only DEGREES of security and responses to attacks.
 
For instance, take your statement "if the firewall machine is cracked into
then it's no good."  Well, that may be true, but if this is the only access
point into your 3k and you have alarms, bells and packet monitors and such
(the DMZ to the 3k) in the access paths, then it is a good trade off.
 
A recent advertisement for hand held authenticators quoted a study that
said:  80% to 97% of compromised systems go undetected.  I tend to believe
this.  Detection is not possible when your access system is flawed or worst
yet, there IS NO plan of detection.  You assume the logon password will do it
married to an LDEV.  Well, those days are over connecting to an unsecured
network.
 
Well, you say, I'll just use the IP Address and User name, that should do it.
right?  Wrong! packet spoofing will get around this approach.  You might keep
out the teenager, but the real cracker will tie you in knots.
 
I read the book "Firewalls and Internet Security - repelling the Wily hacker,
William Cheswick and Steven Bellovin" and currently engaged in a project to
evaluate strategies of securing our 3k machines.  Let me tell you, there are
no simple answers.  These guys work for ATT&T and designed AT&T's
firewall systems for Internet access.  They have good ideas.
 
It is important when talking about host security issues that absolute phrases
are not expressed.  Absolute statements, like "secure network" are oxymoronic
phrases.  Security can only be expressed in degrees of scale, not absolutes.
Contrary to some opinions, the authors of this book believe highly secure
networks are possible by isolating a sub-network using firewalls.
 
"HIGH DEGREE OF SECURITY" meaning that the connecting user is really who they
say they are and that services are delivered according to computer policy.
 
Now think about this core principle of security: "If the user is really who
they say they are."  Traditional passwords over an unsecured network are
pretty much useless to meet this requirement.  A better method is to move into
some sort of hand held authenticator that produces a unique password every
time.  This approach immediately removes the farse of using passwords over an
unsecured network.  Then again, you must believe your data is valuable enough
to protect to this degree.  If not, then use passwords.
 
This is just the surface.  Like I said, security is a matter of degrees -
related to how valuable your data on our machine is to the mission of the
organization.  Life on the 'net is not your DTC environment.  If you try to
apply your DTC security approaches to an unsecured network, you are going to
loose it.  A different mindset must be employed.
 
>:   VT messages.  mmmmm.  Using a sniffer you can probably figure what the VT
>: handshake is about, or maybe turn on the trace of some TCP stacks with
>: NS/open would dump it.  I was wondering if VT had "secret" responses of
>: something along encryption lines, you don't believe it is so.  It's just a
>: matter of figuring out the proper response to VT messages to roll your own
>: VT client?
>- I guess it can be done... but oh boy wouldn't it be tough!  By just watching
>  the traffic I guess one can get to the logon - and of course the trace would
>  reveal the passwords - logon as well.  However, making it a well working
>  one... hmmm.. lot's of grey hair.  VT messages contain several fields
>  that indicate different success/failure/etc statuses and those could
>  mess one up pretty bad.  Anyway, I guess the point is to logon - well,
>  a trace of almost any non-encrypted traffic allows one to do it no matter
>  what protocols are in use.
 
Well, the easy approach is to crack into a box with NS/open installed and
steal it!  or grab a copy of "hpterm" floating around 9k's.  If we flood our
campus with NS/open clients, how long will it take before someone cracks into
a unsecured host and steals a copy?
 
 
>:-) Eero Laurila - HP CSY Networking lab.
 
--------------------------------------------------------------------
Eric J. Schubert                 Administrative Information Services
Senior Data Base Analyst         University of Notre Dame, IN USA
 
Email:            [log in to unmask]
World Wide Web:   http://www.nd.edu/~eschuber