As Your Admin Walks Out the Door ..

Published: 2017-06-19
Last Updated: 2017-06-20 00:40:41 UTC
by Rob VandenBrink (Version: 2)
4 comment(s)

One of our readers (thanks Gebhard) mailed us a link to an article on what the press is apparently now calling a "Revenge Wipe" - a system administrator who has left the organization, and as a "last hurrah", deletes or locks out various system or infrastructure components.

In this case, the organization was a hosting company in the Netherlands (Verelox).  In the case of cloud providers, a disgruntled admin may have access to delete entire networks, hosts, and associated infrastructure.  In the case where it's a smaller CSP, the administrator may also have access to delete customer servers and infrastructure as well.  In Verelox's situation, that seems to have been the case (from their press release at least)

The classic example of this is the City of San Francisco in 2008), where their main administrator (Terry Childs) refused to give up the credentials to their "FiberWAN" Network Infrastructure, even after being detained by law enforcement (he eventually did give the credentials directly to the Mayor).  I've listed several other examples in the references below - note that this was not a new thing even in 2008 - this has been a serious consideration for as long as we've had computers.

So, how should an organization protect themselves from a situation like this?

Back up Job Responsibilities:

Know who has access to what.  Have multiple people with access to each system.  Having any system  with only a single administrator can turn into a real problem in the future.  DOCUMENT things.  BACKUP your configurations in addition to your data.

Use Authorization:

It can be difficult, but wherever possible use Admin accounts with only the rights required.  It’s very easy to build an “every Admin has all  rights” infrastructure.  It’s likely more difficult to build a “why does the VMware admin need the rights to delete an entire LUN on the San” config – but it’s important to think along those lines wherever you can.

Use a back-end directory for authentication to network infrastructure:

What this often means is that folks implement NPS (RADIUS) services in Active Directory.  This allows you to audit access and changes during regular production, and also allows you to deactivate network administrator accounts in one place

Where you can, use Two Factor Authentication

Use 2FA whereever possible, this makes password attacks much less of a threat.  2FA is a definite "easy implement" for VPN and other remote access, also for administration of almost all Cloud Services for your organization.

Just as a side note - I am still seeing that many smaller CSPs have not gone forward with 2FA - if you are looking at any new Cloud services, adding Two Factor Authentication as a "must-have" is a good way to go.

Deal with "Stale" Accounts:

Keep track of accounts that are not in use.  I posted a powershell script for this (targeting AD) in a previous story ==>

Deal with "Service Accounts":

Service accounts are used in Windows and other operating system to run things like Windows Services, or to allow scripts to login to various systems as they run.  The common situation is that these service accounts have Domain Administrator or local Root access (depending on the OS).

Know in your heart that the person you are protecting the organization from is the same person who likely created one or all of these accounts. 

Be sure that these service accounts are documented as they are created, so that if a mass change is required it can be done quickly.

Know that these use a central directory (such as AD or LDAP), so that if you need to change them or disable them, there is one place to go.

I posted a PowerShell script in a previous story to inventory service accounts in AD ==>

Restrict Remote Access:

Be sure that your administrative accounts don't have remote access (VPN, RDP Gateway, Citrix CAG etc).  This falls into the same category as "don't allow Administrators to check mail or browse the internet while logged in as a Domain Admin or root privileges.

On the day:

On the day of termination, be sure that all user accounts available to our administrator are deactivated during the HR interview.  If you've used a central authentication store this should be easy (or at least easier)

Also force a global password change for all users (your departing admin has probably done password resets for many of your users), and if you have any stale accounts simply deactivate those.

For Service accounts, update the passwords for all of these.  This is a good time to be sure that you aren't following a pattern for these passwrods - use long random strings for these (L33t speak versions of your company or product name are not good choices here).

I'm sure that I've missed some important things - please, use our comment for to fill out the picture.  This is a difficult topic, since many of us are admins for one thing or another this really hits close to home.  But for the same reason, it's important that we deal with it correctly, or as correctly as the situation allows.



Rob VandenBrink

4 comment(s)
ISC Stormcast For Monday, June 19th 2017


Diary Archives