Cloudguard Autoscaling Ingress URL Filter

[ramakrishnan]

Dear Folks,

    I have deployed checkpoint Cloudguard in AWS in autoscaling method.

    And I have enabled Application Control and URL filtering blades enabled. Since this Cloudgurad deployment design typically for inbound traffic, how should I check my application control and URL filtering are working or not. In the logs I could  not see only logs. Since cloudguard deployment typically for Inbound connections. Is there any specific setting should I make in order to work? Kindly advise. 

   Basically I just wants a log (because filtering would happen external load balacer(native AWS elb) and see my URLs.

[Chris_Atkinson]

What is the logging level and policy that is configured, is https inspection enabled?

[ramakrishnan]

HTTP Inspection:

Since it's been implemented as cloudguard deployment, so we have ssl off loading carry out by external load balancer, we could see clear http packet in the firewall, with hight custom port not https port(i.e 8080) hence no https inspection involved in checkpoint. By matter of fact, cloudguard autoscaling setup typically for our hosting applications, so potential traffic sare inbound not an outbound. 

Syslog level:

Im new to checkpoint, I could see below syslog settings. 

set syslog filename /var/log/messages
set syslog cplogs off
set syslog mgmtauditlogs on
set syslog auditlog permanent
 

Your quick response much appreciated. 

[Chris_Atkinson]

The policy and logging referred to would be configured within the SmartConsole GUI based application.

Please refer to the "Track" column options: Log / Detailed Log / Extended Log and subsequently "Log Generation": Per Connection or Per Session.

[ramakrishnan]

I could not see Detailed Log / Extended Log, please see the attached scree shot. 

[Chris_Atkinson]

You were oh so close...click on Log and will give you:

[ramakrishnan]

Sorry Wrong attachment I sent. See the attach correct one. I could not see the options. 

But Some how I found the under the policy editor we suppose to add Application control and URL filtering. 

Then we could see the under policy rule "Accept" able see URL filter layer.

However, having mentioned this cloudguard setup for web traffic inbound connections, and ssl offloading happening external lb(application elb) hence url filtering would not kick for inbound traffic. Correct me if im wrong.

If this can be do kindly guide me. 

[ramakrishnan]

My question in short: URL filtering will apply for inbound traffic ? URL filter will apply ONLY for outgoing web traffic ;

Swift answer much appreciated. 

[Chris_Atkinson]

Yes, with the appropriate blades, policy and logging level configured you should have visibility of URLs.

[mdjmcnally]

OK to keep Simple

AppCtrl/URL matches against ALL Traffic both Inbound and Outbound.

The Default Destination in a Rule for AppCtrl/URL was always Internet so couldn't match Inbound Traffic as Inbound Traffic was not the Internet which basically means that Interfaces tagged as External are the Egress.

However if you set a rule at the bottom in R77.30 (bear with me) that was Any, Any, Any Recognised Application, Drop then you would see that Inbound Traffic would drop, unless explicitly permitted by a Rule.

A customer that insisted on this found out the hard way when Check Point added an App for the Remote Access VPN and found that the Remote Access VPN stopped working as was being matched by this rule.

So  AppCtrl/URL does indeed apply to all traffic is just that there is a hidden Any, Any, Accept out of site that would pass this without being logged.

Now regarding your logging settings under track then the only way I can replicate that is if the Policy Layer doesn't have the AppCtrl/URL Blades enabled.

Not talking about the Gateway Object but the Actual Policy Layer.

The extra Log isn't available in R80.x if is just the Firewall/VPN Blade enabled on the Policy Layer.  You need to have those blades enabled at the Policy Layer Level and on the Check Point object itself.

[ramakrishnan]

Thanks for your reply,  happy to here firewall does not look url filter regardless of a direction of traffic(in/out)

but in this  case I have implemented as single arm(interface) so now the question is, how cp determine outbound/inbound traffic? 

Second, However, having said that this auto scaling setup potentially to protect externally hosted applications (predominantly all are Web servers)  so what kind url filter would help us to achieve security, (Since generally URL filter works based on web reputation/categorization and so on) 

Besides, Yes, I will have to enable the App Ctl & URL filter blades(i.e Appl. Ctl and URL filter) in the access policy, then I could see the logs for it. 

As a conclusion, instead enabling URL filter on firewall, better to have enable WAF on loadbalancer, where we get OWAPS top 10 such web vulnerability protection. 

[mdjmcnally]

If you want Protection for Inbound Web Sites then definitely a WAF is a better system then trying to bodge the Check Point to do it.   A WAF is designed to protected hosted Sites behind it ie Inbound as opposed to trying to use the Check Point to do this.

However if as your opening post then just wanted a log then a WAF is overkill.

[ramakrishnan]

> However if as your opening post then just wanted a log then a WAF is overkill.

     Yes, I should have mentioned when I started this post.

     Apparently my customers wants to protect their all out-bound traffic of cloud VM's by URL filters 

     Let's say for example all out bound traffic from cloud VM should be pass thru fw filtering, 

     But this solution wouldn't fit for autoscaling setup; 

      Thanks everyone for your kind and support. 

[mdjmcnally]

Taken from https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Which is the Autoscaling for AWS SK article.

The connections arriving at the Security Gateways have a source IP address belonging to the proxy ELB rather than the web client.
Because the ELB is acting as a TCP proxy and not as an HTTP proxy, no "X-Forwarded-For" HTTP header is present to identify and log the original client.
Instead, the ELB is set up by the CloudFormation Template to add a Proxy Protocol header.
This allows the Security Gateways to log the original client address.

Notes:

• The proxy protocol is only supported in the context of HTTP/S connections as described here.
• At the moment, the original client's IP address can only be logged and cannot be used to enforce access rules in the security policy.

So this would allow Outbound Traffic to be filtered but would be a one size fits all currently in AWS, but would log correctly.