Block access on HIP check failure - how?

[darren_g]

hey.

I've recently been handed an increased priority on making sure that our VPN connections block clients from accessing internal resources on HIP check failure.

I know I can;t just make the tunnel disconnect - but can someone point me to a how-to or doc for configuring the firewall to disallow traffic while the connection is up if the HIP check fails?

Our HIP checks aren't complex - look for a valid anti-virus package which has up to date signatures and check for updates to a reasonable level - and they work (I can see the results), but I can't for the life of me figure out how to block access if they FAIL.

Thanks for any pointers.

[BPry]

@darren_g,

I would create a new hip-profiles entry that matches the inverse of what you're currently checking. As an example, if I was trying to have a profile that matched devices running GlobalProtect agents that I didn't want to support I would have something like this:

               <entry name="Non-Supported-Agent">
                <match>not ("Supported-GlobalProtect-Agent" or "Supported-Beta-GlobalProtect")</match>
              </entry>

As you can see above what I'm saying is that this "Non-Supported-Agent" hip-profile should be matched if the device does not match my "Supported-GlobalProtect-Agent" or "Supported-Beta-GlobalProtect" profiles. Any hip-profile can use existing hip-profiles as matching criteria, and here I'm just saying that this particular profile is what I'm going to match on if you aren't running an agent that I've specified. 

Then you would use that hip-profile as matching criteria in a deny security rulebase entry. I'd personally recommend checking your HIP logs to ensure that you've built out this profile properly before enabling the rule. That would look something like this though:

                <entry name="NSA Detection Drop">
                  <from>
                    <member>BYOD-GlobalProtect</member>
                  </from>
                  <source>
                    <member>BYOD-GlobalProtect</member>
                  </source>
                  <to>
                    <member>any</member>
                  </to>
                  <destination>
                    <member>any</member>
                  </destination>
                  <application>
                    <member>any</member>
                  </application>
                  <service>
                    <member>any</member>
                  </service>
                  <action>deny</action>
                  <log-end>yes</log-end>
                  <log-setting>Email-Alerts</log-setting>
                  <description>Drop NSA agents from accessing resources</description>
                  <group-tag>DENY</group-tag>
                  <tag>
                    <member>DENY</member>
                  </tag>
                  <profile-setting>
                    <group>
                      <member>Default-Protection-Profile</member>
                    </group>
                  </profile-setting>
                  <source-hip>
                    <member>Non-Supported-Agent</member>
                  </source-hip>
                </entry>

Hopefully this gives you the building blocks to build out what you would want to run personally. Personally I would also ensure that you have a hip-notification setup to notify the user that you're dropping their traffic and any remediation steps that they may need to take. 

You can also utilize the API alongside custom reports heavily when you start doing stuff like this as well. As an example we have a script that monitors for anyone matching this HIP profile to send a Slack alert to our helpdesk staff so they're aware of the issue if the user calls, in addition to sending the user an email that includes more information than what we would fit in the HIP message.

Depending on exactly what you have specified you quite possibly will need to build out multiple profiles and multiple rules and hip-notifications to account for everything. 

[darren_g]

Thanks for your reply

The HIP profiles isn't where I'm beating my head against a brick wall - it's applying it to the security policy.

I can't figure out where to tell the security policy to check for the HIP policy match/failure. I'm happy with the HIP profile I've got - but getting the portal/security policy to restrict based on match or failure is doing my head in.

I'm afraid I have to admit I'm not real good at reading the raw XML you've posted either. Back to Google I go, I guess.

Thanks for replying.