With the large number of Raspberry Pis in the wild, and the fact that large groups of them are configured identically (when a newly-flashed SD card is installed with one of the few available images), they are likely to be a tempting target for malware, including botnets.

What can be done to mitigate this?

It is reasonably well known that one should change the password for the "pi" user (Debian) and "root" (Arch.) But how about other system accounts (e.g. "tli", "pnd"?) Do any of them have universal passwords that are presumably the same for all units?

And are there any known vulnerabilities in other packages that are installed in the SD images available for the Pi (e.g. because of hardware limitations, or cut-down versions of those packages?)

In particular I am worried about ssh, mysql and any other services that may be running on a newly-installed image.

up vote 22 down vote accepted

Things I've noticed so far about the stock Debian Squeeze image:

  • /etc/shadow contains a bunch of password hashes for accounts that aren't the pi account (buildbot, etc). Change the password on the pi account, naturally, if you haven't already (or make a new user account for yourself and delete the pi account) but also edit the other entries and replace the hashes with *s. Note /etc/passwd contains duplicate entries for the pi account, which confuses the hell out of adduser / deluser, just delete one.

  • the default ssh daemon configuration permits remote root login. This should be disabled.

  • worth using netstat to check the set of things listening for connections; a surprising amount of stuff is running compared to a typical minimal Debian netinst. It's generally a good idea to reduce exposure to just the things you need, so first either disable or firewall off everything, then expose just the services you deliberately want visible on the public internet (typically just ssh or ssh+http).

  • you'll want to change the ssh host keys rather than using the ones in the image (AIUI the latest image actually regenerates them on first boot)

  • 1
    I don't see the problem with your first statement. What are those additional users for? Shouldn't they be disabled for login? You can check by attempting to su to them. – Jivings Jun 20 '12 at 8:45
  • 2
    I'm going to give this -1. Mainly because you suggest manually editing the shadow file. Which is a tremendously bad idea. – Jivings Jun 20 '12 at 10:35
  • @Jivings No he doesn't. He may just as well imply using vipw; is that a bad idea? No it's not. +1 for implying using vipw. – user2497 Jul 11 '17 at 23:00

There are many ways to address vulnerabilities, however the first thing you should know is that Linux isn't as susceptible to intrusion as other Operating Systems. This is mainly due to lack of malware that targets *NIX. Nevertheless, you want to be aware of the ways in which your system can be accessed.

Passwords

Firstly you should change the default passwords for any users that are able to login. For Debian this is just the default user Pi. For Arch Linux this is the super user root. Passwords are changed when logged in as the user by typing passwd on the command line.

A secure password policy is encouraged, as it would be fairly simple to run brute force dictionary attacks on your default user. Pick a decent, medium length password.

Obscurity

Remote access is probably the most important security hole. What we can use here is named security by obscurity. A common method of attack is to scan a range of IP addresses for open ports. So one of the simplest countermeasures we can take is to be a user who does not use the default ports.

All that needs to be done here is to change the default ports for commonly used protocols. For example, the default SSH port is 22 and FTP is 21. On my system SSH uses 222 and FTP 221, which should obscure these protocols from any automated attack.

Connection Security

Firstly, the most important security concern is that the root account should not be able to log in via SSH. You can disable root login in the /etc/ssh/sshd_config file by commenting or removing this line:

PermitRootLogin yes

It should be set to no by default, but it is best to make sure.


If you use SSH a lot, and are worried about man in the middle attacks, dictionary attacks against your password, then you can use SSH Keys.

Key-based authentication has several advantages over password authentication, for example the key values are significantly more difficult to brute-force than plain passwords.

To set up SSH key authentication you need to first create the key pair. This is most easily done on your client machine (the machine with which you want to access the Pi).

# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/pi/.ssh/id_rsa):

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/pi/.ssh/id_rsa.
Your public key has been saved in /home/pi/.ssh/id_rsa.pub.

As you can see, this has created two files, the private key id_rsa and the public key id_rsa.pub.

The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.

So what we would like to do is copy the public key onto the Raspberry Pi. We can do this very easily:

ssh-copy-id pi@address

