Whilst doing a SNAT on HTTP, can I insert an X-Forwarded-For header on Cloudguard?
If I am running a load balancer or web proxy upstream from a web server, I tend as a matter of course to write in a X-Forwarded-For header onto the onward call to the server.
With horizontally scaling cloudguard, I need to do a SNAT to maintain the flow back through the forwarding gateway, which is fine, but I lose the original source IP address of the client on the internet. This might mess with my analytics tools.
Anyone done anything similar with cloudguard R80.10? It'd be a good feature to write in a custom header - the receiving server can then parse this and write the true IP of the calling client into the log an make use of whatever analytics it might have.
Not sure I understand your description completely, but just in case, take a look at this and let me know if it is applicable:
Are you accepting HTTPS on proxy/elb and forwarding HTTP through CloudGuard?
Well my requirement is a the other way around - I saw that KB, but it assumes the header is aready present.
Consider the following:
- External client calls into public target address of a web service
- Firewall receives packet, and translates the desintation target address of the target, but also to source address of the client
- Web service receives the packet, but all the traffic appear as if it is coming from internal ip addresses
- Analytics services get confused
Normally you get this kind of problem when using a reverse proxy/ load balancer, and it is overcome by inserting a header into the packet. There for I am looking to add a header on the firewall, not inspect one that already exists.
Hmm... still not a complete picture:
Client calls to public IP.
Public IP associated with what object? I presume it is ELB.
ELB then forwards packet to one of the CloudGuard instances.
At this point, the XFF should still be present.
The CloudGuard instance then NATting the source (or client's IP), and then Desination IP (Why?)
The XFF headers are stripped and the server not seeing those.
If the above description is more or less on the money, take a look at The XFF header (X-Forward-For) is not added to web traffic when Security Gateway is in Transparent M...
and see if you can change the interface topology by using another Internal interface instead of external and assigning "All Internet" object to it.
I guess an option is to have something upstream from the FW (e.g. az app gw : does it my default apparently Frequently asked questions for Azure Application Gateway | Microsoft Docs )- I just like the FW to be the first point of touch on perimeter
The issue I have is with scale sets configuration in cloud based deployments, is the implementation of the scale set appears to rely on a snat from the outside client calling in. I understand this would appear to have an affect of creating a reliable return path from the server for the connection to flow back through the same firewall. I guess state sync on 20 firewalls would be crazy to maintain - so I think i can understand the necessity of it.
So if the server - lets say a web server, gets the call after being filtered and having the snat - it no longer has a means of identifying the actual client IP address. Normally I would do this on a load balancer by creating a rewrite rule and inserting the client ip address into a header - then get apache or nginx or what ever to read it - result: happy developers. Happy developers mean I am more likely to remain in employment
I guess we could do something with elastic parsing syslog to centralise logging on the firewall and the http server, this may also keep them happy.
It'd be sixteen shades of awesomeness if the checkpoint coudl manipulate the http header i.e. write in the xff header as part of the policy.
good link ofirsea040d26-f1f2-3b12-9fc6-5c89debaf56c though - appreciate your help again
First, for the question about custom headers: you can ask form Check Point local team to open RFE for it
(Request For Enhancement)
Second, what about :
About logs: you can review Log Exporter - Check Point Log Export
I think this is a design problem - to make it work we effectively have to remove the external firewall - see second flow diagram after this one (there are some generalisations here but pretty much around about right I think)
Then the more defended setup - the same problem again - our solution is in reality just to remove a firewall - check it out, the webserver ends up with the wrong address, so either a feature request or a consolidation of logging (latter sounds more like it)
It took me a few moments to review it
In case I understood it correctly, the challenge is the count the number of visitors (IPs), right?
There are no utilities that doing it? like: Akamai / Alexa / Azure Analytics/IBM/Google / open source and etc...
I'm using these websites: Homepage | Opensource.com , try this page: Analytics and metrics | Opensource.com Or this one: https://www.predictiveanalyticstoday.com/ , for sure there are many that I'm not familiar.
What about: it's to change the design as you wrote
User source -> external load balancer (Insert XFF) - > reverse proxy (?) <-> External Security Device -> Web Server ?
It seems that NGINX + haproxy does support the XFF headers
For logging: you can use elastic to fetch the logs form the MGMT , ) , and to use Elastic API to do the logic.
You can also leverage SIEM applications: Splunk\Arcsight\RSA\LogRhythm\QRadar\McAfee\rsyslog\ng-syslog and any other SIEM application that can run a syslog agent.
I personally once saw these use cases: AWS re:Invent 2017: Log Analytics at Expedia Using Amazon Elasticsearch Service (ABD331) - YouTube + OpenDev 10.2017 | Logging, security, and analytics on Azure with the Elastic Stack - YouTube
OK just wanted to make sure we are on the same page - my issue relates to the loss of the inbound source ip address with a scale set deployment, as an inbound call to (for example) a web server would have the client ip address snat'ted as it passes throught the fw scale set.
This situation happens to me a lot when using a reverse proxy, and sysadmins moan at me about it as they cannot tell where stuff has come from. I over come this by inserting a xff header (so I actually write one in) so the sysadmin can read the header.
So I did this in the above, with a netscaler, and I get the sysadmin to modify (in this case apache) by modifying the logformat configuration, so it can parse the header - no big deal, done that myself; I am ok with that.
So I need a reliable mechanism to write an xff header into the packet - and as I would normally put a firewall on the edge and a reverse proxy behind; I end up in a situation where the reverse proxy is not the problem any more, the firewall is - as the firewall is removing the clients IP address. It'd be great to get the firewall (cloudgauard) to do this - after all you can write what you want into a header right? e.g.
curl -H "X-Forwarded-For: 127.0.0.1" www.letstotallyconfusetheiranalytics.com
curl -H "Dinner: Fish and Chips" www.letstotallyconfusetheiranalytics.com
NOT that I am suggeting anyone should do the above, and showing as an example only.
Nothing wrong with fish and chips mind you
To try and bring this to a conclusion, I expect I will be doing the following. Certificate management might be challenging, but I get end to end encryption, which is a requirement from our security team. Upshot is the use of a device north of the scaleset that has a capability to insert an XFF - i have used the app gateway in microsoft as this is probably the cheapest option.
Nicholas Sheridan yes this looks like a viable option and we are also being challenged by designing end to end SSL protection for Azure. Question will be how to automate certificate and policy management at scale and what tools to use.
To achieve salable performance, say at 10Gbps of SSL traffic how many gateways in the scale set will be required.. I wonder if anyone in the community had experience with high volumes of traffic...