Category: SysAdmin

Introduction

There is nothing more upsetting than email. It’s an old technology, and no one should use it. You know it, I know it, everyone knows it.

It’s just too bad the entire world practically revolves around email. So I’m going to help you with an issue I ran into recently. Hopefully this saves some hair-pulling.

Today, I’ll be explaining how to install the Sendmail like application Postfix in conjunction with Mailutils to allow you to send email from your web application. This particular guide will also solve the issue of your web application server not sending to an external mail server on the same domain.

The example I’ll be using will relate to an Amazon Web Service Elastic Cloud Compute (AWS EC2) instance sending mail to GSuite. I know that there are other (likely better) ways of sending mail like AWS SES (Simple Email Service), GSuite SMTP-Relay, Mailgun, or Mandrill. However, we’re going to go purist on this first try and have the Application Server do the entire job.

Server Setup and Installing Mailutils & Postfix

I’ll be removing Sendmail as Postfix will be replacing it. You can run sudo apt purge sendmail if you would like to remove sendmail with it’s configuration. If you only want to remove sendmail but keep its configuration run: sudo apt remove sendmail.

Next, you’ll want to specify the server hostname and change your hosts file if you haven’t yet.

sudo vim /etc/hostname

Remove the current hostname and replace with your domain. (eg. yourdomain.com)

sudo vim /etc/hosts

Change the first line in your host file to reflect the following:

127.0.0.1 yourdomain.com localhost

Once that is complete, give your instance a restart to have it reflect the changes.

Next we’ll need to make sure we have all the utilities and packages we’ll be using installed. I’m told that installing Mailutils will also install Postfix and prompt the setup steps, but in my case, it did not.

sudo apt install mailutils
sudo apt install postfix

Either mailutils will prompt you to set up postfix (a pink background fullscreen prompt) or installing postfix itself will.

You’ll want to specify the the configuration type as Internet Site. You’ll then want to set the System mail name: to yourdomain.com.

The next step will be editing your Postfix main configuration file.

sudo vim /etc/postfix/main.cf

You’ll want to change these lines:

....
mydestination = $myhostname, yourdomain.com, localhost.yourdomain.internal, localhost
....
inet_interfaces = all
....

To…

....
mydestination = 
....
inet_interfaces = loopback-only
....

Once you’re done, save your file and restart Postfix.

sudo service postfix restart

Make sure your postfix is running without errors using sudo systemctl status postfix. If you run into any errors, give your server a reboot. This is an important note. I was running into issues with port 25 having already been bound.

You can now send a test email by running:

echo "This is some email body text" | mail -s "This is a test email subject" your@email.com

Make sure to test it on your own domain, and you should be good to go!

Notes About Spam

You’ll want to make sure of a few things when sending email from multiple sources. One of the most important, and easiest spam-securing technologies available is the humble SPF record.

By adding a TXT record to your Domain Records, you can specify which servers are allowed to send mail, and what to do when something is not validated.

A simple example of this would be:

v=spf1 a mx include:_spf.example.com ip4:999.88.777.66 -all

This SPF record effectively validates A records, MX records, includes, and IP addresses to be able to send mail as an authorized domain sender. If your web application sits at your A record, you’re done. If not, add it with an ip4: tag and call it a day!

Hope you enjoyed!

I was making some changes to a web server recently that I figured I would make a super short blog tutorial about!

Changing From PHP 5.6-7.0

The same instructions will work for pretty much any version of PHP you would like to install or change from. Just change the version of PHP in the commands and you’re good to go.

Firstly, you’ll need to add the public PHP repository. Then you’ll need to update your packages. Then you need to install PHP. I’ve included both versions in case you’re switching one way or the other. It won’t matter if you have both installed, we’ll only be referencing one by the end.

sudo apt-get-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.0 php5.6 php5.6-mysql php7.0-mysql php-gettext php5.6-mbstring php-mbstring php7.0-mbstring php-xdebug libapache2-mod-php5.6 libapache2-mod-php7.0

Once everything has run its course, you can start disabling and enabling which module is being used in Apache2.

sudo a2dismod php5.6; sudo a2enmod php7.0; sudo service apache2 restart

