How do you search for backdoors from the previous IT person?

It's really, really, really hard. It requires a very complete audit. If you're very sure the old person left something behind that'll go boom, or require their re-hire because they're the only one who can put a fire out, then it's time to assume you've been rooted by a hostile party. Treat it like a group of hackers came in and stole stuff, and you have to clean up after their mess. Because that's what it is.

• Audit every account on every system to ensure it is associated with a specific entity.
• Accounts that seem associated to systems but no one can account for are to be mistrusted.
• Accounts that aren't associated with anything need to be purged (this needs to be done anyway, but it is especially important in this case)
• Change any and all passwords they might conceivably have come into contact with.
• This can be a real problem for utility accounts as those passwords tend to get hard-coded into things.
• If they were a helpdesk type responding to end-user calls, assume they have the password of anyone they assisted.
• If they had Enterprise Admin or Domain Admin to Active Directory, assume they grabbed a copy of the password hashes before they left. These can be cracked so fast now that a company-wide password change will need to be forced within days.
• If they had root access to any *nix boxes assume they walked off with the password hashes.
• Review all public-key SSH key usage to ensure their keys are purged, and audit if any private keys were exposed while you're at it.
• If they had access to any telecom gear, change any router/switch/gateway/PBX passwords. This can be a really royal pain as this can involve significant outages.
• Fully audit your perimeter security arrangements.
• Ensure all firewall holes trace to known authorized devices and ports.
• Ensure all remote access methods (VPN, SSH, BlackBerry, ActiveSync, Citrix, SMTP, IMAP, WebMail, whatever) have no extra authentication tacked on, and fully vet them for unauthorized access methods.
• Ensure remote WAN links trace to fully employed people, and verify it. Especially wireless connections. You don't want them walking off with a company paid cell-modem or smart-phone. Contact all such users to ensure they have the right device.
• Fully audit internal privileged-access arrangements. These are things like SSH/VNC/RDP/DRAC/iLO/IMPI access to servers that general users don't have, or any access to sensitive systems like payroll.
• Work with all external vendors and service providers to ensure contacts are correct.
• Ensure they are eliminated from all contact and service lists. This should be done anyway after any departure, but is extra-important now.
• Validate all contacts are legitimate and have correct contact information, this is to find ghosts that can be impersonated.
• Start hunting for logic bombs.
• Check all automation (task schedulers, cron jobs, UPS call-out lists, or anything that runs on a schedule or is event-triggered) for signs of evil. By "All" I mean all. Check every single crontab. Check every single automated action in your monitoring system, including the probes themselves. Check every single Windows Task Scheduler; even workstations. Unless you work for the government in a highly sensitive area you won't be able to afford "all", do as much as you can.
• Validate key system binaries on every server to ensure they are what they should be. This is tricky, especially on Windows, and nearly impossible to do retroactively on one-off systems.
• Start hunting for rootkits. By definition they're hard to find, but there are scanners for this.

The decision to kick off an audit of this incredible scope needs to be made at a very high level. The decision to treat this as a potential criminal case will be made by your Legal team. If they elect to do some preliminary investigation first, go for it. Start looking.

If you find any evidence, stop immediately.

• Notify your legal team as soon as you find something likely.
• The decision to treat it as a criminal case will be made at that time.
• Further action by untrained hands (you) can spoil evidence and you don't want that, not unless you want the perp to walk free.
• If outside security experts are retained, you are their local expert. Work with them, to their direction. They understand the legal requirements for evidence, you do not.
• There will be a lot of negotiation between the security experts, your management, and legal counsel. That's expected, work with them.

But, really, how far do you have to go? This is where risk management comes into play. Simplistically, this is the method of balancing expected risk against loss. Sysadmins do this when we decide which off-site location we want to put backups; bank safety deposit box vs an out-of-region datacenter. Figuring out how much of this list needs following is an exercise in risk-management.

In this case the assessment will start with a few things:

• The expected skill level of the departed
• The access of the departed
• The expectation that evil was done
• The potential damage of any evil
• Regulatory requirements for reporting perpetrated evil vs preemptively found evil. Generally you have to report the former, but not the later.

The decision of how far down the above rabbit-hole to dive will depend on the answers to these questions. For routine admin departures where expectation of evil is very slight, the full circus is not required; changing admin-level passwords and re-keying any external-facing SSH hosts is probably sufficient. Again, corporate risk-management security posture determines this.

For admins who were terminated for cause, or evil cropped up after their otherwise normal departure, the circus becomes more needed. The worst-case scenario is a paranoid BOFH-type who has been notified that their position will be made redundant in 2 weeks, as that gives them plenty of time to get ready; in circumstances like these Kyle's idea of a generous severance package can mitigate all kind of problems. Even paranoids can forgive a lot of sins after a check containing 4 months pay arrives. That check will probably cost less than the cost of the security consultants needed to ferret out their evil.

But ultimately, it comes down to the cost of determining if evil was done versus the potential cost of any evil actually being done.

I would say it is a balance of how much concern you have vs the money you are willing to pay.

Very concerned:
If you are very concerned then you may want to hire an outside security consultant to do a complete scan of everything from both an outside and internal perspective. If this person was particularly smart you could be in trouble, they might have something that will be dormant for a while. The other option is to simply rebuild everything. This may sound very excessive but you will learn the environment well and you make a disaster recovery project as well.

Mildly Concerned:
If you are only mildly concerned you might just want to do:

