Sorry it took so long for me to get back to these, but it has been one
heck of a busy week....
Early this week, Eric Schubert said....
> 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?
Everyone in Utah will work fine, I don't know about _everyone_ in
Montana. (No disrespect for most Montana residents implied)
> >
> >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.
> >
> 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
)
>
I looked at this page and think that this concept would work. Since all
inbound traffic from the internet has one address (via our security
stuff), The system wide logon could be set up to disallow any logon
except the valid Library access. And on our other systems, the logon
UDC can be set up to disallow *ANY* logon from this address since we
would not want to allow anyone from the outside to any of our other
systems.
> 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.
In 5.0 it is either disabled or configurable. I'm not sure which, but
it can be turned off. Logon UDCs would work.
> 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.
When we first hooked up our securty stuff (ok a firewall), we looked in
to inbound telnet converting to NSVT. We had major problems making this
work. This is when I found out about nqTelnet and we went that
direction.
As far as going up stream, the sailor people probably cannot help us
much since it's they are just telneting to us from a gopher server and
don't seem to do alot of extra stuff for the outbound users/supporters.
> 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".
I agree! I'm so *NOT* thrilled about this (say that phrase like
Chandler from "Friends") that until I need inbound telnet to this HP, I
think we will continue to use nqTlnet.
> 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!
Not a problem, the library application is entirely prompt and response.
> ----------------------------------------------------------------
> 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
>
/alan
Alan "Now on to the next security message" Ambers
[log in to unmask]
|
