We try very hard not to re-invent the wheel and are already big users of tools such as Tripwire and Rookit Hunter but we wanted something lightweight for monitoring site files, not system files.

HashGate is written in Python using only core modules and aims to work on all platforms that can run Python 2.7, not just Linux!

Our main use for HashGate is for monitoring files on WordPress & Magento installations which more commonly are exposed to vulnerabilities allowing hackers to modify files. HashGate records the hashsum of all files in the specified directory and stores them for checking periodically, we run our checks hourly via cron.

Below is an basic example output where a file has been modified:


alex@dogsbody-alex:~$ ./hashgate.py -ca /tmp/files.cache -f /home/alex/Documents/Junk/ -t check
The following files were modified:
/home/alex/Documents/Junk/wordpress/index.php
----------------------------------


Other features of HashGate include whitelisting, which allows us to ignore files that frequently change and don’t need to be monitored such as WordPress’ cache files or Magento’s sessions directory.

There is also VirusTotal checking, this is where HashGate will check flagged files hashes against VirusTotal’s database of malicious files to determine if the change was malicious or not. Due to the nature of VirusTotal’s API we’re only able to do 4 requests per minute so if lot’s of files are flagged it will add some extra time to hash checks.

We have recently open sourced this tool and you can find some more information and a list of the full features and usage in the Github repo, if you feel something can be written better or there’s a feature you’d like to add we invite you to contribute and help us build a better tool. We make use of tools like HashGate in some of our server monitoring packages so be sure to check them out and get in contact if they could be of use.

The post HashGate: An intrusion detection tool appeared first on Dogsbody Technology.

The main thing we use the webhooks for are Pingdom, Newrelic & Sirportly alerts. When an incident is triggered in Pingdom or Newrelic they will make an API call to our webhook with the relevant information we require to investigate an incident, the webhook will then determine the priority of the incident and send an alert to our Pushover user accounts so we are alerted and can respond to the incident.

High priority alerts, such as site outages also trigger a rotating blue police style light which is accompanied by a siren sound from the office speaker.

The Dogsbody Technology office siren

We also use the webhooks to notify a user when certain interactions happen in our ticketing system Sirportly, such as being assigned a new ticket or when one of their existing tickets is replied to.

To ensure our webhooks would have near to 100% uptime and we wouldn’t miss an alert, we decided the best place to host them would be using AWS Lambda & AWS API Gateway. These two services combined allow us to run the webhooks with Amazon’s high availability infrastructure while only paying small amounts on a per request/alert basis, which is the perfect type of model for this service.

To put into perspective how cost effective AWS’ pricing model for our alerts is, last month (June 2016) we received 25,282 alerts for all of our endpoints combined. This worked out at a total monthly cost of … $0.10! AWS actually provide you with a free amount of lambda execution time per month which we haven’t even reached yet, we’re only getting charged that 10 cents for the API Gateway.

Let us know if you find any of the services and technologies mentioned above interesting and we can write some more in-depth blog posts on those subjects, and even some guides on using them. The alerts talked about in this blog post come with the majority of our server monitoring packages, so be sure to get in contact if you need any of our services.

The post Alerts & Webhooks with AWS Lambda appeared first on Dogsbody Technology.

We’re responsible for monitoring and maintaining hundreds of servers on a daily basis.  Checking the status of this infrastructure manually would be virtually impossible. To make this job easier we use tools such as Pingdom and NewRelic however we still felt the need for a high level overview of all servers.

When there is an issue with either a service failing on a server, or the health of a server deteriorates Pingdom and NewRelic will alert us real time via custom webhooks we have written. These are great for reacting to an issue when it happens, however it doesn’t give us a clear overview of the infrastructure we monitor before an issue occurs, this is why we created the Warboard.

The Warboard is displayed in such as way that we only see the metrics we need to. Services at the top of the Pingdom column are ordered by highest response rate, servers in NewRelic are ordered by the highest metric for each server (if CPU utilisation was a higher percentage than memory, disk usage and disk IO it would be used). We display the Warboard on a wall mounted TV for the whole team to see.

Example screenshot of the warboard

In the Pingdom column red checks are checks that are currently down, blue checks are paused and green checks are up. In the NewRelic column red checks are servers that have hit their high threshold on their policy, amber checks have hit their warning threshold, blue checks are servers that are no longer reporting and green checks are servers that have not reached a threshold.

We also have a column for Sirportly, our ticketing system. This shows how many tickets each team member has. Below this is an overview of events in our Google Calendar where we can see upcoming events and scheduled maintenance.

The Warboard backend is all written in Python and the frontend is Python (Flask) using the Jinja2 templating engine. We’ve made the Warboard public on Github, so feel free to contribute, modify it and use it in your own environment if you please.

If you’d like us to monitor your infrastructure be sure to take a look at our maintenance packages and get in contact.

The post The Warboard appeared first on Dogsbody Technology.

