diff --git a/docs/cc_fips_access_mgmt.md b/docs/cc_fips_6.2.5_access_mgmt.md similarity index 100% rename from docs/cc_fips_access_mgmt.md rename to docs/cc_fips_6.2.5_access_mgmt.md diff --git a/docs/cc_fips_appendix.md b/docs/cc_fips_6.2.5_appendix.md similarity index 100% rename from docs/cc_fips_appendix.md rename to docs/cc_fips_6.2.5_appendix.md diff --git a/docs/cc_fips_banners.md b/docs/cc_fips_6.2.5_banners.md similarity index 100% rename from docs/cc_fips_banners.md rename to docs/cc_fips_6.2.5_banners.md diff --git a/docs/cc_fips_compliance_guidelines.md b/docs/cc_fips_6.2.5_compliance_guidelines.md similarity index 86% rename from docs/cc_fips_compliance_guidelines.md rename to docs/cc_fips_6.2.5_compliance_guidelines.md index 038614e5e6..7e0000ca92 100644 --- a/docs/cc_fips_compliance_guidelines.md +++ b/docs/cc_fips_6.2.5_compliance_guidelines.md @@ -7,11 +7,11 @@ For compliance, the following configuration considerations must be made: - FIPS mode must be enabled **during installation**. Use of anything other than FIPS mode is not compliant with Common Criteria certification. - **Except during installation**, all configuration procedures must be performed from the CLI; use of the GUI is not part of the approved use case. Configuring the router OTP Quickstart file from the Conductor GUI **is acceptable under the Common Criteria guidelines**. -- When installing a router, the [IPv4 Option Filter](cc_fips_sec_firewall_filtering.md#ipv4-option-filtering) must be set to `drop-all`. -- When installing a router, the [ICMP Session Match](cc_fips_sec_firewall_filtering.md#icmp-type-as-a-session-attribute) must be set to `identifier-and-type`. -- Configure the [TCP Half-Open Connections Limit](cc_fips_sec_firewall_filtering.md#tcp-half-open-connection-limit) for firewall. -- The `password-policy` must define the minimum password length and maximum number of permitted login attempts per user. Please refer to [Username and Password Policies](cc_fips_config_password_policies.md) for policies, and to [`configure authority password-policy`](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide#configure-authority-password-policy) for CLI commands and context for assigning these values. -- The `admin` account must be given `sudo` privileges allowing it to use the shell for some management capabilities. Edit the `/etc/sudoers` file as `root` using the `visudo` command. This allows you to add an entry for `admin` which will persist across reboots. For additional information, please see [Root Access](cc_fips_access_mgmt.md#root-access) in the Access Management section. +- When installing a router, the [IPv4 Option Filter](cc_fips_6.2.5_sec_firewall_filtering.md#ipv4-option-filtering) must be set to `drop-all`. +- When installing a router, the [ICMP Session Match](cc_fips_6.2.5_sec_firewall_filtering.md#icmp-type-as-a-session-attribute) must be set to `identifier-and-type`. +- Configure the [TCP Half-Open Connections Limit](cc_fips_6.2.5_sec_firewall_filtering.md#tcp-half-open-connection-limit) for firewall. +- The `password-policy` must define the minimum password length and maximum number of permitted login attempts per user. Please refer to [Username and Password Policies](cc_fips_6.2.5_config_password_policies.md) for policies, and to [`configure authority password-policy`](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide#configure-authority-password-policy) for CLI commands and context for assigning these values. +- The `admin` account must be given `sudo` privileges allowing it to use the shell for some management capabilities. Edit the `/etc/sudoers` file as `root` using the `visudo` command. This allows you to add an entry for `admin` which will persist across reboots. For additional information, please see [Root Access](cc_fips_6.2.5_access_mgmt.md#root-access) in the Access Management section. - Traffic logging must be enabled by setting the following command to `true`: `configure authority router router system audit traffic enabled true`. This is a resource intensive setting. Not more than a few sessions are expected to run while collecting traffic events. - Any services that are used to enforce evaluated firewall functionality must have a service-policy attached that applies strict transport state enforcement: diff --git a/docs/cc_fips_conductor_install.md b/docs/cc_fips_6.2.5_conductor_install.md similarity index 97% rename from docs/cc_fips_conductor_install.md rename to docs/cc_fips_6.2.5_conductor_install.md index fc4ade1742..5af3eec9f9 100644 --- a/docs/cc_fips_conductor_install.md +++ b/docs/cc_fips_6.2.5_conductor_install.md @@ -11,7 +11,7 @@ The Conductor installation must be completed before installing a Session Smart R ## Prerequisites -- Installation is performed on a compliant platform; see [Compliant SSR Hardware](cc_fips_compliance_guidelines.md#compliant-ssr-hardware). +- Installation is performed on a compliant platform; see [Compliant SSR Hardware](cc_fips_6.2.5_compliance_guidelines.md#compliant-ssr-hardware). - Verify that the boot priority of the USB drive is properly listed in the system BIOS. - Ensure local console connectivity to the device. - **Logging in as `root` over SSH is not permitted.** When a system is installed using the OTP ISO, a `t128` user is configured with `sudo` privileges. @@ -184,7 +184,7 @@ Conductor High Availability for Cloud Deployments is not supported under Common - At least 1 number - Cannot contain the username in any form - Cannot repeat characters more than 3 times - This operation is only performed on the standalone or first node in the HA peer, and the password must be entered twice. For supporting password information, see [Username and Password Policies](cc_fips_config_password_policies.md). + This operation is only performed on the standalone or first node in the HA peer, and the password must be entered twice. For supporting password information, see [Username and Password Policies](cc_fips_6.2.5_config_password_policies.md). :::note Resetting a password requires entering the old password. If a password is lost or forgotten and the account is inaccessible, the account cannot be recovered. Please keep password records accessible and secure. ::: @@ -370,13 +370,13 @@ Creating router configurations on the conductor allows individual routers to dow A sample branch router configuration is available as a [**template**](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_templates#default-templates) on the conductor. This is a great place to start the configuration process. Additionally, you can create configuration templates that allow administrators to automate the configuration of top-level resources. For more information, see [Configuration Templates](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_templates). -To see an example router configuration, refer to the [Appendix](cc_fips_appendix.md). +To see an example router configuration, refer to the [Appendix](cc_fips_6.2.5_appendix.md). After completing the router configuration on the conductor, please return to this guide to continue the Common Criteria compliant router installation. -If you will be using the OTP Quickstart router installation process, proceed to the [OTP Router Install Process](cc_fips_otp_router_install.md) next, and then use the [QuickStart From the OTP ISO](cc_fips_install_quickstart_otpiso.md) steps to generate a basic configuration and quickstart file for router installation. +If you will be using the OTP Quickstart router installation process, proceed to the [OTP Router Install Process](cc_fips_6.2.5_otp_router_install.md) next, and then use the [QuickStart From the OTP ISO](cc_fips_6.2.5_install_quickstart_otpiso.md) steps to generate a basic configuration and quickstart file for router installation. When configuring and installing a router in an environment operating under the Common Criteria guidelines, it is acceptable to provision this file using the GUI. Other uses of the SSR GUI are not supported under the Common Criteria guidelines. -If you choose to install routers using the Interactive Installation, continue with [Router Interactive Installation](cc_fips_router_install.md). +If you choose to install routers using the Interactive Installation, continue with [Router Interactive Installation](cc_fips_6.2.5_router_install.md). diff --git a/docs/cc_fips_config_audit_event.md b/docs/cc_fips_6.2.5_config_audit_event.md similarity index 100% rename from docs/cc_fips_config_audit_event.md rename to docs/cc_fips_6.2.5_config_audit_event.md diff --git a/docs/cc_fips_config_ntp_auth.md b/docs/cc_fips_6.2.5_config_ntp_auth.md similarity index 98% rename from docs/cc_fips_config_ntp_auth.md rename to docs/cc_fips_6.2.5_config_ntp_auth.md index 6e041d26c5..368ea64d20 100644 --- a/docs/cc_fips_config_ntp_auth.md +++ b/docs/cc_fips_6.2.5_config_ntp_auth.md @@ -35,4 +35,4 @@ authority exit exit exit -``` \ No newline at end of file +``` diff --git a/docs/cc_fips_config_password_policies.md b/docs/cc_fips_6.2.5_config_password_policies.md similarity index 100% rename from docs/cc_fips_config_password_policies.md rename to docs/cc_fips_6.2.5_config_password_policies.md diff --git a/docs/cc_fips_downloading_iso.md b/docs/cc_fips_6.2.5_downloading_iso.md similarity index 100% rename from docs/cc_fips_downloading_iso.md rename to docs/cc_fips_6.2.5_downloading_iso.md diff --git a/docs/cc_fips_install_quickstart_otpiso.md b/docs/cc_fips_6.2.5_install_quickstart_otpiso.md similarity index 100% rename from docs/cc_fips_install_quickstart_otpiso.md rename to docs/cc_fips_6.2.5_install_quickstart_otpiso.md diff --git a/docs/cc_fips_intro.md b/docs/cc_fips_6.2.5_intro.md similarity index 100% rename from docs/cc_fips_intro.md rename to docs/cc_fips_6.2.5_intro.md diff --git a/docs/cc_fips_intro_installation.md b/docs/cc_fips_6.2.5_intro_installation.md similarity index 92% rename from docs/cc_fips_intro_installation.md rename to docs/cc_fips_6.2.5_intro_installation.md index 18dfb990c4..6592c1e111 100644 --- a/docs/cc_fips_intro_installation.md +++ b/docs/cc_fips_6.2.5_intro_installation.md @@ -28,10 +28,10 @@ Access to the SSR Software packages available for download from our software rep Installation is done from the SSR ISO, typically from a bootable image on a flash drive or disk. The install process is as follows: -- [Download the OTP ISO](cc_fips_downloading_iso.md) +- [Download the OTP ISO](cc_fips_6.2.5_downloading_iso.md) - [Create Bootable Media](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_creating_bootable_usb) -- [Install a Conductor](cc_fips_conductor_install.md) +- [Install a Conductor](cc_fips_6.2.5_conductor_install.md) - [Create the Router configuration with the Conductor](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_basic_router_config) or [Import a Configuration](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/single_conductor_config) -- [Install the Router](cc_fips_router_install.md) +- [Install the Router](cc_fips_6.2.5_router_install.md) diff --git a/docs/cc_fips_6.2.5_otp_router_install.md b/docs/cc_fips_6.2.5_otp_router_install.md new file mode 100644 index 0000000000..6f76d5a241 --- /dev/null +++ b/docs/cc_fips_6.2.5_otp_router_install.md @@ -0,0 +1,252 @@ +--- +title: OTP Router Install Process +sidbar_label: OTP Router Install Process +--- + +The simplest deployment of the One Touch Provisioning (OTP) solution is highly automated and leverages just two components, the Conductor and at least one SSR. For many customers, the SSR platform is ordered and delivered as a pre-integrated, off-the-shelf solution through the Juniper SSR partner network. + +The OTP installation process produces a Router installed with SSR software set to factory defaults. Upon completing the OTP installation process, the default behavior is to provision the device with a DHCP client on the first ethernet port and DHCP server listening on all other ports. The user connects to the SSR via ethernet cable and uses the QuickStart file generated by the Conductor to finalize the SSR configuration. After performing the QuickStart operation, the SSR has connectivity to the conductor and downloads the latest configuration (if necessary) to begin operation. + +This process assumes you have already created a bootable device using a USB. Instructions for downloading and creating a bootable device are available in [Downloading an SSR ISO](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_downloading_iso) and [Creating a Bootable USB](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_creating_bootable_usb). + +Router installation can be performed using **either** the OTP process, or the [Interactive Installation](cc_fips_6.2.5_router_install.md). You do not need to perform both. **The steps in this section describes the OTP process.** + +:::note +The Conductor installation must be completed before installing a Session Smart Router or routers using the ISO. The same ISO is used for all installations. +::: + +### QuickStart Provisioning +Basic configuration parameters are encoded within an encrypted file. For each node, a custom file can be exported from the Conductor and minimally contains the following configuration encoded parameters: +- WAN IP address, subnet mask and gateway +- Conductor IP address +- Asset ID + +### Before you Begin + +Before beginning the Router installation, you must have a Conductor operationally deployed and reachable by the router. + +:::important +For Common Criteria compliance, a dedicated, out-of-band network must be used to provide the management connection security between Conductor and Router instances. SSR software does not currently provide any evaluated security assurances for this link. This dedicated network interface must be privately routed, and must not be exposed publicly. +::: + +## Installation + +### Connect the SSR to a Management Console + +Ensure that you have an appropriate rollover cable available to connect to your computer. The SSR has a console port (CONSOLE) with an RJ-45 connector. Use the console port to connect the appliance to a management console or to a console server. The baud rate of the console port is 115200 bps. + +1. Connect the RJ45 rollover cable to the console port on the SSR device. +2. Connect the other end of the cable to your computer. +3. Insert your bootable USB with the new ISO image into the USB port of the SSR device. +4. Connect the power input to the SSR device +5. Power on the SSR. + +### Booting from the USB + +Use the steps appropriate for your device to direct the device to boot from the USB for installation. + +#### SSR100 Series Devices + +1. At the instruction in the terminal window: `Press ESC for boot menu`, do so. + + ![Boot Menu prompt](/img/onboard_otp_boot_menu.png) + +2. From the boot menu, enter the device number corresponding to the USB, and press Enter. + + ![Select Boot Device](/img/onboard_otp_boot_device.png) + +3. When the USB installer boot menu is displayed, continue with the [OTP Router Installation](#otp-router-installation). + +#### SSR1000 Series Devices + +1. At the instruction in the terminal window: `Press or to enter Setup`, do so. + + ![Setup Menu Prompt](/img/1x00_setup_menu.png) + +2. When the Setup Utility window appears, use the left and right arrow keys to navigate to the `Save & Exit` tab. + + ![Setup Utility](/img/setup-menu-prompt.png) + +3. Use the up and down arrow keys to highlight the USB device in the the Boot Override list. + + ![Boot Override list](/img/1x00_boot-override.png) + +4. Press Enter to confirm boot from the USB device. +5. When the USB installer boot menu is displayed, continue with the [OTP Router Installation](#otp-router-installation). + +### OTP Router Installation + +Upon boot, the following screen is displayed. The default selection is booting to the serial console (115200 baud). You must manually choose the installation process suited for your environment. + +1. Use the Up/Down keys to select the `OTP Install 128T Routing Software Serial Console` option. This is a supported installation option for Common Criteria. It uses `/dev/ttyS0` 115200 baud as the serial console for interacting with the installer. + + ![Serial Install Selection](/img/cc_fips_otp_serial.png) + + Selecting the wrong type of console may result in garbled characters being displayed. If allowed to continue it will result in an incorrect installation. If the wrong console is selected, reboot the target system and select the correct line for the target hardware. + + For serial console issues please refer to [Serial Console Troubleshooting](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/ts_serial_console_tsing). + +2. Press the TAB key to edit the configuration. + + To enable FIPS Enforcement for SSR software version 6.2.5-5-sts, add the `fips=1` kernel option to the kernel command line during system installation as shown in the steps below. This ensures that key generation is done with FIPS approved algorithms and continuous monitoring tests in place. + + :::important + FIPS mode is required for Common Criteria compliance. Failure to configure FIPS mode, or the use of any other cryptographic engine nullifies compliance. + ::: + +3. Add `fips=1` to the end of the `vmlinuz` parameters. + + ![FIPS Parameter](/img/cc_fips_otp_serial2.png) + +4. Press **Enter** to start the install. + +:::note +When you modify the GRUB kernel behavior by editing the GRUB menu at boot time, the changes do not persist over a system reboot. Default boot behavior is restored the next time you boot the system. +::: + +### SSR Installation + +This installation process is an automated workflow which does not require user interaction after selecting and initiating the OTP menu option. The system will power off after installation. + +### Root Access +To permit root access to the SSR system, ensure that there is at least one user configured on each system with super user (sudo) privileges. Failure to do so may result in the loss of management connectivity to the router. +**Logging in as `root` over SSH is not permitted.** + +Prerequisites for installation and upgrades now include configuring a super user in `/etc/sudoers` that is allowed to execute Linux shell commands as root (sudo privileges). +During an upgrade, if the existing version allows SSH Root login, it will be disabled. When a system is installed using the OTP ISO, a "t128" user is automatically configured with sudo privileges. + +1. Login using the admin credentials. +2. Enter the Linux shell: Type `shell` to suspend the CLI and enter the Linux shell. +3. Type `su` and enter the default root password. +4. Use the following command to grant sudo privilege to the `admin` user account: + `/usr/sbin/visudo` +5. Add an entry for admin as follows: + ``` + admin ALL=(ALL) ALL + ``` +6. Save the file and exit from `visudo`. +7. Type `exit` to leave the `su` prompt. + +### Change the Default Passwords + +The following user accounts and passwords are created during the ISO installation process: + +| Username | Password | +| -------- | ---------- | +| root | 128tRoutes | +| t128 | 128tRoutes | + +Change these passwords immediately. Use the `passwd` command from the Linux shell to individually set the password for each username. + +``` +[admin@localhost ~]$ sudo passwd t128 +Changing password for user t128 +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ sudo passwd root +Changing password for user root. +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ +``` + +:::note +The root account will not be used for day-to-day access, but the root account password should be stored securely off-box so that it can be used for admin account recovery if required. +::: + +### Software Compliance Validation + +After installing the SSR Software, it is important to verify that the installation successfully completed and that the system is running in the FIPS enforcement mode required for Common Criteria compliance. After starting the SSR router or conductor, the login screen appears on the console. Alternatively you may `ssh` to the SSR management IP address using the admin account. + +1. Login using the admin credentials. +2. Use `show system version` to verify the correct software release is running: + +``` +Last login: Thu Dec 14 13:28:36 UTC 2023 on pts/0 +admin@conductor.conductor# show system version +Fri 2024-03-01 16:23:37 UTC +✔ Retrieving system version 1/1 targets complete... + +=========== =========== ========= ======== ====================== ===================== + Router Node Version Status Build Date Package +=========== =========== ========= ======== ====================== ===================== + 128t-east 128t-east 6.2.5 r2 2024-06-06T23:56:25Z 128T-6.2.5-5r2.el + 7 (package based) + +Completed in 0.05 seconds +admin@conductor.conductor# +``` + It should report Version 6.2.5 and Status r2. + +3. Type `shell` to suspend the CLI and enter the Linux shell. +4. Execute the command `sudo systemctl status 128T` and verify the service is listed as `active (running)`. + +``` +[root@conductor-test admin]# sudo systemctl status 128T -l + 128T.service - 128T service + Loaded: loaded (usr/lib/systemd/system/128T.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2023-7-31 18:04:29 UTC; 50min ago + Main PID: 23317 (processManager) +``` + +5. Perform the following steps to verify the software integrity and protect against future tampering: + +- Execute the self-test scan `sudo systemctl start 128T-rpm-verify` + + The self-test scan is initiated and takes approximately two minutes to complete. Upon completion, run: + + `systemctl status 128T-rpm-verify` + + The scan validates all executable files on the system against the `sha256` digest hash recorded in the signed RPMs from which they were installed. This ensures that no files have been replaced or tampered with. + +- Run `systemctl status 128T-rpm-verify` to confirm that the service shows: + + `PASS: All RPM file digests verified` + +- If the result displays the following: + + `FAIL: RPM file digest mismatch detected` + + The failure must be resolved before continuing to ensure compliance. The full path to each file having a self-check digest mismatch is reported as part of the `status` output. + +- After the self-test scan test has succeed, enable the automatic self-test by executing the `enable` command in the linux shell: + + `sudo systemctl enable 128T-rpm-verify` + + The self-test is enabled on every subsequent reboot. If the self-test fails, the 128T service will not start. + +6. Perform the following steps to verify that FIPS security enforcement mode is enabled in the OS: + `openssl md5 /dev/null` + Expected result: `digital envelope routines … Disabled for fips` + +7. Run the following command to verify that FIPS security enforcing mode is enabled in the kernel: + `cat /proc/sys/crypto/fips_enabled` + Expected result: `1` + +8. Type `exit` to leave the Linux shell and return to the CLI. +9. Type `quit` to log out from CLI. + +You have now completed security validation of the installation. + +### CLI Access Post Install + +Use the following procedure to access the CLI at any time after installation. + +1. Open a terminal window and SSH to the SSR's IP address. +2. Use your login credentials to log in to the SSR + + - If using an account other than admin, type `pcli` to start the SSR CLI. + + - Type `shell` to suspend the CLI and enter the Linux shell. + +To terminate an active session: + +- Type `exit` to return from the Linux shell to the CLI. + +- Type `quit` to log out from CLI. + +- If using an account other than admin, type `exit` to end the login session. + +Common Criteria certification does not require any restrictions on executing commands. See the [Configuration Command Reference Guide](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide) for command information and usage. diff --git a/docs/cc_fips_router_install.md b/docs/cc_fips_6.2.5_router_install.md similarity index 100% rename from docs/cc_fips_router_install.md rename to docs/cc_fips_6.2.5_router_install.md diff --git a/docs/cc_fips_sec_firewall_filtering.md b/docs/cc_fips_6.2.5_sec_firewall_filtering.md similarity index 100% rename from docs/cc_fips_sec_firewall_filtering.md rename to docs/cc_fips_6.2.5_sec_firewall_filtering.md diff --git a/docs/cc_fips_secure_deliver.md b/docs/cc_fips_6.2.5_secure_deliver.md similarity index 100% rename from docs/cc_fips_secure_deliver.md rename to docs/cc_fips_6.2.5_secure_deliver.md diff --git a/docs/cc_fips_software_upgrades.md b/docs/cc_fips_6.2.5_software_upgrades.md similarity index 97% rename from docs/cc_fips_software_upgrades.md rename to docs/cc_fips_6.2.5_software_upgrades.md index 95ef098992..e82d143c24 100644 --- a/docs/cc_fips_software_upgrades.md +++ b/docs/cc_fips_6.2.5_software_upgrades.md @@ -29,7 +29,7 @@ Two upgrade methods are available depending on your network internet access: The When using the `import iso` method, the `check-rpm-signature required` (default) option must be run. This ensures that the RPM signature and `sha256` digest of each package is validated during the import process. The use of `check-rpm-signature disabled` or `check-rpm-signature allow-unsigned` is not compliant for Common Criteria systems. For an online installation, signature checking is performed automatically. -After upgrading the software, repeat the [Software Compliance Validation](cc_fips_access_mgmt.md#software-compliance-validation) steps to ensure continued compliance. +After upgrading the software, repeat the [Software Compliance Validation](cc_fips_6.2.5_access_mgmt.md#software-compliance-validation) steps to ensure continued compliance. :::important Firmware and Software updates are expected to be performed by an Administrator on a regular basis, in response to the release of product updates due to known vulnerabilities. Only Common Criteria compliant software releases shall be installed on the target device. diff --git a/docs/cc_fips_ssr_security_scope.md b/docs/cc_fips_6.2.5_ssr_security_scope.md similarity index 100% rename from docs/cc_fips_ssr_security_scope.md rename to docs/cc_fips_6.2.5_ssr_security_scope.md diff --git a/docs/cc_fips_titlepage.md b/docs/cc_fips_6.2.5_titlepage.md similarity index 89% rename from docs/cc_fips_titlepage.md rename to docs/cc_fips_6.2.5_titlepage.md index 3296022d4e..3f61c834b4 100644 --- a/docs/cc_fips_titlepage.md +++ b/docs/cc_fips_6.2.5_titlepage.md @@ -1,6 +1,6 @@ --- -title: SSR Common Criteria Installation and User Guide -sidebar_label: SSR Common Criteria Installation and User Guide +title: SSR 6.2.5 Common Criteria Installation and User Guide +sidebar_label: SSR 6.2.5 Common Criteria Installation and User Guide --- This guide provides installation and configuration information for using SSR Conductors and Routers in a certified Common Criteria environment. The following platforms are supported for Common Criteria certification: diff --git a/docs/cc_fips_6.3.0_access_mgmt.md b/docs/cc_fips_6.3.0_access_mgmt.md new file mode 100644 index 0000000000..525186b3c5 --- /dev/null +++ b/docs/cc_fips_6.3.0_access_mgmt.md @@ -0,0 +1,460 @@ +--- +title: Access Management +sidebar_label: Access Management +--- + +Following industry security best practices, SSH features have been limited and in the case of SSH Root Login, have been disabled. + +## Root Access +To permit root access to the SSR system, ensure that there is at least one user configured on each system with super user (sudo) privileges. Failure to do so may result in the loss of management connectivity to the router. **Logging in as `root` over SSH is not permitted.** + +Prerequisites for installation and upgrades now include configuring a super user in `/etc/sudoers` that is allowed to execute Linux shell commands as root (sudo privileges). +During an upgrade, if the existing version allows SSH Root login, it will be disabled. When a system is installed using the OTP ISO, a "t128" user is automatically configured with sudo privileges. + +1. Login using the admin credentials. +2. Enter the Linux shell: Type `shell` to suspend the CLI and enter the Linux shell. +3. Type `su` and enter the default root password. +4. Use the following command to grant sudo privilege to the `admin` user account: + `/usr/sbin/visudo` +5. Add an entry for admin as follows: + ``` + admin ALL=(ALL) ALL + ``` +6. Save the file and exit from `visudo`. +7. Type `exit` to leave the `su` prompt. + +## Change the Default Passwords + +The following user accounts and passwords are created during the ISO installation process: + +| Username | Password | +| -------- | ---------- | +| root | 128tRoutes | +| t128 | 128tRoutes | + +Change these passwords immediately. Use the `passwd` command from the Linux shell to individually set the password for each username. + +``` +[admin@localhost ~]$ sudo passwd t128 +Changing password for user t128 +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ sudo passwd root +Changing password for user root. +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ +``` + +:::note +The root account will not be used for day-to-day access, but the root account password should be stored securely off-box so that it can be used for admin account recovery if required. +::: + +## SSH Key-based Authentication + +To configure authentication by public key, use the `scp` command from a Linux/Unix based machine or another SCP client to write the file `/home//.ssh/authorized_keys` to the SSR. + +The contents of this file are the public key of the public/private key pair. To use multiple keys, specify the public key of each of the multiple keys on separate lines of the `authorized_keys` file. + +To remove access for a specific key, replace `authorized_keys` with a file that no longer contains the public part of that key. This can also be accomplished by writing an empty file to remove all keys. + +#### Example: + +If the `t128` user wants to use public key authentication, the `/home/t128/.ssh` directory must be created first and have permissions set using the following commands: +``` +mkdir /home/t128/.ssh +chmod u=rwx,g=,o= /home/t128/.ssh +``` +Then use the directions for uploading an `authorized_keys` file via `scp`, or manually edit `/home/t128/.ssh/authorized_keys` directly. + +## Enable Secure Communication + +In order to secure communication between the Conductor and the managed routers in a distributed environment, it is essential that you enable both strict hostkey checking and asset connection resiliency. These features may be enabled from either the command line or the web interface. + +- [Asset Connection Resiliency](#enable-asset-connection-resiliency) +- [Strict Host Key Checking](#enable-strict-host-key-checking) + +### Enable Asset Connection Resiliency + +Asset Connection Resiliency is set at the Authority level to ensure that all communication between the conductor and the managed routers is secure. By configuring [`asset-connection-resiliency`](config_command_guide.md#configure-authority-asset-connection-resiliency) as `true`, SSH tunnels are created for asset connections between a managed Router and the Conductor. Enabling `ssh-only` mode forces the asset connections to use the SSH tunnels. + +``` +config authority asset-connection-resiliency enabled true +config authority asset-connection-resiliency ssh-only true +``` + +![GUI Enable Asset Resiliency](/img/asset-connection-resiliency.png) + +### Enable Strict Host Key Checking + +Enabling strict `host-key-checking` **provides secure communication between the conductor and a router**. +Similar to SSH, there are two `host-key-checking` options; `yes` which requires the host key to be provisioned manually, or `accept-new` which accepts the key on first connection. + +There are two configuration parameters where `host-key-checking` can be set: + +- **`inter-router host-key-checking`** controls host key verification between a router and the conductor. When set to `yes`, strict host key checking is enabled between the router and the conductor. However, the host keys must be [manually provisioned on each router](#manual-provisioning-of-the-conductor-key). + + ``` + config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking yes + config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-router host-key-checking yes + ``` + +- **`inter-node host-key-checking`** controls host key verification between redundant HA nodes. When set to `yes`, strict host key checking is enabled between the router and the conductor **between each node** of an HA router. However, the host keys must be [manually provisioned on each router](#manual-provisioning-of-the-conductor-key). + +``` +config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-node host-key-checking yes +config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-node host-key-checking yes +``` + +To save the work of manually provisioning the host key on the router, set the `accept-new` parameter. **This automatically loads the host key on first connection**. + +``` +config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking accept-new +``` + +#### Web Interface Example + +![Enable Strict Hostkey Checking](/img/enable-strict-hostkey-checking.png) + +Use the `show system connectivity known-hosts` to view the accepted host keys for the current node. + +### Manual Provisioning of the Conductor Key + +If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accepts-new` configured, it will be necessary to manually provision the conductor key **prior** to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the conductor and configure this in the router. + +On the conductor, identify the `key` for each node using the command `show system connectivity host-keys node all`. + +From the router PCLI, provision each conductor key using the following command: +`create system connectivity known-hosts node ssh-rsa ` + +- `` is the router node. The key should be added on each router node in an HA pair. +- `` is the conductor address. This should be added for each conductor address of an HA conductor pair. +- `` is the `Key` retrieved from the previous step. +- `` is an option that can be used to identify the key; for example `Conductor1`. + +The following example manually configures the key to the conductor node `192.168.1.13`: + +`create system connectivity known-hosts router RTR_EAST_COMBO node combo-east-1 [192.168.1.13]:930 ssh-rsa ` + +## Signing and Importing Webserver Certificates + +Imported webserver and X.509 certificates are validated against trusted certificates configured using `trusted-ca-certificate`. Use the following information to create, sign, and import the certificates to the webserver. + +### 1. Configure SSL Ciphers + +Ciphers for TLS connections are required on both the conductor and router. + +Use the following command to configure webserver ssl ciphers. Note that `` is the name of the router or conductor. + +``` +configure authority router system webserver ssl ciphers TLSv1.2+HIGH:TLSv1+AES:!aNULL:!DSS:!kDH:!PSK:!kECDH +``` + +### 2. Configure a Trusted Certificate + +Certificates are pasted in as a multi-line config. + +Configure a certificate root named `ca_root` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root +admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +### 3. Create the Signing Request + +Use the `create certificate request webserver` command to generate the certificate signing request. + +``` +admin@t327-dut1.cond# create certificate request webserver +Country name (2 letter code): US +State or province name (full name): Massachusetts +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): engineering +Common name: www.router.com +Email address: bob@juniper.net +Subject Alternative Name - DNS (fully qualified domain name): www.router.com +Subject Alternative Name - IP Address: 1.1.1.1 + +Request successfully generated: + +-----BEGIN CERTIFICATE REQUEST----- +MIIDLDCCAhQCAQAwgZkxFzAVBgNVBAMMDnd3dy5yb3V0ZXIuY29tMQswCQYDVQQG +EwJVUzERMA8GA1UEBwwIV2VzdGZvcmQxEDAOBgNVBAoMB0p1bmlwZXIxFDASBgNV +... +. +. +. +-----END CERTIFICATE REQUEST----- +``` + +### 4. Import the Certificate + +After the certificate is signed and returned, it is imported into the SSR for use by the webserver using the `import certificate webserver` command. This process validates the imported certificate against the trusted certificates entered using `trusted-ca-certificate`, and checks for insecure algorithms and invalid configurations. + +**DO NOT ignore any errors, warnings, or failures in this process.** Bypassing or disabling these validations will result in a non-compliant configuration. + +The following example shows an **invalid** self-signed certificate: + +``` +admin@t327-dut1.cond# import certificate webserver +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN CERTIFICATE----- +MIIDHTCCAgWgAwIBAgICL/AwDQYJKoZIhvcNAQELBQAwDzENMAsGA1UEAwwEMTI4 +VDAiGA8yMDI0MDYwNjEyMzIzMVoYDzIwMjUwNjA3MTIzMjMxWjAPMQ0wCwYDVQQD +... +RaIliPRAdN85EXDiAP68ytg5D2ZzxCpmRvj4AiFI3JOc +-----END CERTIFICATE----- + +-----BEGIN PRIVATE KEY----- +MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCo4PCT4Wp89t5P +53ZJtfgKwdV/CfAi3uXAfWmdluKlXjarlgTc6rgX8wGNSRj5/AajEUU6Z68DaejR +... +KBs2Hz/E/goCvyEqNaJOix+l +-----END PRIVATE KEY----- + +⚠ Importing... +certificate contains the following issues: certificate is self-signed +/usr/lib/128technology/unzip/pcli/runfiles/pypi__36__cryptography_40_0_2/cryptography/x509/base.py:576: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. + return rust_x509.load_pem_x509_certificates(data) +Could not validate certificate chain against a trusted anchor. +Would you like to import anyways? [y/N]: N +``` + +### Web Interface Example + +1. From the Authority level, select Authority Settings. + +![Authority Settings Button](/img/config-authority-settings-button.png) + +2. Scroll down to Trusted CA Certificate and click **ADD**. + +![Add Trusted Certificate](/img/import-webserver-cert1.png) + +3. Enter the name of the certificate, set the validation mode to strict, and paste in the certificate text. + +![Paste Certificate](/img/import-webserver-cert2.png) + +4. Click **Validate** and **Commit**. + +## SSH Server Cryptographic Algorithms + +The following SSH parameter lists are hard-coded as the system defaults: + +``` +KexAlgorithms diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256 +HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256,ssh-rsa +Ciphers aes256-ctr,aes128-ctr +MACs hmac-sha2-512,hmac-sha2-256 +``` + +These default SSH parameters are defined by the template file `/usr/lib/128technology/sshd/config.template.fips`: + +If these lists are changed, the `128T` service must be restarted with `systemctl restart 128T`. + +:::important +The template file will be overwritten when newer versions of `128T` software are installed. Changes to this file must be persisted elsewhere and compared to versions from new software. +::: + +### Additional SSH Information + +- Idle SSH sessions are logged out after 60 minutes of inactivity. +- SSH Mode Verification performs strict mode checking of home directory configuration files, as well as user-specific SSH configuration files to prevent one user from logging on to the system as another user. +- SSH logon by a non-certificate-trusted host is not allowed. +- The SSH login grace time is limited to waiting for one minute for a password to be entered. +- SSH access is limited to users assigned to the `wheel` group. +- When creating a user with SSH privileges from the UI, that user must be assigned to an admin user group. +- The SSH client may be used with the `/usr/bin/openssh-fips/ssh` command. When this command is run, the client uses the default ssh client config from `/etc/ssh/ssh_config` with additional restrictions that are hard-coded into the `ssh-fips` client and server. + +## Limiting Login Attempts + +If a user attempts to login unsuccessfully six times within a 15 minute window, they will be locked out for 30 minutes. The failed attempts are cumulative from both SSH and the web interface. The user will need to wait, or their account can be reset by an admin from the Linux shell. +Syntax to unlock: +`faillock --user --reset` + +Common Criteria requires that there is always one local account which can log in. As a “break-glass” the local root account can be used to issue the above ‘faillock’ command, to re-enable the admin account if that has become disabled. The root account is not accessible remotely, this must be performed from the system console. + +:::note +User account status is managed independently per node of the HA pair. +::: + +## File Upload Limitations +The `config import` functionality has the following constraints: + +- A max file size of 25 MB – an error is displayed if the file size is too large. +- One upload per user every 15 seconds. +- Verification of the `*.gz` file format. + +## Software Compliance Validation + +After installing the SSR Software, it is important to verify that the installation completed successfully and that the system is running in FIPS enforcement mode as required for Common Criteria compliance. After starting the SSR router or conductor, the login screen appears on the console. Alternatively you may `ssh` to the SSR management IP address using the admin account. + +1. Login using the admin credentials. +2. Use `show system version` to verify the correct software release is running: + +``` +Last login: Thu Oct 31 20:56:35 UTC 2024 from 10.27.14.48 on pts/0 +*admin@test1.RTR_EAST_CONDUCTOR# show system version +Fri 2024-11-01 18:22:07 UTC +✔ Retrieving system version 1/1 targets complete... + +==================== ======= ========= ======== ====================== ================ + Router Node Version Status Build Date Package +==================== ======= ========= ======== ====================== ================ + RTR_EAST_CONDUCTOR test1 6.3.0 r1 2024-09-28T01:23:30Z 128T-6.3.0-107 + .r1.el7 + (package + based) + +Completed in 0.13 seconds +admin@conductor.conductor# +``` + It should report Version 6.3.0 and Status r1. + +3. Type `shell` to suspend the CLI and enter the Linux shell. +4. Execute the command `sudo systemctl status 128T` and verify the service is listed as `active (running)`. + +``` +[root@conductor-test admin]# sudo systemctl status 128T -l + 128T.service - 128T service + Loaded: loaded (usr/lib/systemd/system/128T.service; enabled; vendor preset: disabled) + Active: active (running) since Thu 2024-10-31 18:04:29 UTC; 1day 50min ago + Main PID: 23317 (processManager) +``` + +5. Perform the following steps to verify the software integrity and protect against future tampering: + +- Execute the self-test scan `sudo systemctl start 128T-rpm-verify` + + The self-test scan is intiated and takes approximately two minutes to complete. Upon completion, run: + + `systemctl status 128T-rpm-verify` + + The scan validates all executable files on the system against the `sha256` digest hash recorded in the signed RPMs from which they were installed. This ensures that no files have been replaced or tampered with. + +- Run `systemctl status 128T-rpm-verify` to confirm that the service shows: + + `PASS: All RPM file digests verified` + +- If the result displays the following: + + `FAIL: RPM file digest mismatch detected` + + The failure must be resolved before continuing to ensure compliance. The full path to each file having a self-check digest mismatch is reported as part of the `status` output. + +- After the self-test scan test has succeed, enable the automatic self-test by executing the `enable` command in the linux shell: + + `sudo systemctl enable 128T-rpm-verify` + + The self-test is enabled on every subsequent reboot. If the self-test fails, the 128T service will not start. + +6. Perform the following steps to verify that FIPS security enforcment mode is enabled in the OS: + `openssl md5 /dev/null` + Expected result: `digital envelope routines … Disabled for fips` + +7. Run the following command to verify that FIPS security enforcing mode is enabled in the kernel: + `cat /proc/sys/crypto/fips_enabled` + Expected result: `1` + +8. Type `exit` to leave the Linux shell and return to the CLI. +9. Type `quit` to log out from CLI. + +You have now completed security validation of the installation. + +## CLI Access Post Install + +Use the following procedure to access the CLI at any time after installation. + +1. Open a terminal window and SSH to the SSR's IP address. +2. Use your login credentials to log in to the SSR + + - If using an account other than admin, type `pcli` to start the SSR CLI. + + - Type `shell` to suspend the CLI and enter the Linux shell. + +To terminate an active session: + +- Type `exit` to return from the Linux shell to the CLI. + +- Type `quit` to log out from CLI. + +- If using an account other than admin, type `exit` to end the login session. + +Common Criteria certification does not require any restrictions on executing commands. See the [Configuration Command Reference Guide](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide) for command information and usage. + +## Additional Software Self-Tests + +In addition to the 128T-rpm-verify RPM binary validation self-test described in the previous section, the SSR software also runs FIPS power-on self-tests at every boot. These are split into three main functional areas: + +- HMAC signature validation of the cryptography related software +- Kernel known-answer tests for the FIPS subsystem +- SSL known-answer tests for the FIPS algorithms + +If any self-test fails, the corresponding cryptographic operations performed by that component are denied and the system journal records an error in the log. + +### HMAC Signature Validation + +Upon installation from the ISO, an HMAC signature is calculated for the Linux kernel and written to the boot partition on disk. With each subsequent boot the software runs an HMAC check of the kernel and compares the result to the stored value. + +If the calculated HMAC matches the stored value, the bootloader continues loading the kernel. + +The validation status is displayed very briefly on console during boot - it scrolls by quickly unless there is an error. + +![validation status](/img/cc_fips_software_self_test1.png) + +It is recorded in `/var/log/messages` for the current boot: + +![Validation status messages](/img/cc_fips_software_self_test2.png) + +It is also recorded in the systemd journal for historical data: + +![Validation status messages](/img/cc_fips_software_self_test3.png) + +If the calculated HMAC does not match the stored value, the bootloader denies loading the kernel and halts the system. In this case, the error log **FATAL: FIPS integrity test failed** is displayed on the system consoleas shown below. + +![HMAC Mismatch](/img/cc_fips_software_self_test4.png) + +### Kernel Known Answer Tests + +The Kernel Known Answer Tests (KAT) for the FIPS subsystem run automatically at startup. Any failures are displayed on the system console during boot. These scroll quickly off screen, but are recorded in `/var/log/messages` for the current boot: + +![KAT Test Failure Log](/img/cc_fips_software_self_test5.png) + +The list shown here is edited for brevity. There are over 120 tests in total. + +It is also recorded in the systemd journal for historical data: + +![KAT Test Failure Journal](/img/cc_fips_software_self_test6.png) + +### OpenSSL Known Answer Tests + +The SSL library used on the SSR is FIPS certified as part of the Oracle Linux 7 operating system. Oracle FIPS documentation is available at https://www.oracle.com/a/ocom/docs/corporate/140sp4170.pdf. Chapter 9 describes the self-test behaviors. + +In summary: + +- Self-tests for each cryptographic algorithm are run whenever the OpenSSL library is loaded into memory on a FIPS-enabled system. The cryptographic module HMAC is also validated using a similar scheme as described above. +- On successful completion of all tests, the OpenSSL module comes into service for the linked application. If any of the tests fail, the module transitions to an error state and the application fails with an error log. +- OpenSSL a set of periodic runtime re-validation tests, which may be triggered during rekeying or other activities. +- No external logs are exposed from OpenSSL during this activity, but the failure to start OpenSSL applications such as OpenSSH are logged by the respective application. + +### Recovery Action for All Self-test Failures + +Regardless which functional area triggers a self-test failure, the recovery process is the same: + +1. Power off the SSR hardware +2. Wait 30 seconds +3. Power on the SSR hardware + +If the system still fails to boot normally after power cycling, the software must be considered compromised. + +Recovery for compromised software requires reinstalling the SSR software from the distribution ISO. This process erases the current disk content and applies a fresh installation. + + + + + diff --git a/docs/cc_fips_6.3.0_appendix.md b/docs/cc_fips_6.3.0_appendix.md new file mode 100644 index 0000000000..9fb8f45bc1 --- /dev/null +++ b/docs/cc_fips_6.3.0_appendix.md @@ -0,0 +1,161 @@ +--- +title: Appendix +sidebar_label: Appendix +--- + +## Common Criteria Sample Configuration + +Shown below is a simple example configuration. Note that this is not a complete configuration, and some values have been removed. + +``` +config + + authority + conductor-address 10.0.0.2 + + + + router conductor + name test-conductor + + node node1 + name node1 + + device-interface mgmt + name mgmt + pci-address + forwarding false + + network-interface mgmt + name mgmt + global-id 1 + + address 10.0.0.2 + ip-address 10.0.0.2 + prefix-length 24 + exit + + address 2001::2 + ip-address 2001::2 + prefix-length 64 + exit + exit + exit + exit + exit + + router router + name test-router + inter-node-security internal + + system + inactivity-timer 86400 + + audit + + traffic + enabled true + exit + exit + exit + + node node1 + name node1 + asset-id + role combo + + device-interface mgmt + name mgmt + pci-address + forwarding false + + network-interface mgmt + name mgmt + global-id 2 + + address 10.0.0.3 + ip-address 10.0.0.3 + prefix-length 24 + exit + exit + exit + + device-interface ge-2 + name ge-2 + pci-address + + network-interface ge-2 + name ge-2 + global-id 3 + tenant lab + + address 2.2.2.1 + ip-address 2.2.2.1 + prefix-length 24 + exit + + address 2001:0:2::1 + ip-address 2001:0:2::1 + prefix-length 64 + exit + exit + exit + + device-interface ge-3 + name ge-3 + pci-address + + network-interface ge-3 + name ge-3 + global-id 4 + + address 3.3.3.1 + ip-address 3.3.3.1 + prefix-length 24 + exit + + address 2001:0:3::1 + ip-address 2001:0:3::1 + prefix-length 64 + exit + exit + exit + exit + exit + + tenant lab + name lab + exit + + + + service lab_ipv4 + name lab_ipv4 + address 0.0.0.0/0 + + access-policy lab + source lab + permission allow + exit + service-policy lab_service_policy + exit + + service lab_ipv6 + name lab_ipv6 + address ::0/0 + + access-policy lab + source lab + permission allow + exit + service-policy lab_service_policy + exit + + service-policy lab_service_policy + name lab_service_policy + exit + exit +exit + +``` + diff --git a/docs/cc_fips_6.3.0_banners.md b/docs/cc_fips_6.3.0_banners.md new file mode 100644 index 0000000000..423184d025 --- /dev/null +++ b/docs/cc_fips_6.3.0_banners.md @@ -0,0 +1,120 @@ +--- +title: Configuring Banners +sidebar_label: Configuring Banners +--- + +Administrators can configure a login banner message to identify a Common Criteria compliant instance using the `configure authority web-messages` command or using the GUI. + +## Using the GUI + +![Configure Web Messages](/img/config_web_message.png) + +![Command line messages](/img/conf_cli_message.png) + +## Using the Command Line + +### `configure authority cli-messages` + +Configure CLI Messages + +##### Subcommands + +| command | description | +| ------- | ----------- | +| `delete` | Delete configuration data | +| [`login-message`](#configure-authority-cli-messages-login-message) | The message displayed before login through console. | +| `override-generated` | Force auto-generated configuration and any modifications to it to persist on commit | +| `show` | Show configuration data for 'cli-messages' | +| [`welcome-message`](#configure-authority-cli-messages-welcome-message) | The message displayed after a successful login through console. | + +### `configure authority cli-messages login-message` + +The message displayed before login through console. + +#### Usage + +``` +configure authority cli-messages login-message [] +``` + +##### Positional Arguments + +| name | description | +| ---- | ----------- | +| string | The value to set for this field | + +#### Description + +##### string + +A text value. + +### `configure authority cli-messages welcome-message` + +The message displayed after a successful login through console. + +#### Usage + +``` +configure authority cli-messages welcome-message [] +``` + +##### Positional Arguments + +| name | description | +| ---- | ----------- | +| string | The value to set for this field | + +#### Description + +##### string + +A text value. + +### `configure authority web-messages` + +Configure Web Messages + +##### Subcommands + +| command | description | +| ------- | ----------- | +| `delete` | Delete configuration data | +| [`login-message`](#configure-authority-web-messages-login-message) | The message displayed on the login screen. | +| `override-generated` | Force auto-generated configuration and any modifications to it to persist on commit | +| `show` | Show configuration data for 'web-messages' | +| [`welcome-message`](#configure-authority-web-messages-welcome-message) | The message displayed after a successful login. | + +### `configure authority web-messages login-message` + +The message displayed on the login screen. + +#### Usage + +``` +configure authority web-messages login-message [] +``` + +##### Positional Arguments + +| name | description | +| ---- | ----------- | +| string | The value to set for this field | + +### `configure authority web-messages welcome-message` + +The message displayed after a successful login. + +#### Usage + +``` +configure authority web-messages welcome-message [] +``` + +##### Positional Arguments + +| name | description | +| ---- | ----------- | +| string | The value to set for this field | + + diff --git a/docs/cc_fips_6.3.0_compliance_guidelines.md b/docs/cc_fips_6.3.0_compliance_guidelines.md new file mode 100644 index 0000000000..b16e59323a --- /dev/null +++ b/docs/cc_fips_6.3.0_compliance_guidelines.md @@ -0,0 +1,72 @@ +--- +title: Common Criteria Compliance Guidelines +sidebar_label: Common Criteria Compliance Guidelines +--- + +For compliance, the following configuration considerations must be made: + +- FIPS mode must be enabled **during installation**. Use of anything other than FIPS mode is not compliant with Common Criteria certification. +- Upon configuration of a valid, `trusted-ca-certificate`, and the [Secure Communications](cc_fips_6.3.0_otp_router_install.md#enable-secure-communication) procedures, all methods of configuration are Common Criteria compliant; procedures may be performed from the CLI, the web interface (GUI), or through the use of [APIs](intro_rest_graphql_apis.md). For information about configuring a `trusted-ca-ertificate`, see [Signing and Importing Webserver Certificates](cc_fips_6.3.0_access_mgmt.md#signing-and-importing-webserver-certificates). +- When installing a router, the [IPv4 Option Filter](cc_fips_6.3.0_sec_firewall_filtering.md#ipv4-option-filtering) must be set to `drop-all`. +- When installing a router, the [ICMP Session Match](cc_fips_6.3.0_sec_firewall_filtering.md#icmp-type-as-a-session-attribute) must be set to `identifier-and-type`. +- Configure the [TCP Half-Open Connections Limit](cc_fips_6.3.0_sec_firewall_filtering.md#tcp-half-open-connection-limit) for firewall. +- [Secure Communications](cc_fips_6.3.0_otp_router_install.md#enable-secure-communication), including Strict Host Key Checking and Asset Connection Resiliency must be enabled during router installation. Steps are provided as part of the Router installation process. +- The `password-policy` must define the minimum password length and maximum number of permitted login attempts per user. Please refer to [Username and Password Policies](cc_fips_6.3.0_config_password_policies.md) for policies, and to [`configure authority password-policy`](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide#configure-authority-password-policy) for CLI commands and context for assigning these values. +- The `admin` account must be given `sudo` privileges allowing it to use the shell for some management capabilities. Edit the `/etc/sudoers` file as `root` using the `visudo` command. This allows you to add an entry for `admin` which will persist across reboots. For additional information, please see [Root Access](cc_fips_6.3.0_access_mgmt.md#root-access) in the Access Management section. +- Traffic logging must be enabled by setting the following command to `true`: `configure authority router router system audit traffic enabled true`. This is a resource intensive setting. Not more than a few sessions are expected to run while collecting traffic events. + +- Any services that are used to enforce evaluated firewall functionality must have a service-policy attached that applies strict transport state enforcement: + `configure authority service-policy transport-state-enforcement strict` + This feature must be configured on services where the evaluated firewall capabilities are expected to be enforced. For services that fall outside of the need for firewall security functionality, such as an HA configuration where the states are not synced across devices, setting this feature to strict may have an impact on traffic flow. It is up to your discretion whether to apply the same restrictions on the service. + + For overview information about service policies, please see [Service and Service Policy Design](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/bcp_service_and_service_policy_design). + + For information about configuration baselines, please see [Service Policy Baseline Configuration](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/bcp_service-policy_defaults). + +- Common Criteria Compliance assessment includes all SSR interfaces. +- Security functionality called out in this guide is required for Common Criteria compliance. Other security features available with the SSR will not jeopardize the compliance certification, but are not compliance requirements. +- The use of SSH is necessary for installation and configuration. Use of SSH on the SSR after FIPS mode has been enabled during install is secure, and compliant with Common Criteria. + +## Compliant SSR Hardware + +The following table provides a complete list of compliant hardware. + +| PLATFORM | NETWORKING | +| --- | --- | +| SSR120 | 2 x 1GbE combo RJ45/SFP
4 x 1GbE RJ4 | +| SSR130 | 2 x 1GbE combo RJ45/SFP
6 x 1GbE RJ45 | +| SSR1200 | 8 x 1GBe RJ45
4 x 1/10 GbE SFP+ | +| SSR1300 | 6 x RJ-45
4 x 10GbE SFP+
3 x 1/10GBe SFP+
4 x 1GBe Ethernet | +| SSR1400 | 6 x 1G RJ-45
4 x 10G SFP+
4 x 1/10/25G SFP28 | +| SSR1500 | 6 x 1G RJ-45 | + +Juniper SSR Common Criteria certified platforms implement cryptographic algorithms on CPUs covered by the following validations: +- [37481](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?validation=37481) +- [37482](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?validation=37482) +- [37469](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?validation=37469) + +## Out of Scope Features + +The following functionality and platforms **are not certified** under Common Criteria. + +- SSR Software versions other than V6.3.0-R1. +- Non-Juniper branded hardware platforms running SSR Software. +- Juniper branded hardware platforms not explicitly included. +- Juniper SSR Software for virtual platforms. +- Juniper MIST. +- IPSec, SNMP, LDAP. +- Virtual Private Network (VPN) and Intrusion Prevention System (IPS) functions. +- SSR Plugins, particularly Wireguard, are excluded from Common Criteria certification. + +### Physical Security + +The SSR Hardware has no physical restrictions for Common Criteria certification, however, there is an assumption of physical security. The Administrator should ensure that physical security, commensurate with the value of the SSR and the data it contains, is provided by the environment into which SSR is deployed. + +### Additional Information Related to Common Criteria + +Common Criteria certification uses FIPS mode to provide cryptographic support. Without FIPS mode enabled during installation, the SSR is not compliant. FIPS mode provides all secure cyphers, and therefore **no additional cryptographic keys are used**. + +:::important +The use of non-evaluated cryptographic engines or use without FIPS mode enabled does not conform to the Common Criteria compliance guidelines and is not certified. +::: + diff --git a/docs/cc_fips_6.3.0_config_audit_event.md b/docs/cc_fips_6.3.0_config_audit_event.md new file mode 100644 index 0000000000..f53b13ae41 --- /dev/null +++ b/docs/cc_fips_6.3.0_config_audit_event.md @@ -0,0 +1,868 @@ +--- +title: Audit Events and Logging +sidebar_label: Audit Events and Logging +--- +The Session Smart Router can be configured to maintain a history of several different class of events in the *event log*, which can subsequently be used to support compliance audits, forensics on network issues related to configuration (misapplied or otherwise), and traceability. This document covers: +- Types of events available on the router +- Enabling the Audit events + +## Event Types +The events generated by the router are classified into the following categories: + +### Traffic Events +Traffic events are generated as sessions are created on the router. These include details such as the protocol, source address, source port, destination address and destination port. In addition, the success or failure status along with a reason code for failure cases are included in the event. + +### Administration Events +Various administration actions performed by a user such as SSH login generate this category of events. The events contain the details about the user action, whether or not the action was permitted, and the reason for any failures. + +### System Events +Various system level events such as service and process restarts are generated by this event category. The details include information about the user and details about the underlying action. + +### Alarm Events +All the SSR alarms generate an add event when the alarm is raised and a clear event when the alarm is cleared. The alarm events can be used to view the history of the events associated with the alarms. The alarm events are implicit events and cannot be disabled via configuration. See [Alarms and Events](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/events_overview) for more details. + +### Provisioning Events +The provisioning events are generated for software download and upgrades as well as for configuration changes that are processed on the router. For configuration changes the event contains a diff of the configuration change that triggered the event. These are implicit events and cannot be disabled via configuration. + +## Basic Configuration +The configuration for audit logging is performed under the `system > audit` branch in the `router` hierarchy. + +To enable audit logging, set `audit administration enabled` to `true`. For cases where an SSR router is not managed by a conductor, audit logging configuration is added to the `system > audit` branch under the `router`. The pcli example below describes the command hierarchy. + +If `auditd` fails to start or is prevented from running, an immediate, real-time message is displayed to all users indicating that the audit logging capability is impacted. This message persists until the failure is resolved. + +### Enable Basic Audit Logging - CLI + +:::note +Configuration not related to audit logging has been filtered out for illustrative purposes. +::: + +``` +config + authority + router my-router + name my-router + system + audit + administration + enabled true + exit + exit + exit + exit + exit +exit +``` + +### Enable Basic Audit Logging - GUI + +1. From the Authority, select your router + +![Choose Router](/img/configure-audit-logging1.png) + +2. Scroll down and select System Settings. + +![System Settings](/img/configure-audit-logging2.png) + +3. Scroll down to Admin Audit Settings, and set it to `true`. + +![Admin Audit Settings](/img/config-audit-logging3.png) + +### Set the Disk Full Action + +Common Criteria compliance does not permit the system to be operated without audit logging enabled. To meet compliance, you must configure the `disk-full-action` as `halt`. This ensures that the SSR device automatically shuts down when the disk has no free space remaining to write audit logs. + +The `halt` operation is not the default action for the SSR device, and must be configured to meet compliance. + +``` +config + authority + router my-router + name my-router + system + audit + disk-full-action halt + exit + exit + exit + exit +exit +``` + +### Storing Events for Short Durations + +By default the SSR routers store all events except traffic events for up to six months on the local disk. In some cases it might be desirable to shorten the length of time for these events to minimize the impact on the local disk. + +In the following example, all the events available on the SSR router are retained for one day. The `retention` is of type duration and can take values in hours and days; for example, 24h or 1d. + +``` +config + authority + router my-router + system + audit + retention 1d + exit + exit + exit + exit +exit +``` + +### Sending Traffic Events to a Syslog Server + +Traffic events are disabled and not persisted by default because they can produce a large volume of data. However, in situations where the traffic events need to be sent off-box for storage, such as a syslog server, they can be enabled but not persisted to local storage. The following snippet provides an example of that configuration. + +``` +config + authority + router my-router + system + audit + traffic + enabled true + persist false + exit + exit + exit + exit + exit +``` + +:::note +For a detailed explanation of configuring the Monitoring Agent to handle audit events, refer to the [SSR Monitoring Agent](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/concepts_monitoring) documentation. +::: + +#### On the SSR + +1. Authorize the **server** public key. + - Copy the `id_rsa.pub` file (`/root/.ssh/id_rsa.pub` located on the **server**) and append it to end of the `authorized_keys` file (`/home/admin/.ssh/authorized_keys`) on the device. + +2. Open the file `/usr/lib/128technology/sshd/config.template.fips` and change the setting `AllowTcpForwarding no` from **no** to `AllowTcpForwarding yes`. + +3. Create an event collector input to capture the traffic events. An example input configuration is shown below. + +```toml +[[inputs.t128_events]] + # It is a best practice to specify a custom index file location + index-file = "/var/lib/128t-monitoring/state/events.index" + topic = "events" + [inputs.t128_events.tagpass] + type = ["traffic"] +``` +Refer to [Event Collector](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/concepts_monitoring#event-collector) for information about creating an event collector. + +4. Define an output where the events are to be sent. In this example, the events are sent to a syslog server. + +```toml +[[outputs.syslog]] + address = "udp://127.20.20.20::1" + default_sdid = "128T" +``` + +5. The input and output are placed in the input and output directories respectively and tied together by the [Monitoring Agent configuration](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/concepts_monitoring#config). A sample monitoring agent configuration: + +```yaml +enabled: true + +inputs: + - name: traffic-events +outputs: + - name: my-syslog + +``` + +6. On the syslog server, start a remote forwarding tunnel to collect the syslog events: + + `ssh -R 127.0.0.1:514:127.0.0.1:514 admin@192.168.1.14 -o ExitOnForwardFailure=yes -i /root/.ssh/id_rsa` + +Once these configurations are in place, starting the [Monitoring Agent application](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/concepts_monitoring/#syslog) will send events to syslog. + +## Remote Logging + +Audit logs can be stored off system by configuring a remote logging server. When the IP address and port are configured, audit logs are sent to the remote system for storage and review. + +``` +config + authority + router Fabric128 + name Fabric128 + system + audit + remote-logging-server 1.1.1.1 60 + address 1.1.1.1 + port 60 + exit + exit + exit + exit + exit + +``` + +Once set, any time a connection is lost between the SSR and the remote logging server, the SSR will automatically attempt to reconnect with the server. In a case where the server is unreachable, the device will shut down. + +## Configuring Syslog Over TLS + +Syslog over TLS allows the secure transportation of system log messages from the syslog client to the syslog server. TLS uses certificates to authenticate and encrypt the communication. + +### Syslog over TLS Configuration - Generate Certificate + +Use the following examples to generate a client certificate for use on the device. Note that to be Common Criteria compliant, steps 1-3 must be performed using the CLI. Step 4 may be performed using either the CLI or GUI. For consistency, it is recommended to complete the process using the CLI. + +#### 1. Generate the Signing Request + +Use the `create certificate request client` command to generate the signing request. + +:::note +Use of an IP-based `Subject Alternative Name` is not supported under Common Criteria. Use of this parameter will result in a non-conforming configuration. +::: + +``` +admin@conductor-node-1.Conductor# create certificate request client syslog +Country name (2 letter code): US +State or province name (full name): MA +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): +Common name: dut1 +Email address: +Subject Alternative Name - DNS (fully qualified domain name): +Subject Alternative Name - IP Address: +% Error: Could not create request: Subject Alternative Name (DNS or IP address) is required +admin@conductor-node-1.Conductor# create certificate request client syslog +Country name (2 letter code): US +State or province name (full name): MA +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): +Common name: dut1 +Email address: +Subject Alternative Name - DNS (fully qualified domain name): dut1 + +Request successfully generated: + +-----BEGIN CERTIFICATE REQUEST----- +MIIC1jCCAb4CAQAwTjENMAsGA1UEAwwEZHV0MTELMAkGA1UEBhMCVVMxETAPBgNV +BAcMCFdlc3Rmb3JkMRAwDgYDVQQKDAdKdW5pcGVyMQswCQYDVQQIDAJNQTCCASIw +DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ8WwHXP/z49sFsxpN5L9THO5y8N +f/as8Nn6XUyG86YyxcR5IYL5gKR5//EunoVjLAUCHgBqxwaUa3enhNEQS97N4Bcs +E7YygMkI7oAnHCioslB+x2Am/xKPRosh3s50fIN3mY409/byMGipfGcyNlMn8XbS +XF/zmGBI1/4aRbeqL5VMDPO+9DNRxXMgqBs2y48WanGvZeZTP5B/sSczlhOSxHnu +DxNYQ7+rZs9NpKzktCXOSA8nszHp5PNCWsa8tVNQvyhAqboTGrXQZhjZRWzg3nzS +. +. +. +wp4dOHuKsnf+ZsfNK4AGUYdh3qEa1/xJxyug1R3AGjItbkUzbJpR6hp7B0YYWV87 +QALMf6F0SKBDXg++ +-----END CERTIFICATE REQUEST----- +``` + +#### 2. Configure the Trusted CA Certificate + +The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. + +Create a root certificate named `ca_root_syslog` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# configure authority trusted-ca-certificate ca_root_syslog +*admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root_syslog])# content +Enter plain for content (Press CTRL-D to finish): +-----BEGIN CERTIFICATE----- +MIIDlDCCAnygAwIBAgIVAJHxzhL42q7io2PBDPR+TCeBsyQgMA0GCSqGSIb3DQEB +CwUAMFExCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1NYXNzYWNodXNldHRzMREwDwYD +VQQKDAhUZXN0IEluYzEXMBUGA1UEAwwOY2EuZXhhbXBsZS5jb20wHhcNMjQxMDIy +MTYzODI1WhcNMjUxMDIyMTYzODI1WjBRMQswCQYDVQQGEwJVUzEWMBQGA1UECAwN +TWFzc2Fja/m1nIs+rY0Fs1LIyWA1kswIVGVzdCBJbmMxFzAVBgNVBAMMDmNhLmV4 +YW1wbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqn81ZnhT +zAPiXOdzJVRdy6GGQJKodQ89/hxZ3oHAFN/7QhknXyWnfz3heShEAw5xdL3PV230 +. +. +. +qynFiqlV0UDGgH+e8hCp41Seva5vBGYvwMVHPU80rhoAsTh1BNpM1r9xbvDQs5ui +3QyeFCt/O0A= +-----END CERTIFICATE----- +``` + +#### 3. Import the Client Certificate + +After the certificate is signed and returned, it is imported into the SSR for use by the client using the `import certificate client` command. It is validated against any trusted certificates entered using `trusted-ca-certificate`. + +The following example shows an valid self-signed certificate being imported: + +``` +admin@conductor-node-1.Conductor# import certificate client syslog +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN PRIVATE KEY----- +MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDFrn/2q4mijt14 +gjmN2agDfu6sykg4OJ2NDy4IRrBYilExRJHllAndtc04rp7EQ544Z+/J/dNJrmXK +GnHvm/Rg0UdKnbFrw5aentpx3rFefdaf8nlJLW5rFH1wxDqUhE+y5q+s+8k3ESt0 +9L/26OxTQP11t5Vh/BEkK5iVHLDBGyHntUvEnM5tFWL7+NvefhuZ6McvY7GPDR8c +bkuNHXlv9laeXQlI6IiiYum8waQDnJBGEx2wPTUguZJWP0YgxLinKiCDIINNEf+Y +dGqxf7I/yKn1gH+Swh0sAYn33651EaGAzjMHYhmpPVR0K9IAPbyGucK0aOriJqZ5 +91wL39G5AgMBAAECggEAE2/xDSQYyG8bv7muRxBbwNw+Q6cwKrcGZtRTRmUM+ee/ +zAReBCDmR3KU1zn0SoALkqhFn6rhl6EaSSEIivLeuJZbWC7hPyNgMACWohOvhQcC +. +. +. +WiYWxHz5Q4wUxV5uTJR3Jq5rzcHr1shyVDT+aFf9tyNdcLFfbziZ1y/EfAPkOOoH +jLD4SXCWbmRxHYVMn3yhqK4= +-----END PRIVATE KEY----- + +-----BEGIN CERTIFICATE----- +MIIDpDCCAoygAwIBAgIVAL1k460IeyrQWoU82ZVHZ2asUrTuMA0GCSqGSIb3DQEB +CwUAMFExCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1NYXNzYWNodXNldHRzMREwDwYD +VQQKDAhUZXN0IEluYzEXMBUGA1UEAwwOY2EuZXhhbXBsZS5jb20wHhcNMjQxMDIy +MTYzODI4WhcNMjUwMTIwMTYzODI4WjBVMQswCQYDVQQGEwJVUzEWMBQGA1UECAwN +TWFzc2FjaHVzZXR031sTH3nuMB3r+h0uSHa1Lc0un+/xGzAZBgNVBAMMEmNsaWVu +dC5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWu +f/ariaKO3XiCOY3ZqAN+7qzKSDg4nY0PLghGsFiKUTFEkeWUCd21zTiunsRDnjhn +. +. +. +zTwd4+soylkHxCW2zZ50lUUqqNt1nSIcVF2V3qqxRZXZcJtN5y9+brpc9Z8eiXys +9cgLsL60tukLdwxH5S6gAw/MSm6ABYjdv +-----END CERTIFICATE----- + +/usr/lib/128technology/unzip/pcli/runfiles/pypi__36__cryptography_40_0_2/cryptography/x509/base.py:576: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. + return rust_x509.load_pem_x509_certificates(data) +✔ Importing... +Certificate imported successfully +Would you like to add the certificate to your configuration? [y/N]: y +Which router is this certificate for? (Select all if it applies to the entire authority) [all]: all + +Certificate imported successfully +Would you like to clean up the temporary certificate and key files? [Y/n]: Y +``` + +#### 4. Configure the Device to Accept the Client Certificate + +Use the following example command to configure your device to accept the certificate. + +` configure authority router ComboWest node combo-west radius client-certificate-name syslog` + +This action can also be performed from the web interface: + +![Client Certificate Import](/img/client_cert_accept_syslog.png) + +### Syslog over TLS Configuration - Existing Certificate + +Use the following information to configure Syslog over TLS using an existing certificate. + +#### 1. Configure the Trusted CA Certificate. + +The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. + +Create a root certificate named `ca_root_syslog` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root_syslog +admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root_syslog])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +:::note +The `trusted-ca-certificate` is a list and may contain different CA roots used for different certificates. In that case, naming them all `ca_root` would not be suitable. It is recommended to choose a name that is meaningful to the user and CA, eg: `ca_root_syslog`. +::: + +#### 2. Configure a Client Certificate to be used for the Syslog Client. + +Repeat the previous step to create a client certificate named `syslog`. + +``` +admin@conductor-node-1.Conductor# config authority client-certificate syslog +admin@conductor-node-1.Conductor (client-certificate[name=syslog])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +#### 3. Configure the Syslog Server at the Authority level to use the configured client certificate. + +The following configuration example will add a syslog server named `syslog` that will use the previously configured client certificate. + +``` +*admin@t327-dut1.cond# configure authority router cond system syslog server +*admin@t327-dut1.cond (server [syslog])# up +*admin@t327-dut1.cond (syslog)# client-certificate-name syslog +*admin@t327-dut1.cond (syslog)# protocol tls +*admin@t327-dut1.cond (syslog)# ocsp strict +*admin@t327-dut1.cond (syslog)# facility any +*admin@t327-dut1.cond (syslog)# severity info +*admin@t327-dut1.cond (syslog)# top +``` + +To complete the process, `validate` and `commit` the changes. After the confiuration changes have been committed, the SSR will send the syslog to the server `syslog` over TLS. + +## Secure Audit Logs Transport + +To provide secure transport of audit logs to and from a remote server, use the following procedures: + +### On the Audit Server: + +1. Generate a private/public key using the utility `ssh-keygen -t rsa -b 4096`. + +2. Open (or create if necessary) the known host file `/root/.ssh/known_hosts` and authorize the host; prepend the IP address of the host with the public key from the SSR `/etc/ssh/ssh_host_rsa_key.pub`: + +``` +[192.168.1.14 ssh-rsa +AAAAB3NzaC1yc2EAAAADAQABAAABAQC4UZe/Q8jce6c02IfFM64UcSJ/IZu3GQNLuElbzsrVZHEVu3/EfNp10acbx1PqlhSxJSJQwXe1Q1vEq6bMR8/tZU3fa6NwCt8rgGs8BT8NQuVHKj5s2CAKtBqhMHQmtngddbEHAj1WJShe3GBr4Xou1uw6o4SEo+8EjO56L3lzSK60dXOx/vDiuDFsNNUjfqD9qSRuwsHPkzdX5s6P8XTYo4OlvMPRplnhEmgczxjGeMQSPBp+vHf6uMHNOKUQqLQsA0dSVKM1CNApXuMsy7HakP1oOn9eKX/uf4VofNfrOW90PrKNd+E9jUgGiiSVc5H8QbCVmO2KhKmGh4wraGa/ +``` +3. Configure the audit server to listen on port 60. For example, using `auditd`: + - Set `tcp_listen_port = 60` in the file `/etc/audit/auditd.conf` + - `service auditd restart` + +### On the SSR + +1. Authorize the **server** public key. + - Copy the `id_rsa.pub` file (`/root/.ssh/id_rsa.pub` located on the **server**) and append it to end of the `authorized_keys` file (`/home/admin/.ssh/authorized_keys`) on the device. + +2. Open the file `/usr/lib/128technology/sshd/config.template.fips` and change the setting `AllowTcpForwarding no` from **no** to `AllowTcpForwarding yes`. +3. Add the config to point the audit server at `localhost port 60` and commit the changes. +``` +*admin@conductor-node-1.Conductor# compare config running candidate + +config + authority + router Conductor + name Conductor + system + audit + remote-logging-server 127.0.0.1 60 + address 127.0.0.1 + port 60 + exit + exit + exit + exit + exit +exit +``` + +4. Return to the audit server and start the port forwarding: + + `ssh -R 127.0.0.1:60:127.0.0.1:60 admin@192.168.1.14 -o ExitOnForwardFailure=yes -i /root/.ssh/id_rsa` + +## Example Audit Logs + +### SSH Session Establishment Failure + +``` +type=USER_AUTH msg=audit(1709742862.344:2320): pid=13394 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="?" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=failed' + +type=USER_AUTH msg=audit(1709742864.269:2321): pid=13394 uid=0 auid=4294967295 ses=4294967295 msg='op=password acct="(unknown)" exe="/usr/sbin/sshd" hostname=? addr=172.18.4.99 terminal=ssh res=failed' +``` + +### SSH Session Establishment Success + +``` +type=USER_AUTH msg=audit(1709742929.672:2335): pid=13700 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_faillock,pam_unix acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=USER_ACCT msg=audit(1709742929.674:2336): pid=13700 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_faillock,pam_unix,pam_localuser acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=CRYPTO_KEY_USER msg=audit(1709742929.676:2337): pid=13700 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=13701 suid=74 rport=52572 laddr=192.168.1.10 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.18.4.99 terminal=? res=success' + +type=USER_AUTH msg=audit(1709742929.678:2338): pid=13700 uid=0 auid=4294967295 ses=4294967295 msg='op=success acct="centos" exe="/usr/sbin/sshd" hostname=? addr=172.18.4.99 terminal=ssh res=success' + +type=CRED_ACQ msg=audit(1709742929.678:2339): pid=13700 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=LOGIN msg=audit(1709742929.678:2340): pid=13700 uid=0 old-auid=4294967295 auid=1000 tty=(none) old-ses=4294967295 ses=36 res=1 + +type=SYSCALL msg=audit(1709742929.678:2340): arch=c000003e syscall=1 success=yes exit=4 a0=4 a1=7ffe4754f5c0 a2=4 a3=3 items=0 ppid=2007 pid=13700 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=36 comm="sshd" exe="/usr/sbin/sshd" key=(null) + +type=PROCTITLE msg=audit(1709742929.678:2340): proctitle=737368643A2063656E746F73205B707269765D + +type=USER_START msg=audit(1709742929.686:2341): pid=13700 uid=0 auid=1000 ses=36 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=CRYPTO_KEY_USER msg=audit(1709742929.687:2342): pid=13734 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=13734 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRYPTO_KEY_USER msg=audit(1709742929.687:2343): pid=13734 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=13734 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRYPTO_KEY_USER msg=audit(1709742929.688:2344): pid=13734 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=13734 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRED_ACQ msg=audit(1709742929.688:2345): pid=13734 uid=0 auid=1000 ses=36 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=USER_LOGIN msg=audit(1709742929.730:2346): pid=13700 uid=0 auid=1000 ses=36 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=/dev/pts/1 res=success' + +type=USER_START msg=audit(1709742929.730:2347): pid=13700 uid=0 auid=1000 ses=36 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=/dev/pts/1 res=success' + +type=CRYPTO_KEY_USER msg=audit(1709742929.732:2348): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=13735 suid=1000 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=SYSCALL msg=audit(1709742940.326:2349): arch=c000003e syscall=159 success=yes exit=0 a0=55e40cbbf980 a1=1 a2=0 a3=55e40e52326c items=0 ppid=1 pid=6697 auid=4294967295 uid=38 gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" key="128T" +``` + +### SSH Session Termination + +``` +type=USER_END msg=audit(1709743019.474:2350): pid=13700 uid=0 auid=1000 ses=36 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' + +type=USER_LOGOUT msg=audit(1709743019.474:2351): pid=13700 uid=0 auid=1000 ses=36 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' + +type=CRYPTO_KEY_USER msg=audit(1709743019.475:2352): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=13734 suid=1000 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRYPTO_KEY_USER msg=audit(1709743019.475:2353): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=session fp=? direction=both spid=13734 suid=1000 rport=52572 laddr=192.168.1.10 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.18.4.99 terminal=? res=success' + +type=USER_END msg=audit(1709743019.478:2354): pid=13700 uid=0 auid=1000 ses=36 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=CRED_DISP msg=audit(1709743019.478:2355): pid=13700 uid=0 auid=1000 ses=36 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="centos" exe="/usr/sbin/sshd" hostname=172.18.4.99 addr=172.18.4.99 terminal=ssh res=success' + +type=CRYPTO_KEY_USER msg=audit(1709743019.479:2356): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=13700 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRYPTO_KEY_USER msg=audit(1709743019.479:2357): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=13700 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' + +type=CRYPTO_KEY_USER msg=audit(1709743019.479:2358): pid=13700 uid=0 auid=1000 ses=36 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=13700 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` + +### NTP Configuration Change + +The command `show event type system detail` shows an NTP configuration change. + +``` +==================================================================== + 2024-03-14T20:58:24.469Z Change to the running 128T configuration. +==================================================================== + Type: admin.running_config_change + Node: test1 + User: admin + Collector: configDirector + Description: running config changes are committed + Permitted: True + Source Ip: 172.18.15.253 + +config + authority + router Fabric128 + name Fabric128 + system + ntp + delete server force 172.2.10.13 + server 172.2.10.14 + ip-address 172.2.10.14 + exit + exit + exit + exit + exit +exit +``` + +### Unsuccessful Login Attempt Limit Met or Exceeded + +These will appear in the `sshd` journal for SSH-based logins, or `Dredd` if it is an API-based login. + +``` +Mar 14 18:21:25 t117-dut1.openstacklocal sshd[11536]: pam_faillock(sshd:auth): Consecutive login failures for user test account temporarily locked + +Mar 14 18:21:27 t117-dut1.openstacklocal sshd[11536]: Failed password for test from 172.18.15.253 port 61203 ssh2 +``` + +### All Use of Identification and Authentication + +This information is found within the journal of `sshd`. + +``` +Mar 14 18:23:23 t117-dut1.openstacklocal sshd[14546]: Accepted password for test from 172.18.15.253 port 61205 ssh2 +``` + +Banner Information: + +``` +$ ssh admin@Conductor +admin@10.22.0.68's password: +Last failed login: Mon Mar 18 04:07:15 UTC 2024 from 172.18.15.253 on ssh:notty +There were 2 failed login attempts since the last successful login. +Last login: Mon Mar 18 04:06:15 2024 from 172.18.15.253 ++---------------------------------------+ +| | +| Welcome to: | +| | +| | . . ,---. . ,---. ,---. ,--. | +| | | | | | | |---' |---' | | +| | `---' ' ' ' ' `---' ' | +| ---' | +| __ ___ __ __ __ | +| |\ | |_ | | | / \ |__) |_/ (_ | +| | \| |__ | |/\| \__/ | \ | \ __) | +| | +| Session Smart Networking Platform ... | ++---------------------------------------+ +admin@conductor-node-1.Conductor# +``` + +### Password-based Authentication + +This information is found within the journal of `sshd`. +``` +Mar 14 18:23:23 t117-dut1.openstacklocal sshd[14546]: Accepted password for test from 172.18.15.253 port 61205 ssh2 +``` + +### Logs for Manual Software Updates + +Logs for SSR software updates can be found at `/var/log/install128t/installer.log`. An example would be updating from `6.3.0-develop` to `6.4.0-develop`. + +``` +2024-03-14 21:34:32,004: INFO - Version requirement: 6.4.0-1.develop.el7 +2024-03-14 21:34:39,218: INFO - Verifying that 128T-0:6.4.0-1.develop.el7.x86_64 will be an upgrade +2024-03-14 21:34:39,218: INFO - Resolving version of Manifest matching 128T-manifest-6.3.0.0.202403021319.develop.el7 +2024-03-14 21:34:42,009: INFO - Using Manifest package 128T-manifest-0:6.3.0.0.202403021319.develop.el7-1.x86_64 +2024-03-14 21:34:51,737: INFO - Resolving version of Deprecated Packages file 128T-deprecated-packages-6.3.0.0.202403021319.develop.el7 +2024-03-14 21:34:55,061: INFO - Using Manifest package 128T-deprecated-packages-0:6.3.0.0.202403021319.develop.el7-1.x86_64 +2024-03-14 21:34:56,613: INFO - Resolving version of Manifest matching 128T-manifest-6.4.0.1.develop.el7 +2024-03-14 21:35:00,501: INFO - Using Manifest package 128T-manifest-0:6.4.0.1.develop.el7-1.x86_64 +2024-03-14 21:35:07,172: INFO - Resolving version of Deprecated Packages file 128T-deprecated-packages-6.4.0.1.develop.el7 +2024-03-14 21:35:10,274: INFO - Using Manifest package 128T-deprecated-packages-0:6.4.0.1.develop.el7-1.x86_64 +``` + +### All Management Activities of Security Functionality Data + +This includes the creation, modification, and deletion of firewall rules. Messages are logged at debug level when a rule is changed in `highway.log` + +``` +Mar 15 13:30:27.485 [HWMC|NIF ] DEBUG (GoogleTest) filter-rule change detected in interface 1-111.0 +``` + +Additionally, when the configuration is applied, the filter-rule being applied is logged in `runtimeStatsHwmOnConfig.log`. + +### Logs for Automatic Updates + +These logs capture the initiation of updates, and the result of the update attempt (success or failure). + +Logs for SSR software updates can be found at `/var/log/install128t/installer.log`. An example would be updating from `6.3.0-develop` to `6.4.0-develop`. + +``` +024-03-14 21:36:34,805: INFO - ================================================================================ +2024-03-14 21:36:34,805: INFO - Package Arch Version Repository Size +2024-03-14 21:36:34,805: INFO - ================================================================================ +2024-03-14 21:36:34,805: INFO - Upgrading: +2024-03-14 21:36:34,805: INFO - 128T x86_64 6.4.0-1.develop.el7 128tech-local-saved 164 M +2024-03-14 21:36:34,805: INFO - 128T-deprecated-packages +2024-03-14 21:36:34,805: INFO - x86_64 6.4.0.1.develop.el7-1 128tech-local-saved 3.5 k +2024-03-14 21:36:34,806: INFO - 128T-manifest x86_64 6.4.0.1.develop.el7-1 128tech-local-saved 25 k +2024-03-14 21:36:34,806: INFO - 128T-minion-watchdog x86_64 2.0.0-1 128tech-local-saved 2.6 M +2024-03-14 21:36:34,806: INFO - 128T-mist-wan-assurance +2024-03-14 21:36:34,806: INFO - x86_64 3.10.0-308 128tech-local-saved 5.0 M +2024-03-14 21:36:34,806: INFO - 128T-snmp-service x86_64 1.1.7-1 128tech-local-saved 3.2 M +2024-03-14 21:36:34,806: INFO - curl x86_64 7.29.0-59.0.3.el7_9.2 128tech-local-saved 272 k +2024-03-14 21:36:34,806: INFO - java-1.8.0-openjdk-headless +2024-03-14 21:36:34,806: INFO - x86_64 1:1.8.0.402.b06-1.el7_9 128tech-local-saved 33 M +2024-03-14 21:36:34,806: INFO - libcurl x86_64 7.29.0-59.0.3.el7_9.2 128tech-local-saved 224 k +2024-03-14 21:36:34,806: INFO - python x86_64 2.7.5-94.0.1.el7_9 128tech-local-saved 96 k +2024-03-14 21:36:34,806: INFO - python-libs x86_64 2.7.5-94.0.1.el7_9 128tech-local-saved 5.6 M +2024-03-14 21:36:34,806: INFO - python3 x86_64 3.6.8-21.0.1.el7_9 128tech-local-saved 70 k +2024-03-14 21:36:34,806: INFO - python3-libs x86_64 3.6.8-21.0.1.el7_9 128tech-local-saved 7.0 M +2024-03-14 21:36:34,806: INFO - Installing dependencies: +2024-03-14 21:36:34,806: INFO - 128T-plugin-starter x86_64 0.0.2-2 128tech-local-saved 2.3 M +2024-03-14 21:36:34,806: INFO - ember x86_64 1.4.0-3.el7 128tech-local-saved 4.5 M +2024-03-14 21:36:34,806: INFO - python-dns noarch 1.12.0-4.20150617git465785f.el7 +2024-03-14 21:36:34,806: INFO - 128tech-local-saved 233 k +2024-03-14 21:36:34,806: INFO - python2-dns noarch 1.12.0-0.el7 128tech-local-saved 3.0 k +2024-03-14 21:36:34,806: INFO - +2024-03-14 21:36:34,806: INFO - Transaction Summary +2024-03-14 21:36:34,806: INFO - ================================================================================ +2024-03-14 21:36:34,806: INFO - Install 4 Packages +2024-03-14 21:36:34,807: INFO - Upgrade 13 Packages +2024-03-14 21:36:34,807: INFO - +2024-03-14 21:36:35,606: INFO - Total size: 228 M +2024-03-14 21:36:35,606: INFO - Downloading Packages: +2024-03-14 21:36:36,368: INFO - Running transaction check +2024-03-14 21:36:37,441: INFO - Transaction check succeeded. +2024-03-14 21:36:37,442: INFO - Running transaction test +2024-03-14 21:36:44,839: INFO - Transaction test succeeded. +2024-03-14 21:38:31,381: INFO - Installed: +2024-03-14 21:38:31,381: INFO - 128T-plugin-starter.x86_64 0.0.2-2 +2024-03-14 21:38:31,381: INFO - ember.x86_64 1.4.0-3.el7 +2024-03-14 21:38:31,381: INFO - python-dns.noarch 1.12.0-4.20150617git465785f.el7 +2024-03-14 21:38:31,381: INFO - python2-dns.noarch 1.12.0-0.el7 +2024-03-14 21:38:31,381: INFO - +2024-03-14 21:38:31,381: INFO - Upgraded: +2024-03-14 21:38:31,381: INFO - 128T.x86_64 6.4.0-1.develop.el7 +2024-03-14 21:38:31,381: INFO - 128T-deprecated-packages.x86_64 6.4.0.1.develop.el7-1 +2024-03-14 21:38:31,381: INFO - 128T-manifest.x86_64 6.4.0.1.develop.el7-1 +2024-03-14 21:38:31,381: INFO - 128T-minion-watchdog.x86_64 2.0.0-1 +2024-03-14 21:38:31,382: INFO - 128T-mist-wan-assurance.x86_64 3.10.0-308 +2024-03-14 21:38:31,382: INFO - 128T-snmp-service.x86_64 1.1.7-1 +2024-03-14 21:38:31,382: INFO - curl.x86_64 7.29.0-59.0.3.el7_9.2 +2024-03-14 21:38:31,382: INFO - java-1.8.0-openjdk-headless.x86_64 1:1.8.0.402.b06-1.el7_9 +2024-03-14 21:38:31,382: INFO - libcurl.x86_64 7.29.0-59.0.3.el7_9.2 +2024-03-14 21:38:31,382: INFO - python.x86_64 2.7.5-94.0.1.el7_9 +2024-03-14 21:38:31,383: INFO - python-libs.x86_64 2.7.5-94.0.1.el7_9 +2024-03-14 21:38:31,383: INFO - python3.x86_64 3.6.8-21.0.1.el7_9 +2024-03-14 21:38:31,383: INFO - python3-libs.x86_64 3.6.8-21.0.1.el7_9 +2024-03-14 21:38:31,383: INFO - +2024-03-14 21:38:31,383: INFO - Complete! +2024-03-14 21:38:31,434: INFO - Successfully installed package(s) 128T-manifest-0:6.4.0.1.develop.el7-1.x86_64, 128T-deprecated-packages-0:6.4.0.1.develop.el7-1.x86_64 +``` + +### Discontinuous Changes to Time + +These changes can be Administrator actuated or changed using an automated process. Note that no continuous changes to time need to be logged. + +This logs the old and new values for the time, as well as the origin (e.g., IP address) of the attempt to change the time, and success or failure. + +The command `show event type system detail` displays changes to time. + +``` +======================================================================================================================== + 2024-01-01T00:02:35.514Z System clock was adjusted by NTP +======================================================================================================================== + Type: system.ntp_adjustment + Node: test2 + User: ntp + Collector: auditd + Event Detail: node=t276-dut2.openstacklocal type=SYSCALL msg=audit(1704067355.514:1953): arch=c000003e + syscall=227 success=yes exit=0 a0=0 a1=7ffceb4e2530 a2=aea5b a3=4ab382 items=0 ppid=1 pid=22241 auid=4294967295 uid=38 + gid=38 euid=38 suid=38 fsuid=38 egid=38 sgid=38 fsgid=38 tty=(none) ses=4294967295 comm="ntpd" exe="/usr/sbin/ntpd" + key="128T" old_time=2024-01-01T00:02:35.514000Z new_time=2024-03-15T17:58:18Z + New Date Time: 2024-03-15T17:58:18Z +``` + +### Local Session Termination - Inactivity Timer + +The termination of a local interactive session by the session locking mechanism due to session timeout. The `PCLILogger journal` will contain an entry such as: + +``` +Mar 17 23:45:25 t184-dut1.openstacklocal logragator[30093]: ERROR [MainThread:pcli.output:201] (admin:2299) - Session timed out after 900 seconds +``` + +### Remote Session Termination - Inactivity Timer + +The termination of a remote session by the session locking mechanism due to session timeout. The `PCLILogger journal` will contain an entry such as: + +``` +Mar 17 23:45:25 t184-dut1.openstacklocal logragator[30093]: ERROR [MainThread:pcli.output:201] (admin:2299) - Session timed out after 900 seconds +``` + +### Interactive Session Termination - Administrator-initiated termination + +The Administrator-initiated termination of the Administrator’s own interactive session. The `PCLILogger journal` will contain an entry such as: + +``` +Mar 17 23:45:25 t184-dut1.openstacklocal logragator[30093]: ERROR [MainThread:pcli.output:201] (admin:2299) - Session timed out after 900 seconds +``` + +### Trusted Channel Function Logs - User + +This allows the identification of the initiator and target of failed attempts to establish a trusted channel. + +#### Initiation + +Logged in `/var/log/audit/audit.log`: + +``` +type=CRYPTO_KEY_USER msg=audit(1710535870.175:2581): pid=1089 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=1089 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535870.185:2582): pid=1089 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=1089 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535870.186:2583): pid=1089 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1089 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_SESSION msg=audit(1710535870.192:2584): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-server cipher=aes128-ctr ksize=128 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha256 spid=1089 suid=74 rport=38122 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=CRYPTO_SESSION msg=audit(1710535870.194:2585): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha256 spid=1089 suid=74 rport=38122 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_AUTH msg=audit(1710535870.352:2586): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710535872.130:2587): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=none acct="t128" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710535872.140:2588): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=pubkey acct="t128" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710535875.285:2589): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_faillock,pam_unix acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=USER_ACCT msg=audit(1710535875.286:2590): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_faillock,pam_unix,pam_localuser acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710535875.287:2591): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=1089 suid=74 rport=38122 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_AUTH msg=audit(1710535875.289:2592): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=success acct="t128" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=success' +type=CRED_ACQ msg=audit(1710535875.289:2593): pid=1088 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=LOGIN msg=audit(1710535875.290:2594): pid=1088 uid=0 old-auid=4294967295 auid=1001 tty=(none) old-ses=4294967295 ses=28 res=1 +type=SYSCALL msg=audit(1710535875.290:2594): arch=c000003e syscall=1 success=yes exit=4 a0=4 a1=7fff18eb2b50 a2=4 a3=3 items=0 ppid=978 pid=1088 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=28 comm="sshd" exe="/usr/sbin/sshd" key=(null) +type=PROCTITLE msg=audit(1710535875.290:2594): proctitle=737368643A2074313238205B707269765D +type=USER_START msg=audit(1710535875.303:2595): pid=1088 uid=0 auid=1001 ses=28 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710535875.305:2596): pid=1106 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=1106 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535875.305:2597): pid=1106 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=1106 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535875.305:2598): pid=1106 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1106 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRED_ACQ msg=audit(1710535875.306:2599): pid=1106 uid=0 auid=1001 ses=28 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +``` + +#### Termination + +Logged in `/var/log/audit/audit.log`: + +``` +type=CRYPTO_KEY_USER msg=audit(1710535893.426:2600): pid=1088 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1106 suid=1001 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535893.426:2601): pid=1088 uid=0 auid=1001 ses=28 msg='op=destroy kind=session fp=? direction=both spid=1106 suid=1001 rport=38122 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_END msg=audit(1710535893.430:2602): pid=1088 uid=0 auid=1001 ses=28 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRED_DISP msg=audit(1710535893.431:2603): pid=1088 uid=0 auid=1001 ses=28 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710535893.431:2604): pid=1088 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=1088 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535893.431:2605): pid=1088 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=1088 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710535893.431:2606): pid=1088 uid=0 auid=1001 ses=28 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1088 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` + +#### Failure + +Logged in `/var/log/audit/audit.log`: + +``` +type=CRYPTO_KEY_USER msg=audit(1710536131.838:2697): pid=1779 uid=0 auid=1001 ses=32 msg='op=destroy kind=session fp=? direction=both spid=1829 suid=1001 rport=56114 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710536131.838:2698): pid=1779 uid=0 auid=1001 ses=32 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1829 suid=1001 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=USER_END msg=audit(1710536131.844:2699): pid=1779 uid=0 auid=1001 ses=32 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRED_DISP msg=audit(1710536131.844:2700): pid=1779 uid=0 auid=1001 ses=32 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="t128" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710536131.845:2701): pid=1779 uid=0 auid=1001 ses=32 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=1779 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710536131.845:2702): pid=1779 uid=0 auid=1001 ses=32 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=1779 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710536131.845:2703): pid=1779 uid=0 auid=1001 ses=32 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=1779 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` + + +### Trusted Channel Function Logs - Administrator + +This allows the identification of the administrator as the initiator and target of failed attempts to establish a trusted channel. + +#### Initiation +Logged in `/var/log/audit/audit.log` (note USER_START): + +``` +type=CRYPTO_KEY_USER msg=audit(1710532936.084:2285): pid=23657 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=23657 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710532936.085:2286): pid=23657 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=23657 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710532936.085:2287): pid=23657 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=23657 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_SESSION msg=audit(1710532936.086:2288): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-server cipher=aes128-ctr ksize=128 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha256 spid=23657 suid=74 rport=47224 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=CRYPTO_SESSION msg=audit(1710532936.087:2289): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 mac=hmac-sha2-256 pfs=diffie-hellman-group14-sha256 spid=23657 suid=74 rport=47224 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_AUTH msg=audit(1710532936.184:2290): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=? acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710532937.840:2291): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=none acct="admin" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710532937.843:2292): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=pubkey acct="admin" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=failed' +type=USER_AUTH msg=audit(1710532945.221:2293): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication grantors=pam_faillock,pam_unix acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=USER_ACCT msg=audit(1710532945.222:2294): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_faillock,pam_localuser acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710532945.222:2295): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=destroy kind=session fp=? direction=both spid=23657 suid=74 rport=47224 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_AUTH msg=audit(1710532945.224:2296): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=success acct="admin" exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=ssh res=success' +type=CRED_ACQ msg=audit(1710532945.225:2297): pid=23656 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=LOGIN msg=audit(1710532945.225:2298): pid=23656 uid=0 old-auid=4294967295 auid=1002 tty=(none) old-ses=4294967295 ses=21 res=1 +type=SYSCALL msg=audit(1710532945.225:2298): arch=c000003e syscall=1 success=yes exit=4 a0=4 a1=7fc5f26b830 a2=4 a3=3 items=0 ppid=2075 pid=23656 auid=1002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=21 comm="sshd" exe="/usr/sbin/sshd" key=(null) +type=PROCTITLE msg=audit(1710532945.225:2298): proctitle=737368643A2061646D696E205B707269765D +type=USER_START msg=audit(1710532945.257:2299): pid=23656 uid=0 auid=1002 ses=21 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710532945.258:2300): pid=23690 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=23690 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710532945.258:2301): pid=23690 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=23690 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710532945.258:2302): pid=23690 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=23690 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRED_ACQ msg=audit(1710532945.259:2303): pid=23690 uid=0 auid=1002 ses=21 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=USER_LOGIN msg=audit(1710532945.311:2304): pid=23656 uid=0 auid=1002 ses=21 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=/dev/pts/1 res=success' +type=USER_START msg=audit(1710532945.311:2305): pid=23656 uid=0 auid=1002 ses=21 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=/dev/pts/1 res=success' +type=CRYPTO_KEY_USER msg=audit(1710532945.313:2306): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=23691 suid=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` + +#### Termination + +Logged in `/var/log/audit/audit.log` (note USER_END): + +``` +type=USER_END msg=audit(1710533006.604:2307): pid=23656 uid=0 auid=1002 ses=21 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' +type=USER_LOGOUT msg=audit(1710533006.604:2308): pid=23656 uid=0 auid=1002 ses=21 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' +type=CRYPTO_KEY_USER msg=audit(1710533006.604:2309): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=23690 suid=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710533006.604:2310): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=session fp=? direction=both spid=23690 suid=1002 rport=47224 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=USER_END msg=audit(1710533006.609:2311): pid=23656 uid=0 auid=1002 ses=21 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRED_DISP msg=audit(1710533006.609:2312): pid=23656 uid=0 auid=1002 ses=21 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710533006.610:2313): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=23656 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710533006.610:2314): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=23656 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710533006.610:2315): pid=23656 uid=0 auid=1002 ses=21 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=23656 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` + +#### Failure + +Logged in `/var/log/audit/audit.log` (also USER END): + +``` +type=USER_END msg=audit(1710534850.445:2438): pid=29870 uid=0 auid=1002 ses=23 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' +type=USER_LOGOUT msg=audit(1710534850.445:2439): pid=29870 uid=0 auid=1002 ses=23 msg='op=login id=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=/dev/pts/1 res=success' +type=CRYPTO_KEY_USER msg=audit(1710534850.446:2440): pid=29870 uid=0 auid=1002 ses=23 msg='op=destroy kind=session fp=? direction=both spid=29904 suid=1002 rport=57848 laddr=192.168.1.5 lport=22 exe="/usr/sbin/sshd" hostname=? addr=172.20.6.12 terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710534850.446:2441): pid=29870 uid=0 auid=1002 ses=23 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=29904 suid=1002 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=USER_END msg=audit(1710534850.465:2442): pid=29870 uid=0 auid=1002 ses=23 msg='op=PAM:session_close grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRED_DISP msg=audit(1710534850.465:2443): pid=29870 uid=0 auid=1002 ses=23 msg='op=PAM:setcred grantors=pam_faillock,pam_unix acct="admin" exe="/usr/sbin/sshd" hostname=172.20.6.12 addr=172.20.6.12 terminal=ssh res=success' +type=CRYPTO_KEY_USER msg=audit(1710534850.467:2444): pid=29870 uid=0 auid=1002 ses=23 msg='op=destroy kind=server fp=SHA256:f7:68:dd:06:e8:30:8b:1b:3e:73:db:60:e6:34:9b:30:c5:0c:b4:b0:3d:7c:1b:20:d3:c2:84:05:4f:fa:d5:7f direction=? spid=29870 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710534850.467:2445): pid=29870 uid=0 auid=1002 ses=23 msg='op=destroy kind=server fp=SHA256:4c:2a:c1:e0:b9:fd:ce:16:c3:f0:89:16:f6:2a:70:40:ca:84:13:9c:02:58:91:4d:2a:1a:14:bc:f0:e6:f2:3c direction=? spid=29870 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +type=CRYPTO_KEY_USER msg=audit(1710534850.467:2446): pid=29870 uid=0 auid=1002 ses=23 msg='op=destroy kind=server fp=SHA256:a7:25:1c:27:28:d9:a9:cc:7f:2b:6e:c4:e0:61:28:cf:31:15:8d:c5:e5:9b:e5:c5:03:24:46:23:ab:42:04:c1 direction=? spid=29870 suid=0 exe="/usr/sbin/sshd" hostname=? addr=? terminal=? res=success' +``` diff --git a/docs/cc_fips_6.3.0_config_ntp_auth.md b/docs/cc_fips_6.3.0_config_ntp_auth.md new file mode 100644 index 0000000000..2499aeaf3f --- /dev/null +++ b/docs/cc_fips_6.3.0_config_ntp_auth.md @@ -0,0 +1,42 @@ +--- +title: NTP Client Authentication +sidebar_label: NTP Client Authentication +--- + +Support for NTP authentication allows external NTP servers to be authenticated using a `sha1` hash, allowing the SSR to verify the identity of the server being used for NTP time synchronization. + +Authentication using `md5` is not supported by FIPS mode or Common Criteria. + +To allow the NTP client to synchronize with an authenticated server the following information must be provided: + +- **Server ip-address:** This is required. +- **Key-number:** The specific number used by the server to identify the key. Range is 1-65534. The number configured on the device must match the key number expected by the server. +- **Authentication type:** `sha1` (required) +- **Shared key from the server:** 40 characters long for `sha1`. + +Example CLI configuration: + +``` +authority + name Authority128 + router Fabric128 + name Fabric128 + system + ntp + server 1.1.1.1 + ip-address 1.1.1.1 + authentication-key + key-number 1 + type sha1 + value ay4SZtX$VuooRx9XD+d+8chLS+95eJtV23+$cjTg + exit + exit + exit + exit + exit +exit +``` + +Configuration using the GUI: + +![GUI NTP Configuration](/img/ntp-client-authentication.png) \ No newline at end of file diff --git a/docs/cc_fips_6.3.0_config_password_policies.md b/docs/cc_fips_6.3.0_config_password_policies.md new file mode 100644 index 0000000000..748065dd66 --- /dev/null +++ b/docs/cc_fips_6.3.0_config_password_policies.md @@ -0,0 +1,38 @@ +--- +title: Username and Password Policies +sidebar_label: Username and Password Policies +--- + +Username and password requirements are listed below. For a list of the CLI commands and how they are used to configure and enforce requirements, please refer to [`configure authority password-policy`](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide#configure-authority-password-policy). + +### Password Requirements + +The SSR password policies have been updated to provide a more secure experience. When creating passwords and password policies for users, the following parameters are enforced. + +1. Password must contain 1 capital, 1 lower case, 1 number and 1 special character. +2. Password must be at least 9 characters. +3. Minimum password length is configurable (greater than 9). +4. When a password is changed, characters must be changed in at least eight of the positions within the password. +5. The minimum password lifetime is 24 hours/1 day. +6. There is a 60-day maximum password lifetime restriction. +7. Password reuse is prohibited for a minimum of **five** generations. +8. A temporary password for system logons is allowed, with an **immediate** change to a permanent password. +9. The default admin password **must** be changed to strong password on first use. +10. The maximum failed login attempts are configurable, with a default of 6. +11. User lock time (time the user must wait before attempting login after reaching the max failed attempts) is configurable. The default is 1800 seconds. + + +### Using the Web Interface + +The Password Policy dialog under Authority Settings can be used to adjust password settings. + +![Configure Password Policies](/img/config-password-policies.png) + +### Username Requirements + +1. Usernames may contain only lower and upper case letters, digits, underscores `_`, or dashes `-`. +2. They can end with a dollar sign `$`. +3. Dashes `-` are not allowed at the beginning of the username. +4. Fully numeric usernames and usernames beginning with `.` are not recommended. +5. Usernames may only be up to 32 characters long. +6. The `.` character is allowed within a username: `firstname.lastname`. diff --git a/docs/cc_fips_6.3.0_config_radsec.md b/docs/cc_fips_6.3.0_config_radsec.md new file mode 100644 index 0000000000..9ac107728a --- /dev/null +++ b/docs/cc_fips_6.3.0_config_radsec.md @@ -0,0 +1,252 @@ +--- +title: RADUIS over TLS +sidebar_label: RADIUS over TLS +--- + +RADIUS over TLS is designed to provide secure communication of RADIUS requests using the Transport Secure Layer (TLS) protocol. RADIUS over TLS, also known as RADSEC, redirects regular RADIUS traffic to remote RADIUS servers connected over TLS. RADSEC allows RADIUS authentication, authorization, and accounting data to be passed safely across untrusted networks. + +## RADSEC Configuration - Existing Certificate + +Use the following information to configure RADIUS over TLS (RADSEC) using an existing certificate. + +#### 1. Configure the RADSEC server. + +The following configuration example will add a radius server named `radsec` + +``` +admin@t327-dut1.cond# configure authority radius-server radsec +admin@t327-dut1.cond (radius-server[name=radsec])# port 2083 +admin@t327-dut1.cond (radius-server[name=radsec])# protocol tls +admin@t327-dut1.cond (radius-server[name=radsec])# account-creation manual +admin@t327-dut1.cond (radius-server[name=radsec])# ocsp strict +admin@t327-dut1.cond (radius-server[name=radsec])# server-name t327-dut1.openstacklocal +admin@t327-dut1.cond (radius-server[name=radsec])# top +``` + +#### 2. Configure the Trusted CA Certificate. + +The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. + +Create a certificate root named `ca_root` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root +admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +:::note +The `trusted-ca-certificate` is a list and may contain different CA roots used for different certificates. In that case, naming them all `ca_root` would not be suitable. In that case, choose a name that is meaningful to the user and CA, eg: `globalsign_root`. +::: + +#### 3. Configure a Client Certificate to be used for the RADIUS client. + +Repeat the previous step to create a client certificate named `radsec`. + +``` +admin@conductor-node-1.Conductor# config authority client-certificate radsec +admin@conductor-node-1.Conductor (client-certificate[name=radsec])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +#### 4. Configure the RADIUS server at the Authority level to use the configured client certificate. + +Associate the previously configured `radsec` client certificate to the radius server running on a specified node. + +`configure authority router cond node t327-dut1 radius client-certificate-name radsec` + +Note that the client certificate selected should match the appropriate IP/hostname of the node as seen from the RADIUS server. + +`validate` and `commit` the changes. + +#### 5. Create a RADIUS User + +Create a remotely authenticated RADIUS user. In this example we create user `test1`. + +``` +*admin@conductor-node-1.Conductor# create user test1 +Full Name: test1 +Authentication Type (remote or local): remote +Roles (space separated): admin +Enabled (true or false): true +Account 'test1' successfully created +``` + +When the user logs into the node `t327-dut1` via ssh, the authentication request is sent via RADSEC to the server `172.18.5.224` and the user is authenticated. + +## RADSEC Configuration - Generate Certificate + +Use the following examples to generate a client certificate for use on the device. + +#### 1. Generate the Signing Request + +Use the `create certificate request client` command to generate the signing request. + +:::note +Use of an IP-based `Subject Alternative Name` is not supported under Common Criteria. Use of this parameter will result in a non-conforming configuration. +::: + +``` +admin@conductor-node-1.Conductor# create certificate request client radsec +Country name (2 letter code): US +State or province name (full name): MA +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): +Common name: dut1 +Email address: +Subject Alternative Name - DNS (fully qualified domain name): +Subject Alternative Name - IP Address: +% Error: Could not create request: Subject Alternative Name (DNS or IP address) is required +admin@conductor-node-1.Conductor# create certificate request client radsec +Country name (2 letter code): US +State or province name (full name): MA +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): +Common name: dut1 +Email address: +Subject Alternative Name - DNS (fully qualified domain name): dut1 + +Request successfully generated: + +-----BEGIN CERTIFICATE REQUEST----- +MIIC1jCCAb4CAQAwTjENMAsGA1UEAwwEZHV0MTELMAkGA1UEBhMCVVMxETAPBgNV +BAcMCFdlc3Rmb3JkMRAwDgYDVQQKDAdKdW5pcGVyMQswCQYDVQQIDAJNQTCCASIw +DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ8WwHXP/z49sFsxpN5L9THO5y8N +f/as8Nn6XUyG86YyxcR5IYL5gKR5//EunoVjLAUCHgBqxwaUa3enhNEQS97N4Bcs +E7YygMkI7oAnHCioslB+x2Am/xKPRosh3s50fIN3mY409/byMGipfGcyNlMT8XbS +XF/zmGBI1/4aRbeqL5VMDPO+9DNRxXMgqBs2y48WanGvZeZTP5B/sSczlhOSxHnu +DxNYQ7+rZs9NpKzktCXOSA8nsz +. +. +. +wp4dOHuKsnf+ZsfNK4AGUYdh3qEa1/xJxyug1R3AGjItbkUzbJpR6hp7B0YYWV87 +QALMf6F0SKBDXg++ +-----END CERTIFICATE REQUEST----- +``` + +#### 2. Configure the Trusted CA Certificate + +The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. + +Create a root certificate named `ca_root` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# configure authority trusted-ca-certificate ca_root +*admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root])# content +Enter plain for content (Press CTRL-D to finish): +-----BEGIN PRIVATE KEY----- +MIIEvAIBADANBgkqhkiG9w0BAQEFAASCBKYwggSiAgEAAoIBAQCqfzVmeFPMA+Jc +53MlVF3LoYZAkqh1Dz3+HFnegcAU3/tCGSdfJad/PeF5KEQDDnF0vc9XbfS2/wJC +wHAt15TH3iarSPE3dV3L0c1tyOFaMUNLAd3nsPArR0w/1YAfr1cAN0rEUZ4WmkZK +vyFx6AsuVm5MpXR4z7U4j955sqRkWsi3I1hLtMPzuWEJA/AbpTCxb1k2xJDQWira +/NALlz6NPVRcngBt56ZDhMNmy/g2zGEcmitEqMUOS7apvRk6hZK94dfjSQe4iEpX +Sdd6vvZxdrWGV10lmDDH0SPtmGBE+34r1UNIbp/XVRh6KxiNcjFVNBwlwqATmTYh +xkXAPw1pAgMBAAECggEACZ3YNLnnvBOiAmx5larvCWvIZz7+am/cJseRmBfIbkT9 +5ooFqvu0OVyTqaJIR8XaR2PnXH6StXmntnqDpHWQTqUvlbGANIqWsyiig26zFCEu +IAXwr0TKRERzKAWT4lwmOAGi4LuQa6Ty/wdNyx9z9f6hBQi2C5Rnm9OdkE6vsAtJ +NbNcsV+bvedfLoJqG1MM3sh3LT3RAltaM0ntw3PdFiMVcQIJgGr85nVJcg4SCUkh +JKlfUE83IqkwAd1V0jn/2yopCmQBLrpyqlRu2MmwFiIS+IUcoReemNK8mlfd8hbR +. +. +. +2P6CP4iOY1EjsxNssrLJKkxXdagYeZo5X2KOIqZ8FeVli4BM0mqX96UPN2zV3dNP +eN1DF6VSLghh30ITUauYdQ++ +-----END PRIVATE KEY----- + +-----BEGIN CERTIFICATE----- +MIIDlDCCAnygAwIBAgIVAJHxzhL42q7io2PBDPR+TCeBsyQgMA0GCSqGSIb3DQEB +CwUAMFExCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1NYXNzYWNodXNldHRzMREwDwYD +VQQKDAhUZXN0IEluYzEXMBUGA1UEAwwOY2EuZXhhbXBsZS5jb20wHhcNMjQxMDIy +MTYzODI1WhcNMjUxMDIyMTYzODI1WjBRMQswCQYDVQQGEwJVUzEWMBQGA1UECAwN +TWFzc2FjaHVzZXR0czERMA8GA1UECgwIVGVzdCBJbmMxFzAVBgNVBAMMDmNhLmV4 +YW1wbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqn81ZnhT +zAPiXOdzJVRdy6GGQJKodQ89/hxZ3oHAFN/7QhknXyWnfz3heShEAw5xdL3PV230 +tv8CQpHKHjWWQzG1MM3sh3LT3RAltaM0NT6shNXE3va46f3zotWBd6PK9jC/Tpme +. +. +. +qynFiqlV0UDGgH+e8hCp41Seva5vBGYvwMVHPU80rhoAsTh1BNpM1r9xbvDQs5ui +3QyeFCt/O0A= +-----END CERTIFICATE----- +``` + +#### 3. Import the Client Certificate + +After the certificate is signed and returned, it is imported into the SSR for use by the client using the `import certificate client` command. It is validated against any trusted certificates entered using `trusted-ca-certificate`. + +The following example shows an valid self-signed certificate being imported: + +``` +admin@conductor-node-1.Conductor# import certificate client radsec +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN PRIVATE KEY----- +MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDFrn/2q4mijt14 +gjmN2agDfu6sykg4OJ2NDy4IRrBYilExRJHllAndtc04rp7EQ544Z+/J/dNJrmXK +GnHvm/Rg0UdKnbFrw5aentpx3rFefdaf8nlJLW5rFH1wxDqUhE+y5q+s+8k3ESt0 +9L/26OxTQP11t5Vh/BEkK5iVHLDBGyHntUvEnM5tFWL7+NvefhuZ6McvY7GPDR8c +bkuNHXlv9laeXQlI6IiiYum8waQDnJBGEx2wPTUguZJWP0YgxLinKiCDIINNEf+Y +dGqxf7I/h01yH4nDGR3nad30fAN+10chzjMHYhmpPVR0K9IAPbyGucK0aOriJqZ5 +91wL39G5AgMBAAECggEAE2/xDSQYyG8bv7muRxBbwNw+Q6cwKrcGZtRTRmUM+ee/ +zAReBCDmR3KU1zn0SoALkqhFn6rhl6EaSSEIivLeuJZbWC7hPyNgMACWohOvhQcC +. +. +. +WiYWxHz5Q4wUxV5uTJR3Jq5rzcHr1shyVDT+aFf9tyNdcLFfbziZ1y/EfAPkOOoH +jLD4SXCWbmRxHYVMn3yhqK4= +-----END PRIVATE KEY----- + +-----BEGIN CERTIFICATE----- +MIIDpDCCAoygAwIBAgIVAL1k460IeyrQWoU82ZVHZ2asUrTuMA0GCSqGSIb3DQEB +CwUAMFExCzAJBgNVBAYTAlVTMRYwFAYDVQQIDA1NYXNzYWNodXNldHRzMREwDwYD +VQQKDAhUZXN0IEluYzEXMBUGA1UEAwwOY2EuZXhhbXBsZS5jb20wHhcNMjQxMDIy +MTYzODI4WhcNMjUwMTIwMTYzODI4WjBVMQswCQYDVQQGEwJVUzEWMBQGA1UECAwN +TWFzc2FjaHVzZXR0czERMA8GA1UECgwIVGVzdCBJbmMxGzAZBgNVBAMMEmNsaWVu +dC5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMWu +f/ariaKO3XiCOY3ZqAN+7qzKSDg4nY0PLghGsFiKUTFEkeWUCd21zTiunsRDnjhn +78n900muZcoace+b9GDRR0qdsWvDlp6e2nHesV591p/yeUktbmsUfXDEOpSET7Lm +r6z7yTcRK3T0v/bo7FNA/XW3lWH8ESQrmJUcsMEbIee1S8Sczm0VYvv4295+G5no +xy9jsY8NHxxuS40deW/2Vp5dCUjoiKJi6bzBpAOckEYTHbA9NSC5klY/RiDEuKcq +IIMgg00R/5h0arF/sj/fL0cKofSeAgu11z1891d1sc0OMwdiGak9VHQr0gA9vIa5 +. +. +. +9cgLsL60tukLdwxH5S6gAw/MSm6ABYjdv +-----END CERTIFICATE----- + +/usr/lib/128technology/unzip/pcli/runfiles/pypi__36__cryptography_40_0_2/cryptography/x509/base.py:576: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. + return rust_x509.load_pem_x509_certificates(data) +✔ Importing... +Certificate imported successfully +Would you like to add the certificate to your configuration? [y/N]: y +Which router is this certificate for? (Select all if it applies to the entire authority) [all]: all +% Warning: +1. certificate contains the following issues: does not have the extendKeyUsage extension + + + config + authority + client-certificate radius + content + +2. certificate contains the following issues: does not have the extendKeyUsage extension + + + config + authority + client-certificate conductor-radius + content + +Certificate imported successfully +Would you like to clean up the temporary certificate and key files? [Y/n]: Y +``` + +#### 4. Configure the Device to Accept the Client Certificate + +Use the following example command to configure your device to accept the certificate. + +`configure authority router ComboWest node combo-west radius client-certificate-name radsec` + diff --git a/docs/cc_fips_6.3.0_config_webserver_certs.md b/docs/cc_fips_6.3.0_config_webserver_certs.md new file mode 100644 index 0000000000..670c4bbf41 --- /dev/null +++ b/docs/cc_fips_6.3.0_config_webserver_certs.md @@ -0,0 +1,141 @@ +--- +title: Signing and Importing Webserver Certificates +sidebar_label: Signing and Importing Webserver Certificates +--- + +Imported webserver certificates are validated against trusted certificates configured using `trusted-ca-certificate`. Use the following information to create, sign, and import the certificates to the webserver. + +### Configure a Trusted Certificate + +Certificates are pasted in as a multi-line config. + +Configure a root certificate named `ca_root` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root +admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +### Generate the Signing Request + +Use the `create certificate request webserver` command to generate the certificate signing request. + +``` +admin@t327-dut1.cond# create certificate request webserver +Country name (2 letter code): US +State or province name (full name): Massachusetts +Locality name (eg: city): Westford +Organization name (eg: company): Juniper +Organization unit (eg: engineering): engineering +Common name: www.router.com +Email address: bob@juniper.net +Subject Alternative Name - DNS (fully qualified domain name): www.router.com +Subject Alternative Name - IP Address: 1.1.1.1 + +Request successfully generated: + +-----BEGIN CERTIFICATE REQUEST----- +MIIDLDCCAhQCAQAwgZkxFzAVBgNVBAMMDnd3dy5yb3V0ZXIuY29tMQswCQYDVQQG +EwJVUzERMA8GA1UEBwwIV2VzdGZvcmQxEDAOBgNVBAoMB0p1bmlwZXIxFDASBgNV +... +. +. +. +-----END CERTIFICATE REQUEST----- +``` + +### Import the Certificate + +After the certificate is signed and returned, it is imported into the SSR for use by the webserver using the `import certificate webserver` command. It is validated against any trusted certificates entered using `trusted-ca-certificate`. + +The following example shows a valid certificate being imported: + +``` +admin@t327-dut1.cond# import certificate webserver +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN CERTIFICATE----- +MIIDHTCCAgWgAwIBAgICL/AwDQYJKoZIhvcNAQELBQAwDzENMAsGA1UEAwwEMTI4 +VDAiGA8yMDI0MDYwNjEyMzIzMVoYDzIwMjUwNjA3MTIzMjMxWjAPMQ0wCwYDVQQD +... +RaIliPRAdN85EXDiAP68ytg5D2ZzxCpmRvj4AiFI3JOc +-----END CERTIFICATE----- + +-----BEGIN PRIVATE KEY----- +MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCo4PCT4Wp89t5P +53ZJtfgKwdV/CfAi3uXAfWmdluKlXjarlgTc6rgX8wGNSRj5/AajEUU6Z68DaejR +... +KBs2Hz/E/goCvyEqNaJOix+l +-----END PRIVATE KEY----- + +admin@t327-dut1.cond# import certificate webserver +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN CERTIFICATE----- +MIIDHTCCAgWgAwIBAgICL/AwDQYJKoZIhvcNAQELBQAwDzENMAsGA1UEAwwEMTI4 +VDAiGA8yMDI0MDYwNjEyMzIzMVoYDzIwMjUwNjA3MTIzMjMxWjAPMQ0wCwYDVQQD +... +RaIliPRAdN85EXDiAP68ytg5D2ZzxCpmRvj4AiFI3JOc +-----END CERTIFICATE----- + +-----BEGIN PRIVATE KEY----- +MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCo4PCT4Wp89t5P +53ZJtfgKwdV/CfAi3uXAfWmdluKlXjarlgTc6rgX8wGNSRj5/AajEUU6Z68DaejR +... +KBs2Hz/E/goCvyEqNaJOix+l +-----END PRIVATE KEY----- + +✔ Importing... +Certificate imported successfully +Would you like to add the certificate to your configuration? [y/N]: y +Which router is this certificate for? (Select all if it applies to the entire authority) [all]: all +% Warning: +1. certificate contains the following issues: does not have the extendKeyUsage extension + + + config + authority + client-certificate webserver + content + +2. certificate contains the following issues: does not have the extendKeyUsage extension + + + config + authority + client-certificate conductor-webserver + content + +Certificate imported successfully +Would you like to clean up the temporary certificate and key files? [Y/n]: Y +``` + +The following example shows an invalid self-signed certificate being imported: + +``` +admin@t327-dut1.cond# import certificate webserver +Enter the end point certificate in PEM format (Press CTRL-D to finish): +-----BEGIN CERTIFICATE----- +MIIDHTCCAgWgAwIBAgICL/AwDQYJKoZIhvcNAQELBQAwDzENMAsGA1UEAwwEMTI4 +VDAiGA8yMDI0MDYwNjEyMzIzMVoYDzIwMjUwNjA3MTIzMjMxWjAPMQ0wCwYDVQQD +... +RaIliPRAdN85EXDiAP68ytg5D2ZzxCpmRvj4AiFI3JOc +-----END CERTIFICATE----- + +-----BEGIN PRIVATE KEY----- +MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQCo4PCT4Wp89t5P +53ZJtfgKwdV/CfAi3uXAfWmdluKlXjarlgTc6rgX8wGNSRj5/AajEUU6Z68DaejR +... +KBs2Hz/E/goCvyEqNaJOix+l +-----END PRIVATE KEY----- + +⚠ Importing... +certificate contains the following issues: certificate is self-signed +/usr/lib/128technology/unzip/pcli/runfiles/pypi__36__cryptography_40_0_2/cryptography/x509/base.py:576: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. + return rust_x509.load_pem_x509_certificates(data) +Could not validate certificate chain against a trusted anchor. +Would you like to import anyways? [y/N]: y +Certificate imported successfully +``` +The imported certificate is validated against the configured trusted root certificates and checked for insecure algorithms and invalid configurations. Bypassing or disabling these validations will result in a non-compliant configuration. + diff --git a/docs/cc_fips_6.3.0_initialize_u-iso_adv_workflow.md b/docs/cc_fips_6.3.0_initialize_u-iso_adv_workflow.md new file mode 100644 index 0000000000..ab06900c42 --- /dev/null +++ b/docs/cc_fips_6.3.0_initialize_u-iso_adv_workflow.md @@ -0,0 +1,168 @@ +--- +title: Initialize Your Device - Advanced Workflows +sidebar_label: Initialize Your Device - Advanced Workflows +--- + +While the Web Interface is the recommended method of initializing and onboarding your SSR device, there are additional methods to complete the process. + +- [PCLI Workflow](#pcli-workflow) +- [USB Initialization](#usb-initialization) +- [File on Disk](#file-on-disk) +- [API Initialization](#api-initialization) + +## PCLI Workflow + +Use the following workflows to initialize and onboard your device. + +### Conductor + +The `initialize conductor` command allows the user to overwrite the defaults provided in the Web workflow and allows for further customization of conductors. + +`initialize conductor ` + +Allowed Options: + +| name | description | +| ---- | ----------- | +| `artifactory-password` | Password portion of the artifactory credentials. | +| `artifactory-user` | User portion of the artifactory credentials. | +| `dns-servers` | Comma separated list of DNS servers. | +| `interface-name` | Interface name (matching a port in the device-map) to bind the node-ip and node-gateway. | +| `learn-from-ha-peer` | If true, the Initializer will use the HA peer to obtain setup information. | +| `node-gateway` | The IP address of the gateway of the node being provisioned. | +| `node-ip` | (Required) The IPv4 address of the node being provisioned (x.x.x.x/y) | +| `node-name` | (Required) The name of the node being provisioned. For standalone, this is `node0`. | +| `router-name` | (Required) Assign a name to the router/conductor. | +| `clustered` | (Required for HA) Whether or not this conductor is to be configured as an HA pair; set to `true` .| +| `ha-interface-name` | Interface name (matching a port in the device-map) to bind the ha-ip. | +| `ha-ip` | The IPv4 address to assign to the HA interface on this node. | +| `ha-peer-ip` | The IPv4 address of the node to be used as an HA peer. | +| `ha-peer-name` | The name of the Node to be used as an HA peer. | +| `ha-peer-username` | The user on the peer node to authenticate as. This user must have sudo privileges. Required if `learn-from-ha-peer` is true. | +| `unsafe-ha-peer-password` | The password for the user on the peer node to authenticate as. WARNING: If this field is used, the preferences file should not be world-readable to avoid leaking the peer node password. Required if `learn-from-ha-peer` is true. | + +When configuring High Availability, if any one of the following options is configured, then they all must be: + +- ha-ip +- ha-interface-name +- ha-peer-ip +- ha-peer-name +- learn-from-ha-peer +- ha-peer-username +- unsafe-ha-peer-password + +For more information on the available options and parameters, refer to the [`initialize conductor`](cli_reference.md#initialize-conductor) command. + +### Conductor-Managed Router + +The following PCLI command can be used to onboard a router to a conductor as conductor managed. + +`initialize conductor-managed router-name conductor-ip ` + +For additional information, refer to the [`initialize conductor-managed`](cli_reference.md#initialize-conductor-managed) command. + +### Mist-Managed Router + +The following PCLI command will onboard a router to the Mist inventory. + +`adopt router-name registration-code ` + +## Automated Onboarding + +Automated onboarding can be used whenever the user wants to automatically set up a device during first boot, and does not require manual input. All the onboarding configurations must be known prior to starting the process. These methods should also be used If the user wants to provide a customized interface mapping scheme for whitebox platforms. + +### Onboarding Config + +The brains behind the automated onboarding process is a json file named `onboarding-config.json`. This file contains all the configuration parameters and drives the entire onboarding process. The `onboarding-config.json` can be provided from a USB, as a file placed in `/etc/128T-hardware-bootstrapper/onboarding-config.json` on the SSR disk, or applied via API initialization. For virtual and cloud based deployments, the same mechanism is supported via cloud-init as well. + +### Conductor Onboarding Configuration + +The following JSON is an example of a valid conductor `onboarding-config.json`. + +``` +{ +"name": "MyConductor", +"mode": "conductor", +"artifactory-user": "username", +"artifactory-password": "password", +"node-name": "node0", +"node-ip": "10.73.1.10/24", +"node-gateway": "10.73.1.11", + "interface-name": "ge-0-0", + "dns-servers": [ + "8.8.8.8", + "1.1.1.1" + ] +} +``` + +### Conductor-Managed Router Onboarding Configuration + +The following is an example onboarding config that can be used to onboard a conductor-managed router using API initialization or a file placed on disk. +``` +{ +“mode”: “conductor-managed”, +“conductor-hosts”: [“1.2.3.4”] +} +``` + +If no router name is supplied in the onboarding config, the default name is chosen in this order: + +1. Serial Number (via DMI table) +2. Hostname +3. UUID (via DMI table) + +### Mist-Managed Router Onboarding Configuration + +The following is an example onboarding config that can be used to onboard a Mist-managed router using API initialization or a file placed on disk. +``` +{ +“mode”: “mist-managed”, +“name”: “mist-router”, +“registration-code”: "” +} +``` + +If no router name is supplied in the onboarding config, the default name is chosen in this order: + +1. Serial Number (via DMI table) +2. Hostname +3. UUID (via DMI table) + +:::note +If no onboarding configuration file is provided, it is assumed that the device is an unmanaged router, and an onboarding configuration will be provided later. +::: + +### USB Initialization + +When the device boots for the first time it looks for a connected USB device named **BOOTSTRAP**. On this device, you can provide an onboarding config, devicemap, and/or pre-post boot scriptlets in the root directory. These files must be called: + +- onboarding-config.json +- devicemap.json +- pre-bootstrap +- post-bootstrap + +Scriptlets are passed in the device identifier, which is typically the device serial number. The order of operations is: + +1. Pre-bootstrap +2. Normal bootstrapping operation +3. Post-bootstrap +4. Onboarding + +### File on Disk + +If no onboarding config was found on a USB device, the initialization process looks for a config file placed on the device; this is a common workflow for virtual devices. You can also provide a customized devicemap in the onboarding config at this time. These files are located at: + +- `/etc/128T-hardware-bootstrapper/onboarding-config.json` +- `/etc/128T-hardware-bootstrapper/pre-bootstrap` +- `/etc/128T-hardware-bootstrapper/post-bootstrap` + +If you wish to not onboard the device and only supply a devicemap, the device is onboarded as an unmanaged router. + +### API Initialization + +If an `onboarding-config.json` was not provided during the initial bootstrapping of the device, the you can choose to initialize the device by supplying an onboarding config path directly from the API. The POST endpoint is `/api/bootstrap/onboarding` with a json body containing the contents of the onboarding-config file. To apply an onboarding configuration, place the contents of the desired onboarding config file in `onboarding-cfg.json` and run the following command. Alternatively, you can include the JSON contents directly in the curl request. + +``` +curl -X POST -H "Content-Type: application/json" -d @onboard-cfg.json http://localhost:31517/api/bootstrap/onboarding +``` diff --git a/docs/cc_fips_6.3.0_initialize_u-iso_device.md b/docs/cc_fips_6.3.0_initialize_u-iso_device.md new file mode 100644 index 0000000000..407863cbbb --- /dev/null +++ b/docs/cc_fips_6.3.0_initialize_u-iso_device.md @@ -0,0 +1,67 @@ +--- +title: Initialize Your Device - Web Workflow +sidebar_label: Initialize Your Device - Web Workflow +--- + +This is the part where configuring your device gets really easy! Use the GUI to initialize the device as a [Conductor](#initialize-a-conductor), or a [Conductor-managed Router](#initialize-a-conductor-managed-router). Use a browser to navigate to your conductor and begin the initialization. + +![U-ISO Device Selection GUI](/img/u-iso8_launch_gui.png) + +## Initialize a Conductor + +Use the following process to initialize your device as a Conductor. + +1. Select **SSR Conductor** under SSR Managed. + + ![SSR Conductor](/img/u-iso8a_initialize_conductor.png) + +2. To initialize a standalone conductor, select **STANDALONE**. To initialize the first conductor of an HA pair, select **HA NODE 0**. Select the address type (DHCP or STATIC). + +:::note +In an HA configuration, **HA NODE 0** must always be configured before HA NODE 1. Configuring Node 1 first prevents Node 0 from starting. +::: + +Enter the following information: + + - Conductor name + - Node IP Address (Static) + - Node Gateway (Static) + - Interface Name (Static) + - DNS Server address (Optional) + - Artifactory username and password (if available) + + ![Conductor Association](/img/u-iso9_define_conductor.png) + +3. Click **ASSOCIATE** + +4. The device reboots and comes online as a Conductor. + +5. To initialize the second conductor of an HA Pair, select **HA NODE 1**, and select the address type (DHCP or STATIC). Enter the following information: + + - Conductor name + - Node IP Address (Static) + - Node Gateway (Static) + - Interface Name (Static) + - DNS Server address (Optional) + - Artifactory username and password (if available) + + ![HA Conductor Association](/img/u-iso9a_ha_conductor.png) + +5. Click **ASSOCIATE** when you have completed the required information. The device reboots and comes online as the second Conductor. + +## Initialize a Conductor-Managed Router + +To initialize your device as a Conductor-managed router, and incorporate `ssh-only` and Strict Hostkey Checking, use the following procedure. + +1. From the SSR initialization page, select the **Or, login locally** link at the bottom of the page. + + ![SSR Local Login](/img/u-iso_com-crit_6.3.0_local-login.png) + +2. Enter the your login credentials. + +3. Use the [**Quickstart Procedure**](cc_fips_6.3.0_otp_router_install.md) and file to configure `ssh-only` and Strict Hostkey checking on the router. + + + + + diff --git a/docs/cc_fips_6.3.0_install_univ_iso.md b/docs/cc_fips_6.3.0_install_univ_iso.md new file mode 100644 index 0000000000..4dbc9f0be5 --- /dev/null +++ b/docs/cc_fips_6.3.0_install_univ_iso.md @@ -0,0 +1,44 @@ +--- +title: SSR Installation +sidebar_label: SSR Installation +--- + +Before beginning, ensure that you have an appropriate rollover cable available to connect to your computer. The SSR has a console port (CONSOLE) with an RJ-45 connector. Use the console port to connect the SSR to a management console or to a console server. The baud rate of the console port is 115200 bps. + +1. Connect an RJ45 rollover cable to the console port on the SSR device. +2. Connect the other end of the cable to your computer. +3. Insert your bootable USB with the new ISO image into the USB port of the SSR device. +4. Connect the power input to the SSR device. +5. Power on the SSR. +6. At the instruction in the terminal window: `Press ESC for boot menu`, do so. +7. From the boot menu, enter the boot device number corresponding to your USB, and press Enter. +8. From the boot menu select **TAB** or **DEL** to enter Setup. + + ![Boot menu](/img/u-iso1_install_presstab_setup.png) + +9. Select the Boot image on the USB device you wish to install. In the example below, there is only one image downloaded. + + ![Choose Image](/img/u-iso2_choose_image.png) + +10. At the Install menu, select Serial or VGA. + + ![Install Type](/img/u-iso3_choose_install_type.png) + +11. To enable FIPS Enforcement for SSR software, select Install Option 1, and select **Enter**. This ensures that key generation is done with FIPS approved algorithms and continuous monitoring tests in place. + + :::important + FIPS mode is required for Common Criteria compliance. Failure to configure FIPS mode, or the use of any other cryptographic engine nullifies compliance. + ::: + + The download and installation begins. + + ![Unpacker](/img/u-iso5_begin_install.png) + +12. When the installation completes, you will be prompted to reboot. A reboot is necessary to start the services and launch the GUI. Device intialization and management is performed from the GUI. + + ![Unpacker Successful](/img/u-iso6_unpacker_complete.png) + + + ![Final Install Screen](/img/u-iso7_serial_install.png) + +**Great job! Your software has installed, now let's go [initialize your device!](cc_fips_6.3.0_initialize_u-iso_device.md)** \ No newline at end of file diff --git a/docs/cc_fips_6.3.0_intro.md b/docs/cc_fips_6.3.0_intro.md new file mode 100644 index 0000000000..cf7980aae1 --- /dev/null +++ b/docs/cc_fips_6.3.0_intro.md @@ -0,0 +1,68 @@ +--- +title: Introduction - SSR Common Criteria Installation and Configuration +sidebar_label: Introduction - SSR Common Criteria Installation and Configuration +--- + +The focus of this document is to provide the required configuration steps to install and operate the SSR in a manner consistent with the requirements of Common Criteria and FIPS. + +Common Criteria for information technology is an international agreement signed by several countries that permits the evaluation of security products against a common set of standards. In the Common Criteria Recognition Arrangement (CCRA) the participants agree to mutually recognize evaluations of products performed in other countries. All evaluations are performed using a common methodology for information technology security evaluation. + +For more information on Common Criteria, see https://www.commoncriteriaportal.org/. + +## Introduction to Session Smart Networking Common Critieria Compliance + +The Session Smart Networking Platform is the first 100% software-defined, session-based distributed IP routing and network services platform designed from the ground-up with an application and service-centric context. The platform consists of two primary components: the Session Smart Router (SSR) and the Conductor. Together, they form a single logical control plane that is highly distributed, and a data plane that is truly session-aware. + +The family of Juniper SSR appliances consists of the Session Smart Networking software executing on Juniper branded platforms. The compliant appliances include the following: + +- SSR 120 +- SSR 130 +- SSR 1200 +- SSR 1300 +- SSR 1400 +- SSR 1500 + +The software is Juniper SSR software v6.3.0-R1. The software is deployed in an ISO package file, which includes Enterprise Linux 7.9 with kernel version 4.18.0. + +The SSR security guidance documentation (this guide, the SSR Common Criteria Installation and User Guide V1.0) is delivered to all users. To achieve Common Criteria compliance, the SSR must at all times be deployed and operated in accordance with this document. The SSR Common Criteria Installation and User Guide V1.0 is a Common Criteria Guidance Supplement which extends the existing manuals and other product documentation. The SSR Common Criteria Installation and User Guide applies to the above listed hardware. + +SSR devices are provisioned and configured by the user as a Session Smart Router (SSR) or into a Session Smart Conductor (Conductor). The Router implements the data plane and control plane functions and performs most functions. The Conductor implements a centralized management and policy engine allowing provisioning and management of several Routers. A Conductor also acts as an information aggregation repository. + +The conductor manages the associated routers. To do this, the Administrator establishes a local or remote management connection to the Conductor. + +Each SSR can be administered individually; the administrator connects locally from console or remotely from a remote management station and issues commands through the Command Line Interface (CLI). For local administration, the administrator authenticates with a username and a password or via public-key authentication using cryptographic keys stored in the local file system. The Administrator’s credentials (private key) used to access the system via SSH must be protected on any other platform on which they reside. + +The SSR implements all the security functions of a network device, as well as a stateful traffic filtering firewall to guard access to the protected network. Routers are deployed in various data centers, branches, and other facilities to protect the network connection. These Routers are associated to a Conductor for configuration management, information aggregation, and life-cycle management. + +### Network Interface Compliance for Common Criteria + +Each SSR has multiple network interfaces. + +- Conductor interfaces always operate as Non-Forwarding. +- Router interfaces may operate as Forwarding or Non-Forwarding. + +A non-forwarding interface is always serviced by the Linux network stack. It is used for management purposes such as configuration, command, and control only. Forwarding interfaces carry SVR traffic between external networks. + +Although the SSR software permits forwarding interfaces to also be configured for management access, these *management over forwarding* operations are non-compliant for Common Criteria deployments. SSH management connections to the SSR must only be configured for non-forwarding interfaces. Refer to the Appendix for an example where management interfaces are correctly configures as `forwarding = false`. + +Wnen running the SSR software version 6.3.0 installed as directed in this guide and `strict hostkey checking` enabled (set to `yes`), a dedicated out of band network mamagement interface is no longer required. + +### Additional Software Details + +SSR provides SSH for Remote Administration on Port 22, using OpenSSH v7.4 and OpenSSL v1.0.2k. These versions are certified for FIPS 140-2 compliance. + +All implementations of cryptographic algorithms are certified under the Cryptographic Algorithm Validation Program (CAVP) only when used on the Juniper hardware platforms listed in this document. + +All software used as part of the SSR is implemented to minimize the attack surface and only allow the minimum number of connections with outside users and products. + +Administration of the SSR can be performed using the following methods: +- CLI or the +- WebGUI +- REST API +- GraphQL PSI + +These are considered Common Criteria-certified when a valid CA certificate and webserver certificate is configured in the `trusted ca-certificate` store, and a valid signed webserver server certificate is imported. For more information, see [Signing and Importing Webserver Certificates](cc_fips_6.3.0_access_mgmt.md#signing-and-importing-webserver-certificates). + +The SSR implements a number of security mechanisms to protect itself and any critical data, and to ensure that attempts to tamper with the SSR or data are detected. + + diff --git a/docs/cc_fips_6.3.0_intro_install_univ-iso.md b/docs/cc_fips_6.3.0_intro_install_univ-iso.md new file mode 100644 index 0000000000..3571d8622a --- /dev/null +++ b/docs/cc_fips_6.3.0_intro_install_univ-iso.md @@ -0,0 +1,41 @@ +--- +title: SSR Image-Based Installation Overview +sidebar_label: SSR Image-Based Installation Overview +--- + +Beginning with version 6.3.0, the SSR uses a single image-based ISO with a significantly simplified installation process. After the SSR installation completes, the GUI provides clear choices and processes for the Conductor and Conductor-managed router configuration options. + +#### Version History + +| Release | Modification | +| ------- | ------------ | +| 6.0.0 | Image-based ISO installation process implemented for Mist-managed networks. | +| 6.3.0 | Image-based ISO updated, migrating to a single ISO installation format for Conductor, Conductor-managed, and Mist-managed deployments. | + +The installation workflow for Common Criteria compliance consists of the following steps: + +- [Download](#download) +- [Create a bootable USB](intro_creating_bootable_usb.md) +- [Software Installation](cc_fips_6.3.0_install_univ_iso.md) +- [Device Initialization](cc_fips_6.3.0_initialize_u-iso_device.md) +- [Quickstart Procedure](cc_fips_6.3.0_quickstart_otp.md) + +## Download + +The image-based ISOs are available for download at the following location: + + +https://software.128technology.com/artifactory/list/generic-128t-install-images-release-local/ + +Files available for download are: + +- `*.iso` - This file is used for installing/staging bare metal platforms. **Use this file to perform an initial image-based install.** +- `*.tar` - This file is used by Mist or the SSR conductor for image-based upgrades, and is accessed directly by the system during the upgrade. User download is not necessary or advised. + +You will be prompted for your username and token to access the web page listing the software versions. Download is done directly from the page. + +### Create a Bootable USB + +Use the instructions for [Creating a Bootable USB](intro_creating_bootable_usb.md) to create a bootable USB drive containing the universal ISO image. + +Once you have the USB, let's go [Install the SSR software!](cc_fips_6.3.0_install_univ_iso.md) \ No newline at end of file diff --git a/docs/cc_fips_6.3.0_intro_installation.md b/docs/cc_fips_6.3.0_intro_installation.md new file mode 100644 index 0000000000..6c290acc9d --- /dev/null +++ b/docs/cc_fips_6.3.0_intro_installation.md @@ -0,0 +1,32 @@ +--- +title: SSR Secure Installation +sidebar_label: Secure Installation Overview +--- + +Welcome to Session Smart Routing - the first software-based routing solution designed to be both session-oriented and service-centric through the application of Secure Vector Routing. The purpose of this guide is to provide an overview and installation walkthrough for the SSR Router and Conductor products into a Linux operating system environment. This product suite is collectively known as SSR Software. + +## Before You Begin +Before you begin the installation and configuration of an SSR Networking Platform, you must: +- Be familiar with Linux fundamentals, basic network addressing, and IP networking terminology. +- Be a system administrator to perform the installation and configuration. + +:::note +The examples listed in this guide generally run commands as a non-root user, except as noted, and prepend commands that must be run as a superuser with sudo. **Logging in as `root` over SSH is not permitted.** +::: + +### SSR Software Version + +The SSR devices ship with an older version of SSR software that is not Common Criteria and FIPS compliant. It is required that you install SSR 6.3.0-r1 software on the device to configure and run Common Criteria and FIPS compliant instances. + +:::note +The installation process is the only way to achieve compliant software. The upgrade process may only be used for subsequent updates after the initial installation of the SSR 6.3.0-r1 software. +::: + +Access to the SSR Software packages available for download from our software repositories is authenticated using the username and token provided to you. + +## Installation Process Overview + +Installation is done using the SSR Universal ISO, typically from a bootable image on a USB or copied to disk. +Please follow the instructions starting with the [SSR Image-Based Installation Overview](cc_fips_6.3.0_intro_install_univ-iso.md). + + diff --git a/docs/cc_fips_otp_router_install.md b/docs/cc_fips_6.3.0_otp_router_install.md similarity index 87% rename from docs/cc_fips_otp_router_install.md rename to docs/cc_fips_6.3.0_otp_router_install.md index 15260ed651..fd9e887988 100644 --- a/docs/cc_fips_otp_router_install.md +++ b/docs/cc_fips_6.3.0_otp_router_install.md @@ -1,16 +1,14 @@ --- -title: OTP Router Install Process -sidbar_label: OTP Router Install Process +title: Router Install Process +sidbar_label: Router Install Process --- -The simplest deployment of the One Touch Provisioning (OTP) solution is highly automated and leverages just two components, the Conductor and at least one SSR. For many customers, the SSR platform is ordered and delivered as a pre-integrated, off-the-shelf solution through the Juniper SSR partner network. +The simplest deployment of the One Touch Provisioning (OTP) solution leverages just two components, the Conductor and at least one SSR. For many customers, the SSR platform is ordered and delivered as a pre-integrated, off-the-shelf solution through the Juniper SSR partner network. The OTP installation process produces a Router installed with SSR software set to factory defaults. Upon completing the OTP installation process, the default behavior is to provision the device with a DHCP client on the first ethernet port and DHCP server listening on all other ports. The user connects to the SSR via ethernet cable and uses the QuickStart file generated by the Conductor to finalize the SSR configuration. After performing the QuickStart operation, the SSR has connectivity to the conductor and downloads the latest configuration (if necessary) to begin operation. This process assumes you have already created a bootable device using a USB. Instructions for downloading and creating a bootable device are available in [Downloading an SSR ISO](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_downloading_iso) and [Creating a Bootable USB](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_creating_bootable_usb). -Router installation can be performed using **either** the OTP process, or the [Interactive Installation](cc_fips_router_install.md). You do not need to perform both. **The steps in this section describes the OTP process.** - :::note The Conductor installation must be completed before installing a Session Smart Router or routers using the ISO. The same ISO is used for all installations. ::: @@ -25,10 +23,6 @@ Basic configuration parameters are encoded within an encrypted file. For each no Before beginning the Router installation, you must have a Conductor operationally deployed and reachable by the router. -:::important -For Common Criteria compliance, a dedicated, out-of-band network must be used to provide the management connection security between Conductor and Router instances. SSR software does not currently provide any evaluated security assurances for this link. This dedicated network interface must be privately routed, and must not be exposed publicly. -::: - ## Installation ### Connect the SSR to a Management Console @@ -80,7 +74,7 @@ Upon boot, the following screen is displayed. The default selection is booting t 1. Use the Up/Down keys to select the `OTP Install 128T Routing Software Serial Console` option. This is a supported installation option for Common Criteria. It uses `/dev/ttyS0` 115200 baud as the serial console for interacting with the installer. - ![Serial Install Selection](/img/cc_fips_otp_serial.png) + ![Serial Install Selection](/img/cc_fips_otp_serial-6.3.0.png) Selecting the wrong type of console may result in garbled characters being displayed. If allowed to continue it will result in an incorrect installation. If the wrong console is selected, reboot the target system and select the correct line for the target hardware. @@ -88,7 +82,7 @@ Upon boot, the following screen is displayed. The default selection is booting t 2. Press the TAB key to edit the configuration. - To enable FIPS Enforcement for SSR software version 6.2.5-5-sts, add the `fips=1` kernel option to the kernel command line during system installation as shown in the steps below. This ensures that key generation is done with FIPS approved algorithms and continuous monitoring tests in place. + To enable FIPS Enforcement for SSR software version 6.3.0-107r1, add the `fips=1` kernel option to the kernel command line during system installation as shown in the steps below. This ensures that key generation is done with FIPS approved algorithms and continuous monitoring tests in place. :::important FIPS mode is required for Common Criteria compliance. Failure to configure FIPS mode, or the use of any other cryptographic engine nullifies compliance. @@ -96,7 +90,7 @@ Upon boot, the following screen is displayed. The default selection is booting t 3. Add `fips=1` to the end of the `vmlinuz` parameters. - ![FIPS Parameter](/img/cc_fips_otp_serial2.png) + ![FIPS Parameter](/img/cc_fips_otp_serial2-6.3.0.png) 4. Press **Enter** to start the install. @@ -108,11 +102,31 @@ When you modify the GRUB kernel behavior by editing the GRUB menu at boot time, This installation process is an automated workflow which does not require user interaction after selecting and initiating the OTP menu option. The system will power off after installation. -### Enable Strict Host Key Checking +### Enable Secure Communication + +In order to secure communication between the Conductor and the managed routers in a distributed environment, it is essential that you enable both strict hostkey checking and asset connection resiliency. These features may be enabled from either the command line or the web interface. + +- [Asset Connection Resiliency](#enable-asset-connection-resiliency) +- [Strict Host Key Checking](#enable-strict-host-key-checking) + +#### Enable Asset Connection Resiliency + +Asset Connection Resiliency is set at the Authority level to ensure that all communication between the conductor and the managed routers is secure. By configuring [`asset-connection-resiliency`](config_command_guide.md#configure-authority-asset-connection-resiliency) as `true`, SSH tunnels are created for asset connections between a managed Router and the Conductor. Enabling `ssh-only` mode forces the asset connections to use the SSH tunnels. + +``` +config authority asset-connection-resiliency enabled true +config authority asset-connection-resiliency ssh-only true +``` + +#### Enable Strict Host Key Checking Enabling strict `host-key-checking` provides secure communication between the conductor and a router. Similar to SSH, there are two `host-key-checking` options; `yes` which requires the host key to be provisioned manually, or `accept-new` which accepts the key on first connection. +When configuring a network that is common criteria compliant, the `host-key-checking` parameter must be set to `yes` at all times, and the host keys provisioned manually on each router. + +During initial provisioning in a protected environment, the `accept-new` option may be used to expedite device set up. Once the host keys are accepted, then `host-key-checking` must be changed to `yes` before any traffic is sent over the network. + There are two configuration parameters where `host-key-checking` can be set: - **[`inter-router host-key-checking`](config_command_guide.md#configure-authority-router-node-ssh-settings-inter-router-host-key-checking)** controls host key verification between a router and the conductor. When set to `yes`, strict host key checking is enabled between the router and the conductor. However, the host keys must be manually provisioned on each router. @@ -229,13 +243,13 @@ Fri 2024-03-01 16:23:37 UTC =========== =========== ========= ======== ====================== ===================== Router Node Version Status Build Date Package =========== =========== ========= ======== ====================== ===================== - 128t-east 128t-east 6.2.5 r2 2024-06-06T23:56:25Z 128T-6.2.5-5r2.el + 128t-east 128t-east 6.3.0 r1 2024-06-06T23:56:25Z 128T-6.3.0-107r1.el 7 (package based) Completed in 0.05 seconds admin@conductor.conductor# ``` - It should report Version 6.2.5 and Status r2. + It should report Version 6.3.0 and Status r1. 3. Type `shell` to suspend the CLI and enter the Linux shell. 4. Execute the command `sudo systemctl status 128T` and verify the service is listed as `active (running)`. diff --git a/docs/cc_fips_6.3.0_quickstart_otp.md b/docs/cc_fips_6.3.0_quickstart_otp.md new file mode 100644 index 0000000000..154e8950af --- /dev/null +++ b/docs/cc_fips_6.3.0_quickstart_otp.md @@ -0,0 +1,239 @@ +--- +title: QuickStart the SSR Router +sidebar_label: QuickStart the SSR +--- + +:::important +Before beginning the Quickstart process, verify that you have enabled [Strict Host Key Checking](cc_fips_6.3.0_otp_router_install.md#enable-strict-host-key-checking) and provisioned the host keys on the router. Failure to enable strict host key checking will invalidate the security of the communications between the conductor and routers. +::: + +Use this procedure to set up a typical standalone branch router leveraging the QuickStart capabilities of the SSR Networking Platform. + +When a router configuration has been added to the conductor but the device has not yet connected, QuickStart instructions will be displayed in place of device-specific information. + +1. On the Conductor, use the web interface to access **Routers** -> **Router Name** -> **QUICKSTART LINK** to begin the QuickStart process. + +![QuickStart Generate QuickStart Link](/img/intro_ztp_quickstart_server_2.png) + +2. Confirm the basic information about the target router, the *router name*, *node name*, and *asset ID*. The *device host address* is the IP address that is assigned to the SSR router during the staging process. By default this is set to `192.168.0.128`. + +3. Enter the password that will be used to encrypt the contents of the QuickStart file. This password will be required when applying the file to the target router. + +![QuickStart Link Generation](/img/intro_ztp_quickstart_server_3.png) + +4. Copy the auto generated “Password” (this can be set to a different value). +5. Follow step 1 in the Quickstart dialog to download the QuickStart file locally by selecting the “Click Here” link. +6. Connect the computer that contains the QuickStart file to any ethernet port except for port 1 on the router. Ensure DHCP is enabled on the computer connected to the router. +7. Follow step 2 in the Quickstart dialog: Click the link to start the QuickStart URL process. +8. Login locally to the new router with the default username `admin` and password `128Tadmin`. +9. Drag and drop the QuickStart file and click **Proceed**. + +![QuickStart file upload](/img/intro_ztp_quickstart_client_1.png) + +10. Paste the “Password” previously copied to unencrypt the QuickStart file and click “Continue” + +![QuickStart Password Field](/img/intro_ztp_quickstart_client_2.png) + +11. Click **Proceed** to start this process. Optionally, select the “Show Details” slider to view the full configuration. + +![QuickStart File Accepted](/img/intro_ztp_quickstart_client_3.png) + +After a few minutes, this process completes and your SSR Router is fully configured. + +![QuickStart Working](/img/intro_ztp_quickstart_client_4.png) + +After a few more minutes, the router QuickStart webpage will show a message that the router was successfully configured. + +![QuickStart Success](/img/intro_ztp_quickstart_client_5.png) + +### Enable Strict Host Key Checking + +Enabling strict `host-key-checking` provides secure communication between the conductor and a router. +Similar to SSH, there are two `host-key-checking` options; `yes` which requires the host key to be provisioned manually, or `accept-new` which accepts the key on first connection. + +There are two configuration parameters where `host-key-checking` can be set: + +- **`inter-router host-key-checking`** controls host key verification between a router and the conductor. When set to `yes`, strict host key checking is enabled between the router and the conductor. However, the host keys must be manually provisioned on each router. + + ``` + config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking yes + config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-router host-key-checking yes + ``` + +- **`inter-node host-key-checking`** controls host key verification between redundant HA nodes. When set to `yes`, strict host key checking is enabled between the router and the conductor **between each node** of an HA router. However, the host keys must be manually provisioned on each router. + +``` +config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-node host-key-checking yes +config authority router RTR_EAST_COMBO node combo-east-2 ssh-settings inter-node host-key-checking yes +``` + +To save the work of manually provisioning the host key on the router, set the `accept-new` parameter. This automatically loads the host key on first connection. + +``` +config authority router RTR_EAST_COMBO node combo-east-1 ssh-settings inter-router host-key-checking accept-new +``` + +Use the `show system connectivity known-hosts` to view the accepted host keys for the current node. + +#### Manual Provisioning of the Conductor Key + +If a router is configured for strict `inter-router host-key-checking` (set to `yes`), but **does not** have `accept-new` configured, it will be necessary to manually provision the conductor key **prior** to onboarding the router to the conductor. This will require the administrator to retrieve the host key of each node of the conductor and configure this in the router. + +On the conductor, identify the `key` for each node using the command `show system connectivity host-keys node all`. + +From the router PCLI, provision each conductor key using the following command: +`create system connectivity known-hosts node ssh-rsa ` + +- `` is the router node. The key should be added on each router node in an HA pair. +- `` is the conductor address. This should be added for each conductor address of an HA conductor pair. +- `` is the `Key` retrieved from the previous step. +- `` is an option that can be used to identify the key; for example `Conductor1`. + +The following example manually configures the key to the conductor node `192.168.1.13`: + +`create system connectivity known-hosts router RTR_EAST_COMBO node combo-east-1 [192.168.1.13]:930 ssh-rsa ` + +### Root Access +To permit root access to the SSR system, ensure that there is at least one user configured on each system with super user (sudo) privileges. Failure to do so may result in the loss of management connectivity to the router. +**Logging in as `root` over SSH is not permitted.** + +Prerequisites for installation and upgrades now include configuring a super user in `/etc/sudoers` that is allowed to execute Linux shell commands as root (sudo privileges). +During an upgrade, if the existing version allows SSH Root login, it will be disabled. When a system is installed using the OTP ISO, a "t128" user is automatically configured with sudo privileges. + +1. Login using the admin credentials. +2. Enter the Linux shell: Type `shell` to suspend the CLI and enter the Linux shell. +3. Type `su` and enter the default root password. +4. Use the following command to grant sudo privilege to the `admin` user account: + `/usr/sbin/visudo` +5. Add an entry for admin as follows: + ``` + admin ALL=(ALL) ALL + ``` +6. Save the file and exit from `visudo`. +7. Type `exit` to leave the `su` prompt. + +### Change the Default Passwords + +The following user accounts and passwords are created during the ISO installation process: + +| Username | Password | +| -------- | ---------- | +| root | 128tRoutes | +| t128 | 128tRoutes | + +Change these passwords immediately. Use the `passwd` command from the Linux shell to individually set the password for each username. + +``` +[admin@localhost ~]$ sudo passwd t128 +Changing password for user t128 +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ sudo passwd root +Changing password for user root. +New password: +Retype new password: +passwd: all authentication tokens updated successfully. +[admin@localhost ~]$ +``` + +:::note +The root account will not be used for day-to-day access, but the root account password should be stored securely off-box so that it can be used for admin account recovery if required. +::: + +### Software Compliance Validation + +After installing the SSR Software, it is important to verify that the installation successfully completed and that the system is running in the FIPS enforcememt mode required for Common Criteria compliance. After starting the SSR router or conductor, the login screen appears on the console. Alternatively you may `ssh` to the SSR management IP address using the admin account. + +1. Login using the admin credentials. +2. Use `show system version` to verify the correct software release is running: + +``` +Last login: Thu Dec 14 13:28:36 UTC 2023 on pts/0 +admin@conductor.conductor# show system version +Fri 2024-03-01 16:23:37 UTC +✔ Retrieving system version 1/1 targets complete... + +=========== =========== ========= ======== ====================== ===================== + Router Node Version Status Build Date Package +=========== =========== ========= ======== ====================== ===================== + 128t-east 128t-east 6.3.0 r1 2024-06-06T23:56:25Z 128T-6.3.0-107.el + 7 (package based) + +Completed in 0.05 seconds +admin@conductor.conductor# +``` + It should report Version 6.3.0 and Status r1. + +3. Type `shell` to suspend the CLI and enter the Linux shell. +4. Execute the command `sudo systemctl status 128T` and verify the service is listed as `active (running)`. + +``` +[root@conductor-test admin]# sudo systemctl status 128T -l + 128T.service - 128T service + Loaded: loaded (usr/lib/systemd/system/128T.service; enabled; vendor preset: disabled) + Active: active (running) since Mon 2023-7-31 18:04:29 UTC; 50min ago + Main PID: 23317 (processManager) +``` + +5. Perform the following steps to verify the software integrity and protect against future tampering: + +- Execute the self-test scan `sudo systemctl start 128T-rpm-verify` + + The self-test scan is intiated and takes approximately two minutes to complete. Upon completion, run: + + `systemctl status 128T-rpm-verify` + + The scan validates all executable files on the system against the `sha256` digest hash recorded in the signed RPMs from which they were installed. This ensures that no files have been replaced or tampered with. + +- Run `systemctl status 128T-rpm-verify` to confirm that the service shows: + + `PASS: All RPM file digests verified` + +- If the result displays the following: + + `FAIL: RPM file digest mismatch detected` + + The failure must be resolved before continuing to ensure compliance. The full path to each file having a self-check digest mismatch is reported as part of the `status` output. + +- After the self-test scan test has succeed, enable the automatic self-test by executing the `enable` command in the linux shell: + + `sudo systemctl enable 128T-rpm-verify` + + The self-test is enabled on every subsequent reboot. If the self-test fails, the 128T service will not start. + +6. Perform the following steps to verify that FIPS security enforcment mode is enabled in the OS: + `openssl md5 /dev/null` + Expected result: `digital envelope routines … Disabled for fips` + +7. Run the following command to verify that FIPS security enforcing mode is enabled in the kernel: + `cat /proc/sys/crypto/fips_enabled` + Expected result: `1` + +8. Type `exit` to leave the Linux shell and return to the CLI. +9. Type `quit` to log out from CLI. + +You have now completed security validation of the installation. + +### CLI Access Post Install + +Use the following procedure to access the CLI at any time after installation. + +1. Open a terminal window and SSH to the SSR's IP address. +2. Use your login credentials to log in to the SSR + + - If using an account other than admin, type `pcli` to start the SSR CLI. + + - Type `shell` to suspend the CLI and enter the Linux shell. + +To terminate an active session: + +- Type `exit` to return from the Linux shell to the CLI. + +- Type `quit` to log out from CLI. + +- If using an account other than admin, type `exit` to end the login session. + +Common Criteria certification does not require any restrictions on executing commands. See the [Configuration Command Reference Guide](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_command_guide) for command information and usage. + +Congratulations, you have setup your SSR router. diff --git a/docs/cc_fips_6.3.0_rest_graphql_apis.md b/docs/cc_fips_6.3.0_rest_graphql_apis.md new file mode 100644 index 0000000000..7349b29425 --- /dev/null +++ b/docs/cc_fips_6.3.0_rest_graphql_apis.md @@ -0,0 +1,214 @@ +--- +title: REST and GraphQL APIs +sidebar_label: REST and GraphQL APIs +--- + +The SSR provides Application Programming Interfaces (APIs) that can be used to interact with the SSR from an external application. The two primary interfaces are REST and GraphQL. + +A REST API (Representational State Transfer Application Programming Interface) is a set of rules and conventions for building and interacting with web services. It uses standard HTTP methods such as GET, POST, PUT, DELETE, etc., to perform operations on resources, which are typically represented in formats like JSON or XML. + +The GraphQL API is an alternative to REST and allows clients to use queries to request exactly the data they need. The server then populates the items in the query. + +:::note +The examples shown in this document use the `curl` command-line application; any HTTP client can be used. +::: + +## Authentication Tokens + +The REST and GraphQL APIs are authorized and authenticated securely using authorization tokens. Tokens are granted using the username and password of a suitably priviliged user, and passed to each API call. The SSR uses the token to determine authorization for each API call. The RBAC privileges of the user determine access to the resources being accessed by the API. + +The `/api/v1/login` REST API is used to generate these tokens. For example: +`curl --request POST -k --url 'https://192.168.0.1/api/v1/login' -H "Content-Type: application/json" -d '{ "username": "admin", "password":"128Tadmin"}'` + +In this example, the address of the SSR is `192.168.0.1` and the username is `admin` with password `128Tadmin`. Additionally the `-H "Content-Type: application/json"` specifies a `Content-Type` header that the client is passing and accepting JSON data. +a `Content-Type` header that the client is passing and accepting JSON data. + +If the login attempt is successful a token is returned. For example: +``` +{"token":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiYWRtaW4iLCJyb2xlcyI6WyJhZG1pbiJdLCJzY29wZXMiOlsiY29uZmlndXJlIiwic2hvdy1jb21tYW5kcyJdLCJjYXBhYmlsaXRpZXMiOlsiY29uZmlnLXJlYWQiLCJjb25maWctd3JpdGUiLCJwcm92aXNpb25pbmciXSwiYXBwbGljYXRpb24iOiJ1bmtub3duIiwidXNlckFnZW50IjoiThiSaintAR31lt0k3njI5LjAlc3MiOiIxMjcuMC4wLjEiLCJpc3MiOiJSVFJfRUFTVF9DT05EVUNUT1IiLCJpYXQiOjE3MjY1NDQ5Mzd9.NoEgcSzm752k1PWsvi5WtyFVCA825WI_fFMfOVeoNXvK1jsyW6UKiwGD8gSJFuQrtNYISgZWlBrqD3bhpiii33-DnAzOOEIuDXpbNGKAw2KwiuVKHoDIj8iWRi1grBERFpDFKCgjO15sR0q2JAb88k_EIkIHLeuS1bLSpi1mGfjRGeNcDh8DkCjQM1jH-DbPXf5oJ7pAq79pflLR-yS5WcWpeeQRaO_xrwWnd9cS4R31T-T0p1q0SYJanB9IQ3YUtue3zqArJmb4qHT46HJ_rctpp6NLXUih2Q7LEe7-DQB3yV9nDoB5vIAZn1PThiSaintAR31lt0k3ndH_KZxkuQQ"} +``` + +This token can be passed via an `Authorization` header to subsequent API calls for authorization. For example: +`curl --request GET -k --url 'https://192.168.0.1/api/v1/version' -H "Content-Type: application/json" -H 'Authorization: Bearer ` + +In this example, the address of the SSR is `192.168.0.1`, the API being called is `/api/v1/version`, and an `Authorization` header is specifying a `Bearer` token. The value returned from the `/api/v1/login` API should replace ``. For example: +from the `/api/v1/login` API should replace ``, for example: +``` +curl --request GET -k --url 'https://192.168.0.1/api/v1/version' -H "Content-Type: application/json" -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiYWRtaW4iLCJyb2xlcyI6WyJhZG1pbiJdLCJzY29wZXMiOlsiY29uZmlndXJlIiwic2hvdy1jb21tYW5kcyJdLCJjYXBhYmlsaXRpZXMiOlsiY29uZmlnLXJlYWQiLCJjb25maWctd3JpdGUiLCJwcm92aXNpb25pbmciXSwiYXBwbGljYXRpb24iOiJ1bmtub3duIiwidXNlckFnZW50IjoiY3VybC83LjIThiSaintAR31lt0k3nlc3MiOiIxMjcuMC4wLjEiLCJpc3MiOiJSVFJfRUFTVF9DT05EVUNUT1IiLCJpYXQiOjE3MjY1NDQ5Mzd9.NoEgcSzm752k1PWsvi5WtyFVCA825WI_fFMfOVeoNXvK1jsyW6UKiwGD8gSJFuQrtNYISgZWlBrqD3bhpiii33-DnAzOOEIuDXpbNGKAw2KwiuVKHoDIj8iWRi1grBERFpDFKCgjO15sR0q2JAb88k_EIkIHLeuS1bLSpi1mGfjRGeNcDh8DkCjQM1jH-DbPXf5oJ7pAq79pflLR-yS5WcWpeeQRaO_xrwWnd9cS4R31T-T0p1q0SYJanB9IQ3YUtue3zqArJmb4qHT46HJ_rctpp6NLXUih2Q7LEe7-DQB3yV9nDoB5vIAZn1PThiSaintAR31lt0k3ndH_KZxkuQQ' +``` + +## Built In Product Documentation + +There are numerous APIs in the SSR. The API documentation is available from the `About This System` page in the GUI. + +There are separate documentation pages for REST and GraphQL. The documentation pages feature interactive elements that allow the APIs to be dynamically tested from the GUI. + +The REST APIs are documented using Swagger and are found here: +`https:///documentation/swagger` + +The GraphQL APIs are documented using an interactive explorer and are found here: +`https:///documentation/graphql` + +## Tips + +The PCLI `trace` command can be used to see the API calls made for a given PCLI command. This can be useful to determine which data is available for common use cases. + +## Configuration Changes + +This section documents the method of configuring features using the `edit configuration` API. The changes mirror what is documented in the PCLI, which contain more detail about these configuration settings. The examples presented here, along with the online API documentation, can be used to create configuration for any of the documented Common Criteria settings. + +Once the `configuration edit` API has been issued and no errors reported in the response, the configuration can be commited using the `commit` API. For example: + +``` +curl --request POST https://127.0.0.1/api/config/commit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' +``` + +:::note +The examples use the command line utility `curl`, however any compliant REST API client can be used. The authorization tokens are removed for brevity. +::: + +### Configure asset-connection-resiliency + +The following examples show how to configure `asset-connection-resiliency` settings: + +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config", + "type": "merge", + "value": { + "authority": { + "asset-connection-resiliency": { + "enabled": true + } + } + } + } + ]' + +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config", + "type": "merge", + "value": { + "authority": { + "asset-connection-resiliency": { + "ssh-only": true + } + } + } + } + ]' +``` + +### Configure ssh-settings + +The following example shows how to set `ssh-settings` `inter-router` `host-key-checking` to `yes`: + +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config/authority/router/RTR_EAST_COMBO/node/combo-east-1/ssh-settings", + "type": "merge", + "value": { + "inter-router": { + "host-key-checking": "yes" + } + } + } + ]' +``` + +The following example shows how to set `ssh-settings` `inter-router` `host-key-checking` to `accept-new`: + +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config/authority/router/RTR_EAST_COMBO/node/combo-east-1/ssh-settings", + "type": "merge", + "value": { + "inter-router": { + "host-key-checking": "accept-new" + } + } + } + ]' +``` + +The following example shows how to set `ssh-settings` `inter-node` `host-key-checking` to `yes`: +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config/authority/router/RTR_EAST_COMBO/node/combo-east-1/ssh-settings", + "type": "merge", + "value": { + "inter-node": { + "host-key-checking": "yes" + } + } + } + ]' +``` + +The following example shows how to set `ssh-settings` `inter-node` `host-key-checking` to `accept-new`: +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config/authority/router/RTR_EAST_COMBO/node/combo-east-1/ssh-settings", + "type": "merge", + "value": { + "inter-node": { + "host-key-checking": "accept-new" + } + } + } + ]' +``` + +### Configure trusted-ca-certificate + +The following example shows how to configure a `trusted-ca-certificate` called "ca_root": + +``` +curl --request PATCH https://127.0.0.1/api/config/edit \ + -H "Content-Type: application/json" \ + -H 'authorization: Bearer ...' \ + -d '[ + { + "path": "/config", + "type": "merge", + "value": { + "authority": { + "trusted-ca-certificate": [ + { + "name": "ca_root", + "content": "-----BEGIN CERTIFICATE----- +... +-----END CERTIFICATE-----" + } + ] + } + } + } + ]' +``` \ No newline at end of file diff --git a/docs/cc_fips_6.3.0_sec_firewall_filtering.md b/docs/cc_fips_6.3.0_sec_firewall_filtering.md new file mode 100644 index 0000000000..1dd3b19c78 --- /dev/null +++ b/docs/cc_fips_6.3.0_sec_firewall_filtering.md @@ -0,0 +1,301 @@ +--- +title: Customizable Firewall Rules and Filters +sidebar_label: Customizable Firewall Rules and Filters +--- + +As part of the security hardening and certification process, the SSR has implemented the following firewall features to provide a more secure platform for network traffic. + +The SSR implements a packet filtering firewall which allows you to define rules for filtering traffic. The rules may be defined for specific traffic or all traffic. + +When Firewall filtering rules are defined, the traffic identified in the traffic filtering rules is filtered. Traffic that is not identified in the firewall filtering rules is allowed to pass, but is subject to conditions configured as part of SSR services. Services can be configured using IP addresses, hostnames, CIDR block ranges, and optionally transport protocols and specific ports. In order for any traffic to pass through an SSR, it must be identified in a service - its source must be classified as belonging to a tenant, its destination needs to match a FIB entry for this tenant, and a next-hop must be available for this service traffic. If traffic arrives at the SSR and does not match the firewall filters or a service, that traffic is not allowed to pass. If no firewall rules are configured, traffic is subject to the SSR and Services configuration. Traffic that does not meet these criteria is dropped. For additional service information, see [Service and Service Policy Design.](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/bcp_service_and_service_policy_design) + +Firewall rules may be applied to each network interface separately, and are applied in the order defined by the user. The SSR follows the rule base for each network connection and implements the first rule that matches the traffic. The SSR inspects each packet independently, and no residual information for previously inspected packets influences the inspection. + +## Packet Filtering + +The SSR uses Berkeley Packet Filters (BPF) to create customizable firewall filters. This filtering solution can be a key tool to prevent packet level attacks and aid with intrusion detection and prevention. Using BPF, packets on the SSR can be filtered by any known packet field, and the order in which filters are applied can be set by the user. +Filters are configured and applied on the receiving network-interface. + +#### Configuration + +1. At the Authority level, define the router, then the node, the device interface, and the network interface where the filters will be configured. + +2. Under `filter-rule`, define: +- The `action` - `deny` discards any packets matching the filter applied. `permit` allows packets that match the rule to bypass any additional rules, and passes the traffic. +- The filter type - `bpf` (Berkeley Packet Filter) is currently the only option. This identifies the filter to be applied. Validation confirms proper BPF syntax. + +3. Configuration of permit rules follows the same process. + +4. After the Filter Rule list has been created, you can reorder the rules using the `move` command. This list determines the order in which filter rules are applied. + +:::note +The number and complexity of rules will have an impact on forwarding performance. +::: + +#### Configuration Examples: + +**Using the CLI** + +``` +*admin@conductor.conductor# configure authority router 128t-west +*admin@conductor.conductor (router[name=128t-west])# node 128t-west +*admin@conductor.conductor (node[name=128t-west])# device-interface bfp-test +*admin@conductor.conductor (device-interface[name=bfp-test])# network-interface intf30 +*admin@conductor.conductor (network-interface[name=intf30])# filter-rule DropUDP_Port400 +*admin@conductor.conductor (filter-rule[name=DropUDP_Port400])# action deny +*admin@conductor.conductor (filter-rule[name=DropUDP_Port400])# bpf "udp port 400" +*admin@conductor.conductor (filter-rule[name=DropUDP_Port400])# exit +*admin@conductor.conductor (network-interface[name=intf30])# filter-rule PermitIPaddress +*admin@conductor.conductor (filter-rule[name=PermitIPaddress])# action permit +*admin@conductor.conductor (filter-rule[name=PermitIPaddress])# bpf "host 192.168.0.0" +``` + +**Using the Web Interface:** + +![Create the Packet filtering rule](/img/pckt_filter_rule_create.png) + +#### Moving Rules + +Rules can be moved using the CLI with the `move` command: + +``` +*admin@conductor.conductor (device-interface[name=bfp-test])# network-interface intf30 +*admin@conductor.conductor (network-interface[name=intf30])# move filter-rule DropUDP_Port400 after PermitIPaddress +*admin@conductor.conductor (network-interface[name=intf30])# show +name intf30 + +filter-rule PermitIPaddress + name PermitIPaddress + bpf "host 192.168.0.0" + action permit +exit + +filter-rule DropUDP_Port400 + name DropUDP_Port400 + bpf "udp port 400" + action deny +exit +``` + +Rules can be moved using the web interface by selecting the three dots next to the rule number: + +![Move a Rule](/img/pckt_filter_rule-move.png) + +:::note +Detailed information about Berkeley Packet Filters is outside of the scope of this documentation, but is readily available on the internet. +::: + +## ICMP + +Because ICMP can be an attack vector for a network or used to discover your network topology, ICMP attributes have been updated for firewall protection. + +### ICMP Type as a Session Attribute + +By default, the SSR does not use ICMP codes as a session attribute. However, the SSR does match ICMP error packets with the sessions that generated them, and only accepts those ICMP packets when they match an existing session. For instance, to protect against ICMP attacks from using a barrage of `Destination Unreachable` messages, if a TCP packet generates a `Destination Unreachable`, upon receipt of the `Destination Unreachable` the SSR uses the code to interpret the packet and match it to an existing session. If a match is found, the packet is forwarded to the end host. If a match is not found, the packet is rejected. + +To enable ICMP type as a session attribute: + +1. From the Authority level, configure `icmp-control`. + + +2. Set `icmp-async-reply` to `drop`. + +3. Set `icmp-session-match` to `identifier and type`. + +#### Configuration Examples + +``` +*admin@conductor.conductor# configure authority icmp-control icmp-async-reply drop +*admin@conductor.conductor# configure authority icmp-control icmp-session-match identifier-and-type +``` + +![ICMP Control](/img/icmp_async_drop.png) + +### Discard ICMP Echo Replies With No Request + +When you configure the ICMP Async Reply as `drop` (shown above), any ICMP Echo Replies that arrive at the SSR are dropped if no corresponding request has been seen. This helps to prevent DoS (Denial of Service) attacks such as an ICMP Ping flood. + +## IPv4 Option Filtering + +Attackers sometimes configure IPv4 options incorrectly, producing either incomplete or malformed fields. These malformed packets can be used to compromise hosts on the network. IPv4 Options Filtering provides a mechanism to determine what to do with network data packets based on the options field of the packets. The SSR will inspect the IPv4 header options, compare them to a user defined exclusiont list, and make necessary decisions whether the packets are allowed or dropped and logged. + +By default, all IPv4 packets with options are allowed. To configure the dropping of specific IPv4 options, you must first enable `drop-all`. This reveals the Drop Exclusions list, where you can define IPv4 options to exclude from the drop action. + +1. At the Authority level, configure `ipv4-option-filter action drop-all`. + +2. To configure allowed options, `ipv4-option-filter drop-exclusion 11`. + +3. Enter the Option type/number from the [IPv4 Parameters](https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-1). + +#### Configuration Examples + +``` +*admin@conductor.conductor# configure authority ipv4-option-filter action drop-all +*admin@conductor.conductor# configure authority ipv4-option-filter drop-exclusion 11 +*admin@conductor.conductor# show config candidate authority ipv4-option-filter + +config + + authority + + ipv4-option-filter + action drop-all + drop-exclusion 11 + exit + exit +exit + +*admin@conductor.conductor# +``` + +![IPV4 Option Filter](/img/ipv4_option_filter_drop.png) + +### Broadcast and Multicast Source Addresses + +To prevent DoS attacks, packets with broadcast or multicast source IP and MAC addresses are now dropped by default. Otherwise the traffic is propogated across the entire network, flooding the network. + +## Transport State Enforcement + +This functionality sets the action on how the TCP state machine should process unexpected TCP packets. This is important because in some cases where these unexpected packets arrive, it may indicate a TCP Reset attack. By default, the SSR checks and follows the TCP sequence numbers of all the sessions passing through, and increments the associated metrics. Setting the Transport State Enforcement field to Strict ensures any packets in the TCP stream that fall outside of the sequence number stream will be dropped. + +Any packets in the TCP stream that fall outside of the sequence number stream will be dropped. This will apply to any service that has this service policy configured. + +#### Configuration Examples + +``` +*admin@conductor.conductor# configure authority service-policy prefer-path-2 transport- +state-enforcement strict +*admin@conductor.conductor# +``` + +![Service Policy](/img/add_transport_state_enf_policy.png) + +![Strict Policy](/img/strict_transport_policy.png) + + +For a detailed description of Transport State Enforcement, refer to [Transport State Enforcement](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/bcp_service_and_service_policy_design#transport-state-enforcement). For additional configuration information, see the [transport-state-enforcement](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/config_reference_guide#service-policy) parameter. + +## TCP Half-Open Connection Limit + +Half-open TCP connections are those where the handshake has started but not completed. An attacker will initiate the handshake in order to take over all available TCP connections, known as a SYN Flood attack or distributed denial of service (DDoS) attack. This prevents service to legitimate traffic and potentially bring down the network. + +The SSR provides the ability to configure a limit to these half-open TCP connections. + +The connection limit is configured at the router level (Authority > Router), and is unlimited by default. To set a limit, enter a numerical value in the `Half-Open Connection Limit` field in the Router Basic Information panel. When configured, the SSR tracks how many half-open sessions there are based on existing TCP session state **and will deny any new TCP sessions once the limit has been reached**. + +:::caution +When the SSR approaches the configured limit of half-open TCP connections, the establishment of **healthy** TCP sessions may be significantly impacted. Please ensure that this value is set appropriately for your network. More importantly, attempt to identify the devices that are creating half-open sessions. +::: + +Additionally, if you require a limit for half-open TCP sessions, it may be helpful to consider the initial TCP session timeout value. The default timer is 10 seconds. If an application fails to establish a TCP socket, the sessions that are in that state will still remain on the SSR for that initial timeout. + +An awareness of these two values (half-open limit and TCP session timer) may mitigate the impact of limiting the establishment of **healthy** TCP sessions. + +#### Configuration Examples + +``` +*admin@conductor.conductor# +*admin@conductor.conductor# configure authority router 128t-west half-open-connection-l +imit 100000 +``` + +![Half-open limit](/img/half_open_cnx_limit.png) + +## Firewall Audit Events + +Use the `show events type traffic` to display the two types of traffic events. + +Use the `show events type traffic.denied` or the `show events type traffic.permitted` to display the firewall audit events. + +``` +admin@combo-east-a.combo-east# show events type traffic.denied +Wed 2024-03-06 21:00:24 UTC +================================================================== + 2024-03-06T21:00:23.956Z Traffic request violates access policy. +================================================================== + Type: traffic.denied + Node: combo-east-a + Denied Reason: access + Destination Address:172.16.2.40 + Destination Port: 1024 + Ingress Interface: 1.10 + Ip Protocol: udp + Permitted: False + Source Address: 172.16.1.40 + Source Port: 1024 +``` + +``` +admin@combo-east-a.combo-east# show events type traffic.permitted +Wed 2024-03-06 21:12:25 UTC +===================================================== + 2024-03-06T21:11:18.014Z Traffic request permitted. +===================================================== + Type: traffic.permitted + Node: combo-east-a + Destination Address:172.16.1.40 + Destination Port: 1024 + Ingress Interface: 5.0 + Ip Protocol: udp + Permitted: True + Source Address: 172.16.2.40 + Source Port: 1024 + +===================================================== + 2024-03-06T21:08:57.335Z Traffic request permitted. +===================================================== + Type: traffic.permitted + Node: combo-east-a + Destination Address:172.16.1.2 + Icmp Type: 8 + Ingress Interface: 1.10 + Ip Protocol: icmp + Permitted: True + Source Address: 172.16.1.40 +``` + +To correlate an interface with a firewall audit event, use the internal ID of the interface to undrestand which interface generated the event. This is visible in the `show device-interface` command as the `Internal ID: 1`. + +``` +admin@test1.Fabric128# show device-interface +Fri 2023-10-27 10:06:30 EDT +✔ Retrieving device interface information... + +======================================== + test1:LAN +======================================== + Type: ethernet + Internal ID: 1 + Forwarding: true + PCI Address: 0000:00:04.0 + MAC Address: fa:16:3e:88:8d:c1 + + Admin Status: up + Operational Status: up + Provisional Status: up + Redundancy Status: non-redundant + Speed: 10 Gb/s + Duplex: full + + in-octets: 360 + in-unicast-pkts: 4 + in-errors: 0 + out-octets: 0 + out-unicast-pkts: 0 + out-errors: 0 + + Plugin Info: unavailable + +``` + +### Discarded Traffic + +When firewall filtering is enabled, and rules are configured, any traffic that does not match the configured policies will be discarded/dropped. Additionally, any traffic meeting the following conditions will be discarded: + +- Any malformed packets. +- If the source address of the network packet is defined as being on a broadcast network. +- If the source address of the network packet is defined as being on a multicast network. +- Any packets with the following IP options: Loose Source Routing, Strict Source Routing, or Record Route. + + + diff --git a/docs/cc_fips_6.3.0_secure_deliver.md b/docs/cc_fips_6.3.0_secure_deliver.md new file mode 100644 index 0000000000..6973441a7f --- /dev/null +++ b/docs/cc_fips_6.3.0_secure_deliver.md @@ -0,0 +1,28 @@ +--- +title: Identifying Secure Product Delivery +sidebar_label: Identifying Secure Product Delivery +--- + +There are several mechanisms provided in the delivery process to ensure that a customer receives a product that has not been tampered with. The customer should perform the following checks upon receipt of a device to verify the integrity of the platform. + +- Shipping label: Ensure that the shipping label correctly identifies the correct customer name and address as well as the device. +- Outside packaging: Inspect the outside shipping box and tape. Ensure that the shipping tape has not been cut or otherwise compromised. Ensure that the box has not been cut or damaged to allow access to the device. +- Inside packaging: Inspect the plastic bag and seal. Ensure that the bag is not cut or removed. Ensure that the seal remains intact. +If you identify a problem during the inspection, immediately contact the supplier. Provide the order number, tracking number, and a description of the identified problem to the supplier. + +Additionally, there are several checks that can be performed to ensure that the customer has received a box sent by Juniper Networks. Perform the following checks upon receipt of the device to verify the authenticity of the device: + +- Verify that the device was ordered using a purchase order. Juniper Networks devices are never shipped without a purchase order. +- When a device is shipped, a shipment notification is sent to the e-mail address provided by the customer when the order is taken. Verify that this e-mail notification was received. Verify that the e-mail contains the following information: + - Purchase order number + - Juniper Networks order number used to track the shipment + - Carrier tracking number used to track the shipment + - List of items shipped including serial numbers + - Address and contacts of both the supplier and the customer + +- Verify that the shipment was initiated by Juniper Networks. To verify that a shipment was initiated by Juniper Networks, you should perform the following tasks: +- Compare the carrier tracking number of the Juniper Networks order number listed in the Juniper Networks shipping notification with the tracking number on the package received. +- Log on to the Juniper Networks online customer support portal at https://support.juniper.net/support to view the order status. +- Compare the carrier tracking number or the Juniper Networks order number listed in the Juniper Networks shipment notification with the tracking number on the package received. + + diff --git a/docs/cc_fips_6.3.0_software_upgrades.md b/docs/cc_fips_6.3.0_software_upgrades.md new file mode 100644 index 0000000000..ed31585f5a --- /dev/null +++ b/docs/cc_fips_6.3.0_software_upgrades.md @@ -0,0 +1,73 @@ +--- +title: Upgrades and Uninstallation +sidebar_label: Upgrades and Uninstallation +--- +This section provides information about the secure upgrade process and the uninstallation process of Common Criteria compliant software. + +## Software Upgrades + +To determine the current version of software running on your Conductor or Router, run the following command from the Conductor CLI: + +[`show system version`](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/cli_reference#show-system-version) + +Use this information if you upgrading to a newer software version **after having installed** an SSR Common Criteria compliant SSR software release, such as 6.2.5-5r2 or 6.3.0-107r1. + +The SSR Software packages are available from the Juniper Networks public servers using the **username and token provided to you.** During the upgrade process, your SSR uses this information to securely access the download location. Depending on your upgrade selection, the following location is accessed by the upgrade process: + + +- https://software.128technology.com/artifactory/list/generic-128t-isos-release-local + +Please refer to [Upgrade Considerations](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_upgrade_considerations) before upgrading. + +:::important +**The SSH Root login is not permitted and is not compliant with Common Criteria guidelines.** +::: + +To perform an upgrade on either a conductor or router, refer to the detailed instructions at [Upgrading the SSR Networking Platform.](https://www.juniper.net/documentation/us/en/software/session-smart-router/docs/intro_upgrading) + +Two upgrade methods are available depending on your network internet access: The `install128t` process which downloads and installs using an internet connection, or the `import iso` method where the ISO is downloaded onto a USB device, then loaded onto the Conductor, and installed from there. + +When using the `import iso` method, the `check-rpm-signature required` (default) option must be run. This ensures that the RPM signature and `sha256` digest of each package is validated during the import process. The use of `check-rpm-signature disabled` or `check-rpm-signature allow-unsigned` is not compliant for Common Criteria systems. For an online installation, signature checking is performed automatically. + +After upgrading the software, repeat the [Software Compliance Validation](cc_fips_6.3.0_access_mgmt.md#software-compliance-validation) steps to ensure continued compliance. + +:::important +Firmware and Software updates are expected to be performed by an Administrator on a regular basis, in response to the release of product updates due to known vulnerabilities. Only Common Criteria compliant software releases shall be installed on the target device. +::: + +## Uninstallation + +Common Criteria requires the Administrator to ensure there is no unauthorized access possible to sensitive residual information (e.g. cryptographic keys, keying material, PINs, passwords, etc.) on Common Criteria certified network equipment when that equipment is discarded or removed from its operational environment. + +For the certified SSR platforms, all software and configuration reside on the SSD hard drive `/dev/sda`. Use the following procedure to zeroize/erase the SSD hard drive. + +1. Log in to the local serial console as the root user + +2. Enter the following to gracefully shut down SSR service: + + `systemctl stop 128T` + +3. Enter the following command to enter single-user mode: + + `systemctl emergency` + +4. Re-enter the root password when prompted + +5. Enter the following command to zeroize the SSD hard drive: + + `dd if=/dev/zero of=/dev/sda bs=1M conv=fsync status=progress ` + + This process may take 30 minutes or more and will report **No space left on device** when complete. + + ![Uninstall and wipe SSD](/img/cc_fips_uninstall.png) + +6. Power off the system, or use the following command for soft power-off: + `echo o > /proc/sysrq-trigger` + +The system is wiped of all information, and is no longer operational as an SSR. If the system is to be reused in future, perform the ISO installation process. + + + + + + diff --git a/docs/cc_fips_6.3.0_ssr_security_scope.md b/docs/cc_fips_6.3.0_ssr_security_scope.md new file mode 100644 index 0000000000..4741431707 --- /dev/null +++ b/docs/cc_fips_6.3.0_ssr_security_scope.md @@ -0,0 +1,107 @@ +--- +title: SSR Security Scope +sidebar_label: SSR Security Scope +--- +This section provides high level descriptions of the security functions and mechanisms of the SSR for Common Criteria Compliance. + +## Security Audit + +The SSR provides an audit function to gather a rich set of detailed audit records of all critical security operations. Audit records are log entries which include necessary data pertinent to the event, allowing detailed analysis of the audit records. These records are protected against unauthorized modification and may be transferred to an audit server for storage and further analysis. The transfer of the audit records to the audit server is protected by SSH. + +## Cryptography + +The SSR implements cryptographic functions allowing secure communication with external devices. The SSR implements a random bit generator to generate cryptographic keys, key agreement mechanisms, public key cryptographic functions, symmetric cryptographic functions, secure hash functions, and keyed hash-based MAC functions providing protection of data and communication. Cryptographic keys and Critical Security Parameters (CSP) are destroyed by the SSR when no longer required. + +All cryptographic algorithms are validated through the Cryptographic Algorithm Validation Program (CAVP) to ensure correct functioning. + +## Syslog Over TLS + +The SSR implements [Syslog over TLS](cc_fips_6.3.0_config_audit_event.md#configuring-syslog-over-tls) for secure communication between the SSR and external devices such as an audit server or remote management device. Communication between the SSR and external devices uses Port 6514. The SSR implements public-key based authentication between itself and other devices. The public keys are stored in key containers. + +The SSR implements X.509 certificate-based authentication mechanisms. + +Both the Command Line Interface (CLI) and the Web Interface can be used to manage the SSR. They may be accessed by successfully authenticated Administrators locally from console, or remotely over SSH. Once authenticated, the Administrator uses the Conductor to manage one or more SSRs (routers). Management communication is also protected by SSH. + +## Platform Management + +Common Criteria-compliant platform management is performed by the administrator. Upon configuration of a valid, `trusted-ca-certificate`, use of the SSR Web interface (GUI), REST and GraphQL APIs is common criteria compliant. For information about configuring a `trusted-ca-ertificate`, see [Signing and Importing Webserver Certificates](cc_fips_6.3.0_access_mgmt.md#signing-and-importing-webserver-certificates). Additionally, platform management may still be performed from the CLI on the Conductor. + +### Identification, Authentication, and Access Management + +Each user is identified with a username and password, and upon successful verification of the password, a user is assigned to a role defined in the user configuration. Users are allowed to change their passwords within the parameters defined on the SSR. The passwords are stored in a secure file preventing unauthorized access. Passwords entered remotely are not echoed to ensure unauthorized parties may not learn passwords of legitimate Administrators. + +Each user may terminate their own session. The SSR also maintains an inactivity timer for each user. When the administrator-defined limit is reached, the SSR terminates that session. The inactivity timer applies to all sessions, regardless of whether they are local or SSH connections. Use the following command to configure the timeout value (in seconds): + +`configure authority router system inactivity-timer 60` + +Additionally, a counter records unsuccessful consecutive authentication attempts for local and remote users. Protective action is taken when the defined maximum value is exceeded. The Authentication window can be configured to display a banner informing the users of the sensitive nature of the SSR, and of the sanctions resulting from misuse or abuse of the SSR. + +### SSR Protection + +The SSR is protected from tampering and unauthorized access by both active and passive means. + +- Active Measures: These are the security measures that ensure that SSR data and functions are not accessible to unauthorized users. These include: + - Self-tests at boot, or when requested by an administrator, to assert correct functioning of the cryptographic functions. + - NTP synchronization producing reliable timestamps. + - Secure storage of passwords, cryptographic keys and CSPs. + - Managing firewall rule inspection to ensure that the previously processed traffic information does not influence the next filtering decisions. + - Secure upgrade process for the SSR software and verification of the authenticity of the upgrade prior to installing it. +- Passive Measures: These are the design characteristics of the SSR that minimize the attack surface accessible to threat agents. The minimization of the attack surface is achieved by the SSR software running on a dedicated hardware platform, with a minimum set of physical ports and connections, implementing only the necessary functions for the SSR. +- There are no general computing capabilities available to the users of the SSR. The SSR is not a general purpose device, no other software shall be installed or operated on the device. + +## Firewall + +The SSR implements a packet filtering firewall which allows you to define rules for filtering traffic. The rules may be defined for specific traffic or all traffic. + +When Firewall filtering rules are defined, only the traffic identified in the traffic filtering rules is filtered. All other traffic is allowed. If no firewall rules are configured, traffic flows normally subject to the SSR configuration. + +Firewall rules may be applied to each network interface separately, and are applied in the order defined by the user. The SSR follows the rule base for each network connection and implements the first rule that matches the traffic. The SSR inspects each packet independently, and no residual information for previously inspected packets influences the inspection. + +## Security Events + +### System Crashes + +The SSR `processManager` automatically restarts the failed processes based on system policy. Core files should be considered to contain customer confidential data and be handled with appropriate security. Core files are stored in `/var/lib/systemd/coredump` and can be removed by the administrator if not required. + +`$ sudo rm -f /var/lib/systemd/coredump/core*` + +The `coredumpctl list` command is used from the Linux shell to display crash history from the system journal. + +![System Crash Coredump](/img/cc_fips_system_crashes.png) + +### Updates to User Accounts + +When a user account is added, changed, or deleted, a security event is recorded in `accessManager.log`. This is for information only; no further action is required by the administrator. + +![Account Updates](/img/cc_fips_account_updates.png) + +### Audit Trail Overflow + +The `Auditd` retention policy is configured for 8MB logs, with five copies. When audit logs exceed 8MB, the current log file will be closed and a new file opened. After 5 files have been rotated in this manner, the oldest file will be deleted. No further action is required by the administrator. + +A `disk space remaining` action is configured and set to 100MB. If the system disk contains less than 100MB free space a warning message is written in syslog allowing the administrator to take recovery steps as required. Recovery steps include transfer of the audit logs off of the system, or removing non-critical files such as core dumps to free sufficient space on the disk. If the warning is ignored, the disk may eventually fill completely, impacting SSR service. + +The system configuration `disk-full-action` is set to `halt`. The system shuts down when audit logs can no longer be written due to disk space being exhausted. Recovery requires manual intervention during the boot process, allowing you to temporarily start the system in single-user maintenance mode with audit disabled. At this time stale files can be deleted from the disk. + +If the system halted due to audit disk full, proceed as follows: +1. Connect to the serial console port. +2. Boot the system. +3. During the GRUB2 boot menu countdown, press `e` to edit. + +![Press E](/img/cc_fips_audit_trail3.png) + +4. Scroll down and append `audit=0 S` to the end of the vmlinuz kernel line. + +![Add audit=0](/img/cc_fips_audit_trail4.png) + +5. Press Ctrl-x to boot the system into Single User mode. +6. Enter the root password when prompted, to access maintenance mode. +7. Remove stale logs and crash dump files to free space on the disk. + +![Remove logs](/img/cc_fips_audit_trail7.png) + +8. When complete, type `reboot` to boot back into normal SSR service. + +:::note +When you modify the GRUB kernel behavior by editing the GRUB menu at boot time, the changes do not persist over a system reboot. Default boot behavior is restored the next time you boot the system. +::: diff --git a/docs/cc_fips_6.3.0_titlepage.md b/docs/cc_fips_6.3.0_titlepage.md new file mode 100644 index 0000000000..17bea84ba8 --- /dev/null +++ b/docs/cc_fips_6.3.0_titlepage.md @@ -0,0 +1,32 @@ +--- +title: SSR 6.3.0 Common Criteria Installation and User Guide +sidebar_label: SSR 6.3.0 Common Criteria Installation and User Guide +--- + +This guide provides installation and configuration information for using SSR Conductors and Routers in a certified Common Criteria environment. The following platforms are supported for Common Criteria certification: + +Supported Software version: + +- Version 6.3.0-R1 +- Release Date: October 2024 + +Supported Hardware (must have Software Version 6.3.0-R1 installed): + +- SSR 120 +- SSR 130 +- SSR 1200 +- SSR 1300 +- SSR 1400 +- SSR 1500 + +#### Revision History + +This Common Criteria document is maintained separately from the SSR documentation. All revisions to this documentation set are recorded below. + +| Document Revision | Modification | Date | +| --- | --- | --- | +| 0.1 | Draft version for 6.3.0-R1 Common Criteria | June 28, 2024 | +| 0.2 | Draft version with updated installation process, initial edits and feature documentation. | October 9, 2024 | +| 0.3 | Draft version with X.509 process, other edits. | October 10, 2024 | +| 0.4 | Draft version with GUI and API update info. | November 8, 2024 | + diff --git a/docs/config_command_guide.md b/docs/config_command_guide.md index 3f4daccd31..d43794bbe0 100755 --- a/docs/config_command_guide.md +++ b/docs/config_command_guide.md @@ -17,7 +17,7 @@ Authority configuration is the top-most level in the SSR configuration hierarchy | [`asset-connection-resiliency`](#configure-authority-asset-connection-resiliency) | Configure Asset Connection Resiliency | | [`backwards-compatible-vrf-bgp-tenants`](#configure-authority-backwards-compatible-vrf-bgp-tenants) | When generating tenant names for VRF BGP over SVR, do not use leading or trailing underscores. This enables backwards compatibility with router versions smaller than 5.1.3 | | [`bgp-service-generation`](#configure-authority-bgp-service-generation) | Configure Bgp Service Generation | -| [`cli-messages`](#configure-authority-cli-messages) | Configure Cli Messages | +| [`cli-messages`](#configure-authority-cli-messages) | Configure CLI Messages | | [`client-certificate`](#configure-authority-client-certificate) | The client-certificate configuration contains client certificate content. | | `clone` | Clone a list item | | [`conductor-address`](#configure-authority-conductor-address) | IP address or FQDN of the conductor | diff --git a/docs/config_domain-based_web_filter.md b/docs/config_domain-based_web_filter.md index cc3a47efcc..487c68d99a 100644 --- a/docs/config_domain-based_web_filter.md +++ b/docs/config_domain-based_web_filter.md @@ -254,7 +254,7 @@ For example, on the URL: http://www.google.com/doodles/doodle-champion-island-ga exit exit ``` - + 2. If there was no match to the first query, then does any child service match the domain in the URL? - Yes, the following domain based service matches the URL: @@ -306,7 +306,7 @@ In this case, `google.com` does not fall into the category of Technology. ### Matching Order Algorithm The matching order algorithm is the same for scenarios when all the web filtering config options are used across different child services under the parent, or used on the same child service. For example, consider the following service: - + ``` service block-search.internet name search.internet diff --git a/docs/config_radsec.md b/docs/config_radsec.md index b861b31463..8346201c6c 100644 --- a/docs/config_radsec.md +++ b/docs/config_radsec.md @@ -246,5 +246,5 @@ Would you like to clean up the temporary certificate and key files? [Y/n]: Y Use the following example command to configure your device to accept the certificate. -` configure authority router ComboWest node combo-west radius client-certificate-name radsec` +`configure authority router ComboWest node combo-west radius client-certificate-name radsec` diff --git a/docs/config_syslog_tls.md b/docs/config_syslog_tls.md index 435dbba2b9..34d540f718 100644 --- a/docs/config_syslog_tls.md +++ b/docs/config_syslog_tls.md @@ -1,59 +1,10 @@ --- -title: Configuring Syslog Over TLS -sidebar_label: Configuring Syslog Over TLS +title: Syslog Over TLS +sidebar_label: Syslog Over TLS --- Syslog over TLS allows the secure transportation of system log messages from the syslog client to the syslog server. TLS uses certificates to authenticate and encrypt the communication. -## Syslog over TLS Configuration - Existing Certificate - -Use the following information to configure Syslog over TLS using an existing certificate. - -#### 1. Configure the Trusted CA Certificate. - -The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. - -Create a root certificate named `ca_root` and paste the certificate file content into the command: - -``` -admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root -admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root])# content -Enter plain for content (Press CTRL-D to finish): - -``` - -:::note -The `trusted-ca-certificate` is a list and may contain different CA roots used for different certificates. In that case, naming them all `ca_root` would not be suitable. In that case, choose a name that is meaningful to the user and CA, eg: `globalsign_root`. -::: - -#### 2. Configure a Client Certificate to be used for the Syslog Client. - -Repeat the previous step to create a client certificate named `syslog`. - -``` -admin@conductor-node-1.Conductor# config authority client-certificate syslog -admin@conductor-node-1.Conductor (client-certificate[name=syslog])# content -Enter plain for content (Press CTRL-D to finish): - -``` - -#### 3. Configure the Syslog Server at the Authority level to use the configured client certificate. - -The following configuration example will add a syslog server named `syslog` that will use the previously configured client certificate. - -``` -*admin@t327-dut1.cond# configure authority router cond system syslog server 192.168.1.100 6514 -*admin@t327-dut1.cond (server[ip-address=192.168.1.100][port=6514])# up -*admin@t327-dut1.cond (syslog)# client-certificate-name syslog -*admin@t327-dut1.cond (syslog)# protocol tls -*admin@t327-dut1.cond (syslog)# ocsp strict -*admin@t327-dut1.cond (syslog)# facility any -*admin@t327-dut1.cond (syslog)# severity info -*admin@t327-dut1.cond (syslog)# top -``` - -To complete the process, `validate` and `commit` the changes. After the confiuration changes have been committed, the SSR will send the syslog to 192.168.1.100:6514 over TLS. - ## Syslog over TLS Configuration - Generate Certificate Use the following examples to generate a client certificate for use on the device. @@ -185,3 +136,54 @@ Would you like to clean up the temporary certificate and key files? [Y/n]: Y Use the following example command to configure your device to accept the certificate. ` configure authority router ComboWest node combo-west radius client-certificate-name syslog` + +## Syslog over TLS Configuration - Existing Certificate + +Use the following information to configure Syslog over TLS using an existing certificate. + +#### 1. Configure the Trusted CA Certificate. + +The trusted CA certificate is necessary to validate the incoming client certificate. Certificates are pasted in as a multi-line config. + +Create a root certificate named `ca_root_syslog` and paste the certificate file content into the command: + +``` +admin@conductor-node-1.Conductor# config authority trusted-ca-certificate ca_root_syslog +admin@conductor-node-1.Conductor (trusted-ca-certificate[name=ca_root_syslog])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +:::note +The `trusted-ca-certificate` is a list and may contain different CA roots used for different certificates. In that case, naming them all `ca_root` would not be suitable. It is recommended to choose a name that is meaningful to the user and CA, eg: `ca_root_syslog`. +::: + +#### 2. Configure a Client Certificate to be used for the Syslog Client. + +Repeat the previous step to create a client certificate named `syslog`. + +``` +admin@conductor-node-1.Conductor# config authority client-certificate syslog +admin@conductor-node-1.Conductor (client-certificate[name=syslog])# content +Enter plain for content (Press CTRL-D to finish): + +``` + +#### 3. Configure the Syslog Server at the Authority level to use the configured client certificate. + +The following configuration example will add a syslog server named `syslog` that will use the previously configured client certificate. + +``` +*admin@t327-dut1.cond# configure authority router cond system syslog server 192.168.1.100 6514 +*admin@t327-dut1.cond (server[ip-address=192.168.1.100][port=6514])# up +*admin@t327-dut1.cond (syslog)# client-certificate-name syslog +*admin@t327-dut1.cond (syslog)# protocol tls +*admin@t327-dut1.cond (syslog)# ocsp strict +*admin@t327-dut1.cond (syslog)# facility any +*admin@t327-dut1.cond (syslog)# severity info +*admin@t327-dut1.cond (syslog)# top +``` + +To complete the process, `validate` and `commit` the changes. After the confiuration changes have been committed, the SSR will send the syslog to `192.168.1.100:6514` over TLS. + + diff --git a/docs/howto_ms365.md b/docs/howto_ms365.md index f468939df7..144aaad769 100644 --- a/docs/howto_ms365.md +++ b/docs/howto_ms365.md @@ -3,7 +3,7 @@ title: Microsoft 365 sidebar_label: Microsoft 365 --- -The SSR optimizes Microsoft 365 sessions, allowing you to easily configure the associated services to be delivered using the recommended [network connectivity principles](https://docs.microsoft.com/en-us/office365/enterprise/office-365-network-connectivity-principles). It uses an [AppID module](concepts_appid.md#appid-using-modules) for automatic discovery of Microsoft 365 endpoints, and simple service definition. +The SSR optimizes Microsoft 365 sessions, allowing you to easily configure the associated services to be delivered using the recommended [network connectivity principles](https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-network-connectivity-principles?view=o365-worldwide#microsoft-365-connectivity-principles). It uses an [AppID module](concepts_appid.md#appid-using-modules) for automatic discovery of Microsoft 365 endpoints, and simple service definition. :::info Microsoft 365, or M365 is formerly known as Office 365, or O365. diff --git a/docs/howto_router_migration.md b/docs/howto_router_migration.md index 45a9e5f2c5..32cf477dd5 100644 --- a/docs/howto_router_migration.md +++ b/docs/howto_router_migration.md @@ -73,6 +73,7 @@ The following example manually configures the key to the conductor node `192.168 `create system connectivity known-hosts router RTR_EAST_COMBO node combo-east-1 [192.168.1.13]:930 ssh-rsa ` +See [Enable Strict Host Key Checking](cc_fips_6.3.0_quickstart_otp.md#enable-strict-host-key-checking) for configuration information. + For additional information, see [`create system connectivity known-hosts`](cli_reference.md#create-system-connectivity-known-hosts). -See [Enable Strict Host Key Checking](cc_fips_otp_router_install.md#enable-strict-host-key-checking) for configuration information. \ No newline at end of file diff --git a/docs/howto_update_bios.md b/docs/howto_update_bios.md index 9d3c17d392..02253ce0ca 100644 --- a/docs/howto_update_bios.md +++ b/docs/howto_update_bios.md @@ -88,6 +88,7 @@ supports-priv-flags: yes ## Installation The BIOS update package can be installed using either of two methods: + - On-line install from Juniper SSR repositories. - RPM download & off-line installation. @@ -97,6 +98,7 @@ On systems with internet access, use the following steps to download and install 1. Login to your SSR device using SSH or through the console. 2. Enter the following command: + `sudo dnf install -y afulnx` ``` @@ -162,6 +164,7 @@ DO NOT INTERRUPT THIS PROCESS AFTER CONFIRMING! Doing so may result in an unboot ::: 3. The upgrade process takes place: + - Current BIOS version is saved as a backup. - Current DMI information is saved. - BIOS, ME, and NIC firmware is updated. diff --git a/docs/intro_downloading_iso.md b/docs/intro_downloading_iso.md index 0d83cff569..1d7c7e86be 100644 --- a/docs/intro_downloading_iso.md +++ b/docs/intro_downloading_iso.md @@ -25,6 +25,7 @@ For users installing *earlier, package-based versions of the SSR software*, the - **One Touch Provisioning (OTP)** is the default and preferred method of installation. OTP sets up DHCP on all interfaces and boots a Web Server GUI. After installing the Conductor and configuring routers through the Conductor, the OTP bootstrap process will install and configure the router. See the following procedures for OTP installation steps: - [Router Installation Using OTP](intro_otp_iso_install.mdx) - [Quickstart from the OTP ISO](intro_install_quickstart_otpiso.md) + - **Interactive:** Beginning with SSR version 6.3.0, the use of the interactive installer is not supported, nor necessary. Software installation and upgrade activities are supported from the GUI or PCLI. With software versions earlier than 6.3.0, upgrading the SSR software on a conductor or router that is managed by a conductor using the interactive installer may result in the system becoming unresponsive. For this reason it is highly recommended that upgrades be performed through the conductor UI. For a new installation of a conductor using software prior to 6.3.0, the interactive method can be used. :::note diff --git a/docs/intro_otp_iso_install.mdx b/docs/intro_otp_iso_install.mdx index 4817c31e4b..6a0196be36 100644 --- a/docs/intro_otp_iso_install.mdx +++ b/docs/intro_otp_iso_install.mdx @@ -28,11 +28,11 @@ Basic configuration parameters are encoded within an encrypted file. For each no ### Disk Cloning -Disk Cloning allows you to create a generic router platform image that can be used to perform multiple installations quickly and efficiently. After the initial ISO installation and power off, the platform is generic and can be cloned to a disk to create a copy of that platform. +Disk Cloning allows you to create a generic router platform image that can be used to perform multiple installations quickly and efficiently. After the initial ISO installation and power off, the platform is generic and can be cloned to a disk to create a copy of that platform. :::note When using cloned images, an identical hardware platform must be used. Create a new disk image for each hardware variation. ::: -The cloned platform disk is then used to install the filesystem and SSR software on any number of other identical hardware platforms. +The cloned platform disk is then used to install the filesystem and SSR software on any number of other identical hardware platforms. The general process for disk cloning is as follows: @@ -61,7 +61,7 @@ To install the Router using the OTP workflow, use the arrow keys to select the * Not all hardware has video support. Booting to the serial console 115200 baud is the default, and is automatically selected after 30 seconds. When using the serial console, the terminal size is 80x25 - anything smaller may result in abnormal navigation behavior. Selecting the wrong type of console (Serial or VGA) may result in garbled characters being displayed, and if left to continue will result in an incorrect installation. If the wrong console is selected, reboot the target system and select the correct line for the target hardware. -::: +::: #### SSR System via Serial Console @@ -151,14 +151,14 @@ Changing password for user t128 Changing password for t128 (current)UNIX password: New password: -Retype new password: +Retype new password: passwd: all authentication tokens updated successfully. -[t128@test-router ~]$ su - +[t128@test-router ~]$ su - Password: [root@test-router ~]# passwd Changing password for user root. New password: -Retype new password: +Retype new password: passwd: all authentication tokens updated successfully. [root@test-router ~]# ``` @@ -176,7 +176,7 @@ The scriptlets must have executable permissions to be executed properly. Any stdout/stderr output generated from the scriptlets is logged in `/var/log/128T-bootstrap/-scriptlet.log`. ### Bootstrapping Flow Chart -The diagram below shows the procedure the Bootstrap utility follows during the first bootup of the platform after the ISO installation completes. +The diagram below shows the procedure the Bootstrap utility follows during the first bootup of the platform after the ISO installation completes. ` +See [Enable Strict Host Key Checking](cc_fips_6.3.0_quickstart_otp.md#enable-strict-host-key-checking) for configuration information. + For additional information, see [`create system connectivity known-hosts`](cli_reference.md#create-system-connectivity-known-hosts). -See [Enable Strict Host Key Checking](cc_fips_otp_router_install.md#enable-strict-host-key-checking) for configuration information. \ No newline at end of file diff --git a/docs/plugin_ipsec_client.md b/docs/plugin_ipsec_client.md index 758eb09b38..8c602f6a9e 100644 --- a/docs/plugin_ipsec_client.md +++ b/docs/plugin_ipsec_client.md @@ -6,7 +6,7 @@ sidebar_label: IPsec Client The 128T-ipsec-client plugin provides a way to send and encrypt traffic to IPsec endpoints through the SSR. It is possible to configure the plugin for each router to have multiple destination IPsec endpoints and thus the SSR will failover between them. This is accomplished by performing a [Service Function Chain (SFC)](plugin_intro.md#service-function-chaining) with Libreswan, a third-party IPsec client. By enabling this plugin, you can provide IPsec tunnel connectivity to third party providers from your SSR. :::note -The instructions for installing and managing the plugin can be found [here](plugin_intro.md#installation-and-management). +The instructions for installing and managing the plugin can be found in [Plugin Workflow - Installation and Management](plugin_intro.md#installation-and-management). ::: ## Configuration @@ -14,30 +14,52 @@ The instructions for installing and managing the plugin can be found [here](plug The IPsec plugin setup has the following key parts to the configuration. * `ipsec-profile` describing the mechanism with which to connect to the server. * `ipsec-client` represent the remote endpoints or server with which the ipsec client communicates. +* `ipsec-client-settings` configure universal settings for all conductor-managed routers. * `service-route`'s to route the traffic through the tunnels ### Profiles -The `router > ipsec-profile`'s are reusable IPsec settings that can be used across multiple nodes in a router and multiple IPsec endpoint `remote`s. The table below represents the most common configuration elements for a valid ipsec profile. + +The `router > ipsec-profile`'s are reusable IPsec settings that can be used across multiple nodes in a router and multiple IPsec endpoint `remote`s. The examples below show two IPSec profiles that are mutually exclusive; one using pre-shared keys, and one using certificate based authentication. ``` router - ipsec-profile zscaler - name zscaler - ike-encryption aes256 - ike-digest sha2 - ike-modp modp1024 - authentication-protocol esp - phase2-encryption aes_gcm128 - phase2-digest sha2 - phase2-modp modp1024 - ike-lifetime 1h - connection-lifetime 8h - perfect-forward-secrecy true - dpddelay 20 - dpdtimeout 100 - dpdaction restart - local-id [local-id@domain.com] - pre-shared-key (removed) + ipsec-profile zscaler-preshared-key + name zscaler-preshared-key + ike-encryption aes256 + ike-digest sha2 + ike-modp modp1024 + authentication-protocol esp + phase2-encryption aes_gcm128 + phase2-digest sha2 + phase2-modp modp1024 + ike-lifetime 1h + connection-lifetime 8h + perfect-forward-secrecy true + dpddelay 20 + dpdtimeout 100 + dpdaction restart + local-id [local-id@domain.com] + pre-shared-key (removed) + exit + ipsec-profile zscaler-certificate + name zscaler-certificate + ike-encryption aes128 + ike-digest sha2 + ike-modp modp1024 + authentication-protocol esp + phase2-encryption aes_gcm256 + phase2-digest sha2 + phase2-modp modp1024 + ike-lifetime 1h + connection-lifetime 8h + perfect-forward-secrecy true + dpddelay 20 + dpdtimeout 100 + dpdaction restart + local-id [local-id@domain.com] + private-key-name rem1-private-key + local-certificate-name rem1-cert + trusted-ca-certificate-name ca-cert exit exit ``` @@ -61,10 +83,21 @@ The above configuration example represents a typical profile used for a IPSec pr | dpdtimeout | seconds | 100 | After the period has elapsed with no traffic including DPD traffic, the connection will be declared dead | | dpdaction | enum | restart | Action taken once the enabled peer is detected as dead | | local-id | string | user-defined | How to identify the router for authentication. Can be an IP address of FQDN. Must be preceded with an `@` symbol to prevent resolution as shown in the example | -| pre-shared-key | string | user-defined | pre-shared key used for authentication | +| pre-shared-key | string | user-defined | pre-shared key used for authentication | +| private-key-name | reference | - | The name that references the private key defined in [Private Key](#private-key) | +| local-certificate-name | reference | - | The name that references the client certificate defined in [`client-certificate`](config_command_guide.md#configure-authority-client-certificate)| +| trusted-ca-certificate-name | reference | - | The name that references the trusted CA certificate defined in [`trusted-ca-certificate`](config_command_guide.md#configure-authority-trusted-ca-certificate) | + +##### Version History + +| Release | Modification | +| -------- | ------------------------------------ | +| 3.7.0 | `profile > private-key-name` introduced | +| 3.7.0 | `profile > local-certificate-name ` introduced | +| 3.7.0 | `profile > trusted-ca-certificate-name` introduced | :::note -This plugin can only connect to IPsec endpoints that support pre-shared key authentication. +`local-certificate-name`, `trusted-ca-certificate-name` and `private-key-name` must be configured in order to use X.509 certificate type. ::: #### Custom Options @@ -117,7 +150,7 @@ The main config properties of a remote endpoint are as follows. | name | string | The name of the remote client to be used for sending traffic to the tunnel. | | host | ip-or-fqdn | The address or FQDN of the remote endpoint. | | profile | reference | The name of the profile to be used for this remote endpoint. | -| remote-id | string | The optional remote identifier used during authentication. | +| remote-id | string | The optional remote identifier used during authentication. This field must be correctly configured as the remote side certificate common name (CN). | | subnet | ip-prefix | The remote subnet behind the tunnel. | | tunnel-monitor | container | Properties for monitoring the phase-2 connection. See [Tunnel Monitoring](#tunnel-monitoring) for more information. | @@ -151,8 +184,8 @@ router myRouter remote secondary name primary host - profile myProfile - remote-id prisma@paloalto.com + profile zscaler-certificate + remote-id subnet 0.0.0/0 tunnel-monitor enabled true @@ -179,6 +212,75 @@ The `ipsec-client > name` cannot start with `ipsec` or `mast`. See notes [here]( Each `remote` represents a unique tunnel destination and can be used to route traffic in/out of the tunnels. Typically each node has two tunnels to act as primary and backup. +### Client Settings + +##### Version History + +| Release | Modification | +| -------- | ------------------------------------ | +| 3.7.0 | `authority > ipsec-client-settings` introduced | + +Client settings are a collection of common settings that apply to all conductor-managed routers running the IPSec plugin. + +The main configuration properties of client settings are as follows: + +| Config | Type | Description | +| -------- | ----- | ------------------- | +| common-criteria-mode | boolean | Default is `false`. When enabled, common criteria mode is applied upon validation. | +| private-key | list | List of [Private Keys](#private-key) to be used for IPSec X.509 certificate type. | + + +``` console +config + + authority + ipsec-client-settings + common-criteria-mode true + private-key rem1-private-key + name rem1-private-key + content (removed) + exit + + private-key rem2-private-key + name rem2-private-key + content (removed) + exit + exit +exit +``` + +#### Private Key + +##### Version History + +| Release | Modification | +| -------- | ------------------------------------ | +| 3.7.0 | `ipsec-client-settings > private-key` introduced | + +The `private-key` allows the users to configure private keys to be used for IPSec X.508 certificate type. + +``` +config + authority + ipsec-client-settings + private-key rem1-private-key + name rem1-private-key + content (removed) + exit + exit + exit +exit +``` + +| Config | Type | Description | +| -------- | ----- | ------------------- | +| name | string | The name of the the private key. | +| content | string | Private key to be used for X.509 certificate. | + +:::warning +The `private-key` is used to create the pkc12 certificate for tunnel authentication. A wrongly configured private key may prevent an IPSec tunnel from being established successfully. +::: + ### Tunnel Monitoring ##### Version History @@ -289,6 +391,20 @@ exit Once enabled, the records will allow the IPsec controller to perform additional functions such as detecting and remediating stuck egress tunnel sessions and reporting the name of the WAN interface being used for the tunnel. +### Configure X.509 Certificate-type for Tunnel Authentication + +The IPsec plugin requires users to generate/acquire their private key, a CA certificate file, and user certificate file. This must be signed by the CA certificate offline by utilities mentioned in Libreswan document (or other reliable sources such as openssl). Refer to the public [HOWTO:_Using_NSS_with_libreswan document](https://libreswan.org/wiki/HOWTO:_Using_NSS_with_libreswan) for additional information. Note that the IPsec plugin will take over the configuration mentioned in `Importing third-party files into NSS` in the Libreswan document. + +Use the following steps to create the X.509 certificate-type for Tunnel Authentication. + +1. Configure the [`private-key`](#private-key). +2. Configure the [`client-certificate`](config_command_guide.md#configure-authority-client-certificate). +3. Configure the [`trusted-ca-certificate`](config_command_guide.md#configure-authority-trusted-ca-certificate). +4. Enter the key names for each of these items in their respective fields in the [`ipsec-profile`](#profiles). + +This information is used to generate the PKCS12 file. The IPsec NSS database stores the generated PKCS12 file for tunnel authentication. + + ### Directing traffic through the tunnel The user can leverage standard SSR service and service-route to direct intended traffic over the ipsec tunnel. In the example below, all guest internet traffic is sent over the ipsec tunnel for break and inspect. This can be accomplished as follows: @@ -870,7 +986,6 @@ Image based install and upgrade (IBU) support for SSR 6.3.0. _**Resolution:**_ The DNS resolution from IPSec namespace enforces better controls and limits to avoid a startup race condition due to which the monitoring script was getting stuck forever. The graceful handling would prevent other scripts from getting stuck indefinetly. - ### Release 3.6.1 **Release Date:** May 29, 2024 @@ -899,7 +1014,6 @@ Image based install and upgrade (IBU) support for SSR 6.3.0. _**Resolution:**_ Delete the port 500 and 4500 sessions whenever the tunnel does not come up. - ### Release 3.6.0 **Release Date:** Oct 13, 2023 diff --git a/docs/release_notes_128t_6.3.md b/docs/release_notes_128t_6.3.md index dd2e168078..a5d309bf87 100644 --- a/docs/release_notes_128t_6.3.md +++ b/docs/release_notes_128t_6.3.md @@ -130,7 +130,7 @@ Before upgrading please review the [**Upgrade Considerations**](intro_upgrade_co ### New Features -- **I95-23304 Dynamic Source NAT:** Dynamic Source NAT translates multiple source IP addresses into a smaller pool of translated addresses and dynamic ports, which conserves public IP address space and provides the flexibility to source NAT a specific IP range. This supports scaling up sessions for an internal service. For more information, see [Dynamic NAT](config_dnat.md). +- **I95-23304 Dynamic Source NAT:** Dynamic Source NAT translates multiple source IP addresses into a smaller pool of translated addresses and dynamic ports, which conserves public IP address space and provides the flexibility to source NAT a specific IP range. This supports scaling up sessions for an internal service. For more information, see [Dynamic NAT](config_dnat.md). ------ - **I95-23816 Network Interface Traffic Engineering:** Network interface traffic engineering allows you to impose limitations on all traffic egressing a specific network-interface. For more information about using and configuring network interface traffic engineering, see [Network Interface Traffic Engineering](config_te_net_intf.md). ------ @@ -178,7 +178,7 @@ Before upgrading please review the [**Upgrade Considerations**](intro_upgrade_co - **The following CVE's have been identified and addressed in this release:** CVE-2024-22232, CVE-2024-21011, CVE-2024-21012, CVE-2024-21068, CVE-2024-21085, CVE-2024-21094, CVE-2019-13631, CVE-2019-15505, CVE-2019-25162, CVE-2020-25656, CVE-2020-36777, CVE-2021-3753, CVE-2021-4204, CVE-2021-46934, CVE-2021-47013, CVE-2021-47055, CVE-2021-47118, CVE-2021-47153, CVE-2021-47171, CVE-2021-47185, CVE-2022-0500, CVE-2022-23222, CVE-2022-3565, CVE-2022-45934, CVE-2022-48627, CVE-2022-48669, CVE-2023-1513, CVE-2023-24023, CVE-2023-25775, CVE-2023-28464, CVE-2023-31083, CVE-2023-3567, CVE-2023-37453, CVE-2023-38409, CVE-2023-39189, CVE-2023-39192, CVE-2023-39193, CVE-2023-39194, CVE-2023-39198, CVE-2023-4133, CVE-2023-4244, CVE-2023-42754, CVE-2023-42755, CVE-2023-45863, CVE-2023-51779, CVE-2023-51780, CVE-2023-52340, CVE-2023-52434, CVE-2023-52439, CVE-2023-52445, CVE-2023-52448, CVE-2023-52477, CVE-2023-52489, CVE-2023-52513, CVE-2023-52520, CVE-2023-52528, CVE-2023-52565, CVE-2023-52574, CVE-2023-52578, CVE-2023-52580, CVE-2023-52581, CVE-2023-52594, CVE-2023-52595, CVE-2023-52598, CVE-2023-52606, CVE-2023-52607, CVE-2023-52610, CVE-2023-52620, CVE-2023-6121, CVE-2023-6176, CVE-2023-6240, CVE-2023-6622, CVE-2023-6915, CVE-2023-6932, CVE-2024-0340, CVE-2024-0841, CVE-2024-23307, CVE-2024-25742, CVE-2024-25743, CVE-2024-25744, CVE-2024-26593, CVE-2024-26602, CVE-2024-26603, CVE-2024-26609, CVE-2024-26610, CVE-2024-26615, CVE-2024-26642, CVE-2024-26643, CVE-2024-26659, CVE-2024-26664, CVE-2024-26671, CVE-2024-26693, CVE-2024-26694, CVE-2024-26743, CVE-2024-26744, CVE-2024-26779, CVE-2024-26872, CVE-2024-26892, CVE-2024-26897, CVE-2024-26901, CVE-2024-26919, CVE-2024-26933, CVE-2024-26934, CVE-2024-26964, CVE-2024-26973, CVE-2024-26993, CVE-2024-27014, CVE-2024-27048,CVE-2024-27052, CVE-2024-27056, CVE-2024-27059, CVE-2024-2961, CVE-2024-33599, CVE-2024-33600, CVE-2024-33601, CVE-2024-33602, CVE-2024-32487, CVE-2023-4408, CVE-2023-50387, CVE-2023-50868, CVE-2023-4408, CVE-2023-50387, CVE-2023-50868, CVE-2024-3596. ------ -- **I95-48453 Reverse SSH tunnels do not check Known Hosts file:** Functionality has been added to allow for the retrieval of the ssh known hosts and authorized keys file contents on the SSR. For details on the known host functionality, see [Strict Host Key Checking](cc_fips_otp_router_install.md#enable-strict-host-key-checking). +- **I95-48453 Reverse SSH tunnels do not check Known Hosts file:** Functionality has been added to allow for the retrieval of the ssh known hosts and authorized keys file contents on the SSR. For details on the known host functionality, see [Strict Host Key Checking](cc_fips_6.3.0_quickstart_otp.md#enable-strict-host-key-checking). ------ - **I95-49218 Filter OSPF routes using RIB Policy routes:** Use the `configure authority router routing rib-policy` command from either the routing default-instance (`configure authority router routing`) or inside `configure authority router routing vrf` to provide additional filtering for OSPF routes. For more information see [`configure authority router routing rib-policy`](config_command_guide.md#configure-authority-router-routing-rib-policy) and [`configure authority router routing vrf rib-policy`](config_command_guide.md#configure-authority-router-routing-vrf-rib-policy). ------ diff --git a/docs/sec_hardening_guidelines.md b/docs/sec_hardening_guidelines.md index 9267a78829..b07839983c 100644 --- a/docs/sec_hardening_guidelines.md +++ b/docs/sec_hardening_guidelines.md @@ -3,7 +3,7 @@ title: Security Hardening Guidelines sidebar_label: Security Hardening Guidelines --- -This section provides a list of security hardening actions and guidelines to provide additional security to your SSR and your network overall. Many of the guidelines below are covered in the [SSR Common Critieria Install and Configuration](cc_fips_titlepage.md) documentation. +This section provides a list of security hardening actions and guidelines to provide additional security to your SSR and your network overall. Many of the guidelines below are covered in the [SSR Common Critieria Install and Configuration](cc_fips_6.3.0_titlepage.md) documentation. ## Administrative - Review SSR security polices for CVE tracking and notifications: [Juniper SSR Security Policies](about_security_policy.md#release). @@ -33,7 +33,7 @@ When the SSR approaches the configured limit of half-open TCP connections, the e - Ensure Proxy ARP is either not configured, or is restricted to specific interfaces. ## Management Services Security -- Consider enabling [FIPS mode](cc_fips_conductor_install.md#conductor-installation) to restrict the encryption algorithms used for management connections. +- Consider enabling [FIPS mode](cc_fips_6.3.0_install_univ_iso.md) to restrict the encryption algorithms used for management connections. - Configure known/trusted NTP servers and authentication. - Configure SNMP using the most secure method with more than one trusted server. - Community strings and USM passwords should be difficult to guess and follow password complexity policy. @@ -43,7 +43,7 @@ When the SSR approaches the configured limit of half-open TCP connections, the e - Create configuration backups to more than one trusted server to provide resiliency. ## Access Security -- Configure a [login warning banner](cc_fips_banners.md) that is displayed prior to credentials being provided. +- Configure a [login warning banner](cc_fips_6.3.0_banners.md) that is displayed prior to credentials being provided. - Ensure unnecessary host services (SSH, HTTPS, etc.) are not configured. - Use HTTPS with a valid certificate signed by a trusted CA. - Ensure access lists are configured for required services (SSH, HTTPS). diff --git a/sidebars.js b/sidebars.js index 3628c7384e..495d61d673 100644 --- a/sidebars.js +++ b/sidebars.js @@ -17,26 +17,50 @@ module.exports = { "intro_system_reqs", "config_firewall_ports", ], - "SSR Common Criteria Install and Configuration": [ - "cc_fips_titlepage", - "cc_fips_intro", - "cc_fips_compliance_guidelines", - "cc_fips_ssr_security_scope", - "cc_fips_secure_deliver", - "cc_fips_intro_installation", - "cc_fips_downloading_iso", - "cc_fips_conductor_install", - "cc_fips_otp_router_install", - "cc_fips_install_quickstart_otpiso", - "cc_fips_router_install", - "cc_fips_access_mgmt", - "cc_fips_config_ntp_auth", - "cc_fips_config_password_policies", - "cc_fips_config_audit_event", - "cc_fips_sec_firewall_filtering", - "cc_fips_banners", - "cc_fips_software_upgrades", - "cc_fips_appendix", + "SSR 6.2.5 Common Criteria Install and Configuration": [ + "cc_fips_6.2.5_titlepage", + "cc_fips_6.2.5_intro", + "cc_fips_6.2.5_compliance_guidelines", + "cc_fips_6.2.5_ssr_security_scope", + "cc_fips_6.2.5_secure_deliver", + "cc_fips_6.2.5_intro_installation", + "cc_fips_6.2.5_downloading_iso", + "cc_fips_6.2.5_conductor_install", + "cc_fips_6.2.5_otp_router_install", + "cc_fips_6.2.5_install_quickstart_otpiso", + "cc_fips_6.2.5_router_install", + "cc_fips_6.2.5_access_mgmt", + "cc_fips_6.2.5_config_ntp_auth", + "cc_fips_6.2.5_config_password_policies", + "cc_fips_6.2.5_config_audit_event", + "cc_fips_6.2.5_sec_firewall_filtering", + "cc_fips_6.2.5_banners", + "cc_fips_6.2.5_software_upgrades", + "cc_fips_6.2.5_appendix", + ], + "SSR 6.3.0 Common Criteria Install and Configuration": [ + "cc_fips_6.3.0_titlepage", + "cc_fips_6.3.0_intro", + "cc_fips_6.3.0_compliance_guidelines", + "cc_fips_6.3.0_ssr_security_scope", + "cc_fips_6.3.0_secure_deliver", + "cc_fips_6.3.0_intro_installation", + "cc_fips_6.3.0_intro_install_univ-iso", + "cc_fips_6.3.0_install_univ_iso", + "cc_fips_6.3.0_initialize_u-iso_device", + "cc_fips_6.3.0_otp_router_install", + "cc_fips_6.3.0_quickstart_otp", + "cc_fips_6.3.0_initialize_u-iso_adv_workflow", + "cc_fips_6.3.0_access_mgmt", + "cc_fips_6.3.0_config_radsec", + "cc_fips_6.3.0_config_ntp_auth", + "cc_fips_6.3.0_config_password_policies", + "cc_fips_6.3.0_config_audit_event", + "cc_fips_6.3.0_sec_firewall_filtering", + "cc_fips_6.3.0_banners", + "cc_fips_6.3.0_rest_graphql_apis", + "cc_fips_6.3.0_software_upgrades", + "cc_fips_6.3.0_appendix", ], "Upgrading the SSR": [ "intro_upgrade_considerations", @@ -341,6 +365,7 @@ module.exports = { "howto_pppoe_vlan", "howto_ms365", "howto_trusted_ca_certificate", + "howto_update_bios", ], }, { diff --git a/static/img/add_transport_state_enf_policy.png b/static/img/add_transport_state_enf_policy.png new file mode 100644 index 0000000000..c34519c6e2 Binary files /dev/null and b/static/img/add_transport_state_enf_policy.png differ diff --git a/static/img/asset-connection-resiliency.png b/static/img/asset-connection-resiliency.png new file mode 100644 index 0000000000..3c793a263f Binary files /dev/null and b/static/img/asset-connection-resiliency.png differ diff --git a/static/img/cc_fips_otp_serial-6.3.0.png b/static/img/cc_fips_otp_serial-6.3.0.png new file mode 100644 index 0000000000..30b67f3e84 Binary files /dev/null and b/static/img/cc_fips_otp_serial-6.3.0.png differ diff --git a/static/img/cc_fips_otp_serial2-6.3.0.png b/static/img/cc_fips_otp_serial2-6.3.0.png new file mode 100644 index 0000000000..a0e7a19f76 Binary files /dev/null and b/static/img/cc_fips_otp_serial2-6.3.0.png differ diff --git a/static/img/client_cert_accept_syslog.png b/static/img/client_cert_accept_syslog.png new file mode 100644 index 0000000000..2264c2e3de Binary files /dev/null and b/static/img/client_cert_accept_syslog.png differ diff --git a/static/img/conf_cli_message.png b/static/img/conf_cli_message.png new file mode 100644 index 0000000000..e11c454f53 Binary files /dev/null and b/static/img/conf_cli_message.png differ diff --git a/static/img/config-audit-logging3.png b/static/img/config-audit-logging3.png new file mode 100644 index 0000000000..68a29f85a9 Binary files /dev/null and b/static/img/config-audit-logging3.png differ diff --git a/static/img/config-authority-settings-button.png b/static/img/config-authority-settings-button.png new file mode 100644 index 0000000000..057be7dedc Binary files /dev/null and b/static/img/config-authority-settings-button.png differ diff --git a/static/img/config-password-policies.png b/static/img/config-password-policies.png new file mode 100644 index 0000000000..de9b24c98d Binary files /dev/null and b/static/img/config-password-policies.png differ diff --git a/static/img/config_web_message.png b/static/img/config_web_message.png new file mode 100644 index 0000000000..f725e4f8d6 Binary files /dev/null and b/static/img/config_web_message.png differ diff --git a/static/img/configure-audit-logging1.png b/static/img/configure-audit-logging1.png new file mode 100644 index 0000000000..827231d94f Binary files /dev/null and b/static/img/configure-audit-logging1.png differ diff --git a/static/img/configure-audit-logging2.png b/static/img/configure-audit-logging2.png new file mode 100644 index 0000000000..e0735dbf27 Binary files /dev/null and b/static/img/configure-audit-logging2.png differ diff --git a/static/img/enable-strict-hostkey-checking.png b/static/img/enable-strict-hostkey-checking.png new file mode 100644 index 0000000000..bd2919f6e5 Binary files /dev/null and b/static/img/enable-strict-hostkey-checking.png differ diff --git a/static/img/half_open_cnx_limit.png b/static/img/half_open_cnx_limit.png new file mode 100644 index 0000000000..4afdbbf9bc Binary files /dev/null and b/static/img/half_open_cnx_limit.png differ diff --git a/static/img/icmp_async_drop.png b/static/img/icmp_async_drop.png new file mode 100644 index 0000000000..2d10293815 Binary files /dev/null and b/static/img/icmp_async_drop.png differ diff --git a/static/img/import-webserver-cert1.png b/static/img/import-webserver-cert1.png new file mode 100644 index 0000000000..d4f23b67dc Binary files /dev/null and b/static/img/import-webserver-cert1.png differ diff --git a/static/img/import-webserver-cert2.png b/static/img/import-webserver-cert2.png new file mode 100644 index 0000000000..212876da51 Binary files /dev/null and b/static/img/import-webserver-cert2.png differ diff --git a/static/img/ipv4_option_filter_drop.png b/static/img/ipv4_option_filter_drop.png new file mode 100644 index 0000000000..273fffcf87 Binary files /dev/null and b/static/img/ipv4_option_filter_drop.png differ diff --git a/static/img/ntp-client-authentication.png b/static/img/ntp-client-authentication.png new file mode 100644 index 0000000000..9bd755ecf5 Binary files /dev/null and b/static/img/ntp-client-authentication.png differ diff --git a/static/img/pckt_filter_rule-move.png b/static/img/pckt_filter_rule-move.png new file mode 100644 index 0000000000..605bdcebc6 Binary files /dev/null and b/static/img/pckt_filter_rule-move.png differ diff --git a/static/img/pckt_filter_rule_create.png b/static/img/pckt_filter_rule_create.png new file mode 100644 index 0000000000..cc23cfd5f6 Binary files /dev/null and b/static/img/pckt_filter_rule_create.png differ diff --git a/static/img/software-compliance-valid.png b/static/img/software-compliance-valid.png new file mode 100644 index 0000000000..a652aa957a Binary files /dev/null and b/static/img/software-compliance-valid.png differ diff --git a/static/img/strict_transport_policy.png b/static/img/strict_transport_policy.png new file mode 100644 index 0000000000..2d046782d5 Binary files /dev/null and b/static/img/strict_transport_policy.png differ diff --git a/static/img/u-iso_com-crit_6.3.0_local-login.png b/static/img/u-iso_com-crit_6.3.0_local-login.png new file mode 100644 index 0000000000..f06c64812b Binary files /dev/null and b/static/img/u-iso_com-crit_6.3.0_local-login.png differ