Monday, June 19, 2017

Restricting Access at in Varnish Server Wide to Admin Areas

There are lots of ways to implement access controls and additional security on your hosting. I recently implemented a very restrictive but easy to manage implementation for our FreeBSD server that runs everything through Varnish. I could have placed this restriction in Apache via .HTACCESS files or global rules but placing them in Varnish they execute earlier and have less server overhead and ensure there are no caching related flaws.

To set this up I added the following to the top of my /usr/local/etc/varnish.vcl file.
# Whitelist of IP Address's or Ranges that are allowd to access restricted administration pages.
acl admin {
    "127.0.0.1";
    "localhost";
    "10.1.0.0"/16; # Local Network Class B
    "192.168.1.0"/16; # Local Network Class C
    "1.1.1.1"; # Sample
    # INSERT IPS #
}

Next inside the vcl_recv sub, or add one if needed include this before other rules. The bold text is doing URL matching to determine what scripts or directories to require approval for.  This could also be applied to specific domains but in this case it is server wide.
# Optional feature to only allow access to matched pages if client is on a whitelist.
    if (req.url ~ "^/wp-(login|admin|cron|json)" && client.ip !~ admin) {
        # Whitelist for all admin pages
        return (synth(403, "IP address not authorized, please request access from AdminEmail" ));
    }

Now you can reload varnish and do some testing by adding and removing your local network or IP and ensure its working. You can stop here but this isn't very convenient to manage or update form offsite.
sudo service varnishd reload

Add a custom script to grant access to IP's.

We have a custom script hidden our our server that it not indexed or published anywhere that our administrator can use to add new addressed on the fly. It asks for a name, location, and IP Address and will update the varnish.vcl file and reload the configuration when submitted.

You can post this script to a secret location on the web server.  You may want to add a password to it for extra security and don't link to it anywhere. You will also need to run the following commands.

// Make writable by www user.
sudo chmod g+w /usr/local/etc/varnish.vcl
sudo chgrp www /usr/local/etc/varnish.vcl
// Add custom script to reload varnish.
echo "#!/usr/local/bin/bash
service varnishd reload" > ~/varnish-reload
// Move script and make it executable
sudo cp ~/varnish-reload /usr/local/bin/varnish-reload
rm ~/varnish-reload
sudo chmod +x /usr/local/bin/varnish-reload

Read XML Sitemap to a CSV File

You may need to process a sitemap for redirects or get a list of all your pages for some testing or monitoring process.  Here is a simple script you can run to convert your sitemap to a CSV file.  It even supports multi-file sitemaps.

Simply save this script sitemap-to-csv.pl to your computer. You will need Perl to run in.

Then you can execute it from the command line with the following format:
// This will automatically append /sitemap.xml
./sitemap-to-csv.pl http://domain.com

// Or specify the exact file.
perl sitemap-to-csv.pl http://domain.com

// With SSL domain authentication override.
PERL_LWP_SSL_VERIFY_HOSTNAME=0 ./sitemap-to-csv.pl http://domain.com

Monday, February 6, 2017

Configure SSL Termination with Varnish Caching and HTTP/2

To create the fastest web pages possible in a LAMP stack can be a bit tricky.  This document covers configureing blazing fast HTTPS sites on Freebsd with Apache, Varnish, Nginx, PHP, Mysql and letsencrypt.sh.  Of course you can swap out the PHP/Mysql parts as needed, or even use your own certificates instead of lets encrypt.sh as you need.

Monday, January 30, 2017

Easily post leads in Wordpress Fast Secure Contact Form Plugin to iContact

When using the Fast Secure Contact Form plugin for wordpress is is very very simply to seamlessly forward leads from any forms you wish to the iContact platform with very little configuration.

Tuesday, November 1, 2016

Guide to Custom Database Access in Umbraco 7 With Built in PetaPoco

Though there are a lot of ways to write custom database code, and in many place in Umbraco custom tables my no be needed as the CMS can handle most any custom data needs. There are reasons and use cases for using custom database tables and code including:
  • Reading data from external systems.
  • Large datasets that we don’t want to clog out cache’s and Umbraco tree with.
  • Performance sensitive querying where the Document -> Property models setup may not be preferable.
  • Complex cross-joins and many-to-many relationships that may not be easy to replicate in Umbraco.
  • Customer data, log data, or “write once” style form submissions where the data need not be in Umbraco trees.
  • Data that may need to be easily accessed from external systems. 
    • They can also use public Web API methods or custom views that read from the Umbraco core tables but writing data this was it less safe.

Though there are a lot of ways to do the database code and everyone has their own preferences, this guide is using the same PetaPoco system that Umbraco uses internal.  This has a few key benefits:
  • Very lightweight system yet powerful.
  • Fully compatible with Umbraco models, methodologies, and serialization.
  • Easy to implement and generate models.
  • All code is using existing database code already present in the Umbraco Core to minimize overhead.