Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Apstra Data Center Director Server Introduction

The information in this section is about managing the server. For information about installing and upgrading the server, see the Juniper Apstra Installation and Upgrade Guide. .

Server Hardening

The server base OS uses Ubuntu 22.04 LTS to pick up the latest Linux OS improvements. The server backend uses Python 3.

Apstra ships as a pre-hardened virtual appliance. Hardening happens during the build, before you ever download the image, so there's no hardening script for you to run after installation. The appliance is built against the CIS Ubuntu Linux Benchmark at Level 1, which aligns with many enterprise security compliance frameworks.

This section describes:

  • How Apstra scans for, prioritizes, and addresses vulnerabilities.
  • How the appliance image is built and hardened.
  • The hardening and validation steps applied to the appliance.
  • How you can access the server securely.
  • The security tasks you should complete after you deploy the server.

Vulnerability Scanning and Management

A Tenable/Nessus vulnerability scan runs every week. Each scan includes SAST (Static Application Security Testing), SCA (Software Composition Analysis), container scanning, and API scanning. Scans cover all released, supported versions of Apstra, plus the latest build of any version that's in development.

The scanning software is set up to notify Apstra Engineering and Support about any newly found vulnerability above a set CVSS threshold. Vulnerabilities are handled through a severity-based, risk-based process:

  • Critical (CVSSv3 9.0 and higher): A tracked issue is created, and the vulnerability must be addressed in the same or immediate release. These vulnerabilities have a higher likelihood and potential impact of exploitation. Coordination with PSIRT is required.
  • High (CVSSv3 7.0 to 8.9): A tracked issue is created, and the vulnerability is treated as a high priority for remediation in the same release. PSIRT is involved as appropriate.
  • Medium (CVSSv3 5.0 to 6.9): Remediation depends on risk and how easily the vulnerability can be exploited. Easily exploitable vulnerabilities that affect internet-facing environments are addressed before release. Lower-impact vulnerabilities that require privileged or local access, and that sit behind a firewall, might be deferred to a later release based on a risk assessment.

In addition to the weekly scans, an external vendor runs a penetration test on Apstra once a year.

Based on these security findings, Apstra puts together a targeted plan to update security packages in the field.

How Security Fixes are Delivered

Apstra uses an automated CI/CD process to build releases. This process brings 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. Critical issues in the scan report are fixed. Less critical findings are reviewed, and the ones that need attention are selected for remediation.

The only path to resolving security issues is a software upgrade. In an upgrade, the new Ubuntu release and related packages are bundled with the Apstra software. That bundle has been tested and placed into longevity tests for any regression, performance, or functionality issues.

The Ubuntu version and packages are pristine when Apstra builds and ships them. Over time, though, newly discovered vulnerabilities cause additional issues, and those issues are resolved by an upgrade. For an isolated critical issue, Apstra can create a hotfix to apply to a production deployment, or recommend a mitigation procedure.

In-Build Hardening Process

Before you download 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. These domains are summarized in Hardening and Validation Steps.

The VM includes the latest versions of all Ubuntu packages as of the Apstra release date minus six weeks. The six weeks allow for validation and burn-in time before GA.

The Apstra VM image is built in multiple phases:

  1. A base Ubuntu system image is created from the official Ubuntu ISO image in the Ubuntu online repositories.

  2. The source ISO is checked for authenticity using SHA hashes.

  3. Only the minimum configuration and packages that Apstra needs are installed. Security policies are applied automatically. The configuration used is similar to the CIS Ubuntu hardening standards (CIS Ubuntu Linux Benchmarks), which align with many security compliance frameworks in the enterprise space.

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

  5. For each official release, the build reuses this hardened base system and installs only the Apstra-specific packages on top of it.

  6. The raw VM image is converted into the following formats and marked as ready for distribution on the download site:
    • OVA, for VMware
    • QCOW2, for Linux KVM
    • VHDX, for Microsoft Hyper-V

Hardening and Validation Steps

The Apstra appliance build includes the following hardening and validation steps.

Source Validity

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

HTTPS Encryption

  • The Apstra server provides the Apstra GUI and REST API over HTTPS, using Nginx.
  • Apstra follows documented Nginx procedures for replacing TLS certificates. Replacing the certificate gives you client-to-server authentication and end-to-end encryption.
  • The TLS certificate that ships with Apstra is self-signed, which isn't secure. We recommend replacing it with a signed certificate. See Replace SSL Certificate on Apstra Server with Signed One.

File System Security

  • Unnecessary file system drivers are disabled.
  • File system mounts are secured.
  • Apstra services don't share disk space with the rest of the OS (for example, /var/log/Apstra).
  • File system permissions are strong.

Service Security

  • Unnecessary services are disabled.
  • AppArmor is configured.
  • The SSH configuration is hardened.

Network Security

  • iptables is configured with a default-deny policy.
  • The system has uRPF, IP routing is disabled, and related settings are applied.
  • Warning banners state that any action should only be taken with support from Apstra.
  • SSH login attempts are throttled to prevent brute-force attacks.

Auditing

  • System configuration changes are audited by auditd.
  • Login and logout failures and successes are audited.
  • Privilege escalations are audited.

Secure Server Access

You can administer the Apstra server in three ways:

  • JavaScript Web UI (port 443): HTTPS, with basic authentication and role-based access control (RBAC).
  • REST API (port 443): HTTPS, with basic authentication and RBAC.
  • SSH (port 22): Root login isn't permitted by default.

NOTE: Apstra ships with a default GUI admin password. It's critical that you change this password after the server completes its first boot. We recommend using SSH to access the Apstra server to change the password. See Reset GUI Admin Password.

Post-Deployment Security Tasks

The following security tasks are documented elsewhere in this guide. Complete them after you deploy the server: