[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
>
> 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
> --
> 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/
datefmt.htm
Democracy imposed from without is the severest form of tyranny.
-- Lloyd Biggle, Jr. Analog, Apr 1961
More information about the linux
mailing list