Introducing Nautobot Firewall Models

Introducing the Nautobot Firewall Models application! A data-model driven solution for modeling layer 4 firewall policies and access lists. This will allow anyone to model policies to drive their network and security automation. Even better, the firewall models are built to take a vendor-agnostic approach; the models are robust to provide maximum flexibility.

The application is currently available for install directly via PyPI as a beta release with the intent to gather feedback from the community and implement a few enhancements to help with the user experience prior to a v1.0.0 release. The app requires Nautobotv1.3.0 or later, as it employs the use of DynamicGroups as an option in Policy assignment.

Setting Up a Development Environment

The application follows the same type of development environment as most apps found in the Nautobot namespace of GitHub from the stance of being built on Poetry, Docker, and PyInvoke. This app does introduce a management command to Nautobot that is very helpful to use in a local development environment OR to just populate a small set of data for use in testing out the app. Management commands are a set of actions that the nautobot-server command has access to. A few common ones you see are createsuperuser or runserver. The management command published by the app is create_test_firewall_data. This command uses the same set of data used in running unittests to populate a set of test data. To follow a similar pattern for the other common management command, in the development environment you can run invoke testdata to wrap running the nautobot-server command. Why does this matter? If you’re using the local development environment, the invoke command is easiest. But if you are not using local development for the deployment, nautobot-server create_test_firewall_data is available.

Example Local Setup Commands

➜  plugins git clone git@github.com:nautobot/nautobot-plugin-firewall-models.git
➜  plugins cd nautobot-plugin-firewall-models 
➜  nautobot-plugin-firewall-models git:(develop) poetry install
➜  nautobot-plugin-firewall-models git:(develop) poetry shell
➜  nautobot-plugin-firewall-models git:(develop) cp development/creds.example.env development/creds.env
➜  nautobot-plugin-firewall-models git:(develop) invoke build
## I like running migrate, but it can be skipped as called by start.
➜  nautobot-plugin-firewall-models git:(develop) invoke migrate
➜  nautobot-plugin-firewall-models git:(develop) invoke start
## To do a one-time load of data, migrations must have finished.
➜  nautobot-plugin-firewall-models git:(develop) invoke testdata
Running docker-compose command "ps --services --filter status=running"
Running docker-compose command "exec nautobot nautobot-server create_test_firewall_data"
Attempting to populate dummy data.
Successfully populated dummy data!

Navigating the UI

Navigating the app is done via the Firewall nav bar dropdown.

Reviewing a Policy with Rules

After selecting Policy from navmenu, select a Policy from the list. To get more detail on the rule assigned to the Policy, click on Policy Rules Expanded.

Assigning the Policy to a Device OR DynamicGroup can be done via the Edit menu.

When initially assigning a PolicyRule to a Policy, the index of the relationship is not set. To set the index, click Edit Policy Rule Indexes and you will see No Index Set for the newly added PolicyRule. You can adjust multiple indexes at once and hit Submit.

The weight for assigned Devices or DynamicGroups is edited similarly to editing a PolicyRule index, however the weight does default to 100 on the initial assignment. 

Building a Simple Policy

Use the following steps to create a small Policy that has one PolicyRule: to allow HTTP/HTTPS access from an IPRange to an FQDN then an implicit deny.

1. Create an IPRange with a starting address of 10.0.0.1 and ending address of 10.0.0.100.
2. Create an FQDN named demo.nautobot.com.
3. Create an AddressObject named User Workstations with the 10.0.0.1-10.0.0.100 IPRange assigned.
4. Create a second AddressObject named Nautobot Demo FQDN with the demo.nautobot.com FQDN assigned.
5. Since we have two ServiceObjects to target AND they are both created by the initial migrations, create a ServiceObjectGroup named Web Services with both the HTTP (TCP/80) and HTTPS (TCP/443) ServiceObjects assigned.
6. Create a PolicyRule with the following attributes assigned:
   • name = Allow Users to Nautobot Demo
   • Source Address Objects = User Workstations
   • Destination Address Objects = Nautobot Demo FQDN
   • Service Object Groups = Web Services
   • Action = allow
   • Status = Active
   • Leave the remaining attributes blank. 
7. Create a second PolicyRule with only the name set to DENY ALL and action set to deny.
8. Create a Policy named Public demo access and assign both newly created PolicyRules. 
9. Last, click Edit Policy Rule Indexes and assign the allowed rule an index of 10 and the deny rule an index of 100. 

Although this process does require navigating through a few views, all objects are backed by a full REST API and can be fully created and maintained via the API.