As we all know, there are two versions of PHP that run: Apache2 and CLI. To change the CLI version fo PHP, you’ll have to run the following command.

sudo update-alternatives --set php /usr/bin/php7.0

This means when you run php -v you’ll see PHP 7.0 as your PHP CLI version.

That’s it! Super simple stuff!

Why should we install security certificates?

I’m a big proponent of protecting data and encrypting communication on the internet regardless of the source or destination. There are just some things that shouldn’t be shared, and it’s the same reason why all envelopes aren’t made entirely of transparent plastic (recycling aside).

This doesn’t just protect your “data” but the transfer of secure information like your credit card numbers and passwords. You should always be cognoscente of the sites you’re sending your data to, and whether you would be okay sharing that information with a perfect stranger.

Note: most people still like to refer to these certificates as SSL certificates. This is referring to an old and obsolete protocol that used to be used for encryption. The new version, and widely accepted standard today is the TLS encryption protocol. At the time of writing this blog, I’ve successfully installed a TLS 1.2 certificate using Certbot with a strong key exchange (ECDHE_RS with P-256), and a strong cipher (AES_128_GCM) according to the security audit in Google Chrome. (Ctrl+Shift+I > Security tab).

Things you’ll need before moving forward.

I’m going to make the assumption that you’ve taken the time to set up your Ubuntu server and install Apache on it. Specifically that you’ve properly configured your (one or more) domains in separate Virtual host files that specify the ServerName.

Let’s get encrypting!

Firstly, you’ll want to add the Certbot repository to your list of software repositories. To do this, run the following command.

sudo add-apt-repository ppa:certbot/certbot

Once that’s finished running its course, you’ll want to pull the latest version of all of your software repositories.

sudo apt-get update

Finally, you can install the Certbot client using the following command.

sudo apt-get install python-certbot-apache

Ubuntu will then take a few moments to install the required software and the client on your system. You’re finally ready to install your TLS certificate on your server.

TLS how to install it! (hah, encryption pun)

This step is actually exceedingly easy. I was very pleased at how simple it was to install, and I think you’ll really enjoy it too.

To run the Certbot installation script and install your certificate into your Virtual Host in one shot, run the following command.

sudo certbot --apache -d yourdomain.com

You can add more domains to this single certificate by specifying multiple domains. Just flag on another -d www.yourdomain.com and you’re flying!

The installation script will walk you through a few questions regarding an administrative email address, accepting their terms of service, and whether or not all traffic will be going through HTTPS or not. It’ll look something like this:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):support@[redacted]

-------------------------------------------------------------------
Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree in order to register with the ACME server at https://acme-v01.api.letsencrypt.org/directory
-------------------------------------------------------------------
(A)gree/(C)ancel: a

-------------------------------------------------------------------
Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about EFF and our work to encrypt the web, protect its users and defend digital rights.
-------------------------------------------------------------------
(Y)es/(N)o: y
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for [redacted]
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate for [redacted] to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access
-------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

-------------------------------------------------------------------
Congratulations! You have successfully enabled https://[redacted]

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=[redacted]
-------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/[redacted]/fullchain.pem. Your cert will
   expire on [redacted]. To obtain a new or tweaked version of this
   certificate in the future, simply run certbot again with the
   "certonly" option. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

They even offer up an easy way to renew your certificate when it eventually expires! Fantastic!

I have to renew this thing every few months?!

Yep! These free certificates will expire every 90 days. There are technical reasons why they would want you to renew your certificate, like renewing your encryption keys to reduce the risk of decryption. Other than that, it’s nice to automate auto renewal, so you never have to think about this again (almost).

We’ll be using our handy-dandy cron to manage our renewal.

sudo crontab -e

This will prompt you to select a text editor. Vim is my preferred, so I select 3. Add the following line at the bottom of your file to schedule your task to run every day at 4:15am.

15 4 * * * /usr/bin/certbot renew --quiet

:wq to write/quit in Vim and you’ll see a friendly little installation message.

You can opt to run the renewal script less frequently, but since it checks and only updates certificates set to expire in less than thirty days, you won’t be wasting very many precious CPU cycles.

