Why have an encrypted partition

It is a modern day habit to run much of your life through a computer today. This means online banking, social media, personal photos, etc. Much of this leave data stored on the hard drive of the machine you have used accessable to anyone with a little computer know how. In the wrong hands this can be very valuble information. s

Unfortunately modern operating systems do not encrypt data by default. The password login screen is just that a login screen to a running computer. It lulls people into thinking their data is safe behind their password. This a false sense of security however as the data can be access using a simple linux live disk.

The solution to this is to encrypt your hard drive. With Debian and clones this is very simply done when setting up the computer.

Automatic Mounting

Mounting an encrypted partition automatically can be very useful when needing to mount many different drives that use encryption but only want to enter one pass-phrase.

The first step in doing this is to create a random keyfile to be used to as the decryption key. This can then be stored securely on one encrypted drive that the user enters the pass-phrase for at boot and decrypts the other drives. An inportant security step is to ensure only root can read the file. This prevent mistakens change to the file.

1
2

sudo dd if=/dev/urandom of=/root/keyfile bs=1024 count=4
sudo chmod 0400 /root/keyfile

The next step is to add the key file to the luks container. This will require a current pass-phrase keyfile for the container. Once successful it will return ‘OK.’

1

sudo cryptsetup luksAddKey  /dev/sdX /root/keyfile

The next step is to automatically mount the encrypted drive. The first bit sets up the drive to be automatically decrypted and mapped to a device mapper. The second is an addition to fstab that mounts the mapper to a file system mount point. Edit the file /etc/crypttab and add a new entry like the following: {Name of mapper} {disk/block device mapper} {none for pass-phrase or keyfile location} {container type - generally luks}

1

storage    /dev/md0  /root/keyfile  luks

Lastly add a new line to /etc/fstab that will mount the created mapper.

1

/dev/mapper/<mappername> <mountlocation>  <file system type - ext4> defaults 0  0

This will automatically mount the raid device. Note the encryption of the system is only as secure as the ability of people to access the keyfile. I recommend using a linux system with encrypted OS disk which requires a pass-phrase so that the keyfile is not stored in plain text ever.

Install update manager

Firstly run

1

sudo apt-get install update-manager

This will install the manager that will take care of updating the system.

If upgrading from a lts (long term support) version to a non lts version edit /etc/update-manager/release-upgrades and the value of Prompt= from lts to normal first.

Do upgrade

The start the upgrade process by executing

1

sudo do-release-upgrade

It will then ask you if you want to proceed. Pressing y it then opens a non standard ssh port (1022 in mycase) if updating remotely to which you can connect if there is an issue and potentially fix the system.

Create an SSL certificate

To create a SSL certificate run the following command and input the requested information.

1

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt

Edit config and enable HTTPS for Apache

Edit the default ssl config site to at least contain the following

/etc/apache/sites-availiable/default-ssl

1
2
3
4
5

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile     /etc/ssl/localcerts/apache.crt
    SSLCertificateKeyFile  /etc/ssl/localcerts/apache.key
</VirtualHost>

The site then needs to be enabled along with the ssl capabilities of Apache. The server then needs to be reloaded but I prefer to restart Apache.

1
2
3

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo service apache2 restart

Force Wordpress to use SSL for Admin logins

To get Wordpress to use SSL just for admin sessions and logging in is simple. It is achieved by adding a single line to the wp-config.php file but before the stated line like below. Beware once this option is set connections will use HTTPS port 443 so ensure Apache is configured to listen on this port as well.

/usr/share/wordpress/wp-config.php (on debian systems)

1
2
3

define('FORCE_SSL_ADMIN', true);
require_once(ABSPATH . 'wp-settings.php');
?>

How to force use of HTTPS in Apache using htaccess

First ensure that in the virtual server allows the use of htaccess files to be read and acted upon. This is achieve by changing the allowoveride setting in the virtual server config from None to All.

1
2
3
4
5
6

<Directory /var/www >
 Options Indexes FollowSymLinks MultiViews
 AllowOverride All
 Order allow,deny
 allow from all
</Directory>

Create a .htaccess file in the directory you would like to force the use of HTTPS in.

1
2
3

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https:  %{HTTP_HOST}%{REQUEST_URI}

The more often you find yourself using ssh you quickly tire of having to write long commands specifying identity key files and per host configurations. Using bash aliases is one solution but a nicer solution is to use a personal configuration file.

Global SSH client configuration file

/etc/ssh/ssh_config - This file must be world readable but not writeable. It contains the default settings for all ssh users.

User-specific SSH client configuration files

~/.ssh config - This file is the user’s own configuration file. It overrides any defaults or the settings in the global client configuration file. If you have not already used ssh or setup a local ssh directory do so by issuing

