Network security¶
Drasi is a heavily networked system, and as such potentially susceptible to various attacks over the network. It only implements some mild forms of authentication measures, and should therefore only be operated on a trusted network.
Trusted network¶
As explained below, the connection verifications that drasi do perform are in place mainly to avoid mistakes during operation, and not as security measures. Drasi should therefore only be operated on a trusted network. When operated on nodes that have access to other networks as well, firewall configuration need to prevent connections from the outside to ever reach drasi.
While some care has been taken in drasi not to trust the data sent from any client, and in particular before the verification steps, this should not be relied upon for security.
TCP port verification¶
Drasi instances are identified by the host they run on, and a fixed TCP port. Since only one process can bind and listen for connections on a specific TCP port on a node, the network layer ensures that no stale drasi process can interfere with operations. Every internal drasi connection (communication between master, slave and event builder as well as drasi data protocol) must be accepted by both sides, and on both sides the other end must be explicitly given (together with any other configuration parameters).
When an internal drasi connection is made, the client (B) that initiates the connection begin by telling the server (A) from which instance it connects (i.e. its server TCP port). This information can however not be verified from the details of the TCP connection (only the source IP number is given), and thus must be independently verified. (If it does not match configured details of any expected incoming connection, it will be closed immediately after sending a failure response.) The instance (A) that just received the connection will make (or already made) a connection as a client (A) to the other server instance (B) where the first connection should originate (i.e. according to the configuration of B, in particular the just given TCP port number). When the first connection request is received (by A), a random number is sent (from A) over the second (back-link) connection, and (B) shall provide that to (A) over the first connection.
The purpose of this mechanism is to ensure that drasi instances talk to the expected other instances. It is easy for network sniffers to pick up the verification number, thus it is of little use for security purposes.
The above mechanism applies to the following connections, which always need to be used in pairs between the processes:
| Task(thread A) | Command | Task(thread B) | Command |
|---|---|---|---|
| Readout | --eb=B |
Event builder | --eb-master=A |
| Readout (data) | --server=drasi,dest=B |
Event builder | --drasi=A |
| Trig bus master | --slave=B |
Trig bus slave | --master=A |
Only allowed IP numbers¶
The following is not implemented yet.
Other connections (monitoring, control operations and transport and stream protocol data transmissions) are initiated by clients that do not themselves hold a specific port. Thus the reverse port verification cannot be performed. All incoming connections must however come from IP numbers (or ranges) that have been listed in the configuration of the drasi server instance. Allowed IP numbers are given per kind of connection. Host names can also be used, they will be looked up (translated to IP numbers) at the time the server starts (thus wild-cards cannot be used).
This does provide some limited form of protection, since an attacker at least would have to be able to intercept packages to a machine with an allowed IP number.