1. Do not allow direct root/administrator login
2. Make sure passwords are secure and changed regularly (by force if necessary)
3. Use a network firewall, such as APF
4. Use an application firewall, such as ModSecurity
5. Chroot all non-root users to keep them out of system directories
6. Use virus scanners and spam filters
7. Close mail server open relays
8. Keep all software and scripts up-to-date
9. Test your server for security holes
10. Keep up on the latest security news
11. Use SSL for secure data transactions
12. Set permissions as strictly as possible on any web-accessible files

Image Source: Wikimedia Commons

Answer: The truth is that having root logins enabled is not in itself a security risk. The real risk comes from having an easily hacked root password or non-secure web applications on your server that allow hackers to decipher the root password. Disabling root login gives those hackers one less avenue to exploit, and if you do not need to login directly as root through SSH, there is really no reason to have it enabled.

Actually disabling the root login is not nearly as complicated as my above explanation. Just follow these steps:

1. Login to your server via SSH
2. Become root:
su
3. Edit /etc/ssh/ssh_config
4. Add the following line:
PermitRootLogin no
5. Save and exit

Photo Source: Flickr

On a Windows server, file executables typically have .exe, .com, or .bat extensions. Without question, any emails or other transfers that contain such attachments should be blocked. Many attackers have adapted to mail scanners that block those extensions and will often send files with alternative extensions like .zip, but the files are still actually executables. You can decide what types of files to restrict and how to scan and monitor incoming files.

On a Linux server, any file can potentially be executable when it is assigned the correct permissions. In fact, standard executables have no file extensions at all. This means you have to be extra cautious about unauthorized scripts. You can deny executable privileges to any directories/partitions except the ones owned by root. This should greatly reduce the chances of security exploits. Usually, a Linux mail server will still receive Windows virus executables intended for home Windows computers. You should, therefore, configure a mail scanner to detect them and quarantine them.

Photo Source: Flickr

/ – Known as the root partition, this is where all of the system files belong. You will find /usr, /lib, /etc, and many other critical system directories all under the root partition.

/swap – The swap partition is a virtual memory storage directory that Linux will use when your memory has been filled. On systems with large amounts of RAM, the swap may be used very sparingly.

That is it. Although it might seem complicated, those are the only two partitions you need to get Linux up and running. There are, however, other partitions that you can create for specific directories. Partitioning them may add security and stability to your server.

/usr – This holds executable binaries, kernel source, and documentation
/var – Mail spool directories, logs, and sometimes virtual web server directories are held here.
/tmp – This holds temporary files (having its own partition can keep attackers from using it to gain access to the server)
/boot – This holds the kernel image and boot loader
/home – Keep user home directories separate from the root file system.

Tomorrow, we will cover more information about setting up each partition.

Photo Source: Flickr

There are benefits and drawbacks to each. With “su”, root is a true separate user, and some administrators find it more useful to be able to log in as root and run several commands. With “sudo” only commands with those words in front of it will be administrative preventing the user from accidentally running a dangerous command as root.

There are security benefits to each, and the argument over which is better can get heated. Suffice it is to say that it ultimately depends on the preference of the system administrator. Does he/she want to deal with one password or two? Technically, an administrator can decide to use both on the same server and use the one that is most beneficial at the time. It can also be useful if you have multiple users who need various permissions.

Photo Source: Flickr

1. Disable the root password on the real server. Users may decide to use root passwords on their VPS systems, but do not make it easy for attackers to get past them to the real system.

2. Create a user designed just for admin tasks and give it “sudo” rights.

3. Create an ssh user to handle any remote logins and an sftp user for uploads to the real server. Disable remote access for all other users.

4. Run OpenSSH on a port other than the default 22. You can use 2222 or something else.

5. Rely on SSH keys for the two secure users and disable clear password authentication.

Photo Source: Flickr

In most Linux distributions, umask for all users is set in /etc/bashrc or /etc/profile. It uses a four digit code to determine the permissions. The default umask is 0002, which sets default directory permissions to 775 and default file permissions to 664. Use this simple calculation to determine the umask code for a permission:

Subtract the permission you want from the default file permission:

777 - 755 = 022

Similarly, for directories:

666 - 644 = 022

For a complete explanation of umask settings, type man umask from the command line.

Image Source: Wikimedia Commons

Answer: In a previous post, we covered the “who” command, which will tell an administrator which users are currently logged into the system, but another important thing to know about your server is which users you actually have. You will want to look at a complete list of users to make sure all the existing users are supposed to be there.

To list all users, enter the following command:

cat /etc/passwd | cut -d":" -f1

Also, to find out the total number of accounts, enter:

cat /etc/passwd | wc -l

Please note that this will look for all accounts, including those created by Linux, such as “mail” and “haldaemon”, but it will also include manually created local users.

To begin you need to make sure your Linux distribution has the necessary libraries (usually -dev or -devel endings) to build software from source. In Redhat-based distros, you need the development tools:

# yum groupinstall "Development Tools"

Next, download the program you want to install. It will typically be compressed in a tar.gz or tar.bz2 archive. You will need to uncompress them:

$ tar xvzf package.tar.gz
or
$ tar xvjf package.tar.bz2

Now, change to the package directory.

$ cd package

You should see a “configure” script in the directory. You will use this to setup the build. If you receive errors that prevent it from completing, you will need to install any of the development packages that it requires. Sometimes, this can take time.

$ ./configure

Now run “make” which actually performs the build process:

$ make

Finally, run “make install” as root to install the newly created binary files in their proper locations. All of this will happen automatically.

# make install

If all goes well, you are done. It is that easy to build and install software, assuming you receive no major errors.

Why would you want to schedule a reboot? Usually, you only need to reboot a Linux server after installing a kernel update. Since you can plan such an update ahead of time, the ideal time to reboot would be when most users are not accessing the server. That time, however, might be when you are asleep.

To use “at”, become root and type “at” followed by the time you want the server to reboot:

# at 4am tuesday

This will start the “at” prompt, where you need to type “reboot”.

at> reboot

Press CTRL+D to save your settings. Now your server will reboot at the specified time.