This article discusses how to add conditions for devices to the WAN and Internet firewall rulebases for enhanced security and protection.
The Device setting for the WAN and Internet firewall rules gives you the ability to expand the scope of your firewall security policy to include conditional access based on the actual device of the end-user. You can specify the requirements for devices to be allowed to access the network. For example:
-
WAN firewall - Specify the source of the rule to only apply to devices that meet the pre-defined posture or based on geo-location
-
Internet firewall - Define rules for a SaaS application that limits access based on the device settings and location
By default the Device settings do not impact traffic because they are set to are Any Any and automatically match all traffic.
For more information about the Cato WAN and Internet firewall, see the Knowledge Base articles in WAN & Internet Firewalls.
-
Device Posture profiles are supported for the following Cato Clients:
-
Windows Client v5.2 and higher
-
-
Before you can add a Device Profile to the Device settings for a rule:
-
You must create and configure the Device Profile
-
-
Known limitation - Rules that use Device Profiles are only applied when the user is connected with the Cato Client (even if they are located behind a Socket)
These are the Device settings conditions that you can add to a firewall rule:
-
Platforms - Device Operating System (OS)
-
Countries - Source country for the connection based on the physical location of the device (according to the IP address geo-location)
-
Profiles - Device Profiles (configured in Access > Device Posture)
-
Connection Origin - The geolocation of the device (Remote or behind a site)
When you configure multiple conditions for a rule, they have an AND relationship, the rule is matched only if traffic matches the criteria defined in all of the items.
Within a condition (a single cell), the items have an OR relationship. For example, a rule that has the Platforms condition of Windows, and macOS, matches all Windows or macOS devices.
This is an example a rule where the traffic must meet all of these Device conditions: Windows devices, located in India, that meet the requirements of the Test Profile.
The Platforms condition for a firewall rule lets you define the device OS that match the rule. For example, for a specific network segment, only allow access to Windows, macOS, or Linux devices.
The Countries condition lets you define the source of the traffic that matches the rule based on the IP geo-location of the device. For example, restrict access to a site for a branch office, so that only devices that are located in the same country as the office are allowed to connect.
The Profiles condition lets you restrict the rule to only match devices that meet the requirements of the Device Profile. This condition is based on the Device Posture feature, which checks if the device meets the posture requirements. For example, only devices that have the newest Anti-Malware software version meet the posture requirements.
The Device Profiles are currently not supported on all Client versions, for more information see Creating Device Posture Profiles and Device Checks.
The firewall can only determine if a Client matches the Device Check for supported Clients. For each Device Check, you can define the behavior for unsupported Clients that match the other requirements firewall rule (Source, App/Category, and so on):
-
Skip the Device Check, and apply the firewall action to the unsupported Clients
-
Apply the Device Check, and the Client doesn't match the firewall rule and the action isn't applied
The following table explains the behavior for unsupported Clients when the connection matches all the other settings of the firewall rule. The behavior depends on whether the Skip this check for unsupported SDP Client version option is enabled or cleared (disabled) in the Device Check.
|
Unsupported Clients |
Firewall Rule Action |
Client Behavior |
|---|---|---|
|
Skip check (Enabled) |
Block |
Unsupported Clients automatically skip the Device Check and are blocked (they can't connect) |
|
Allow |
Unsupported Clients automatically skip the Device Check and are allowed (they can connect) |
|
|
Apply Check (Disabled) |
Block |
Unsupported Clients fail to match the Device Check, the firewall skips this rule (doesn't apply the block action to the connection) |
|
Allow |
Unsupported Clients fail to match the Device Check, the firewall skips this rule (doesn't apply the allow action to the connection) |
The Device Origin condition lets you define the geo-location device that matches the rule. For example, allow access sensitive information behind a site, but not when working remotely.
You can configure the device settings in a new or existing firewall rule.
To configure the Device conditions for a firewall rule:
-
From the Security section in the navigation pane, select Internet Firewall or WAN Firewall.
-
Click New to create a new rule, or click the Edit icon
in the Device column for an existing rule.
-
In the Device section, configure the Platforms, Countries, and Profiles that are required to match this rule.
-
Click Apply, and then click Save.
The Device conditions are configured for the rule.
This an example of a WAN firewall rule that allows traffic in both directions for all SDP users that match the all of the following Device conditions: using a Windows OS device, physically located in South Korea, and matches the requirements of the Test Policy Device Profile.
This is an example of an Internet firewall rule that is an exception to the rule that blocks the Social category. The exception allows traffic that matches the following Device conditions: using a Windows or macOS device, and physically located in the United States.
4 comments
Hi, I have been trying to configure a WAN FW rule to allow access to an internal resource via RDP for windows devices that meet the following device posture criteria: the microsoft embedded ATP (Defender) is running on the device.
However, when trying to access the resource via RDP it looks like the policy (2) does not get a hit and the user is then blocked by the implicit deny all (5) at the end.
Any help/hints would be appreciated, thanks!
Hello Andrea!
Hard to say really! Are you running the correct version of the Windows client (i.e. above 5.2)?
In the meantime, I will check with colleagues, but if I don't find an answer for you quickly, I will be recommending that you open a Support ticket with us to investigate further. That would be the best way to handle further investigation.
Kind Regards,
Dermot Doran (Cato Networks Community Manager)
thanks for your prompt reply Dermot. I would not want to waste support time and resources, since this is in my Cato Lab. I was just looking for some evident mistakes in my configuration. Not sure why the policy does not get hit...
And yes, I am running client 5.4 on my windows VMs.
Thanks, Andrea.
Understood, Andrea! However, I would like to see if we can get to an answer for you. A Support Ticket would be faster or you could post this to our Community (just started). We have a topic called "How & Why?". That might be a better place to discuss this.
The link to the community should be visible to you at the top of this page, but here is the link anyway!
Please sign in to leave a comment.