securing your network with arcos®

TM

W H I T E P A P E R

Securing Your Network with ArcOS®

1

WHITE PAPERSECURING YOUR NETWORK WITH ArcOs®

Table of Contents

Introduction ..................................................................................................................................................................................................... 2

Secure Device Infrastructure ................................................................................................................................................................... 2

Image Signing and Validation ......................................................................................................................................................... 2

Administrative Interfaces ................................................................................................................................................................ 3

User Access Methods ......................................................................................................................................................................... 3

User Accounts and Role-based Access ....................................................................................................................................... 3

New Services and Packages ............................................................................................................................................................ 4

Secure Control and Data Planes .............................................................................................................................................................. 5

Control Plane Protection .................................................................................................................................................................. 5

Secure Routing ...................................................................................................................................................................................... 6

Secure Operations ......................................................................................................................................................................................... 7

Monitoring Resources, Processes, and Logs ............................................................................................................................ 7

Security Updates .................................................................................................................................................................................. 8

Secure Telemetry ........................................................................................................................................................................................... 8

Summary ...........................................................................................................................................................................................................9

2


Introduction

In our hyper-connected digital world, a robust, scalable network infrastructure that maximizes visibility, control, automation, data security, and privacy is a top priority for network operators. Implementing proper security procedures and best practices is critical to mitigating any internal or external threats from compromising the network and disrupting the business. Fundamental to these security procedures is proper configuration and monitoring of the network operating system (NOS) and applications.

ArcOS offers multiple security options that can easily adapt to ever-changing business requirements.

This white paper discusses the key security capabilities of ArcOS and best practices for configuring, operating, and monitoring network devices.

Secure Device Infrastructure

The ArcOS-based infrastructure provides a solid foundation to build a secure network. This section discusses the available security options and the best practices for securing device infrastructure.

Image Signing and Validation

All officially released Arrcus software is GNU Privacy Guard (GPG) key-server signed, including ONL, the base Linux system, and the ArcOS image.

“Security has been a priority and integral to how ArcOS was architected since inception” Randy Bush, MTS, Arrcus

Figure 1: ArcOS security capabilities

3


Open Network Install Environment (ONIE) software can be used to install ArcOS on the network device if it was not pre-installed on the hardware. Arrcus provides its users the software tool(s) to validate the software authenticity before its installation by ONIE, as ONIE does not presently have the capability to validate the signed software.

Administrative Interfaces

The administrative interfaces on a network device are used to access and manage the device. Therefore, it’s critical to secure these interfaces to prevent any vulnerabilities during initial image load and to maintain reachability to the device in the event of a failure.

We recommend that the administrative interfaces be connected to a separate out-of-band management network to have separation between management and data traffic. This separation can be achieved by placing the administrative interfaces into the management virtual routing and forwarding (VRF) network instance.

Additionally, we suggest that the out-of-band management network be isolated from the user using a firewall.

User Access Methods

ArcOS supports two fully encrypted modes of access: SSH with Linux/Open SSH key-based authentication and TACACS+ mediated password-based authentication. Administrative users may create and maintain new Linux/OpenSSH users as well as new TACACS+ users. In either case, full session encryption is mandatory. ArcOS does not allow Telnet and other unencrypted protocols.

User Accounts and Role-based Access

ArcOS supports two types of users: local users and remote users.

The management ethernet port is named “ma1” in ArcOS

Figure 2: Securing out-of-band management network

4


Local Users:

ArcOS creates local users on system bootup. ArcOS will have the account “root” with a default password.

The ArcOS image pre-creates two Linux groups, “admin” and “operator” and with no pre-configured users. However, users can be assigned to these groups after first login via the ArcOS CLI. The “admin” user group will have “config” and “view” privileges while the “operator” user group will have only “view” privileges.

Remote Users:

ArcOS creates remote users on a remote AAA server and supports TACACS+ for the authentication of remote users. While users are locally authenticated first by default, the authentication sequence (local vs. remote) can be modified by either a “root” or an “admin.” For example, “TACACS Local” would mean to try TACACS+ first, and then “Local.” Note that “Local” cannot be deleted, as this is a safety mechanism in case the TACACS+ server is not available.

Multiple TACACS+ servers, all reachable via the management VRF, can also be configured. For local user authentication, a public and private key pair mechanism can be used, but with TACACS+, ArcOS currently supports only password-based authentication.

While login through management or console ports is enabled, login through the IP address of front panel ports is disabled. Users are classified into three groups (“root,” “admin,” or “operator”) with the user role defining the login behavior:

