Securing the device (Dunfell)

Owned by Hai Nam Tran
Last updated: 24. Jan 2023 by Bernd Mierzowski
6 min read

Security for embedded systems is a serious issue, though often overlooked. This chapter gives an overview of common security risks that might occur during the deployment and lifespan of the product. We also give hints and tips on the implementation of some chosen security mechanisms. Since we are not able to cover every possible risks in the manual, users are strongly recommended to read on further topics regarding these issues.

For the following list of security risks, no claim of completeness can be made. There may arise other risks or - on the opposite - limitations in the design of your application by following the instructions provided in this chapter.

Services

SECO Northern Europe devices are initially shipped with a “developer friendly” state. That means, all services are available and already activated. This provides a helpful state on which customers can easily deploy further application. However, leaving those services unchecked can lead to potential security risks. Once the customers have finalized their deployment on the devices, we recommend a review of the services in-used and to disable all those that are not required for the applications. See chapter [Services] on how to disable.

Independent of the device’s application, following special cares need to be taken:

SSH

An SSH services is enabled by default on SECO Northern Europe devices with Yocto. In addition to the password and user suggestions from [User permissions concept], there are more hints on securing the ssh service in the chapter [SSH service]. It is possible to restrict users allowed using this service, lock SFTP access to a subfolder only and create custom crypto keys.

User permissions concept

Linux is designed as a multi-user system and provides a mechanism known as file permissions. Each file has an owner, a group and flags that grant write, read and/or execute permissions to the owner, the group or anybody. Additionally there is a super user, called root, who has access to all files. More information on this concept can be found here.

Customers should follow the principle of minimal privilege for user rights on the devices. Please note that SECO Northern Europe tools are usually assigned with access rights for all users since it is more developer friendly.

Root password

Since SECO Northern Europe is an OEM manufacturer and we are delivering serial-produced devices to several customers, a default root password would lead to a form of pseudo security. Moreover a default password for all devices is highly vulnerable. For this purpose our devices usually have no root password set. It is essential that a password will be set by customers before the devices are deployed. This is the minimum security measure to be done.

root@santaro:~# passwd root Changing password for root Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New password: <enter your secure password> Re-enter new password: <enter your secure password> passwd: password changed. root@santaro:~#

What does it mean if no root password is set? Without root password, anyone connect to the device will have full system control since root user usually have all permissions on the system.

Blocking root access. Linux offers the opportunity to disable the root-login for specific services like ssh, or the serial console. Since the root login is always a popular target for attackers this easy mechanism will decrease the risk for those kinds of brute force attacks.

This can be done by setting the root account’s shell to /sbin/nologin in the /etc/passwd file:

root:x:0:0:root:/root:/sbin/nologin ...

Ensure that another user account with the possibility to gain super user (su) rights is created before the root access is disabled. Otherwise, you might completely lose access to the device.

Non-root users

Normally a non-root user should be used for "everyday tasks" on the system.

The tool adduser can be used to create a non-root user

root@santaro:~# adduser <user name> Changing password for <user name> Enter the new password (minimum of 5 characters) Please use a combination of upper and lower case letters and numbers. New password:<enter your secure password> Re-enter new password:<enter your secure password> passwd: password changed.

This creates a new user <user name> with group <user name> and the home directory /home/<user name>/.

The new user can be used to login immediately. See the man page of adduser for more options.

Superuser privileges for non-root users

sudo allows non-root users to have access to single commands with root user privileges. If login for root user is disabled, this can be used by non-root user to do system tasks. To enable usages of this feature, the group sudo should be enabled in the sudoer file and the user needs to be added to this group.

Edit the file /etc/sudoers with the command:

nano sudo

and uncomment the following line:

%sudo ALL=(ALL) ALL

This enables the sudo privilege for users in the group "sudo". To add a user to this group, execute the following command:

usermod -G sudo -a user

Now it is possible to execute commands with root previleges when logged in as <user name>:

