nautobot / nautobot-app-firewall-models

Model Firewall policies in Nautobot

Home Page:https://docs.nautobot.com/projects/firewall-models/en/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Move Service to Policy Rule

abates opened this issue · comments

Environment

  • Python version:
  • Nautobot version:
  • nautobot-plugin-firewall-model version:

Proposed Functionality

Services (http, https, tcp/8080 etc) are typically associated with a firewall rule, not a source or destination address. In the current implementation the service is tied to the SourceDestination model. In my simple use cases it seems to make more sense for Service to be tied to the PolicyRule object.

Use Case

The following is a pretty standard way to receive information for a firewall change request. The request's rules are defined as action/protocol/source/destination. Depending on the protocol (icmp, udp, tcp etc) there may be optional values for source or destination port or (in the case of icmp) type and code:

request_id: 12345
rules:
  - action: permit
    protocol: tcp
    src: 
      addr: 192.168.10.1/32
    dst: 
      addr: 192.168.12.0/28
      port: 80

  - action: permit
    protocol: tcp
    src: 
      addr: 192.168.10.1/32
    dst: 
      addr: 192.168.12.0/28
      port: 80

  - action: permit
    protocol: tcp
    src: 
      addr: 192.168.10.1/32
    dst: 
      addr: 192.168.12.0/28
      port: 80

It seems like there should be a Service object created that is associated with the PolicyRule, not with the SourceDestination objects

I guess the idea was to support a more advanced firewall rule that could define also the source port

Yeah, we'll definitely need to maintain a way to specify source port, there are certainly many examples of needing a source port (DHCP or DNS for instance).

I think for the service relationship to move to PolicyRule that will also require adding source port to the Service model. My concern with the way it is now is that you could get a situation where your source relationship has a different IP protocol than your destination relationship.

I see. Your main concern is about protocol/port consistency.
This inconsistency could be mitigated by using data validation when two services are defined in the same rule, so the protocol is validated then.

I think my this is my main question: Is there a use case where a service needs to be defined as a pair of services (source and destination)? If not, we can simplify the firewall models by moving the service relationship to the policy rule and adding an optional source port field.

As it is right now, to create a rule like "permit tcp host 10.1.1.1 host 10.2.2.2 eq 22" you would need to create a service policy object with nothing in it for the source and a second service policy object for tcp/22.

@abates , I was looking for some example of having a source port, and I have not been able to find one. So, it would align with your view.
Just to get more points, please ask in #ask-architecture to see if someone has other experience/idea