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

Add an API to lookup matching prefix and VLAN details from an IP or subnet address #2577

Closed
lunkwill42 opened this issue Feb 17, 2023 · 3 comments · Fixed by #2578
Closed
Assignees

Comments

@lunkwill42
Copy link
Member

lunkwill42 commented Feb 17, 2023

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

Given either a single IP address or a subnet address, it is desirable to look up the details of the known prefixes that contain the given address. There is currently no good API in NAV to do this, except maybe through the machine tracking endpoint, which may divulge too much sensitive information about the physical location history of a single host. The intent here is to get information about matching subnets, not about a host itself.

This API is requested by the Sikt Cyber Security Center, to enable looking up information about the purpose of a subnet allocation, given a list of suspicious IP addresses from vulnerability scans or abuse reports.

Describe the solution you'd like

An API endpoint that takes a CIDR address as its input (e.g. 10.0.0.42/32 for a single host, or 10.42.0.0/16 for a full subnet), and outputs a list of matching Prefix objects from NAV. Most of the interesting allocation details for a subnet is contained within a NAV Vlan object.

Each Prefix has a relation to a Vlan, so in order to obviate the need for the client to perform yet another lookup, the Vlan relation should be inlined in each Prefix object output.

The current /prefix API endpoint nearly matches the bill - but it lacks two important features from this spec:

  1. It does not feature a filter to match prefixes that contain a given IP/CIDR address. This could easily be added, though.
  2. It does not inline the matching Vlan object, it just outputs its primary key value. This isn't as straightforward to "fix" without breaking compatibility with existing API clients that expect the vlan value to be an integer id of a Vlan object. While not a fully clean solution, the corresponding Vlan object could be serialized and inlined under a different attribute name to retain backwards compatibility.

Describe alternatives you've considered

A new API endpoint could be tailored to this, but it feels like it would contain a lot of redundancies compared to the solution described above. Maintaining the related functionality in the same ViewSet would be preferable, IMHO.

@stveit
Copy link
Contributor

stveit commented Feb 20, 2023

Clarification for behaviour:

Given two Prefixes
Prefix A: 10.0.0.0/8
Prefix B: 10.1.5.0/24
If 10.1.0.0/16 is given as input, should then Prefix A be returned as it contains the entirety of 10.1.0.0/16, but Prefix B should not be returned as it only contains some of the addresses that make up 10.1.0.0/16?

@lunkwill42
Copy link
Member Author

Clarification for behaviour:

Given two Prefixes Prefix A: 10.0.0.0/8 Prefix B: 10.1.5.0/24 If 10.1.0.0/16 is given as input, should then Prefix A be returned as it contains the entirety of 10.1.0.0/16, but Prefix B should not be returned as it only contains some of the addresses that make up 10.1.0.0/16?

A prefix from NAV should only match if the input address is entirely contained within it (and a prefix is, of course, entirely contained within self too).

This is equivalent to the << operator in PostgreSQL, which is what we usually use in NAV for this type of matching (which leaves the heavy lifting to PostgreSQL, rather than Python. See https://www.postgresql.org/docs/13/functions-net.html)

@lunkwill42
Copy link
Member Author

It might also be that what I'm describing is actually the <<= operator - you can easily play around with this in PostgreSQL using the psql command line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants