aboutsecurity

Security concept on the workstation

The workstation is computer with a fixed IP adress. That means it is, in principle, possible to adress it through the local network and through the world wide web. This feature allows us to use it as a server for data storage, embedding it in a cluster or host websites.

However, the university constrains this acces from the internet for security reasons.

The issue is very complex and cannot be covered here in depth. Here, just a couple of things are important to know because we are responsible for the server security.

Types of networks

First, each computer has an IP adress of 4 bytes length ($ 2^8 $, which means each byte ranges from 0 to 255). In most cases today those IP adresses are assigned to the computer dynamically (via a thing called DNS server). But at the university, each computer gets a fixed IP adress.

Imagine the internet is organised hierarchically, comparable to the computers resident country, city, street and house number. So the University of Montpellier II has a fixed IP adress area, starting with 162.38.x.x . Within the university, there is a local area network for each institute or part of an institute. Our floor is assigned the area 162.38.184.x . The final number is differentiating the individual computers. The Workstation's adress is 162.38.184.118.

A special IP range within the university is assigned to connections build via VPN. This connection protocol allows members of the University to connect into the network from everywhere in the world, to access all the scholarly services where access management is working through the IP adress, such as libraries, journals etc.. This is quite useful to manage access to our own ressources, as you will see below.

Types of access

There are different protocolls used to access a computer through the network, for example TCP/IP, SSH or HTTP. These usually listen to calls on a particular 'port'.

These protocolls serve different purposes, they transmit different kinds of information. Most important for our use are:

• FTP (File Transfer Protocol), port 20 & 21: It is used to view and transfer files on the server.
• SSH (Secure Shell), port 22: It is used to build a trustworthy command tunnel to the server, which allows you to run services and programms on the server.
• HTTP (Hypertext Transfer Protocol), port 80: It is used to transmit websites.
• HTTPS (HTTP Secure), port 443: Same as HTTP, but using encrypted transmission.

Other examples of protocols are POP3, IMAP and SMTP (all used for receiving and sending e-mails). Ports are defined as 16 bit, so they can take numbers between 0 and 65535.

Security settings

The university can set restrictions about from which network layers the ports of the computers in the networks are accessible. For instance by default they say, HTTP is only possible between computers of the same group.

Those restrictions can be lifted by request. The IT desk of the ISEM (Yannick Frontera) is the right adress for that. But it will need to be justified and the full liability will be with us.

Currently, the port 80 of the workstation for http connections is open to the local network of the equipe (IP range 162.38.184.0 - 162.38.184.255) as well as for the VPN (IP range 162.38.106.0 -- 162.38.106.255). This allows accessing the wiki websites from within those IP ranges.

VPN

We requested that the access to the HTTP webserver (port 80) on the workstation will be allowed from the VPN IP range. This allows visiting the labdocs and gitlist from home after building a VPN connection.

SSH via private/public key only

SSH access is allowed from the entire internet, which is useful to allow collaborators to share git repositories or to access the computational power of the workstation.

Usually, any user can log in to the workstation via SSH (port 22) and his specific user password. Since this log-in can be tried many times, it is vulnerable to so called brute-force attacks. A hacker just needs to try repeatedly user names and passwords on the IP adress to get access to the workstation.

That is why the log-in via password is disabled on the workstation and only connections via SSH are allowed ^1.

It can be enabled and disabled by modifying the SSH config file. If logged in to the workstation, type (requiring root rights):

sudo vi /etc/ssh/sshd_config

This opens the file with the command line editor 'vi' (a tricky thing, this one). Here you will find a line

PasswordAuthentication no

Outcommenting this line or replacing no with yes will enable the password login again. Then you can exit the file (typing 'ZZ' in vi) and restart the SSH server by typing

sudo service ssh reload

Check authlog of ssh

Users authenticate to the workstation using ssh protocol. The workstation is visible to the public under its fix IP. To check that no irregular activities are happening or brute force attacks are undertaken, it is recommended to check the log regularly.

sudo less /var/log/auth.log

this returns a list of all attempted logins and more

Typically you would see activities of CRON jobs, which is normal. But it also is likely you see break in attempts

lz.gs.dynamic.163data.com.cn [61.178.42.254] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar  1 14:48:34 kefi118 sshd[14689]: Invalid user test from 61.178.42.254
Mar  1 14:48:34 kefi118 sshd[14689]: input_userauth_request: invalid user test [preauth]

or

