Securing the Network

To implement a secure ActivID Appliance authentication system, it is important to understand the communication dependencies between ActivID Appliance and other components within the overall network system.

Critical Warning about Cookies

All browsers MUST use cookies to avoid becoming liable to session hijacking. For further information on Cookie Theft/Session Hijacking, go to https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Cookie_Theft/Session_Hijacking

Critical Warning about IPMI

Intelligent Platform Management Interface (IPMI) runs on a small, self-contained server (a motherboard extra chip) called a baseboard management controller (BMC). BMCs have small, but mighty controllers. Nevertheless, a BMC will go down if it is subject to either a denial-of-service (DoS) or a distributed denial-of-service (DDoS) attack.

During installation, you must completely restrict all inbound and outbound network access and communications to any BMC installed. BMCs have no network defenses or firewall capabilities, so you must do this at the network layer (for example, routers, switches, network devices, etc.).
Never permit network traffic from the outside world – that is, from any resource not in the management network zone – to access a BMC’s active IPMI network interface. This means no Serial over LAN, no web interface, and no IPMI protocol (UDP 623).
Keep all IPMI network interfaces on their own segregated network.
Optimally, the IPMI-managed network segregation should be physical. At a minimum, you must have the interfaces on a separate virtual LAN (VLAN). If the added complexity of managing a separation will cause too many problems for your installation, then you must physically segregate the IPMI-managed network.
When you enable IPMI in the Basic Input / Output (System BIOS) you must have the dedicated network interface controller (NIC) connected to the monitoring network. If a dedicated NIC is not connected to the monitoring network, then the IPMI will use any other available NIC which could expose the IPMI/BMC to the public!

Recommended Network Deployment

The following figure illustrates the recommended network deployment and typical communication flows.

As illustrated in the previous figure, network deployment can mean a configuration that requires connectivity with a variety of external components. ActivID Appliance must be connected to, and accessed by, network devices and clients. This requirement makes those devices and clients vulnerable to cyber-attacks that might be targeted at the ActivID Appliance hardware and its related software.

The best way to protect ActivID Appliance and related dependent entities from network-based cyber-attacks requires a layered approach that is based upon the Open System Interconnection (OSI) model, which consists of seven layers. The layers relevant to the network communication are layers 2 to 4, specifically the Data Link, Network, and Transport layers. The following figure illustrates the seven layers of the OSI model.

Note: A detailed explanation of the OSI model is beyond the scope of these recommendations. The illustration of the OSI model is included for reference purposes only. HID Global assumes that the reader possesses an in-depth knowledge of the seven layers or is willing to access additional reference sources for this material.

Recommended Network Configuration

To prevent Layer 2 attacks, devices that are located on the same IP network must be unable to communicate with each other using the Data Link Layer. A separate network must be used for ActivID Appliance and related software, and this network must be separated both physically and logically from any other device.

In some network environments, the previously suggested level of separation is neither practical nor feasible. In such cases, ActivID Appliance should be protected at the Data Link Layer by using private Virtual Local Area Networks (VLANs). Using private VLANs (PVLANs) or using a separate physical network forces all communications to be routed, and thus pass through a Layer 3 device (such as a router, firewall, or a Layer 3 switch).

Note: Standard network switches operate at the Layer 2 level in the OSI model, while a Layer 3 switch is a high-performance device that performs network routing and can support the same routing protocols as network routers do.

Every device on the network infrastructure should be configured with Access Control Lists (ACLs), including switches, firewalls, and routers. ACLs can be customized to adapt to the environment in which they are used, and should be implemented using the minimum privileges required to perform the desired tasks. The ports required for ActivID Appliance communication are listed in the following table.
ActivID Appliance and related software should be deployed with two separate network interfaces – one interface which is made public for ActivID Appliance operators and users – and another interface used for connections with back-end components and potential back-up systems.
Intruder Detection Systems (IDS) should be deployed on both network segments that are connected to ActivID Appliance. Host-based Intrusion Protection Systems (IPS) should be installed on ActivID Appliance.

Rate Limiting and Denial of Service Prevention

ActivID Appliance does not embed a rate-limiting feature. It is recommended that you deploy it behind a reverse proxy, load balancer, API Gateway or Web Application Firewall that provides this capability to prevent resource starvation and Denial of Service attacks.

The rate limits to set depend on the deployment architecture and the workflows that ActivID Appliance will serve. For example, a customer using API-based or RADIUS authentication flows, would need to allow hundreds of requests per second (or more) as the requests come from a small number of client applications that manage the connections of all the end users.

However, a customer mainly using ActivID Appliance for Single-Sign On, SAML, or Push Authentication should consider much lower threshold as the end users are connecting to the ActivID Appliance without intermediary. In the latter case, it is suspicious for a single client to request many authentications in a very short period of time.

In general, it is advised to define a configuration that differentiates System Users (that is, RADIUS front-ends, Service Providers, Open ID clients, etc) that are typically in an internal network and need a high rate and burst to operate, from end users (connecting via browsers to access the ActivID Authentication Portal and HID approve apps) that might come from the internet and should be more strongly rate-limited.