Category: EC2

Lockdown only the admin account

If you are running WooCommerc e-commerce, membership site or have som other reason for giving your users access to the admin panel the Clef Two-Factor Authentication WordPress plugin is our recommendation. The Authy Two Factor Authentication is another excellent WordPress plugin. Use one of these plugins to lock down only the accounts with admin rights. Not the user accounts.

Customized access control

If there is only yourself or a few users that need access to your admin panel, then placing a .htaccess file in the /wp-admin/ folder is our choice. This enables you to limit the access by IP address, IP-range or domain names of your choice. You can customize a .htacces file to do pretty much anything. Another advantage is that .htaccess files are fast and easy to disable for a few minutes to work and then re-activating when completed. That can be useful when you need access from a cell phone connection or for some other reason. Another reason is that .htaccess files is not a plugin. The fewer plugins you need, the better.

CloudFlare IP module

Your .htaccess file will only work if you also use the CloudFlare IP module when using CloudFlare. This is because this module is required to show your real IP and not the address re-written by CloudFlare. Follow these instructions

To deactivate .htaccess

sudo mv .htaccess 1htaccess

To re-activate access limitation to WordPress admin panel

sudo mv 1htaccess .htaccess
TIP:
Use TextExpander or a similar app on your PC, mobile and tablet to enable and disable the .htaccess.

Create the .htaccess file

Create a file with the name .htaccess in:

cd /wp-admin

Then create the file

sudo nano .htaccess

Just replace 888.888.888.888 with your IP’s below.
Then cut-and-paste this content into your .htaccess file:

<LIMIT GET>
Require all denied
# Localhost
Require ip 127.0.0.1
Require ip 888.888.888.888
Require ip 888.888.888.888
# Home
Require ip 888.888.888.888
# VPS servers
Require ip 888.888.888.888
# Work
Require ip 888.888.888.888
# Cabin
Require ip 888.888.888.888
# John Smith
Require ip 888.888.888.888
</LIMIT>

.htaccess is disabled by default in Ubuntu 16. ModRewrite could also be disabled. Here are the two steps needed to activate pretty permalink and all the other stuff related to .htaccess.

Activate ModRewrite

 sudo a2enmod rewrite
 sudo service apache2 restart

Edit the Apache main configuration file to activate .htaccess

Open the main configuration file for Apache:

 sudo nano /etc/apache2/apache2.conf

Search for the expression “Options Indexes FollowSymLinks“. Do this by pressing “CTRL + W” and paste the phrase into the Nano search field.
Find the following three lines:

 Options Indexes FollowSymLinks
 AllowOverride None
 Require all granted

Change the word “None” to “All”.
The correct version would look like this:

 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted

Then restart Apache again

 sudo service apache2 restart

Short version

• Use the AWS firewall.
• Only open incoming port 443 and 22 to the Internet. Limit the IP address to the IP range of CloudFlare and your own IP.
• Only open port 11211 and port 3306 in the local default network for in and outgoing traffic
• Limit outgoing on 22 to your own IP
• Open UDP port 123 to make the NTP client work to sync time
• Use port 443 for e-mail with OAuth 2.0 and Google API
• The package management tool apt-get needs outgoing port 80 to be open

 

In line with the concept of JeOS security is handled in the cloud and not on Ubuntu or in WordPress.

CloudFlare has some security features that will protect your server and WordPress well.

The firewall is available in your AWS control panel. Block any port and service not needed. Allow only the required IP addresses. Furthermore, CloudFlare provides some WordPress specific and general security features.

The only port that needs to be open on the server is 443 for web traffic and port 22 for your administration. All other ports should be closed.

Port 443 should only be open for the IP-range belonging to CloudFlare and perhaps the IP of your PC if you choose not to use VPN as described below.

When you are using VPN as described below, then connections to port 443 should only be allowed from the IP ranges belonging to CloudFlare.

Port 22 should only be open for the IP address belonging to the IP of your devices. Most of the time this would be only a single IP or a small IP-range.

Configuring firewall

Incoming and outgoing ports

AWS Default security group

Port 11211 for ElastiCahe – default security group

Port 3306 for Amazon – defult security group

IP addresses

Port 443 incoming from only CloudFlare.com IP-range

Port 443 outgoing for everything 0.0.0.0

Port 22 incoming and outgoing from only your office IP address.
When out of office log in to http://AWS.Amazon.com and add your current IP in the firewall. Delete the record when back in office.

Sending e-mail using port 443

The WordPress plugin Postman SMTP Mailer/Email Log uses OAuth 2.0 for sending mail using port 443. By using this plugin then there is no need for opening additional ports for outgoing traffic in the AWS firewall.

Blocking outgoing ports could be smart

If the bad guys should get control over your server. Sometimes they start servers and services. Then they hope for that the service can run undetected for a long time. By blocking all outgoing traffic except 22 and 443, using your server undetected would become more difficult.

Connect directly to the server and use stricter security rules inCloudFlare

You can bypass CloudFlare and connect directly to your servers WordPress admin panel. Bypassing CloudFlare enables you to use even stricter security policy rules at CloudFlare. A good practice is to connect to  WordPress directly on the IP using the hosts file. We have made a list with some useful tools to manage your hosts file easier and faster.

Alternatively, could you connect directly to the WordPress admin panel by using a VPN connection through SSH.

Use VPN access while out of office

SSH can acts as an excellent VPN server using SOCKS. When you need to access WordPress admin panel from some different IP then open port 22 for any IP. Access the server admin pages using VPN through the SOCKS proxy. SOCKS is a fast and easy to set up. It is also fast to enable and disable. VPN provides secure access to the WordPress admin panel without going through the security systems at CloudFlare. There is no software to install on the server. There is no software to install on your MAC or Windows. Another example of the JeOS concept.

Budget minded means more than dollars leaving your account.  Budget minded means the working hours needed to keep servers and sites running.

WP JeOS is a budget minded VPS server. That is why running many servers is always an option and often makes sense. It might come a day when you just can’t afford downtime on your WooCommerce. Then it might make sense to move WooCommerce to a dedicated WP JeOs server that just runs this single site. Furter down the road there might be a WP site that just won’t behave, so you decide to put it on another dedicated WP JeOS server to more easily debug it. Suddenly you ended up with 5 WP JeOS servers with a total of 25 WordPress sites. That’s where WordShell comes in.

 

3. party plugins you might have bought

A great timesaver with WordShell is the way it handles plugins that come from other places than the WordPress.ORG repository. This usually paid WordPress plugins will often end up as an orphan somewhere hidden on your hard drive. With WordShell, they are all gathered in a folder and can be used for both upgrade and install.

Look at this timesaver!

You need to get a list of plugins on all 25 WordPress sites on 5 VPS servers that needs updating. With your mobile, tablet or PC SSH into your server and issue the command.

wordshell all --listupdates --everything

Then update Akismet on all 25 WordPress sites on five servers from your mobile, tablet or PC by typing:

wordshell all kismet --update --latest

If you have TextExpander on your mobile, tablet and PC, you could just type the abbreviation

Zlup

moreover, then the abbreviation to upgrade

Zup

You can automate even more

Run WordShell from a script on the server.

To fully automate run WordShell and WP-CLI as a cron job.

WP-CLI vs. WordShell. Who is the better?

WP-CLI is a free solution for managing a single WordPress on a single server using the command line.

WordShell overlaps WP-CLI and gives you, even more, alternatives, so you simultaneously can perform actions on many WordPress sites located on different servers. It is a good choice to use both WP-CLI and WordShell.

Command line gives you the flexibility to manage WordPress from any device regardless the quality of the Internet connection.

The answer to the questions: Use both.

Bring a Bluetooth keyboard for your mobile and tablet

Things tend to go wrong on holidays and when you are out traveling and away from office. Command line gives you the flexibility to manage sites fast from mobile, tablet and PC from remote low bandwidth areas. I huge timesaver is to bring with a small Bluetooth keyboard. You can find little collapsible ones that easily fits into your pocket. Running SSH from a proper keyboard is much faster.

With just a few websites it might be faster to use UpdraftPlus Migrator to move from the legacy server to the new server. This is an alternative solution.

Create the root folders on the server

On the new server create the root for each WordPress site under

sudo cd /var/www/

sudo mkdir /var/www/mydomain.com

To avoid updating the Apache config files, this should be the same folder structure as on the legacy server.

Apache config files

Make a backup of the default Apache config files on the target server.

cd /etc/apache2/sites-available

Create a zip file with the configuration

sudo zip new-apache-config-files.zip *.conf

Copy the zip file to somewhere where you can access it with a browser.

sudo cp /etc/apache2/sites-available/new-apache-config-files.zip /var/www/html/new-apache-config-files.zip

Copy the Apache config files from the legacy server and place them on the new server.

cd /etc/apache2/sites-available

Create the zip file with the configuration:

sudo zip old-apache-config-files.zip *.conf

Copy the Apache config file to somewhere the zip file can be accessed with a browser if needed.

sudo cp /etc/apache2/sites-available/old-apache-config-files.zip /var/www/html/old-apache-config-files.zip

On the target server download the config files.

sudo wget http://www.domainname.com/old-apache-config-files.zip

Unzip the Apache config files on the new server

sudo unzip old-apache-config-files.zip

sudo mv *.conf /etc/apache2/sites-available

Activate the websites on the new server

It is time to activate the sites on the new server.

sudo cd /etc/apache2/sites-available

Enable the Apache config files

sudo a2ensite *.conf

Restart Apache and verify that it works

sudo service apache2 restart

After the migration, remove the zip files:

sudo /var/www/html/rm *.zip

Recommended procedure for migration and testing without downtime

Leverage the power of the hosts file

• You can migrate and test without changing the domain records. All you do is modifying the hosts file on your PC. This enables you to test the new server before actually changing the records in DNS.
• This way you can perform the migration with no downtime. Here is a list of graphical tools you can use to edit your hosts file on OS X and Windows. When something gets broken, then you can fix it without downtime. When you finally change DNS to go live on the server. Then you have already tested that everything is working.

Time for creating RDS database

• Create the database on the new Amazon AWS RDS server. You can do this using the command-line or graphical tools like Sequel Pro, MySQL Workbench or Navicat. Use the favorite of your choice.  The easiest way is often to tunnel trough EC2 to RDS using SSH.

Activate WordPress and restore

• Install an empty WordPress site using the old manual way, by using WP-CLI or WordShell.
• Restore UpdraftPlus Backups from the legacy server to the new, fresh WordPress JeOS VPS server.
• Test that the site works correctly by changing the hosts files instead of changing public DNS for the domains
• Go live by changing public DNS.

This procedure could be the fastest if you have many websites. With one website or just a few websites it might be easier to migrate using the migration procedure as we have outlined in this post. If you are unable to migrate using UpdraftPlus Migrator using this manual procedure could help you out.

Moving many WordPress sites

Migrate the databases

• Export the databases from the legacy server
• Create empty databases on the new Amazon RDS
• Import the database backup from the legacy server into the new RDS. Use command-line or use Sequel Pro, MySQL Workbench or Navigate to create an empty database and then import the data. The easiest and safest way is often to tunnel trough EC2 to RDS using SSH.

Migrate files and folders

• On the legacy server you should create a zip file of the file and folder system using this command:

sudo zip -r website-files.zip /var/www/

Copy the zip file to somewhere on the legacy server where it is available with a browser

sudo mv /var/www/website-files.zip /var/www/html/website-files.zip

On the new server download the zip file from the legacy server

sudo wget https://www.domainname.com/website-files.zip

Unzip.

sudo unzip website-files.zip

Then move the website content to the correct place on the new server.

 sudo cd /var/www/

sudo cp -r . /var/www/

Then remove the unzipped folder

cd ..
cd ..
rm -r var

• Change ownership of the files. It should be correct. We do this just to verify

chown -R www-data /var/www/

• If you haven’t already done this in previous steps: On the new, fresh server create empty databases in Amazon RDS. Import the database content from the old server into the databases
• Change the database server name value in wp-config.php to point to the new RDS databases.
• Change the username and password values in wp-config.php  to point to the new RDS databases if required.

Migrate the Apache configuration

• Migrate the Apache config files from the legacy server to the new server a described in this post.

Test by editing the hosts file on your PC

• Here is a tip on how you can test everything without changing the DNS and go live. Prevent downtime by doing this. To make sure everything is OK before making the DNS edits it’s a good habit is to test by changing your hosts file instead of the public DNS. Editing the hosts file is often faster to do in a graphical environment than in command-line. We have made a list of graphical tools for editing the hosts file on OS X and Windows.

