Apstra Server Hardening

Vulnerability Scanning

A Tenable / Nessus vulnerability scan occurs weekly against all released, supported versions of Juniper Apstra in addition to the latest build of any version in development. This software is set up to notify Apstra Engineering and Support for any newfound security vulnerabilities over a particular threshold of CVSS > 8.0. As part of these security findings, Juniper Apstra formulates a targeted plan to update security packages in the field.

Juniper Apstra uses an automated CI/CD process for building releases that include bringing in the latest versions of Ubuntu and updated packages. The SecOps part of the build system then runs a Tenable I.O Nessus scan for vulnerabilities. We review that report and fix any critical issues and review less critical problems to cherry-pick those vulnerabilities that we deem that require attention.

Our only path to resolving security issues is a software upgrade where the new Ubuntu release and related packages, bundled with the Apstra Software, have been tested and placed into longevity tests for any regression, performance, or functionality issue. The version of Ubuntu and packages are pristine when we build and ship them. Still, vulnerabilities discovered over time will result in additional problems that are resolved by the upgrade. For isolated critical issues, we can create and apply a hotfix to a production deployment or recommend a mitigation procedure.

Process for Hardening (In-Build Process)

Before the customer downloads the Apstra VM, Apstra hardens it against the current CIS Ubuntu version as a "Level 1" system. This process includes basic security configuration in a few security domains, summarized here. The VM has the latest versions of all Ubuntu packages as of the date the Apstra release is available minus six weeks (validation and burn-in time before GA).

The Apstra VM Image is built off a multi build phase process:

1. Apstra creates a base Ubuntu system image from the Ubuntu ISO image from Ubuntu repositories online.

2. Validation of the authenticity of source ISO with SHA hashes

3. Apply minimum configuration and minimum installation packages for Apstra to install and automatically assign security policies. The configuration used is similar to the CIS Ubuntu hardening standards, https://www.cisecurity.org/benchmark/ubuntu_linux/, which aligns with many security compliance frameworks in the enterprise space.

4. After hardening scripts run, build artifacts, and cache folders are deleted to minimize disk usage, log files trimmed, and base system VM is 'closed'.

5. As part of the official build release artifacts, we reuse the base system created above installing only the Apstra-specific packages.

6. Build artifacts for the same, raw VM image is converted into OVA for VMware, QCOW2 for Linux KVM, and VHDX for Microsoft Hyper-V and marked as ready for distribution (https://support.juniper.net/support/downloads/?p=apstra)

   .

Hardening/Validation Steps

• Source validity

  • Ubuntu source ISO is validated with SHA hashes before the build process begins

• HTTPS Encryption

  • The Apstra Server provides the Apstra UI and API using HTTPS on Nginx. Apstra uses Nginx documented procedures to replace TLS certificates in order to accomplish client to server authentication and end-to-end encryption. Apstra encourages users to replace the included insecure, "self-signed" TLS certificates with signed certificates.

• File system security

  • Disable unnecessary file system drivers

  • Ensure file system mounts are secure

  • Apstra services don't share disk space with rest of OS (e.g./var/log/Apstra)

  • File system permissions are strong

• Services security

  • Disable unnecessary services

  • Configure AppArmor

  • Harden SSH configuration

• Network security

  • Ensure iptables is configured with an appropriate 'default deny' policy

  • Ensure the system has uRPF, disable IP routing, etc

  • Warning banners that state that any action should only be made with support from Apstra.

  • Apply login throttles to ssh login attempts (brute force prevention)

• Auditing

  • Ensure system configuration changes are audited (run auditd)

  • Audit login/logout failures and successes

  • Audit privilege escalations

• Secure server access

  • There are three methods to administer the Apstra Server:

    1. Javascript Web UI (443): HTTPS, Basic Authentication and RBAC*

    2. REST API (443): HTTPS, Basic Authentication and RBAC*

    3. SSH (22): No root login permitted by default

  Note:

  IMPORTANT: Change the default admin password. Apstra ships with a default admin password. It is critical that this password is changed after the server has completed the first boot process. Apstra recommends using SSH to access the Apstra server to change the password. For more information, see Reset Apstra GUI Admin Password.