• The “root” user always lands in the Linux shell upon login and can also access the ArcOS shell.

• Users in the “admin” user group always land in the ArcOS shell upon login, but can access the Linux shell with access scope defined by the “root” user.

• Users in the “operator” user group always land in the ArcOS shell upon login and will not have access to the Linux shell.

New Services and Packages

The open architecture of ArcOS enables end users to customize the install package to meet their specific needs. Based on Debian Linux, ArcOS is an open Linux system where the network administrator has the flexibility of installing other Linux applications using known Debian packages. Specifically, the network administrator has the option to use well-known

ArcOS audits all user logins and logouts by default

The “root” user is highly encouraged to change the password on first login

5


methods of authenticating and verifying new services on the device, whether they come from global or local repositories. Additionally, the network administrator would need to update the whitelist using the ArcOpsTM toolkit to avoid false alarms about new services or packages installed on the ArcOS device.

More information on ArcOps toolkit can be found in the Monitoring Resources, Processes, and Logs section of this white paper.

Secure Control and Data Planes

In today’s business environment, network elements are exposed to a myriad of threats, and any compromises in the network could lead to service disruption, unintended routing of traffic, and management integrity issues. Securing control and data plane traffic is critical to maintaining network stability.

Control Plane Protection

Network devices can be susceptible to Denial of Service (DoS) attacks from malicious or unnecessary traffic that could overwhelm the system CPU, which needs to be protected to allow for control plane packets (e.g., routing protocol packets) and management plane packets (e.g., SSH) to access the CPU resources. Control Plane Policing (CoPP) is designed to control access to system resources and to prioritize both management and control plane traffic over unnecessary or potentially dangerous DoS traffic.

In ArcOS, Control Plane Policing (CoPP) is enabled by default on all the interfaces with default prioritization settings to police different types of traffic to the CPU. The default CoPP policy groups critical routing protocol traffic (e.g., BFD, BGPv4/v6, IS-IS, OSPFv2/v3, etc.) in one queue, critical Layer 2 traffic (e.g., BPDU, LACP, etc.) in another queue, and management traffic (e.g., TACACS+, FTP, SSH, ICMP/LLDP, SNMP, CLI, etc.) in another queue.

Figure 3: Control plane protection

ArcOS enables policing by default to protect management and control plane traffic

Data Plane Security

ArcOS supports storm control and ACLs (L2, IPv4, and IPv6) to control broadcast, unknown unicast and multicast (BUM) traffic and drop traffic classified as insecure by operator

6


If the default CoPP policy is suitable for the deployment, no additional configurations are required. Otherwise, a new customized CoPP policy may be constructed by first creating access control lists (ACLs) for the interesting category of traffic to be policed, and then by associating the newly created ACLs with the CoPP classifier objects.

Secure Routing

Routing plays a prominent role in the control plane. Thus, it’s absolutely critical to take measures to secure it. Routing protocols are susceptible to malicious attacks, which can divert traffic to an unintended destination or knock the entire network off. Secure communication with an authorized neighboring peer is essential to protecting the integrity of the device.

Routing Protocol Authentication

In ArcOS, secure authentication of routing protocols is accomplished via key-based Message-Digest 5 (MD5) algorithm, which leverages a timer-based keychain mechanism for each routing peer.

Support for TCP-Authentication Option (TCP-AO), which uses a stronger message authentication code (MAC), to protect against replay attacks will be a future enhancement.

Secure BGP

Given BGP’s traditional role in the internet to exchange routing information between network domains, it has a number of capabilities that strengthen security, which ArcOS supports, including:

• Controlling/limiting prefixes exchanged between peers (IPv4/IPv6 prefix-filtering) A BGP device consumes CPU, memory, and sometimes even data plane resources when exchanging prefixes with its neighbor. A properly set threshold for prefix exchange ensures that the usage of system resources is kept at a heathy level.

• Secure inter-domain routing through route origin validation (ROV) An operator may unintentionally advertise a prefix that it does not own. The origin validation capability allows a BGP receiver to validate that the received prefix originated from the “right” AS. It effectively prevents traffic blackholing.

• AS path filtering When a network peers with two providers, there is a risk that it becomes a transit network for the two providers if its prefix advertisement is not properly filtered. The AS path filter capability effectively prevents this from happening as a prefix from certain AS can be filtered out before its advertisement.

