Security

Hello Team,

 

Please find the FortiGate VPN OnGuard Integration Document that has been tested and implemented it works seamlessly and much faster than COA.

 

The workflow would be :

• A user connected the Fortigate VPN on his system
• After which OnGuard sends WebAuth Information to Clearpass.
• Clearpass Evaluates the posture policy and assigns Healthy/Quarantine/Infected postures.
• As an Enforcement action CPPM would do a REST API call to the Fortigte Firewall with the IP address(Inner IP Address) & Posture Token.
• Fortigate Firewall which is already configured with Policies that would look for the posture tokens would take a course of action that would limit access to the VPN users or allow full access to the VPN users.

 

By this, we can place the OnGuard along with Fortigate VPN for performing the compliance check which is much needed.

Note: The prerequisite for this to work is the Devices are to be Domain Joined Machines or should be domain joined ones.

 

-Chaitanya DNSS

Maybe I'm missing something, but there is something broken with that integration: you assume all clients have OnGuard installed and running.

 

If a client connects WITHOUT OnGuard and is assigned an IP address from a previously Healthy client (it can if you use a dynamic IP pool), it will be considered as healthy even though it may be unhealthy/infected.

 

Same for a client that, while healthy, just removes the OnGuard client. It will be considered healthy forever.

 

As far as I know, the dynamic IPs for Fortigate spt will not timeout. So, once you add an IP to "Healthy" spt, it will stay there until you update it to go to another spt. Without OnGuard running, you will never update it, so it will stay healthy forever.

For this integration to work clients are expected to have OnGuard on their Devices(pushed VIA GPO or existing already). Since the devices are GPO managed(Company Owned)  I don’t think users can uninstall the application without admin rights.

In case a client gets an IP that is marked as healthy already in FortiGate, it would undergo a health check again the moment it initiates the connection(change in Connection) and would get the right posture tagged to it.

 

-Chaitanya DNSS

So, you present a security solution that is unreliable and easilly bypasseable. And that also will never support BYOD scenarios...

 

This will work if it you use an initial HTTP enforcement that update the health status on Fortigate when the client connects to, for example, Unknown. Then, OnGuard would update it to the proper posture.

Doesn't seem to work tho ( at least for VPN, that was what I tried). ClearPass never sends the HTTP API call from the authentication radius service to the Fortigate,

Ahh, I don't see this as unreliable as in my earlier mention i stated one of the solution prerequisites is to have OnGuard Installed Users who dont have the OnGuard Installed will not have the posture token updated with the IP, and inturn the access to internal resources are restricted on the Firewall.

 

The use case targetted here to have devices compliant with Company IT Policy are only to be allowed to connect to the VPN(with Full Access).Devies who connect and doesnot have the posture data would be having restricted access. 

 

The HTTP Enforcement happens on the WebAuth not in the Radius request

 

Please feel free to unicast me cdnss@hpe.com to help you on the same

 

-Chaitanya DNSS

So, with your "solution" all I have to do to bypass it is:

 

Bypass 1:

 

- Let's say the policy requires "encryption" or "antivirus" or even removes USB access

- I connect to the network with the PC compliant and running onguard.

- ClearPass will send the info to the Fortigate: IP of PC is Healthy. 

- That information will stay there until a new info is sent by ClearPass. It never expires!

- Now, I'm on PC and disable OnGuard. Either I remove the app, or reinstall the PC, Whatever.

- I reconnect to the network

- The Fortigate will still have the old information saying the PC is healthy (because it never expires).

- I can now connect from a PC without OnGuard, that may no longer be compliant.

 

Bypass 2 - Dynamic IPs:

- Network is set to give dynamic IPs to PCs.

- I connect with PC1. Dhcp gives him IP1.

- Onguard runs. A message is sent to Fortigate saying IP1 => Healthy. Fortigate will keep this info until it receives a new info, that is only sent when Onguard runs.

- PC1 disconnects from the network.

- Now, PC2 connects at a later date and dhcp will give him the same IP1 as PC1.

- PC2 does not have OnGuard, but Fortigate still has the info that IP1 is healthy, because it neves expires.

- PC2 connects without OnGuard or without being compliant.

 

I can replicate both scenarios on my lab, and get into the network with computers not running OnGuard, so I know this happens with your "solution".

 

As an example, if I want to be able to access USB pen drive when OnGuard prevents that, I just connect first with everything running, let ClearPass send the POST to the Fortigate, and then remove OnGuard from the PC and am able to access the USB drive when connected.

 

This would only work if Fortigate had a timeout for the ClearPass info, which it doesn't.

Thank you for the Brief about the Bypass Scenarios. 

 

For the ByPass1: 

Ideally, when the Systems is managed by GPO i don't think user would be able to uninstall the OnGuard if this is the case the original NAC purpose dissolves I meant if your first scenario holds it would dissolve the whole purpose of NAC :)(Even without the Fortigate integration in normal Wired/Wireless Scenario he can do the same ). Willing to make the Device Complaint to IT policy, on the other hand, giving User's Admin permission to uninstall the applications is self-negating. 

 

For ByPass2: 

 As stated earlier the OnGuard functionality is to Detect the Change of state in the Interface and trigger a WebAuth. Now in case, a client gets IP1 & Logs Off.  When Client 2 connects the VPN and assuming that he gets the IP1 itself, our OnGuard would immediately trigger a WebAuth that would be again posted to Fortigate. So here even though the IP is the same OnGuard would trigger a WebAuth and if the device is UnHealthy it will be updated to Fortigate. 

 

-Chaitanya DNSS 

 

Bypass1 :

Not all devices are managed by GPO or domain joined. It's year 2020.

 

Bypass2:

If the new device does not have OnGuard, webauth will never trigger, so posture will never be updated on the fortigate. It will reuse the "binding" on the fortigate of the previous device. So, if the previous device using IP1 was healthy, the new one will be considered healthy even if it does not run OnGuard or even has it installed. Again, the "binding" on the fortigate will never expire and is only updated when the Onguard running on the client runs a health check. If there is no Onguard on the client, or it is disabled, there will be no update and IP1 will keep using the old posture result, even when the client is not the same.

 

This is a broken solution, easily bypassable, that will not work for non-domain joined devices.

This Solution is for only Domain Joined Machines that was mentioned in my earlier posts too.

There are a lot of successful NAC implementations that are done for Wired/Wireless setups  which does include the OnGuard to be installed and if your bypass example applies, NAC will nowhere be successful not only with Aruba go with any Vendor.  The administrator should push the OnGuard application and if the user is able to Uninstall/Disable it there is no point in placing NAC there. So ideally this application that is pushed, the end-user should not have the admin rights and one of the way i see organization implement is using GPO. So with GPO in control, this should work without bypass.

 

-Chaitanya DNSS

 

 

So many rubish...

 

I can enforce OnGuard posture with ClearPass... If user disables it, it will not be able to access. Just enforce the posture to be recent. Done.

Possible with ClearPass and all other NAC solutions.

User removes the agent, posture will not be recent, he is denied acces to the network.

 

This is just not possible with your half assed "solution" that plainly doesn't works properly and is easily bypassed. Because you can't tell the "Fortigate" to remove the binding after the user removes the agent. Also not possible to remove the binding by time. Once OnGuard runs once for the IP, it will stick to that value (say, healthy) forever if user removes OnGuard afterwards.

 

(Oh, and OnGuard also supports guests with dissolvable agents; maybe you also expect guest computers will also to be GPO managed...)

If you are dissatisfied, why don't you open a TAC case so that they can look into your issue specifically?  You are responding to a person who volunteered to answer your question.  You should open a TAC case so that you can have someone assigned who is paid to solve your problem.  If that is still unsuccessful, be sure to drop your Aruba representative an email to let them know why you are dissatisfied.

Hi Joseph,

You are correct.  If I want a solution, I can call TAC.

 

But the solution posted is from a "Presales Technical Consultant, System engineer at Aruba, a Hewlett Packard Enterprise company". That makes me believe this is a Aruba solution, and not just some "random guy working for free".

As a official solution, it is very poor as it doesn't work reliably or securely for the majority of the OnGuard use cases. Guest Access, non-domain joined, VPN computers at home, etc.

 

Adding to that, nothing on the original post referred anything about it only working for Domain Joined machines, leading people to think the solution works for all the scenarios.

 

 

Thank you Ricardo for the inputs. 

I have updated my original post with the pre-requisites and hope that clarifies.

 

 

 

Did you test the solution? In my lab, when the API call adds the user IP to the 'Healthy' or 'Infected' group during a check in that IP only stays there as long as the session is active. As soon as i disconnect from the VPN, the FortiGate cleans up the IP from the dynamic object. This works across multiple devices and sessions. As soon as the firewall sees the session for the VPN user is gone, it removes the IP address from the object. The caveat that i found is that VPN session and the dynamic ClearPass object have to be in the same VDOM.

Your complaint applies to the traditional API integration to push an IP into a group, but using this 'dynamic ClearPass' object in FortiGate seems to clear it up.

Tested with CPPM 6.10.2 and FortiGate 7.0.3

------------------------------
eliasz zurawka
------------------------------

Original Message:
Sent: Jun 23, 2020 07:44 AM
From: Ricardo Duarte
Subject: OnGuard VPN(Posture) -FortiGate Firewall Integration

Hi Joseph,

You are correct.  If I want a solution, I can call TAC.

 

But the solution posted is from a "Presales Technical Consultant, System engineer at Aruba, a Hewlett Packard Enterprise company". That makes me believe this is a Aruba solution, and not just some "random guy working for free".

As a official solution, it is very poor as it doesn't work reliably or securely for the majority of the OnGuard use cases. Guest Access, non-domain joined, VPN computers at home, etc.

 

Adding to that, nothing on the original post referred anything about it only working for Domain Joined machines, leading people to think the solution works for all the scenarios.

 

 

Hello Chaitanya, how do I get this when create context server

Original Message:
Sent: May 25, 2020 02:05 AM
From: Chaitanya DNSS
Subject: OnGuard VPN(Posture) -FortiGate Firewall Integration

Hello Team,

 

Please find the FortiGate VPN OnGuard Integration Document that has been tested and implemented it works seamlessly and much faster than COA.

 

The workflow would be :

• A user connected the Fortigate VPN on his system
• After which OnGuard sends WebAuth Information to Clearpass.
• Clearpass Evaluates the posture policy and assigns Healthy/Quarantine/Infected postures.
• As an Enforcement action CPPM would do a REST API call to the Fortigte Firewall with the IP address(Inner IP Address) & Posture Token.
• Fortigate Firewall which is already configured with Policies that would look for the posture tokens would take a course of action that would limit access to the VPN users or allow full access to the VPN users.

 

By this, we can place the OnGuard along with Fortigate VPN for performing the compliance check which is much needed.

Note: The prerequisite for this to work is the Devices are to be Domain Joined Machines or should be domain joined ones.

 

-Chaitanya DNSS