Welcome …

Posted on

f5 Master Key for RMA and Migration

f5 Master Key Backup and Restore

The f5 master key is used to encrypt and decrypt all that is secure on your f5 appliance including certificate keys, passphrases and UCS configuration files; this is obviously therefore an absolutely vital piece of information in certain situations.

If you have a synchronized cluster then this is not so much of an issue: when you add a new device to the cluster – be that a new member or an RMA replacement for a failed appliance – then the master key will be synchronized as well.

Situations where this can really impact your ability to get back up and running quickly is when you have a standalone appliance or you are transferring config from one machine to another:

Scenario:

  • Standalone appliance fails, monitoring systems go crazy and red lights start blinking everywhere – you call it in and you have a new machine on site in 4 hours (if you bought the right support contract!)
  • You plug it in and give it a management IP and access the GUI
  • Feeling smug because you’ve taken regular backups and stored them offline, you upload your latest UCS archive to restore the configuration
  • Config load fails as it is unable to decrypt the SSL keys passphrases, LDAP profiles passphrases, cookie encryption passphrases etc. etc.
  • You may see the following in the logs: Decryption of the field (field_name) for object (object_name) failed

Resolution:

  • Trawl through the config, edit out the passphrases and re-key most of it from scratch

OR

  • Change the master key to the one from the failed appliance, upload your UCS config and engage ultra-smug mode.

This is very easily done using the “f5 Master Key Utility” and should form part of your backup process for all your f5 appliances:

Backup the Master Key Using f5mku

  • Use the “-K” switch to display the master key and then copy the resulting key securely to an offline vault:
[root@f5] ~ # f5mku -K
7gcOKj3dhFjhr4mFy0AU1p==

Restore the Master Key Uing f5mku

  • Use the “-r” switch to restore the key to your new appliance:
[root@f5] ~ # f5mku -r 7gcOKj3dhFjhr4mFy0AU1p==
Rekeying Master Key...
[root@f5] ~ #
  • Job done! Now you can upload the UCS config archive without needing to worry about decryption failures.

 

Note: f5kmu Options

[root@f5] ~ # f5mku --h
f5mku: invalid option -- -

Usage: f5mku [d:?fhHr:t:uUvYZ]

Commands: (one of these must be specified)
-d bits generate a base64 encoded RSA key and output to stdout
-f fetch unit key
-Z dump debug information
-r key rekey with the specifed master key (b64 encoded)

Options:
-? -h this help
-t # Timeout value in seconds (1-500)
-u Unit test posture (no HAL)
-U Test unit key functionality.
-H Force I/O to HAL storage
-v set verbose mode
-Y Answer Yes to any queries

Log messages (including debug) go to authpriv and local6 facilities.

No related posts.

Posted on

Skybox – Files Needed for Policy Analysis

With Skybox it is possible to analyse the Check Point security policy – the files you need to export from the manager for this are:

The following files are required to import a Check Point FireWall-1 configuration:

  • objects_5_0.C: The network objects file contains objects (including assets, networks, and services) referenced in the access rules.
  • rulebases_5_0.fws: The rulebase file contains the access rules.
  • (Optional) install_statuses.C: The installed statuses file includes the name of the policy (the active policy) that is currently installed in the firewall.
  • (Optional) vsx_objects.C: The VSX device objects file contains objects (including assets, networks, and services) referenced in the access rules of VSX (virtual systems) firewalls.

Note: If the Check Point configuration contains several policies, install_statuses.C is mandatory (it contains the information of which policy is installed on which firewall).

These files are located at:

  • (Windows) C:\WINDOWS\FW1\<version#>\conf
  • (Linux) /<FireWall-1_installation_path>/CPfw1-<version#>/conf

You also need the name of the active policy on each firewall module and the ifconfig and netstat –rnv output from each firewall module.

No related posts.

Posted on

Gaia: Invalid command:’scp -t’ Error

Invalid command:’scp -t /path/to/dir/’

This article explains the cause of the “Invalid command:’scp -t xxxxx'” error and how to solve it.

Background

Researching this error actually brought to my attention two undocumented switches of the scp command: “-f” and “-t”.

These flags are automatically added to the command when it’s run depending on whether you’re copying to (-t) or from (-f):

Command                                                                                                              Actual command run

scp ./myfile.txt   name@server:/myfile.txt               scp -t /myfile.txt

scp  name@server:/myfile.txt  ./myfile.txt               scp -f /myfile.txt

This can be seen when running scp with the -v verbose/debug flag:

linux:/ # scp -v myfile.txt name@server:/home/name/myfile.txt
Executing: program /usr/bin/ssh host server, user admin, command scp -v -t /home/admin/myfile.txt
<snip>
CLINFR0329  Invalid command:'scp -v -t /home/name/myfile.txt'.
linux:/ #

Solution

Besides being of interest regarding the -f and -t flags, the only thing that we can really glean from this is that the remote system doesn’t recognise the command, the flags or both.

In the case of Checkpoint Gaia it is down to the fact that the default shell is “clish” and not bash which is required for scp.

To mitigate this we can set the default login shell to be bash, either temporarily or permanently, using a quick command from clish:

gw-8f991f> set user admin shell /bin/bash
gw-8f991f> save config
gw-8f991f>

To make this change only temporarily, do not use the “save config” command.

To revert the change:

gw-8f991f> set user admin shell /etc/cli.sh
gw-8f991f> save config

Hope you save yourself some time!

No related posts.