Fortinet Document Library

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:

Version:


Table of Contents

Important Notes for 6.1.2 or earlier to 6.2.0 Upgrade

  1. For your Supervisor and Worker, do not use the upgrade menu item in configFSM.sh to upgrade from 6.1.x to 6.2.0. This is deprecated, so it will not work. Use the new method as instructed in this guide (See Upgrade Supervisor for your appropriate deployment in ).

  2. The 6.2.0 upgrade will attempt to migrate existing SVN files (stored in /svn) from the old svn format to the new svn-lite format. During this process, it will first export /svn to /opt and then import them back to /svn in the new svn-lite format. If your /svn uses a large amount of disk space, and /opt does not have enough disk space left, then migration will fail. Fortinet recommends doing the following steps before upgrading:

    • Check /svn usage

    • Check if there is enough disk space left in /opt to accommodate /svn

    • Expand /opt by the size of /svn

    • Begin upgrade

      See Steps for Expanding /opt Disk for more information.

  3. If you are using AWS Elasticsearch, then after upgrading to 6.2.0, take the following steps:

    1. Go to ADMIN > Setup > Storage> Online.

    2. Select "ES-type" and re-enter the credential.

  4. In 6.1.x releases, new 5.x collectors could not register to the Supervisor. This restriction has been removed in 6.2.0 so long as the Supervisor is running in non-FIPS mode. However, 5.x collectors are not recommended since CentOS 6 has been declared End of Life.

  5. If you have more than 5 Workers, Fortinet recommends using at least 16 vCPU for the Supervisor and to increase the number of notification threads for RuleMaster (See the sizing guide for more information). To do this, SSH to the Supervisor and take the following steps:

    1. Modify the phoenix_config.txt file, located at /opt/phoenix/config/ with
      #notification will open threads to accept connections
      #FSM upgrade preserves customer changes to the parameter value
      notification_server_thread_num=50

      Note: The default notification_server_thread_num is 20.

    2. Restart phRuleMaster.

  6. Upgrading Elasticsearch Transport Client usage - The Transport Client option has been removed as Elasticsearch no longer supports that client. If you are using Transport Client in pre-6.2.0, you will need to modify the existing URL by adding "http://" or "https://" in front of the URL field after upgrading, as displayed in ADMIN > Setup > Storage > Online > with Elasticsearch selected.

    1. When upgrading to 6.2.0, the Elasticsearch Cluster IP/Host field changes to the URL field. In the URL field, add "http://" or "https://" to your IP address.

    2. Next, select Test to confirm functionality, and select Save to save the updated settings.

  7. Prior to upgrading, ensure that hot node and warm node counts are both greater than the number of replicas. Failure to do so will result in Test and Save operation failure after an upgrade. This basic requirement check has been added for version 6.2.0 and later.

  8. Remember to remove the browser cache after logging on to the 6.2.0 GUI and before doing any operations.

As part of a fix for excessive SSL communication errors between phReportWorker and phReportMaster (Bug 710109) in 6.2.1, the value for count_distinct_precision in the /opt/phoenix/config/phoenix_config.txt file is reduced from 14 to 9 for the Supervisor and Worker nodes. While 6.2.1 fresh install sets the value correctly, 6.2.1 upgrade may keep the old value (14) and fail to set the new value (9). Because of this, you can still have excessive SSL communication errors between phReportWorker and phReportMaster and it may appear that bug 710109 is not fixed.

To fix this issue, follow the instructions in Modification on the Supervisor and Modification on each Worker for your Supervisor and Workers.

Pre-Upgrade Checklist

To perform an upgrade, the following prerequisites must be met.

  1. Carefully consider the known issues, if any, in the Release Notes.

  2. Make sure the Supervisor processes are all up.

  3. Make sure you can login to the FortiSIEM GUI and successfully discover your devices.

  4. Take a snapshot of the running FortiSIEM instance.

  5. Make sure the FortiSIEM license is not expired.

  6. Make sure the Supervisor, Workers and Collectors can connect to the Internet on port 443 to the CentOS OS repositories (os-pkgs-cdn.fortisiem.fortinet.com and os-pkgs.fortisiem.fortinet.com) hosted by Fortinet, to get the latest OS packages. Connectivity can be either directly or via a proxy. For proxy based upgrades, see Upgrade via Proxy. If Internet connectivity is not available, then follow the Offline Upgrade Guide.

  7. Make sure your primary DNS Server on the Supervisor, Workers, and Collectors can reverse lookup its own IP. See the example below. The upgrade process uses this check to make sure DNS is working properly.

    # nslookup 8.8.8.8 8.8.8.8
    8.8.8.8.in-addr.arpa name = dns.google.com

    Do not proceed if the reverse DNS lookup fails on the Supervisor, Worker(s), or Collector(s).
    For more information about DNS servers, see the Reference section.

  8. Upgrade to 6.2.0 requires that the Supervisor and Workers can ping the CentOS image repository os-pkgs-cdn.fortisiem.fortinet.com. If you can ping successfully, then continue with the upgrade. Otherwise, replace line 26 in upgrade.sh as shown here before beginning the upgrade process.

    Replace
    ping_host="os-pkgs-cdn.fortisiem.fortinet.com"

    with
    ping_host=“127.0.0.1”

