FortiSIEM
FortiSIEM provides Security Information and Event Management (SIEM) and User and Entity Behavior Analytics (UEBA)
mbenvenuti
Staff
Staff
Article Id 322853
Description This article describes how to migrate all the data from a FortiSIEM to another machine.
Scope FortiSIEM.
Solution

When there are issues with an initial FortiSIEM machine, the appliance has been replaced because of hardware issues or other reasons, it is necessary to migrate all the data from the original machine to the new one. 

 

Follow the next steps to migrate all the data:

 

  1. Context: Next steps can be applied in the next conditions:
  • From Hardware machine to New Hardware machine.
  • From VM to new VM.
  • From Hardware to new VM and vice-versa.

 

  1. Requirements: Targeted FortiSIEM requires to be in the same:
  • Version (ex: v7.1.4): The use of the same version is recommended but it is also possible to upgrade the database if needed by following the optional steps in the 'Upgrade CMDB version' section.
  • Mode (Enterprise or Service Provider).
  • Online storage has to be EventDB or NFS (when using clickhouse need to go through Clickhouse Backup-Restore ).

 

  1. Building the FortiSIEM target: Install the new FortiSIEM Super and follow all the steps till the FortiSIEM is licensed and running stable.

 

  1. Transferring the data: Here is the list of valuable FortiSIEM data:
  • /cmdb => database where all discovered devices are listed with their credentials, FortiSIEM configuration, and incidents.
  • /svn => devices configurations.
  • /data => devices events received.

 

  1. Restoring the CMDB and SVN: On the original FortiSIEM, take the /data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX file and transfer it to the targeted FortiSIEM on /tmp directory.

 

Example from new (or targeted) FortiSIEM CLI:

 

rsync -az root@ORIGINAL_FortiSIEM_IP:/data/archive/cmdb/phoenixdb_202X-XX-XXTXX-XX-XX /tmp

 

Stop all the services except the database service from the targeted FortiSIEM:

 

systemctl stop phxctl.service

phxctl stop

Stopping phoenix ...
@Fri Jun 28 11:29:27 CEST 2024, Stopping backend process ...
@Fri Jun 28 11:29:53 CEST 2024, Stopping apache ...
@Fri Jun 28 11:29:54 CEST 2024, Stopping phAnomaly master...
Stopping phAnomaly master...
Terminated
@Fri Jun 28 11:29:57 CEST 2024, Stopping phAnomaly worker...
Stopping phAnomaly worker...
Terminated
@Fri Jun 28 11:30:03 CEST 2024, Stopping phGenerativeAI...
Stopping phGenerativeAI...
@Fri Jun 28 11:30:07 CEST 2024, Stopping phClickHouseMonitor...
@Fri Jun 28 11:30:07 CEST 2024, Stopping application server ...
@Fri Jun 28 11:30:32 CEST 2024, Stopping postgres ...
Stop the Api Nodejs Sevice..
Cleaning the Redis for API
Stopping the Redis for API

systemctl start postgresql-13

 

Run the restoration command (this may take some time along the amount of data) :

 

/opt/phoenix/deployment/db_restore.sh /tmp/phoenixdb_202X-XX-XXTXX-XX-XX

Restore database phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX ...

Successfully restored phoenixdb from /tmp/phoenixdb_202X-XX-XXTXX-XX-XX

 

Upgrade the CMDB version (optional steps, follow this only if the FortiSIEM target is on the upper version):

 

tablelist=`psql -U phoenix phoenixdb -At -c "select tablename from pg_catalog.pg_tables where tablename like 'ph_malware_%';" | tr '\n' ',' | sed 's#,$##g'`
psql -U phoenix phoenixdb -c "truncate table $tablelist ;"
psql -U phoenix phoenixdb -c "vacuum $tablelist ;"

threeMonthsAgo=`date -d '-90 day' +"%s000"`
psql -U phoenix phoenixdb -c "delete from ph_incident where last_seen_time < ${threeMonthsAgo}"

sh /opt/phoenix/deployment/db_upgrade.sh /tmp | tee -a /tmp/db_migration.log
...
DB schema is upgraded to new version 7.2.1 successfuly
GRANT
Database is upgraded successfully

rm -rf /opt/phoenix/cache/REPLACE_BY_IP_OF_THE_SUPER /opt/glassfish/domains/domain1/generated/ /opt/glassfish/domains/domain1/osgi-cache/

 

Update the hardware ID:

 

hardware_id=`phgetUUID`
psql -U phoenix phoenixdb -c "update ph_sys_conf set value='$hardware_id' where property = 'hardware_id';"

 

Update the IP address if it is not the same as the original FortiSIEM:

 

new_ip='type_your_new_ip_here'
psql -U phoenix phoenixdb -c "update ph_sys_server set ip_addr='${new_ip}' where mode=2 and ( role is NULL or role = 0 );"
psql -U phoenix phoenixdb -c "update ph_sys_conf set value = 'https://${new_ip}/svn' where property = 'svn_url';"
psql -U phoenix phoenixdb -c "update ph_health_status set host_ip='${new_ip}' where nodetype=0;"

 

Restore SVN:

 

rsync -az root@ORIGINAL_FortiSIEM_IP:/svn/ /svn

 

Reset service and database password:

 

systemctl start phxctl.service

phxctl start

curl -u "super/admin:XXXXXXXX" -XPUT -k https://localhost/phoenix/rest/custMgmt/service/changePwd
phtools --change-svc-passwd force

 

If curl and/or phtools commands are rejecting an 403 error code, upload the license at:  

 

https://super_ip/phoenix/licenseUpload.jsf

 

At this stage, most of the ph services should be running except phRule processes where database password update will fix it with next commands:

 

db_password=`phLicenseTool --showDatabasePassword`

psql -U phoenix phoenixdb -c "alter user phoenix password '$db_password'"

reboot

 

From that moment, FortiSIEM can be used and receive new events.

 

  1. Restoring the EventDB/NFS: After the online storage is configured and mounted, run the next command from the new FortiSIEM super CLI as root to start transferring the events:

 

nohup rsync -az --progress root@ORIGINAL_FortiSIEM_IP:/data/eventdb/ /data/eventdb > /tmp/transfered_files.txt 2>&1 &

 

Follow the transfer with this command:

 

tail -f /tmp/transfered_files.txt