On Sat, 24 Jun 1995 09:10:08 PDT Alan Ambers <[log in to unmask]> said:
>We currently have no connection to the Internet, but we soon will be
>connecting via a new firewall (HP9000) using Raptor software.  There are
>many connectivity issues, but one of the hottest ones is connecting so
>users from the outside can get to our library system (HP3000/960).  We
>currently are using the VTLS software.
 
Welcome to the club :-)
 
>I know we have to by a TAC card to support inbound telnet.  We don't have
>MPE/iX 5.0 yet, but even if we did, I believe that the first pass will
>support outbound telnet only.  Is inbound telnet w/o a TAC close?
 
I don't know the MR dates of the host telnet server, nor do I know the exact
implementation (which is a crucial question to your next comments...)
 
>My concern is to avoid to have users coming in having to issue a HELLO
>command.  I feel that it is a big security risk.
 
Your concern is not only valid, but shared by many (not just VTLS users).
 
>I used a gopher/veronica search for VTLS sites and then connected to a few.
>The HP3000 sites did prompt me to issue a HELLO command.  Unfortunately, I
>connected to a site in Sweeden that the ususal "/QUIT" command didn't work...
 
Ours does the latter.  Many years ago (1979!), before STARTSESS, redirection
of $stdin/$stdlist, IPC, and other goods, I created a secure application menu
type system called TERMNET (HPIUG Proceedings, Orlando 1981 I believe) which
grabbed a set of :REFUSEd terminals and would attach a "logon", then "menu",
then "application" to those ports, all direct descendants of the main father
process.  This saved the overhead of a CI and menu process (important in the
Series II/III days) and since the terminals were :REFUSEd, they couldn't get
a colon prompt if they wanted to.  But now I digress...
 
When we later installed VTLS, I kludged the TERMNET package to use the VTLS
application program (Libbie) as it's "logon" procedure.  It would then run the
program on the terminal, and if it ever terminated, the father process could
detect it's absence and would restart the logon process.  It has worked for
over 10 years and still runs fine on our 950 on MPE/iX 5.0.  But getting back
to network abilities...
 
>I thought I read somewhere that the the TAC can be set up so an inbound telnet
>can go to a specific (nailed) ldev.  If this is true, can I set up the HP for
>programatic sessions?  Or if that is not possible, can I set up for the
>multiple telnet sessions to go to a set of ldev specific ports? I then can use
>our security package to only ever allow one logon, so they could not get past
>it even if they new other passwords.
 
First off, you definately want to firewall the IP address of the DTC with the
TAC; if you telnet to it you will get the DTC user interface and can connect
to whatever you like.  Secondly, you can define a secondary IP address in the
TAC configuration that points to your library system and allow this IP through
the firewall.  But no, to my knowledge there is no way to assign a telnet
session to a nailed port; they are by definition non-nailed.  I wish there was
a provision to do so (being able to provide login information at the TAC would
help, but not solve the problem).
 
If you don't need universal telnet access to the library, or in other words
you want any telnet session to be restricted to only a VTLS logon, you can
assign a system-wide option logon UDC to check the value of HPDTCPORTID.
If the value matches the MAC address and slot number of the telnet card, you
know it's a telnet session.  The user will still have to do a :HELLO though.
You will NOT know the originating IP address of the connection, but you can
at least tell if it is a TAC-based telnet session.
 
The other option is to setup back-to-back DTCs (or reverse terminal server
to DTC) so they can telnet to a specific port which in turn goes into a port
of the DTC that you CAN nail to a specific LDEV.  Note that you can nail a
real port to an LDEV and you can assign an IP address to a real port, but
the latter is "outbound" only.  You could do this on a single DTC but it
will take up two ports for each connection.  We are doing this using a Gandalf
EtherGate terminal server module in an old PACX 2000 data switch going out to
a reserved block of ports on the library's DTC (controlled by TERMNET).  But
for future consideration...
 
If the 3000's host-based telnet is as robust as the 9000's (inetd based)
when delivered, you might be able to assign a specific port for VTLS users.
You could then just change /etc/inetd.conf to run VTLS for that port in
place of the login program.  But I don't know if the underlying code will
be adequate to do this (redirecting stdin/stdlist to a raw socket), but you
might get away with it using a wrapper or some code changes.  I've been able
to invoke MPE programs and get output back out using httpd and cgi-bin
scripts with "callci", but of course this isn't an "interactive" dialogue.
 
[\] Jeff Kell, [log in to unmask]