user@santaro:~$ cat /etc/sudoers cat: can't open '/etc/sudoers': Permission denied user@santaro:~$ sudo cat /etc/sudoers Password: ## sudoers file. ## ## This file MUST be edited with the 'visudo' command as root. ## Failure to use 'visudo' may result in syntax or file permission errors ## that prevent sudo from running. ...

Flash-N-Go System

Newer SECO Northern Europe devices are equipped with an Flash-N-Go System as backup OS. Within Flash-N-Go the user has full control of the device’s configuration and the partitions on the flash disk respectively eMMC without a password or further authentication.

As described in [Deploying the Linux system to the target] booting into Flash-N-Go System can be triggered by pressing the bootmode switch or with the bootselect tool from the yocto OS.

The bootselect tool can only change the bootmode when called with root privileges, so following password and user suggestions from [User permissions concept] should solve this issue.

The bootmode switch should be secured with restricting physical access by the mechanical construction.

If this is impossible, it is recommended to disable the backup OS.

Execute following command sequence:

root@gufboardll:~# mount /dev/mmcblk0p2 /mnt/ root@gufboardll:~# mv /mnt/boot.cfg /mnt/boot-alt.cfg root@gufboardll:~# umount /mnt/ root@gufboardll:~# mount /dev/mmcblk0p1 /mnt/ root@gufboardll:~# mv /mnt/boot-alt.cfg /mnt/boot-alt.cfg.bak root@gufboardll:~# umount /mnt/

This change disables the access to the backup OS Flash-N-Go System completely. If the normal OS becomes inaccessible for some reason, there is no way for a customer to fix the device.

Updating the system normally without the backup OS Flash-N-Go System is impossible. Though it is possible to revert the change and re-enable Flash-N-Go System from the normal OS, if it is functional.

Networking

Firewall - netfilter/iptables

By default, all network communication is allowed. However, Linux can be configured to block certain IP packets depending on its header (e.g. by port or by protocol) using iptables, which is basically a firewall. As this mechanism is very powerful and complex, it is not documented here in detail. Please take a look at the following link for a basic introduction.

As a first start we show some basic usecases here.

If you call these commands from a network login, your connection will/could break. Without physical access to the serial or USB console, you won’t be able to access the device anymore.

Block all network traffic:

root@santaro:~# iptables -F root@santaro:~# iptables -A INPUT -j DROP

This is the first step and it is a mandatory preparation for the following steps.

Open SSH access only:

root@santaro:~# iptables -I INPUT 1 -i eth0 -p tcp --dport 22 -m state --state NEW, ESTABLISHED -j ACCEPT root@santaro:~# iptables -I OUTPUT 1 -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

Open network access on port 80 and DNS replies on port 53 from the device:

root@santaro:~# iptables -I INPUT 1 -p udp --source-port 53 -j ACCEPT root@santaro:~# iptables -I OUTPUT 1 -o eth0 -p tcp --dport 80 -m state --state NEW, ESTABLISHED -j ACCEPT root@santaro:~# iptables -I INPUT 1 -i eth0 -p tcp -m state --state ESTABLISHED -j ACCEPT

Save the firewall configuration as persistent:

root@santaro:~# iptables-save > /etc/iptables.rules root@santaro:~# echo "iptables-restore < /etc/iptables.rules" > /etc/network/if-pre-up.d/iptables root@santaro:~# chmod +x /etc/network/if-pre-up.d/iptables

Disable the firewall:

root@santaro:~# iptables -F

Using secure network protocols

Newer and more secure network protocols, e.g. HTTPS, FTPS and SSH, are strongly recommended over their outdated counterparts.

Further mechanisms regarding the security for network connected Linux systems are described here.

Restrict physical access

Each physical interface like USB, SD-Card or Ethernet socket can serve as possible entrance gates for attackers. Unessential ports should be physically disabled or restricted from easy outside access. This reduces the likelihood that an attacker can connect to the system and therefore lower the risk of a potential security issue.

Application security

Application security is seldom a high priority for embedded devices. But it is, of course, essential to take account of identifying risks in embedded applications. Since application development is a very complex subject and it is out of scope for SECO Northern Europe, we will refer to secondary lecture at this point.