Fortinet black logo

Post-Upgrade Tasks

Post-Upgrade Tasks

Change in the default behavior of the On Create, On Update, and On Delete playbooks for MSSP configurations

Prior to version 7.4.2, for modules that had multi-tenancy enabled and configured for data replication, the On Create, On Update, and On Delete playbooks executed on both the instances where the record is created as well as on the instance where the record is replicated. From release 7.4.2 onwards, the default behavior of the On Create, On Update, and On Delete playbooks is to run only on the instance where the record is created.

If you want to retain the previous behavior for these playbooks, i.e., run the On Create, On Update, and On Delete playbooks on both the source and the replicated instance of the record, then do the following:

  1. Open the parameters_prod.yaml file:
    vi /opt/cyops-api/config/parameters_prod.yaml
  2. Change the value of the execute_workflow_on_replicate_node parameter to true. By default, this parameter is set to false.
  3. Run the following command:
    systemctl restart php-fpm && sudo -u nginx php /opt/cyops-api/bin/console cache:clear && systemctl restart php-fpm
Note

These steps change the default behavior of playbooks to run on both the source and replicated instances of the record instead of only the source instance. However, you can update this behavior to run either on the instance where the record is created or where it is replicated by opening the playbook that contains the On Create, On Update, or On Delete step and selecting the appropriate option. The behavior selected on the UI takes preference over the default behavior. For information on updating the behavior from the UI, see the 'Distributed Tenancy Support' chapter in the Multi-tenancy Support in FortiSOAR guide.

Restart the cyops-integrations-agent service on the tenant nodes for multi-tenant configurations

Considering that data communication between the tenant node to the master node is stopped prior to an upgrade of a FortiSOAR distributed multi-tenancy configuration, post-upgrade of both your master and tenant nodes from a release prior to 7.4.2 to release 7.4.2 or later, you must restart the cyops-integrations-agent service on the tenant nodes using the following command:
systemctl restart cyops-integrations-agent
You must restart the cyops-integrations-agent service at tenant nodes before you download the agent's or tenant's logs, from the master node's console.

Update the config.ini file to prevent the Jinja Editor from traversing paths

FortiSOAR playbooks create or edit operations allow path traversal, giving authorized attackers access to sensitive system files. Perform the following actions after the upgrade to make sure that this does not happen:

  1. SSH to your FortiSOAR VM and login as a root user.
  2. Edit the config.ini file:
    vi /opt/cyops-workflow/sealab/sealab/config.ini
  3. Add the following parameter in the [application] section of the config.ini file:
    DISALLOWED_JINJA_FILTERS = ['readfile']
  4. Restart the 'uwsgi' service using the following command:
    systemctl restart uwsgi

Post-Upgrade Tasks

Change in the default behavior of the On Create, On Update, and On Delete playbooks for MSSP configurations

Prior to version 7.4.2, for modules that had multi-tenancy enabled and configured for data replication, the On Create, On Update, and On Delete playbooks executed on both the instances where the record is created as well as on the instance where the record is replicated. From release 7.4.2 onwards, the default behavior of the On Create, On Update, and On Delete playbooks is to run only on the instance where the record is created.

If you want to retain the previous behavior for these playbooks, i.e., run the On Create, On Update, and On Delete playbooks on both the source and the replicated instance of the record, then do the following:

  1. Open the parameters_prod.yaml file:
    vi /opt/cyops-api/config/parameters_prod.yaml
  2. Change the value of the execute_workflow_on_replicate_node parameter to true. By default, this parameter is set to false.
  3. Run the following command:
    systemctl restart php-fpm && sudo -u nginx php /opt/cyops-api/bin/console cache:clear && systemctl restart php-fpm
Note

These steps change the default behavior of playbooks to run on both the source and replicated instances of the record instead of only the source instance. However, you can update this behavior to run either on the instance where the record is created or where it is replicated by opening the playbook that contains the On Create, On Update, or On Delete step and selecting the appropriate option. The behavior selected on the UI takes preference over the default behavior. For information on updating the behavior from the UI, see the 'Distributed Tenancy Support' chapter in the Multi-tenancy Support in FortiSOAR guide.

Restart the cyops-integrations-agent service on the tenant nodes for multi-tenant configurations

Considering that data communication between the tenant node to the master node is stopped prior to an upgrade of a FortiSOAR distributed multi-tenancy configuration, post-upgrade of both your master and tenant nodes from a release prior to 7.4.2 to release 7.4.2 or later, you must restart the cyops-integrations-agent service on the tenant nodes using the following command:
systemctl restart cyops-integrations-agent
You must restart the cyops-integrations-agent service at tenant nodes before you download the agent's or tenant's logs, from the master node's console.

Update the config.ini file to prevent the Jinja Editor from traversing paths

FortiSOAR playbooks create or edit operations allow path traversal, giving authorized attackers access to sensitive system files. Perform the following actions after the upgrade to make sure that this does not happen:

  1. SSH to your FortiSOAR VM and login as a root user.
  2. Edit the config.ini file:
    vi /opt/cyops-workflow/sealab/sealab/config.ini
  3. Add the following parameter in the [application] section of the config.ini file:
    DISALLOWED_JINJA_FILTERS = ['readfile']
  4. Restart the 'uwsgi' service using the following command:
    systemctl restart uwsgi