Why Deploy Corda Firewall?
There are many potential threats within an enterprise network, but these largely fall into the following categories:
- Threats against assets held by systems inside the enterprise environment.
Threats against assets are classified as potential attack vectors against systems that control access to individual assets. This class of attack is typified by an attacker finding means to send messages to a victim system that manages an asset that will result in the asset being accessed or modified when it should not.
- Threats against the systems within that environment.
Threats against the network environment are classified as potential attacks systems to which a message was not apparently intended. This class of attack is typified by an attacker finding means to send messages to some victim system other than the one apparently intended as the recipient
- Denial of service threats.
Denial of service threats are broadly classified as attempts by other systems to prevent a local system from performing its intended purpose. This class of attack is typified by an attacker finding a way to send messages that fully consume some resource within a victim system. For example, this might be an attack that saturates connection tables, CPU availability, storage capacity, memory availability, networking bandwidth, etc.
Egress Data Path
Egress messages are generated by the local Corda node and forwarded through the internal firewall to a SOCKS 4/5 proxy. This proxy acts as a protocol break at the TLS layer since the TLS sessions from the local Corda node to external nodes are different. The SOCKS proxy terminates the connection from the local node and re-establishes a new connection to an external node.
Ingress Data Path
Ingress messages originate with a remote Corda node and are forwarded to the firewall float component within the DMZ. The firewall float terminates the TLS sessions from the remote node, using the TLS certificate provided to it by the local Corda node. The firewall float also acts as a protocol break as the ingress messages are held by the float until they are subsequently requested by the local node.
Note: The TLS connection from the firewall float to the local Corda node is optional, given the potential need to perform content scanning following the firewall float.
The ingress data path is the one primarily concerned with most of the threat models.
Threats Against Assets
Corda takes very great steps to ensure that underlying assets are protected against protocol-level attacks. Message encoding is a binary format, and thus much more precisely defined than text-based protocol designs. This, in turn, means that any structured content fields are precisely delineated and interpreted. Where any fields are presented to the vault database they are automatically escaped to prevent the possibility of SQL injection attacks. No content is simply “passed through”. Another class of potential attack against assets might be that requests were incorrectly formed or validated, but Corda requires that all transactions are not only well-formed, but also correctly signed by appropriate counterparts. Most importantly, Corda’s view of the correctness of transactions is not only defined by external requests, but also that the local node agrees that any such request is also correct from a business logic perspective. A request deemed invalid by the local node will be logged and rejected.
Threats Against the Network Environment
Corda’s use of AMQP and the firewall float means that there is no possibility of traffic ingressing to the DMZ being forwarded to any system in the production zone without the explicit control of the local Corda node. Traffic is not forwarded beyond the firewall float, and only the Corda node will pull data from the firewall float. This eliminates a number of potential attack vectors in which ingress traffic is scheduled such that it will be automatically forwarded to an unexpected host within the production zone.
Corda requires that all TLS sessions are mutually authenticated by both endpoints, and a requirement to participate within a Corda network is that both derive their root identity from a well-defined certificate issuer (root of trust). Actors outside of the Corda network will not have this and will thus see incoming connections rejected. Should an actor inside of the Corda network misbehave in a way that has DoS-like characteristics then it will quickly be detected, and the originator of the problem will rapidly be known by virtue of logging events. As each identity is issued by a common authority, then it is easy to determine which node, and thus which legal entity, is responsible.
For further details on the Corda Threat Model please use this link https://docs.corda.net/head/design/threat-model/corda-threat-model.html