Cloudflare DNS Propagation Issues

Background

I have been doing website migrations and have been updating the DNS entries of these websites to point at the new server’s IP addresses. I have been getting major propagation delays on my personal devices when checking the sites I have migrated. It took me a little while to realize that this was most likely a Cloudflare DNS issue. When I switched my personal devices DNS servers to Google’s (8.8.8.8) and they worked.

Google DNS was used to circumvent Turkey blocking Twitter, ultimately leading Turkey to block Google DNS in 2014.

I use Cloudflare DNS on all of my personal devices. I mainly do this for privacy and security reasons. They also have simple instructions to set it up on numerous devices.

  • iPhone
  • Android
  • MacOS
  • Windows
  • Linux
  • Router

Solution

After doing some googling, I stumbled across 1.1.1.1 Purge Cache. Everything worked as soon as I used this tool. It took me a while to find this tool as most of the results relate to propagation delays related to using CDN tool that Cloudflare provides.

Using Let’s Encrypt to Secure WordPress on AWS Lightsail

This tutorial is a slightly modified version of the tutorial on Bitnami’s documentation site This tutorial will show you how to:

  1. Install LEGO (Let’s Encrypt client written in GO)
  2. Generate TLS/SSL Certificate with Lego
  3. Configure Apache to use the TLS/SSL Certificate
  4. Configure Apache to only use HTTPS
  5. Update wp-config.php
  6. Automate Certificate Renewal

Prerequisites

  1. A running Bitnami instance on AWS Ligthsail.
  2. A registered domain name configured properly for your Bitnami instance.

Step 1 – Install a TLS/SSL Certificate with Let’s Encrypt

Let’s Encrypt certificates are fetched via client software running on your server. The Lego client simplifies the process of Let’s Encrypt certificate generate. To use it, follow these steps:

First, change directories to the tmp directory.

cd /tmp

Copy the latest version of the LEGO client from github:

sudo curl -s https://api.github.com/repos/xenolf/lego/releases/latest | grep browser_download_url | grep linux_amd64 | cut -d '"' -f 4 | wget -i -

Unpack the source code:

sudo tar xf lego_vX.Y.Z_linux_amd64.tar.gz

Move the source code into /usr/local/bin

sudo mv lego /usr/local/bin/lego

Step 2 – Generate a TLS/SSL Certificate with Let’s Encrypt

First, turn off apache (or nginx). The Lego client needs port 80 available to complete the request.

sudo /opt/bitnami/ctlscript.sh stop apache

You can now run the Lego client to generate your certificate and key. Replace EMAIL-ADDRESS and DOMAIN with your email address that you want to receive expiration notifications and the domain of your site.

sudo lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/etc/lego" run
sudo lego --http --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/etc/lego" run

Agree to the terms of service.  A set of certificates will now be generated in the /etc/lego/certificates directory. This set includes the server certificate file DOMAIN.crt and the server certificate key file DOMAIN.key.

Step 3 – Configure Apache to use the TLS/SSL Certificate

This section differs from the bitnami tutorial. The bitnami tutorial has you replace the existing self-signed certificates.

Navigate to the bitnami configuration directory for apache.

cd /opt/bitnami/apache2/conf/bitnami

Open the bitnami.conf file for editing.

sudo vi bitnami.conf

Change the SSLCertificateFile and SSLCertificateKeyFile directives to point to your newly generated certificates.

SSLCertificateFile "/etc/lego/certificates/DOMAIN.crt"
SSLCertificateKeyFile "/etc/lego/certificates/DOMAIN.key"

Start apache.

sudo /opt/bitnami/ctlscript.sh start apache

Step 4 – Force HTTPS

Add the following to the top of the /opt/bitnami/apps/wordpress/conf/httpd-prefix.conf file:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*) https://%{SERVER_NAME}/$1 [R,L]

Restart apache.

sudo /opt/bitnami/ctlscript.sh restart apache

Step 5 – Update wp-config.php

Make sure you update WP_SITEURL and WP_HOME in /opt/bitnami/apps/wordpress/htdocs/wp-config.php

define('WP_SITEURL', 'https://example.com/');
define('WP_HOME', 'https://example.com/');

Step 6 – Automate Certificate Renewal

To automatically renew your certificates before they expire, write a script to perform the tasks required to renew the certificate and schedule a cron job to run the script periodically.

First using your favorite editor, create a script renew-certificate.shin the /etc/lego directory.

sudo vi /etc/lego/renew-certificate.sh

