General system maintenance

This section describes common maintenance procedures to perform on your ASMS system.

In this topic:

Reboot the appliance

This procedure describes how to reboot your appliance, which is sometimes required as part of other maintenance and configuration procedures.

Do the following:

1. Connect to the ASMS Administration Interface. For details, see Connect to and Utilize the Administration Interface.

2. Press CTRL+C to exit the menu.

3. Run the following command:

   reboot

If needed, Hardware Appliances can also be rebooted by pressing the power button on the front panel of the appliance for 10 seconds, and then pressing it again. We do not recommend this method as part of regular operation.

Back to top

Reset the appliance to factory defaults

This procedure describes how to reset the appliance to factory defaults, and must be performed if you are reusing an appliance in a new role.

For example, you might do this if you appliance was previously used as a Central Manager, and you now want to use it as a Load Unit or Remote Agent.

Do the following:

1. We recommend backing up your data before you reset the appliance.

2. Remove any USB flash drive from the appliance in order to eliminate temp partitions on the OS that can fail the restore operation.

3. Connect to the ASMS Administration Interface. For details, see Connect to and Utilize the Administration Interface.

4. Run the following command:

   reboot

5. When the appliance reboots and a message appears, press SPACE. Do this within 5 seconds to prevent the appliance from fully rebooting.

   The appliance OS menu appears.

   

6. Use the arrow keys to select Restore to Factory Defaults, then press ENTER.

   A warning message appears.

7. Enter erase.

   Another warning message appears.

8. Enter YES. Make sure you use capital letters.

   The system is formatted and re-installed, and all data is deleted. This process can take several minutes.

   At the end of the process, the system is automatically restarted.

9. Continue by configuring your machine again. For details, see Configure ASMS machines. To upgrade your machine, contact AlgoSec support to retrieve older versions of ASMS.

Back to top

Install ASMS on a repurposed AlgoSec hardware appliance

This procedure describes how to repurpose an AlgoSec hardware appliance with A32.10 if you are reusing the appliance in a new role.

For example, you might do this if you appliance was previously used as a Central Manager, and you now want to use it as a Load Unit or Remote Agent.

Do the following:

Reinstall ASMS, either:

• from a bootable flask drive (see Install ASMS from a bootable flash drive)

• with iLO (see Install ASMS with iLO 5).

Back to top

AlgoSec Hardware Appliance Firmware Service Pack Updates

From time to time we publish updates to the latest AlgoSec Hardware Appliance Firmware Service Pack we support. You can see the latest supported versions on the Partner and Customer Portal HERE.

To update the AlgoSec Hardware Appliance Firmware Service Pack:

Do the following:

1. Go to the Partner and Customer Portal Downloads > Software > AlgoSec firmware appliance updates or click HERE.

2. Download latest verified version of Service Pack for Proliant (SPP) for the Gen version appliance by clicking the link on the page.

3. Login to iLO.

4. Open the Remote Console. Click Virtual Folder > CD/DVD > Local .iso file.

5. Select file you just downloaded. Click Open.

6. Reboot your server.

7. When the server restarts, press F11 to access the Boot menu.

8. Enter the option number for One Time Boot to CD-ROM.

9. Select the option Automatic Firmware Upgrade. The upgrade process should take around 45 minutes.

Back to top

Migrate the Central Manager

This procedure describes how to migrate the ASMS Central Manager to another appliance, including a virtual appliance, AlgoSec hardware appliance, or an AWS/Azure instance. For example, you may want to do this while in the process of decommissioning end-of-life appliances or moving up to the cloud.

Do the following:

1. Verify the system specifications on the source and target machines.

   ASMS versions	Ensure that the ASMS version and build installed on both the source and target machines are identical.
   License	Ensure that a valid ASMS license is installed on the target machine. For more details, see Install a license.
   System requirements	Review the specifications on the target machine to ensure compliance. For more details, see System requirements. Additionally, verify how much storage is being used on the /data partition on the source machine. You must have at least the same amount of storage plus another 5% free on the target machine's /data partition.