Upgrade Overview

The general upgrade paths are:

 

Upgrading From Pre-5.3.0

If you are running FortiSIEM that is pre-5.3.0, take the following steps:

  1. Upgrade to 5.4.0 by using the 5.4.0 Upgrade Guide: Single Node Deployment / Cluster Deployment.
  2. Perform a health check to make sure the system has upgraded to 5.4.0 successfully.
  3. If you are running a Software Virtual Appliance, you must migrate to 6.1.1. Since the base OS changed from CentOS 6 to CentOS 8, the steps are platform specific. Use the appropriate 6.1.1 guide and follow the migration instructions.

     

    If you are running a hardware appliance (3500G, 3500F, 2000F, 500F), you must migrate to 6.1.2. Since the base OS changed from CentOS 6 to CentOS 8, the steps are platform specific. Follow the "Migrating from 5.3.x or 5.4.x to 6.1.2" instructions from the appropriate appliance specific documents listed here.
    Note: If you are upgrading from a 2000F, 3500F, or 3500G appliance, make sure to follow the instructions at Fix After Upgrading 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2 after migrating to 6.1.2.

     

  4. Perform a health check to make sure the system is upgraded to 6.1.1 or 6.1.2 successfully.
  5. Upgrade to 6.2.x by following the steps in Upgrading From 6.1.x.

Upgrading From 5.3.x or 5.4.0

Start at step 3 from Upgrading From Pre-5.3.0, and follow the progressive steps.

Note: If you are upgrading from a 2000F, 3500F, or 3500G appliance, make sure to follow the instructions at Fix After Upgrading 2000F, 3500F, or 3500G From 5.3.x or 5.4.0 to 6.1.2 after migrating to 6.1.2.

Upgrading From 6.1.x

Note: Prior to your 6.1.x to 6.2.x upgrade, ensure that the Supervisor, and all Workers, and Collectors are running 6.1.x.

If a proxy is needed for FortiSIEM Supervisor, Worker or Hardware appliances (FSM-2000F, 3500F, and 3500G) to access the Internet, please refer to Upgrade via Proxy before starting.

After completion of your upgrade, follow the appropriate steps in Post Upgrade Health Check.

There are two possible upgrades after upgrading to 6.1.x. Follow the steps for your appropriate FortiSIEM setup for single node deployment or cluster deployment.

Upgrade via Proxy

During upgrade, the FortiSIEM Supervisor, Worker or Hardware appliances (FSM-2000F, 3500F, and 3500G) must be able to communicate with CentOS OS repositories (os-pkgs-cdn.fortisiem.fortinet.com and os-pkgs.fortisiem.fortinet.com) hosted by Fortinet, to get the latest OS packages. Follow these steps to set up this communication via proxy, before initiating the upgrade.

  1. SSH to the node.

  2. Create this file etc/profile.d/proxy.sh with the following content and then save the file.

    PROXY_URL="<proxy-ip-or-hostname>:<proxy-port>"
    export http_proxy="$PROXY_URL"
    export https_proxy="$PROXY_URL"
    export ftp_proxy="$PROXY_URL"
    export no_proxy="127.0.0.1,localhost" 
    
  3. Run source /etc/profile.d/proxy.sh.

  4. Test that you can use the proxy to successfully communicate with the two sites here:
    os-pkgs-cdn.fortisiem.fortinet.com
    os-pkgs.fortisiem.fortinet.com.

  5. Begin the upgrade.

Post Upgrade Health Check

  1. Check Cloud health and Collector health from the FortiSIEM GUI:
    • Versions display correctly.
    • All processes are up and running.
    • Resource usage is within limits.
  2. Check that the Redis passwords match on the Supervisor and Workers:
    • Supervisor: run the command phLicenseTool --showRedisPassword
    • Worker: run the command grep -i auth /opt/node-rest-service/ecosystem.config.js
  3. Check that the database passwords match on the Supervisor and Workers:
    • Supervisor: run the command phLicenseTool --showDatabasePassword
    • Worker: run the command grep Auth_PQ_dbpass /etc/httpd/conf/httpd.conf
  4. Elasticsearch case: check the Elasticsearch health
  5. Check that events are received correctly:
    1. Search All Events in last 10 minutes and make sure there is data.
    2. Search for events from Collector and Agents and make sure there is data. Both old and new collectors and agents must work.
    3. Search for events using CMDB Groups (Windows, Linux, Firewalls, etc.) and make sure there is data.
  6. Make sure there are no SVN authentication errors in CMDB when you click any device name.
  7. Make sure recent Incidents and their triggering events are displayed.

Upgrade Single Node Deployment

Upgrading a single node deployment requires upgrading your supervisor. If you have any collectors, make sure to upgrade your supervisor first before upgrading them.

Upgrade Supervisor

