View Full Version : Locking Down A Server
6th October 2005, 03:18 PM
I have a couple of Fedora Core 4 boxes working very well. I have some custom software running on them that I don't particularly want anyone to have access to other then me.
I have removed all of the regular user accounts, changed all of the entries in /etc/passed other then root to login to /bash/nologin and changed the root password to a complicated 14 character string.
This morning, I logged into the server and noticed that someone from the datacenter / hosting company had logged into the server. First, how is this possible? Second, how can I avoid this from happening in the future?
Any help is greatly appreciated.
6th October 2005, 03:55 PM
Do you own these boxes ?
6th October 2005, 04:07 PM
Yes - I do own them.
7th October 2005, 12:57 AM
You mentioned "data center/hosting company"--does this mean you RENT the boxes?
If so, they will have admin rights over the boxes no matter how you set the password.
If you buy the servers even and they merely maintain the place they occupy--they will still have admin/login rights.
If the boxes are sitting somewhere beside you in your home--tell them to bug off--cease and desist---etc.
7th October 2005, 01:29 AM
I own the servers. I am colocating them with a small hosting company using only their bandwidth. I am not doing anything shady, I just have a custom piece of accounting software on the machine and a backup server that backs up the data. There is personal and sensitve information on these boxes. They obviously don't do much as the bandwidth consumption is so low (100 MB per month).
Is there no way to do this?
7th October 2005, 07:24 AM
If you own these servers and you are only renting space and bandwidth, they should have no business on you server. Unfortunately, if you have physical access to a system, it is relatively easy to break in. One way to avoid that, is to set a boot password, but then you have the problem of entering the password after a re-start, i.e. you have to be physically present to do so.
Consider your system compromised.
7th October 2005, 03:45 PM
Physical access makes sence - however they aren't rooting the server using physical access.
Beyond removed all of the regular user accounts, changing all of the entries in /etc/passed other then root to login to /bash/nologin and changing the root password to a complicated 14 character string, there is no way to further lock down the server?
So then, assuming that physcial access was not used, does anyone know how they got into my box?
7th October 2005, 03:55 PM
Sounds like you are pretty certain you have these boxes locked down. Re-read the log and be doubly sure that the person did in fact log in. The next thing to do would be to look into using and Intrusion Detection System (something like Tripwire).
7th October 2005, 04:03 PM
Thank-you for the reply.
I'm not sure that I have the boxes locked down. A person with an IP address locally, inside the datacenter has logged in twice according to the log.
All that I've done is:
removed all of the regular user accounts, changed all of the entries in /etc/passed other then root to login to /bash/nologin and changed the root password to a complicated 14 character string.
Is there anything else that I can do?
7th October 2005, 08:39 PM
Make sure you are using ssh2 only and not ssh1/ssh2. ssh1 has some vulnerabilities.
Also, can you post the log file you are getting the login info from. You may want to sanitize whatever you can, before posting.
Otherwise, you should actually disable root login, create a user account for yourself,
and then "su -" (switch user) into the root account.
AllowUsers Rob2000007 otheruser anotheruser
P.S. many of the lines in sshd_config are commented or have a # in front of them. These lines are usually the default, so when changing to a non-default value, the line should not have a # in front of it, i.e. it is uncommented.
The last line in this example allows only the specified user/s to login via ssh,
so you can restrict anyone else. Remember to grant a shell to the user you allow to login.
Make sure there is no telnet server running, disable unneeded services, etc. etc.
8th October 2005, 12:52 AM
AllowUsers Rob2000007 otheruser anotheruser
This is something I suggest. All of the script kiddies who try to hit your server, will have a harder time getting access if you are only allowing 3 users access. (it also helps when people can find ways to crack the system accounts too). Also, there is a program called Bastille out there, google it. It is designed to "lock" up a system.
8th October 2005, 01:16 AM
Be very very careful setting Bastille up--it can lock everything out almost if you are not extremly careful (including YOU at boot time and never boot past the password stage--not the normal password stage--one Bastille puts in). Bastille is very good at this and can help lock down a server/computer very well--to the point of reinstalling if you are not very careful answering some complicated questions. Read every screen very carefully!! some of the default setting will lock it a little tighter then you may want....
8th October 2005, 01:45 AM
Can you post the lines of your log that shows this login?
Were they supposed to login? (maintainance etc.)
If not, did you give them any username/pwd ?
Did they use a username they shouldn't have?
Do you suspect/have evidence that the person that logged in used shady methods to get into your servers? (sniffing your pwd while you ssh etc.)
Before you do anything, make sure that you have all the facts. If you're sure they are the ones at fault, pull your servers out of there. I wouldn't trust these machines now, nor your data. Inform this hosting company about the incident. If you had explicitly told them not to attempt a login on these machines and you have this in writing, you could even take legal action against them. If you also had a login banner, warning unauthorised users, it'll help your case against them.
8th October 2005, 11:01 AM
The most obvious things to look for are the best here. Thanks VStrider, we all jumped in past those ideas.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.