[clug] Detecting malicious former employees

Kim Holburn kim.holburn at nicta.com.au
Tue Sep 12 04:44:00 GMT 2006

An excellent response.

Can I just add/emphasise that the basis of all security must be a  
security policy.

On 2006 Sep 12, at 12:21 PM, steve jenkin wrote:

> 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.

large and non-memorable root passwords.

>    - 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.

Or a centralised authorisation and authentication system.

>  - 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 routers, firewalls, switches etc should have a very, very  
restricted set of machines that are allowed to access them or a  
separate non-routing network.

>      - 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, ....

and audit all externally published IPs and ports.

> ============================================================
> 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
> 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
> -- 
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux

Kim Holburn
Security Manager, National ICT Australia Ltd.
Ph: +61 2 61258620 M: +61 417820641  F: +61 2 6230 6121
mailto:kim.holburn at nicta.com.au  aim://kimholburn
skype://kholburn - PGP Public Key on request
Cacert Root Cert: http://www.cacert.org/cacert.crt
Aust. Spam Act: To stop receiving mail from me: reply and let me know.
Use ISO 8601 dates [YYYY-MM-DD] http://www.saqqara.demon.co.uk/ 

Democracy imposed from without is the severest form of tyranny.
                           -- Lloyd Biggle, Jr. Analog, Apr 1961

More information about the linux mailing list