To upgrade your Supervisor, take the following steps.

  1. Make sure Workers are shut down. Collectors can remain up and running.
  2. Login to the Supervisor via SSH.
  3. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  4. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip, then upload it to your Supervisor node under the /opt/upgrade/ folder.
  5. Go to /opt/upgrade.
    cd /opt/upgrade
  6. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  7. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  8. Start the upgrade process by entering the following.
    sh upgrade.sh
  9. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Collectors

To upgrade your Collectors, take the following steps.

Main Upgrade Steps

  1. Login to the Supervisor via SSH as root.

  2. Prepare the Collector upgrade image by running the following command on the Supervisor.

    phSetupCollectorUpgrade.sh /opt/upgrade/FSM_Upgrade_All_6.2.0_build0219.zip <SupervisorFQDN>

    Note: Replace <SupervisorFQDN> with the fully qualified domain name of the Supervisor.

    This is what the output is in shell:

    # phSetupCollectorUpgrade.sh

    Usage: /opt/phoenix/phscripts/bin/phSetupCollectorUpgrade.sh coImageZipPath superFQDN

  3. Go to ADMIN > Health > Collector Health.

  4. Select a Collector.

    1. Download the image by clicking Download Image.

    2. Upgrade the image by clicking Install Image.

  5. Make sure the Collector and all its processes are up.

  6. Repeat steps 3 through 5 for all Collectors.

Upgrade Cluster Deployment

It is critical to review Overview prior to taking the detailed steps to upgrade your FortiSIEM cluster.

Overview

  1. Shut down all Workers.
    • Collectors can be up and running.
  2. Upgrade the Supervisor first, while all Workers are shut down.
  3. After the Supervisor upgrade is complete, verify it is up and running.
  4. Upgrade each Worker individually.
  5. If your online storage is Elasticsearch, take the following steps:
    1. Navigate to ADMIN > Setup > Storage > Online.
    2. Click Test to verify the space.
    3. Click Save to save.
  6. Upgrade each Collector individually.

 

Step 1 prevents the accumulation of Report files when the Supervisor is not available during its upgrade. If these steps are not followed, the Supervisor may not come up after the upgrade because of excessive unprocessed report file accumulation.

 

Note: Both the Supervisor and Workers must be on the same FortiSIEM version, otherwise various software modules may not work properly. However, Collectors can be in an older version, one version older to be exact. These Collectors will work, however they may not have the latest discovery and performance monitoring features offered in the latest Supervisor/Worker versions. FortiSIEM recommends that you upgrade your Collectors as soon as possible. If you have Collectors in your deployment, make sure you have configured an image server to use as a repository for them.

Detailed Steps

Take the following steps to upgrade your FortiSIEM cluster.

  1. Shutdown all Worker nodes.
    # shutdown now
  2. Upgrade your Supervisor using the steps in Upgrade Supervisor. Make sure the Supervisor is running the version you have upgraded to and that all processes are up and running.
    # phshowVersion.sh
    # phstatus
  3. If you are running Elasticsearch, and upgrading from 6.1.x to 6.2.0, then take the following steps, else skip this step and proceed to Step 4.
    1. Navigate to ADMIN >  Storage > Online Elasticsearch.
    2. Verify that the Elasticsearch cluster has enough nodes (each type node >= replica + 1).
    3. Go to ADMIN > Setup > Storage > Online.
    4. Select "ES-type" and re-enter the credential of the Elasticsearch cluster.
    5. Click Test and Save. This important step pushes the latest event attribute definitions to Elasticsearch.
  4. Upgrade each Worker one by one, using the procedure in Upgrade Workers.
  5. Login to the Supervisor and go to ADMIN > Health > Cloud Health to ensure that all Workers and Supervisor have been upgraded to the intended version.
    Note: The Supervisor and Workers must be on the same version.
  6. Upgrade Collectors using the steps in Upgrade Collectors.

Upgrade Supervisor

To upgrade your Supervisor, take the following steps.

  1. Make sure Workers are shut down. Collectors can remain up and running.
  2. Login to the Supervisor via SSH.
  3. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  4. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip, then upload it to your Supervisor node under the /opt/upgrade/ folder.
  5. Go to /opt/upgrade.
    cd /opt/upgrade
  6. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  7. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  8. Start the upgrade process by entering the following.
    sh upgrade.sh
  9. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Workers

To upgrade your Workers, take the following steps for each Worker.

  1. Login to a worker via SSH.
  2. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  3. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip to /opt/upgrade.
  4. Go to /opt/upgrade.
    cd /opt/upgrade
  5. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  6. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  7. Start the upgrade process by entering the following.
    sh upgrade.sh
  8. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Collectors

Main Upgrade Steps

