Best way to secure management dial in

Hi Fredrik,

~ I'm planning to implement dial in using a modem connected to the ~ console port of our core routers. My concern however is how this can ~ be made secure. ~ Any ideas? ~ ~ Regards ~ Fredrik

This is a legitimate concern. Since console ports do not have modem control, they will not detect a hangup from the modem. Consequently, one user could dial in to the console, authenticate, then hang up, and a subsequent caller could access the router prompt without having to authenticate. You could reduce the window of vulnerability by shrinking exec-timeout to your maximum pain tolerance point, but this would still be a vulnerability.

Moreover, if your ROMMON is configured to permit halt upon break, a caller could dial in and get to ROMMON without ever having to authenticate. (As the line may detect a break signal due to a simple glitch on the line, it would be prudent to run in production with halt on break disabled.)

The only really secure methods of permitting dialin access to your router would be to front end it with something that does authentication independently.

One option would be to have a dialin modem or set of modems connected to router line(s) that have modem control and that are configured to do proper authentication. Once you dial into these modems and authenticate to the router, you could then reverse telnet out other router line(s) to the console ports of interest.

Another option would be to use answer modems that have builtin security. The USR Courier, for example, can be configured to require a DTMF or ASCII password. This is what I would recommend if you must directly connect an answer modem to a console port.

Regards,

Aaron

Why not a terminal server attached to the console ports, IP connecteded to a small OpenVMS box, like a DS10L connected to it using SSH. Nobody will ever hack you. telnet can be sniffed.

~ > ~ I'm planning to implement dial in using a modem connected to the ~ > ~ console port of our core routers. My concern however is how this can ~ > ~ be made secure. ~ > ~ Any ideas? ~ > ~ ~ > ~ Regards ~ > ~ Fredrik ~ >

~ > This is a legitimate concern. Since console ports do not have modem ~ > control, they will not detect a hangup from the modem. Consequently, ~ > one user could dial in to the console, authenticate, then hang up, ~ > and a subsequent caller could access the router prompt without having ~ > to authenticate. You could reduce the window of vulnerability by ~ > shrinking exec-timeout to your maximum pain tolerance point, but this ~ > would still be a vulnerability. ~ >

~ > Moreover, if your ROMMON is configured to permit halt upon break, a ~ > caller could dial in and get to ROMMON without ever having to ~ > authenticate. ~ > (As the line may detect a break signal due to a simple glitch on the ~ > line, ~ > it would be prudent to run in production with halt on break disabled.) ~ >

~ > The only really secure methods of permitting dialin access to your router ~ > would be to front end it with something that does authentication ~ > independently. ~ >

~ > One option would be to have a dialin modem or set of modems connected to ~ > router line(s) that have modem control and that are configured to ~ > do proper authentication. Once you dial into these modems and ~ > authenticate ~ > to the router, you could then reverse telnet out other router line(s) to ~ > the console ports of interest. ~ >

~ > Another option would be to use answer modems that have builtin security. ~ > The USR Courier, for example, can be configured to require a DTMF or ~ > ASCII password. This is what I would recommend if you must directly ~ > connect an answer modem to a console port. ~ >

~ > Regards, ~ >

~ > Aaron ~ ~ Why not a terminal server attached to the console ports, IP connecteded to ~ a small ~ OpenVMS box, like a DS10L connected to it using SSH. Nobody will ever ~ hack you.

Sure - good to hear that VMS still has its partisans.

~ telnet can be sniffed.

True but irrelevant unless you permit sniffer access to your data path. It would be hard to offer such access in the case where the telnet data path is internal to a router.

If this is an issue for you, you could use "reverse ssh" instead of "reverse telnet" to provide the console line access via your routers.

Cheers,

Aaron (denizen of comp.os.vms, 198? - 199?)