corrupted objects database - missing secure client groups

[speculatrix]

We've got a problem with our NGX-R60 checkpoint smart console... when we fire it up we see a sequence of pop-up boxes thus:

rule 41 - cannot locate object XYZ-Secureclient@Any
rule 42 - cannot locate object XYZ-Secureclient@Any
rule 43 - cannot locate object XYZ-Secureclient@Any
rule 0 - cannot locate object XYZ-Secureclient@Any
rule 1 - cannot locate object XYZ-Secureclient@Any
rule 3 - cannot locate object ABC-RBSusers@Any
rule 5 - cannot locate object ABC-Secureclient@Any


eventually smartdashboard opens and if I go to "manage->users & administrators" the list is nearly empty.

the good & bad news is that our replica management console which used the checkpoint automatic replication has been updating for some time - logged on and it reports that there was a collision some time ago and it stopped. This means we have copies of the rulesets and objects for reference from an uncorrupted database, the bad news is that they're all out of date.

the previous firewall admins didn't use the DB version control, they merely saved policies with new names, so we don't have anything worthwhile in the version control system. in fact, the first time it had been used was last week when someone came back from checkpoint training and said we ought to be using it, so we did, and I am wondering if this led to the corruption? The same admins never installed a proper backup system either so backups we have are very sporadic.

any ideas at all for recovering the data would be gratefully received.

[abusharif]

try using dbexport via CLI so you can dump users/groups into the text format and then maybe recreate the users from that information.

[speculatrix]

thanks for coming back to me so quickly.

I've searched for dbexport.exe, db.exe and export.exe but cannot find such a program... I am wondering if you are using some abbreviation or "shortcut" name that me as a non-expert wouldn't understand?

thanks again for your time

[speculatrix]

aha, I found upgrade_export.exe and upgrade_import.exe, so I am trying those out.

[abusharif]

ahh sorry if i wasnt clear enough..

i was thinking of fwm dbexport -f /var/myusers.txt

upgrade_export / import are used only to take backup and restore of complete checkpoint configuration. If you have faulty items in it, they will hunt you arround.


Anyway, I've had similar problems with users and groups and in my case it helped only by creating new group (with another name) and adding users to it and then just deleting old group. Think this is documented somewhere on checkpoint knowledgebase and it involves dbexport as describe above to "find the source of your problem". Guess someone will fill out, or i'll check that in the afternoon and post it.

[speculatrix]

thanks for that. I have been exploring the file system and looking for the file which contains the users... interestingly, it seems that CP keeps a sequence of copies of the file fwauth.NDB with sequential numbers appended.

we are too scared to start copying and replacing files on this box, so what we're going to do is clone it (it's a compaq DL380) and then treat it as a forensic science project to find out if we can roll back some of the file versions, and then if it works do it to the live box!

[speculatrix]

well, good news. another department had Acronis backup/clone utility, so we got hold of another DL380 and cloned the entire system onto it (Acronis, you're magic, I highly commend you!!)

We then looked for "fwauth.ndb*" across all disks and found that there were loads of such files. We then played around a lot, and noticed in one particular directory (\windows\f1\r60\fw1\conf) there was an fwauth.ndbbkp, and fwauth.ndb354.

Along the way we renamed the ndb354 to ndb354_, and took a copy of ndbbkp and called it fwauth.ndb354. You have to stop the firewall service in the services control panel before doing this.

This worked, so we wiped the clone, restored it from the acronis image, and did the minimum fix, and everything seemed ok... including the revision database system.

We then applied this fix to our live management console and it worked!

However, trying to use the revision system then broke the rule base and it wouldn't display rules, but luckily reverting to the just-saved revision made it work. So, we will have to go back to the old procedure (dating back to the guys who started here with CP v4.1) of simply saving policies with a date-stamp name.

Note that if you do this, you do so at your own risk. Also, when we invoked our support contract with our vendor, asking about all these numbered fwauth.ndb files and could we fix our dashboard through hacking files, they didn't say we could - got no advice about it (they said to restore from backup), so this is either unknown to Checkpoint or at least totally unapproved hacking!