To upgrade your Collectors, take the following steps.

  1. Login to the Supervisor via SSH as root.

  2. Prepare the Collector upgrade image by running the following command on the Supervisor.

    phSetupCollectorUpgrade.sh /opt/upgrade/FSM_Upgrade_All_6.2.0_build0219.zip <SupervisorFQDN>

    Note: Replace <SupervisorFQDN> with the fully qualified domain name of the Supervisor.

    This is what the output is in shell:

    # phSetupCollectorUpgrade.sh

    Usage: /opt/phoenix/phscripts/bin/phSetupCollectorUpgrade.sh coImageZipPath superFQDN

  3. Go to ADMIN > Health > Collector Health.

  4. Select a Collector.

    1. Download the image by clicking Download Image.

    2. Upgrade the image by clicking Install Image.

  5. Make sure the Collector and all its processes are up.

  6. Repeat steps 3 through 5 for all Collectors.

Upgrade Log

The 6.2.0_build0219 Upgrade ansible log file is located here:  /usr/local/upgrade/logs/ansible.log.

Errors can be found at the end of the file.

Migrate Log

The 5.3.x/5.4.x to 6.1.x Migrate ansible log file is located here: /usr/local/migrate/logs/ansible.log.

Errors can be found at the end of the file.

Reference

Steps for Expanding /opt Disk

  1. Go to the Hypervisor and increase the /opt disk by the size of /svn disk

  2. # ssh into the supervisor as root

  3. # lsblk

    NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    ...
    sdb           8:16   0  100G  0 disk            << old size
    ├─sdb1        8:17   0 22.4G  0 part [SWAP]
    └─sdb2        8:18   0 68.9G  0 part /opt
          ...
    
  4. # yum -y install cloud-utils-growpart gdisk

  5. # growpart /dev/sdb 2
    CHANGED: partition=2 start=50782208 old: size=144529408 end=195311616 new: size=473505759 end=524287967

  6. # lsblk

    Changed the size to 250GB for example:
    #lsblk
    NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    ...
    sdb           8:16   0  250G  0 disk            <<< NOTE the new size for the disk in /opt
    ├─sdb1        8:17   0 22.4G  0 part [SWAP]
    └─sdb2        8:18   0 68.9G  0 part /opt
    ...
    

     

  7. # xfs_growfs /dev/sdb2

    meta-data=/dev/sdb2              isize=512    agcount=4, agsize=4516544 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=1, sparse=1, rmapbt=0
             =                       reflink=1
    data     =                       bsize=4096   blocks=18066176, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    log      =internal log           bsize=4096   blocks=8821, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 18066176 to 59188219
    
  8. # df -hz

    Filesystem           Size  Used Avail Use% Mounted on
    ...
    /dev/sdb2            226G  6.1G  220G   3% /  << NOTE the new disk size
    

DNS Information

The DNS servers used are defined in the /etc/resolv.conf file. To obtain the list, run this command:

# cat /etc/resolv.conf

# Generated by NetworkManager

search example.lab

nameserver 8.8.8.8

Next, check that the DNS returns valid pointer records for the defined DNS servers. The upgrade process uses this check to make sure DNS is working properly.

 

Working example:

# nslookup 8.8.8.8 8.8.8.8

8.8.8.8.in-addr.arpa name = dns.google.com

 

Here is an example of a failed DNS reverse lookup, which will result in the FortiSIEM upgrade failing.

# nslookup 172.16.99.254

** server can't find 254.99.16.172.in-addr.arpa: NXDOMAIN

Do not proceed if the reverse DNS lookup fails on the Supervisor, Worker(s), or Collector(s). Either change the DNS to a server where the reverse lookup works, or specify the correct pointer record in the DNS server.

Fix After Upgrading 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2

After upgrading hardware appliances 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2, the swap is reduced from 24GB to 2GB. Note that the upgrade from 6.1.2 to 6.2.x does not have this problem. This will impact performance. To fix this issue, take the following steps.

  1. First, run the following command based on your hardware appliance model.
    For 2000F

    swapon –s /dev/mapper/FSIEM2000F-phx_swap
    For 3500F
    swapon –s /dev/mapper/FSIEM3500F-phx_swap
    For 3500G
    swapon –s /dev/mapper/FSIEM3500G-phx_swap

  2. Add the following line to /etc/fstab for the above swap partition based on your hardware appliance model.
    For 2000F
    /dev/FSIEM2000F/phx_swap /swapfile swap defaults 0 0

    For 3500F
    /dev/FSIEM3500F/phx_swap /swapfile swap defaults 0 0

    For 3500G
    /dev/FSIEM3500G/phx_swap /swapfile swap defaults 0 0

  3. Reboot the hardware appliance.

  4. Run the following command
    swapon --show
    and make sure there are 2 swap partitions mounted instead of just 1, as shown here.

[root@sp5753 ~]# swapon --show
NAME      TYPE      SIZE USED PRIO
/dev/dm-5 partition  30G   0B   -3
/dev/dm-0 partition 2.5G   0B   -2

