panos_query_rules: Match by glob pattern and subnet

[megakoresh]

Currently query rules module matches directly by string comparison. This is very inflexible and not very useful (if I knew such exact parameters why would I look up the rule to the begin with?). A much more useful approach would be to try matching by subnet e.g.

destination_ip: 192.168.88.6 would match a rule with destination ip: 192.168.88.0/24 and same for source.

And failing that also match by glob pattern or substring e.g.

destination_ip: 192.168.88.* would match rules with destination ips 192.168.88.0/28 as well as 192.168.88.128/28.

Would also be nice if specifying port range like 4455-5566 would match rules with ports within that range.

An additional argument like strict could be used to keep current behaviour, or vice versa - loose could be used to apply behaviour like described above.

Since I dont know where to post this, I replicated this issue on ansible as well: ansible/ansible#51382

[shinmog]

This repo is the right place to post this.

This is interesting. If we're going to support searches like this, it seems like it would want to be able to do A or B, A and B, etc. For simplicity maybe we assume the module won't support parenthesis stuff, so no (A and B) or C.

Did you have a mental image of what the playbook task might look like?

[megakoresh]

Did you have a mental image of what the playbook task might look like?

@shinmog I expected similar functionality to that of Panorama policy search in security policy view. The playbook should look exactly like it does now (maybe with optional extra boolean loose_match parameter, like the one you have hard-coded now, but give it more meaning).

A rule like this

from: 192.168.88.0/24
to: 192.168.89.0/24
service: https,http
source_zone: nap
destination_zone: dmz

Should be matched by this

panos_query_rules:
  destination_ip: 192.168.89.55
  username: '{{ username }}'
  password: '{{ password }}'
  ip_address: '{{ ip_address }}'

or this

panos_query_rules:
  destination_ip: 192.168*
  username: '{{ username }}'
  password: '{{ password }}'
  ip_address: '{{ ip_address }}'

or this

panos_query_rules:
  destination_port: 443
  username: '{{ username }}'
  password: '{{ password }}'
  ip_address: '{{ ip_address }}'

or this

panos_query_rules:
  source_ip: 192.168.88.55
  username: '{{ username }}'
  password: '{{ password }}'
  ip_address: '{{ ip_address }}'

You get the idea I hope. Its a rule search, not a direct policy match, I want to be able to specify loosely parameters and get all rules that sort of match them. So that means when the module evaluates a criteria I would like it to try direct match, if that fails, try object match (i.e. if its an IP, check if its in the subnet that is defined in the rule) and if that fails, try just glob pattern match.

I looked over the code and it doesn't seem difficult to implement this, especially if you know what to expect PanOS REST API to return (I have had difficulty with that in the past...).

[shinmog]

Looking around, the CLI has a test security-policy-match command. It wouldn't allow you to search for just destination_port = 443, as it requires at least source / destination / protocol. So if you would want to just search destination_port = 443 then this wouldn't work.

[shinmog]

So, if an Ansible module wrapped around test security-policy-match, would that fit your needs?

[megakoresh]

So, if an Ansible module wrapped around test security-policy-match, would that fit your needs?

@shinmog I actually would say that no, I prefer the current approach. I have coded my own solution using security-policy-match and its limitations are exactly why I went to this module in the first place.

I would like something like a loose search functionality, which allows filling parameters on a best-effort basis. Security policy match is way too strict and way too slow for bulk execution, especially if going through panorama and not connecting to firewalls directly. So no, I would prefer if the module worked the same way as it does now, just instead of direct string matches it would optionally also try parsing the ip and matching by subnet, and if that fails matching it loosely with glob pattern, as I showed above.