SPLAT R76 fails to install on VMware ESXi 5

Hi everyone

Just a quick one: I went to install the open-server version of SPLAT R76 today on our ESXi host and ran into an error almost immediately. It was the same anaconda error that is found in CheckPoint sk92354 :

Traceback (most recent call last):
File "/usr/bin/anaconda", line 661, in ?
intf.run(id, dispatch, configFileData)
File "/usr/lib/anaconda/text.py", line 441, in run
rc = apply(win, (self.screen, ) + args)
File "/usr/lib/anaconda/textw/splat_comps_text.py", line 56, in __call__
splatCompProcess("Software Blades", screen, meothod, sc,selectedProductsObj,prodLine)
File "/usr/lib/anaconda/textw/splat_comps_text.py", line 48, in splatCompProcess
while (sc.copyNextFile(CD) == -1):
File "/usr/lib/anaconda/splatcomps.py", line 231, in copyNextFile
ret = self.copyFile(source, dir, dest)
File "/usr/lib/anaconda/splatcomps.py", line 85, in copyFile
os.write(d, count)

Changing the SCSI controller from VMware Paravirtual to LSI Logic SAS allows the system to run through the initial configuration/formatting correctly.

VSX: Policy installation failing due to "Can't open..."

Hi everyone,

Had a new issue happen to me this morning while pushing to an R67 VSLS cluster. During the push, one MVS reported that all of it's configuration files plus those of it's VS were missing.

This output was taken from $CPDIR/log/cpd.elg, however the message within Dashboard was nearly identical:

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/policy/local.dt

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/policy/local.scv

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/policy/local.lp

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/policy/local.cfg

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/CTX/CTX00002/policy/local.dt

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/CTX/CTX00002/policy/local.scv

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/CTX/CTX00002/policy/local.lp

[7 Dec 12:46:04] file_digest: Can't open /opt/CPsuite-V40/fw1/CTX/CTX00002/policy/local.cfg

etc, etc, for all of the VS (13).

Doing a quick 'ls' for any of those files returned no results...

I'm still not sure how the issue occured (and on only one of the three MVS in the cluster), but running this will correct the issue for you by creating the files all at once:

cat $CPDIR/log/cpd.elg | grep "file_digest: Can't open" | awk '{print "touch",$7}' | sh

SPLAT + GAIA : Inaccessible via Console/SSH/GUI

Hi Everyone,

Over the last few months I've seen a large amount of SPLAT appliances become completely inaccessible via "normal" methods (R71->R75). Upon further investigation it seems all of them are suffering from the same problem, however it's quite strange as all three methods use separate authentication schemes.

##It should be noted that *only* CP-branded appliances have been experiencing the issue, open servers seem to be safe from this.

Edit:: Upon further investigation, it appears that all SPLAT and GAIA devices can be affected by this bug.

Doing a debug of an SSH authentication attempt we can see the firewall immediately close the connection via a FIN, without ever presenting the 'reprompt' as if you typed the wrong password:

SSH attempt with the -vv flags:
admin@<firewall_IP>'s password:
debug2: we sent a password packet, wait for reply
Connection closed by <host_IP>

TCPDUMP:

<firewall_IP>.22 > <host_IP>.33506: F 1393:1393(0) ack 1269 win 79 <nop,nop,timestamp 3558805529 352019454> (DF)

After trying multiple ways of "breaking in", we gave up and rebooted one of the devices and attempted to access it via maintenance mode, which was succesful.

Looking at /var/log/messages, we can see faillog is broken in some way:

cp_pam_tally[23237]: /var/log/faillog is either world writable or not a normal file

Looking at the file in detail, we saw that it is completely corrupted (filled with ascii/hex symbols).

Replacing the file with a fresh, empty copy (or simply removing it entirely) corrects the issue.

However, next time /usr/bin/faillog is called to do a rollover, the file becomes corrupted once again, and all access is lost...

To prevent this from happening, I've implemented a 'manual' rollover to prevent faillog from doing it itself via CRON (obviously from maintenance mode after the issue occured):

To create a cron entry:
crontab -e

The editor on SPLAT is still VI(m), so press 'i' to enter input mode, and type:

* * * * * /bin/bash /home/admin/faillog_rollover.sh

This will have crond run the faillog_rollover.sh script every minute, which you can grab here (chmod +x it):

faillog_rollover.sh

Make sure to adjust the path for the script in crontab if you don't place it in /home/admin/

CheckPoint R&D is also aware of the issue and are working on a corrected faillog binary (shadow-utils really), however for the time being this is definitely an easy fix. Until the fixed binary is included in a normal release however, I'd *highly* recommend having this cron job installed on any SPLAT-based Appliance, since fixing the issue once it's occured via maintenance mode isn't the easiest thing to schedule.

Follow Up: CP has released a fixed shadow-utils RPM that addresses the issue, however they have confirmed GAIA is currently susceptible, and that the rollover fix will be incorporated into the next release of GAIA.

Thanks for reading,

Upgrade to R70.50 from R70.30/40 fails due to licensing errors on IPSO

Hi everyone,

It's been awhile since I've posted anything, but tonight I actually experienced something I hadn't seen before, so I figured I should share:

I was in the process of upgrading three separate clusters from R70.30/R70.40 to R70.50 and was presented with this error upon running the UnixInstallScript:

# ./UnixInstallScript

***********************************************************
Welcome to Check Point R70.50 Installation
***********************************************************
In order to install Check Point R70.50 you must first install Check Point R70 Software Blades
For additional information please refer to the release notes.

I checked the licenses and noticed that I was in fact already using Blade Licenses on some clusters, while on one I was still using the old system.

This perplexed me greatly. Upon digging around in /opt I noticed that CPshared was *completely* missing (if anyone knows why this is, please let me know):
# cd /opt
# ls -lah CPshared
ls: CPshared: No such file or directory

Upon realizing that this was the case, I moved to correct the issue (CPshared is just a link to /svn really)
# mkdir CPshared
# cd CPshared
# ln -s /opt/CPsuite-R70/svn 5.0

Once this was complete and I had 5.0 linking to /svn, I tried to run the script once again (with success!):

***********************************************************
Welcome to Check Point R70.50 Installation
***********************************************************
The following components will be installed:
 * R70.50
Installation Application is about to stop all Check Point Processes.
Do you wish to continue (y/n) [y] ?

I've seen a few unanswered posts around the community with the same error, so hopefully this will help someone out :)

Cheers,

TCPDUMP: How to capture a full packet

This request generally comes around when there is some suspicious network activity seen by one of the IDS and the engineer wants to see the entire packet:

tcpdump -nnvvXSs 1514 -i eth0

FWMonitor: How to filter by network range

Pretty simple idea, however wildcards don't work in the generic 'src/dst' statements unfortunately.

Let's say I want to capture all traffic sourced from 192.168.0.0/24 destined to the 10.15.15.0/24 over port 80, I'd use the following syntax:

fw monitor -e "firstblock={<192.168.0.0,192.168.0.255>};secondblock={<10.15.15.0,10.15.15.255>}; accept (src in firstblock, dst in secondblock, sport=80);"

The first IP Block is the starting IP for the network, and the second is the last IP in the block. You can define as many 'groups' as you'd like. Just make sure that the rest of the 'accept' statement ends up between two parent parenthesis.