In the past, one of reasons websites weren’t HTTPS everywhere was due to the added latency from the overhead of the HTTPS connection. With a slow internet connection and slower servers by todays standard this caused the sites to become sluggish which obviously isn’t great from a user experience point of view. Now that bandwidth and server performance has improved, the overhead is negligible, there have also been improvements such as SPDY and HTTP/2 which can drastically improve a websites performance over HTTPS, we will be covering how these work in future blog posts.

There are a few steps you can do to get your website running HTTPS everywhere:

• Redirecting all HTTP requests to HTTPS; this can be done in your apache or nginx configuration and will tell web browsers that any request they make for content over HTTP should be redirected to the HTTPS equivalent URL. Ideally you would use a 301 (permanent) redirect for this, redirecting HTTP requests to HTTPS is something we do for the Dogsbody Technology site.
• Add the HSTS (HTTP Strict Transport Security) header to your website; again this is done in your apache or nginx configuration. This header tells browsers that it should only access the website over HTTPS, the browser will make sure not to request HTTP pages until the “max-age” time is reached (how long the browser should cache the HSTS setting for). There is also an option “includeSubdomains” which tells the browser any subdomain on for the site should also be served over HTTPS, you should be careful when setting this if you have any subdomains that won’t work over HTTPS. We don’t include subdomains in our HSTS settings as we have a few subdomains out of our control that can’t be served over HTTPS.
• The last thing you should do, only if you have the “includeSubdomains” setting mentioned above is add your website to the HSTS preload list. The HSTS preload list is a list of domains included by browsers that will serve over HTTPS by default without having to perform an initial HTTP request to the website. For this to work you will also need an additional “preload” option specified in your web servers HSTS configuration. You can submit your site to the HSTS preload list here.

Another good option is the HTTPS Everywhere browser plugin from the EFF, it works to achieve the same result as using HSTS preload and act as a list of rules browsers should follow for websites. It allows a finer grain control than HSTS and is perfect for domains like ours where we can’t include every subdomain, you can write your own ruleset for the plugin and do a git pull request to get your website in the next release they do. You can see our pull request where we added the rules for dogsbodytechnology.com & dogsbodyhosting.net and some specific subdomains.

Once you’ve done all of the above steps you can be pretty happy that your site is HTTPS everywhere, and the majority of all traffic to your website will be served over HTTPS (some older browsers don’t support the HSTS header).

If you think going HTTPS everywhere is the next step for you be sure to get in contact with us and we can help you achieve that!

The post HTTPS Everywhere appeared first on Dogsbody Technology.

We needed a way to mirror the latest releases of the popular Linux distributions that we use so they are easily accessible for when we need them in the office. We decided that the best way to do this was to setup a script mirroring these popular repositorys on a Raspberry PI that we use for various things in the office.

We had a spare 1TB external harddrive that seemed like the perfect fit, and as it’s always best to start projects with a clean slate we did a full shred of the disk to make sure it was completely clean. This was done with the following command:

sudo shred -n 1 -z /dev/sda &

This performs a pass on the disk filling it with random bytes and then a second pass that writes 0’s to the disk.

The next step was to create some partitions on our disk, one of these we were going to use as swap space for the Raspberry PI and the other for storage of all our ISO’s we were going to mirror. We used fdisk to partition the disk and created two primary partitions, the first partition was 1GB of swap (it’s always better to make your swap partition first as it will be created on the inner sectors of the disk where the disk spins faster). The second partition was for our storage and used the rest of our available disk space.

After partitioning our disk we need to format the partitions accordingly, our storage partition was /dev/sda2 so we formatted it as ext4 with:

sudo mkfs.ext4 /dev/sda2 -L storage

And then mounted it as /mnt/storage with the following commands:

sudo mkdir /mnt/storage
sudo mount /dev/sda2 /mnt/storage

We now had around 1TB of storage under /mnt/storage that we could use to store all of our ISOs for easy access over the office network meaning we always have the latest and greatest versions at our disposal.

Finally to setup our Raspberry PI swap partition and enable swapping on it we did the following:

sudo mkswap /dev/sda1
sudo swapon /dev/sda1

We will also need to disable the standard Raspberry PI swap that uses the SD card with the following commands:

sudo dphys-swapfile swapoff
sudo dphys-swapfile uninstall
sudo chkconfig dphys-swapfile off

The command:

sudo swapon -s

Will now show our new 1GB swap partition on /dev/sda1.

Finally we need to add some lines to our fstab file so the partitions are automounted at boot. We edited /etc/fstab and added the following lines:

/dev/sda2 /mnt/storage ext4 defaults 0 2
/dev/sda1 none swap sw 0 0

Save that file and you should be all done! You can reboot to make sure that all of the partitions are automounted and that your Raspberry PI is now swapping on the new 1GB swap partition we made.

The post Adding an external harddrive to a Raspberry Pi appeared first on Dogsbody Technology.

We really enjoyed the event and camped in O2 provided tents. The best talk of the event was from Vint Cerf who talked about how having a unique idea is useless unless you act upon it. You can browse the gallery below of the photos we took during Campus Party.

We hope to see you at future Campus Parties we attend!

The post Campus Party 2013 appeared first on Dogsbody Technology.