Using Wisdom In the Use Of Your Linux Server

Hello, all!
It's been a while since I've posted, so I thought I'd explain some of the fundamentals of a Linux system, as well as what to do and what not to do while using your server or other system. This article isn't necessarily targeted for newbies to the Linux environment, but I'm thinking about writing some articles to help those new to the Linux operating system and its environment.

Punctuation is heavily used, as commands rely on several characters a screen reader may not speak by default. Visually impaired users are advised to set their punctuation level to most or all in their preferred screen reader, if using one.

Some fundamentals and basic terminology used in this article

I'm not going to describe every term in the book, but these are some basics to give you an idea of what I talk about in this article.

Linux

Linux is an operating system typically run on servers. It's used because of its open-source design, lightweight footprint, and simple yet versatile command line interface.

Unix

An operating system similar to Linux. The terms Linux and Unix are used somewhat interchangeably, when a command on Unix would apply to one on Linux.

Command line

The command line is a place where a user can enter commands. Typically, the command line makes use of a shell, which is a program that parses commands, scripts, and characters used in commands that can be executed on a Linux system. In this article, the $ (dollar sign) is used to denote the beginning of a command for a regular user, and # (the hash or pound symbol) is used for a command executed as root. When copying these commands, leave the $ and or # signs out of it, and remove the white space to the left of the command. I explain this because I've seen comments from users that didn't know this, so they executed the commands with everything included, which didn't work.

Paths, directories, and files

A path in the Linux environment consists of names separated by the / (slash) character. An example of a path would be
/directory/to/my/file

A directory could be explained as a container that holds several files.

A file is something that contains information, like configuration information for a program, or even a program that can be executed on the system.

Fundamentals of a path

The / (slash) character separates the various directories from one another.

The ~ (Tilda) character is a shortcut to a users home directory, like /home/tech.

./ is a way of specifying the current directory.
../ is a way of specifying a directories parent. For example, if you're in /home/tech/arch, ../ would take you to /home/tech.

Program

A program is a file that, when executed, performs various operations based on the instructions written for the program.

Firewall

A firewall is typically used to protect a server from connection flooding, people looking for open ports, etc.

Things not to do

$ sudo halt

This only applies if you're running a dedicated server that you don't have direct access to. If you have access to the hardware or you can restart your system through a console, halt is okay. If not, don't use it. Halt will shut down your system and it won't start back up. You can probably understand why that could be a problem for a dedicated system. You'd have downtime until your support request to boot your server back up was received.

Logging in directly as root

This is a bad idea. You'll want to avoid logging in directly as root whenever possible, since root can execute virtually any command on the system. Use utilities like sudo to execute commands if you must have root privileges. Also, try and avoid running programs as root or allowing programs to run as root whenever possible.

$ sudo rm -rf /

DO NOT EXECUTE THIS!

I hope that was sufficiently emphasized, but I'll repeat it again. Do not execute that command. I can't say that enough. That command will delete every file on your system. Not only that, but it will also delete every file on any mounted drive. You'll be in quite a bit of trouble, especially if you're on a dedicated server. If you're on a VPS, you'll be in trouble still, though it probably won't be as severe, especially if your VPS provider offers a backup service like Linode does.

$ sudo chmod 000 /

Your server might still be up and running if you do this, but I doubt it'll be able to do much after that. You certainly won't be able to log in as a normal user again, or execute commands as a non-root user. Any process that attempts to start as a non-root user will fail to do so, and if you're locked from logging into your root account, you're in trouble. If you restart the system, many of your processes will fail to start and you'll receive errors, as they won't have the availability to write to logs, execute other needed commands, etc. If you have root available, you can recover by executing the following command after logging in as root:
# chmod 755 /
You probably won't be able to do that remotely, either. You'd have to have a console of some type.

Explaining the chmod command

This is a brief, but hopefully understandable explanation of the format of the chmod command, as used in this document.

Chmod is used to change the permissions of directories and files. The numbers used indicate the permissions. 1 is execute, 2 is write, and 4 is read. They can be added together to produce the values required in the chmod command. For example, 6 would indicate read/write access, 2 + 4 = 6. 5 would indicate read/execute access, 4 + 1 = 5. 3 would be write/execute, and 7 would be read/write/execute access.

