Overview

Note: Readers should be familiar with the terminology in ROS/Concepts.

ROS is a distributed system: it provides a mechanism for nodes to exchange information over a network. By definition, networks are shared resources, so it is important to consider security aspects of connecting systems using ROS.

By default, a ROS master will respond to requests from any device on the network (or host) that can connect to it. Any host on the network can publish or subscribe topics, list or modify parameters, and so on. If an unauthorized user can connect to the ROS master, they could leak sensitive information (such as data from sensors or cameras), or even send commands to move a robot, which creates both a privacy and a safety risk.

For this reason, a ROS master should never be connected to the public Internet--or any network with users not authorized to use it--without taking additional steps to restrict access to the system. This page describes two strategies for limiting access to a ROS master node:

• Using the network to restrict which hosts can access systems using ROS, such as creating an isolated network or using a firewall
• Extensions to ROS that can authenticate users before allowing them to make commands

Using the network

If possible, we suggest using ROS on a network not connected to the Internet, or on a network behind a firewall configured to block incoming traffic on the ROS master port (TCP port 11311).

A common configuration is to run ROS hosts on a separate network behind a consumer router that performs Network Address Translation (NAT) to allow multiple devices to share the same public IP address. This is common in most home networks, or research labs that create separate networks for robot platforms. By design, NAT blocks incoming connections that were not initiated by internal hosts, so a master behind a NAT would not be visible to the Internet by default. While NAT provides a first step to blocking external traffic, NAT is not a security apparatus: a NAT may be misconfigured or exploited to open ports for outside access, so we recommend using a more complete firewall solution, as described below.

When using an isolated network or NAT, you can enable users from outside the network to access the network using a Virtual Private Network (VPN) or other tunneling solution. Using a VPN is the recommended method for enabling outside access for a group of authorized users. A common open-source VPN is OpenVPN; other solutions may be available using your organization's network resources. Note that a simple SSH or HTTP proxy is insufficient as nodes must connect to each other on a number of ports.

If the general public must access certain parts of a ROS architecture (for example, as part of a web application), we recommend investigating Rosbridge.

Some university or other campus networks assign public IP addresses to each host on the network. Without other access controls, these hosts are directly reachable from other hosts on the Internet. Thus, users working on these networks should configure a firewall (such as iptables) to block connections from outside your network--see Further Reading for guides on how to do this.

When using ROS research labs or other organizations, we recommend consulting with your organization's IT staff to devise a comprehensive firewall mechanism for protecting your systems. IT staff may be able to provide help configuring systems, or tailoring campus network resources to create a secure environment for ROS hosts.

1. ROS on Mobile systems

Users who run ROS on a laptop or other mobile system should be conscious of the network they are using when running ROS. For example, a laptop that uses ROS in on an isolated research network and then moves to an open university may be at risk if the master is left running. We recommend that users of mobile systems be conscious of when ROS is running when moving between networks, or configure a local firewall such as iptables.

2. Configuring a firewall

This guide is not intended to provide a comprehensive explanation of how to configure a firewall. To do this, we recommend consulting external resources, such as those listed in Further Reading.

To configure your firewall, you must decide what range of IP addresses represents the set of IPs that should be allowed to connect to it, which we refer to as the "internal network". The internal network could be your research lab network, just one or more IP addresses, or your entire university network--it is up to you to decide an acceptable range of IPs based on your requirements.

At minimum, your firewall should do the following:

• Permit all traffic to the ROS master port (TCP port 11311) from the internal network, to allow ROS master traffic
• Permit all new TCP and UDP connections from the internal network on any port to allow for connections from subscribers
• Permit traffic on ports for other services that may be needed (like SSH)
• Block other new TCP and UDP connections from other networks (this can be handled by setting the "default" policy on incoming connections)

Extensions to provide security

If you need to add security features in the ROS platform itself, we recommend investigating the following options:

• Rosbridge: A WebSocket interface to ROS and a server to allow web applications interact with ROS nodes. This can be useful if you need to permit access to ROS from the public Internet, to enable a web application or other access by other users.

• SROS: An architecture to add TLS (Transport Layer Security) support for ROS transport mechanisms

• ROS2 middleware is based on DDS. ROS2 utilizes the DDS-Security standard to provide configurable authentication, authorization, and encryption mechanisms.

ROS Internet mapping project

The ROS Internet Mapping Project is an effort to scan the Internet for open ROS masters. You can find more information about the project and further recommendations for providing security at: https://systems.cs.brown.edu/robotsecurity

Further reading

1. Configuring a host-based firewall

• https://linux.die.net/man/8/iptables

• https://www.digitalocean.com/community/tutorials/how-the-iptables-firewall-works

• https://www.howtogeek.com/177621/the-beginners-guide-to-iptables-the-linux-firewall/

2. Overview of Network Address Translation and addressing

• https://whatismyipaddress.com/nat

• https://en.wikipedia.org/wiki/Network_Address_Translation