Getting a Tor hidden service running doesn't have to be hard. I've just published an example Sinatra application demonstrating how to deploy a hidden service to Heroku (or Dokku, etc) in just a few lines. The app uses my ruby-hidden-service library with the multi and apt Heroku buildpacks to install and configure Tor. A deployed example is running at sinatra-hidden-service.herokuapp.com.
Here are the complete steps required to deploy the sample app:
I've just released Rack::DetectTor, Rack middleware for detecting Tor users. It adds an environment varliable
tor_exit_user with a value of
false to the Rack
request object. I've previously blogged about detecting Tor users in nginx using iptables, however Rack::DetectTor is a much neater and more self contained solution for Ruby/Rack based web apps (built on Ruby on Rails, Sinatra, Padrino, etc).
More info on the Github project page: https://github.com/warrenguy/rack-detect-tor
I've just launched BTC Watch. It's a simple service that monitors the Bitcoin network in realtime, allowing you to subscribe to real-time e-mail updates of transactions occuring on addresses you wish to monitor. You can opt to receive notification immediately when the transaction first appears on the network, and/or when the transaction has been confirmed between 1 and 120 times and at several steps inbetween.
You might find this useful for monitoring addresses you publish for receiving funds or donations, or for keeping track of your own addresses and transactions. No sign up is required. Just enter your email address, and the Bitcoin address you want to monitor, and you're set. Check it out at https://btc-watch.warrenguy.me. Some screenshots of sample email notifications are below. The emails have both text and HTML parts, and also include an attached file with a JSON object containing the complete transaction information.
After a few months of downtime (sorry!), the DNS tester is back.
It no longer uses the full list of nameservers from public-dns.tk, as it appears that someone is zmapping the entire IPv4 submitting every DNS server they find to the database (this was the cause of the downtime - my importer couldn't handle the large volume). Consequently the quality of data is now relatively poor and includes many dynamic addresses etc. For now I'm just using a subset of the servers (those that have been up reliably for at least several months), which should be good enough.
I currently manage around 15 Linux servers in my personal capacity, all now virtualised "in the cloud", with the majority currently at either Linode or Digital Ocean. Recently I began sending email for the first time from a server at Digital Ocean, and noticed consistent delays in delivery. I'm sending email via a smarthost on another server for delivery, and on inspection, it appeared that the Digital Ocean machine is unable to connect to the smarthost via IPv6, and so times out and retries on IPv4. On further inspection, I discovered I was unable to connect to any IPv6 address on the Internet on either port 25 or 587.
On raising a support ticket with Digital Ocean, I learned that this is a deliberate practice by Digital Ocean. In fact, all common email related ports are blocked: 25 (SMTP); 109 (POP2); 110 (POP3); 143 (IMAP); 465 (SMTPS); 587 (SMTP submission); 993 (IMAPS); and 995 (POP3S). I've reproduced my communication with Digital Ocean support here verbatim:
I learned yesterday that some HTTPS blogs/feeds weren't being successfully polled by the (very old) PlanetPlanet software powering Planet SysAdmin. Rather than figuring out why software last maintained in 2006 isn't working properly in 2015, I upgraded to the more recent Planet Venus fork.
Everything should look and work the same as before. However as a consequence of rebuilding the Planet cache and being able to poll certain HTTPS blogs for the first time in a long time, some old posts from as early as 2008 have sneaked back into the feed today. If you notice any other problems with the Planet, please let me know!
I'm devoting a little time this weekend to the upkeep of Planet SysAdmin, so I'm putting out a call for new content.
Do you write a system administration, tech, security or otherwise relevant blog? Know of one that other SysAdmins might enjoy or find useful? Then please let me know about it! Comment below or send me an email.
Have you ever wanted or needed to verify a GPG, OTP, SSL certificate or other fingerprint read aloud over the phone or even just sitting next to someone? This is important for detecting and preventing man-in-the-middle attacks, but reading/transcribing hexadecimal values can be tedious and error prone. Back in 1995, linguist Patrick Juola and PGP's Phil Zimmerman standardised a list of words corresponding with hexadecimal byte pairs for exactly this purpose. Each byte pair is represented by one of two words, depending on its position, to protect against inadvertently duplicated, missed, transposed words. As an example, my GPG fingerprint
D1D4 64C0 04F0 0FB5 C9A4 C8D8 E433 E7FB 7FF5 6256 could be read aloud as "stairway souvenir flytrap recipe adrift upcoming artist positive spearhead Pandora spaniel stupendous tonic concurrent transit Wichita lockup visitor flagpole escapade".
This is a simple method of exposing a Tor hidden service via a regular TCP port.
You might find this useful as a convenient way of exposing a service behind a NAT firewall to the internet, or to provide a public internet presence for a service that you wish to conceal the real location of.
This is a slightly hacky method of detecting Tor users in nginx. I'm using it on this website to advise Tor users of the existence of a hidden service that can alternatively be used to access this website. You can visit this website via Tor to see it in action.
We'll be using
ipset to match the IP of incoming connections to our
nginx server against Tor exits that allow access to our site, and redirecting those connections to a different ip:port. In your nginx config, you can then add custom rules, headers, or use an alternative server block, or whatever you like. This method could be applied to services other than nginx.
This is an exercise in regenerating an RSA private key while possessing only the public key. You might also find this useful if you happen to know all of the parameters of a private key (modulus, public exponent, and either the private exponent or prime factors), and want to reconstruct a key from them (skip to the end). This covers only the practical steps required without detailed explanation.
The example used here is a 256-bit RSA key, which can be factored on my laptop in less than three minutes. You won't (I hope) find any 256-bit RSA keys in the real world, however you could likely factor a 512-bit key (which sadly do exist in the wild) with modern hardware in a matter of days.
In the few days since launching my Global DNS Tester, I've made a few significant improvements. It's no longer limited to looking up A records alone; you can now compare A, AAAA, PTR, CNAME, NS, MX, and SOA records returned for any given host/IP from up to 100 public nameservers simultaneously.
I've also made a bunch of iterative improvements to the interface, and some minor performance improvements.
Helping a friend diagnose a DNS problem earlier, I stumbled across a huge list of public nameservers (more than 3,000 at present) at public-dns.tk. Inspired, I hacked together a simple script to query a random set of them and display the results.
So, I've just published a simple web based utility (URL at end of this post) for checking the A record of a hostname from a random set of global public nameservers. It allows you to query up to 100 servers at a time, either from all available global nameservers, or filtered by country. You might find it useful for diagnosing DNS propagation delays, nameserver connectivity issues, geotargeted DNS, and more. The nameserver list is updated about once an hour. I may release the source code at a later time, if I get around to cleaning it up a bit.
I've been seeing a lot of "referrer spam" cluttering Google Analytics etc lately, particularly from SEO scam operator semalt.com. Not only is it annoying, it affects the accuracy and usefulness your web analytics/reporting (whether Google Analytics or other), especially for relatively low volume websites.
The most effective way to block it is at the source: your web server. Below are instructions for blocking referrer spam using nginx and Apache. If blocking at the server level is not an option for you, you can also filter referrer spam using Google Analytics itself, which is detailed at the end of the post.