• A a port scan from the outside.
• Virus/Spyware Scan. Rootkit Scan for Linux Machines.
• Look over the firewall configuration for anything you don't understand.
• Change all passwords and look for any unknown accounts (Make sure they didn't activate someone who is no longer with the company so they could use that etc).
• This might also be a good time to look into installing an Intrusion Detection System (IDS).
• Watch the logs more closely than you normally do.

For the Future:
Going forward when an admin leaves give him a nice party and then when he drunk just offer him a ride home -- then dispose of him in the nearest river, marsh, or lake. More seriously, this is one of the good reasons to give admins generous severance pay. You want them to feel okay about leaving as much as possible. Even if they shouldn't feel good, who cares?, suck it up and make them happy. Pretend it is your fault and not theirs. The cost of a raise in costs for unemployment insurance and the severance package don't compare to the damage they could do. This is all about the path of least resistance and creating as little drama as possible.

Don't forget the likes of Teamviewer, LogmeIn, etc... I know this was already mentioned, but a software audit (many apps out there) of every server/workstation wouldn't hurt, including subnet(s) scans with nmap's NSE scripts.

First things first - get a backup of everything on off-site storage (e.g. tape, or HDD that you disconnect and put in storage). That way, if something malicious takes place, you may be able to recover a little.

Next, comb through your firewall rules. Any suspicious open ports should be closed. If there is a back door then preventing access to it would be a good thing.

User accounts - look for your disgruntled user and ensure their access is removed as soon as possible. If there are SSH keys, or /etc/passwd files, or LDAP entries, even .htaccess files, should all be scanned.

On your important servers look for applications and active listening ports. Ensure the running processes attached to them appear sensible.

Ultimately a determined disgruntled employee can do anything - after all, they have knowledge of all the internal systems. One hopes that they have the integrity not to take negative action.

A well-run infrastructure is going to have the tools, monitoring, and controls in place to largely prevent this. These include:

• Proper network segmentation and firewalling
• Host based IDS
• Network based IDS
• Central logging
• Access control
• Change control

If these tools are in place properly, you will have an audit trail. Otherwise, you're going to have to perform a full penetration test.

First step would be to audit all access and change all passwords. Focus on external access and potential entry points-- this is where your time is best spent. If the external footprint is not justified, eliminate it or shrink it. This will allow you time to focus on more of the details internally. Be aware of all outbound traffic as well, as programmatic solutions could be transferring restricted data externally.

Ultimately, being a systems and network administrator will allow full access to most if not all things. With this, comes a high degree of responsibility. Hiring with this level of responsibility should not be taken lightly and steps should be taken to minimize risk from the start. If a professional is hired, even leaving on bad terms, they would not take actions that would be unprofessional or illegal.

There are many detailed posts on Server Fault that cover proper system auditing for security as well as what to do in case of someone's termination. This situation is not unique from those.

A clever BOFH could do any of the following:

1. Periodic program that initiates a netcat outbound connection on a well known port to pick up commands. E.g. Port 80. If well done the back and forth traffic would have the appearance of traffic for that port. So if on port 80, it would have HTTP headers, and the payload would be chunks embedded in images.

2. Aperiodic command that looks in specific places for files to execute. Places can be on users computers, network computers, extra tables in databases, temporary spool file directories.

3. Programs that check to see if one or more of the other backdoors is still in place. If it is not, then a variant on it is installed, and the details emailed to the BOFH

4. Since much in the way of backups is now done with disk, modify the backups to contain at least some of your root kits.

Ways to protect yourself from this sort of thing:

1. When an BOFH class employee leaves, install a new box in the DMZ. It gets a copy of all traffic passing the firewall. Look for anomalies in this traffic. The latter is non-trivial, especially if the BOFH is good at mimicking normal traffic patterns.

2. Redo your servers so that critical binaries are stored on read-only media. That is, if you want to modify /bin/ps, you have to go to the machine, physically move a switch from RO to RW, reboot single user, remount that partition rw, install your new copy of ps, sync, reboot, toggle switch. A system done this way has at least some trusted programs and a trusted kernel for doing further work.

Of course if you are using windows, you're hosed.

3. Compartmentalize your infra-structure. Not reasonable with small to medium size firms.

Ways to prevent this sort of thing.

1. Vet applicants carefully.

2. Find out if these people are disgruntled and fix the personnel problems ahead of time.

3. When you dismiss an admin with these sorts of powers sweeten the pie:

   a. His salary or a fraction of his salary continues for a period of time or until there is a major change in the system behaviour that is unexplained by the IT staff. This could be on an exponential decay. E.g. he gets full pay for 6 months, 80% of that for 6 months, 80 percent of that for the next 6 months.

   b. Part of his pay is in the form of stock options that don't take effect for one to five years after he leaves. These options are not removed when he leaves. He has an incentive to make sure that the company will be running well in 5 years.

It strikes me that the problem exists even before the admin leaves. It's just that one notices the problem more at that time.

-> One needs a process to audit every change, and part of the process is that changes are only applied through it.

There's a big one that everyone's left out.

Remember that there aren't just systems.

• Do vendors know that person isn't on staff, and shouldn't be allowed access (colo, telco)
• Are there any external hosted services that may have separate passwords (exchange, crm)
• Could they have blackmail material on anyway (alright this is starting to reach a bit...)

Make sure to tell everyone in the company once they have left. This will eliminate the social engineering attack vector. If the company is big, then make sure the people who need to know, know.

If the admin was also responsible for code written (corporate website etc) then you will need to do a code audit as well.

Unless you're really really paranoid, then my suggestion would simply be running several TCP/IP scanning tools (tcpview, wireshark etc) to see if there is anything suspicious attempting to contact the outside world.

Change the administrator passwords and make sure there are no 'additional' administrator accounts that don't need to be there.

Also, don't forget to change the wireless access passwords and check over your security software settings (AV and Firewall in particular)