Some tips to help secure your Linux server and thwart hackers
Disable SSH login for the root user
Many Linux hacks are accomplished by botnets doing simple dictionary attacks against common ssh user profiles like root. To see how your system is a target, check the secure log file...
cat /var/log/secure
Best practice is to prevent ssh access via the internet. Barring that, create special user(s) who have ssh access and prevent root and other common users (like root) from logging into ssh. How to do this:
1. Create a new user
adduser admin passwd admin
2. add this line to bottom of file /etc/sudoers to give your new account sufficient priviledges.
admin ALL=(ALL) ALL
3. use su command (substitute user) as to make sure you can assume root privileges.
su -
4. to remove root SSH login access for root user, set the PermitRootLogin parameter to no
vi /etc/ssh/sshd_config PermitRootLogin no
5. restart sshd services.
systemctl restart sshd.service
Keep up to date with security patches
If you dont already use yum security plugin, then consider installing it.
to install:
yum install yum-security
list security updates
yum list-securityor
yum list-sec
install security updates
yum update --securityexample:
yum update --security Loaded plugins: fastestmirror, security Setting up Update Process Loading mirror speeds from cached hostfile * atomic: www6.atomicorp.com * base: mirror.csclub.uwaterloo.ca * epel: mirror.csclub.uwaterloo.ca * extras: mirror.csclub.uwaterloo.ca * updates: mirror.csclub.uwaterloo.ca Resolving Dependencies Limiting packages to security relevant ones 2 package(s) needed (+0 related) for security, out of 393 available --> Running transaction check ---> Package libssh.x86_64 0:0.5.5-2.el6.art will be updated ---> Package libssh.x86_64 0:0.5.5-3.el6 will be an update ---> Package socat.x86_64 0:1.7.2.1-2.el6.art will be updated ---> Package socat.x86_64 0:1.7.2.3-1.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: libssh x86_64 0.5.5-3.el6 epel 121 k socat x86_64 1.7.2.3-1.el6 epel 246 k Transaction Summary ================================================================================ Upgrade 2 Package(s) Total download size: 367 k Is this ok [y/N]: y Downloading Packages: (1/2): libssh-0.5.5-3.el6.x86_64.rpm | 121 kB 00:00 (2/2): socat-1.7.2.3-1.el6.x86_64.rpm | 246 kB 00:00 -------------------------------------------------------------------------------- Total 406 kB/s | 367 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : libssh-0.5.5-3.el6.x86_64 1/4 Updating : socat-1.7.2.3-1.el6.x86_64 2/4 Cleanup : libssh-0.5.5-2.el6.art.x86_64 3/4 Cleanup : socat-1.7.2.1-2.el6.art.x86_64 4/4 Verifying : socat-1.7.2.3-1.el6.x86_64 1/4 Verifying : libssh-0.5.5-3.el6.x86_64 2/4 Verifying : socat-1.7.2.1-2.el6.art.x86_64 3/4 Verifying : libssh-0.5.5-2.el6.art.x86_64 4/4 Updated: libssh.x86_64 0:0.5.5-3.el6 socat.x86_64 0:1.7.2.3-1.el6 Complete!
Automate updates
Updating system software is one of the best methods of reducing risk of having a server compromised. The main advantage of automating the updates is that machines are likely to get updated more quickly, more often, and more uniformly than if they updates are done manually. There is some risk in automatic updates, if updates contain bugs and cause your applications to fail.
You can automate security updates with the yum-cron pluginto install:
yum install yum-cron
By default, it’s configured to download all of the available updates and apply them immediately after downloading. Reports will be emailed to the root user on the system. Settings are found in /etc/sysconfig/yum-cron
You may have to create blank file /var/lock/subsys/yum-cron to make it work properly.
touch /var/lock/subsys/yum-cron
Another option is to have server email you with periodic updates using a cron job. There is a good discussion of this at link above.
#!/bin/sh /usr/bin/yum check-update 2>&1 | /bin/mail -s "yum check-update output" root
Suppressing information in http headers
There is no reason to reveal too much information in http headers. This information can be used by hackers to try to exploit vulnerabilities in the Apache, PHP or other modules you are running, specially if you are running older versions with known vulnerabilities. In example below, we are telling the world about our version of Apache and PHP.
Before:
To turn off php information, in php.ini, set:
expose_php = off
To suppress showing Apache information, set Servertokens and ServerSignature values in httpd.conf file.
ServerTokens ProductOnly ServerSignature Off
After:
Prevent users from seeing listings of files
Normally you probably don't want users to stumble on pages that list files or directories in your server.
in httpd.conf file
In file httpd.conf, look for the word 'Indexes', preceeded by the Options directive, usually wrapped inside Directory tags. These may occur in several places.
example:<Directory /var/www/html> Options Includes Indexes FollowSymLinks MultiViews </Directory>
In these cases you want to remove the word Indexes. After removing, restart server and test page again
in .htaccess file
In you don't have access to httpd.conf file, or want more granular control, you can do the same thing in the .htaccess file to disable display of directories in a specific directory and its subdirectories.
Options -Indexes
If all goes well, you should get a "Forbidden" error when you try to access a directory that doesn't have an index file.
Prevent authorized users from accessing text-based shell.
If some of your users don't require text-based shell via SSH, then change their user profile tp prevent access
to prevent access
> usermod -s /sbin/nologin someuser - or - > usermod -s /bin/false someuser
to allow access
> usermod -s /bin/bash someuser
You can verify who has access and who does not by viewing /etc/passwd file. You will notice that many user profiles already have this
> cat /etc/passwd
/sbin/nologin vs /bin/false
When /sbin/nologin is set as the shell, if user with that shell logs in, they'll get a polite message saying 'This account is currently not available.'. This message can be changed with the file /etc/nologin.txt.
/bin/false is just a binary that immediately exits, returning false, when its called, so when someone who has false as shell logs in, they're immediately logged out when false exits.
nologin is the more user friendly option, with a customizable message given to the user trying to login, so you would theoretically want to use that but both nologin and false will have the same end result of someone not having a shell and not being able to ssh in.
If your SSH is accessible on the internet, then this is particularly important. You may even consider doing this for root profile. Most SSH brute force attacks attemp to use root user. Make sure that you are able to access root priviledges using sudo first!
Make a passowrd for GRUB
You can configure GRUB to prompt for username and password with command
> grub-cryptor
> grub-md5-crypt