NSO is a fantastic tool for multi-vendor firewall rules management. I guess this is no surprise for anyone who is familiar with the internal machinery of the tool.
With NSO 4.4, one new feature was added to allow much easier firewall rules management using NSO templates and I want to discuss this point in this article.
Why is firewall rules managing complicated?
The main issue has to do with ordering. Basically, a firewall rule is a list of complex objects where a number of restrictions are imposed regarding the order of its elements.
Additionally, the elements that make the rule are typically from different service instances and many times from different service types. One example could be your firewall rules towards the Internet. Some rules are added by instance1 of type service1 but some from instance123 from service2, etc. etc. We will call this requirement "multi-tenancy".
One aspect that is very hard about firewall rule management is to perform compliance reporting. All the different service instances that are part of a firewall rule list have their life-cycle activities (creation, modifications or deletions) but the restrictions for the order on the rule lists need to be preserved all the time. Moreover, the security compliance team needs to receive a report of compliance from the system at anytime.
Managing firewall rules, the NSO way:
NSO service manager and FASTMAP algorithms allow you "off the shelf" to support "multi-tenancy" and compliance reporting. However, the most important feature in this space is that NSO allows you to be extremely precise on how you wish to manage the order of your firewall rules.
It all starts with standard YANG. When we look at RFC7950 and how YANG can manage order in lists, we need to study the "ordered-by" statement (section 7.7.7 ) that can take two values:
- "ordered-by system": This is the default behavior for a list. It basically means that NSO will choose the list order. In NSO case, it will use the "natural" order for the lists keys. This option means that the user does not have any control on thus is typically not adequate for firewall rule management.
- "ordered-by user": In this case, the order in the list is 100% managed by the user. This will be the option when working with list of firewall rules.
I am going to use for example a Checkpoint device. If we look at the NSO checkpoint NED, we can find the definition of the list of access-rules as an "ordered-by user" list:
// access-layer * / access-rule *
list access-rule {
ordered-by user;
key name;
leaf name {
type string;
}
uses access-rule;
}
As an "ordered-by user" list, I can use the NSO CLI command "move" to organize the list in any way that I see fit: admin@ncs% move devices device checkpoint-lab config checkpoint-gaiaos_rest:access-layer new_test access-rule SERVICE_testnew
Possible completions: after before first last
If we chose one option: admin@ncs% move devices device checkpoint-lab config checkpoint-gaiaos_rest:access-layer new_test access-rule SERVICE_testnew first [ok][2017-03-27 11:49:29]
[edit] admin@ncs%
What we will see is that the NSO NED will use the device API to configure the new order. In this case, Checkpoint provides us a "position" statement that we can match accordingly ("top" = "first"):
admin@ncs% commit dry-run outformat native
native {
device {
name checkpoint-lab
data POST https://10.147.46.109:443/web_api/delete-access-rule
{
"name" : "SERVICE_testnew",
"layer" : "new_test"
}
POST https://10.147.46.109:443/web_api/add-access-rule
{
"comments": "",
"service": "SERVICE_SRV_GROUP_testnew",
"name": "SERVICE_testnew",
"destination": "Any",
"action": "Drop",
"position": "top",
"source": "SERVICE_GROUP_testnew",
"custom-fields": {
"field-1": "",
"field-2": "",
"field-3": ""
},
"track": "None",
"layer": "new_test",
"enabled": true
}
}
}
[ok][2017-03-27 11:49:45]
[edit]
admin@ncs%
The use of these "move" options are also available when writing a NSO service, particularly in a service template. Particularly, if I want to insert new rules always on top of the access-rule list, I can use: <access-rule insert="first">
Or if I want new rules to be created before the final "Cleanup Rule" (deny any any): <access-rule insert="before" value="Cleanup Rule">
NSO Guard for "ordered-by user" lists, a new NSO 4.4 feature:
All the features that we have seen so far were native NSO features for a long time. However, in order to address all the restrictions in firewall rule management, they were not enough.
Imagine the example above, where a service template has the following insert request:
<access-layer xmlns="http://tail-f.com/ned/checkpoint-gaiaos_rest">
<name>My layer</name>
<access-rule insert="first">
<name>SERVICE_{/name}</name>
<source>
<name>SERVICE_GROUP_{/name}</name>
</source>
<destination>
<name>Any</name>
</destination>
<service>
<name>SERVICE_SRV_GROUP_{/name}</name>
</service>
</access-rule>
</access-layer>
So, when the add the first instance, a rule will be added on top of access-rule list. However, when you add the second service instance, the initial rule will be moved to the second place in order to give space to the new first rule. At the end of the day, there is only one possible rule (at any given time) to the top position. This means that there is only one service instance that will be "in-sync".
In reality, the firewall rule requirement is not that a given rule is always in the same position but that it remains in a "zone" delimited by some specific rules. In our case, we do not really cases where the rule is as long as it is always before the "Cleanup rule" that will deny all the traffic.
The guard feature in NSO 4.4. allows us to express these requirements in a simple way:
<access-rule insert="first" guard="Cleanup\ rule">
This template configuration should be interpreted as:
- if the rule does not exist, it should be created in the first position of the list.
- if the rule already exists, it should always be located between the first position and the "Cleanup rule".
Using this new feature, multiple service instances that control the same access-rule will be "in-sync":
admin@ncs% request db-firewalls db-firewall * check-sync
db-firewalls db-firewall paas_1 check-sync
in-sync true
db-firewalls db-firewall paas_2 check-sync
in-sync true
[ok][2017-03-27 12:09:17]
[edit]
admin@ncs%
If we look at the "NSO development guide", we can find many additional uses of the new guard feature:
• If insert="first", then the constraint is fulfilled if the element exists in the configuration before the element indicated by the guard.
• If insert="last", then the constraint is fulfilled if the element exists in the configuration after the element indicated by the guard.
• If insert="after", then the constraint is fulfilled if the element exists in the configuration before the element indicated by the guard, but after the element indicated by the key or value statement.
• If insert="before", then the constraint is fulfilled if the element exists in the configuration after the element indicated by the guard, but before the element indicated by the key or value statement.
• If the guard evaluates to an empty node-set (i.e. the node indicated by the guard does not exist in the target configuration), then the constraint is not fulfilled.
Conclusion:
NSO is a fantastic tool for firewall rule management, particularly in multi-vendor, multi-domain environments. With NSO 4.4, the guard feature was introduced, which makes support for complex firewall rules constrains extremely easy.
Note: All these features are available for any "ordered-by user" list. Particularly, we can find similar requirements in areas such as QoS management or routing policy management.
