full-disclosure - Removing FIred admins

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <402C653A.70808@prosysmeg.com>
From: ryl at prosysmeg.com (Raymond Lillard)
Subject: Removing FIred admins

Cael Abal wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael T. Harding wrote:
> 
> | Anybody know of a checklist or guide to removing access across the entire
> | organization for a "retired" admin?
> | Mixed environment including Linux, Unix, Windows, Cisco, Nortel
> 
> Wow.  Nightmare.
> 
> I would expect this is exactly what you didn't want to hear, but you're
> in an awfully scary situation.  Imagine every sneaky thing a cracker
> could do -- subvert your IDS, implement Ken Thompson-esque
> login/compiler bugs, etc... And then consider that they might've
> happened any time in the past few years and have by now completely
> infiltrated your backup media.

Michael,

I'm assuming you are the "retiree's" manager.

If your "retiree" had little or no warning, you are more likely
to be safe than not.  If your "retiree" received a series of
personnel action memos over a period of 6 months prior to the
event, then you must ask yourself how vindictive this person
is likely to be, and also how clever.

I'm afraid I don't have much advice beyond what you already
know to help with the cleanup after the fact.

Going forward, consider setting up a machine to be a private
backup loghost to which only you and (maybe a trusted aide
have access) - including physical access.  Disable all services,
especially logins, on the interface where you run syslogd.
Hire a new sysadmin.  Read the logs faithfully.

Like so many security problems this one requires some
"social engineering".  Just the knowledge that a secure
loghost exists, will raise the level of effort required
for any future mischief.

Good Luck,
Ray