At 01:50 PM 4/15/96 +0500, Alan AMBERS wrote:
>Sometime last week, Eric said about inbound NQtelnet....
>
>I changed and "resolved" the problem that cause the delay today.  Most
>all of our users come to us from the Maryland Sailor system, so their
>address was in the host table since this connection does not have DNS.
>
 
Hey, I tried it out.  Super fast!  Less than a second.  Was this just for my
IP address or will a guy in Utah get the same response?
 
 
>
>My concern about MPE/iX 5.5 inbound telnet is the fact that users will
>get a "colon" prompt once they get through.  Is there some feature in
>5.5 that will "minimize" the security risk.  If not, I would just prefer
>to keep using NQtelnet for this application.
>
 
Yah, I was thinking about the security problem.  You could have people
banging away trying _any_ logon with your current arrangement.
 
SECURE THE DATA (you have mobility) OR SECURE THE NETWORK (nailed locations):
 
Sensitive data is another bag that can be solved (briefly) using secure Web
(anywhere) or secure HUB's or switched ethernet installed at the client's
location - in combination with security software on the host (nailing those
users to those locations) and a physically secure local network (locked
closets to routers, HUB's, fiber backbone.)
 
But nailing users to locations reminds me of "cave man" security.  I would
prefer mobility.  But mobility requires data encryption devices and probably
crypto-card technology for ultra protection (begin plug.  check out
SAFE/3000 - the first crypto card available for HP 3000.  We tested the
first one last week!  end of plug.)
 
Secure Telnet is not available but Open Market WEB secure sockets layer is
available, a form of data encryption.  But the Web doesn't help a terminal
based application.  Without secure Telnet, mobility is questionable for
sensitive data access.  It depends on your risk tolerance.
 
 But Libraries don't suffer from the "sensitive data stream" problem because
all your delivered data is public.  That just leaves IP Network services and
host security issues.
 
SERVICES ON NETWORK (brief overview):
 
Ok, I'm assuming you know about NS/3000 RPM, RFA and other "dangling" server
stuff (ISQL, ODBC) machine to machine services on the 3000.  People usually
remember the "big" ones, like FTP.  If you drop your 3000 on the 'net, you
must worry about all open port services that once were pretty much private
on small LAN configurations.  We had to put filters on our CISCO router to
allow only specific ports reachable to the "outside".  External 3000 DNS was
a tricky one, using UDP ports in the 60,000+ ranges - not the Unix convention.
 
You may want to filter reachable "PING" also, this little protocol could
result in a "service denial" attack if a client "pinged" your machine to
death.  Ping does allow easy means to find your machine, it may be more
useful alive than filtered.
 
Next, don't forget to look at your SNMP MIB's.  What the heck is a MIB?
These are nice little hooks within your system for the network manager to
see what's happening via Simple Network Management Protocol. SNMP uses
"community access variables" within a MIB to monitor activity.  You need to
check what MIB's are configured for your HP SNMP access and make sure there
are no read/write variables allowed (unless you want them that way) and what
kinds of information are public.
 
HOST LOGON:
 
One MPE host solution for this situation is to create a system wide UDC and
bounce any logon from outside a particular IP address (MPE 5.5 will come
with the needed MPE script enhancements. (See 5.5 communicator or
 
 http://jazz.external.hp.com/papers/Communicator/5.5/ci_enhancements.html )
 
But the most known and trusted user of them all "MANAGER.SYS" could be
logged on to bypass UDC's with parm=-1, I believe.  Then you have to buy
security software just for the purpose of disarming MPE UDC bypass!?
 
Sidebar:  Can MPE disable the PARM=-1 bypass UDC logon with a system
configuration change?   If not, it should!  If it does, you can use a system
logon UDC.
 
You could also do something at the firewall (like hard code a specific logon
proxy to HP Telnet on an open client connection) and not give an MPE prompt
or make users "logon".  We did something similar here but it involves Unix
'c' programming and changing telnetd() daemon code on the firewall machine.
If you truly have a firewall machine state-wide already, it should allow a
"proxy" on behave of another machine - but it may not do an immediate logon
on the client's behalf.  Talk with the person down or up stream from your
network library connection.
 
Or do both:  A system logon UDC network bouncer (make an exception for the
desired public logon, of course!) and Firewall Proxy.  That would be the
best combo.
 
But without an "auto-logon" firewall proxy of some kind, you are stuck with
a user doing "MPE iX: HELLO JOE.PUBLIC".
 
OH, almost forgot.  Better have your vendor change your application program
terminal escapes to ANSI terminal values or VT100 values depending on
inbound HP Telnet connecting term type.  NQTelnet is automatically
translating HPterm for you!
 
----------------------------------------------------------------
Eric J. Schubert                    Senior Data Base Analyst
Office of Information Technologies  Univ of Notre Dame, IN USA
(219) 631-7306                      http://www.nd.edu/~eschuber