#linux server security

How To Ensure Server Security

How to ensure server security?

Question server before giving answers in such way that our server said more work should mention that what we call computer. Server has become an essential for all large or small business needs today.

  Server PCs (Personal Computer) by hardware problemsare less and length of service of employees in the 7/24 capacity terms, according to this study, cases with special…

One of the the basic foundations of working with Linux is delegating file access permissions: who can access the file and who can manipulate it. Default file permissions for system files are usually already set by the OS. However new files created by users and third party programs need to be taken care of manually. Missteps in setting up file permissions can lead to problems with the system, newly installed programs, and potentially increase security risks. More importantly, this can lead to authentication and authorization errors. For example, when you try to setup key-based access to your server, generate the keys, put them into a folder and accept access permissions of that folder, try to connect but.... the server is still asking for a password. If you look into the system journal you'll see the following:

Permissions 0755 for '/Users/username/.ssh/id_rsa' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored

Obviously! We put the key into a public folder, that's accessible to anyone... even the server figured it out. Doing stuff like that not only leaves your server open, but any other server that might be using that same key for access. Sometimes you might hit an error when trying to create a directory:

mkdir: cannot create directory `/home/myfiles': Permission denied

Again, the problem is file permissions. Basically, every file created- either automatically or manually- in Linux will have some kind of permissions already assigned to it. We'll need to be able to look through, understand, and modify them. Checking Permissions The common command for getting a list of folder contents is "ls -l":

ls –l total 4 lrwxrwxrwx 1 root root   11 May 27 19:47 examplelink -> examplelink drwxr-xr-x 2 root root 4096 May 27 19:46 mydirectory -rw-r--r-- 1 root root    0 May 27 19:45 script.sh -rw-r----- 1 root root    0 May 27 19:45 simplefile.txt

Here we got four basic kinds of files: 1. A shortcut "examplelink" 2. directory "mydirectory" 3. Script file "script.sh" 4. Simple text "simplefile.txt" You can see the corresponding file attributes in the column to the left; from left to right they describe the nature of the file ('-' basic file, 'd' directory, 'I' symbolic link/shortcut) and the access permissions for this file. The next three symbols refer to the permissions of the primary user, the primary group of that user, and, finally, anyone else who might have potential access. For the file 'simplefile.txt,' the user (root) can read (r) and write to (w) the file, which includes moving and/or deleting the file. A dash means that this file can't be executed, meaning that running it as an application won't work. Other users in the group 'root' only have read-only access (r--), including seeing the file's attributes, while everyone else don't have read access to begin with (---). For the 'mydirectory' file, the parameters are very similar except for the execute parameter (x) for the last group. This designates the file as being executable as a program or application. Take note that the 'script.sh' file is executable, however no user or group has permissions to do so. At this point, it should be obvious that in order to maximize system integrity we really need to assign file permissions on a file by file basis as much as we can.

Modifying Permissions

IMPORTANT: Modifying some permissions, especially if you have root privileges, can severely disrupt the entire OS. Pay close attention to what you're doing, and test everything before executing. Don't forget to make backups before modifying anything, especially for larger files and directories, and store it in a secure location. When modifying permissions, pay attention to the way you use the '/' symbol in file paths. Using the command "chmond u-x /home/username", if you put an extra space in front of the first '/' by accident you will actually revoke execution permissions for every file on the server! The 'chmod' command, by the way, is how you change file access permissions. For example if you attempt to run the 'script.sh' file from before, it won't work:

./script.sh bash: ./script.sh: Permission denied

So, we'll use the following command:

chmod u+x script.sh

Let's unpack that real quick: using the 'chmod' command we're allowing (+) the user (u) access to execute (x) the file 'script.sh.' When we check the file attributes we should see:

ls -l | grep script -rwxr--r-- 1 root root    0 May 27 19:45 script.sh

You should be able to see the 'x' listed in the attributes, which let's us know this user can now run the file. If the file has information you're trying to hide from the rest of the group, you will need to revoke read rights from everyone else in the group:

chmod go-r script.sh

Here, the other users (o) of the group (g) are getting their read (r) permissions revoked (-). You can change up this command to substitute the 'o' for 'a' (all) to remove permissions from everyone in the group. Using the 'a' tag will include permissions even for the root users until they modify those permissions again. When using this command to change permissions for a directory, you will only be changing permissions for the directory and not for any files or subdirectories in it. In order to include files and subdirectories you need to add the tag '-R' to the command:

chmod -R g+x ./mydirectory

It's actually easier to assign permissions using a number system, so let's go over that real quick. Remember when we were going over the private keys we used to access the server without a password. If you created them like regular files, they will have the default rights 655 which corresponds to the primary user having read-write access, and everyone else having read access. So for the key folder, it's enough to just have read access to these files:

chmod 400 /home/myuser/.ssh/id_rsa

Or if you need to give access to the entire folder:

chmod -R 400 /home/myuser/.ssh

Here's the shortlist of common numerical commands used to modify permissions:

400- the primary user has read-only access, and no one else has access. 600- the primary user has read-write access, and everyone else has read only access. file can't be executed. 700- same permissions as 600, except that the file can be executed.

Normally, the group only needs read access, but in some cases you might encounter these commands as well:

777- this will allow complete access for any and every user, to read and write. Generally, this permission level shouldn't be used. 660- everyone has read-write permissions, but the file cannot be executed. 644- the primary user can read and write, but not run. Everyone else has read only access.

Expanding Standard Permissions

In order to assign permissions to users across multiple Linux distros, and a variety of file systems, you will need to install 'acl' and 'attr' packages. This is especially true for users using Samba and using file systems based on ext4.

So, to summarize, the main issue with file permissions is to properly limit file access to users and groups on a case by case basis. Depending on your needs, you may have to give every user unique and, sometimes, complex sets of parameters.

Hope this article helped you out. We're not quite done with Linux file permissions; our next article will go deeper into this topic, so stay tuned. Always remember to follow ServerSuit on Facebook and Twitter to keep up with new articles. Until next time!

There are never enough questions about Linux server security and how to be sure that no one, except you, would ever be able to connect to it. We've discussed this before with our articles on using key-based authentication and fail2ban. I can personally think that you should always use keys to access SSH on your server, because even the best passwords can be broken. Not to mention having to change it every few months and trying to remember it. Yeah, I know password managers exist but when we're talking about your server with sensitive data on it, you want to be damn sure it’s safe. And that’s where 2-factor authentication comes in.

Back in the day, it was something like in the movies: two people entering theirs unique passwords and pressing buttons simultaneously to open the secret hangar or something. Now it’s just entering a quick, temporarily generated, password you recieved in a text to confirm it's really you using your password. But enough analogies. Let me show you how to configure your CentOS server to use Google Authenticator's 2-factor authentication service. Make sure you get the relevant Android or iPhone apps before using it.

Install required packages and make sure you have the current time set on your server:

yum install make gcc pam-devel ntp chkconfig ntp on service ntpd start

Add EPEL repository and install the Google-authenticator package:

yum install epel-release yum install google-authenticator

Configure your Google authenticator. You'll also need to answer some questions. We provided a simple guide to the answers for you, too.

[root@serversuit ~]# google-authenticator https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/root@centos-512mb-fra1-01%3Fsecret%3DENFNPPXC3VPT5ZEV Your new secret key is: ENFNPPXC3VPT5ZEV Your verification code is 282506 Your emergency scratch codes are:  44365444  68651888  65307512  43469780  11074666 Do you want me to update your "~/.google_authenticator" file (y/n) y Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y By default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) n If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y

Configure PAM.

Edit ‘/etc/pam.d/sshd’ file and add the line shown below at the top of the file:

auth       required     pam_google_authenticator.so nullok

The ‘nullok’ directive means that Google Authenticator will be applied only for users that have ‘~/.google_authenticator’ file in their profile.

Configure ‘sshd’ service

Edit ‘/etc/ssh/sshd_config’ file, check the settings below and restart the service:

PasswordAuthentication yes ChallengeResponseAuthentication yes UsePAM yes service sshd restart

Now it’s about the time to test your settings:

login as: root Using keyboard-interactive authentication. Verification code: Using keyboard-interactive authentication. Password: Last login: Thu Jun  2 08:29:20 2016 from [root@serversuit ~]#

If you enter the wrong verification code you should see the following error in the ‘/var/log/secure’ file:

Jun  2 08:38:06 serversuit sshd(pam_google_authenticator)[12367]: Invalid verification code

So, as you can see, even if your password becomes compromised would-be intruders still can’t login to your server without your smartphone!

Just some advice, before I let you go: 1. Hold on to your secret key and emergency scratch codes. You’ll need them if you reset, or lose, your smartphone.

2. You can allow login to your server from local network without using 2-factor authentication: just create a file ‘/etc/security/access-local.conf’ with the following content and you're good to go:

# Allow access from the local network’s + : ALL : 10.0.0.0/8 + : ALL : 172.16.0.0/12 + : ALL : 192.168.0.0/16 + : ALL : LOCAL - : ALL : ALL

I used the usual local networks, so you'll need to figure out which ones will work for you.

3. If you are logging with SSH keys then you won't be asked for your verification code! It make sense, since SSH key authentication is already strong enough. But you should still use 2-factor authentication without key file if you're working from untrusted environment.

That's all for now. I hope that this article will help you out! Follow us on Twitter and Facebook, to stay updated with future articles.

Until next time!

This is going to be the first of a series of articles about Linux server security and best practices. Every good systems administrator wants their servers to be secure, and I’m sure that you are no exception. I assume that you already know about having a good root password, and your servers always have latest security updates installed. Let’s begin with a Linux firewall called ‘iptables’. In CentOS you can see the current iptables config in a readable format running this command:

[root@ServerSuit ~]# iptables -L Chain INPUT (policy ACCEPT) target     prot opt source      destination ACCEPT     all  --  anywhere    anywhere            state RELATED,ESTABLISHED ACCEPT     icmp --  anywhere    anywhere ACCEPT     all  --  anywhere    anywhere ACCEPT     tcp  --  anywhere    anywhere            state NEW tcp dpt:ssh REJECT     all  --  anywhere    anywhere            reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target     prot opt source      destination REJECT     all  --  anywhere    anywhere            reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target     prot opt source      destination

So, let me explain the basics of what we're looking at here. Every network packet went through one of iptables ‘chains’, where it will be checked against every rule from the top, down. All packets sent from other devices and addressed to our server will go straight to chain “INPUT”. Every packet created on our server and sent outside will go through chain “OUTPUT” rules, and if server receives a packet addressed to different IP address than its own, that packet will go to chain “FORWARD”. In most cases, forward iptables rules will be applied if our server is acting as a router. So, the default ipconfig will do the following: 1. Allow all packets for previously established connections, as permitted by other rules. 2. Allow all incoming ICMP packets (i.e. ping) 3. Allow all traffic to local loopback interface (127.0.0.1) 4. Allow incoming SSH connections to the server 5. Restrict all other incoming connections 6. Restrict all forward connections 7. Allow all outgoing connections from the server. In other words, you can setup any connection that begins at the server itself, but only be able to ping and connect through SSH externally! This is how these rules look if you had to write out the commands:

[root@ServerSuit ~]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited

Anyway, that's the basic theory. Let’s look at a few examples! In most cases, you just want your new installation to work remotely. Right now if you installed Apache you’ll need to allow HTTP and HTTPS ports open for incoming connections, first. Here's how we do it:

[root@ServerSuit ~]# iptables -I INPUT 1 -p tcp --dport 80 -j ACCEPT [root@ServerSuit ~]# iptables -I INPUT 2 -p tcp --dport 443 -j ACCEPT [root@ServerSuit ~]# iptables-save > /etc/sysconfig/iptables

We inserted 2 rules at the top of INPUT chain to allow incoming connections to TCP ports 80 and 443. Make sure you save that config, or your changes will only work until server reboot. Notice: if you add this rules with –A tag, they’ll be added after the REJECT rule at INPUT chain and won't actually work. That’s why we insert them at the 1 and 2 lines of firewall rules. You can change the ‘-p’ and ‘—dport’ tags for your application. For example, if you install exim and dovecot servers you’ll need to allow incoming connections to TCP 25 and 110 ports. That's one of the more frequently asked questions with iptables for beginning systems administrators. Ok, now let's check this out: you might've looked at /var/log/messages and seen something like this:

Apr 03 18:45:09 ServerSuit sshd[1927]: Failed password for root from 1.1.1.1 port 52279 ssh2 Apr 03 18:45:10 ServerSuit unix_chkpwd[1932]: password check failed for user (root) Apr 03 18:45:11 ServerSuit sshd[1927]: Failed password for root from 1.1.1.1 port 52279 ssh2 Apr 03 18:45:12 ServerSuit unix_chkpwd[1933]: password check failed for user (root) Apr 03 18:45:15 ServerSuit sshd[1927]: Failed password for root from 1.1.1.1 port 52279 ssh2 Apr 03 18:45:16 ServerSuit unix_chkpwd[1934]: password check failed for user (root) Apr 03 18:45:17 ServerSuit sshd[1927]: Failed password for root from 1.1.1.1 port 52279 ssh2 Apr 03 18:45:17 ServerSuit sshd[1928]: Disconnecting: Too many authentication failures for root

Seems like somebody was trying to pick your ‘root’ account password and its IP address is ‘1.1.1.1’. You can restrict this IP address from connecting to your server:

[root@ServerSuit ~]# iptables -nL INPUT --line-numbers Chain INPUT (policy ACCEPT) num  target     prot opt source       destination 1    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp dpt:80 2    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp dpt:443 3    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0           state RELATED,ESTABLISHED 4    ACCEPT     icmp --  0.0.0.0/0    0.0.0.0/0 5    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0 6    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           state NEW tcp dpt:22 7    REJECT     all  --  0.0.0.0/0    0.0.0.0/0           reject-with icmp-host-prohibited [root@ServerSuit ~]# iptables -I INPUT 6 -s 1.1.1.1 -p tcp --dport 22 -j REJECT [root@ServerSuit ~]# iptables -nL INPUT --line-numbers Chain INPUT (policy ACCEPT) num  target     prot opt source       destination 1    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp dpt:80 2    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           tcp dpt:443 3    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0           state RELATED,ESTABLISHED 4    ACCEPT     icmp --  0.0.0.0/0    0.0.0.0/0 5    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0 6    REJECT     tcp  --  1.1.1.1      0.0.0.0/0           tcp dpt:22 reject-with icmp-port-unreachable 7    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0           state NEW tcp dpt:22 8    REJECT     all  --  0.0.0.0/0    0.0.0.0/0           reject-with icmp-host-prohibited

Addressing Cloud Computing Security Issues

For a while now I have run my own server and on it I have been running the very cool ConfigServer Security and Firewall to protect my server against nasty people wishing to do it harm. When you get it all installed there is a handy little tool that gives you a report on what you servers security is really like. if like me you are running Webmin then it is in System > ConfigServer Security & Firewall click the top button "Check Server Security". if you are in your bash shell its (note , you will need to pass this to an html file and then open it with a browser , or email it to yourself)

/path/to/csf/csf -m

the area that I am going to talk about now is the part that says "Check /tmp is mounted noexec,nosuid"  in my case this came back with "/tmp should be mounted as a separate filesystem with the noexec,nosuid options set". Now the easiest way to fix this is to make a small area on your Hard Disk that you can mount to be used by the temporary files. 

Ok so first you are going to need to create a backup of your fstab file. I would Strongly recommend that you back up your entire system or at least all your data. i did a snap-shot of my machine first. 

cp /etc/fstab /etc/fstab.bak

Next we will create the tempmnt partition file - This will store all your temp files in a virtual drive , this one is around 1GB

cd /var dd if=/dev/zero of=tmpMnt bs=1024 count=1048576

Ok like all drives this one will need to be formatted. (You will need to press y when asked!)

mkfs.ext3 -j /var/tmpMnt

Make a copy of the current /tmp ( you will need this later )

cp -Rp /tmp /tmp_backup

Now mount the file system that we just created

mount -o loop,noexec,nosuid,rw /var/tmpMnt /tmp

now we have mount the new virtual partition to /tmp we need to make sure it has the right permissions they are 1777

chmod 1777 /tmp

Time to put back any temporary files that we had

cp -Rp /tmp_backup/* /tmp/

Add the new mount point to the fstab file , this tells linux where to mount your virtual tmp folder in the future

echo "/var/tmpMnt /tmp ext3 loop,rw,noexec,nosuid,nodev 0 0" >> /etc/fstab

Cool and now you have your /tmp folder running with noexec ( This means don't run binary applications ) and nosuid ( This means it can't su to another user or root ). However if you where to re-run the server security check you will see that it would still complain about /var/tmp so lets correct that. It would be pointless having another tmp file system for this as in linux we can created a symbolic link to link the folder /var/tmp to the new tmp file system this is done as follows

rm -rf /var/tmp/ ln -s /tmp/ /var/tmp

And there you go your system is a little more secure. I recommend that you follow the others recommendations on the list where possible. You can also set it up so that it emails you this report every so often so you can keep an eye on what's going on