Re: logging onto an ioc (rlogin,telnet)

[Alan Biocca <AKBiocca@LBL.gov>]

SNMP to serial adapters, Security Policy Issues, and Watchdog Timers:

I haven't had a chance to try it yet, but one suggestion I am considering 
is to use SNMP. Inexpensive ethernet SNMP to serial adapters are available 
at www.lantronix.com, and any SNMP management software could be used to 
connect to the crate. There are inexpensive and even free SNMP programs for 
most platforms. There are also handshake lines that potentially could be 
used to drive a reboot signal with a small hardware interface.

This is similar to the other terminal servers mentioned, however they have 
the option to use SNMP (they can also do telnet, etc). They may be lower 
cost than other terminal servers.

We intend to evaluate them but have not procured one yet. I was told they 
are quite inexpensive but this is third hand info. A quick review of the 
website doesn't seem to mention prices.

Security Policy Issues..?

More specifically, what does 'disable telnet and rlogin' mean? Not running 
the servers on regular hosts will not affect login to crates - to login to 
the crate you need only the client software which itself is no security 
risk. If the crate has no routes outside your secure machines (especially 
no default route) then rlogin or telnet attacks from outside will not be 
able to connect to crates due to no return route.

So a security policy could be:

1) no vxworks default routes
2) no vxworks routes outside secure controls machines
3) no telnet or rlogin daemons on hosts other than vxworks
4) leave telnet/rlogin client software on hosts (this will be required in 
any case to connect to remote machines that still use it, the whole 
external world is not converting to ssh).

Watchdog Timers exist on most CPU boards. We have set them up to autoreboot 
the crate if it fails to respond for a number of seconds. The watchdog 
timer is a hardware timeout-to-reset counter that must be attended 
periodically by software to prevent the hardware autoreboot. The timers 
longest timeout is generally a bit short so we used a periodic interrupt to 
create a lengthened version. Critical periodic code is augmented to reload 
the software watchdog. More than one of these can be implemented if there 
are several critical tasks to be monitored. The interrupt driven extender 
decrements and checks all critical task counters. If all of them are 
positive it then clears the hardware watchdog. Freezeup of any component of 
this causes an automatic hardware reset reboot a few seconds later.

Our experience in running this for a few years was excellent - occasionally 
the network code would hang the system and it always repaired itself. I 
can't remember any occasions where we had to reboot the crate manually 
except to force new software versions to load. This was a cryosystem that 
had to run continuously for months and the software was designed to handle 
rebooting without ill effects on the system. This was a few versions of 
vxworks ago so I don't know that the code we did is of much use, and the 
watchdog hardware is cpu specific, so it requires a per-cpu-type library. 
(BEVALAC HISS CryoSystem).

-- Alan K Biocca
Advanced Light Source Controls


At 09:31 AM 8/20/99 -0700, luchini@SLAC.Stanford.EDU wrote:
> Hi,
>
> SLAC is tightening up security on its networks
> and so plans are in the works to disable
> rlogin and telnet. SSH...