In a company there are Raspberry Pis which are connected to its network environment. A person with bad intentions could swap the SD card and replace it by his own which makes the Pi to a "sniffer" or the person could use it in other harmful ways.

My thoughts about preventing such an attack:

A locked Raspberry Pi case which is a physical barrier for the attacker.

Not the topic of this question:

Protecting/encrypting the data on the SD card.

The question:

Are there any other ways to protect against such a threat?

  • Physical barriers could bypassed too. You could for example do Network Access Control by implementing a MAC-Address changing Script (replace the vendor part with your own 6 hex numbers for example) into your distro and check against these known "good" MAC-Adresses.
    – architekt
    Jun 2 '17 at 9:30
  • 5
    An attacker in the position to be able to swap the SD card could probably just swap the device itself too - plug one which they've previously compromised into the network port.
    – Matthew
    Jun 2 '17 at 9:44
  • @Matthew not if that pi won't receive a valid ip address from the network Jun 2 '17 at 12:04
  • 1
    @GotAQuestion How do you prevent the malicious device from joining the network? Are you using VPN where the legitimate device knows the secret but the malicious device does not? Jun 2 '17 at 13:53

You must use Full Disk Encryption on the sdcard used to boot the Pi. Using it, if the attacker gets the sdcard away, it will not be able to read its contents. This will protect the 802.1x credentials stored in the card.

Second, use 802.1x authentication on the network. 802.1x requires login and password for the client to get an IP address. Without a valid login and password, the Pi will not be able to join the network even if the attacker plugs the network cable on it.

With this, you will have to connect a keyboard and monitor to the Pi, to enter the disk password and the 802.1x credentials. If this Pi is to run a secure environment, keep a know good disk image somewhere else and reflash the card every time the Pi is shut down. This will prevent the attacker from coming in, shutting down the Pi and backdooring the bootloader (the Evil Maid attack). This is required, unless you want the attacker to get the 802.1x credentials and full disk encryption key at the same time.

Bonus point: nobody without valid credentials will be able to get to an unsupervised room and plug in a laptop.

Forget MAC address authentication, it's trivial to change the MAC.

  • OP specificly said "Not the topic of this question: Protecting/encrypting the data on the SD card" ... maybe consider changing the first line of your answer from being about "Full Disk Encryption". I mean it makes sense when paired with 802.1x but maybe lead with that. Jun 2 '17 at 14:29
  • Full disk encryption is mandatory to protect the 802.1x credentials stored on the sdcard. Without FDE, the attacker just loads the disk on his laptop, reads the 802.1x credentials, and put another sdcard on the Pi.
    – ThoriumBR
    Jun 2 '17 at 14:32
  • Just chiming in case OP decides to go with this - check out OffSec's LUKS Raspi. Same concept but you can figure out the implementation from there - the idea is the same - to protect the device from being read by anyone else.
    – thel3l
    Jun 2 '17 at 15:01
  • LUKS RasPi alone will protect the sdcard, not the network. And that is OP's ultimate goal. OP must pair LUKS with 802.1x authentication to really protect both the device and the network.
    – ThoriumBR
    Jun 2 '17 at 15:13

I think putting the Pis in a cupboard or server rack that has a door which can be locked should do the trick with the least amount of hassle.

ThoriumBRs answer is really good, but horribly complicated to set up. Reflashing the sd card every time the Pi is shut down is certainly an option, but unless you're working for a very security-conscious employer (which is unlikely considering that your hardware platform is the Raspberry Pi) this is unlikely to actually be implementable in practice.


The Pi does not have any kind of mechanism for ensuring that only a known-good software image is booted. Nor does it have any mechanism for allowing an image to be booted without the attacker being able to find out what is in the image.

So your options are basically.

  1. Physically secure the pi.
  2. Keep the authentication secrets needed to access your network in ram only. The downside of this approach is that whenever you have a power failure those secrets must be re-entered.
  3. Lock down the network port so that even if the attacker does compromise the Pi the damage it can do to the rest of your systems is limited.

P.S. note that MAC address restrictions are not very secure, it is trivial for an attacker to insert a sniffer, grab the MAC address of a legitimate device and then reconfigure his device with that MAC address.


If you give people easy physical access to your RPIs with no supervision, you should place it on a least trusted segment of the network (preferably a dedicated vlan for IOT).

In your case I would worry about exploits as much as devices being physically stolen. Seeing your question it is safe to assume that tinkering with a device would possibly go undetected.

So far all the answers are focusing on mitigation of very narrow attack vectors. I would suggest top down approach where you can focus on your network security and not the security of RPIs. Configure your network such that every RPI is treated as compromised device and you are good to go. Having “sticky” MAC address is actually a very good security measure opposed to the popular believe. It must be configured so the use of any MAC address other than the one of your RPI causes the port shut-down on the switch (tripping this wire should also send an alert to the admin). Does it stop well prepared attacker from gaining access? No it does not. Does it make life of every amateur with a sniffer much more difficult? Yes it does. Do you want anyone to sniff on your network? No you don’t, so use it cause it is cheap, easy to implement and provides extra security.

All the traffic coming from your IoT should go through a proxy that makes sure that only legitimate queries/connections are coming to the internal network. In the ideal world the RPI should be behind a stateful firewall playing a role of the server where your client server would initiate the connection ensuring that RPI answers only when asked to. This way attacker would have access identical to being on public wi-fi (or less if each device can have its own VLAN tag).

In conclusion, if you have a network of easily accessible Linux boxes and you are afraid that they may get compromised, then treat them as already compromised and you’ll be as safe as it gets.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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