This article tries to itemize various limitations we recognize in the ACNET transport layer.
The ACNET protocol is actually a payload of UDP, so it inherits any security implications. Although
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
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
FGATE to prevent outsiders from doing settings or sending bogus
DBNEWS reports and
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
FGATE will prevent access from web applications and mobile devices.