Monitoring the Tor daemon with Telegraf

My services have been available via Tor .onion for around 7 years now, but my monitoring of their availability has always been relatively limited. I did previously have smokeping running reachability tests, but other than that there's been a reliance on me noticing that things weren't right (or perhaps receiving reports that an .onion was misbehaving).

Part of the reason for this is that there's never (to my knowledge) been a good centralised way to monitor the health of a Tor install. Nyx is a fantastic command line tool, but relies on the operator logging into their box: it's akin to relying on top to monitor CPU usage.

I've always figured that it should be possible to monitor the tor daemon more effectively, but never really quite got around to do anything about it.

This week, I decided to take a pop at it, and a quick scan over Tor's control port spec revealed how easy it should be to collect stats.

This documentation details how to use my new Tor Daemon Plugin for Telegraf to collect metrics from a Tor daemon.

The full list of statistics collected can be seen in the plugin's README, but they include

  • bytes_rx: total bytes received by Tor
  • bytes_tx: total bytes transmitted by Tor
  • uptime: Tor daemon uptime
  • version_status: Tor's assessment of whether the installed version is OK to use
  • Accounting information: is a quota set? If so, how much is left?
  • Reachability test statuses
  • Guard node states

Although my main focus is on monitoring the availability of my onion services, the plugin can be used to monitor tor relays, bridges and exit nodes too.

Read more…

Monkeying about with Pyodide and PyScript

Earlier in the week, I saw an article about running Python in the browser via a port of the Python interpreter to WebAssembly.

I couldn't think of an immediate need for using it over Javascript, but often learn unexpected things when playing around with new technologies, so I wanted to have a play around with it.

An obvious start point for me seemed to be to see whether I could use the Python InfluxDB Client to connect to InfluxDB Cloud and query data out.

This proved to be more challenging than I expected, this post follows the process of tinkering around with Pyodide and Pyscript in order to get the client running and ultimately build a semi-interactive webpage that can query InfluxDB using Python in the browser.

Read more…

Re-Seasoning a Roasting Pan

It's so easily done: you cook a nice roast dinner and someone "helps" by cleaning your roasting tray.

You find out, far too late, that they did this by putting it in the dishwasher, so the next time you see your trusty roasting pan all the seasoning's been stripped and it's a rusty mess

Unless you're partial to added rust in your food, this is an unmitigated disaster - anything cooked in the pan is going to stick and your roast spuds will pull apart when you try and take them out of the pan.

It is, however a recoverable disaster - the pan can be re-seasoned using much the same method as you'd use to Season cast-iron cookware.

Essentially, what it involves is coating the tray in (cooking) oil, and then holding that oil at it's smoke point for an extended period so that it leaves a protective residue on the base of the pan.

In this post, I'm going to re-season what was my best roasting tray. The same process can be used for cast-iron pans too.

Read more…

The Importance of Human Oversight

(updated )

A few days ago, news broke that $34,000,000 had become forever irretrievable as the result of a bug in a smart contract created by AkuDreams.

It's a good example of an issue that's pervasive across multiple industries, rather than being something that's cryptocurrency specific (though I'm no fan of crytocurrencies)

The reason that $34m in ethereum has been lost isn't simply because someone made a mistake in a smart contract: that's just the inevitable result of an underlying naivety in the smart contract model itself. As we shall see, that same naivety is all too common in the wider technology industry too.

Read more…

Gitlab-Issue-Listing-Script v0.4

Version: 0.4

Project Info

Gitlab Issue Listing Script (GILS) is a php front-end to the Gitlab API. It's intended as a means to work around Gitlabs awful SEO

Much like my original JIRA implementation (JILS) it provides a simple HTML view of information - it's intended as a read-only interface rather than one accepting input.

Read more…

RemoveAMP: V1.6

Project Info

RemoveAMP is a userscript for Greasemonkey/Tampermonkey designed to pull in a short snippet of javascript that will attempt to detect Accelerated Mobile Pages when they load, and navigate away from them to the fully functional canonical URLs. If the publisher hasn't specified the canonical, a DuckDuckGo search link will be injected into the page to help you find it.

See the Project README and FKAMP-1 for more information on why I consider this desirable.

As of April 2022, issue tracking can be found here

Read more…

Gitlab-Issue-Listing-Script v0.3

Version: 0.3

Project Info

Gitlab Issue Listing Script (GILS) is a php front-end to the Gitlab API. It's intended as a means to work around Gitlabs awful SEO

Much like my original JIRA implementation (JILS) it provides a simple HTML view of information - it's intended as a read-only interface rather than one accepting input.

Read more…

OSINTing the OS-INTers and The Dangers of Meta-Data

I recently tweeted a short thread having noticed an unexpected domain in my analytic system's "bad domains" list.

A "bad" domain is one that's serving my content, but is not one of my domains.

For example, if you were to download this page onto a webserver serving foo.example.com, when someone viewed your copy of the page, I'd see foo.example.com in my bad domains list. The same would be true if you instead configured a CDN (like Cloudflare) to serve my content under your name etc.

Ordinarily the list alerts me when I've made a mistake in configuration somewhere, as well as helping keep track of which Tor2Web services are active.

What I saw on that Saturday was somewhat different:

That's an unexpected domain

I'm censoring the exact domain name as identifying it in full doesn't really serve any useful purpose (although this post will use a fuller name than in my earlier tweet: part of the name is publicly discoverable anyway).

Someone had viewed a page containing my analytics at the url https://[subdomain].profound.cellebrite.cloud/webfiles/on/io/e26whn2524322mkxb3cbyk27ev2ihhq2biz35hty7gzgsyrwrygq27yd.onion/posts/blog/116-republished-freedom4all/C38EB530D1FD2C0105D250C1AB5E4319.OM20220324085844.html

This is interesting for a few reasons

  • Cellebrite are a digital intelligence company
  • The path indicates that it's a mirrored copy of the www.bentasker.co.uk onion
  • The filename C38EB530D1FD2C0105D250C1AB5E4319.OM20220324085844.html doesn't fit any naming convention I've ever used
  • The file doesn't exist (I did initially worry that maybe I'd been compromised)

You might have heard the name Cellebrite before: they've been in the news a number of times, with topics including suggestions that they'd sold their services to Russia and Belarus, the assistance they provided in prosecuting the tragic Henry Borel case, and claims that they helped the FBI crack the phone of the San Bernardino shooter.

More recently, Moxie Marlinspike highlighted vulnerabilities in Cellebrite's UFED product.

I already knew of the company, not least because they popped up in the Bitfi stuff a couple of years back.

With a background like that, seeing their name anywhere near my stuff couldn't but provoke a bit of curiosity.

I reported my findings to Cellebrite (who have resolved the issue) and we'll look at their response towards the end of this post. I first want to explore the techniques used to highlight how just a little bit of meta-data can guide the discovery of so much more.

Read more…