Lastly, since we installed the certificate with the --apache flag, it’ll automatically reconfigure the Apache server every time it renews. This means less server maintenance and downtime!

Final Thoughts

Encryption used to be a very painful process, and even though cPanel and WHM made it easier than before, it was never a simple or pleasant process. I would spend at best 20 minutes to an hour waiting for email verifications, installations, and whatever else these Certificate Authorities required to get everything up and running. With Certbot and Let’s Encrypt, I was encrypting and serving an existing Apache site in less than five minutes.

Overall, I’d have to say I’m very happy with the process. I’m even happier about the cost, time, and effort savings. Now… if they’d only release a logo or badge of some sort for sites that want to promote the use of their services… How am I supposed to let other people know how awesome you are without a sticker on the back of my laptop and the bottom of my website!? 😉

– Cole

There really isn’t much that’s more important than securing your web server when launching a website. Most of your development tasks are completed (hopefully), your designs are wonderful, and your designers are excited to finally get this project off their plate. So how do we go about securing our web server after launch?

Today, I’ll be talking specifically about the Apache2 web server. The particular flavour of Linux OS that I’ll be addressing is Ubuntu 16.04 (Debian also) considering it seems to be one of the most frequently used web servers today. There are some minor file location differences with RHEL/CentOS/Fedora, though not major. There are other tutorials addressing the particulars floating around. So I won’t include them here.

I’ll be using my favourite command line text editor Vim, but feel free to replace any vim command with nano if you’re more familiar with. I’ll include some basic information to help you through using Vim if you’re unfamiliar.

Shut-out Server Specification: Hide Your Server Version and OS Details

When hitting a server display page like a directory listing or a 404, you may notice that there exists a small colophon reading your servers version, IP, and Port. You can get rid of this tidbit of revealing data by changing some code in your Apache2 configuration files.

Type sudo vim /etc/apache2/apache2.conf to edit the file.

You may quickly notice a nice little message describing that your configuration file has been split for simplicity at the top. Always read documentation!

# This is the main Apache server configuration file. It contains the
# configuration directives that give the server its instructions.
# See http://httpd.apache.org/docs/2.4/ for detailed information about
# the directives and /usr/share/doc/apache2/README.Debian about Debian specific
# hints.
#
#
# Summary of how the Apache 2 configuration works in Debian:
# The Apache 2 web server configuration in Debian is quite different to
# upstream's suggested way to configure the web server. This is because Debian's
# default Apache2 installation attempts to make adding and removing modules,
# virtual hosts, and extra configuration directives as flexible as possible, in
# order to make automating the changes and administering the server as easy as
# possible.

# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
#
# /etc/apache2/
# |-- apache2.conf
# | `-- ports.conf
# |-- mods-enabled
# | |-- *.load
# | `-- *.conf
# |-- conf-enabled
# | `-- *.conf
# `-- sites-enabled
# `-- *.conf
#
#
# * apache2.conf is the main configuration file (this file). It puts the pieces
# together by including all remaining configuration files when starting up the
# web server.
#
# * ports.conf is always included from the main configuration file. It is
# supposed to determine listening ports for incoming connections which can be
# customized anytime.
#
# * Configuration files in the mods-enabled/, conf-enabled/ and sites-enabled/
# directories contain particular configuration snippets which manage modules,
# global configuration fragments, or virtual host configurations,
# respectively.
#
# They are activated by symlinking available configuration files from their
# respective *-available/ counterparts. These should be managed by using our
# helpers a2enmod/a2dismod, a2ensite/a2dissite and a2enconf/a2disconf. See
# their respective man pages for detailed information.
#
# * The binary is called apache2. Due to the use of environment variables, in
# the default configuration, apache2 needs to be started/stopped with
# /etc/init.d/apache2 or apache2ctl. Calling /usr/bin/apache2 directly will not
# work with the default configuration.

The actual file will be located in a separate configuration folder. Press esc to enter command mode and type :q or :q! if you accidentally changed the file to exit the file in Vim.

Type sudo vim /etc/apache2/conf-enabled/security.conf to edit the file containing security features.

Look for the string ServerSignature by typing /ServerSignature in Vim command mode (press esc at any time to enter command mode). You can use the arrow keys or h,j,k, and l to move your cursor left, down, up, and right respectively in command mode.

press i to enter text edit mode. This is the mode that you will be most familiar with when typing using a keyboard. Press esc to go back into command mode.

Change the following variables as follows:

ServerSignature Off
ServerTokens Prod

Once you’re done editing the file, enter command mode (esc) and type :wq to write the file and quit. If you’ve messed up the file, feel free to :q! to forcefully quit the file and ignore all changes as :q may not do the job alone. Typing u in command mode will undo any changes you’ve recently made as well, if that suits you better.

Once you’re back in the Ubuntu command line, restart the server by typing sudo service apache2 restart

Now when you visit the same 404 or directory listing page, you won’t be seeing that server signature! Congrats on completing step one!

Disable Detailed Directories: Hide Directory Listing and Files

Your Apache2 server will want to list out all the directories and files if you don’t have a base index.html or index.php (or other if specified in Apache2) in your directory. You can hide this functionality by adding a simple line of code to your apache2.conf file.

Type sudo vim /etc/apache2/apache2.conf to edit the base configuration file and hide directories from all sites located in your web folder.

Type /Directory /var/www/html to find the code you need to edit. It should be a block that looks like this:

<Directory /var/www/html>
 AllowOverride All
</Directory>

Just below AllowOverride All you’ll want to add Options -Indexes. You should end up with this.

<Directory /var/www/html>
 AllowOverride All
 Options -Indexes
</Directory>

Once you’ve changed your code, :wq out of the file and restart your server with sudo service apache2 restart. Once you hit a directory, you’ll now find a message forbidding you from accessing that folder. Congrats on completing step 2!

Write Where We’re Willed: Web Server File Permissions

Web servers are left open to hackers when using open file permissions (777 or -rwxrwxrwx / drwxrwxrwx). It’s important to make sure that your web server is given proper permissions to access and write directories, without opening them to hackers and visitors.

One simple way to do this is to disable write and execution tags where applicable in the permissions for folders and files. Permissions use binary triplets to turn on and off permissions. First, the base ten digit is converted to binary, and those positions turn on and off file and folder features.

To change all directories within your web folder to 755 (rwxr-xr-x):

find /var/www/html -type d -exec chmod 755 {} \;

To change all files within your web folder to 644 (rw-r--r--):

find /var/ww/html -type f -exec chmod 644 {} \;

These permissions not only work well for statically built websites, but also for content management systems like Magento and WordPress.

Updating Ubuntu: Specifically Apache2

Updating your server, and specifically updating Apache2 is very important. You’ll want to make sure you’re updating regularly to make sure the most important security patches have been applied.

Firstly you’ll want to update your package information by using sudo apt-get update

If you’d simply like to install updates for Apache2, just type sudo apt-get install apache2. You should be returned a message that looks something like the following.

Reading package lists... Done
Building dependency tree
Reading state information... Done
apache2 is already the newest version (2.4.18-2ubuntu3.3).
0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded.

As you can see, I have 21 packages that are not upgraded on my server. If you’d like to update all of these packages, you can type sudo apt-get upgrade.

If you’d rather view the packages that need updating and install them one by one (using a command similar to the one for apache2), you can do so by typing sudo apt-get upgrade --dry-run or /usr/lib/update-notifier/apt-check -p for a simpler return.

Conclusion

These are only a few of the many ways you can harden your Apache2 web server. I’ll be adding to and maintaining this list as time passes, but there are a few extra things you’ll want to be sure to check out.

HTTPS and SSL Certificates

You’ll want to make sure that you’re installing SSL Certificates on all of your sites. Whether they’re extended validation or self signed, this can help keep traffic encrypted, and your users feeling safe. There are many other reasons to install SSL, a big reason is that Google promotes sites that use it more than ones that don’t (for obvious reasons). With tools like Lets Encrypt there really is no reason not to install a cert on all of your servers.

Firewalls Firewalls Firewalls

Personally, I like to host on AWS where their console and security features allow for very strict access to your cloud network infrastructure. If you don’t have access to such strong security measures on your own personal server, you’ll want to ensure that you take advantage of the firewall tools available in Ubuntu.

