Searching for IPS protections via ssh

[the_rock]

Hey guys,

Figured would share this in case anyone encounters the same problem. So had issue with customer where certain parts of sites on Azure were not coming up when testing from on prem and we ran debug and discovered it was related to IPS, but had hard time finding out the protection in question. So I saw there is a command you can runvia expert mode if you have xeha-decimal value for protection (which we did from the drops) and once we got the protection name, was easy to fix the problem.

[Expert@quantum-firewall:0]# ips

Usage:
ips stat # Display IPS status
ips on|off # Enable\Disable IPS
ips bypass stat # Display Bypass Under Load status
ips bypass on|off # Enable\Disable bypass mode
ips bypass set cpu|mem low|high <th> # Set bypass thresholds
ips debug [-e filter] -o <outfile> # Get IPS debugs
ips refreshcap # Refresh the sample capture repository
ips stats [<ip_address> -m] [-g <seconds>] [<ip_address> <seconds>] [-h]
# Print IPS performance and PM statistics
ips protection <protection_id (hex)> # Display protection name

Note: IPS CLI configuration is temporary - it will be overridden by the next
policy installation or boot
[Expert@quantum-firewall:0]# ips protection 0x82e5656a
Web Servers Malicious URL Directory Traversal
[Expert@quantum-firewall:0]#

I would say since we saw lots of errors first packet isnt SYN and customer proved this worked fine when NOT traversing the CP cluster, I would say, if you ever see that message, always check threat prevention blades, specially IPS, apart from obvious "culprits"...routing, NAT, sxl : - )

Cheers,

Andy

[the_rock]

Btw, these are drops from zdebug.

To add this as a side note, no matter what words we used to search for IPS protection in smart console, absolutely nothing worked and we were unable to find the actual protection.

@;436822375;[vs_0];[tid_1];[fw4_1];ips_cmi_handler_match_cb_ex: Packet dir 0, 19 2.168.37.190:63474 -> 10.30.11.17:80 IPP 6 dropped by IPS [reject] , protection_ id=0x82e5656a, protection_name=<GW CLI: ips protection 0x82e5656a>;
@;436822377;[vs_0];[tid_1];[fw4_1];fw_log_drop_ex: Packet proto=6 192.168.37.190 :63474 -> 10.30.11.17:80 dropped by fwmultik_process_f2p_cookie_inner Reason: PS L Drop: WS
@;436822379;[vs_0];[tid_1];[fw4_1];fw_log_drop_ex: Packet proto=6 192.168.37.190 :63474 -> 10.30.11.17:80 dropped by fwmultik_process_f2p_cookie_inner Reason: PS L Drop: WS
@;436822442;[vs_0];[tid_1];[fw4_1];ips_cmi_handler_match_cb_ex: Packet dir 0, 19 2.168.37.190:63424 -> 10.30.11.17:80 IPP 6 dropped by IPS [reject] , protection_ id=0x82e5656a, protection_name=<GW CLI: ips protection 0x82e5656a>;

[G_W_Albrecht]

I can find it:

Has even been updated recently...

[the_rock]

Well, you can find it when I gave full name lol. If you search by the actual words from the debug I attached, you will NOT find it : - )

Andy

[G_W_Albrecht]

Yes, therefore i use the most important part only...

[the_rock]

Right and to GET to most important part you need the command : - )

[G_W_Albrecht]

But the command will not be helpfull if you cannot find the protection 😎

[the_rock]

So answer this then...based on debug I posted, and ONLY debug, how would you ever figure out what is the IPS protection if you dont run command I gave? 🙂

[madu1]

Thanks for the info @the_rock .  I had exactly the same issue today; zdebug gave a hex code which doesn't show up when you search in the protections in SmartConsole.  The CLI command told me the protection name, then I found it in SmartConsole using the name.

Interestingly also, these drops did not appear in the logs in SmartConsole, so at first I didn't even think I had an IPS issue until I'd done the zdebug.  Not the first time the logs alone don't tell the full story.  Or any of the story!

[the_rock]

Glad it helped you.

Andy

[PhoneBoy]

The issue about lack of logging a specific IPS protection should probably be raised with TAC: https://help.checkpoint.com 

[PhoneBoy]

Great tip!

[the_rock]

Figured would share since I learned this myself today as well : - )

[Timothy_Hall]

Very nice, thanks for sharing.

[the_rock]

No worries, any time. I asked my colleague to share this link with TAC engineer, hopefully it saves them some time if they ever encounter this with another customer.

Cheers.

[Timothy_Hall]

Forgot to mention that it is possible to make the offending IPS signature name show up directly in the fw ctl zdebug drop output by changing variable enable_inspect_debug_compilation from false to true in GUIdbedit, although doing so will substantially increase the size of the compiled policy sent to the gateway: sk60395: How to debug IPS during issues with DCE-RPC traffic. 

I haven't done this in quite some time and it may no longer be supported.

[the_rock]

Ah, good to know.