If you want to skip past the meat of the article and just read how to better secure your Raspberry Pi, do the following steps:
Don't use the default login of U:pi PW:raspberry.
If you don't need SSH, disable it.
If you do need SSH, consider only using ssh keys, and disabling username/password login via /etc/ssh/sshd_config and changing your PasswordAuthentication field from yes or commented out to
PasswordAuthentication no
If ssh and passwords are a must, take some steps to make brute force attacks harder:
PermitRootLogin no
AllowUsers your_username
LoginGraceTime 30
MaxAuthTries 1
MaxStartups 2
Really, read the official security guide from raspberrypi.org.
On to my idiocy.
A quick back-story: I host a couple things at home - a personal website, a Jenkins instance and a Minecraft server. I've got a NUC that runs all of these things, and I route traffic through a Raspberry Pi 3 which I use as a reverse proxy and DNS client. Most of my workflow can be accessed through Firefox, so I haven't logged into the NUC or the Pi in quite some time.
On February 18th I received the following email from Verizon Security:
At first, when I saw this, I thought nothing of it. Given my experiences with Verizon in the past, I thought this was related to my self hosting of my website but was nothing serious to worry about. I logged into my Verizon account and was greeted by this poorly formatted security message:
At this point, I was suspicious. The Mirai Malware name was specifically listed, and as someone who has almost 20 IoT devices on their network, I was a bit concerned. However, given all this information, I didn't really know where to start.
I have one of the original Google OnHub routers that I bought years ago. With it comes an app which allows you to do tasks most routers let you do - port forwarding, set static IPs, and do remote restarts.
Another major feature the router supports is viewing devices on your network. You can see IP addresses, give priority speeds to a device, and see the amount of data that has been consumed. Having read up on Mirai and how it operates, I figured it was a decent place to start. Here was a look at my network devices, by consumption, for 7 days between February 11 and February 17:
We use our Apple TV constantly as background noise, so this was kind of shocking. I understand that traffic coming into the network for my website goes through the Raspberry Pi, but 95GB of data is absurd.
I ssh'd into my Raspberry Pi and decided to see what was running, because I could see connections being made in real time through the Google Wifi app. I did this through using the command `top:
Most of this doesn't seem nefarious, but what stuck out was the random curl command (on PID 6658 and PID 7740) and the wget commnad (on PID 7690) all running as root. They would appear and disappear so they were hard to determine, but they definitely weren't traffic to my website. If you hit c while running top it will show the full command being run, and this was the output:
If you go to the IP address in the wget command (please don't) it's an html site with just the word "ghost". If you add the i686 to the URL, it downloads a file. At this point, it's pretty clear that not only do I have major issues, but the issues will continue unless I figure out what I did wrong.
I started searching for how this could happen to my Raspberry Pi. There are two main issues that when combined can make your raspberry pi exploitable right out of the box. The issues being SSH server being enabled and the default username and password for the pi being the same for all Pis. If you have a Raspberry Pi purchased after November 2016 (or have updated it since) then ssh is disabled, and you are required to change the default user and password. But if you just plugged it in, years ago and forgot about it, you could be vulnerable.
By default, the raspberry pi login is:
username: pi
password: raspberry
If you have a pi, you should really check if this login still works. I know that I changed the password for this account and disabled it, in favor of an account named nick (duh). However, I definitely have SSH turned on as that's the only way I access my Raspberry Pi. When setting up my reverse proxy, I opened up my Pi to ports 80 and 443 through the Google Wifi app. I decided to check and see if those were still functioning and if I'd changed anything else.
At this point I knew I had made a mistake, because port 22 was open to the world on my Pi. I was playing around with the idea of having a web server for SSH into my NUC, but it never came to fruition. Forgetting to remove port forwarding on 22 to my Pi was mistake number one.
Mistake number two I don't recall, but I checked the users list on my Pi using nano /etc/passwd and found a user named temp. Out of a sheer guess, the password was also temp. I don't recall making this user but having spent many a late frustrating night working on my reverse proxy, there's no doubt in my mind that I did it. The third issue (which I had resolved the week before) was that the url pi.doty.dev routed to my raspberry pi. So anyone could type ssh temp@pi.doty.dev and enter password temp and they'd have access to my entire Raspberry Pi.
Whoops.
According to the Verizon Notice, the Mirai malware can be removed if the device is pulled from the network and power cycled. After multiple attempts I noticed that definitely did not work for me, so I ended up erasing the entire thing using the NOOBS Recovery System and everything now works like a charm.
Now, with a clean-slate Raspberry Pi, I decided I should look into steps I can take so this doesn't happen again (beyond being just a total idiot). Here are some basic steps you can take to protect your Raspberry Pi, or any generic Linux system with an open network:
Prologue: Obviously, don't do all the stuff I did unless you absolutely know what you're doing.
Don't port forward port 22 on your router.
Don't make a user temp with a password of temp on any machine that touches the internet.
Check in on your devices every once in a while to make sure they're not downloading gigabytes of data a day for no reason.
First: Change the default username and password immediately upon using your Pi and connecting it to the internet. It should require that you do this, because pi/raspberry is not a secure combo, especially when everyone knows it.
Next: Make sure your SSH is disabled by default, unless you absolutely need it. If you're using the Pi locally to tinker, you probably don't need SSH turned on.
Next: IF at all possible, use SSH keys for login and ONLY SSH keys. This makes being brute-forced virtually impossible, as only you will have the private key to use. Doing this ensures that you're only likelihood of being compromised is if your host machine is stolen or compromised itself. This article talks about the importance of using SSH keys. If your device needs to be publicly available, you likely cannot disable password login. Nonetheless, you can disable it via editing /etc/ssh/sshd_config and setting the value to no:
PasswordAuthentication no
This field might be yes or commented out, or both. Make sure to uncomment it if so as yes is the default value. If you run into issues this StackExchange post has some useful information.
If you're going to open up SSH to the world, expect brute force attacks. Make sure you're using secure passwords. I'd highly recommend using a password manager for everything. Otherwise, make sure it has some length to it - the longer, the better. Check out this guide.
If SSH is open, you'll need to edit your /etc/ssh/sshd_config. Here are some settings that will help:
PermitRootLogin no
AllowUsers your_username
LoginGraceTime 30
MaxAuthTries 1
MaxStartups 2
If you want to read more on some smart options to choose when using openSSH, I highly recommend this article and reading the official guide from raspberrypi.org.
Happy coding!
Top comments (2)
I would also recommend using a utility like fail2ban to lock out users making repeated failed logon attempts. It modifies the firewall rules to ban these users for a period of time and can be configured to send an alert message to the system log or via e-mail.
That's a great idea! I think I had a friend recommend I add that as well, but I apparently forgot. Thanks for reminding me!