Now that all the formats for the numbers have been covered, let's cover why there are three numbers.

User	Group	Public
7	5	0
Read/write/execute access	Read/execute access	No access

Just in case the table didn't fit with the article nicely or wasn't understood, I'll explain it in the traditional way. The first number indicates the user has access. The second indicates the group has access. The third is for public access. So, the permissions 750 would indicate that the user has all access, the group can only read and execute, and everyone else can't access the file or directory. The only exception to this is root, which is once again why it's a bad idea to do everything as root, or log in directly as that user.

Another option I use is -R, which will recursively apply permissions. This option is available on chown as well, which is virtually the same as chmod. The only difference is that you'll enter user:group in place of where the numbers would normally have gone. Here's an example.
$ sudo chown root:root /
This makes the user and group named root own the root directory in the file system, which is / (slash). This command is okay to execute, since the user and group root already own this particular directory.
Do not add -R to that command if you choose to execute it! You'll make all your files and directories on the system owned by root, which will cause problems when other users try and execute something that needed to belong to them.

A brief explanation of users and groups

The Unix security mottle was written to allow users granular control over file and ownership permissions. You can be as secure or as insecure as you want. Here's an example.

Typically, if you create a user on a Debian system with the adduser command, each user will be given a group that matches the username for the user. So, if I created a user with the username john, the users group would also be john. But, let's say I wanted john to share files with some other users, Sally, Jessy and Tim, who have all been added to the trustedusers group. These users would have full access to each others files, but not the entire system. Chmod 777 on John's home directory? Nope. Add john to the trustedusers group, either as his primary group or a secondary one, depending on how you wanted to handle things. The easiest way would be to add John to the trustedusers group, and make that his primary group. That way, any file he created would be owned by the trustedusers group. Now, we can chmod his home directory to 770. That allows Tim, Jessy and Sally to have access to John's files, but it isolates their files from other people on the system.

There are probably better ways of accomplishing the same task, but this is a simple explanation of the power of users and groups on a Unix system.

$ sudo chmod 000 /bin/chmod

If you execute this, you'll lock yourself out of using the chmod command. You'll have to either find a binary you can run, or compile it from source to unlock yourself from using it.

$ sudo chmod 000 -R /bin

If you execute this command, you'll lock yourself out of executing many commands on the system. Don't chmod /usr, /sbin, or any other important directory like /etc, /dev, or /home to 000 either.

Setting umask to 000

Do you really want to let everyone do everything with any file or folder you create? I didn't think so.

Umask tells the default permissions that will be used when creating a file. This is somewhat confusing, since it's opposite of chmod. 7 is assumed by default, and instead of adding the values for read, write and execute, you subtract them. So, 027 will give your user all access, the group read and execute access, and everyone else no access. I might explain this in more detail if it's requested. How to set umask will be covered later in this article.

$ sudo iptables -A INPUT -j DROP

If you're running the iptables firewall, which I'll explain later on in this article, this command will block all network access to your server. In otherwords, if you're using some remote means of getting into your system, you're out of luck. Replacing INPUT with OUTPUT is just as bad, as is setting the policies for the INPUT and OUTPUT chains before setting rules.

Things to do

Update the system

This is the first thing you'll want to do after an OS install, even if you've installed it using an internet install. Use your package manager to update your software.

Install sudo and set up a user with sudo access

This is the next thing you'll want to do when setting up or securing your server. Many Linux distributions come with sudo by default, but some don't. On arch Linux, for instance, use the following command to install sudo.
# pacman -Sy sudo
Debian:
# apt-get install sudo
CentOS, RedHat, Fadora, or other similar operating system:
# yum install sudo
I may have gotten that command wrong, I'm uncertain as I haven't used CentOS or a similar operating system for quite some time. In any case, look up the package manager for your operating system and how to use it. After that, install sudo and edit the sudoers file.

The sudoers file

There are more detailed explanations of the sudoers file out there, but this will simply ensure you have configured it correctly for your user account.

