Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance parsing of JSON for firewall IP aliases #8277

Open
2 tasks done
gglockner opened this issue Feb 3, 2025 · 3 comments
Open
2 tasks done

Enhance parsing of JSON for firewall IP aliases #8277

gglockner opened this issue Feb 3, 2025 · 3 comments
Assignees
Labels
feature Adding new functionality

Comments

@gglockner
Copy link

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Is your feature request related to a problem? Please describe.

Amazon Web Services (AWS) publishes their IP address ranges in JSON format. Here is the documentation and here is the direct link to the JSON data. Using OPNsense 25.1 (amd64), I would like to use Firewall > Aliases to import this data as Type "URL Table in JSON format (IPs)". I have looked at the source in src/opnsense/scripts/filter/lib/alias/uri.py; as best as I can determine, this JSON data cannot be parsed by this OPNsense feature.

Describe the solution you like

The "Path expression" field should support more query options, so that this data can be used for firewall rules. Consider jq, a popular tool to process JSON data. The following Linux shell command gives all IPv4 address ranges from AWS:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[].ip_prefix'

jq is quite powerful, so you could do a more sophisticated filter such as: all IPv4 ranges for AWS EC2 in the us-east-1 region:

curl https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes[] | select(.region=="us-east-1") | select(.service=="EC2") | .ip_prefix'

This type of logic would be difficult to replicate using the limited single-line parsing implementation in src/opnsense/scripts/filter/lib/alias/uri.py.

Describe alternatives you considered

It would be straightforward to implement this in src/opnsense/scripts/filter/lib/alias/uri.py if the jq shell package were installed by default in OPNsense. Alternately, there are a few pure-Python data transformation libraries, but they either have a nonstandard syntax or implement only a subset of jq syntax.

Additional context

I started discussing this topic in #8107 but split this into a separate Github issue.

@AdSchellevis AdSchellevis self-assigned this Feb 3, 2025
@AdSchellevis AdSchellevis added the feature Adding new functionality label Feb 3, 2025
@AdSchellevis
Copy link
Member

I might need to revise my original answer, for some reason I missed the native python binding available via https://github.com/opnsense/ports/blob/master/textproc/py-jq, which is more or less a stub around the library itself.
Usually these are not too complicated in maintenance.

I might do a small proof of concept with this, there are pro's and cons here. jqlang is used by quite some people, has an online tester available (https://jqplay.org/), but is not very easy to learn for less experienced users.

Offering only simple patterns a.b, a.*.b might be easier to explain, but has the downside of not being extendable in the future. As we already released the a.b pattern in 25.1, there's also the small issue of different formats in its current state.

@gglockner
Copy link
Author

gglockner commented Feb 3, 2025

If we agree that this would be implemented via a Python front-end to jq, I would be happy to contribute the code for this. The key thing that prevents me from implementing it myself and submitting a pull request is that I cannot figure out how to ensure that the packages for jq and textproc are installed by default.

I agree there is a very small chance this could break some installations. However, the chance should be tiny considering this feature was introduced merely a few days ago in 25.1.

@AdSchellevis
Copy link
Member

let me fiddle a bit and get back to you, compiling the port in this case is rather quick

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Adding new functionality
Development

No branches or pull requests

2 participants