Important Notes for 6.1.2 or earlier to 6.2.0 Upgrade

  1. For your Supervisor and Worker, do not use the upgrade menu item in configFSM.sh to upgrade from 6.1.x to 6.2.0. This is deprecated, so it will not work. Use the new method as instructed in this guide (See Upgrade Supervisor for your appropriate deployment in ).

  2. The 6.2.0 upgrade will attempt to migrate existing SVN files (stored in /svn) from the old svn format to the new svn-lite format. During this process, it will first export /svn to /opt and then import them back to /svn in the new svn-lite format. If your /svn uses a large amount of disk space, and /opt does not have enough disk space left, then migration will fail. Fortinet recommends doing the following steps before upgrading:

    • Check /svn usage

    • Check if there is enough disk space left in /opt to accommodate /svn

    • Expand /opt by the size of /svn

    • Begin upgrade

      See Steps for Expanding /opt Disk for more information.

  3. If you are using AWS Elasticsearch, then after upgrading to 6.2.0, take the following steps:

    1. Go to ADMIN > Setup > Storage> Online.

    2. Select "ES-type" and re-enter the credential.

  4. In 6.1.x releases, new 5.x collectors could not register to the Supervisor. This restriction has been removed in 6.2.0 so long as the Supervisor is running in non-FIPS mode. However, 5.x collectors are not recommended since CentOS 6 has been declared End of Life.

  5. If you have more than 5 Workers, Fortinet recommends using at least 16 vCPU for the Supervisor and to increase the number of notification threads for RuleMaster (See the sizing guide for more information). To do this, SSH to the Supervisor and take the following steps:

    1. Modify the phoenix_config.txt file, located at /opt/phoenix/config/ with
      #notification will open threads to accept connections
      #FSM upgrade preserves customer changes to the parameter value
      notification_server_thread_num=50

      Note: The default notification_server_thread_num is 20.

    2. Restart phRuleMaster.

  6. Upgrading Elasticsearch Transport Client usage - The Transport Client option has been removed as Elasticsearch no longer supports that client. If you are using Transport Client in pre-6.2.0, you will need to modify the existing URL by adding "http://" or "https://" in front of the URL field after upgrading, as displayed in ADMIN > Setup > Storage > Online > with Elasticsearch selected.

    1. When upgrading to 6.2.0, the Elasticsearch Cluster IP/Host field changes to the URL field. In the URL field, add "http://" or "https://" to your IP address.

    2. Next, select Test to confirm functionality, and select Save to save the updated settings.

  7. Prior to upgrading, ensure that hot node and warm node counts are both greater than the number of replicas. Failure to do so will result in Test and Save operation failure after an upgrade. This basic requirement check has been added for version 6.2.0 and later.

  8. Remember to remove the browser cache after logging on to the 6.2.0 GUI and before doing any operations.

As part of a fix for excessive SSL communication errors between phReportWorker and phReportMaster (Bug 710109) in 6.2.1, the value for count_distinct_precision in the /opt/phoenix/config/phoenix_config.txt file is reduced from 14 to 9 for the Supervisor and Worker nodes. While 6.2.1 fresh install sets the value correctly, 6.2.1 upgrade may keep the old value (14) and fail to set the new value (9). Because of this, you can still have excessive SSL communication errors between phReportWorker and phReportMaster and it may appear that bug 710109 is not fixed.

To fix this issue, follow the instructions in Modification on the Supervisor and Modification on each Worker for your Supervisor and Workers.

Pre-Upgrade Checklist

To perform an upgrade, the following prerequisites must be met.

  1. Carefully consider the known issues, if any, in the Release Notes.

  2. Make sure the Supervisor processes are all up.

  3. Make sure you can login to the FortiSIEM GUI and successfully discover your devices.

  4. Take a snapshot of the running FortiSIEM instance.

  5. Make sure the FortiSIEM license is not expired.

  6. Make sure the Supervisor, Workers and Collectors can connect to the Internet on port 443 to the CentOS OS repositories (os-pkgs-cdn.fortisiem.fortinet.com and os-pkgs.fortisiem.fortinet.com) hosted by Fortinet, to get the latest OS packages. Connectivity can be either directly or via a proxy. For proxy based upgrades, see Upgrade via Proxy. If Internet connectivity is not available, then follow the Offline Upgrade Guide.

  7. Make sure your primary DNS Server on the Supervisor, Workers, and Collectors can reverse lookup its own IP. See the example below. The upgrade process uses this check to make sure DNS is working properly.

    # nslookup 8.8.8.8 8.8.8.8
    8.8.8.8.in-addr.arpa name = dns.google.com

    Do not proceed if the reverse DNS lookup fails on the Supervisor, Worker(s), or Collector(s).
    For more information about DNS servers, see the Reference section.

  8. Upgrade to 6.2.0 requires that the Supervisor and Workers can ping the CentOS image repository os-pkgs-cdn.fortisiem.fortinet.com. If you can ping successfully, then continue with the upgrade. Otherwise, replace line 26 in upgrade.sh as shown here before beginning the upgrade process.

    Replace
    ping_host="os-pkgs-cdn.fortisiem.fortinet.com"

    with
    ping_host=“127.0.0.1”

Upgrade Overview

The general upgrade paths are:

 

Upgrading From Pre-5.3.0

