1) What security and precautions do I need to set up before I let the public access my site? I do not want to start forwarding my domain there until it is ready to go.

If you are using the 16.04 based WordPress image it comes pre-configured with fail2ban for added protection. You may wish to also set up automatic updates on your droplet. Additionally to further protect your your droplet we’ve outlined a few basic steps here.

2) Wordpress has a plugin called ContactForm 7 which will email me when someone presses send. Do I need to set up any mail servers or anything?

For basic sending you may want to install the postfix MTA with:

apt-get update
apt-get install postfix

You may also wish to set up an SPF record for security and to help ensure delivery of your messages.

Alternatively you could also install one of the many SMTP plugins for WordPress which will replace the PHP mail() command inside WP so it will instead send messages over SMTP. This would allow you to send directly via your gmail or other mail account and save some trouble.

Here are a few options:

• https://wordpress.org/plugins/easy-wp-smtp/
• https://wordpress.org/plugins/wp-mail-smtp/
• https://wordpress.org/plugins/gmail-smtp/

3) Can I access this via FTP?

By default none of our images include FTP as it is an inherently insecure protocol. Instead, every droplet is accessible via SFTP which operates over SSH with an encrypted connection. Most modern FTP clients support SFTP but if you need one, I recommend Filezilla. You will connect to port 22 with your root user (or another user if you’ve created one). If you use root, you will start out in the /root directory and will have to change up a directory .. to reach the root of the drive. Your web root will be in /var/www/html

4) How do I set daily backups of my droplet? It would be good to one week of these, then on the 7th day delete the longest one and start again. If that is possible?

We have a weekly backup service available that you can enable on any droplet. This creates a backup of your entire filesystem at a cost of 20% of your droplet’s cost. If you require daily backups of your site you can also look into available WordPress plugins designed to do this.

5) Are there any things that you guys would suggest for this droplet etc.. ?

Most of our suggestions are above. The key is to make sure that your droplet and WordPress stay up to date and to be careful about what plugins and themes you install as poorly coded ones can often have security vulnerabilities.

If you run into more questions, let us know 😃

@webydevyguy

When it comes to WordPress, the best course of action to maintain a secure installation is staying up to date. The vast majority of compromises take place due to either WordPress or a WordPress Plugin being out of date, while others take place because the web hosting provider or administrator for the web server didn’t keep their web server updated.

When it comes to the web server side, you’ll need to make sure Apache, MySQL and PHP are kept up to date. For the most part, this is relatively easy if they were installed using a Package Manager. Since you’re using Ubuntu, that package manager will be aptitude. The primary command you’ll be using is going to be apt-get as it covers updating, upgrading, installing, removing, and purging. Just keep in mind that before upgrading, you really want to make a backup of core configuration files (i.e. server configuration, PHP configuration, etc) as this may be overwritten when an upgrade is performed.

Also on the server side, you want to make sure permissions are correct for all files and directories. In far too many cases I’ve seen directories and files owned by the root and you really don’t want that. You should always separate ownership, even if you’re only hosting one domain on the droplet, as you don’t want the public executing files that are owned by the root user, period.

As for login, such as SSH and SFTP, ideally you should use root to do your initial setup and then create a sudo user (with an SSH key) to login from there on. You would then escalate that sudo users permissions to execute commands from the CLI instead of using the root user. You could also use that same sudo user to login to SFTP, though ultimately, I recommend complete separation. Run as root at first, create a sudo user to run commands and another user to login to SFTP. Yes, you’re managing 3 users instead of one, though that’s going to be the more secure route (pending your passwords are all secure).

The last part about passwords brings me to one very important security measure and that’s simply using secure passwords.

If you’re using dictionary words, names and/or dates, anything of significance, anything that can be pulled from the web (i.e. social profiles) or something easily guessable, stop.

Passwords should always be as random as possible and ideally at least 12-16 characters long with an alphanumeric mix combined with special symbols. My preference is 32-64 characters.

This is really just touching on some of the basics. Going much further and it may be a little bit overkill for a personal website, but when it comes to a website that is storing user data, handling payments, and/or related storage, the goal is security.

@webydevyguy

Always happy to help!

When using apt-get, you’ll mainly be working with a few commands.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install
sudo apt-get purge
sudo apt-get remove
sudo apt-get autoremove

apt-get update basically synchronizes your server with upstream repositories which ensures that you’re able to install the latest package versions. It won’t make any major changes or effect existing software installations.

apt-get upgrade will automatically upgrade all existing software packages where possible. This is where you really want to make backups of configuration prior to execution. A snapshot will work as a method of backup, though you really would benefit more from knowing what to backup.

apt-get install is what you’ll use to install software packages, such as additional PHP modules, or similar. Keeping your web server as lean as possible is the goal, so only install what you absolutely need for your setup.

apt-get remove is how you’ll delete a package, or remove it from your server. It doesn’t always remove configuration files when ran, so that’s what the next function is for.

apt-get purge is for when you absolutely want to remove most all traces of a piece of software.

sudo apt-get autoremove removes packages that are installed but not currently being used by any existing software that has been installed. This is more of a cleanup utility command and its safe to run without effecting current installations or configuration.

Backups

When it comes to creating backups, a snapshot will work as one method as it will store the current state of the machine to an image that can be restored at a later date. One thing to keep in mind is that if you simply restore from a snapshot, it will overwrite everything on your server (including website data, thus you will lose any work you’ve done from the time you took the snapshot to the time you restore it).

The best course of action is to know what files you need to keep copies of and which ones you don’t.

For example, if you run apt-get upgrade and NGINX is on the list, you’d want to make a backup of the core NGINX directory which is /etc/nginx.

If PHP is on the list, you should make a backup of /etc/php. Exact version data for PHP will be below this folder, but it’s safe to backup the entire directory.

Files, Permissions, etc

When you change over to a directory using cd, you can run a list command to view directory info. That info will tell you the current CHMOD as well as what user & group owns the file.

You DO NOT want to randomly go around changing file permissions unless you know what you are doing as many files require root to be the owner.

You only want to change ownership of files that you will be allowing the public to access. In most all cases, this will be files in your users /home/ directory.

For example, we can create a new user directory by running:

sudo mkdir -p /home/example

Then we can create a new user:

sudo useradd -d /home/example example

The above command creates a new user named example, a new group named example and sets the home directory for the user to /home/example.

We would then proceed to create any additional directories that are needed for the account. For me I normally create a few more structures, such as:

sudo mkdir -p /home/example/htdocs/{public,private,logs}

The {public,private,logs} allows me to create multiple directories below htdocs using expansion, so we’ll end up with:

/home/example/htdocs/public
/home/example/htdocs/private
/home/example/htdocs/logs

At this point, all of these directories are owned by root, so we now need to change that by changing the ownership. This is done by using chown (ch = change, own = ownership).

chown -R example:example /home/example

The above command will recursively change ownership on /home/example and all of the directories we just created above.

Of course, this is just the basics. We can get even more detailed and even more in-depth, though this gives you an idea of how we go about getting things setup. It’s all one step at a time.