FireSIGHT backup and restore

Before we make a short summer break, let’s do one important step in our Sourcefire saga – backup and restore. This is our lab environment with lots of changes, so it would be nice if we had the option to go back in time, in case we made some sort of configuration error. This step is even more important in production environment.

Before we set up backup on our “Defense Center“, we need to do some preparations. This involves finding some *NIX box in our network and creating a user there, because Sourcefire will save its backups to that server using SCP/SSH protocol. Of course, all backups are first created and stored locally, but in the case we loose the DC, we also lose our backups.

Creating and setting up user account on the Linux box is an easy task:

groupadd sfrbck
useradd -d /files/SFRBCK -g sfrbck sfrbck
mkdir SFRBCK
chown sfrbck:sfrbck /files/SFRBCK/
chmod 770 /files/SFRBCK/
passwd sfrbck

First we created a group called sfrbck. Then we created an user also called sfrbck, made it member of the group we just created and assigned it a home directory of /files/SFRBCK. We then created that directory, took ownership and gave security permissions so that only that user and group can access this folder. Finally we gave this user a password.

Before we proceed, we should make sure that this user is able to log on to this server with SSH and copy some files over it, using SCP protocol.

Although it’s not required, this step can help a lot in case that recover needs to be performed. I usually make a small text file that contains all information I need for the recovery process. This file is then placed along side with backup files on the *NIX server. For example, in case of Sourcefire implementations with one FireSIGHT and two modules, this file could describe all IP addresses, software versions, network diagram, … all that can help rebuild the topology if needed.

Now let’s go to the “Defense Center“. Under “System->Tools->Backup/Restore->Backup Profiles” we click “Create Profile”. Then we fill in the basic information on how this backup will perform:

29-May-2015 8-27-59 AM

We gave this backup a name, select to backup only configuration, set up email notifications, file path on the Linux server and username/password to access this file path location. Copying of backup file to SSH server is optional and only available if the “Copy when complete” check box is checked. We click Save. We have now our backup profile created under “Backup Profiles” and we can edit or delete it.

This backup is going to happen every day at certain time, so we need to create a schedule. This is done by clicking “System->Tools->Scheduling” and clicking the “Add Task” button. An “Edit Task” dialog opens. This is very straight forward to fill in:

29-May-2015 8-33-57 AM

A “Job Type” should be Backup. We click Recurring, so our task repeats itself starting at specified date and time, every this many hours, days, weeks or months. We give this schedule a name of “SFR_CONFIG_BACKUP” and tie it to the backup profile “SFR_CONFIG_BACKUP” we created in previous step. We click Save.

When the task executes, we can verify its status under “System->Tools->Backup/Restore->Backup Management”. Here are all manual or automatic backups created:

29-May-2015 8-39-28 AM

Let’s pay attention to our last backup, squared in blue. We can see its name. If we log in to our Linux box, we should see this very same file and we should receive an e-mail stating that the backup is completed and the file copy is also completed.

By clicking on of completed backups, we can see what files/folders are part of this backup:

29-May-2015 8-43-30 AM

In order to perform the restore, we must upload the backup file from our Linux server to the “Defense Center“. If that file is not already there, that is. If it’s not, under “System->Tools->Backup/Restore” we click “Upload Backup”, browse for backup file which we transferred on our PC from Linux server.

Once our backup file is uploaded, we select it, and click “Restore” button. The Restore option will reboot the “Defense Center“!

In order to demonstrate the restore process, we will delete one of our “Access Control Policy” rules. This is our policy now:

29-May-2015 8-56-39 AM

And after deleting the rule number one and committing changes:

29-May-2015 8-57-53 AM

After our mistake is committed, let’s do a recover process and wait for the DC to reboot. Important thing to note is that our data plane traffic will continue to flow even if the DC is down or rebooting. Our SFR modules will continue to operate and save locally information that will be sent to the DC once it’s back online. We can verify this after restore is completed by not finding any gaps in time in our DC logs.

Once we click Restore, we can see what is going to be restored and we click Restore again:

29-May-2015 9-03-20 AM

If we had virtual DC, we can watch what is going on on the “Virtual Center” virtual machine console. Now we wait …

After the process completes and we log back in, we can verify the status of our job:

29-May-2015 9-09-58 AM

Now we need to re-apply our policies to our SFR modules, because this restore process actually is some sort of change that must be pushed down to modules. We know how to do this 🙂

Finally, let’s check our policy and the rule we deleted:

29-May-2015 9-21-21 AM

Believe me, this is not copy/paste 🙂 of previous screen shot. It is actually a successful restore.


Some final thoughts …

Our backups are stored on some *NIX machine and it would be nice to backup our /files/SFRBCK folder from that machine as an additional safety measure.

Because we will generate 100MB or more files each day, we perhaps should have some sort of cleaning performed on our *NIX server. For example, we could add this line to our crontab facility:

0 0 28 * * find /files/SFRBCK/*SFR_CONFIG_BACKUP_* -mtime +30 -exec rm {} \;

This will trigger every 28th of the month at midnight and delete all backup files older that 30 days. I strongly recommend to test this script line before put it in production. Who knows … 🙂

Please note that the search pattern must contains our backup profile name, because this name is the part of the file name uploaded to our *NIX server. Also note that between {} and \; must be at least one <SPACE> character.


Thanks for reading and see you soon …


This entry was posted in Cisco, FirePOWER, Firewall, IPS, Security, Sourcefire and tagged , , , . Bookmark the permalink.

2 Responses to FireSIGHT backup and restore

  1. Pingback: Cisco Sourcefire 5.3.x to 5.4.x Upgrade | popravak

  2. sandeep says:


    Currenly I have four ASA-5545 firepower module were in production and planning to upgrade those modules. When I am Trying to backup managed devices in defense center, but i did find any device list devices to perform backup.

    Please help me to resolve this issue. Thank you

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s