Add the following lines to your file. Again, make sure to replace DOMAIN and EMAIL-ADDRESS.

#!/bin/bash

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /usr/local/bin/lego --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/etc/lego" renew
sudo /opt/bitnami/ctlscript.sh start apache
#!/bin/bash

sudo /opt/bitnami/ctlscript.sh stop apache
sudo /usr/local/bin/lego --http --email="EMAIL-ADDRESS" --domains="DOMAIN" --path="/etc/lego" renew
sudo /opt/bitnami/ctlscript.sh start apache

This script will stop apache, run the Lego client with the renew command, and then start apache again.

Make the script executable

sudo chmod +x /etc/lego/renew-certificate.sh

Execute the following command to open the crontab editor.

sudo crontab -e

A cron job allows you to run a certain command a set time. Add the following lines to the crontab file and save it.

0 0 1 * * /etc/lego/renew-certificate.sh 2> /dev/null

This cron job will run on the first day of every month at midnight.

Issues Updating Drupal Core from 8.5.1 to 8.5.3

Introduction

Another highly critical security advisory has been issued for Drupal.

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being compromised. This vulnerability is related to Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002. Both SA-CORE-2018-002 and this vulnerability are being exploited in the wild.

I ran into two different issues when updating from Drupal version 8.5.1 to 8.5.3 using composer on a Drupal instance.

Issue 1: Cannot Allocate Memory

composer update
...
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 30 updates, 0 removals
  - Updating guzzlehttp/guzzle (6.3.2 => 6.3.3): The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details
                                                    

  [ErrorException]                                   
  proc_open(): fork failed - Cannot allocate memory 

I was able to fix the issue by following the link in the error message: https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors. Increasing the swap space fixed this issue.

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

Issue 2: Nothing to install or update

composer update
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update

This was another trivial issue. The composer.json file was restricted the update from updating past version 8.5.1

composer prohibits drupal/core:8.5.3
drupal-composer/drupal-project - requires drupal/core (8.5.1)

Changing the require section in the composer.json from:

“require”:{
	

	"drupal/core": "8.5.1",

}

To

“require”:{


	"drupal/core": "~8.5",


}

This tells composer that it can update to the latest version of the Drupal core in 8.5.x.

composer update
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Updating drupal/core (8.5.1 => 8.5.3):  Checking out b012f0ae51
Writing lock file
Generating autoload files
Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)Downloading (100%)> DrupalProject\composer\ScriptHandler::createRequiredFiles

Success!

Mount SFTP over SOCKS Proxy in OSX with Cyberduck

I can only access certain servers at work over SSH if I am using a machine with a certain static IP address. I wanted to be able to mount the servers file space using SFTP on a Macbook Air when I am either at home or at  a remote location. I investigated a lot of different ways to accomplish this with little success. After a lot of trial and error I was able to create a Socks proxy to my work machine using ssh and then mount the server file systems by using Cyberduck and enabling the use of the socks proxy.

Network Diagram
Network Diagram

First, I needed to create the socks proxy. In order to do this I had to SSH into my work machine and dynamical forward a port 8080. You may forward any port that is not being used greater than 1024. This will send any traffic on that port through the tunnel and out of the machine that you are connected to.

ssh [email protected] -D8080

After I have created the SSH connection with the dynamic port forwarding, I enabled the socks proxy in OSX Network Preferences -> Advanced -> Proxies. Check the “SOCKS Proxy” box. Then, set the “SOCKS Proxy Server” to 127.0.0.1:8080. Finally, add the IP or Domain of the machine that has the SSH connection to the “Bypass proxy settings for these Hosts & Domains” box.

OSX Socks proxy settings
OSX SOCKS Proxy Settings

Now enable the proxy in Cyberduck. Go to “Cyberduck” -> “System Preferences” -> “Connection” and check the box that says “Use system proxy settings”.

Cyberduck system preferences for proxies
Cyberduck system preferences for proxies

Now every connection in Cyberduck will flow through your SOCKS proxy that you set up so you can mount the remote server file system over SFTP.

Using Twitter API with a Proxy in WordPress

1280px-Reverse_proxy_h2g2bob.svg

I was launching a new WordPress website at work that was developed by an outside agency. This site was using twitteroauth built into the theme to access the twitter API. Where I work all the web servers are behind a firewall with a strict whitelist for all incoming and outgoing connections besides the incoming HTTP and HTTPS requests. This makes it difficult to access the twitter API because it could be a different IP address every time. To solve this issues my work provides a proxy server to make requests out to. So my research began.

