[unisog] Admin Access to Servers

Addam Schroll addam at purdue.edu
Fri Nov 17 14:47:58 GMT 2006


See comments inline.

Russell Fulton wrote:
> 
> Addam Schroll wrote:
>> The current concept goes so far as to require each admin to carry a
>> separate laptop from their normal machine in order to allow remote
>> access from home or work.  Unfortunately, the extra machine and
>> draconian policies have the admins up in arms.
>>
>>   
> I don't get the requirement for a second machine.  

I'm not sure I do either.  Which is why I wanted to find out if others
had taken this approach or not.

> All our admin have laptops that they are expected to take home and use
> for remote access as well as for work on site (most of us have big
> screens and keyboards at our desks).  We operate a VPN concentrator and
> an SSH gateway into our network. 
> 
> We are in the middle of a project to require 2FA on all servers that
> hold sensitive data.  Currently the ssh gateway requires 2fa and we have
> plans to implement a new group on the VPN that will require 2fa, users
> in this group will get addresses from a different pool to 'ordinary'
> users and only addresses from this pool will be allowed through the
> firewall into the secure network.  To connect to machines with sensitive
> data admins will have to use 2fa again to log in.  On Unix boxes we also
> require 2fa for sudo.
> 
> 2FA does a reasonable job of mitigating keylogging and other password
> stealing threats. 

I agree, and I definitely support the part of the project here that
requires 2FA for login to the admin laptop (as this is currently the
single point of entry to the sensitive systems).  If the laptops were
removed from the equation, I would still like to see 2FA enforced on
access points to critical systems.

> We have had some grumbles from admins about requiring multiple 2FA log
> ins (worst case 3 -- ssh gateway, account login, sudo) with up to a
> minute wait for the token to role over (we are using RSA).  We did
> consider 'crypto card' which had a feature that allow you to get the 
> next number without waiting, the down side is that it is easy to get the
> card out of sync by pressing the next button too many times (five ?). 
> This requires the  tokens to be physically returned to base for
> resynching.   We had visions of kids playing with keys and discovering
> that they can change the number by squeezing the token -- hello! Mum(or
> Dad;) is now locked out!  We were also worried about the less robust
> nature of the tokens with a physical switch in them.

We are using the Aladdin USB SmartToken system for our own 2FA.  I
wasn't directly involved in the choice here, so I don't know the
background for why this particular solution was chosen.  But it also
presents a number of challenges, as any 2FA solution tends to be
somewhat complex to rollout to a number of access systems and users.

Thanks for the input, I appreciate it.

> Cheers, Russell.
> _______________________________________________
> unisog mailing list
> unisog at lists.dshield.org
> https://lists.sans.org/mailman/listinfo/unisog

-- 
Addam Schroll
IT Security and Privacy Analyst
Office of the Vice President for Information Technology Security and
Privacy, Purdue University addam at purdue.edu
PGP/GPG: B3FD 239B 573E D7F8 076B 9FDC 347D 4D4E 355F E9D0


More information about the unisog mailing list