Following lots of rude interruptions from the Wolf, Hans decided the Arduino Yún's security needed beefing up. After a bit of reading Hans realised that this could be a 16 week design challenge in it's own right.


Hans' plan of action for the lock down was as follows:


  • Users and passwords
  • Handle brute force attacks
  • Remove unused functions
  • Apply principle of least privilege



Hans had already changed the default root password to something unique but realised if he was sending out lots of IOT devices it would make sense to have a mechanism where you could provide everyone of them with a unique default password. This could be printed on a label on the bottom of the device so if it was reset to defaults it would take this rather than something that people could google for.


It's possible to check the user accounts by looking at the passwords file.


cat /etc/passwd


Installed by default on the Yún are the following:



Given that there's no FTP then the FTP user is a candidate for removal, although it would make sense to check that is not used for the WebUI.


We can disable the accounts using


passwd -l username

Brute Force

The Enchanted Cottage has some protection against brute force attacks in that the Linino portion and hence the Wifi is turned off for most the the time hence there is no way to connect. However in the computer world the few seconds that the system is up and connected should sufficient for a break to be attempted.


The two areas that could be vulnerable to this are the Web Admin UI provided by Arduino and the SSH port. It might be possible to turn these off. Given that these are used to fix or configure the device that's maybe not a good idea.  It's also possible to configure SSH to use certificates rather than password for login. To do this on the finished product we'd need to have some way of getting the keys back and forth.


This can be setup by following the instructions for setting up Drop Bear SSH for Public/Private Key authentication


The best method for handling brute force attacks is to use a intruder detection system such as Fail2Ban which uses the inbuilt firewall IPTables to lockout IPaddress that have strange activity patterns. The only dependency for Fail2Ban appears to be Python so for the cottage this seems like a good solution. The module is not yet available as a downloadable OPKG package but it can be installed manually. Fail2ban install on GNU Linux


The daemon file need tweeking to run on this platform, one from RedHat was used as a basis.


and this was tested with

/etc/init.d/fail2ban start



/etc/init.d/fail2ban stop


Removing features

Whilst Hans was researching security he had a visit from the Woodcutter who wanted to see how the build was coming on. Whilst they were wandering around admiring the structure the Woodcutter tripped on a stump and reached out and grabbed the nearest thing to him, a hanging basket of flowers. The chain supporting the basket broken and the basket and Woodcutter went crashing to the ground. The Woodcutter picked himself up and brushed off the soil and flowers. He looked at the basket on the floor and said "a chain is only as strong as it's weakest link". He picked up the basket, passed it to Hans and wandered off into the forest.


Hans realised that there were features on the Yún that were not being used. These could be removed to stop them being the weakest link.


Looking at the list of installed packages there seems to be some candidates for removal.


  • avahi - A Zero Configuration network tool.
  • cpu-mcu-bridge - The bridge, this is already swapped out so is not used.
  • spacebrew - A friendly wrapper for APIs
  • temboo - A friendly wrapper for APIs


Hans also wondered about avrdude, the tool for putting new sketches onto the AtMega. But removing that would stop the end user applying patches over the Wifi.


opkg remove temboo
opkg remove spacebrew
opkg remove cpu-mcu-bridge


Removing avahi raised a warning that it was used by depended on by other package so it was not removed at this time.


The other key feature to review is the Rest API, the uhttp webserver publishes data on the Arduino pins and can control the ATMega via a correctly constructed URL.




We can disable the Arduino specific end points by editing the /etc/httpd.conf file to comment out lines by putting an # in front of them.




Principles of least privilege

This security concept is basically don't give more permissions that is needed to do the task required. Then if anything goes wrong or there's a security loophole then a hacker is less likely to be able to escalate their privileges further.


Again, swapping out the bridge code with the reduced functionality of the python script means that the ATMega has access to less of the Linino side. However, python is running as root, which is a bit much given that it only needs to read a configuration file and get a file off the network to process and send via serial the ATMega.


There are tools to help lock down these permissions such as SELinux but it would appear that these would need the Kernel patching which unfortunately means I don't have time to implement this process.


Next: Enchanted Objects Design Challenge - Tools



SSH Tutorial for Linux - Support Documentation

MQTT Security Fundamentals - Securing MQTT Systems

The 10 challenges of securing IoT communications  |  Atmel | Bits & Pieces List of Yún packages

Welcome to pySerial’s documentation — pySerial 2.7 documentation

20 Linux Server Hardening Security Tips

operating systems - Hardening Linux Server - Information Security Stack Exchange

Using REST with Arduino Yun | Open Electronics

Web Server Configuration (uHTTPd)

What is the principle of least privilege?

Minimize Privileges

SELinux The_security_context_of_a_process