Intruder
Last week, I tried out Intruder, a cyber security start-up, run by Chris Wallis.
Intruder are one of the start-ups in the GCHQ/Wayra cyber accelerator, where I’m the Mentor in Residence (a day a week).
The service from Intruder was smooth and easy. Their main selling point is that they will make cyber security easy for you: they ask for some details of where your internet-facing equipment is based (IP addresses or website addresses), and they do the rest.
I had to sign a disclaimer saying I promised not to take them to court for gently probing my server and services. They come from an ‘ethical hacker’ background, where they were doing penetration testing for big corporates, and they’re very professional, so I wasn’t concerned.
My ‘internet-facing infrastructure’ is very limited, so it wasn’t hard to list it. I have some equipment at home, behind a broadband router/firewall, and I have a server on the internet that runs Apache, serving six or seven websites, including this one.
Two of those websites use Wordpress as the content management system, rather than Jekyll (as this site uses). The server also has an SSH port for me to get in and fiddle (or write content for the blog with good old Vim!).
Intruder give you a free trial before you decide whether you like it or not, so I gave it a go.
So, what did they tell me?
I had one Medium-level threat, that my Wordpress admin login screen was available to anyone on the internet. I had one Low-level threat that my websites weren’t using HSTS header fields, and they should.
What do these mean?
Both threats had some simple explanations on the site, and included steps I should consider taking to fix them, which was useful.
I haven’t ‘fixed’ the Wordpress admin login page one, as I use Wordfence (a Wordpress firewall that blocks the IP of anyone trying and failing to log in to the site), so brute force attacks aren’t really a problem.
The HSTS header thing means you should have an https:// version of your site, properly protected by a modern certificate, and then force browsers to go to that encrypted site instead of the unencrypted one. The HSTS flag is something that allows your browser to notice (and reject) attempts by someone evil showing you an unencrypted version of the site as a spoof - your browser ‘knows’ it should be seeing encrypted versions of that site only, so it rejects it.
This didn’t take too long to fix, although I made a few mistakes, which helped me learn a bit more about Apache configs and modules :-)
Although these two problems were fairly minor on their own, fixing them made me realise that the Wordpress admin interface could previously be accessed (by me) over an unencrypted connection, which would involve sending my complex password over the internet unencrypted, which is really bad. Fixing the site encryption, re-directs, and HSTS flags has stopped that happening.
Good stuff.
So, I think I’ll sign up to monthly checks of my tiny infrastructure, and see what they find next!
If you want to try out their service (which I’d recommend without reservation), check out their website (link above), or go straight to their sign-up page
JD