Handling LAN and Internet Traffic

​​Background​

MCSR (Minimum Cyber Security Requirements) are sets of umbrella terms governing development and deployment of software services made by ABB. Among these terms, several result in special networking behaviors being implemented on an Edge computing device.

Objectives​

Starting with applicable MCSR terms, the following interpretations were made and agreed upon:

• GCSC-MIFP-RE.8 - The OS enforces strict isolation between the user-space processes, and the Edge computing device asks the business unit to prepare and use two (or more) network interfaces, one of which is dedicated to Internet connectivity, and others dedicated to LAN communication.
• GCSC-MP-RE.4 - Only the ports required by the system and application are enabled. Debugging symbols are never installed. There is a capability to disable or block any ports not required by the product. The host OS is a standard minimum installation; therefore, no additional software is present in it.
• GCSC-MIFI-RE.4 - Endpoints (i.e. IP addresses) are reduced to the minimum necessary. Only necessary services and ports are enabled. Any additional system components are not installed in the first place. Direct management across the internet is disabled.
• GCSC-MIFI-RE.2 - Internet and LAN networks are logically isolated. No routing takes place between the networks. All traffic is filtered and subject to a strict system firewall. Load balancing is not involved, and therefore not applicable.

Bridge Network and Firewall​

The latest implementation satisfies all of the requirements above by employing a strict system firewall that activates as soon as the network comes online, never exposing the system to the network without firewall protection. Once the appliance is deployed at the customer's site, the customer may freely install any number of network interfaces for LAN communication over any valid LAN IP block, as permitted by the system firewall. The system firewall protects the appliance from incoming contact initiated by any number of Internet-connected networks.

In addition, should internet traffic arrive at any LAN network - e.g. the operator mistakenly swaps a network cable socket, or a router is mistakenly exposing Edge to the Internet - the system remains protected as the firewall correctly identifies the origin of the traffic and blocks it accordingly. In the unlikely case of a compromised upstream router spoofing the source IP address, or a malicious router configuration masquerading the internet IP address to look like LAN, a fallback in the comprehensive firewall setup will block such traffic and prevent incoming connection/contact. The fallback relies on additional user input (configuration key BLOCK_INCOMING_CONTACT_ON_IFACE in /var/ability/config/edge.env) to function. Therefore, on the Edge computing device, administration tasks cannot be carried out via LAN through the network interface that offers internet connectivity.

Keep in mind that the application alone may make various guarantees as to which specific network it receives traffic from. However, applications are far more complicated than a system firewall, therefore it is not sufficient to rely entirely on such application behavior. In such cases, the system firewall continues to provide adequate protection.

Flexibility in the reference Edge implementation allows LAN traffic to originate from all valid LAN IP ranges (127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16). If it is necessary to further restrict the IP ranges, the business unit may choose to deploy additional firewall rules upon successful installation of the reference Edge software stack. See more details in the Advanced Edge Configuration page manual for an example.

Direct Access to Layer 2 Connectivit​​​y​

Prerequisites

In order to transmit and receive IP multicast packets, all participating switches and routers must be capable of handling IP multicast packets and their security policy must allow such packets to flow in the network. This simple experiment can be used to determine whether networking equipments are capable of handling IP multicast:

(Assuming that computer A and computer B are connected to the same IP router with any number of switches in between): Run "netcat" utility on computer A (receiver): nc -l -u -p 1234 Run "netcat" utility on computer B (transmitter): echo hi | nc -u -p 224.0.0.1 1234

If the receiver successfully receives message "hi", then the networking equipments are indeed capable of handling IP multicast.

Configuration

During the manufacturing phase, the business unit will draft network topology requirements and ask for a vacant block of IP addresses to be assigned to container instances eligible for IP multicast. The product installer, now enhanced with new configuration parameters (/var/ability/config/edge.env), will carry out the initial configuration of this layer-2 container network. The new parameters are:

• LAYER2_CONNECTIVITY_HOST_IFACE: the name of the network interface on the container host that offers layer-2 network connectivity. It must offer LAN connectivity exclusively and must not offer internet connectivity. Business units are advised to carefully inspect the network interface naming convention employed by the OS, and then to customize this configuration value accordingly.
• LAYER2_CONNECTIVITY_GATEWAY_IP: the IP address of the network gateway on the host network interface.
• LAYER2_CONNECTIVITY_SUBNET_CIDR: the IP address block corresponding to the host network interface.
• LAYER2_CONNECTIVITY_CONTAINERS_CIDR: the IP address block vacant within the host network and ready to be allocated to eligible containers as they come online. Without thorough customization of the new parameters, the installer will not prepare direct layer-2 connectivity by default.

Deployment

In the type definition created for the business unit module (abb.ability.configuration.edge.modules.BUModule), introduce a new property unrestrictedNetworkAccess under the docker key:

"unrestrictedNetworkAccess": {
    "description": "Gives container unrestricted network access",
    "dataType": "boolean",
    "value": false,
    "isMandatory": false
  }

In the corresponding information model, set the new property's value to boolean true:

"docker": {
    "image": {
    "value": "abbability.azurecr.io/abb.ability.iotedge.referencemodule:1.0.0"
    },

    "unrestrictedNetworkAccess": {
    "value": true
    }
}

The proxy software component on the Edge computing device recognizes the new property value and attaches the container service to macvlan network prepared on the container host. The container service may then freely choose to use layer-2 connectivity for IP multicast, or the regular LAN bridge network that remains available, or both at the same time.​