We all know it happens. A bitter old IT guy leaves a backdoor into the system and network in order to have fun with the new guys and show the company how bad things are without him.
I've never personally experienced this. The most I've experienced is somebody who broke and stole stuff right before leaving. I'm sure this happens, though.
So, when taking over a network that can't quite be trusted, what steps should be taken to ensure everything is safe and secure?
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.
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.
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 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:
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:
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:
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.
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.
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
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:
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.
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.
Ways to prevent this sort of thing.
Vet applicants carefully.
Find out if these people are disgruntled and fix the personnel problems ahead of time.
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.
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)
Check logs on your servers (and computers they directly work on). Look not only for their account, but also accounts that are not known administrators. Look for holes in your logs. If an event log was cleared on a server recently, it is suspect.
Check the modified date on files on your web servers. Run a quick script to list all the recently changed files and review them.
Check the last updated date on all of your group policy and user objects in AD.
Verify all of your backups are working and the existing backups still exists.
Check servers where you are running Volume Shadow Copy services for previous history to be missing.
I already see lots of good things listed and just wanted to add these other things you can quickly check. It would be worth it to do a full review of everything. But start with the places with the most recent changes. Some of these things can be quickly checked and can raise some early red flags to help you out.
I suggest that you start at the perimeter. Verify your firewall configurations make sure you do not have un-expected entry points into the network. Make sure the network physically secure against him re-entering and getting access to any computers.
Verify that you have fully working and restoreable backups. Good backups will keep you from loosing data if he does do something destructive.
Checking any services that are allowed through the perimeter and make sure he has been denied access. Make sure that those systems have good working logging mechanisms in place.
Basically, I'd say that if you've a competent BOFH, you're doomed... there are plenty of way of installing bombs that would be unnoticed. And if your company is used to eject "manu-military" those who are fired, be sure that the bomb will be planted well bofore the layoff !!!
Best way is to minimize the risks of having an angry admin... Avoid the "layoff for costs cut" (if he is a competent and vicious BOFH, the losses you may incur will probably be way bigger than what you'll get from the layoff)... If he made some unacceptable mistake, it's better to have him fix it (unpaid) as an alternative to layoff... He'll be more prudent next time to not repeat the mistake (which will be an increase in his value)... But be sure to hit the good target (it's common that uncompetent people with good charisma reject their own fault to the competent but less social one).
And if you're facing a true BOFH in the worst sense (and that that behaviour is the reason of the layoff), you'd better be prepared to reinstall from scratch all the system he has been in contact with (which will probably mean every single computer).
Don't forget that a single bit change may make the whole system go havoc... (setuid bit, Jump if Carry to Jump if No Carry, ...) and that even the compilation tools may have been compromized.
Good luck if he really knows anything and set anything up in advance. Even a dimwit can call/email/fax the telco with disconnects or even ask them to run full test patterns on the circuits during the day.
Seriously, showing a little love and a few grand on departure really lessens the risk.
Oh yeah, in case they call to "get a password or something" remind them of your 1099 rate and the 1 hour min and 100 travel expenses per call regardless if you have to be anywhere...
Hey, that's the same as my luggage! 1,2,3,4!
Delete everything, start again ;)
Burn it.... burn it all.
It is the only way to be sure.
Then, burn all of your external interests, domain registrars, credit card payment providers the lot.
On second thought, perhaps it is easier to ask any Bikie mates to convince the individual that it is healthier for them not to bother you.
Presumably, a competent admin somewhere along the way made what is called a BACKUP of the base system configuration. It would also be safe to assume there are backups done with some reasonable level of frequency allowing for a known safe backup to be restored from.
Given that some things do change, it is a good idea to run from your backup virtualized if possible until you can ensure the primary installation is not compromised.
Assuming the worst becomes evident, you merge what you are able to, and input by hand the remainder.
I'm shocked no one has mentioned using a safe backup, prior to myself. Does that mean I should submit my resume to your HR departments?
You know your system and what it do. So your could try to imagine what could be invented to connect from outside, even when you no longer be sysadmin...
Depending on how are the network infrastructure and how all this work, you are the best person that may know what to do and where this could be located.
But as you seem speaking from an experimented bofh, you have to search near everywhere...
As the main goal is to take remote control of your system, accross your internet connection, you may watch (even replace because this could be corrupted too!!) the firewall and try to identify each active connection.
Replacement of firewall won't assure a full protection but ensure that nothing left hidden. So if you watch for packet forwarded by the firewall, you must see everything including unwanted traffic.
You may use tcpdump for tracking everything (like US paranoid does;) and browse dump file with advanced tool like wireshark. Take a few time to see what this command (need 100Gb free space on disk):
tcpdump -i eth0 -s 0 -C 100 -w tcpdump- -W 1000 >tcpdump.log 2>tcpdump.err </dev/null &
Even if you find something, you won't be sure that you've been found whole bad stuff!
Finally, you won't be really quiet before you've been re-installed everything (from trusted sources!)
If you can't redo the server, the next best thing is probably to lock down your firewalls as much as you can. Follow every single possible inbound connection and make sure it is reduced to the absolute minimum.
Change all passwords.
Replace all ssh keys.
Generally its quite hard...
but if its a website, have a look at the code just behind the Login button.
We found a "if username='admin'" type thing once...
In essence, make the knowledge of the previous IT people worthless.
Change everything you can change without impacting the IT infrastructure.
Changing or diversifying suppliers is another good practice.
