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.

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!

Captive Portal Fails to Load Properly or Returns 404

Captive Portal Fails to Load Properly or Returns 404

This article describes how to fix the issue whereby captive portal fails to load, is returned only partially without the user / pass fields or returns a 404 error. This also mitigates issues with:slow access to a Mobile Access gateway on wireless or lossy networks.

The mechanism responsible for the problems is “SACK” – an acronym for Selective ACKknowledgment. The “SACK-permitted” option and “SACK” option alter the acknowledgment behavior of TCP:

SACK-permitted

The SACK-permitted option is offered to the remote end during TCP setup as an option to an opening SYN packet. The SACK option permits selective acknowledgment of permitted data. The default TCP acknowledgment behavior is to acknowledge the highest sequence number of in-order bytes. This default behavior is prone to cause unnecessary retransmission of data, which can exacerbate a congestion condition that may have been the cause of the original packet loss.

A packet capture on the client or gateway will typically show many retransmitted packets and ends with the client eventually sending RST packets to the gateway.

SACK

The SACK option allows the receiver to modify the acknowledgment field to describe noncontinuous blocks of received data, so that the sender can retransmit only what is missing at the receiver’s end.

Solution

Disable Selective-ACK by setting the value of cpas_tcp_do_sack kernel parameter to “0” (zero).

Procedure:

To Disable Selective-ACK on-the-fly, run:

[Expert@gateway]# fw ctl set int cpas_tcp_do_sack 0

Check that the value was accepted:

[Expert@gateway]# fw ctl get int cpas_tcp_do_sack

To disable the parameter permanently:

Edit the $FWDIR/boot/modules/fwkern.conf file using Vi editor to add a line with the format “parameter_name=value", in this case:

cpas_tcp_do_sack=0

Reboot the gateway after any changes to the $FWDIR/boot/modules/fwkern.conf file.

Notes:

  • Disabling Selective-ACK can impact networking throughput when client/server are using large TCP Windows and there is packet loss between these hosts.
  • In Cluster, perform the procedure on all cluster members.
Exit mobile version
%%footer%%