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