[clug] Detecting malicious former employees

steve jenkin sjenkin at canb.auug.org.au
Tue Sep 12 02:21:00 GMT 2006


John Fletcher wrote on 11/9/06 3:22 PM:
> Hi guys,
>  
> I'm looking for some advice about precautions to take when a potentially
> malicious and highly priviliged (previously had root pw) employee leaves an
> organisation.  Can anyone give me some advice about precautions to take and
> especially where to look to detect possible attempts to gain access or
> engage in malicious activity?
>  
> In this particular case we're talking about linux firewall, PPTPD,
> mailservers, and various other bits and pieces.  Most work done from remote
> locations, not onsite.
>  
> Thanks,
> Fletch.

Fletch,
  There are some constraints on the problem you haven't specified...
As Mikal et al pointed out, this is only a "what if" isn't it :-)

- Does the organisation supply services/operational support to third
parties?

- How big is the organisation? In {employees, locations, servers, desktops}

- How much non-Unix are we talking??

- How dependant is the organisation on it's I.T.??
  - Is it in the I.T. or software business?
  - Is it like a law firm that *must* have records on-line?

- How paranoid or "aggressive" is the management stance?
  - Do they have an "escort directly from the building" policy?
  - Will they/have they pursued anyone through legal channels?
    [Like Randall Schwartz and Intel]

- What paperwork/agreements do people sign when they join?
  - Is it *clear* what they should/should not do?


============================================================

Attempting a solution:
 - This is *not* possible after the event, you need to plan for it.
   [Been there...]

 - If "management" don't have a written policy on what they do and do
not want in the situation, they need to create one.
   Don't second guess them.  This is a management issue, not I.T.

Specific steps:
 - Never, ever allow root or privileged logins... 'sudo' is your friend.
   - root passwords in the boss's "safe" in sealed, signed envelope.
   - a near perfect solution is "single sign-on" with secure-id
key-fobs. The key-fob can be disabled immediately in one place.

 - If you have more than one server, you need a system that distributes
and sync's *all* the admin/privileged accounts.

 - I've heard of a tool for managing a large field of routers for a 3rd
party:
   - admins use ssh to access the portal (proves who they are)
   - run the access command - a perl script
     - *never* any direct access to routers
     - all commands parsed by script, then executed on router by script.
       - all commands logged, timed and 'owned'.
   - they were able to answer definitively, "what was changed"?
     - and by whom, when...

 - With your central admin tool (you've got one, right?), move the home
   directory of the departee immediately to another (inaccessible)
   place.

 - Never, ever reuse UID's or usernames...
   - watch those group permissions as well.  'sudo' is your friend.

 - Of course, you *do* regular audits of all your systems, scripts,
   processes, procedures, policies, ....

============================================================

The tools mentioned that find all logins/running processes owned by a
user are a good idea. Unix has a weakness in this area.

If I was planning to leave (or suspected I was about to get fired), I
would take copies of everything I needed/wanted well beforehand. And leave

If I planned to 'attack after end day', I'd sniff or crack whatever
passwords I could - especially of other admins, managers or users.
I'd leave some innocent sounding 'setuid' programs around.
 [nothing so crass as directly to root, but something like 'oracle'
 [that can become root for certain activities
I may make a bogus user & give them a path to gain privilege.
I'd have a few different ways in via some webserver ports/pages, or some
innocent entry in /etc/inetd.conf
I might modify a privileged cronjob to ssh *out*, or for a short time
allow incoming 'ssh'. Hard to trace 'sshd' restarting...

And there would have to be another bunch of things really devious minds
could come up with.  After all, we are talking a *motivated*, possibly
competent, attacker with a perfect knowledge of your systems, processes
and procedures...  This is a worst case scenario...

Of course, you *do* vet and background check your admins (like Govt.
security clearances) if you are very concerned...

And you *do* have good version control, change management and (host)
Intrusion Detection Systems. And automatic systems to alert/alarm.

And you *do* have good backups and some spare servers that you can
fail-over to... Even a remote site??

There are a few very good SysAdmin books that *should* cover the
policies and procedures necessary.
- Evi Nemeth and co...
- The O'Reilley book on (Unix) System Admin
- Tom Limoncelli's book

HTH
sj

-- 
Steve Jenkin, Info Tech, Systems and Design Specialist.
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA

sjenkin at canb.auug.org.au http://www.canb.auug.org.au/~sjenkin


More information about the linux mailing list