Morning … so we had a new layer 7 application rolled out on our network. This application pretty much used http and https POST, GET, packets to communicate and it wasn’t working. This always creates a lovely little finger pointing vacuum which sucks everyone in. Needles to say our engineers were saying ‘we’ are not blocking it’ meaning our firewalls were not blocking any packets transmitted from the sources specified on the ports defined. OK.
Back to the application vendor, round and round we went for hours, testing, tracing, and nadda, we have no evidence to say its being blocked. OK.
It got escalated, standard.
So I wanted to see for my self what was going on, placed a few calls T’d it up with the vendor, and away we went.
My laptop connected locally to domain and network. Installed application. SSH’d to firewall and did tcpdump on interface my traffic would come in on. Booted up wireshark and set to log local interface. Application did its ‘thing’ now this is where I became stumped. Packets flew out my laptop, and never came in firewall interface (or so I thought). After some discussion, I put a call in to a friend as I was under the impression the tcpdump command dumped ALL traffic it saw … apparently not.
Basically the IPS was dropping the non_compliant_HTTP requests despite an IPS exclusion which one of our engineers had setup correctly. This wasn’t displaying in the smart view tracker or a TCP dump I did on the internal interface of the firewall via SSH. The only way I manage to see the packets drop was by doing a top level debug on the firewall via ssh grep’d to my source IP. Which displayed the below
fw-lambeth-1[admin]#
fw-lambeth-1[admin]#
fw-lambeth-1[admin]# fw ctl zdebug + drop | grep 10.10.10.10
Dec 2 10:01:19 fw-lambeth-1 <kern.[LOG_CRIT]> kernel: FW-1: Initializing debugging buffer to size 1023K
;fw_log_drop: Packet proto=6 10.10.10.10:54861 -> 8.8.8.8:80 dropped by fwpslglue_chain Reason: PSL Reject: HTTP_PSL;
;fw_log_drop: Packet proto=6 10.10.10.10:54861 -> 8.8.8.8:80 dropped by fwpslglue_chain Reason: PSL Reject: HTTP_PSL;
^Cfw-lambeth-1[admin]#
NB. IP addresses changed for obvious reasons.
I validated this in a wire shark packet capture and saw the packets so I knew my laptop was sending them at this point I basically just told support provider to go straight to check point and get me the hotfix (I found the one we needed on a KB article) then they sent me the one for Secure OS which I luckily checked before hand through CPVINFO command and hat to wait an hour for Checkpoint in Israel to send the correct one for IPSO (checked it again!) applied.
This whole process took around 24 hours. You can find release notes below.
Release Notes for Hot Fix fw1_wrapper_HOTFIX_FOXX_HF_HA20_480 build 983480002_2 Linux
=====================================================================================
Overview
========
Hotfix should be installed on Gateway
This Hot Fix should be installed over Check Point Security Gateway R75.20 HFA 20
Files updated by this hotfix (Linux):
=====================================
please verify that in the cpvinfo output on the below files you see :
Module Name = fw1
Minor Release = foxx_hf_ha20_480
Build Number = 983480002
/opt/CPsuite-R75.20/fw1/boot/modules/fwmod.2.6.18.cp.i686.o
/opt/CPsuite-R75.20/fw1/boot/modules/fwmod.2.6.18.cp.i686.noPAE.o
/opt/CPsuite-R75.20/fw1/boot/modules/fwmod.2.6.18.i686.o
/opt/CPsuite-R75.20/fw1/boot/modules/fw6mod.2.6.18.cp.i686.o
/opt/CPsuite-R75.20/fw1/boot/modules/fw6mod.2.6.18.cp.i686.noPAE.o
/opt/CPsuite-R75.20/fw1/boot/modules/fw6mod.2.6.18.i686.o
/opt/CPsuite-R75.20/fw1/lib/inspectEngine.2.6.18.cp.i686.o
/opt/CPsuite-R75.20/fw1/lib/inspectEngine.2.6.18.cp.i686.noPAE.o
/opt/CPsuite-R75.20/fw1/lib/inspectEngine.2.6.18.i686.o
To verify that the fix was installed correctly, run ‘cpvinfo’ utility on each of the modified file.
For Example:
# cpvinfo <file_name>
And make sure that the Module Name, Minor Release and Build Number have been changed according to the output above
Bug Fixes:
==========
CR01148828 – Quick UFP cause Block HTTP Non Compliant error when access legitimate websites (google, checkpoint, microsoft…)
CR01149768 – BUG: soft lockup – CPU#0 stuck for 10s!
Hotfix Installation Instructions:
=================================
Please not this firewall is now decommissioned which has allowed me to post this article.
Hope this helps someone
Marc