2. Disable any monitoring or analysis processes any devices managed by the Central Manager. Migration may fail if there are devices currently being monitored or analyzed. For details, see Schedule analysis and Configure real-time monitoring.

3. If you have configured an SSL certificate pass phrase, remove it now (recommended) or copy the ssl pass phrase file.

   To remove the SSL certificate pass phrase:

   1. On the CLI, enter the following script to print the pass phrase:

      echo -e '#!/bin/bash\necho "Enter your SSL Passphrase here"' > /etc/httpd/conf.d/sslpassphrase 

      chmod 700 /etc/httpd/conf.d/sslpassphrase

   2. Configure httpd to use the pass phrase script by entering the following:

      1. Edit /etc/httpd/conf.d/ssl.conf

      2. Change text from:

         SSLPassPhraseDialog builtin

         to:

         SSLPassPhraseDialog exec:/etc/httpd/conf.d/sslpassphrase

   3. Check that httpd starts without having to enter a pass phrase. Enter:

      /etc/init.d/httpd restart

   To copy the SSL certificate pass phrase:

   1. Log in to Source as root user.

      1. Run the commands:

         PASSP=`grep SSLPassPhraseDialog /etc/httpd/conf.d/ssl.conf | grep -v builtin | cut -f2 -d\:` ; chmod a+x $PASSP

         PFILE=`echo ${PASSP##*/}` ; echo $PFILE

      2. Copy the CLI printed output.

         

         In this case, httpd-ssl-pass-dialog.

      3. Run the following replacing the actual Target IP:

         rsync -rtu $PASSP <TARGET_IP>:/usr/libexec/

      4. Enter password when prompted.

   2. Log in to Target as root user and enter the following replacing the string you copied from step 1:

      \cp -rpv /usr/libexec/httpd-ssl-pass-dialog{,.BACKUP_COPY} ; \cp -rpv /usr/libexec/<Copied string from step 1> /usr/libexec/httpd-ssl-pass-dialog

      For Example, if the copied string is <httpd-ssl-pass-dialog>, the command will be:

       \cp -rpv /usr/libexec/httpd-ssl-pass-dialog/usr/libexec/httpd-ssl-pass-dialog

   3. Verification: Restart httpd and ensure httpd starts up:

      service httpd restart

4. Connect to the Central Manager administration interface via SSH and log in as root.

   For details, see Connect to and Utilize the Administration Interface.

5. In the main menu, enter 16 to migrate ASMS units.
6. Enter 1 to migrate a Central Manger.
7. Enter the IP address and root password of the target machine that will host the new Central Manager.

8. The migration tool runs prerequisite checks on the target machine configuration and ASMS versions.

   • If there are reports that are detected that have not yet been synced, we recommend you stop the process now and sync the reports before running the migration process again. This will reduce downtime during the migration. See Sync reports from a peer node.
   • If the prerequisite checks find issues, see Resolve migration prerequisite check issues.

   • If all checks pass, confirm the details by entering y. The migration begins and displays a confirmation message when complete.

9. If you are migrating a system with HA/DR clusters, rebuild your broken clusters. For details, see Build a cluster.

10. Run a manual analysis to create an unscheduled report on all on individual devices, groups, and matrices defined in AFA. See Run a manual AFA analysis.

After migration, the system is configured as follows:

Back to top

Sync reports from a peer node

Reports are pulled from the peer node.

Do the following:

* Reports are synched up to Sept 8 2020 (30 minutes ago) from peer node [node IP] *

Re-run sync reports from [node IP]? (y/n)

1. On the destination node, go to the algosec_conf menu, and enter option 16 - Migrate ASMS units. Enter option 3 -Sync reports from peer node.

2. Enter the IP address and root password of the peer node. Reports are synced to the destination node.

   Warning: Make sure you enter the correct IP for the peer node, otherwise data can be overwritten.

Back to top

Relocate devices