If you are running FortiSIEM that is pre-5.3.0, take the following steps:

  1. Upgrade to 5.4.0 by using the 5.4.0 Upgrade Guide: Single Node Deployment / Cluster Deployment.
  2. Perform a health check to make sure the system has upgraded to 5.4.0 successfully.
  3. If you are running a Software Virtual Appliance, you must migrate to 6.1.1. Since the base OS changed from CentOS 6 to CentOS 8, the steps are platform specific. Use the appropriate 6.1.1 guide and follow the migration instructions.

     

    If you are running a hardware appliance (3500G, 3500F, 2000F, 500F), you must migrate to 6.1.2. Since the base OS changed from CentOS 6 to CentOS 8, the steps are platform specific. Follow the "Migrating from 5.3.x or 5.4.x to 6.1.2" instructions from the appropriate appliance specific documents listed here.
    Note: If you are upgrading from a 2000F, 3500F, or 3500G appliance, make sure to follow the instructions at Fix After Upgrading 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2 after migrating to 6.1.2.

     

  4. Perform a health check to make sure the system is upgraded to 6.1.1 or 6.1.2 successfully.
  5. Upgrade to 6.2.x by following the steps in Upgrading From 6.1.x.

Upgrading From 5.3.x or 5.4.0

Start at step 3 from Upgrading From Pre-5.3.0, and follow the progressive steps.

Note: If you are upgrading from a 2000F, 3500F, or 3500G appliance, make sure to follow the instructions at Fix After Upgrading 2000F, 3500F, or 3500G From 5.3.x or 5.4.0 to 6.1.2 after migrating to 6.1.2.

Upgrading From 6.1.x

Note: Prior to your 6.1.x to 6.2.x upgrade, ensure that the Supervisor, and all Workers, and Collectors are running 6.1.x.

If a proxy is needed for FortiSIEM Supervisor, Worker or Hardware appliances (FSM-2000F, 3500F, and 3500G) to access the Internet, please refer to Upgrade via Proxy before starting.

After completion of your upgrade, follow the appropriate steps in Post Upgrade Health Check.

There are two possible upgrades after upgrading to 6.1.x. Follow the steps for your appropriate FortiSIEM setup for single node deployment or cluster deployment.

Upgrade via Proxy

During upgrade, the FortiSIEM Supervisor, Worker or Hardware appliances (FSM-2000F, 3500F, and 3500G) must be able to communicate with CentOS OS repositories (os-pkgs-cdn.fortisiem.fortinet.com and os-pkgs.fortisiem.fortinet.com) hosted by Fortinet, to get the latest OS packages. Follow these steps to set up this communication via proxy, before initiating the upgrade.

  1. SSH to the node.

  2. Create this file etc/profile.d/proxy.sh with the following content and then save the file.

    PROXY_URL="<proxy-ip-or-hostname>:<proxy-port>"
    export http_proxy="$PROXY_URL"
    export https_proxy="$PROXY_URL"
    export ftp_proxy="$PROXY_URL"
    export no_proxy="127.0.0.1,localhost" 
    
  3. Run source /etc/profile.d/proxy.sh.

  4. Test that you can use the proxy to successfully communicate with the two sites here:
    os-pkgs-cdn.fortisiem.fortinet.com
    os-pkgs.fortisiem.fortinet.com.

  5. Begin the upgrade.

Post Upgrade Health Check

  1. Check Cloud health and Collector health from the FortiSIEM GUI:
    • Versions display correctly.
    • All processes are up and running.
    • Resource usage is within limits.
  2. Check that the Redis passwords match on the Supervisor and Workers:
    • Supervisor: run the command phLicenseTool --showRedisPassword
    • Worker: run the command grep -i auth /opt/node-rest-service/ecosystem.config.js
  3. Check that the database passwords match on the Supervisor and Workers:
    • Supervisor: run the command phLicenseTool --showDatabasePassword
    • Worker: run the command grep Auth_PQ_dbpass /etc/httpd/conf/httpd.conf
  4. Elasticsearch case: check the Elasticsearch health
  5. Check that events are received correctly:
    1. Search All Events in last 10 minutes and make sure there is data.
    2. Search for events from Collector and Agents and make sure there is data. Both old and new collectors and agents must work.
    3. Search for events using CMDB Groups (Windows, Linux, Firewalls, etc.) and make sure there is data.
  6. Make sure there are no SVN authentication errors in CMDB when you click any device name.
  7. Make sure recent Incidents and their triggering events are displayed.

Upgrade Single Node Deployment

Upgrading a single node deployment requires upgrading your supervisor. If you have any collectors, make sure to upgrade your supervisor first before upgrading them.

Upgrade Supervisor

To upgrade your Supervisor, take the following steps.

  1. Make sure Workers are shut down. Collectors can remain up and running.
  2. Login to the Supervisor via SSH.
  3. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  4. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip, then upload it to your Supervisor node under the /opt/upgrade/ folder.
  5. Go to /opt/upgrade.
    cd /opt/upgrade
  6. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  7. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  8. Start the upgrade process by entering the following.
    sh upgrade.sh
  9. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Collectors

