I’ve been using iStorage devices for several years now and following the Sky News coverage of one of my data breach discoveries I was offered the opportunity to test out iStorage’s newest device; the CloudAshur Encrypted Cloud Module (don’t worry there aren’t any affiliate tags in this post [or anywhere on this blog for that matter]).

CloudAshur only supports Windows and Mac for now but the product has only just entered the market, I’m hoping they’ll support Linux/Chromebook soon.

Dark.Fail is a dual stack (clearnet + .onion) website whose stated purpose is “to compile a list of ‘official’ .onion links to serve as an anti phishing resource”.

To aid in their (and everyone’s) ability to confirm if a given .onion mirror is legitimate or not the Dark.Fail website has proposed the “Onion Mirror Guidelines”.

This blog post discusses the OMG and Ablative’s OMG Ansible role that is available on Ansible Galaxy.

Since the early days of QuakeNet I’ve always wanted to run an IRC server but I’ve never had a real reason to do so. With Ablative Hosting starting to gain traction I’ve found that some people don’t want to send an email to ask a question or get support. It seems I now have my reason.

A discussion around Plumbago a small graphite tor proxy that forwards Graphite line protocol metrics to a Tor hidden service

One of the key elements of Ablative Hosting is that it will primarily use cryptocurrencies so it can’t have it’s funding sources pulled as happened to FetLife. Bitcoin transactions are entirely public, ZCash has issues when moving funds between shielded and normal addresses so for the customer who demands the utmost privacy the obvious choice is Monero. When I first set about implementing support for generating Monero addresses (and monitoring transactions to the that address) I had standardised on using nginx to reverse proxy connections to various daemons.

CI/CD is something that many organisations aspire to but the idea of “flicking the switch” inspires dread. With my latest little project I decided that I would do CI/CD from the very start to prevent the fear of automated deploys Due to its sensible configuration and secure design I aim to use OpenBSD wherever possible and this project is no different. Gitlab have a CI system built directly into their product.

BrassHornCommunications is 99% OpenBSD and in January Vultr announced support for OpenBSD virtual machines, not only that but they also support BGP peering from virtual machines! After earning some credit for writing the OpenBSD BGP guide I set about automating the BGP configuration of new VMs to use my IPs. Vultr allows IPv4 announcements as granular as a /32 but IPv6 is a minimum of /64, I allocated a /36 of IPv6 space and a /24 of IPv4 space and updated the RIPE route records for AS28715 to declare a ROUTE-SET specifically for Vultr;

My newest side project involves the configuration of OpenBSDs HTTPD(8) to serve a clients domain via plain HTTP and via TLS using an automatically provisioned LetsEncrypt certificate. The difficulty is that if we don’t have a certificate but we do have the config then httpd will fail to launch leaving the user in a worse situation than they were before. The answer is to use Ansible’s stat module and liberal use of Jinja IF statements.

Backups are very useful and in the event of fire or theft it is very useful to have them offsite, however offsite backups leave your data at risk of compromise if the offsite storage is attacked. To prevent an attacker from locating your offsite backup (e.g. if you were backing up your laptop whilst in a hotel) and preventing theft of the data in the event the location is discovered one can use Tor and GPG.