jonwatson blog

broadcasting useless crap to the internet since 1200 baud

I find myself explaining my standpoint on this repeatedly. Usually, a few times a month, the topic of mobile security will come up on some social media site I am on, and I will have to re-explain why I think Apple is the better choice of mobile ecosystem from a security perspective.

I'm lazy by nature and repeating myself is a lot of work. It also gets tough to express myself in the fairly limiting characters allowed on most social media sites. So, this post is my evergreen post about the topic. If you've followed a link here, someone wants you to read this.

1. Both Apple and Google suck but for different reasons

Both companies have created a walled garden. That's a term that means it's really nice here, enjoy your time, but you can't easily leave. Both Apple and Google have created vast ecosystems that trap users by virtue of making it hard to leave. That's a shitty way to do business but it's the only way for now. You may think that all the good stuff you use daily is trivial to create but it's not. That smartphone you're holding in your hand represents billions of dollars of hardware and software investments by those companies. They get that money back in different ways. Read on.


Fail2Ban Logo

I’ve been a big fan of Fail2Ban for a decade or longer. It’s a quick way to introduce some brute force protection to your system and it generally just works “out of the box”.

Recently, however, I found a situation where it didn’t really work nicely so I found myself knee-deep in Fail2Ban documentation. I am installing the awesome Citadel Groupware and its logs are not very standard. For some reason, Fail2Ban basically has date formats that it understands hard coded into it. It’s pretty flexible but if you have an app that prints time stamps in a format that Fail2Ban doesn’t understand, it looks like you’re out of luck.


Data Center

Data Centres are made for servers, not humans. Consequently, they are inhospitable places and prolonged exposure to this adverse environment can quickly take a toll on your productivity and your health. Once your health starts to go, your attitude and your deep-thinking abilities go with it and the quality of your work drops. You owe it to yourself and your team to remain as effective as possible while onsite, and here’s some tips to help.

I’ve spent a few weeks in several different data centres around the globe this year, and here are some things I’ve learned that can help you out if your destined for one of these hell holes.



I installed my own instance of Pleroma today using an inexpensive VM from Luna Node. (referral link)

I created the least expensive instance for this, an m.1s instance. Previously I had tried to install Mastodon on this small instance but it did not have enough memory to compile. Pleroma is lighter and has no problem.

$0.0486 hourly ($3.50 monthly)
1024 MB RAM
1 vCPU
0.2 cpu-points
15 GB SSD storage
1000 GB bandwidth

Expect scripting

I’ve been playing with Expect lately. Expect is an extension of the TCL scripting language developed in the 1990s. It main purpose in life is to automate terminal interactions and it does that job very well.

I spend most of my day in a shell and automate as much as humanly possible so that I can be as lazy as humanly possible. Using tools like ssh and scp it’s very easy to automate simple commands and simple file transfers. But when these tasks become complex enough that they need to respond to terminal prompts, or provide arbitrary changing input, those tools fall apart.

My particular use case was a need to grep through logs on multiple Linux servers looking for PAN (credit card) data as part of a PCI compliance exercise. This would be a trivial task to achieve using plain old ssh except for the fact that I use a Yubi key to log on to the servers and I have to go through a bastion host, so every login happens twice. I need to interactively provide the PIN for my Yubi at each login. The same problem exists for encrypted public keys. For a while I just copied my Yubi PIN and pasted it at every prompt, but that became a pain pretty quickly so I started casting around for other options.



I've lost track how many times someone has come wandering up to me with a bunch of private keys and a cert and thrown it all at me saying “I dunno which key was used!”. The slow way to figure that out is to put them into your web server config and see if it starts. The easier way is to use openssl.

Assuming the certificate is in $CERTFILE and the key is in $KEYFILE, these two openssl commands will extract the modulus out of each:

$ openssl x509 -noout -modulus -in $CERTFILE | openssl md5

$ openssl rsa -noout -modulus -in $KEYFILE | openssl md5

If the moduluses (moduli?) match, then you can be pretty sure that is the key that goes with this cert.

#SSL #sysadmin