Things you should do to secure/lock-down a new server.
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Last edited by jim.thornton; 03-24-2015 at 11:58 AM.
Assuming this is going to be a shared hosting server on CentOS, what would you do
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.
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.
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. (..) 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,
- 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.
Quote:
Originally Posted by jim.thornton
(..) maybe for a shared hosting environment, but maybe for a dedicated purpose. Really, the basic security principals should be similar.
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.
Quote:
- Change port from 22 to something else.
- close port 22 in the firewall
- open the new ssh port in the firewall
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.
Quote:
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.
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.
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.
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 -
Last edited by T3RM1NVT0R; 03-27-2015 at 07:37 PM.
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.
I would basically just be compiling the information.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.