yurisk.info

The best place to hide something is to place it before your eyes. Thanks to theacademypro.com I discovered a cool feature of the SmartDashboard – ability to print rules directly from the Dashboard , you just go to File -> Print -> Rule Base.. and that’s it. Just amazing , I have been using Dashboards  throughout these years hundreds of times and never noticed it. Seems like you have to learn all your life to just return to the place you started from .
Happy New Year All!

Backing up firewall configs for disaster recovery  is tedious and mundane task. And if you have enough firewalls doing it manually becomes impractical . To address this case I set up a highly secured server that periodically runs script backing up the clients’ firewalls.

I use here poll model – this central server connects by SSH to the remote firewalls ,issues upgrade_export command then downloads backup using SCP and finally deletes the backup from the firewall itself.
Advantage of such a schema as opposed to the push model where firewalls push backups to the central server I see in that:
 - I can secure this server much more as no remotely accessible services are running (so no remote exploit is possible)
 - I can have rule in firewall before this server Inbound – > Deny Any Any
 - I centrally manage the backup script , if something changes I fix just one script .
Disadvantage – password to enter the firewalls is stored clear text in the script.
Now to the script – I did it in Expect to make life easier , in short it just emulates interactive login by SSH, then runs upgrade_export command, downloads by SCP the backup file, also creating file with md5sum of the backup and downloading it as well. The final action is to login by SSH back and remove the backup file from the firewall.
Naming it does by adding current date to the IP of the firewall. No error checking is done.
 
Files used in script:
hosts  – file containing IPs of the firewalls to backup in the form <IP of firewall> one per line .

The script goes next (at the end you can download script as file to fix lines wrapping):

Script as a file

Checkpoint firewalls have 2 means of  transferring files in/out – ftp (only out) and SCP (in/out) .

At some stage of the debug/upgrade process you will have to move files in either direction. The most secure and the only one allowing to also upload files to the firewall is SCP protocol. On windows platforms picking the GUI SCP client is not hard – you only have WinSCP as your choice. And being otherwise  reliable and easy to use software it just doesn’t work with Checkpoint many times.  To fix this is easier than you can think of.

But first few prerequisites:

  To allow SCP connection to the firewall you have to :

       – create file named /etc/scpusers

       – add to it user per line – with which user you will be connecting for SCP session

       – make sure that for this user(s) shell is set to /bin/bash in /etc/passwd file

       – and of course allow SSH protocol connection from your host to the firewall.

After all the above done you connect using WinSCP, all goes well, try to download some file and …

Error happens…
The easiest way (and the only one I found so far ) is to .. NOT use WinSCP but instead use wonderful
software PSCP from Putty authour that doesn’t have GUI but works flawlessly with Checkpoint.
Download it here www.chiark.greenend.org.uk/~sgtatham , read instructions and have no regrets ever after.

Log is knowledge (of who did what) and knowledge is power. All modern Operating Sytems today provide extensive logging facilities, and Linux on which Checkpoint products are based is no exception.
Checkpoint have own logging capabilities where logs are enabled in Security rulebase. And that’s fine, but SSHD daemon also has  logging and rotating feature which by default is limited to retain only last 4 logfiles.
I found it very useful to have ssh access logs for a longer period, especially when client also has access to the firewall and does changes on his/her own.
To tune parameters of the SSH logging edit /etc/cpshell/log_rotation.conf (no need to restart anything) :

# cat /etc/cpshell/log_rotation.conf
# File    max  size    backlog
# By default max size is 65536 bytes and backlog (how many files to rtain) is 4, I usually change it to the values before:
/var/log/messages 65536 256
/var/log/routing_messages 64536 256
/var/log/wtmp 65536 256
/var/log/lastlog 262400 256
/var/log/secure 64536 256
$CPDIR/log/cpstart.log 1048576 4
# Files after this line will not be shown by log command
/var/log/CPbackup.elg 64536 4
/var/CPbackup/log/backup_logs.elg 64536 4
$FWDIR/log/fwd.elg 1048576 4
$FWDIR/log/dtlsd.elg 1048576 4

< CUT here —————————– >

This is a quick reference sheet of all usable options for the fw monitor tool .
The previous experience with the tool is assumed, i’ll just say that if you are serious about debugging Checkpoint products learn it and learn it well.
By default the fw monitor sniffing driver is inserted into the 4 locations on
the Firewall kernel chain .

Here they are:

 i (PREIN) – inbound direction before firewall Virtual
Machine (VM, and it is CP terminology) . Most important fact to know about that
is that this packet capturing location shows packets BEFORE any security rule
in the policy is applied. That is, no matter what rules say a packet should at
least be seen here, this would prove that packets actually reach the firewall
at all.
 I (POSTIN) – inbound direction after firewall VM.
 o (PREOUT) – outbound direction before firewall VM,
 O (POSTOUT) – outbound direction after firewall VM.

You can change point of insertion within the fw chain with :

# fw monitor –p<i|I|O|o> <where to
insert>

easiest way to specify where to insert is to first see the chain:
# fw ctl chain
then give relative to any module you see there <+|->module_name

Now the usage itself:
# fw monitor
Usage: fw monitor [- u|s] [-i] [-d] [-T] <{-e
expression}+|-f <filter-file|->> [-l len] [-m mask] [-x offset[,len]]
[-o <file>] <[-pi pos] [-pI pos] [-po pos] [-pO pos] | -p all [-a
]> [-ci count] [-co count]

Round up of options:

-m mask , which point of capture is to be displayed, possible: i,I,o,O
-d/-D debug output from fw monitor itself, not very useful IMO.
-u|s print also connection/session Universal ID
- i after writing each packet flush stdout
-T add timestamp, not interesting
-e expr expression to filter the packets (in detail later)
-f filter_file the same as above but read expression from file
-l <len> packet length to capture

Expressions
On the very low level fw monitor understands byte offsets from the header
start. So to specify for example 20th byte of the IP packet (that is source IP)
you can just use:

# fw monitor -e ‘accept [12,b]=8.8.8.8;’

Where:
12 – offset in bytes from the beginning of the packet
b – mandatory, means big endian order.
4 – not seen here but size (in bytes) of how many bytes to look for from the
starting offset (default is 4 )

To look for source port 53 (UDP/TCP) in raw packet:

# fw monitor -m i -e ‘accept [20:2,b]=53;’
Here I say to fw monitor to look at 2 bytes at offset 20.

While this way of looking at packets is the most general and therefore includes
all cases, you rarely have the need for such a granular looking glass. In 99%
of the cases you will be doing alright with a limited known set of expressions.
Just for that Checkpoint defined and kindly provided us in every Splat
installation with definition files that give meaningful synonyms to the most
used patterns. There are few definition files but they circularly reference
each other providing multiple synonyms for the same pattern.
I put all those predefined patterns in the list below for the easy to use
reference.

and – logical AND
or – logical OR
not - logical NOT
> MORE than
< LESS than
>= MORE than or EQUAL to
<= LESS than or EQUAL to
You can combine logical expressions and influence order by using ()

Below is laundry list of examples to showcase the reference table above.

Resources:
decock.org/ginspect Online fw monitor/tcpdump expressions constructor
PDF version of this article