How to create a zip from folders and archives on the legacy server

To install the zip program:

sudo apt-get install zip

To use the zip program:

sudo zip -r compressed_filename.zip folder name

How to Unzip

To install the unzip program:

sudo apt-get install unzip

To unzip a file use this command

unzip file.zip -d destination_folder

How to change the owner of the files

After unzipping the folders, you should make sure that the owner and group of the data are correct.

chown -R www-data /var/www/html

How to improve the page loading times on your website using Google mod_pagespeed module for Apache. The Google PageSpeed module can be set to use the Amazon ElastiCache for caching of files. This takes load of Ubuntu and lets you focus the memory to run Apache.

 

After installing the Google PageSpeed module open the config file:

sudo nano /etc/apache2/mods-available/pagespeed.conf

Scroll down to the section:

# If you want, you can use one or more memcached servers as the store for
# the mod_pagespeed cache.
 ModPagespeedMemcachedServers

Then add the address to your ElastiCache server.
Save the config file.
Restart Apache

sudo service apache2 restart

Change to Redis when it becomes available

Redis is a faster and better cache that memcache.

You shold change to redis when mod_pagespeed from Google starts to support Redis

Verify that PageSpeed works correctly

Your google page speed module has a web based reporting panel only available to localhost. You connect to the VPS server using SOCKS proxy through your SSHD server.

To access the Google page speed panel use the default HTTP:// access without SSL and the internal IP of you EC2 server.

The internal IP of your EC2  VPS server id displayed if you type

ifconfig

If the local IP of you EC2 VPS is 88.88.88.88 you can access the PageSpeed panel on the address:

http://88.88.88.88/pagespeed_admin/console

 

How to gain access to the PageSpeed panel

Check that you still have the HTML root folder

Check that you still have the default apache folder HTML

cd /var/www/
ls -a

If the necessary create the folder

sudo mkdir /var/www/html

For your reference create an index.html file

sudo nano /var/www/html/index.html

Tape some reference text in the file and then save it.

Then make sure that Apache can write to the folder

sudo chown www-data:www-data -R /var/www/html

 

Start the default port 80 Apache configuration

Every active Apache config file represents a potential entry point for the bad guys to your VPS. Every active Apache config drains your VPS server for memory. That is why only the config files you need should be active. In this case, you should activate the config file when you need to access the Google PageSpeed stats. Afterwards, disable the config file to block it as a possible entry point for bad guys and free up the resources.

To enable the config file:

sudo a2ensite 000-default.conf
sudo service apache2 restart

To deactivate the config file:

sudo a2dissite 000-default.conf
sudo service apache2 restart

Verify that you can access your server on port 80. If the local IP is 88.88.88.88, then you should be able to access the index.html file you have created in

/var/www/html/

by typing:

http://88.88.88.88/index.html

Don’t continue to the next step before this works

Allow the local IP to access Google PageSpeed panel

Open the page speed config file

sudo nano /etc/apache2/mods-available/pagespeed.conf

Use “Ctrl + w” to search for

Allow from 127.0.0.1

Then add the local IP for your EC2 VPS server.

If the IP is 88.88.88.88 then this part of the config file would look like this:

 

 

 <Location /pagespeed_admin>
 Order allow,deny
 Allow from localhost
 Allow from 127.0.0.1
 Allow from 88.88.88.88
 SetHandler pagespeed_admin
 </Location>
 <Location /pagespeed_global_admin>
 Order allow,deny
 Allow from localhost
 Allow from 127.0.0.1
 Allow from 88.88.88.88
 SetHandler pagespeed_global_admin
 </Location>

Save the config file.

Restart Apache

sudo service apache2 restart

Connect to your VPS with VPN

Finally, connect to your EC2 VPS server using SOCKS proxy VPN.

The Google PageSpeed stats and info should now be able at:

http://88.88.88.88/pagespeed_admin/console

[themedy_button url=”https://www.wpjeos.no/socks-proxy/” icon=”wrench” font_awesome_att=”” label=”How to access your VPS through SOCKS VPN” colour=”blue” colour_custom=”” size=”large” edge=”rounded” target=”_self”]