To upgrade your Collectors, take the following steps.

Main Upgrade Steps

  1. Login to the Supervisor via SSH as root.

  2. Prepare the Collector upgrade image by running the following command on the Supervisor.

    phSetupCollectorUpgrade.sh /opt/upgrade/FSM_Upgrade_All_6.2.0_build0219.zip <SupervisorFQDN>

    Note: Replace <SupervisorFQDN> with the fully qualified domain name of the Supervisor.

    This is what the output is in shell:

    # phSetupCollectorUpgrade.sh

    Usage: /opt/phoenix/phscripts/bin/phSetupCollectorUpgrade.sh coImageZipPath superFQDN

  3. Go to ADMIN > Health > Collector Health.

  4. Select a Collector.

    1. Download the image by clicking Download Image.

    2. Upgrade the image by clicking Install Image.

  5. Make sure the Collector and all its processes are up.

  6. Repeat steps 3 through 5 for all Collectors.

Upgrade Cluster Deployment

It is critical to review Overview prior to taking the detailed steps to upgrade your FortiSIEM cluster.

Overview

  1. Shut down all Workers.
    • Collectors can be up and running.
  2. Upgrade the Supervisor first, while all Workers are shut down.
  3. After the Supervisor upgrade is complete, verify it is up and running.
  4. Upgrade each Worker individually.
  5. If your online storage is Elasticsearch, take the following steps:
    1. Navigate to ADMIN > Setup > Storage > Online.
    2. Click Test to verify the space.
    3. Click Save to save.
  6. Upgrade each Collector individually.

 

Step 1 prevents the accumulation of Report files when the Supervisor is not available during its upgrade. If these steps are not followed, the Supervisor may not come up after the upgrade because of excessive unprocessed report file accumulation.

 

Note: Both the Supervisor and Workers must be on the same FortiSIEM version, otherwise various software modules may not work properly. However, Collectors can be in an older version, one version older to be exact. These Collectors will work, however they may not have the latest discovery and performance monitoring features offered in the latest Supervisor/Worker versions. FortiSIEM recommends that you upgrade your Collectors as soon as possible. If you have Collectors in your deployment, make sure you have configured an image server to use as a repository for them.

Detailed Steps

Take the following steps to upgrade your FortiSIEM cluster.

  1. Shutdown all Worker nodes.
    # shutdown now
  2. Upgrade your Supervisor using the steps in Upgrade Supervisor. Make sure the Supervisor is running the version you have upgraded to and that all processes are up and running.
    # phshowVersion.sh
    # phstatus
  3. If you are running Elasticsearch, and upgrading from 6.1.x to 6.2.0, then take the following steps, else skip this step and proceed to Step 4.
    1. Navigate to ADMIN >  Storage > Online Elasticsearch.
    2. Verify that the Elasticsearch cluster has enough nodes (each type node >= replica + 1).
    3. Go to ADMIN > Setup > Storage > Online.
    4. Select "ES-type" and re-enter the credential of the Elasticsearch cluster.
    5. Click Test and Save. This important step pushes the latest event attribute definitions to Elasticsearch.
  4. Upgrade each Worker one by one, using the procedure in Upgrade Workers.
  5. Login to the Supervisor and go to ADMIN > Health > Cloud Health to ensure that all Workers and Supervisor have been upgraded to the intended version.
    Note: The Supervisor and Workers must be on the same version.
  6. Upgrade Collectors using the steps in Upgrade Collectors.

Upgrade Supervisor

To upgrade your Supervisor, take the following steps.

  1. Make sure Workers are shut down. Collectors can remain up and running.
  2. Login to the Supervisor via SSH.
  3. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  4. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip, then upload it to your Supervisor node under the /opt/upgrade/ folder.
  5. Go to /opt/upgrade.
    cd /opt/upgrade
  6. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  7. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  8. Start the upgrade process by entering the following.
    sh upgrade.sh
  9. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Workers

To upgrade your Workers, take the following steps for each Worker.

  1. Login to a worker via SSH.
  2. Create the /upgrade directory.
    mkdir -p /opt/upgrade
  3. Download the upgrade zip package FSM_Upgrade_All_6.2.0_build0219.zip to /opt/upgrade.
  4. Go to /opt/upgrade.
    cd /opt/upgrade
  5. Unzip the upgrade zip package.
    unzip FSM_Upgrade_All_6.2.0_build0219.zip
  6. Go to the FSM_Upgrade_All_6.2.0_build0219 directory.
    cd FSM_Upgrade_All_6.2.0_build0219
    1. Run a screen.
      screen -S upgrade

      Note: This is intended for situations where network connectivity is less than favorable. If there is any connection loss, log back into the SSH console and return to the virtual screen by using the following command.
      screen -r

  7. Start the upgrade process by entering the following.
    sh upgrade.sh
  8. After the process is completed, perform a basic health check. All processes should be up and running.

Upgrade Collectors

Main Upgrade Steps

