A Raspberry Pi is a tiny computer designed for makers and all sorts of Internet-of-Things types of projects. Make magazine has an article about securing it. Reading it, I am struck by how much work it is to secure. I fear that this is beyond the capabilities of most tinkerers, and the result will be even more insecure IoT devices.
Steve • September 12, 2017 6:30 AM
I agree many will not follow. Great find Bruce!
keiner • September 12, 2017 6:46 AM
insecurity by design for the Raspian distribution:
no firewall at all
Interweb thingy full with 1 gazillion of How-To’s to make the thing available on the internet. Fortunately not that many can/want to do so, at least not without changing at least the password.
I use my raspberries only in the local network and they are blocked from reaching anything outside LAN…
GiT • September 12, 2017 6:55 AM
Not sure if this really helps the security situation? But may be interesting to some… Using TOR for IOT devices and home networks: https://www.wired.com/2016/07/now-can-hide-smart-home-darknet/
Ioannis • September 12, 2017 7:30 AM
Most of these stuff should be part of the staple puppet/chef/ansible/etc configuration for any distribution. Try following any hardening guide, they’re usually much longer than this.
agumonkey • September 12, 2017 7:34 AM
I don’t think it’s neither hard nor out of reach. A large share of people tinkering with pi do far longer and far fuzzier things; that tutorial won’t scare them for sure.
That said, it should be mandatory and shown every time you buy a pi.
Joshua Bowman • September 12, 2017 8:10 AM
This is much more about Raspbian, the default Pi OS, than it is about the Pi. The Pi has physical security issues, but they’re only slightly higher than any computing device’s physical security. If you want to avoid Raspbian’s entry-level catering problems, just use a real Linux OS with Pi drivers! It’s really not that hard.
Raspbian trades off security for beginner usability. It’ll probably never change much.
rmd • September 12, 2017 8:11 AM
I think the biggest risk isn’t the average home user, but places like universities where you tend to have very large populations of poorly secured devices and often very little in the way of internal barriers blocking E/W traffic.
anon • September 12, 2017 8:12 AM
Well, the prime security measure is to change the default password. That should be the very first thing any person setting up any (not just IoT) device should think of. Although this should have entered the realm of common sense by now, your average Joe Consultant/Jane The-Only-Tech-Savy-Employee still skips this step due to convenience, and that’s where the Internet-of-Shit is born.
Without password change, the remaining security measures in that guide are mostly useless — if you know the password, the system is fair game anyway.
OTOH, with a strong password the system is okay-ish in its default state. The additional measures are not essential, they are defense-in-depth. I’d say automatic updates are the most important (“apt install unattended-upgrades”), followed by ssh authorization via public/private-keypair only. “Turn off what you don’t need” is also a good one. None of these are Pi-specific but apply to any computing system on the net.
So in summary: Nothing special to see here, move on and do the same stuff you’d hopefully do anyways.
BTW, that firewall logging tip is actually harmful, as those that have enough knowledge to benefit from that will also have the knowledge to set this up by themselves. Those that don’t will find their log files full of information they can’t make sense of, distracting them from more important messages. In the worst case it will fill their free disk space until the Pi no longer works correctly.
Me • September 12, 2017 8:13 AM
It takes less than 20 minutes for a Pi to get pwned by ssh if not secured. I tried, as an experiment.
MikeB • September 12, 2017 8:21 AM
This is pretty vanilla security for any Linux box. I don’t see tinkerers having a particularly difficult time with it. Possibly the biggest hurdle being getting them to think about it.
Peter A. • September 12, 2017 8:29 AM
All but one of this “security issues” applies to all stock Linux distribution sand are non-issues after all.
The only issue about Raspbian is a default user/password pair. It is necessary, otherwise you would not be able to access your Pi after you’ve copied install image on your SD card – the process is unlike installing a desktop Linux from a CD, when the installer prompts you to create user/password pair. The only improvement to make here is to force password change after first login in the default install image.
Others are non-issues. Creating another account and blocking pi account only marginally helps by disabling automated password guessing for this account, but once you have a strong password it is a non-issue.
Passwordless sudo is not much worse than sudo with a password – once you guessed the password to log in to the account which allows sudo at all, you use the same password for sudo. You have to either enable sudo on some account or you have to allow root logins (which is frowned upon for no reason) – otherwise you won’t be able to manage your box. Actually, sudo with a password is a protection from the admin himself – to allow him a slight pause after typing a command, so he can think for a second time.
Allowing SSH “from anywhere” (i.e. by providing proper user/password pair) is a non-issue – almost all Linuxes out there allow SSH login for at least one account, because that is how you get to access them! and nobody screams about millions of vulnerable machines. Of course, if you know for sure you’ll never need to login to your Linux box (be it Pi or full-featured PC) from outside of your network, you may limit it and you may do other stuff like disabling PAM or challenge-response as an extra precaution – but many boxes do use PAM (multi-user machines) or challenge-response auth (various OTP schemes) for good reasons and there’s absolutely no problem with that.
Firewall: very few Linux distribution apply firewall rules out of the box, and even if they do, they do really basic stuff. No need to worry. Just don’t run a service with cleartext passwords or no access control at all. Many desktop distributions run a lot of services by default and nobody complains because they are reasonably secure.
Pete • September 12, 2017 8:35 AM
This isn’t a raspberry pi issue. It is a disto issue.
Not everyone uses raspbian. Think I used it for 10 minutes, once.
Look for accounts with shells.
$ grep sh /etc/passwd
OSMC (kodi-centric distro) has root and the osmc accounts with a shell. No other accounts allow logins. The root account on osmc doesn’t have a password – only sudo can be used by the osmc account to get elevated access.
The osmc account DOES have a trivial password “osmc”, but changing that is bonehead.
The real issue is that lots and lots of noobs are using Unix-like systems without the knowledge to do so and making all sorts of incorrect assumptions. Most have never heard of ssh, much less know the common ideas for securing it, like never using passwords or allowing remote root access – EVER.
I wouldn’t disable password-based logins everywhere. I’d just disable them over the network and force ssh-keys be used. sshd has tcp-wrappers built-in, so preventing non-LAN ssh attempts is trivial.
Most have never heard of denyhosts or fail2ban either.
Don’t get me started about people/companies still using plain FTP. Don’t.
John • September 12, 2017 8:36 AM
Well this doesn’t strike me at all.
A raspberry is a type of a machine that makes computations. Aka a type of computer. And like any type of computer -especially the ones that can act like server- WORK needs to be done to secure them. Before judging about the default user/pass, ask yourself a question: How many people simply dump a raspberry iso image to the sd card, plug in the lan cable and wait until they can ssh to configure the raspberry to their needs? I’ll answer that: a lot.
So a lot of the default stuff that are automatically added by the raspbian or other images, are because a lot of users actually need that. If you’re willing to take your raspberry on a ride to the internet, then you sir/m’am must read a thing or two (actually a thousand things) to be able to say that you’ve secured the boxed devil. I agree that ways to secure thing should be more user friendly and easier. But this is not related to the raspberry, it’s related to every computer.
We should find ways to provide easier and more user-friendly ways for people to secure things. Default setup values are a bliss for some people and we shouldn’t judge these. What we should judge is how easy is it for someone to secure a computer box and if the OS informs the user that the box is kinda unsecured. So in the raspberry case, a big splash warning (on the GUI or the terminal) that the user should change their settings (using an easy user friendly way) is the solution to solve this. We should find the golden ration to security/user-friendliness instead of trying to remove from the scale any of the two.
ab praeceptis • September 12, 2017 8:46 AM
I fully agree with Bruce Schneier. While many here will smile and consider it easy, we should keep in mind that many Arm tinker boards come with Ubuntu. “Ubuntu” and how to install it also happens to be one of the more frequent type of help requests. That’s a clear sign that many of those users have a clickedyclick GUI background and mindset and are far from comfortably editing config files, let alone properly and sufficiently understanding their system.
I’m wondering why the companies don’t deliver their stuff reasonably well configured (e.g. having a default what the article suggests plus maybe a “setup” script asking for some parameters).
Another useful approach might be to have a set of config scripts for typical scenarios (e.g. “I want a small web server on my board”) available from which the users can chose and from which reasonably secure configurations can be created.
keiner • September 12, 2017 8:51 AM
@Peter A.
“The only issue about Raspbian is a default user/password pair.”
Could be FORCED to change (both) on first login. Maybe not in the distri used for schools, but for other users.
“Passwordless sudo is not much worse than sudo with a password – once you guessed the password to log in to the account which allows sudo at all, you use the same password for sudo.”
Ehhm, on my Linux, I need the root password for sudo. User pw for sudo is usual in Debian…
@Joshua B
“If you want to avoid Raspbian’s entry-level catering problems, just use a real Linux OS with Pi drivers! It’s really not that hard.”
Show me an OS other than raspian with support for the cam module and the GPIOs…
keiner • September 12, 2017 8:57 AM
@ab prae
One of the frequently used setups for raspis is a small home media server using Kodi. I downloaded it once and burned an SD-card, booted and got shocked by the news that the only used on this system has a HARDCODED password. Never booted that again.
But this is quit frequently used out there in the wild….
wellwellwell • September 12, 2017 9:00 AM
Well, yes and no. Yes its a long laundry list to go, but many out of the box linux distros are not better by default. But mainly – pi is here for study/play purposes mainly, not for production environment. You can’t expect airsoft gun to make significant harm…
Wael • September 12, 2017 9:07 AM
http://www.raspbsd.org/#image-info
https://wiki.freebsd.org/arm64/rpi3
I haven’t used it myself since my Raspberry Pi never arrived. If I order another set, FreeBSD is what I’ll use.
keiner • September 12, 2017 9:09 AM
@wellwellwell
You know about the raspian compute module? Is integrated into smart TVs, commercial home automation modules etc. growing and growing. There is a big and growing commercial market for this stuff.
Lot’s of people use it as small local mail-, print-, VOIPservers in professional environments. One of the reason the raspi 2B is not dying out, cause these people don’t like the (more powerful) raspi 3b (due to built-in wifi, you know 😉 )
keiner • September 12, 2017 9:16 AM
@ internet fraud from pi dealer? 😉
BSD: expect a ruff ride…
If you just want to play around without GPIO/cam, try openSUSE TW. Not a plug&play solution, but I have some of those around stable for more than 1 year. No support for wifi on raspi 3b, however. I like it.
ab praeceptis • September 12, 2017 9:21 AM
keiner
Oh, I don’t doubt that there more or less positive examples out there, too. Moreover, also as a P.S. to my last comment, we should note that OpenBSD (or whetever) wouldn’t be better per se.
And yes, we need not even discuss that, of course it’s insane to deliver boards with hardcoded passwords. One wonders how there are still some companies who didn’t get that message.
But still, I see that all over the place with the unices, generally there is much left to be desired and many, many users are even so much overwhelmed that trying it they quickly give up on Linux (or the BSDs) because it seems so complex and frightening.
While there will probably always be some complexity in a (not ultra trivial) OS there is certainly a lot that could be made friendlier. That why I talked about typical scenarios: they would help a lot – and quite possibly lure interested users into learning more rather than be frightened and drop it. Things like “I want to use my [whatever board] to run a small web server”.
When that has been done (e.g. the oss router projects) it usually became a big success.
keiner • September 12, 2017 9:27 AM
@ab prae
It’s not the hardware, it’s the OS you download from wherever you want from the interweb. Raspian, openSUSE, Kodi, whatever, an image file you download and dd to an SD-card. Put the SD-card into the slot of the raspi and boot it up. That’s how the OS (and btw all firmware) is added to the hardware you buy…
Wael • September 12, 2017 9:37 AM
internet fraud from pi dealer? 😉
More likely something else. FreeBSD on newly supported HW isn’t exactly cakewalk. Camera is supported, links say.
keiner • September 12, 2017 10:02 AM
@Wael
re cam: saw that, but don’t really buy that… have a few action cam style raspis doing .h264 hi res videos. Let me know if that works on BSD… 🙂
Bob • September 12, 2017 10:07 AM
Hardening systems has never been quick and easy. A Raspberry Pi doesn’t strike me as any more insecure out of the box than countless other pieces of garbage coming together to form the internet of stupid shit. At least with the Pi, it’s possible to harden it, and I have to assume that someone using a Raspberry Pi instead of some off-the-shelf piece of consumer garbage has a little more skill to apply to that end.
Of course, not everybody, or even most people, are going to take any steps at all to harden their Pis, but the option is at least there, and the number/percentage is still going to be higher than with the people buying proprietary shit that’s locked down into a state of permanent insecurity.
wellwellwell • September 12, 2017 10:14 AM
@keiner well it doesn’t change my words. Only someone “wise” started to push it outside of the ground it was intended to be used.
notsowell • September 12, 2017 10:23 AM
@Joshua Bowman
Raspbian trades off security for beginner usability. It’ll probably never change much.
The particular product may happen to have poor security and excellent beginner usability, but that is a false dichotomy. There is no trade-off.
Computer security is poor in general, and there is too much resistance to change from people who have a little gig going on the side.
FYI: Good security never interferes with beginner usability.
Wael • September 12, 2017 10:46 AM
@keiner,
re cam: saw that, but don’t really buy that
I’m kind of skeptical, too.
Let me know if that works on BSD… 🙂
When I have the HW and if I have the time, I’ll do.
de La Boetie • September 12, 2017 11:12 AM
On the Richter scale of unnecessary graunch to add basic security, I’d say the Pi is middling. But this is only because it’s dreadful or impossible on some other devices.
I would recommend casting Iot and similar devices (e.g. Voip adapters, webcams), onto a distinct internal LAN network (via VLAN or otherwise), to ensure that they are not in a position to attack your internal file-systems.
Who? • September 12, 2017 11:20 AM
Bruce,
The funny part of this —if we can call it funny at all— is that a Raspberry Pi is not an IoT device, it is a small computer. At least you have a chance to make it relatively secure, and you have a chance to run operating systems like OpenBSD on it too (OpenBSD is being ported to the Raspberry Pi 3 right now).
Think on an IoT device as some sort of Raspberry Pi, so closed than it cannot be hardened and, usually, with worse quality operating systems than a Linux that at least can be upgraded each few months. A true IoT device is much worse than a Raspberry Pi, even if both have a comparable size.
JohnnyS • September 12, 2017 11:36 AM
@ab praeceptis
It’s true that putting a Linux box on an unprotected Internet connection requires some work, and the steps listed are effectively the “standard” way of securing such a Linux box. There’s nothing here that would freak out a typical Linux sysadmin.
BUT! You and Bruce Schneier have hit the nail on the head here: Because the Raspberry Pi is NOT marketed as a home PC or a system designed to be deployed on a private network with carefully controlled Internet access as provided by an appropriate home router/firewall (or similar). It’s marketed as a “tinkerer” board that can do IoT stuff. “Maker” articles have all kinds of Internet-enabled “cool” stuff you can do with a Pi.
It’s brilliant to sell something like this to help people understand what computing is all about and get them started on a career in information technology BUT without a specifically hardened and carefully configured OS (i.e. NOT Raspbian), this device should only be marketed to be used in a sandbox well away from the Internet and the attendant risks of exposure to every blackhat In The World.
Dave • September 12, 2017 1:07 PM
until recently: ssh (with user password) open by default…
I don’t know what’s worse, enabled by default or disabled by default. Having experienced the disabled-by-default I’d say that’s far worse, because there’s no way to set up your Pi once it’s flashed without plugging in a USB keyboard, mouse, and monitor, and hoping whatever 1980s-style manual config the video subsystem requires happens to be set up correctly that you’ll get something displayed. It was incredibly frustrating having to spend about half an hour hauling out assorted bits of hardware and trying to get them working with the Pi just because some cretin decided it was a “security feature” to disable the only way you have to configure the thing.
Jason • September 12, 2017 2:28 PM
I’ll agree, and go even farther: it’s not just security, it’s irresponsible to promote the Pi as a good computer for neophytes at all. Rasbpian and most other OSes available for it are a thin layer of condescending “My First Computer” crap on top of a deep tank full of arcane Linux sink-or-swim.
Tatütata • September 12, 2017 6:20 PM
It’s marketed as a “tinkerer” board that can do IoT stuff.
Until you begin to do serious things with it.
Recently someone asked me for advice regarding the choice of a controller for an small-scale industrial process, and I spontaneously answered “Raspberry Pi”. It’s got more than enough oomph to do some basic DSP, it has just the right amount of GPIO, and can run reports and statistics. And the price is right.
There’s not even a prototype yet. But what if they rush that thing into production with the barely debugged software and default config? That kind of article is a useful checklist and makes several steps in the right direction.
But objectively, a Pi is no worse than “real” process controllers from large companies like Siemens and Schneider Electric, which had their own issues with weak default passwords and the like…
BTW, Shodan reports 277 devices that seem to be Raspberry Pies, that answer either on the Telnet or HTTP ports. I expected much more. Would Apache and the such necessarily betray the underlying hardware to the outside world?
Snarki, child of Loki • September 12, 2017 6:39 PM
Oh, come ON!
Hardening a Raspberry PI is super easy, anyone can do it!
Hardware solutions, while’u’wait!
John • September 12, 2017 8:09 PM
Here’s the thing, though. The Pi Foundation is small and approachable. If there is a concern then a small blurb or comments even on a very well-known blog isn’t going to do quite as much as reaching out to them directly. I am certain they would be receptive to constructive criticism or suggestions to improve security. They have already put a reminder on the default user to change the password. It isn’t much but you have to start somewhere. They do have a priority on entry level usability (the goal of the project is for teaching the fundamentals of programming) but one could point out that they could also be teaching the basics of security as well.
sooth_sayer • September 12, 2017 8:32 PM
I really don’t agree with the hang waving.
pi’s are no different than any other platform that can be vulnerable in wrong hands.
I use ~10 pis routinely to run small little jigs and fixtures.
Whether I secure them or not depends upon their exposure to vectors.
The work to secure them is about 2 minutes of typing .. a lot of people who use them probably don’t care about having their pi pwned .. swap the SDcard and be back in business in 20 minutes! of .. maybe 5!.
Questions are legitimate • September 12, 2017 9:50 PM
“pi’s are no different than any other platform that can be vulnerable in wrong hands.”
But other companies including less popular ones do more to mitigate obvious ones.
It costs some nonzero amount. But Pi is also very popular.
“Whether I secure them or not depends upon their exposure to vectors.”
Which in 100% of cases is a recipe for security failure, eventually.
“The work to secure them is about 2 minutes of typing”
An $10 o-ring destroyed the Challenger rocket.
“a lot of people who use them probably don’t care about having their pi pwned”
Making it more likely than less that the default security state is in place, a veritable dinner table for blackhats by default with few mitigations or basic SOP’s.
“swap the SDcard and be back in business in 20 minutes! of .. maybe 5!.”
Or maybe never, depending. You have to detect that you’re pwned first.
That’s non trivial though you’d pretend otherwise.
Let’s get down to basics.
A product can be flawed, but the reason why is a fair question to ask, isn’t it?
Clive Robinson • September 12, 2017 9:55 PM
@ ab praeceptis,
I’m wondering why the companies don’t deliver their stuff reasonably well configured (e.g. having a default what the article suggests plus maybe a “setup” script asking for some parameters).
Long answer short Wintel cartel position is to blaim.
The long answer is the solution to the problem was available in the mid 1990’s but it got “murdered at birth” by the industry.
Which is why as others have noted running “headless” is the way of the Single Board Computer (SBC) in general not just the Pi and it’s always problematic. You used to get similar problems with building PCs from your own selection of bits. In fact you still do with Live CD’s, which is why the likes of Knoppix does not always “work out the box” on a PC, even though it jumps through many loops and hoops trying to do so (which is one reason it can take so long to boot).
As such anyone running a headless computer, or trying to run an unconfigured OS on a desktop should be aware of the implications. Back just a few years ago they used to be, and it’s why small businesses could earn a living making PCs, because they used to be able to make a margine from “Configuration as a Service” (CaaS).
Take Microsoft for instance, they used to have this problem all the time hence CaaS was the price most payed without question. But MS still does have the problem when a user replaces a monitor with a new one that Microsoft do not have specific support for or the manufacturer has not written a driver for earlier MS OS’s.
Microsoft’s solution was to use their market position to force hardware suppliers to make their equipment compatible with the MS OS and supply drivers for it. It has had a side effect of causing way more working electronics to “fill the dump” against WEEE requirments due to the very early End Of Life (EOL) policy of both Microsoft and the hardware suppliers.
Whilst the Pi was not the first SBC and is very popular, there is no SBC out there that can use their market position to force hardware manufactures to supply drivers etc. This is also true for most if not all *nixs OS’s as anyone trying to put them on the latest hardware will tell you.
Sun tried to come up with an industry wide solution via Open Boot / Open Firmware in the mid 1990’s when the “hardware independent” PCi bus came out. The market chose not to get behind it for various reasons (it’s been said MS “stuck a rod in the wheel” of that).
To get what you want means that there needs to be an industry wide standard for both hardware recognition and driver code such that manufactures just need to write one set of driver code. The only way that can work with multiple CPU types is if the drivers are written in a code that is independent of the CPU Istruction Set Architecture (ISA). Sun tried to do that with a Forth Interpreter that the manufacturer just had to supply the Byte Code for.
It would have given you what you want but “the market knows best” is the mantra even when it is very visably wrong. Which means in free market economic terms that there has to have been a hidden agenda at some point.
HarHar • September 12, 2017 11:31 PM
@keiner: gentoo … cam aswell as GPIOs …
Ole Juul • September 13, 2017 2:52 AM
Interesting to see the comments mostly fall into two categories. One group is familiar with setting up operating systems on computers, and the other apparently does not normally do this kind of work, but feels they have something to say about it nevertheless.
Adam • September 13, 2017 6:01 AM
Definitely not the device’s fault, definitely the fault of the popular dists.
I actually have an industrial device sitting on my desk that has a Raspberry Pi Zero inside it. This thing is meant to go into factories as a PLC yet it’s running a modified version of Rasbian. The default password has been changed (good) but if I hook up the device with a micro HDMI to a monitor I see it’s basically just Rasbian in most other respects. Even comes with a demo of Minecraft 🙂
ab praeceptis • September 13, 2017 9:12 AM
Clive Robinson
While I largely agree with what you say, my feeling is that the involved parties shouldn’t be left that easily from the hook.
The diverse parties involved in those, let me call it “multipurpose SBCs” (like the Pi) could do better, much better.
Granted, it might not make a lot of sense business wise but my impression is that the reasons are other, namely and particularly what I perceive as a race to enter or possibly even conquer the market. Ever new players (along already existing ones) come up with ever new boards. It seems to me that they put all their muscles at designing and producing ever new boards and there are simply very few resources left for the question “how easy and safe is it to use our products”.
But a lot could be done. I have provided some simple examples and I have hinted at the oss router projects which did exactly that: they made it easy and (relatively) safe to install and use their stuff; typically it’s like “insert CD or usb, run setup, and then use an easy web interface to configure your system/router”.
I also mentioned ubuntu for a reason. It’s perceived by many as an “easy linux”.
Finally, as Bruce Schneier seemed to indirectly suggest and as I expressly suggested, there are even quite some things that would need no config at all for most users and that would almost beg for a sensible pre configured standard. SSH server config is one example.
Side note: I feel that in a way we shot our own feet. It has become kind of standard that “the community” will help. There are, for instance, fora for diverse linux distros and the BSDs. From what I see there has been a strange transformation. They came into existence because there was so little documentation available and what was available was usually for “geeks”, not for Jane and Joe. After the transformation, today, it seems that quite some companies simply open a forum (if that) and everyone assumes as totally normal that “the community” will provide support, documentation, etc.
TS • September 13, 2017 9:52 AM
Does not apply to windows 10 core, which some use. Or does it?
kiwano • September 13, 2017 10:54 AM
“…preferably on non-default ports” sigh
Who? • September 13, 2017 11:11 AM
@ kiwano
I agree, suggesting running services on non-default ports is bad advice. It helps protecting against, let us say, botnets that try guessing a username/password on hundreds of thousands of devices but it is useless against someone slightly better than a script kittie.
Most advice given in this report is either common-sense or bad advice. The usual tricks that anyone was using to protect his “Slackware PC” with a 0.9.x-series kernel on 1993. I was expecting something targeted to close unwanted services or reducing the huge attack surface on these toy operating systems.
Dave • September 13, 2017 12:02 PM
@keiner:
an empty file /boot/ssh does the trick 😉
And how do you get that in there, given that SSH is disabled?
(And yes, I know that you can mount the filesystem on another machine and hack it in directly, but that doesn’t help if you’re not in a position to do that).
Clive Robinson • September 13, 2017 12:09 PM
@ ab praeceptis,
While I largely agree with what you say, my feeling is that the involved parties shouldn’t be left that easily from the hook.
Unfortunatly the “involved parties” are on both the supplier and user sides these days.
Not long ago SBCs were very much the province of “engineers” using them to design systems prior to first layout committ. Back then SBCs were often “hardware demonstrators” or “evaluation systems” with a price that would mean there was little or no chance the SBC would end up in a final product.
Then the price dropped and dropped again and again. Now it often does not make sense to make your own design, because the mass produced SBCs are less expensive than any Bill OF Materials (BOM) price you would get from making your own.
The reason for such a low price is the SBCs went from being “Engineering Development” parts to “Consumer Of The Shelf” (COTS) parts quite rapidly. And the lower the price the more “Maker” type buyers would buy, so the price would drop again.
Not wishing to be nasty but most Makers are not proffessional embedded systems design engineers, they are people from other domains of expertise and inventive thinkers/tinkerers. I would not try to design fashion clothing, however that has not stopped fashion creators putting easily available electronics in their clothing…
Creative people whilst being thinkers, are often not thinking outside of narrow confines. Likewise children are always looking for the next buz not consequences.
Thus they don’t want technology to “get in the way” they want it to make dreams with. Thus the suppliers tend to respond to what the market wants, and what will reduce the high cost of customer support etc.
Thus you have an implicit collusion between the seller and the buyer… And security does not get a look in.
But worse IoT [1] is now following in the Maker foot steps, the “Slap it together and punt it out” mentality has now taken a firm hold. Often wedded to “collect it all” “privacy invasion for profit”. I keep thinking I’m in a “Zombie Horror” film where technology has become the questing undead trying to consume our brains (or atleast the contents).
Basically it is us who want security who are now seen as the freek show and that is not good. As has been observed “The only rights we have are the rights we can defend”…
[1] I’ve lately decided that IoT realy means “Inception of Trash”.
ab praeceptis • September 13, 2017 12:20 PM
Clive Robinson
[1] I’ve lately decided that IoT realy means “Inception of Trash”.
Haha, great. I myself took it as a mix of a massive marketing and sales scheme and ever more people with ever less professionalism but I guess your formula hits the point pretty well.
Sidenote: I take iot also i.a. as a rather crude and obvious attempt to push ipv6.
herman • September 13, 2017 1:42 PM
Actually, all you got to do is set a proper password.
Linux isn’t Windows. It doesn’t really need a firewall script at all.
So, securing the little thing is trivial.
keiner • September 13, 2017 1:45 PM
@Dave
You burn the SD-card, afterwards you mount the respective partition and place the empty file in the right place.
Take your card and boot it -> Done! 😀
cdmiller • September 15, 2017 12:26 PM
If one does not like the free default OS I suppose one can write their own. Problem solved.
m4ker • September 15, 2017 12:56 PM
I believe Bruce’s intention for this article isn’t to say securing Raspbian is hard or even laborous for his readers, but maybe the average maker magazine reader – who are a target audience for these kinds of boards.
Try the article on your granpa and you get the point. We make terrible, insecure defaults and WE gotta gix it /for/ them, not the other way around.
cdmiller • September 15, 2017 3:29 PM
@m4ker
Granpa is dead, problem solved 🙂 Further, Granpa didn’t read maker magazines. Seriously, SSH is disabled by default since last Fall on Raspbian OS. Is anyone struck by how much work it is to enable SSH on a headless Pi. This is a textbook Schneier troll on the intersection of agendas, usability vs security. History reveals systems are often released with insecure defaults and not changed until the security issues threaten their marketability or usability.
Glen Turner • September 15, 2017 9:16 PM
I have used a Raspberry Pi since its initial release. I’d note the following:
Raspbian turning off SSH by default was a good idea. SSH could be easier to configure for local subnet access only, which is often the use-case for SSH. Enabling SSH isn’t difficult: inexperienced users can use raspi-config, experienced users can create the symlink for systemd when originally writing the image to the RPi’s SD card. The system does re-create host keys and uses the hardware random number generator to do so.
the hardcoded userid+password doesn’t really matter. What does matter is that this knowledge that this account exists is also contained deep within some obscure configuration files (such as the user ‘pi’ being hardcoded in PolKit rather than the group ‘adm’). That makes it difficult for a user to simply lock the ‘pi’ account.
the default SSH and systems groups configuration could usefully have a ‘sshin’ group, allowing ‘pi’ to be easily removed from that group via raspi-config.
creating an new account and locking the ‘pi’ account should be an option in their excellent raspi-config utility.
the lack of a firewall isn’t damning: an open port in a host firewall to faulty software doesn’t save a host from compromise. What is more important is that, having decided a firewall is needed, netfilter-persistent is the usual software installed rather than firewalld or some other more approachable mechanism. Bruce is right about the complexity: on a desktop machine with SSH server, mDNS, and ability to print “wc -l /etc/iptables/rules.v4” says 58 lines of configuration. Similarly, iptables is too difficult to configure for local subnet only access (eg, you need to know the network prefix on every interface).
Real life is even more complex than the article suggests. Locking the ‘pi’ user isn’t done correctly, and now the machine can’t be shut down. The iptables configuration doesn’t allow printing or scanning.
The article had no mention of the software update policy for the RPi, which is that kernel updates to previously-released versions are not supported. This means that there are a lot of RPis not running maintained software. Fortunately, Raspbian’s policy (which tracks Debian’s policy) means the user-space utilities have better support. Even so, the original RPi release used Debian Wheezy, and that is still on a considerable number of RPis.
The RPi ships with IPv6 and mDNS disabled. This is a shame as a link-local address announced via mDNS would give 90% of RPi SSH servers the access they need without further exposing SSH to the internet.
wb greene • September 16, 2017 9:59 AM
Nobody seems concerned that as far as I can tell, every cable/dsl modem that most “normal” people use the access the Internet comes with a default password that is printed in plain text on the label!
The sky has not fallen for two reasons. You can only use it from inside its LAN and the text on the label is not accessible without physical possession of it.
I do worry about the second default password for wifi, its “strong” but also printed on the label and I couldn’t change mine, to do so it needs an “Access Code” which is also on the label but my access code doesn’t appear to work 🙁
I’m kind of surprised a criminal enterprise hasn’t developed to get these passwords and physical home addresses from the installers for drive-by free WiFi access.
TJ • September 17, 2017 12:47 AM
Most IoT attacks use nothing but default keys or passwords.. No buffer overflows, SQLi, XSS, CSRF, CGI exec etc..
Most are behind a NAT too..
No guide can fix laziness..
Jared Hall • September 21, 2017 11:41 PM
TJ: Hah! “No guide can fix laziness..”
There should be a book about that. “Laziness for Dummies”!
Preston L Bannister • October 5, 2017 10:20 PM
The rules for securing a Raspberry Pi are essentially the rules for securing vanilla Linux. Lots to get wrong, but only the usual.
The alternatives in this space are ESP32 (designed in China, and not well described), or Arduino (an 8-bit CPU).
As a security guy, do you trust hardware/firmware designed in China?
I would suggest you want to strongly make the opposite argument. The Raspberry Pi is well-documented, and the concerns of securing a Pi are the usual concerns of securing Linux. The unknowns are small.
What are the concerns of securing an ESP32? We do not know. There is chance the hardware is open to subversion … by design.
What are the concerns of an 8-bit CPU largely programmed by hardware folk? Do you expect the result to be secure?
The “Internet of Things” is all about cheap hardware largely secured by folk who have very limited grasp security. We want the shortest path for that group.
John Simmons • May 22, 2019 3:33 PM
It does take a lot of effort to set up and secure a raspberry pi webserver. Part of the problem is that, aside from here: https://cheapskatesguide.org/articles/raspberry-pi-website.html , no one website gives you all the information that you need to successfully set up a raspberry pi webserver, secure it, and run your own website from it. That means you have to do a LOT of research.
Zaun • October 28, 2019 3:04 PM
I wouldn’t say the Raspberry Pi + Raspbian is hard to secure. In fact, it can be locked down very effectively:
1: After putting the OS on a MicroSD card, enable SSH, log in, and upgrade all files.
2: Create your own user, password protect it, lock pi via password and give it a bogus shell in /etc/passwd. I’ve even deleted the pi user completely, but if using the desktop environment, one might have issues.
3: Set SSH to be key only. I do key plus the Google Authenticator, so if I don’t have my SSH key with me, I can still access it via 2FA.
4: Install ufw and turn it on. From there, use a whitelist of IP addresses you are going to be SSHing to the machine, and deny everything else. You don’t want to waste time blacklisting sites, so figure out where you will be coming from and only allow those. Even if the Pi is sitting on an internal network, I enable firewalling anyway.
5: Install fail2ban. This is a last resort, but it does help… but between SSH keys and IP firewalling, fail2ban should never kick in.
The only real downside of a Raspberry Pi is that it initially has a known username/password. It would be nice if there were a way, when writing the Raspbian image, for one to specify a custom file that could specify another default username/PW, so random guessing wouldn’t find the Pi before it is configured. After that, I do wish UFW was installed and enabled by default.
1&1~=Umm • October 28, 2019 4:29 PM
@Zaun:
“I wouldn’t say the Raspberry Pi + Raspbian is hard to secure. In fact, it can be locked down very effectively:”
That might have once been true.
However later hardware has built in extetnal communications hardware and due to NDA’s some binary blobs.
Whilst it might be benign unless you have certain ‘confidential’ information and thr ability to reverse engineer binary blobs, you have to take things on trust or forego certain functionality.
The Pi is not unique in this, lots of SBC’s are going down this route and it’s not a good route for security.
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
MM • September 12, 2017 6:29 AM
“Reading it, I am struck by how much work it is to secure.”
But I am struck by this