topic Re: Identity Awareness not matching users behind proxy in General Topics

Identity Awareness not matching users behind proxy

David_Herselman — Wed, 12 Sep 2018 21:25:04 GMT

We configured security policy layers to detect users behind proxies:

Some systems use an explicit caching Squid proxy which is configured to send requests to the Check Point security gateway's proxy interface:

acl local-servers dst 10.0.0.0/8 100.64.0.0/10 172.16.0.0/12 192.168.0.0/16

always_direct allow local-servers
always_direct deny all
never_direct deny local-servers
never_direct allow all
cache_peer 100.127.254.1 parent 3128 0 no-query no-digest

Check Point security gateway is configured accordingly:

Users can only browse when we allow unauthenticated access from the Squid proxy's IP address. We temporarily changed the workstation to explicitly use the Check Point security gateway's proxy interface, navigated to https://fwcp1.lair.co.za/connect, authenticated and thereafter changed the proxy settings back to using Squid. Reviewing log entries shows the security gateway correctly identifying the IP of the workstation behind the Squid proxy but the IP is not associated with the authenticated user for that IP:

Re: Identity Awareness not matching users behind proxy

Danny — Wed, 12 Sep 2018 22:37:27 GMT

In my experience using caching proxies these days causes more issues than it solves. Website contents have become so dynamic that caching website contents brings you much less than in the early days of the internet with static websites.

Re: Identity Awareness not matching users behind proxy

PhoneBoy — Wed, 12 Sep 2018 22:38:18 GMT

Did you enable XFF on the gateway as well?

Re: Identity Awareness not matching users behind proxy

David_Herselman — Thu, 13 Sep 2018 07:09:40 GMT

It is indeed:

network group object:

Re: Identity Awareness not matching users behind proxy

David_Herselman — Thu, 13 Sep 2018 07:13:08 GMT

We are based in South Africa and subsequently suffer from 160ms latency to Europe and 270ms latency to the USA. Using caching proxies when deploying Linux systems massively reduces deployment times so we wish to continue using them.

PS: User LAN and WiFi traffic wouldn't be channeled through the caching proxies, which in turn direct their requests via the security gateway's proxy.

Re: Identity Awareness not matching users behind proxy

PhoneBoy — Thu, 13 Sep 2018 16:43:37 GMT

In my right in understanding that the authentication is occurring only with Captive Portal and not with, say, Identity Collector or ADQuery?

I'd also check with a tcpdump the proxy is actually sending the XFF header.

I suspect a TAC case is probably in order also.

Re: Identity Awareness not matching users behind proxy

David_Herselman — Thu, 13 Sep 2018 22:14:04 GMT

Correct, we run Samba AD and still need to write our own ADQuery 'equivalent' to feed authentication events to Identity Awareness using the Identity Web API. We were however pleasantly surprised to discover that captive portal and Kerberos authentication events survive policy installs, unlike AD Query Identity Awareness association events on classic Windows AD environments.

XFF is definitely working, as evident on the sample log entry in the original post where the record contains 'Proxied Source IP 192.168.5.12'.

I'll log a case with TAC, wanted to make sure I wasn't missing something first...

Re: Identity Awareness not matching users behind proxy

PhoneBoy — Thu, 13 Sep 2018 23:44:43 GMT

Wonder if you can hook up Samba to RADIUS Accounting?

I know you can hook up Samba to a RADIUS server for VPN authentication: VPN Single SignOn with Samba AD - SambaWiki

Not sure if that's easier than writing an IDA API connector, but another avenue to consider.

Re: Identity Awareness not matching users behind proxy

David_Herselman — Fri, 14 Sep 2018 04:16:45 GMT

We actually already use FreeRADIUS to authenticate support staff to AD using security group memberships, to return relevant authorisation tokens.

Samba 4.7 and later supports Security Event logging natively (Setting up Audit Logging - SambaWiki), so we could drop our custom patches to send logon/logoff time summaries to the HR department. Legacy laws in South Africa require archaic sign in/out records for the government's worker compensation fund, with hefty penalties on non-compliance...

Anyway, debugging ADQuery a while back showed me how the Security Event logs are processed by SQL-esque queries, so I believe I can write a fairly simple event log Samba event log processor. Just need to investigate whether or not Web API Identity Awareness associations are cleared at policy install, the way ADQuery associations are. If not a boot script could tell the processor to search back for the last hour's events, the same way ADQuery does.

This is getting really off topic but I see great value in implementing WPA2-Enterprise (802.1x) for AD based WiFi authentication using RADIUS, which could then inform Identity Awareness when users connect to WiFi networks instead of replying on captive portal authentication every day.

Time, time, time...

Re: Identity Awareness not matching users behind proxy

David_Herselman — Fri, 21 Sep 2018 11:23:35 GMT

We had another problem whereby application policies were not granting accessing to users when directing traffic via the security gateway proxy service, whilst they worked perfectly when sending requests directly. This most probably has to do with pre-defined applications being set with fixed port associations:

I'll log a feature request for HTTP_proxy and HTTPS_proxy service ports to track the security gateway's custom proxy port setting.

XFF unfortunately still doesn't work when we leave the Check Point security gateway on the default 8080 port assignment and update Squid to forward requests there.

Re: Identity Awareness not matching users behind proxy

PhoneBoy — Fri, 21 Sep 2018 14:37:05 GMT

Can't you just add the custom services?

Or are you saying that doesn't appear to work?

Re: Identity Awareness not matching users behind proxy

David_Herselman — Fri, 21 Sep 2018 15:25:02 GMT

This is locked down by the global policy on the MDS environment. I could clone the policy, change the proxy port and assign it to the relevant domain but it may be preferable to have the proxy port automatically track the associated security gateway's proxy port setting:

Re: Identity Awareness not matching users behind proxy

PhoneBoy — Fri, 21 Sep 2018 15:42:08 GMT

Tracking the gateways explicit proxy port would definitely be an RFE.