Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am the Network and Systems Administrator in an organization of just under 500 users. We have a number of Windows Servers, and that is certainly my area of expertise.

We also have a very small handful of Debian servers.

We are about to terminate the sysadmin of these Debian systems.

Short of powering down the systems, I would like to know how I can ensure that the previous admin does not have control of these systems in the future, at least until we hire a replacement linux sysadmin.

I have physical/virtual-console access to each of the systems, so I can reboot them in various user-modes. I just don't know what to do.

Please assume that I do not currently have root access to all of these systems (an oversight on my part that I now recognize.)

I have some experience in Linux, and use it on my desktop on a daily basis, but I must admit that I am a competent user of linux, not a systems admin.

I have no fear of the command line however....

Is there a list of steps that one should take to "secure" a system from somebody else?

Again, I assure you that this is legit, I am re-taking control of my employer's systems, at the request of my employer.

I hope to not have to shut the systems down permanently and still be reasonably certain that they are secure.

Thanks for your time.

share|improve this question
2  
Are these systems accessible from outside the company network? If not simply making sure his VPN credentials are revoked should be enough to keep him off the system. –  3dinfluence Apr 1 '10 at 14:22

4 Answers 4

up vote 5 down vote accepted

This reply is primarily to espouse the benefits of properly maintaining access within your IT department.

Your situation examples the benefit of an audit trail and proper access control. For example, all access would require an access request ticket with approval, without exception. Upon termination, you audit the ticket system.

For common roles within your company, the access can be standardized and even easier to eliminate.

For IT roles, we have a spreadsheet that we work out of for terminations. It lists everything to prevent oversight. We also audit our access request tickets and our work logging system, as all production changes are documented there.

Administrators should also have individual user accounts, which they use to access administrative privileges. root and administrative accounts should not be authenticated to directly. While this is not technically infallible, it enables an audit trail as well as individual accountability. With this, locking all his accounts would be a first step and then you change all admin accounts.

If you have not already, I would encourage you to implement some of these solutions if not all of them. I consider them integral and it reduces risk when an involuntary termination occurs.

First, remove all external facing access. Any access the person could use without being on premise. Then, change all passwords. Every administrator password, every system password, every application password, every vendor account password, every support account password-- everything. If the risk for retaliation is great, you might expire all employees' passwords as well.

Since you do not have the root passwords to the Linux servers, you can boot in single user mode and change it. With GRUB and LILO, you would simply append single. The methods are similar.

As others have recommended, audit all crontabs (located in /var/spool/cron), system users, running daemons, ssh keypairs, and the systems in general.

While rebuilding is the only way to be certain, it should not be necessary in most cases. Any respectful professional would not risk their career on such a guttural reaction. It would also enable pursuit of both criminal and civil damages by your employer. Ultimately, I would suggest having a serious discussion regarding the risks with your manager after performing due diligence with removal.

share|improve this answer
1  
This is excellent, and exactly the lesson I am learning here. I let this guy build up these boxes and put them in a position that we now rely on. This is entirely my failure. –  netadmin Apr 1 '10 at 17:08
    
Oh, the person terminating him could always ask for the passwords too. ;) Most reasonable people would provide them. –  Warner Apr 1 '10 at 17:18
    
That will be done, but I have expectations that he will not be entirely forthcoming –  netadmin Apr 1 '10 at 18:34

You can restart the Debian systems in single user mode and change the password for the root account, but you'll also have to make sure that there aren't other users with SSH access that the sysadmin has access to.

Any FTP passwords or MySQL passwords should be changed as well. You can also start checking the services and cron jobs, and make sure every program that's running is supposed to run.

The safest and fastest route would be backing up your data and reinstalling the servers, though it depends if you can accept the downtime this creates.

share|improve this answer
    
The downtime would surely be extended. These systems primarily provide integration between other systems... and I am not sure I have the expertise to recreate the current sysadmin's work. Thank you for the suggestion however, I may need to go that route. –  netadmin Apr 1 '10 at 14:20
1  
Also look for ssh keys, since that will bypass blanked passwords. –  Scott Pack Apr 1 '10 at 14:30

Delete unkonwn ssh keys from /root/.ssh/authorized_keys , and search if other users have unknown users in their authorized_keys file.

share|improve this answer

Base two weeks leave pay on the root password!

share|improve this answer
    
+1 I like this. –  Warner Apr 1 '10 at 21:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.