General system maintenance

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

Note: For Best Practices for Ongoing Maintenance in ASMS, see Best Practices for Ongoing Maintenance in ASMS.

Reboot the appliance

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

Note: Perform a graceful shutdown and restart of the ASMS services to prevent unexpected behavior. For details, see ASMS graceful shutdown and startup in AlgoPedia.

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.

Install ASMS on a repurposed AlgoSec hardware appliance

This procedure describes how to repurpose an AlgoSec hardware appliance with A33.00 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

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.

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.

Note: Migration can be performed only from the Central Manager that is being migrated.

Additionally, if you are working with HA clusters, this procedure breaks those clusters. Rebuild them when the migration is complete.

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.

  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:

Source machine

We recommend that you do not use the source machine after migrating without resetting it to factory settings.

Therefore, all services on the source machine are disabled.

For more details, see Install ASMS on a repurposed AlgoSec hardware appliance .

Remote Agents

Remote Agents connected to the Central Manager will be automatically reconnected to the new Central Manager.

Sync reports from a peer node

Reports are pulled from the peer node.

Important: You can only sync reports from one peer. If you try to sync from more than one, data will be overwritten.

Do the following:

Note: If you are syncing reports as part of a migration process, the destination node is your target node, and the peer node is your source node).

Tip: If you have previously synced reports, the system prompts you to re-run reports:

* 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)

Enter n to select another node IP, or press CTRL+D to abort.

  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.

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.

Important: If you are relocating devices from a Central Manager to a Remote Agent, ensure that your devices are collected together in a device group in AFA. When relocating devices from a Central Manager, you must relocate a group, even if you are only relocating a single device. The group being relocated should include only top-level devices. For more details, see Manage groups.

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.

Important: When relocating a Check Point PV1/MDS that has an MLM log server configured, the MLM log server must be manually relocated. It is not automatically relocated.

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.

Tip: Migrating an entire ASMS system is a complicated process. If you are migrating a complex deployment with Remote Agents across geographic locations, consider that the migration may required a few days.

In such cases, consider performing each Remote Agent migration and device relocation in incremental steps.

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

Step Procedures

1. Start by migrating your Central Manager. Run through the entire migration and verify that everything works as expected when done.

For details, see:

2. Migrate Load Units by removing the existing units and adding new ones.

For details, see:

3. Relocate devices as needed from legacy Remote Agents to new Remote Agents.

When you're done, remove the legacy Remote Agents from your system.

For details, see:

4. Run sanity checks again to ensure that ASMS is running again as expected. For details, see System sanity checks.

For more details, see also ASMS system architecture.

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:

 

â See also: