In my former post, I've been introducing briefly the Fortinet Secure Web Gateway product named FortiProxy or FPX. This post extends a bit my discoveries and testing's. I'll also intent to showcase some FortiIsolator (FIS) integration example and how both Fortinet products can interact, thus providing Browser Isolation at the FPX SWG Policy level.
First, if you're running Windows, you'd might be interested into this tool; called ProxyCap here https://www.proxycap.com/. This will let you test different proxies towards different process, say an implicit rule for everything on the standard FPX web-proxy while for example firefox.exe would be routed through the SOCKS5 proxy running on a different port on the same FPX SWG. I thought this was a really handy tool for testing's and validating different proxy configuration.
Another tool which showed useful is the autoproxy.exe proxy.pac results tester. You can use this executable to check your current proxy.pac returns according to tested entries; for example:
autoprox -u:https://ghost.reverside.ch -p:c:\temp\proxy.pac
Searching proxy for url : https://ghost.reverside.ch
Searching proxy using file : c:\temp\proxy.pac
The Winsock 2.2 dll was found okay
Calling InternetInitializeAutoProxyDll with c:\temp\proxy.pac
Calling InternetGetProxyInfo for url https://ghost.reverside.ch and host ghost.reverside.ch
Proxy returned for url https://ghost.reverside.ch is:
DIRECTNow let's check how I've setup my Web Proxy on the FPX appliance:
As seen above, I'm using the TCP:8080 for both HTTP/HTTPS proxy requests. A SOCKS5 proxy is running on TCP:1080, I've made this so in order to possibly control who has access to the different proxying methods at the FortiGate level. Our last setting of interest here is the Proxy Auto Config (PAC) port, set here on TCP:8089.
This would allow me to create none authenticated FortiGate policies toward the PAC port, so that any not yet authenticated endpoint/user could retrieve the proxy.pac file and according to the proxy.pac contents and endpoint traffic, trigger a FORM based Captive Portal authentication. Obviously, Kerberos would provide a transparent authentication method although, I have a personal preference towards hard timed Captive Portal human-based authentications schemes.
A view from my current FortiGate rules set, granting connectivity towards the FPX SWG Appliance as well as outbound connectivity once authenticated:
The FPX DNS server will only resolve local domains as well as some browsers hard coded captive portals destinations. The proxy.pac on TCP:8089 access is granted without authentication. Once the pac file content is retrieved and processed by the host, a very few direct connections are granted, like for example the locally hijacked; detectportal.firefox.com.
Direct connection which will trigger the FortiGate Captive Portal authentication (Last policy shown above). The Auths flow from FGT to FAC+AD using RADIUS and RADIUS Accounting is then used to inject the authenticated users within FSSO, effectively detecting users sign-ons and sign-offs from incoming RADIUS accounting (Start, Stop, and Interim-Update) records.
The nice thing about this is that the users can be traced within any given vDOMs and you can therefore use FSSO groups bindings within your FortiGate & FortiProxy SWG policies, as by the time you made a successful authentication, the FPX SWG will already have the FSSO user logon and group(s) information, hence traffic will flow normally and transparently.
As an example of what type of rules you'll be able to create, here is a view of an Isolation rule. That rule will isolate matching traffic through FortiIsolator, providing Browser Isolation at the FortiProxy policy level upon successfully authentified users (the RADIUS groups serves as a backup authentication method):
Indeed, Newly Observed Domains, Unrated Domains and the Hacking (for demo purposes) FortiGuard Web Filtering categories will match this rule thus being offloaded/processed by the FortiIsolator appliance, here is a hitting example of this:
As shown above, we can see a complete Browser Isolation on this page. Using FortiIsolator, web content is executed in a remote disposable container and displayed to users visually, isolating potential threat.
The FPX | FIS integration couldn't be easier:
Currently, the final goal of my setup is to completely remove any default gateway from any back-end FortiGate Virtual Domains. Thus forcing any outbound connectivity through the FPX appliance and/or under complete local routing control. Goal which will make a post of it's own...
Of course, there are always some culprits, or say badly coded apps that doesn't act nicely upon controlled proxied connectivity. That's where ProxyCap can help. Though recent breaches showed us clearly that anything that doesn't comply simply shouldn't execute, if Cybersecurity is of a concern of course.
That's it on this one, in the hope you've found something meaningful in here. Happy 2021!
Obuno