This procedure describes how to relocate devices between nodes in distributed architectures, providing a full Remote Agent migration tool.

For example, you may want to do this while in the process of decommissioning end-of-life appliances or moving up to the cloud.

Relocation is performed in the background without system downtime, and supports the following options:

• From the ASMS Central Manager to Remote Agents.
• From Remote Agents to the ASMS Central Manager.
• Between different Remote Agents.

Relocating a device relocates all device-related data, including reports.

Do the following:

1. Ensure that the ASMS version and build installed on both your source and target machines are identical.

2. On the Central Manager, connect to administration interface via SSH and log in as root.

   For details, see Connect to and Utilize the Administration Interface.

3. In the main menu, enter 16 to migrate ASMS units.

4. Enter 2 to relocate devices between nodes.

5. The detected nodes and their IPs are displayed. Select the following when prompted:

   • The source node, where the devices are currently located.

     When relocating from the Central Manager to a Remote Agent, you must also specify a device group to relocate.

   • The target node, where you want to move the devices.

6. Enter a time limit, in minutes, after which you want the relocation process to time-out if not completed.

   The default value is 0, and leaves no time limit.

7. If prompted, determine whether you want to disable monitoring, scheduled analysis, and log collection for all devices once relocated.

   Tip: We recommend disabling these functions, especially when relocating devices to the Central Manager, to reduce CPU load on the Central Manager machine. For more details, see Default configurations for relocated devices.

8. At the prompt,

   do you want to relocate devices whose connectivity check failed, despite the failure (not recommended)? (y/n) [n]:

   By default, N, devices without connectivity are not relocated. However, by entering Y you can force relocation of devices that are down when needed.

9. Press ENTER to start the relocation process. Relocation is performed in the background and the log file location is displayed.

   Just before the relocation is complete, the system checks the connectivity to the new device. If the check passes, the relocation processes is completed. If the connectivity check fails, the devices remain on the source node.

   Note: If you have relocated management devices and their children, AFA runs an automatic connectivity check on the management device only. For any child, managed devices, manually verify that connectivity is active between ASMS and the device.

   If connectivity is down, edit the device configuration in the AFA Administration area. For details, see Access the DEVICES SETUP page.

10. If device relocation is partially successful because some of the nodes were skipped, re-run the process to relocate the skipped devices.

11. After relocation is complete, edit the device configuration if needed, such as to reconfigure a syslog server or rescheduling analysis, in the AFA Administration area. For details, see Default configurations for relocated devices and Access the DEVICES SETUP page. To change the IP of the Remote Agent to which devices were relocated, see To change the IP address of a Remote Agent.

Default configurations for relocated devices

Relocation configures the system as follows, depending on the relocation you have performed:

From the ASMS Central Manager to Remote Agents	Monitoring, scheduled analysis, and syslog messaging is enabled for all relocated devices.
From Remote Agents to the ASMS Central Manager	Relocated devices are added to a single group on the Central Manager. This group is named after the source Remote Agent, enabling you to relocate the devices again as needed. Note: If you are relocating management devices, such as a Palo Alto Panorama or Juniper Space Security Director, this group includes only the management device names, although both management and managed devices are relocated as configured. Monitoring, scheduled analysis, and syslog messages is disabled for all relocated devices to reduce load on the Central Manager.*
Between different Remote Agents	Monitoring, scheduled analysis, and syslog message is kept unchanged for each relocated device.*
Local syslog configuration	When relocating devices that use a local syslog server, this configuration is also automatically relocated to the target node. No changes are made for external syslog servers.

*Re-enable monitoring, scheduled analysis, and syslog messaging

If monitoring, scheduled analysis, and syslog messages are disabled on your device after relocating, use the enableDevices and enableDevicesOnRemoteAgent APIs to re-enable these again.

Relocate specific devices

If you want to relocate specific devices together, do so by creating a group and then relocating that group via API.

For example, you may want to do this if you have two Remote Agents, each with their own devices.

