Re: Modems on Servers

[William . Stackpole]

I've been following this thread for awhile but haven't had the time to add my 2 cents.  I've dealt with this problem at a couple of different jobs and agree that there are no really good solutions to the problem.  Here's what I've done in the past.

One site was a military installation where the vendor dialed into a mainframe system to do software updates and configurations.  Because there was a high level of security required, the modem was disconnected from the phone line.  The vendor called when they wanted to dial-in, the line was connected and a monitor program run on the console so the operators would know when the vendor disconnected so we could come in a disconnect the phone line from the modem.

At another site we brought the vendor through a router with dial-in capabilities.  The vendor's access was controlled by a RADIUS server that limited their access by day and time-of-day. (When your vendor only uses a couple of lines for modem calls, calling number controls can be pretty effective too but this turned out to be too much hassle on the RADIUS implementation we had)  RADIUS assigned the vendor a specific IP address that was filtered by the router so they could only Telnet to the host they were servicing.  We also had additional controls on the host to prevent them from doing things like Telnetting to other hosts.  This arrangement had two advantages.  First is was automated and second the RADIUS server kept log-on and log-off records we could reconcile with the vendor's invoices.

I've also been involved with the use of commercial call-back units.  The one I worked with used a SecureID ACE server to validate the user.  Once validated the user was presented with a menu of options including the machine/network they wanted to access and (if they were authorized) the number to call them back on.  This allowed a user to have multiple callback numbers but it still didn't allow them to dial-in from a hotel room.

My general sense is that vendors tend to be more sophisticated users and can tolerate additional requirements like going through an access server or using a token like SecureID.  The real dial-in challenge seem to be with ordinary users that expect dial-in to work just like their desk connection and have little patience for things like PINs, tokens and callback.

My preference for authentication is UserID and password in combination with a smart card.  You plug your smart card into the system, log-in with your UserID and password and let the smart card verify your identity.  If users have to do this on every system they use, it will become normal for them.  That's not to say that the solution does not have it own problems, including some substantial management overhead but it is relatively simple from a user perspective.

Anyway, for what it's worth, that's my two cent.

Bill Stackpole, CISSP