1
2

mkdir -p ~/.ssh
chmod 0700 ~/.ssh

Options for your configuration file

Like all other Linux configuration files lines starting with a hash or that are empty are ignored.

• Host - This is the name of the host s you specify after ‘ssh’ on the command line. It specifies to which hosts the following configuration options applies to. The section ends with a new Host section or at the end of the file. A wild card * can be used to provide global defaults for all hosts.
• HostName - This is where the server name or ip address is specified.
• User - This is the user name to log in with for the SSH connection.
• IdentityFile - This option specifies an encryption key file from which the users encryption key is read and used to verify the user to the server. The default is ~ .ssh id_dsa, ~ .ssh id_ecdsa and ~ .ssh id_rsa.
• UserKnownHostsFile - This option allows you to specify a hosts file to verify the servers key again already known servers.
• ProxyCommand - Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with the user’s shell. In the command string, any occurrence of %h will be substituted by the host name to connect, %p by the port, and %r by the remote user name. The command can be basically anything, and should read from its standard input and write to its standard output. This directive is useful in conjunction with and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.1.0.253
• ProxyCommand usr bin nc -X connect -x 192.1.0.253:3128 %h %p
• LocalForward - Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be [bind_address]:port and the second argument must be host:port.
• Port - Specifies the port number to connect on if the server is not using the default of 22.
• ServerAliveInterval - Sets a timeout interval in seconds after which if no data has been received from the server, a message is sent through the encrypted channel to request a response from the server.
• ServerAliveCountMax - Sets the number of server alive messages which may be sent without receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session.

Running a website it is often useful to password protect areas of your site. If the area is not using php and is a simple site using html links to files that can be downloaded using https then a .htaccess file is the way to go.

Setup

First off start by putting a file titled “.htaccess” into the directory you would like restricted. It should contain the following lines

1
2
3
4
5

.htaccess
AuthType Basic
AuthName "Authorisation Required."
AuthUserFile  /etc/apache2/htpasswd
Require valid-user

Next create a password file to store the credential of the people you want to allow into said area. You create the file by issuing the following with your first username. The -c option creates a new file.

1

sudo htpasswd -c  /etc/apache2/htpasswd username

It will ask you to enter a password and to it repeat to ensure you typed it correctly. Subsequent users can be added by the same command but used without the -c flag. Using the -c flag creates or overwrites the file. Next we need to ensure that only the Apache server can read the file. (assumes that www-data is the Apache server group)

1
2

sudo chown :www-data /etc/apache2/htpasswd
sudo chmod 740  /etc/apache2/htpasswd

Lastly Apache needs to be told that the .htaccess files in directories should be acted upon. This is done by editing the file /etc/apache2/sites- available/default. Where it says AllowOverride None change it to AllowOverride All. Lastly reload Apache and it will start asking you for a password when entering that directory.

1

sudo service apache2 reload

Note: unless the site is using https the passwords will be sent in clear text.

SSH is a way of remotely logging into a computer securely. It was invented to replace telnet which transmitted passwords in plain text to the computer and so could easily be snooped.

Installation

The ssh client is installed by default on most Linux distributions. On Linux Debian based machines the server can be installed by issuing

1

sudo apt-get install openssh-server

Configuration and options

The SSH server is configured by the text file /etc/ssh/sshd_config. Important options are

• Protocol 2 . This is used to ensure that only the newer protocol two is used as the first one has attack vectors that completely compromise it’s use.
• Port [number]. This option allows you to change the port that the server will listen on. It by default listens to port 22
• PermitRootLogin no. This option is highly recommend as logging root is taboo due to the accidental damage that can be done. Not just that however logging in as a lower level user and using the sudo command allows accountability.
• PermitEmptyPassword no. This tells the server to not allow login attempts that contain an empty password. This is important to help with the enforcement of a password policy. It is also EXTREMELY bad to allow any account to have no password at all.
• X11Forwarding [yes|no]. This option allows the X windowing graphical display appications (not apps!) to be forwarded to the client computer and displayed using an X window server. This is very straight forward on Linux machine which have X installed by default.
• TCPKeepAlive yes. This option will keep the SSH connection open during periods of no use.
• AllowUsers [list of users]. This option allows the server admin to grant SSH login access ONLY to the listed users. Conversely DenyUsers allows all users to login but deny those listed.
• AllowGroups [list of groups]. If restricted SSH access is needed and there are many user accounts. It is easier to use a group policy. Creating a group sshaccess and adding users to this group that need SSH usage. AlternativelyDenyGroups could be used.

After making changes to the configuration file you need to restart the ssh deamon.

1

 sudo service ssh restart