If the first Remote Agent is being disabled temporarily for maintenance purposes, group its devices to retain the membership details. Then use the relocation API call to relocate that group to the second Remote Agent. When the maintenance is complete, relocate that same group back again to the first Remote Agent.

When creating this group, verify the following:

• Verify that you include only devices that are managed by this same Remote Agent

• Verify that you include any management devices required, such as Palo Alto Panorama or Juniper Space Security Director devices.

  All devices managed by these parent devices are relocated together with their management devices, and do not need to be included in the group.

• Verify that all devices included in the group are accessible from the target machine.

Use the relocation REST API call and the treeNames A name for the device that includes an aggregated string of the device's name and the name of any parent or grandparent devices. This name is not displayed in the UI, and must be returned from the database by API. Since this name includes the tree hierarchy, it's used as the unique system device. Alternate terms: tree name, name, unique name, database name, canonized name parameter to define the name of the group you want to relocate. For more details, see Relocate devices between nodes and Manage groups.

Check Point devices with OPSEC certificates

OPSEC certificates for Check Point devices are generated per IP. Therefore, while most relocations of Check Point devices to new Remote Agents should succeed, you may have unexpected issues. In such cases, regenerate the certificate and re-install the certificate on the device.

For more details, see OPSEC Setup.

Check or cancel relocation process

To check relocation progress or to cancel relocation, note the UUID displayed in the CLI, and use one of the following REST API requests:

• GET device-relocation-controller
• DELETE device-relocation-controller

For each of these API requests, use the UUID as the value for the uuid parameter. For more details, see Check device relocation progress and Cancel device relocation.

Tip: We recommend using the ASMS Swagger API documentation to perform these API requests.

For more details, see ASMS Swagger documentation.

Back to top

Use case scenario: Migrating an entire ASMS system

The following procedure describes a sample process for migrating your entire ASMS system to new appliances.

For example, you may want to do this if you are moving your data centers to a new location or to the cloud, moving to a new set of upgraded appliances, or if you're adding additional appliances to your system.

Click each step in the following image to jump down for more details.

For more details, see also ASMS system architecture.

Back to top

Contact AlgoSec technical support

This procedure describes how to contact AlgoSec support, and the files the send with your support case.

Do the following:

1. Access the Support Home page on the AlgoSec portal.

2. Click Submit a Support Case.

3. Complete the fields and submit the ticket. Make sure to attach any relevant logs to your case.

   Create support logs from ASMS as follows:

   Create AFA support logs

   Do the following:

   1. In AFA, click your username at the top-right, and select Support.
   2. (Optional) In the Support dialog, enable Debug mode if needed, and then reproduce the issue so that the details are logged. In this case, return to the Support dialog again when you're done.

   3. Select either General support file, or the specific item you want to include in your log file.

      If you select any option other than the General support file, define the devices you want to generate the log file for. To add a device to the list, start entering a device name in the text box at the bottom of the dialog, and then select the device from the dropdown list displayed.

   4. Click Generate Files.
   5. Scroll down further to the table of support files. Click the Details link in the File Path column to access the support file you created.
   Create FireFlow support logs

   Do the following:

   1. In FireFlow, click your username at the top-right, and select Support.

   2. (Optional) In the Support dialog, enable Debug mode if needed, and then reproduce the issue so that the details are logged. In this case, return to the Support dialog again when you're done.

   3. Click the Download General Support Zip link to download the file.

   Create a general support log file via CLI

   If your UI is unavailable, generate a general support log file via CLI.

   Access the algosec_conf CLI menu, and enter 18 to collect log files. These will be general system logs and include data for the entire system, and not per device. For more details, see Connect to and Utilize the Administration Interface.

   HA support logs

   Create HA support logs, if the case relates to high availability issues. For more details, see Collect cluster logs for AlgoSec technical support.

Back to top

â See also:

• Manage ASMS issues
• Backup and restore
• ASMS licensing
• Sending outgoing syslog messages