Where pi is the Raspberry Pi username, and address is the IP address of the Pi.

I'll reiterate, we distribute the public key. The private key is yours. Hold onto it tightly, to release that key breaks the security of the system.

The Arch wiki has an excellent description on how this works:

When an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is like a coded message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by someone with the private key. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the correct response.

For more information on the security of public key authentication, Wikipedia has a thorough explanation.

With SSH security in place you can do an awful amount of encrypted, secure data transfers. Practically every other port connection can be routed through SSH if needed. You can even forward the X session through SSH so that it appears on another machine.

As an interesting example, yesterday I was running Eclipse on my Desktop, viewing it on my Raspberry Pi, and controlling the mouse and keyboard from my Netbook. Such is the power of SSH.

Permissions

File permissions are the crux of the Linux security system. They effect who can see your files and folders, and can be very important at protecting your data. For example, log in to the Raspberry Pi as a normal user and run:

cat /etc/shadow

The shadow file contains encrypted passwords for the users on the system, so we wouldn't want just about anyone to take a look at it! So you should see this response:

cat: /etc/shadow: Permission denied

We can see why this is by taking a look at the permissions of the file:

ls -l /etc/shadow
-rw------- 1 root root 821 Jun 11 22:13 /etc/shadow

This tells us that the file is owned by root, and only the owner has read/write permissions. Let's break down that output.

-rw-------

This is the state of the permissions. The first bit tells us the type of file (- means regular file). The next three bits represent the actions available to the owner of the file. The second three bits represent the group, and the final three are for other or everyone else. Thus a directory with full permissions would look like this:

drwxrwxrwx  10 root root   280 Jun 20 11:40 tmp/

That's read, write and execute permissions for the owner, group and everyone else.

The next important part is the two names. In our case root root. The first user is the owner of the file. The second is the usergroup. For example it would be common to see:

drwxr-xr-x  10 pi users   280 Jun 20 11:40 home/pi

This would allow read/write access for the user pi on his home directory, and read access for all other users.

Permissions most often referred to and controlled using octal values. For example, if we want to set rw for only the owner we would type:

chmod 600 /path/to/file

This is a basic overview, for more details on Linux file permissions, here is a good article.


This understanding is important when securing files and folders. For example, say we have just set up SSH keys. We definitely do not want any other users to see inside our ~/.ssh directory, or they would be able to take our private key. Thus we remove their read privileges:

chmod 700 ~/.ssh
ls -la ~/.ssh 
drwx------   2 james users  4096 Jun 18 03:05 .

I hope this clears up some of your concerns with securing Linux. From this you should be able to see that it is a pretty secure system and if you are careful you should have no security issues.

  • 10
    I disagree with your Obscurity remark, it would take seconds to map the ports open on your device and find your ssh server. Disable password logins and stick to the normal ports. I doubt you need ftp at all, use scp instead. – Alex Chamberlain Jun 20 '12 at 11:03
  • 2
    @AlexChamberlain It is a temporary speed-bump for attackers, but by no means a complete solution alone. – Jivings Jun 20 '12 at 11:05
  • 3
    Changing default ports tends to lower door-knocking which often leads to dictionary attacks. Sure it's a terribly minor security measure but it has other benefits as well i.e. it can limit log bloat. It's more of a preventative action than security but still worthy of consideration. – Beeblebrox Jul 5 '12 at 3:58
  • 2
    @AlexChamberlain, During the debian ssh key debacle we logged a lot of attempts at port 22 and none anywhere else. In that instance, running on a different port would have bought you lots of time while the hackers were trying to work out which of the exploited hosts were valuable. SBO doesn't help nearly as much if the attacker is targeting you specifically. – John La Rooy Aug 22 '12 at 22:42
  • 1
    I agree. My point was that it's not just thereotical - there has been a time in recent memory where SBO definitely did help, and made a significant difference. – John La Rooy Aug 22 '12 at 23:04

To prevent bruteforce attacks, you can install and configure fail2ban. It will parse log files (such as /var/log/auth.log) and try to detect if several login attempts have failed. Then, it will automatically ban the source IP addresses with iptables.

There are a bunch of howtos around the Internet.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.