Improving security for network-connected, embedded Linux based systems

Kirill Marinushkin is an Embedded Software Developer at Argus-Spectr. He designs embedded systems for sensor networks. Kirill has developed devices with secure remote access over TCP/IP and wireless protocols.
Embedded systems‘ ability to access devices over the Internet or local networks facilitates a wide range of convenient interactions. The evolution of the Internet of Things (IoT) means fast growth of embedded networks. For these applications, network communication appliance has become a great issue. The resources of embedded systems are too limited and may hardly provide reliable protection against cyber attacks. High-performance devices with Linux may have advantages for secure network access.

Scripts and techniques can improve the security level of network access for these Linux-based devices. The goal is to access a device as a network security for remote control and administration. This can be conducted in two levels: the SSH-level for secure remote shell access and SFTP file transfer, and IP-level protection.

Configuring user permissions for SSH access

The SSH server options include a number of methods to limit user permissions. For both secured shell and SFTP services, the options “PermitRootLogin”, “AllowUsers”, or “DenyUsers” limit the logins able to connect to the device over SSH. For SFTP, more parameters are available to change the root directory paths. This method is important to protect the system parts that include critical and confidential data. This option allows the configured users to operate only inside their directories and sub-directories, so you can leave them in their “sandbox.” The option “Subsystem SFTP internal-SFTP” combined with “ChrootDirectory” allow to change the root directory for specified users. The “ChrootDirectory” section for all configured logins should be placed at the end of the configuration file. When setting up the directories for different users, the owner of that directories should be a root user.

To configure the network security SSH permissions, edit the file /etc/init.d/sshd_config as in the example:

For performing non-standard user access to your embedded Linux application in the embedded system, it is convenient to use the SSH protocol as a secure layer for network communication appliance.

A common way is to run your service as a server listening to the specified TCP port. To provide the SSH connection, you may use “libssh” – an open-source project licensed under the LGPL. The project has several examples including the sshd source code that provides a great basis to build your server application. Note: this solution is not connected to the OpenSSH server and requires its own port number and user management.

Another option is to use the existing running OpenSSH server for your service. The idea is to replace the shell utility with your own application for specified users. This time users would interact with the remote system over the standard input/output interface like a terminal. This solution is a more efficient way to organize secure remote access with the exact functionality you need. To replace the shell for users, edit their parameters in the “/etc/passwd” file by replacing the last option with the path to your application.

“Iptables” is a powerful tool for protecting remote access to the target Linux system at the IP level. Iptables allows the system to filter the traffic independently of the application-level network protocol. It is the most universal option that may work for almost every platform.

Iptables support should be turned on during the Linux kernel configuration. Pay network communication appliance that some necessary iptables options like “conntrack” or “connlimit” may be turned off in the kernel by default so turn them on to use more iptables possibilities.

Launching iptables script on system start
The iptables utility embedded Linux works as a network traffic filter. The filter is performed as chains of rules applied by running the “iptables” command with different parameters. The rules are set together in a script file. To put the iptables to the initial state, begin the script with the example rules below.

Prevent brute force attacks
Brute force is the biggest security problem when using the SSH protocol. A simple firewall can be set up using iptables to prevent brute force attacks. The idea is to block the IP addresses that flood the SSH port and limit the maximum number of opened connections. The script below serves this purpose.

Whitelist/blacklist IP addresses
If the clients’ IP addresses are static, the best way to perform network communication appliance is to allow access for certain IP addresses only. That means no other user except the specified ones would be able to access the target embedded system remotely. This may be done by creating a whitelist of legal IP addresses. For the example script below, the admitted IP addresses are written down in the file line by line like this.
The described services and methods use the IPv4 protocol. The secure configuration of the IPv6 protocol is ignored, which makes it unsafe to keep enabled. If IPv6 support is turned on in the kernel, then it should have additional protection. Or, if you don’t need it, you may just turn it off by adding this line in the /etc/sysctl.conf file.

SSH-level security
Remote access over SSH shell and SFTP presents the greatest opportunity of controlling the target embedded system with Linux. Enabling this function is a convenient way for administrating the device. The SSH protocol performs a high level of security and cryptography. There are several possible configurations of the “sshd” utility associated with the SSH shell and SFTP server services to improve SSH-level security.

Among popular Linux distributions for embedded systems (such as Angstrom or Arago-project), the “Dropbear” utility is a default SSH server. Unfortunately, it provides a limited set of configuration options. Important configuration possibilities such as users’ permissions are disabled in this utility. So if the target device is going to have remote access, installing “OpenSSH” server would be a better idea. To change the SSH servers, remove the Dropbear starting script (or move it, like in the example below) and install the OpenSSH package:

refer to: