Things you should do to secure/lock-down a new server.
 

I would like to compile a list of things to do to lock-down a new server. My server is up and running but I always like to know the best (or different) was of doing things.

As people make suggestions to this list, I will update the original post with the information and maybe we can compile a great sticky.

So... What steps do you take to secure your server. Assuming this is going to be a shared hosting server on CentOS, what would you do (and how would you do it)?

What programs/scripts do you install?
What configurations do you make to the system?
What services do you use?

Anything that would help someone starting in setting things up right.

Starting points:

Install:
clamav
rkhunter
aide
fail2ban

iptables and firewall in and out ONLY the services you'll need.

I'd install (and remove extra) only apps that I directly needed. Many old apps have holes in them still.

I'd look to many of the web pages on securing red hat servers.

http://wiki.centos.org/HowTos/SELinux

Disable every port possible.

Be sure to restrict any remote even ssh if you don't really need it.

Be sure to limit all users accounts to minimal.

If possible block ip addresses unknown and allow to those that are known to me.

Plenty of other ideas like rotate passwords or use certificates and such.

Boat load of others. I still like hosts files.

Shared server means shared responsibility for keeping the underlying OS secure, credentials safe and software up to date.
So first ask your provider for proof, or find out by asking specific questions, about the security posture of the machine.
Next to that shared hosting account are cheap and common sense sez you get what you pay for.
Next to that not all shared hosting providers are created equal. If I'm looking at brute force log entries I know there's certain large well-known companies I'd stay away from no matter their pricing.
- Don't store business critical data and don't run business critical processes on a shared hosting server.
- Restrict who has login / editing capabilities for services on the shared hosting account and audit their machines regularly. If the provider offers control panel access ensure its only accessible over TLS and has its own password. Adhere to SSH Best Practices if you have SSH access. That goes for all services actually.
- Only run software in that accounts web stack that is maintained and updated regularly and adhere to these products security documentation.
- Run a SVN, GIT or whatever else repo elsewhere that serves as a Staging area from which to push changes to the account. This ensures you have a backup / working copy just in case.
- Until you post more details shared hosting account also means no root access so what you can do is limited. Checking SHA256 hashes of files should work always.

I mean let's say someone is setting up a server so they can run a webhosting server. So this server being setup would likely be a VPS, or dedicated server.

Just looking for basic low-level instructions on setting up a secure server. So, if you can expand on how things would be accomplished. For example:

SSH Config:
- Turn off password authentication
- Change port from 22 to something else.
- close port 22 in the firewall
- open the new ssh port in the firewall

Partition the hard drive like this....
Mount the following partitions with ... permissions
install xxxxx program
configure xxxxx program with the following settings

I'm looking for to assist others in settings up a basic server, so that it is secure enough to open access to the internet, maybe for a shared hosting environment, but maybe for a dedicated purpose. Really, the basic security principals should be similar. I'm not looking for security suggestions that are for specific reasons, more general.

- CentOS inherits extensive documentation from RHEL so start there first with the admin and security docs,
- visit the SANS Reading Room for Web Servers, Application and Database Best Practices and Security,
- top it off with the same at OWASP and then
- visit Cisecurity for the appropriate profile to check the server with regularly.

*If unsure collate a checklist from the above resources and post it here for review.


That may be so but a Shared Hosting Server has a way larger attack surface and sees a lot more heterogeneity in really a lot of aspects: auditing, access methods and workarounds, user SNAFUs, web server user configuration, application performance characteristics and security problems. So to say "the basic security principals should be similar" isn't cutting it, which you would only know if you were ever responsible for such beasts. Buyer beware and such...

This is a great idea use keys instead but password protect those keys too.

This is useless in today's world. The newly chosen port will be found also and quickly with today's port scanners. Better to leave it alone and setup Fail2ban.

If you are really looking to go this direction then you have a lot to learn. You should look into some sort of security course to help you learn what you need to know and how to detect when you are being attacked and when you have been compromised.

I was hoping to build this as a community rather than "me". I know that, by far, I'm not qualified enough to do this. I was just hoping to build it with the help of the community to give a really good starting place for people new to it. It's not for me right now. The purpose was to build this dynamically and get input from others. I would basically just be compiling the information.

I must have misunderstood where you were coming from. Sorry.

Adding few more points:

1. Disable root login over ssh. Make sure only normal users are allowed to ssh and then if required can switch to root. Limit that access to system admins only, do not give root access to application admin or db admins etc.

2. Keep a log for sudo su - . Check this document. It will keep log even when users switch using sudo su - or sudo su - root.

3. Make sure you have password complexity requirement in place. Configure PAM accordingly.

4. Limit ssh connections for a user or group of users.

5. Use linux firewall in coordination with hardware firewall.

6. Set password expiry for user accounts including root. You can set password expiry to 60 or 90 days.

7. Disable unused user account immediately.

8. Limit failed login count to lower value, let say 3.

9. In Linux everything is a file so keep file system permission restrictive. Make use of umask to configure them.

10. If you are setting up a service account make sure it is set with nologin.

That's all I can remember for now.

Note: If you are configuring ssh key based authentication with passphrase (which is a good idea) make sure you are keeping track of passwords. If your password is expired you won't be able to login with ssh keybased authentication. It will first prompt you to change your password by putting in old password and then entering the new. Once done your ssh key based authentication will work again. Key here is you should remember the old password of the account otherwise you will end up locking yourself.

Edit: Forgot to mention when giving sudo access to users be very specific, just don't go with sudo su -

T3RM1NVTOR - All great advice. Love the one with root history logging.

Glad you find it helpful!

If your running a webserver look into mod-security, this is an application firewall designed for apache web servers, highly configurable and will take some learning with trial and error to get it right. Also look at moving log files to a log server, in case the server is comprimised you won't be able to trust your log files. Also a backup plan is a must, there are quiet a number of programs you can use to back up your server.

Yeah, I can see how that would work for you...

However there's a few problems with that approach. While you don't need a course in security as lazydog suggested you do need to understand some basics. As posts show there actually are very few people on LQ who have a "holistic" view of what security entails let alone have extensive practical knowledge of applied security. This means that you're getting all valid points I'm sure but no order or priority, no validation and no consistency. You may think you can get away easily by saying you're only a conduit but realize that you are responsible for relaying information, so if you're not certain if it's valid, consistent and complete then what's all that effort really worth?... And that's the reason why I pointed out what you should start with. No short cuts. (And no completely unnecessary duplication either.)


*More importantly security isn't a check list but a continuous process. Now that's a line you find emphasized in any security document worth its salt, however the implications of that aren't easily conveyed or learned by following a check list as it requires proper hardening, regular auditing and reporting, constant vigilance, research and adjustments. As any proper admin will tell you.