I’m connecting a BB to the internet and want to make sure it is relatively secure. Things like Cloud9, BoneScript, and root default password are all things that might leave open security holes.
I’m no Unix expert so I’ll pose the question here. Can anyone point me to a guide for what I should do to make the BB secure for long term autonomous connection to the Internet?
Well, that's a difficult question. You connect it to the Internet so
that it's capable of performing certain functions that you want, but
you want to secure it so that it will not do anything that you don't
want. The best approach, then, is to rigorously specify what's
allowed and what's not, and implement controls that match this spec.
You have several tools in your disposal:
- you can set up an independent firewall in front of your device: if
your device is on a home/ISP network you probably have a router that
already implements that.
- the BBB can run the Linux firewall (iptables) that control the
network traffic into and out of your device
- if your requirements can be met by your BBB always originating
traffic, things are easier: both iptables and ISP router firewalls
support outgoing connections out of the box, and your BBB is in
control of the traffic. You have to pay attention to DNS---DNS
spoofing is the principal vulnerability for this kind of setup
- if you need to connect to the BBB from the outside, you want to
limit the open ports and implement it in a cryptographically secure
way, by using SSH/SSL/TLS or IPsec. This is tricky to get right,
because there's always a possibility of vulnerabilities like
Heartbleed
A good term to google for is "hardening a Debian server."
There are many articles and several good books for people with various
backgrounds.
Before you can "hardening a Debian server" you have to make a "normal"
Debian Server out of it...
Login as root in the terminal (e.g. with putty from a win machine):
root@arm:~# adduser prz # add a new regular user with password
root@arm:~# deluser debian # remove the "Testuser"
root@arm:~# rm -rf /home/debian
root@arm:~# passwd # give root a real passwd
At this point I propose to install a "real" like apache:
root@arm:~# apt-get install apache2
Now you can check with a portsniffer e.g. nmap what ports are open on
your BBB but now your system should be fairly secure
btw, in the official Debian image on beagleboard.org/latest-images ,
there is an "un-tweak" script that'll undo some of the ssh things we
did to make "easier" out of the box, but less secure then a default
install.
cd /opt/scripts/un-tweak-image/
./debian-re-secure-root-ssh.sh
Regards,
Before you can “hardening a Debian server” you have to make a “normal”
Debian Server out of it…Login as root in the terminal (e.g. with putty from a win machine):
root@arm:~# adduser prz # add a new regular user with password
root@arm:~# deluser debian # remove the “Testuser”
root@arm:~# rm -rf /home/debian
root@arm:~# passwd # give root a real passwd
If a person can not figure this out on their own, they probably deserve to get rooted, or whatever else happens to them. Some would also argue removing root.
Personally I would avoid apache2 unless absolutely necessary, as it is fairly large. But then again my own rootfs is only 137MB ( bare-fs )
Removing root would certainly make it secure.
usermod -d / root
userdel -r root
will make it absolutely secure. Not terribly useful but very secure.
That also brings up the #1 dumbest idea in computer security.
I dont see how apache has anything to do with “securing” it.
Trying to make an embedded BBB into a product requires securing it. If it enjoys physical security there are some standard procedures you can use
and quite a bit of material on the Web. However, there are 3 entry points to a physically exposed machine: the USB client port, the SD port
and the RJ45 port. The RJ45 port is invariably needed and can be secured with software antics; I cannot find any material on how to disable
the usb and SD access points. By disable I mean you cannot use them at all; so yes, if your eMMC dies or you need to update you are toast.
It seems an embedded machine with a fixed set of functions can only be protected by placing epoxy on the SD and USB ports.
Forgot to add the ISP header; that may be tied to a tty port that can be disabled. Still working on that.
Trying to make an embedded BBB into a product requires securing it. If it enjoys physical security there are some standard procedures you can use
and quite a bit of material on the Web. However, there are 3 entry points to a physically exposed machine: the USB client port, the SD port
and the RJ45 port. The RJ45 port is invariably needed and can be secured with software antics; I cannot find any material on how to disable
the usb and SD access points. By disable I mean you cannot use them at all; so yes, if your eMMC dies or you need to update you are toast.
It seems an embedded machine with a fixed set of functions can only be protected by placing epoxy on the SD and USB ports.
You can disable whatever you want via the devicetree.
http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
Regards,
John
You can disable whatever you want via the devicetree.
http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
Regards,
John
Except all those devices are still active at boot.Which means both could be hijacked at boot time.
In order to secure these two devices, I think you’d have to do so from within uboot.
Thank you Herman - I thought the only time you can access the boot sequence is on the 6-pin header with a tty attached, so if
I could disable that I might have a prayer.
You can disable whatever you want via the devicetree.
http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
Regards,
John
Except all those devices are still active at boot.Which means both could be hijacked at boot time.
In order to secure these two devices, I think you’d have to do so from within uboot.
Yeah, good point, but given that you could insert a SDCard and press the BOOT button, you get to replace u-boot. Ultimately, you need to prevent physical access to the BBB to make it secure.
Regards,
John
John, you can override that behavior. It may require hacking the uboot source, but all that can be done
John, you can override that behavior. It may require hacking the uboot source, but all that can be done
Nop, this is a hardware issue. Pressing the BOOT button changes the order of the boot devices. eMMC isn’t even accessed when the BOOT button is pressed.
Regards,
John
It is if there is nothing in the SD slot. All the button does is change the boot order not the boot options.
Gerald
OK - but where do we go from here? uEnv.txt is out, device tree is out and everybody has to hack their own uboot to enable boot security?
I mean, when considering embedded Unix surely somebody that knows more about this than your average app-oriented developer could
provide a modifiable boot sequence that controls the options and immediately disables devices that are unneeded gateways into the system?
Encase the board in a gallon bucket of acrylic.. Should keep most evil
people away.
Regards,