• TTL-based network protection As BGP runs at the edge of a network, it’s more susceptible to attacks. A TTL-based security check prevents attacks being launched from networking devices behind the legitimate and directly connected peers by filtering all of the incoming BGP packet’s TTL value.

Other Protection Mechanisms

Arrcus is working in IETF and other forums to develop and deploy more automated key generation and distribution mechanisms, potentially based on RFC 5705 - Keying Material Exporters for Transport Layer Security (TLS)

7


Secure Operations

After a device is fully configured, it’s important to monitor the device throughout its operation for any security or performance issues, outages, and configuration changes to ensure that the business is operating smoothly.

Monitoring Resources, Processes, and Logs

ArcOS provides an operations toolkit, ArcOps, that eases the day-to-day management of a network device and/or a collection of devices forming the network fabric. The ArcOps toolkit enables monitoring of key performance metrics (KPIs) of the device. Its various functions include:

• Maintaining a whitelist of processes (ArcOS built-in production processes and administrator-approved processes) and alerting when a non-whitelist process is created.

• Maintaining a whitelist of user IDs and alerting when a non-whitelist user ID is created or logs in.

• Maintaining a whitelist of network ports and alerting when a non-whitelist port is opened.

For example, the following snippet shows some of the non-whitelist processes created:

ArcOS comes with a pre-configured whitelist for all the KPIs, which a network administrator can change at install.

ArcOps also provides a remote secure log collation functionality. This enables ArcOS device to collect KPIs – including resource utilization like CPU, memory, file descriptors, and various ArcOS process logs – and stream them securely to a remote server for collation and further analysis.

In addition, ArcOps provides a uniform way of transferring ArcOS device configs to a central config server for recordkeeping and analysis. ArcOS also monitors its processes for any malfunctions and, in the event of a core dump, transfers the core file to the central log server for further analysis.

Figure 4: Non-whitelist process monitoring

Monitoring ArcOS Logs

ArcOS is based on Debian Linux and as such supports all available Linux-based logging mechanisms. Standard Linux tools such as logwatch or Nagios can be used to monitor ArcOS logs stored under /var/log/arcos/<daemon-name>.txt

8


Security Updates

Arrcus constantly monitors the Linux security updates in the open source forum and evaluates their impact on the ArcOS install base. It has developed a system to notify its customers of impending Linux security issues and the recommended software updates.

Secure Telemetry

In order to ensure the continuous availability of a network, it’s critical to have visibility into network state changes at all times. Traditional methods of collecting network data are based on polling mechanisms such as the SNMP protocol or on CLI ‘”show’” commands. However, these network monitoring mechanisms are either unstructured, inefficient, incomplete, or have significant scale issues. New push-based streaming telemetry mechanisms have gained momentum over the aforementioned legacy methods.

ArcOS’s streaming telemetry enables the ability to stream out real-time, model-driven data, which is used to make intelligent decisions related to visibility, troubleshooting, and traffic engineering.

ArcOS supports the ability to stream out the following network state data from the device:

• Platform state information – memory usage, state of peripherals, process state, etc.

• BGP and RIB state information – IPv4/IPv6, neighbor, AFI/SAFI, attributes, path, and remote next-hop

• Interface statistics – ingress and egress packet counters

• ACL statistics – time when an ACL was hit, packets matching the rule, etc.

Figure 5: Streaming telemetry

9


About Arrcus

Arrcus was founded to enrich human experiences by interconnecting people, machines, and data. Our mission is to provide software-powered network transformation for the interconnected world. The Arrcus team consists of world-class technologists who have an unparalleled record in shipping industry-leading networking products, complemented by industry thought leaders, operating executives, and strategic company builders.

The company is headquartered in San Jose, California.

For more information, go to www.arrcus.com or follow @arrcusinc.

9

[email protected]

408-884-1965

www.arrcus.com

2077 Gateway PlaceSuite 400San Jose, CA

Data is streamed out from the network device in JSON message format, either periodically or when there is an internal state change.

Arrcus does not recommend the use of an unprotected Kafka in a deployment environment where extra security is needed.

Summary

ArcOS enables several security features by default, including prohibiting insecure access, auditing all logins and logouts, and control plane policing. Together with operational best practices, ArcOS-based secure network infrastructure eases the IT staff’s task in supporting their organization’s digital and business transformation. ArcOS enables them to leapfrog their legacy counterparts and achieve an unprecedent level of productivity.

Note: Please refer to the ArcOS configuration guide for release-specific feature support.

ArcOS telemetry streams its JSON data over TLS-protected Kafka

securing your network with arcos®

Documents