WordPress on AWS EC2 – part 4

How to make your instance more secure?

This post is obviously not complete security guide and it’s not meant to be. However I want to talk about some basics which I think are minimum in subject of securing our Linux. I must emphasize that you have complete control of your instance and it’s your responsibility to take care about security of your data and your site users. I definitely encourage to constantly learn about server administration.


One of the most important things are regular updates of the system and other installed software. Unfortunately vulnerabilities happened everywhere (famous example of vulnerability in OpenSSL library from 2014) so we should install every security updates as fast as possible. Before we continue let’s update our system.

The first step will be following command:

sudo apt-get update

In this way we ensure that our system “knows” about all the updates available but nothing will be installed yet.

Next we can do this:

sudo apt-get upgrade

or this:

sudo apt-get dist-upgrade

There is significant difference between those two. In first case only packages that were already installed will be updated. However common practice is that one package depends on others. If new version of installed software depends on package which was not required previously and this package is not available in system, update will fail. All information about the problems will be printed to the console.

In second case dependencies are resolved automatically and some packages can be deleted or new packages can be installed. Now it really doesn’t matter because we just launch our instance and we don’t using it for any purpose yet. However when we start web server, database and our site will be made public, we won’t want something stop working because of update. It doesn’t mean of course that we shouldn’t update our system. It only means that we always need to know what we are doing and why. We probably should consider launching stage environment and check any modifications there first. In AWS ecosystem it’s really easy to duplicate EC2 instance.

Some of you probably notice that though installation of all updates, OpenSSL library which I mention remains in version 1.0.1f, which is theoretically vulnerable to HeartBleed attack. In fact it’s not true. This version was patched by Ubuntu maintainers the same day which vulnerability was disclosed. More information here.

Now we should reboot our instance.

sudo reboot

When you run this command your connection will be interrupted. Wait minute or two and try to connect again.

Change the default SSH port

It’s worth to consider change the default SSH port from 22 to some other number grater than 1023. Many bots which are used to automatic attacks search for open SSH port, but they limit themselves to default port. It of course won’t stop all intrusion attempts but can help reduce the number of them. We can change port in SSH configuration file. We must edit it as root so we run command:

sudo nano /etc/ssh/sshd_config

Of course you can use your favorite text editor instead of nano. 🙂
Lets find following line in file

Port 22

and change the value to something else, for example:

Port 56321


Now save changes (in nano ctrl+O and confirm hitting enter) and exit editor (in nano ctrl+X). We should restart SSH service to reload configuration:

sudo service ssh restart

Our current connection should not be interrupted but from now on every new connection to our instance must be on port which we put to config file. As you remember we define some security rules in our EC2 dashboard so we need to go back there and open up this port.

In group “Network & Security” we need to find tab called “Security Groups” and then right click group which our instance belongs to. From menu choose “Edit inbound rules”. Now in place of SSH we select “Custom TCP Rule” and enter the new port number. Remember to save the changes.


Powinno być już możliwe nawiązanie nowego połączenia. Jeśli łączymy się z konsoli musimy dodać parametr “-p” i dopisać po nim numer portu, a więc w moim przypadku będzie to:

Now we should be able to start new connection. If you’re using console you should add “-p” followed by port number. In my case it will be:

ssh -i ~/.ssh/test1-keys.pem ubuntu@ -p 56321

If you’re connecting by putty, find on list of saved sessions your instance and load settings. Now you should change port number and save your session again.



After this part our system is up to date and SSH works on different than default port number. As I mention it’s not guarantee that you are 100% secure. I recommend that you read about some tools which can help you in process of hardening your system. In next part we’ll install software which is essential to run our virtual machine as web server.

Part 1
Part 2
Part 3
Part 5
Part 6
Part 7
Part 8

WordPress on AWS EC2 – part 3

How to connect to my instance

In previous post we launch our virtual machine so now is the time to log in via SSH. In this part we attach Elastic IP which will be our public IP address and we connect to our instance using previously downloaded private key.

How to attach Elastic IP

You can attach one public IP to any single instance without additional costs. This IP will be linked with our AWS account so we can easily attach and detach it from one instance to another as we need. One virtual machine can also have more than one public IP address if we need this kind of configuration for some reason. This address is reserved for us as long as we won’t release it. Theoretically our instance have public address attached in time of launching but it’s randomly picked so when we stop our machine it will be released and new address will be attached on resume.

In our case we want that our address will persist forever and ever and if we need to scale up in the future we probably want to have possibility of transfer this IP address to another machine. Fortunately this process is very easy. 🙂

Let’s find Elastic IPs tab in our EC2 dashboard. There we will click Allocate New Address and confirm.


Next let’s right click on IP and choose action Associate Address. We can do the same thing from Actions dropdown. Click on input called Instance should revealed list of our instances where we can choose that we are recently created. We can also filter this list by instance ID or Name tag. Select your instance and then click Associate button.


If you check your list of instances you should see that this new address was really attached to your machine.

Connect through SSH

Linux / Mac

If you work on Linux or Mac, just add downloaded private key to your .ssh directory i home directory:

mv /path/to/your/key.pem ~/.ssh

If you doesn’t have this folder, create it:

mkdir ~/.ssh

Private key should have very restrictive settings of permissions. Let’s set 400 then (available only for reading, only for file owner).

chmod 400 ~/.ssh/your_key.pem

Now you should be able to connect to your instance. Default user name for Ubuntu is… ubuntu. My private key are in test1-keys.pem file in .ssh directory and IP address of my instance is, so i type following command:

ssh -i ~/.ssh/test1-keys.pem ubuntu@

I wrote down key fingerprint from server logs so now I can verify if I’m really connecting to my instance. If yes I can confirm that I want to connect. From now on my computer “knows” my virtual machine so I won’t need to check this fingerprint for every connection. If everything was fine you just logged in to your instance. Congratulations! 🙂



If you’re working on Windows, you’ll need to use additional tools. First of all Windows don’t support SSH natively (probably something will change about this in near future as we can read here). I use and recommend PuTTY as SSH client for Windows. Additionally we can’t use private key as it is, we need to convert it to format which can be read by PuTTY. We can do this with tool called PuTTYgen, which we can download here.

Let’s open PuTTYgen and load our private key. Next we click on Save private key button. We’ll be asked if we really want to save our private key without password protection. There are different opinions on this subject. Here you can read interesting discussion about it. Everyone should take this decision himself. One thing I want to tell is that if your key is not password protected, anyone who can read your key file, can access your instance also. I’m not creating password for sake of this tutorial.


Where to save the new key file? I’ll follow the “Linux” way and create .ssh folder in my user directory, but you can place it anywhere you want. However it’s important to remember that if you are not the only user of this computer you should place it in directory not accessible by other users.

So last thing is to use PuTTY to log in on our machine. User name in Ubuntu is by deafult ubuntu nad IP address of my instance is In Host Name I should type ubuntu@ and in SSH -> Auth tab I need to select private key file.


Now it is worth to save this settings so i won’t need to retype them in future.


When you click Open button security alert pop-up should appear with information that this server is not known. If you wrote down key fingerprints you can verify if they’re match. If yes confirm that you want to connect and you should be in. Next time this verification will not be required.



So we have established SSH connection to our EC2 instance. We are step closer to run WordPress. In next part we will talk a little bit about configuration of our server in terms of security.

Part 1
Part 2
Part 4
Part 5
Part 6
Part 7
Part 8