Project

General

Profile

Security Issues

The primary level of security used to protect our control system is to locate it, in its entirety, behind a firewall. This limits our "attacks" to internal software bugs -- mostly resulting in DOS situations (too many open connections, too much traffic, etc.) With the addition of Javascript and mobile device clients, we are making the ACNET control system available to a larger audience. We need to make sure we're doing all we can to minimize disruptions these new clients can cause to the control system, both accidental and malicious.

This article tries to itemize various limitations we recognize in the ACNET transport layer.

Forged Headers

The ACNET protocol is actually a payload of UDP, so it inherits any security implications. Although acnetd validates every packet that it receives and sends, a malicious client could forge a UDP header to make it appear to be a valid reply, for instance. It should be noted, however, that this form of attack can only be done inside the controls network. Javascript clients are sending their data over a WebSocket (i.e. TCP) and the data is forwarded to ACNET by trusted nodes.

WebSocket interface

We've recently added support for WebSockets, meaning a client using a WebSocket can be an ACNET client. This sections covers the security decisions we made for this interface. Of all the ACNET implementations used in the control system, acnetd is the only one that supports this feature, so we'll simply focus on it.

acnetd gets this support through a compile-time option. Currently, the only ACNET system running a WebSocket-enabled acnetd is FGATE. To enable this feature, build using "make TCP_CLIENTS=1". Command line options are used to further control access. The "-t" option is needed to make acnetd open the TCP connection; without it, the UDP interface is all that is available. This means we could install a WebSocket-capable version on every node but only enable it on the nodes that will participate in the WebSocket pool. There is another option "-r" which accepts a list of ACNET handles. As requests are made through the WebSocket interface, acnetd checks if the target task matches any in this list and, if so, sends an error back to the client. We specify SETDAT, SETS32, DBNEWS, STATES on FGATE to prevent outsiders from doing settings or sending bogus DBNEWS reports and STATES changes.

Our web server is configured as a WebSocket proxy. The configuration allows load balancing among several WebSocket nodes but, at the moment, only FGATE is specified in the pool of nodes. FGATE's firewall is configured to only accept WebSocket connections from the web server. Disabling the web proxy, changing FGATE's firewall, or shutting down acnetd on FGATE will prevent access from web applications and mobile devices.