Mar  1 16:52:03 kefi118 sshd[11046]: Invalid user shoutcast from 81.92.149.33
Mar  1 16:52:03 kefi118 sshd[11046]: input_userauth_request: invalid user shoutcast [preauth]
Mar  1 16:52:03 kefi118 sshd[11046]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:03 kefi118 sshd[11050]: Invalid user shoutcast from 81.92.149.33
Mar  1 16:52:03 kefi118 sshd[11050]: input_userauth_request: invalid user shoutcast [preauth]
Mar  1 16:52:03 kefi118 sshd[11050]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:03 kefi118 sshd[11058]: Invalid user tamara from 81.92.149.33
Mar  1 16:52:03 kefi118 sshd[11058]: input_userauth_request: invalid user tamara [preauth]
Mar  1 16:52:03 kefi118 sshd[11058]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:04 kefi118 sshd[11061]: Invalid user tamara from 81.92.149.33
Mar  1 16:52:04 kefi118 sshd[11061]: input_userauth_request: invalid user tamara [preauth]
Mar  1 16:52:04 kefi118 sshd[11061]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:04 kefi118 sshd[11070]: Invalid user postgr3s from 81.92.149.33
Mar  1 16:52:04 kefi118 sshd[11070]: input_userauth_request: invalid user postgr3s [preauth]
Mar  1 16:52:04 kefi118 sshd[11070]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:05 kefi118 sshd[11073]: Invalid user monica from 81.92.149.33
Mar  1 16:52:05 kefi118 sshd[11073]: input_userauth_request: invalid user monica [preauth]
Mar  1 16:52:05 kefi118 sshd[11073]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:05 kefi118 sshd[11081]: Invalid user monica from 81.92.149.33
Mar  1 16:52:05 kefi118 sshd[11081]: input_userauth_request: invalid user monica [preauth]
Mar  1 16:52:05 kefi118 sshd[11081]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:06 kefi118 sshd[11084]: Invalid user svn from 81.92.149.33
Mar  1 16:52:06 kefi118 sshd[11084]: input_userauth_request: invalid user svn [preauth]
Mar  1 16:52:06 kefi118 sshd[11084]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:06 kefi118 sshd[11088]: Invalid user addicted from 81.92.149.33
Mar  1 16:52:06 kefi118 sshd[11088]: input_userauth_request: invalid user addicted [preauth]
Mar  1 16:52:06 kefi118 sshd[11088]: Received disconnect from 81.92.149.33: 11: Bye Bye [preauth]
Mar  1 16:52:06 kefi118 sshd[11096]: Invalid user redirecte from 81.92.149.33

Those repeat multiple times a second, trying different configurations like user names or ports. The calls are coming from regularly changing IPs which indicates that they are executed by computers of a botnet. A classical brute-force attack. But there is nothing to worry about. Since we disabled password authentication, such an attempt is futile. Still, it completely spams our authlog and obscures all other activity that are going on at the doorstep of the workstation.

Thus, we want to block those attacks by using a firewall and a little tool called 'fail2ban'.

firewall

Ubuntu has a built in firewall that is configured on the workstation to allow ssh connections on port 22, disable outgoing ssh calls, etc.

See the status of the firewall by calling

sudo ufw status

To configure it, we set

$ sudo ufw allow ssh/tcp
$ sudo ufw allow 20
$ sudo ufw allow 21
$ sudo ufw allow 80/tcp
$ sudo ufw allow www
$ sudo ufw logging on
$ sudo ufw enable
$ sudo ufw status

This enables access on ports 20 (ssh) and 80 (http, for wiki and internal websites). It activates logging and activates the firewall. In case of a brute-force attack, it is easy to add the IP adress of the attacking computer to the firewalls blacklist

sudo ufw deny proto tcp from 61.178.42.254 to any port 22

Just in case, this is how to disable the firewall:

$ sudo ufw disable

Resources: How to Geek: How to Configure Ubuntu Firewall , Ubuntu Wiki: Uncomplicated Firewall, Ubuntu Server guide: Firewall

fail2ban

Since the bots will imediately switch to another IP address once they are blocked, adding IPs to the blacklist manually is not a solution. We are going to use an automated tool that identifies malicius login attempts and adds them to a blacklist, called fail2ban.

Install is easy:

$ sudo apt-get install fail2ban 

Then make a copy of the default configuration file, that fail2ban is going to use

$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

and modify the settings

$ sudo nano /etc/fail2ban/jail.local

The nano editor shows you the defaults

[DEFAULT]

# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1/8
bantime  = 600
maxretry = 3

Here, it is important to whitelist our own IPs and/or the IP range of the university local ISEM (162.38.184.0/8) and VPN (162.38.106.0/8) network. Also we raise the bantime, i.e. the time an IP will be blocked, to one hour. The maximal number of retries before an IP will be banned remains 3, but it could even be set to 1, since we only authenticate by private/public key pair, which will never fail.

ignoreip = 127.0.0.1/8 162.38.184.88 162.38.184.0/8 162.38.106.0/8
bantime  = 3600
maxretry = 3

Now just restart fail2ban and we are done.

sudo service fail2ban restart

This should help keeping our authlog clean.

Resources: digitalocean howto: fail2ban, fail2ban website

Troubleshooting

If your ssh connection still does not work without promting a password or with the response

Permission denied (publickey).

then there is something wrong. Check the following:

• the public key on the workstation matches the public key on your local computer.
• the users .ssh directory has the right permissions. It must be in mode 700. To check, type ls -l -a in your home directory, and look for .ssh: it should have rwx------! the owner must be the user.
• same for the users 'authorized_keys' file.

If positive, the ssh server has trouble reading your authorized_keys file without you being logged in with your account. This would be the case if your home directory is encrypted (as it is in Sonias case).

Solution: (from this source)

If you have an encrypted home directory, SSH cannot access your authorized_keys file because it is inside your encrypted home directory and won't be available until after you are authenticated. Therefore, SSH will default to password authentication.

To solve this, create a folder outside your home named /etc/ssh/<username> (replace <username> with your actual username). This directory should have 755 permissions and be owned by the user. Move the 'authorized_keys' file into it. The authorized_keys file should have 644 permissions and be owned by the user.

Then edit your /etc/ssh/sshd_config and add:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Finally, restart ssh with:

sudo service ssh restart

The next time you connect with SSH you should not have to enter your password.

webserver constraints

Read here how to set constraints for the webserver!