If you have any questions, make sure you comment below!

Cheers,
Cole Speelman

This will be a relatively short informative blog regarding how to setup and secure an installation of MySQL on Ubuntu.

MySQL Server Installation

Firstly, update your package library and install your MySQL server.

sudo apt-get update
sudo apt-get install mysql-server

You’ll be prompted to create a root password during the installation. Make sure it’s a complicated password that you’ll remember, because you’ll be needing it.

MySQL Server Configuration

You’ll want to be sure to harden security on your MySQL installation by running the security script.

sudo mysql_secure_installation

This will prompt you to enter your root user password that you created during installation.

Firstly, the setup will ask if you would like to install a VALIDATE PASSWORD PLUGIN that can test passwords and improve security. If you’re the only one administering databases and are diligent about using great passwords, you opt-out.

Second, it will ask if you’d like to change the root password. If you’re having second thoughts about your password strength, you can change it now.

Third, it will ask if you would like to remove anonymous users. I typically use applications like WordPress and Magento, so I always have database users created out of the gate. I opted to remove anonymous users, but you may decide to run this script again before launching your site and remove them at a later date.

Fourth, it will ask if you would like to disallow root user remote access. I strongly suggest enabling this, especially considering that we’ll have phpMyAdmin installed shortly, removing any need for this.

The last two questions are to remove the test database, and to reload the privilege table, both of which I answered yes, as I won’t be needing the test database, and the privileges are important.

Server Status

To check the status of MySQL server you can run the sudo service mysql status command. If the server is not running, you can start it with sudo service mysql restart or sudo service mysql start.

Reset MySQL Root Password

You may find yourself in the situation that you have forgotten your root password. This recently happened to me after I jumped into a server that I had not maintained in quite some time (it was development, don’t worry).

The first step to resetting your password is to gain access to the terminal (ssh is typically what I use). Once you’re in, you’ll want to stop the MySQL service.

sudo service mysql stop

Once you’ve stopped running your server, you’ll need to prep the next command by creating a folder for it to access.

sudo mkdir /var/run/mysqld
sudo chown mysql: /var/run/mysqld

You can start the server with a few options that I’ll explain.

sudo mysqld_safe --skip-grant-tables --skip-networking &

The --skip-grant-tables flag turns off the need for authentication, and the --skip-networking flag turns off the ability to access the database remotely (important when authentication is disabled).

Once you’ve run the server, enter the mysql command line tool, and change the password.

sudo mysql

For MySQL 5.7.6 and later:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourNewPassword';

For MySQL 5.7.5 and earlier:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('YourNewPassword');

Then you’ll need to reboot your MySQL server.

#Shut down MySQL
sudo mysqladmin -S /var/run/mysqld/mysqld.sock shutdown

#Start the MySQL service normally.
sudo service mysql start

From there on out, you can use whatever you set as YourNewPassword to access root functionality.

Notes for PHPMyAdmin

If you’ve decided to do your database administration through PHPMyAdmin, I would strongly suggest disallowing any unauthorized access to it. I’ve seen people block access with an Apache password option, but this doesn’t really help as much as you would think.

Blocking all access except your own is quite easy if you have a static IP address. If you don’t have a static IP address, you can contact your ISP and let them know that you would like one. If a static IP address isn’t in the books for you for one reason or another, you could always check your IP address and change the IP address in the configuration file each time you need access. Which shouldn’t be terribly often.

Either way, here’s how you do it:

sudo vim /etc/apache2/conf-enabled/phpmyadmin.conf

and add these lines to your code:

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
 Options SymLinksIfOwnerMatch
 DirectoryIndex index.php

 # Add Your IP instead of ##.##.##.##
 Order Allow,Deny
 Allow from ##.##.##.## 

This will effectively block all access except for your IP address. It doesn’t get much more secure than this for PHPMyAdmin.

Conclusion

MySQL is fun. Don’t get bogged down with the basics! With this basic installation information, you’ll be well on your way to working with databases and enjoying all that relational databases have to offer!

Cheers,
Cole Speelman