Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Albin_Petersson
Contributor

is it possible to change settings for how application control works?

Helloes.

 

We have an odd problem that I was hoping someone could shed some light on. The rules below is what is the issue.

2019-05-02 08_20_30-sod-as23613 - sod-as23613 - Remote Desktop Connection.png

 

Normally both these rules are active. We have a web application that is a bit special, so it's not detectable by checkpoint application control. But that's OK, it's allowed in rule 105.13 we thought.

However, it seems that once the application control blade is activated, it stays active for all the rules following? We get the following error on rule 105.13 with the application rule active, and we don't get it when that rule is disabled.

2019-05-02 08_26_07-sod-as23613 - sod-as23613 - Remote Desktop Connection.png

 

Question 1: Can you change the settings for application control somewhere to tune this error?

Question 2: How come application control is activated first when there is a rule with application, and then staying active after that rule?

6 Replies
G_W_Albrecht
Legend
Legend

Albin_Petersson
Contributor

yeah, i saw that one. But is the only way to change settings for application control to turn it of in the kernel? Seems a bit blunt.

Timothy_Hall
Champion
Champion

Unfortunately there is no way to create the equivalent of a TP exception for APCL/URLF-inspected traffic in a case such as this.  Even creating an explicit APCL/URLF rule matching this traffic will result in APCL still trying to classify it, no matter what the action is set to  in that rule.  With ordered layers what you would need to do is construct your APCL/URLF-related rulebase to ensure that the subject traffic "falls off" the end of the APCL/URLF layer and hits the implicit cleanup rule (action Accept) to avoid that inspection completely.  For inline layers, try creating a new http-noinspect service set for port 80, Protocol Signature not checked, and put it in the service of that rule.

Alternatively you could essentially "whitelist" this traffic directly in SecureXL to avoid APCL/URLF and TP for this traffic completely in R80.10, see here: sk139772: SecureXL Fast Accelerator (sim fastaccel) for Non Scalable Platforms 

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Albin_Petersson
Contributor

Alright. Thanks for the explanation. 🙂

 

TP_Master
Employee
Employee

Hi Albin,

This is not an application control action per-se but rather a log that says that while Application Control was working on this connection (inspecting it on the HTTP level) it had an issue with the HTTP response (which was non RFC-compliant).

When you activated the APCL blade you actually made the GW inspect HTTP and therefore you got this error.

 

The solution should be to go to the "Non Compliant HTTP" setting under "Inspection Settings" (you can get there from the Smartconsole policy tab - under "shared policies" there's a shortcut there. Then either change the advanced setttings of this setting or move it to Allow such that it won't Drop non-compliant requests. Just make sure to edit this protection on the settings profile assigned to your gateway.

 

HTH

xsxso
Employee Alumnus
Employee Alumnus

The way to do it in the GUI is per the screenshot below. Please note that the hierarchy is as follows: You can make a new profile > edit its characteristics under General > and then apply it to a Gateway OR you can add an exception to an already existing profile and then apply it to a gateway OR you can add an exception to all profiles in place. The sequence of events as far as the GUI can be a bit confusing here. Do note that in order to apply this you have to install both Threat Prevention and Access Control policies. 

2021-02-09_10-28-36.png

 

 

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events