Author: Austin

Securing this WordPress blog from evil hackers!

Post author By Austin
Post date March 13, 2021
3 Comments on Securing this WordPress blog from evil hackers!

In my introduction post, I said I would write about topics in order of interest. Securing WordPress blogs from hackers isn’t exactly fun or interesting but it is very necessary in this day and age. Hackers are constantly probing sites on the internet for insecurities. They’re constantly trying to log into WordPress sites with easily guessed passwords (hint: don’t use ‘password’ as your password). Here are some hints on how to secure WordPress blogs from hackers.

If you prefer a video version, check out my first ever YouTube video (!) covering this same content here – https://youtu.be/wKgm_684acM.

When I set this site up, the first 24 hours were pretty quiet. After that, the attacks started ramping up. I decided to take action and lock down access. There are three main things I did to secure this WordPress blog installation and VPS it is hosted on:

Disable password-based SSH authentication for logins
Install and enable Fail2Ban
Install WordPress specific Fail2Ban filters

#1 – Disable password-based SSH authentication

Step 0 – Enable SSH Key Authentication

Before you disable password-based authentication, you need to enable SSH key based authentication. I have posted a SSH key tutorial here – SSH Key Tutorial.

Password-based SSH authentication

SSH stands for secure shell. It is how 99% of Linux/Unix servers on the public internet and private intranets are administered. There are two main methods of logging in with SSH: 1) password and 2) key. Password is pretty straight-forward and is what most people are familiar with. You have a username and password. If you enter the right password for the username, you get in. Hackers are constantly testing common usernames (root, admin, user, guest) with common passwords (password, password1, password123, test, etc.). Further – they aren’t testing just one combination of user/pass at a time, they keep trying passwords until they give up or are banned. I had my VPS for a few weeks before activating austinsnerdythings.com on it and here is a random sample starting a minute after midnight for about six minutes:
$sudo head -n 100 /var/log/auth.log.1

Feb 28 00:01:52 austinsnerdythings.com sshd[2265571]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=222.184.14.90 user=root
Feb 28 00:01:54 austinsnerdythings.com sshd[2265571]: Failed password for root from 222.184.14.90 port 45182 ssh2
Feb 28 00:01:54 austinsnerdythings.com sshd[2265571]: Received disconnect from 222.184.14.90 port 45182:11: Bye Bye [preauth]
Feb 28 00:01:54 austinsnerdythings.com sshd[2265571]: Disconnected from authenticating user root 222.184.14.90 port 45182 [preauth]
<snip>
Feb 28 00:04:59 austinsnerdythings.com sshd[2265587]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=139.198.121.63 user=root
Feb 28 00:05:02 austinsnerdythings.com sshd[2265587]: Failed password for root from 139.198.121.63 port 53437 ssh2
Feb 28 00:05:04 austinsnerdythings.com sshd[2265587]: Connection closed by authenticating user root 139.198.121.63 port 53437 [preauth]
Feb 28 00:06:06 austinsnerdythings.com sshd[2265591]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=212.64.38.8 user=root
Feb 28 00:06:07 austinsnerdythings.com sshd[2265591]: Failed password for root from 212.64.38.8 port 37354 ssh2
Feb 28 00:06:08 austinsnerdythings.com sshd[2265591]: Received disconnect from 212.64.38.8 port 37354:11: Bye Bye [preauth]
Feb 28 00:06:08 austinsnerdythings.com sshd[2265591]: Disconnected from authenticating user root 212.64.38.8 port 37354 [preauth]
<snip>
Feb 28 00:06:48 austinsnerdythings.com sshd[2265595]: Received disconnect from 49.88.112.118 port 37056:11: [preauth]
Feb 28 00:06:48 austinsnerdythings.com sshd[2265595]: Disconnected from 49.88.112.118 port 37056 [preauth]
Feb 28 00:06:56 austinsnerdythings.com sshd[2265589]: Connection reset by 49.88.112.118 port 53318 [preauth]
Feb 28 00:08:00 austinsnerdythings.com sshd[2265597]: Received disconnect from 49.88.112.118 port 61081:11: [preauth]
Feb 28 00:08:00 austinsnerdythings.com sshd[2265597]: Disconnected from authenticating user root 49.88.112.118 port 61081 [preauth]

Each login attempt is 3-4 lines, so that’s 10 attempts in 6 minutes. Also notice the repeating IP addresses – 49.88.112.118 tried 4 separate times to log in across 6 minutes!

Hackers try user/pass logins because they’re relatively easy. And they get lucky often enough it is worth it.

Key-based SSH authentication

The other method to logging in with SSH is via public/private key. How this works is you generate a public/private keypair. Then you put the contents of the public key on the server you want to log in to. When logging in, your SSH client says “hello, I am user austin and I have a key to login and here it is”! The public key that’s copied to the remote server looks like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCuzcK6yIyqJabWprjaZZI9mXpVaSewoGZROcYTf/iB6OvJklIYmM/j/YHPWq1fV30QcGPpUBwKFk8DrJNn5bIk3fow67TVC0Wr2tWy7DDweTNUpk7L01MBRhjLG2xpO9RU9F4hDyzAFI4NcrSOb6J9FL6ItrfQS/LZ7H3IrmBGIjp4OooQOhR4iw5KFEdgvNgs8rAaxSl2FziTRrxhISTzkQY0BUMBkUNjsJid4x3rTXJ9UyUDYwN2/WMfzf9aGJdRzPLIiNKsxbDeTzC3vd8TCfFOUJ+hmS8gSOY0vhLS/1wQp91jR10FF4d67z9FTwAyh+o6uKJfmvNpTXIhN austin@EARTH

And the private key (that should never be shared! this a throwaway key) looks like this:

As you might imagine, it’s a lot harder to guess that key than it is a password. In fact, cracking a 2048 bit key like the one above would take 300 trillion years with a quantum supercomputer (which doesn’t yet exist)! Source. The universe is 15 billion years old. That means it would require 300 trillion / 15 billion = 20,000 universe lifetimes to crack.

Before you disable password-authentication, you need to be 100% sure that key-based authentication is working or else you will lock yourself out of your server!

To disable password-based authentication, you need to edit /etc/ssh/sshd_config, find PasswordAuthentication and put no after it. If it is commented out (there is a # at the front of the line) delete the #. It will look like this when finished:

Then you need to restart the SSH daemon (service) for the change to take effect:sudo systemctl restart ssh.service. Now you password-based SSH authentication has been disabled!

My failed authentication attempts dropped dramatically after disabling password-based SSH authentication. Below is the same general timeframe from the morning of when this post was written:

Mar 13 00:00:24 austinsnerdythings.com sshd[108357]: Invalid user ftpuser from 167.99.34.31 port 59060
Mar 13 00:00:24 austinsnerdythings.com sshd[108357]: Received disconnect from 167.99.34.31 port 59060:11: Normal Shutdown, Thank you for playing [preauth]
Mar 13 00:00:24 austinsnerdythings.com sshd[108357]: Disconnected from invalid user ftpuser 167.99.34.31 port 59060 [preauth]
Mar 13 00:03:09 austinsnerdythings.com sshd[108549]: Received disconnect from 24.8.45.4 port 5402:11: disconnected by user
Mar 13 00:03:09 austinsnerdythings.com sshd[108549]: Disconnected from user austin 24.8.45.4 port 5402
Mar 13 00:03:09 austinsnerdythings.com sshd[108438]: pam_unix(sshd:session): session closed for user austin
Mar 13 00:12:33 austinsnerdythings.com sshd[108934]: Invalid user postgres from 167.99.34.31 port 46444
Mar 13 00:12:33 austinsnerdythings.com sshd[108934]: Received disconnect from 167.99.34.31 port 46444:11: Normal Shutdown, Thank you for playing [preauth]
Mar 13 00:12:33 austinsnerdythings.com sshd[108934]: Disconnected from invalid user postgres 167.99.34.31 port 46444 [preauth]
Mar 13 00:12:44 austinsnerdythings.com sshd[108941]: Received disconnect from 222.187.232.213 port 11758:11: [preauth]
Mar 13 00:12:44 austinsnerdythings.com sshd[108941]: Disconnected from authenticating user root 222.187.232.213 port 11758 [preauth]
Mar 13 00:17:40 austinsnerdythings.com sshd[109097]: Received disconnect from 221.131.165.23 port 32827:11: [preauth]
Mar 13 00:17:40 austinsnerdythings.com sshd[109097]: Disconnected from authenticating user root 221.131.165.23 port 32827 [preauth]
Mar 13 00:24:51 austinsnerdythings.com sshd[109322]: Invalid user postgres from 167.99.34.31 port 33830
Mar 13 00:24:52 austinsnerdythings.com sshd[109322]: Received disconnect from 167.99.34.31 port 33830:11: Normal Shutdown, Thank you for playing [preauth]
Mar 13 00:24:52 austinsnerdythings.com sshd[109322]: Disconnected from invalid user postgres 167.99.34.31 port 33830 [preauth]

Most of these are just disconnects. The hackers see that my server is not accepting passwords and they just disconnect – they don’t even try to log in.

#2 – Install Fail2Ban

Fail2Ban is a helpful tool that monitors various logs and if it sees too many failed attempts, it will issue a ban on the offending IP address.

It is simple enough to install. First, update your package cache. On Ubuntu/Debian, this is done with apt:sudo apt update.
Then install fail2ban:sudo apt install -y fail2ban. This automatically enables Fail2ban so that it starts on boot. It has a bunch of out-of-the-box rules and will handle many services without any additional configuration. This is what my Fail2ban log looks like as of right now. This is all SSH bans. Notice that the duration is increasing for IP 167.172.170.218. The default ban duration is 10 minutes and I have it configured to double (plus some randomness) every extra attempt.

#3 – Add WordPress specific Fail2ban jails and plugin

Attempts to log into WordPress look like normal web traffic in web logs. Failed logins aren’t recorded specifically. We can change that by adding a plugin to WordPress that writes to /var/log/auth.log for a number of activities. Fail2ban monitors /var/log/auth.log for failed logins so it can act appropriately. I am using WP-Fail2Ban-Redux which does exactly what it says and without any nonsense. To finish the install, I copied the files from wp-content/plugins/wp-fail2ban-redux/config/filters and /jail to my fail2ban filter.d/ and jail.d/ folders:

cp /var/www/wordpress/wp-content/plugins/wp-fail2ban-redux/config/filters/wordpress-hard.conf /etc/fail2ban/filter.d/wordpress-hard.conf
cp /var/www/wordpress/wp-content/plugins/wp-fail2ban-redux/config/filters/wordpress-soft.conf /etc/fail2ban/filter.d/wordpress-soft.conf
cp /var/www/wordpress/wp-content/plugins/wp-fail2ban-redux/config/jail/wordpress.conf /etc/fail2ban/jail.d/wordpress.conf

Restart fail2ban so the changes take effect:
sudo systemctl restart fail2ban
View all the bans in your log! Congrats, you’ve now applied some top notch security practices to your blog.

#4 – ALWAYS KEEP YOUR WORDPRESS INSTALL UPDATED

That is the entirety of #4.

#5 – To disable XMLRPC or not, that is the question

I haven’t disabled XML-RPC yet. XML-RPC is a way to programmatically interact with WordPress blogs. Hackers can use it to rapidly try user/password combinations and other things like that. Installing the WordPress specific Fail2Ban components will effectively ban offenders while still allowing access to the underlying services.

In conclusion

It isn’t too hard to make these three changes to secure your WordPress blog and doing so will increase the security drastically. If you would like assistance doing this on your site, please use the contact form to get in touch with me. Lastly, always keep your WordPress install up to date. Every so often, security researchers find holes in the base WordPress code. Automatic updates will prevent your site from being a target.

Tags cyber sercurity, hacking, ssh, WordPress

Home Assistant Home Automation

Home Automation 101

[this post is a work in progress – baby woke up!]

Let me start this post with a screenshot of my Home Assistant home page:

Home Automation sounds scary but isn’t

You can start as small as you want. The screenshot above (Home Assistant) home page shows where we’ve landed after a few hours of configuration and a couple weeks of fine tuning. We have switches for lights, heaters, and humidifiers. We have sliders to set the humidity and temperature for our six month old daughter’s nursery. And we also have some graphs showing temperature and humidity for a few spots around the house.

We also have a few simple automations:

Turn on lights 50 minutes before sunset
Turn everything off if everyone leaves the house (device tracking is all local and done by our WiFi controller)
Turn on fan to draw in cool outside air when the temperature is cool enough outside
Thermostat control that regulates temperature in our daughter’s nursery
“Thermostat” control that regulates humidity in our daughter’s nursery

The rest is just extra data (I like data).

Breaking it down

How we got started with Home Automation

We started with a basic Philips Hue kit with two light bulbs and a bridge (base station you plug into your router). Philips Hue is set up with a easy-to-use app on smartphones. The app is pretty simple and allows for creation of “scenes” where you preset lights to how you want them and you can activate them whenever. At the time (early 2016ish?) the app also featured scheduled scene activation, but we found it wasn’t very reliable. Thus I began a quest for a better way to control the lights.

Enter Home Assistant. Home Assistant is an open-source application that is commonly installed on Raspberry Pi which integrates all the smart home things. It has exploded in popularity over the last couple years. From the website, Home Assistant is “[an] open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server.”

The local control and privacy aspect speaks to me. You will see in other posts that if there two ways of doing something with one being “connect it to the cloud” and easy vs “do it all locally” and hard, I will always pick the local, hard way to do it.

Anyways, I installed Home Assistant on a Raspberry Pi (similar to Piaware, they make it super easy – flash the install to a SD card and boot. bam, done.), clicked add on the Philips Hue integration, pressed the button on the Hue Bridge, and there were my bulbs in Home Assistant! I now had a method to control them via code or schedules or whatever that wasn’t linked to an app. I was hooked.

Adding other smart home devices to Home Assistant

[baby woke up again! to be continued]

Tags home assistant, home automation

ADS-B SDR

Receiving aircraft ADS-B (position) signals – part 2

Post author By Austin
Post date March 10, 2021
2 Comments on Receiving aircraft ADS-B (position) signals – part 2

Welcome back from part one (Receiving aircraft ADS-B (position) signals)! Now that you have all the required equipment – what do you need to do to set it up? Thankfully, the folks over at FlightAware have made this super easy. FlightAware provides a flight tracking platform that is mostly fed by users like me (and soon to be you!). In return for feeding them data, they will give you a free enterprise subscription, which is normally $89/month. It adds a lot of tracking abilities which are great for aviation nerds like myself. To get the most data possible, they have put together some great getting started guides, which I will link here – https://flightaware.com/adsb/piaware/build. The short version is:

Write the Piaware operating system to your SD card
Either enable WiFi or plug into your router
Plug everything in
Claim your station on FlightAware.com after a few minutes
Watch the data start flowing!

Here is a picture of the most basic setup possible:

Simple ADS-B receiver setup with RTL-SDR and 1090 MHz antenna

To really increase your reception, there are three things you need to do (but before you proceed, I must warn you – this becomes addictive):

Get a bigger/better antenna. Antennas are measured by something called “gain”. The more gain, the better (generally speaking). More gain means the same signal is received stronger and with more clarity.
Reduce the other noise. A bigger antenna will amplify all signals in the same frequency range. ADS-B is on a very specific frequency (1090 MHz). An ADS-B filter reduces the signal at frequencies other than 1090 MHz.
Amplify the filtered signal. With the other signals filtered out, amplify what remains (legit 1090 MHz ADS-B signals).

This is what my full setup looks like:

Full ADS-B setup with 1090 MHz antenna, 1090 MHz filter, and Flightaware pro stick — Full ADS-B setup with 1090 MHz antenna, 1090 MHz filter, and Flightaware Pro stick

FlightAware started producing each of these a couple years ago (again, sticking with the theme of making it easy to provide them data). Originally, each was a separate item. Now the amplifier and filter are built into the same device on the FlightAware Pro Stick Plus. The antenna will remain separate. These upgrades together will cost around $80-90. I’ve provided some Amazon links below to check the current prices:

FlightAware 1090 MHz ADS-B Antenna – 26 in
FlightAware Pro Stick USB ADS-B Receiver
AirNav RadarBox 1090 MHz ADS-B Filter
Combined receiver and filter – FlightAware Pro Stick Plus (seems like it is currently unavailable on Amazon but in stock on eBay)

I like to keep the filter and receiver separate so if something goes wrong with either I can keep sending signals. As a side note, I am up to 735 days feeding FlightAware without interruption (two years and two days)!

flightaware connected for 735 days straight

The antenna is currently hanging in my garage which isn’t ideal but I still get signals from 100+ miles away consistently. I messed with a bunch of DIY antennas that I’ll post one day but settled on the FlightAware stuff because it works so well. I have the full setup of FlightAware antenna feeding the 1090 MHz SMA filter into the Pro Stick. When I lived in California this yielded 100-200 planes on busy days up to 200 miles away. This stuff is good fun, and as I warned above, it gets addictive. There is a physical limit though to how far you can receive signals, and that limit is around 250 miles for planes at 40,000 ft due to the curvature of the earth. Planes flying lower will fall off at closer distances.

Repositioning the antenna

I moved the antenna up a bit and am getting 20% more messages per second and distance – take a look here at Receiving aircraft ADS-B (position) signals – part 3 (antenna reposition)

Please let me know in the comments what you want to see about my setup! I will get around to making YouTube videos eventually to post because I know a lot of people like videos more than text but I want to do the text stuff first to get my thoughts together.

Austin’s Nerdy Things is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com.

Tags ADS-B, radio, Raspberry Pi, RTL-SDR

ADS-B SDR

Receiving aircraft ADS-B (position) signals

Post author By Austin
Post date March 9, 2021
2 Comments on Receiving aircraft ADS-B (position) signals

If you came from the SDR (software defined radio) introduction post, you already have an idea of what these devices can do. If you came from somewhere else and want a brief introduction, head on over to SDRs (or how I pull radio signals out of the air).

The SDR topic that provides me the most entertainment is picking up aircraft ADS-B (Automatic Dependent Surveillance-Broadcast) position signals. As of 2020, all civilian aircraft in the United States are required to transmit their position continuously. I am not sure of the specifics but they are transmitted at least once per second, sometimes more with different messages. The idea is if every aircraft has both a ADS-B transmitter and receiver, there will be less crashes because the position of every nearby aircraft is known. There is also a Federal Aviation Administration (FAA) component where they will be able to better direct aircraft in the national airspace.

What this means for those of us here on the ground is we can be constantly receiving position data from planes flying in the air above us, or taxiing around airports around us.

Below is a screenshot of what the Denver airspace looks like during a typical Tuesday evening:

aircraft positions around enver — ADS-B positions on a Tuesday evening

There are 33 aircraft with data being received by my stations in the above screenshot, of which 25 are showing a location. Green colors are low altitude, blues are medium, and purple is high altitude. The farthest plane away from my house (station) is 100.9 nautical miles away, or 115 “normal” miles away. The highest altitude is actually being shared by two planes: N499RK and ICAO identifier A66618, both of which are business jets, at 45,000 ft. The lowest plane is N735CF at 6,700 ft, which is a training aircraft doing pattern work (repeated take offs and landings) at KBJC.

It is pretty straight-forward to get this data, assuming you have the right equipment. Most people get started with a Raspberry Pi. If you already have one, great! It is super easy to flash the SD card with Piaware, plug in your SDR, attach the antenna and start watching the positions stream in.

If you don’t have a Raspberry Pi, they’re pretty reasonably priced. The Raspberry Pi 4 is the newest version. Any size memory will work. Raspberry Pi 3 will also work! If you want some information on getting started with a Raspberry Pi, check out my Getting Started with a Raspberry Pi YouTube video.

The most basic setup will run you about $110 to get started. This includes a Raspberry Pi 3B+ starter kit (with SD card and everything needed to run the Pi) as well as a RTL-SDR with a basic antenna. You can check the current prices here on Amazon:

CanaKit Raspberry Pi 3 B+ Starter Kit (32 GB EVO+ Edition)

Nooelec NESDR Mini USB RTL-SDR RTL2832U & R820T Tuner for ADS-B

These are the exact items I used to get started and they’re still up and running. I repurposed the Nooelec SDR for around the house stuff because I got a different SDR for ADS-B reception. As I was testing these links, Amazon kindly reminded me how long ago I got into this hobby – more than five years ago!

nooelec RTL-SDR purchased from Amazon in 2016

This post got long quick so I’ll stop here for now. The two links are enough for everything you need to get started. I’ll continue with a part two for how to set everything up, as well as upgrades to increase reception.

Continued at Receiving aircraft ADS-B (position) signals – part 2!

Tags ADS-B, radio, Raspberry Pi, RTL-SDR

SDR

SDRs (or how I pull radio signals out of the air)

Post author By Austin
Post date March 7, 2021
No Comments on SDRs (or how I pull radio signals out of the air)

I figured I’ll be posting things based on how frequently I used them, at least to start. Eventually, I’d like to post based on your requests! Out of all the topics listed in the Introduction post, I use (or at least have various systems & automations using) SDRs to pull data out of radio signals the most frequently. In fact, most of what I have set up runs 24×7.

First off – what is a SDR? SDR stands for software defined radio. It means you can plug in one of these USB-based devices into your computer, and instantly be able to pull radio signals out of the air. Previously, like from whenever radio became a thing, until recently, radios were analog devices made up of resistors, transistors, and other things like that. They were bought tuned to a specific frequency and further, only listening to a certain type of signal on that specific frequency.

Software defined radio (SDR) changes all of that. It can be tuned to a wide range of frequencies and just passes along the data it gets to whatever program you use to decode the signals. Luckily for us, there are many open-source programs written by very smart people that already decode these signals!

This is the broad post for SDRs. I’ll write more posts for what I’m doing with the specifics. You may also see them called RTL-SDRs. RTL is the shortened name of the chipset (RealTek). There are other, more expensive SDRs not based on RealTek chipsets that can work better in some situations. For me, the $15-25 RTL SDRs do great. RTL-SDRs were originally intended to receive over-the-air TV signals. I’m sure they do fine with that but I’ve never tried to utilize them for their intended use.

Here are some of the things I’m doing with SDRs:

ADS-B aircraft signal reception. As of the beginning of 2020, all civilian aircraft within US airspace must constantly broadcast their position. With a decently positioned antenna, these signals can be received up to 250 miles away from the aircraft! Link to part one of ADS-B reception.
AMR – automated meter reading. Where I live, the electric and gas utility has meters installed at my house that broadcast their usage at least once a minute. I can receive these signals from my (and my neighbors!) meters and plot them to determine electricity/natural gas usage.
Temperature sensor reading. You know those basic temperature sensor kits that most dads have sitting near the kitchen sink? The ones with a screen showing temperature/humidity inside and outside? Those are very easily decoded. I have one hanging outside and a few others around the house. They can also be placed in the freezer for advanced warning if a freezer goes out!

Some other thing I’m not currently doing but have thought about:

Satellite reception for weather satellites (US GOES, Russian Meteor M2, and others). They transmit when overhead for the non-geosynchronous satellites and all the time for the geosynchronous satellites. The antenna required is quite a bit bigger than the around-the-house SDR stuff but still perfectly reasonable.
General amateur radio reception
Police radio scanning
Aviation frequency reception

This post will be much better with pictures! I’ll add them soon.

Tags data, radio, SDR