Scrubbing a FTD 2110/2130 backup file for IP addresses

[Eric R. Jones]

We have an issue with our FTD 2110 device complaining about disk usage issues. The device is at 71% capacity and the Readiness check fails it because there's not enough space being detected. I went through solo to find old update files etc... and remove them. After that the alarm went away and the check passed. Fast forward 12 hours later into our planned ASI window and it's failing. I open a TAC case and after a webex it's determined that there is no inode issue and we have exhausted places to look for large files but think it could be a bunch of small files. We're not positive which small files are the culprits so the Engineer spins up a lab and asks us to pass on a recent backup so they can test it. We have to scrub anything that leaves for IP's and passwords etc... I don't believe the passwords are human readable or able to be run through something to break the has and reveal the password, also the engieer assured me they don't need them, but what about IP address?

I've never untar'd a backup to see what's in there until now. alot of lovely dot gz files but where to start and is it doable are my questions?

ej

[Marius Gunnerud]

What version are you running?

I have never had to untar a backup .tar file for FMC/FTD yet, so I am a bit unsure were to start.  But I have seen a ton of these high disk space usage messages.  Did the TAC engineer check the logrotate settings.  in every case I have seen this error is due to the logrotate path being not correct.  Check the path of the following:

sudo cat /ngfw/etc/logrotate-5min.d/pm.logrotate

sudo cat /ngfw/etc/logrotate.size.d

The path / first line in both should be /ngfw/var/log/process_std*.log {

[Eric R. Jones]

sudo cat /ngfw/etc/logrotate-5min.d/pm.logrotate – logrotate-5min.d doesn’t
exist

sudo cat /ngfw/etc/logrotate.size.d – logrotate.size.d is a directory with
various logrotate files including pm.logrotate which contains the line
/ngfw/var/log/process_std*.log {

[Marius Gunnerud]

You are checking this on the FTD2110/2130 and the logrotate-5min.d doesn't exist?

What version of FTD are you running?

[Marvin Rhoads]

Modifying a backup to scrub addresses (even if it were possible) will most likely result in it not being able to be used by TAC to restore. You would have to remove ACP entries, MANY database entries (network discovery data etc.), NAT entries, objects, etc. etc.

Try running this workaround which helps with Geodb files taking up excessive space:

https://community.cisco.com/t5/network-security/increase-cisco-ftd-and-fmc-default-disk-size-in-vmware/m-p/4893971#M1103030

I check for space hogs using the following commands as root superuser (which command depends on the hardware model):

find /ngfw -type f -exec du -Sh {} + | sort -rh | head -n 15

find /var -type f -exec du -Sh {} + | sort -rh | head -n 15

/ngfw/Volume/lib the command is du -sh * (note the space preceding the *).
You can ascertain your mysql directory in use with "which mysql" command.
Safe to delete older versions' directories

[Eric R. Jones]

After I untar'd the file and got a look at what was in there I pretty much gave up. We just uploaded the backup to the case as most of what's in there is in a show tech-support output. I got a webex scheduling coming up over the next couple of days.