WordPress began to provide configuration settings in the wp-config.php file for them (http://wpengineer.com/1227/wordpress-proxysupport/):

define('WP_PROXY_HOST', '192.168.84.101');
define('WP_PROXY_PORT', '8080');
define('WP_PROXY_USERNAME', 'my_user_name');
define('WP_PROXY_PASSWORD', 'my_password');
define('WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com');

Unfortunately, the developers built the twitter api into their theme so I had to manually track down the API calls to modify them to use the WordPress configuration settings. In the twitteroauth.php file in the themes folder I was able to add three lines to the
curl_setopt parameters to function http (http://php.net/manual/en/function.curl-setopt.php):

curl_setopt($ci, CURLOPT_PROXY, '192.168.84.101');
curl_setopt($ci, CURLOPT_PROXYPORT, 8080);
curl_setopt($ci, CURLOPT_HTTPPROXYTUNNEL, 1);

Everything worked once I added those three lines.

Home Automation Over Wi-Fi

Introduction

On an episode of Hak5 they discussed setting up a garage door to be opened with a mobile device. Unfortunately, the audio was missing on the section where they discussed building/configuring the actual hardware to operate the garage door. This episode inspired me to start working on some home automation that could be accessed with any internet capable device without the need to install any software on the device. I wanted to be able to control several lights throughout my house and my garage.

I decided to use x10 to give me a starting point.

X10 is an international and open industry standard for communication among electronic devices used for home automation, also known as domotics. It primarily uses power line wiring for signaling and control, where the signals involve brief radio frequency bursts representing digital information. A wireless radio based protocol transport is also defined – wikipedia

Hardware

  1. Arduino
  2. 10KΩ Resistor
  3. x10 PSC04
  4. x10 Lamp Module
  5. x10 Universal Relay Module
  6. RJ11 Cable
  7. RJ11 Jack
  8. LAMP server with an open USB port

Step 1: Building and Configuring the Arduino

Follow the wiring schematics below for wiring your Arduino to an RJ11 Jack.

Data Pin = Pin 8

Zero Crossing Pin = Pin 9

X10 - arduino wiring schematic

First, wire the 5v connection on the Arduino to the 10KΩ resistor. This will be wired to the data pin 8. Second wire data pin 8 to the black wire on the RJ 11 surface jack. Wire the green and red wires on the RJ11 surface jack together and wire them to the ground pin on the Arduino. Finally wire the data pin 9 to the yellow wire on the surface jack (sometimes you may have to swap the data pin and the zero crossing pin depending on if the RJ11 cord is a cross over or not)

RJ 11 Jack Wiring
Arduino and RJ11 Jack

Grab the x10 Library from arduino.

Clone my github repository https://github.com/jfurcean/House-Control.git.

Push the arduino/x10House.pde to the arduino. This code reads data in the form of ascii characters over the USB. It converts the characters into x10 byte codes that are used with the x10 Library. It then uses the x10 Library to push x10 commands out to the PSC04 moudle over RJ11.

Step 2: Configuring the Webserver

A webserver running PHP with an open USB port is required. I used a LAMP server running Ubuntu 11.04. Drop the contents of www from my github repository into your active web directory. Inside index.php you must set $serialPath to the path that your arduino is connected to. For example

$serialPath = “/dev/ttyUSB0″;

If your using Apache as your webserver you must allow Apache to write to that path name.

sudo chgrp www-data /dev/ttyUSB0

sudo chmod 775 /dev/ttyUSB0

The web application reads config files to display certain x10 actions. When viewing the web application you need to make sure  userName set. For example:

http://192.168.1.101?userName=john.

This will then use john.xml as the config file. The config file determines what stuff you can control.

<modules>
<module name=’Living Room’ house=’a’ unit=’1′ type=’light’/>
<module name=’Bed Room’ house=’a’ unit=’3′ type=’light’/>
<module name=’Garage’ house=’a’ unit=’2′ type=’button’/>
</modules>

Web Interface

Web Interface - x10 Modules Listing
Web Interface - Light x10 Module Control
Web Interface - x10 Button Module Control

 Step 3: Add/Wire x10 Modules

All that is left is to plug any lamp into a lamp module, an appliance into an appliance module or wire a garage door, sprinkler, etc to the universal relay module.

x10 Lamp Module
x10 Universal Relay Module

Step 4: Enjoy

Enjoy being able to control your house from any internet capable device connected to your network

Light Control via iPod Touch

Garage Door Control via iPod Touch

Questions? Comments? Suggestions?

Please feel free to contact me