You'll want an entry like this in the file, which is typically located in /etc/sudoers.
john ALL=(ALL) ALL
This will allow john to execute all commands using sudo, temporarily elevating those commands to root.

You can also add groups in the sudoers file, like so.
%sudo ALL=(ALL) ALL
This allows anyone in the sudo group to execute any command.

Regularly update the system

Use your package manager to ensure the system is regularly kept up to date, fixing any security holes in software you may have installed. If you haven't installed software using your operating system's package manager, you'll be responsible for upgrading it and ensuring it's installed and maintained correctly.

Give shell accounts to only those you trust

If you're going to give out shell accounts, it's advisable to give them only to those who you trust, or secure your system against possible attack paths. The best method is to give out shell accounts to only those people who need them, as there are usually ways people can access other services without a shell.

Disallow passwords and use SSH keys

Most people use OpenSSH to access their systems, but if you don't, this won't apply to you. Using SSH keys to secure your system, combine with disallowing passwords, will go a long way toward securing your system from hackers. It may also be inconvenient for people using sftp clients, though, depending on which client they're using. Using passwords is much easier, but not advisable if you want to have a more secure system. If you choose to use a password, set the following in the /etc/ssh/sshd_config file
PermitRootLogin no

sudo chmod 711 /home

If you don't want your users to list the contents of /home, which is typically where a users home directory is, you can execute this command. For extra security, you'll probably want to go through the /home directory and chmod all the directories to 750, preventing anyone else from accessing anyone's files or directories. You could easily do this by executing the following two commands as root:
# chmod 750 -R /home
# chmod 711 /home
There may be an easier way of doing this, but this seems to generally work okay, especially if you have the commands in a shell script or copy and paste them, so they're done quickly enough that most users wouldn't notice.

Please, don't forget to make home executable by everyone, or you'll have problems getting into your system unless you're logging in as root.

Make sure users directories are created with permissions 750

You can edit /etc/adduser.conf in Debian or a similar system like Ubuntu. This file has many options, but you'll be able to change the permissions users directories are created with. Generally, 750 is a good rule for security.

Change umask to make users files more secure

This is an excellent idea. It protects your users and you.

To change the umask setting, edit one of these files:

• /etc/bash.bashrc
• /etc/bashrc
• /etc/profile

Editing /etc/profile is recommended, as that's the one that is global across many of the Linux distributions I've seen. Add the following line:
umask 027
This secures files quite nicely, as you probably remember from my previous explanation of umask.

sudo chmod 711 /

If you want to execute this command, DO IT CORRECTLY!

This will prevent your users from reading /, the root file system. They won't be able to list anything in /, which will prevent them from determining where files could be stored. You could also set the same permissions on /etc to prevent users from accessing configuration files, though this might cause problems. I haven't tested this. Note that if you choose to do this, it may not only cause problems, but will make it more difficult for you to edit your configuration files.

Deactivate unnecessary services

Unless you're starting from a minimalist installation, you should deactivate unnecessary services that you don't require. This will free up memory, disk space, and will close possible avenues for attackers to get into your system.

Set up a basic firewall

Use iptables to set up a basic firewall, somewhat like this:
sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -P INPUT DROP
This will do the following things:

1. Allow connections that are related and established to another through the firewall, like a file transfer that's already running.
2. Allow incoming connections to port 22, the default port used by OpenSSH.
3. Set the default policy for the INPUT chain to drop, so any connection not placed in our rules are dropped.

Enjoy what you're doing!

Unless you're being paid a lot of money to secure a system, enjoy what you're doing! A lack of stress goes a long way toward learning new things. I, myself, learn much better in a calm, relaxed environment. If I get stressed or overwhelmed, or even if I don't enjoy what it is I'm doing, I have a more difficult time learning new things.

Final notes

Keep in mind that I'm not an expert on Linux system administration, though since I have been doing it for five years as a hobby, I think I have some intermediate knowledge on how to do a few things here and there. I'll do my best to answer any questions, if asked, and if relevant and thoughtful, I'll possibly add them to this article. If I think of anything new since adding this list, I'll be sure to add it in the correct order.

Have fun, everyone!