To upgrade your Collectors, take the following steps.

  1. Login to the Supervisor via SSH as root.

  2. Prepare the Collector upgrade image by running the following command on the Supervisor.

    phSetupCollectorUpgrade.sh /opt/upgrade/FSM_Upgrade_All_6.2.0_build0219.zip <SupervisorFQDN>

    Note: Replace <SupervisorFQDN> with the fully qualified domain name of the Supervisor.

    This is what the output is in shell:

    # phSetupCollectorUpgrade.sh

    Usage: /opt/phoenix/phscripts/bin/phSetupCollectorUpgrade.sh coImageZipPath superFQDN

  3. Go to ADMIN > Health > Collector Health.

  4. Select a Collector.

    1. Download the image by clicking Download Image.

    2. Upgrade the image by clicking Install Image.

  5. Make sure the Collector and all its processes are up.

  6. Repeat steps 3 through 5 for all Collectors.

Upgrade Log

The 6.2.0_build0219 Upgrade ansible log file is located here:  /usr/local/upgrade/logs/ansible.log.

Errors can be found at the end of the file.

Migrate Log

The 5.3.x/5.4.x to 6.1.x Migrate ansible log file is located here: /usr/local/migrate/logs/ansible.log.

Errors can be found at the end of the file.

Reference

Steps for Expanding /opt Disk

  1. Go to the Hypervisor and increase the /opt disk by the size of /svn disk

  2. # ssh into the supervisor as root

  3. # lsblk

    NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    ...
    sdb           8:16   0  100G  0 disk            << old size
    ├─sdb1        8:17   0 22.4G  0 part [SWAP]
    └─sdb2        8:18   0 68.9G  0 part /opt
          ...
    
  4. # yum -y install cloud-utils-growpart gdisk

  5. # growpart /dev/sdb 2
    CHANGED: partition=2 start=50782208 old: size=144529408 end=195311616 new: size=473505759 end=524287967

  6. # lsblk

    Changed the size to 250GB for example:
    #lsblk
    NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    ...
    sdb           8:16   0  250G  0 disk            <<< NOTE the new size for the disk in /opt
    ├─sdb1        8:17   0 22.4G  0 part [SWAP]
    └─sdb2        8:18   0 68.9G  0 part /opt
    ...
    

     

  7. # xfs_growfs /dev/sdb2

    meta-data=/dev/sdb2              isize=512    agcount=4, agsize=4516544 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=1, sparse=1, rmapbt=0
             =                       reflink=1
    data     =                       bsize=4096   blocks=18066176, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
    log      =internal log           bsize=4096   blocks=8821, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 18066176 to 59188219
    
  8. # df -hz

    Filesystem           Size  Used Avail Use% Mounted on
    ...
    /dev/sdb2            226G  6.1G  220G   3% /  << NOTE the new disk size
    

DNS Information

The DNS servers used are defined in the /etc/resolv.conf file. To obtain the list, run this command:

# cat /etc/resolv.conf

# Generated by NetworkManager

search example.lab

nameserver 8.8.8.8

Next, check that the DNS returns valid pointer records for the defined DNS servers. The upgrade process uses this check to make sure DNS is working properly.

 

Working example:

# nslookup 8.8.8.8 8.8.8.8

8.8.8.8.in-addr.arpa name = dns.google.com

 

Here is an example of a failed DNS reverse lookup, which will result in the FortiSIEM upgrade failing.

# nslookup 172.16.99.254

** server can't find 254.99.16.172.in-addr.arpa: NXDOMAIN

Do not proceed if the reverse DNS lookup fails on the Supervisor, Worker(s), or Collector(s). Either change the DNS to a server where the reverse lookup works, or specify the correct pointer record in the DNS server.

Fix After Upgrading 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2

After upgrading hardware appliances 2000F, 3500F, or 3500G from 5.3.x or 5.4.0 to 6.1.2, the swap is reduced from 24GB to 2GB. Note that the upgrade from 6.1.2 to 6.2.x does not have this problem. This will impact performance. To fix this issue, take the following steps.

  1. First, run the following command based on your hardware appliance model.
    For 2000F

    swapon –s /dev/mapper/FSIEM2000F-phx_swap
    For 3500F
    swapon –s /dev/mapper/FSIEM3500F-phx_swap
    For 3500G
    swapon –s /dev/mapper/FSIEM3500G-phx_swap

  2. Add the following line to /etc/fstab for the above swap partition based on your hardware appliance model.
    For 2000F
    /dev/FSIEM2000F/phx_swap /swapfile swap defaults 0 0

    For 3500F
    /dev/FSIEM3500F/phx_swap /swapfile swap defaults 0 0

    For 3500G
    /dev/FSIEM3500G/phx_swap /swapfile swap defaults 0 0

  3. Reboot the hardware appliance.

  4. Run the following command
    swapon --show
    and make sure there are 2 swap partitions mounted instead of just 1, as shown here.

[root@sp5753 ~]# swapon --show
NAME      TYPE      SIZE USED PRIO
/dev/dm-5 partition  30G   0B   -3
/dev/dm-0 partition 2.5G   0B   -2