-
-
Notifications
You must be signed in to change notification settings - Fork 185
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 IPNEIGH plugin for IPv4/6 discovery using the ip neigh
command
#896
Conversation
Also I want to point out a minor difficulty I had during development. I tried using the function That function set the empty values in the database to the string I haven't changed the function to return |
Thanks a lot for the PR 🎉🙌 - a question - why did you choose this approach instead of using the global subnets setting?
If we proceed with this approach, please specify example values in the settings description - users don't often know the format. One of the main reasons I keep this setting global is to simplify setup, so having a separate subnets configuration for the plugin defeats the purpose. I do understand it comes with more flexibility - maybe in future I'd implement inheriting and overriding settings. |
The problem is the way the setting is done: it's formatted like the arguments of a program (like the other scanning utilities (the |
hmmm, I can accept the PR if you give me an example of valid inputs - I'd still myself rewrite the plugin to use the global setting at this point, but I can do it myself. |
You mean regex the field? I'm not sure, it's a fragment of the args of totally different commands. It's heavily tailored for the Moreover, the subnet is currently ignored.. It could be used for IPv4s returned by the plugin, but it would be weird to do that for v4, and not v6. IPv6 adresses of devices in a network can be of two kinds: public and link-local. In case of subnetting a IPv6 subnet field would be required for both. The current implementation of the cli args does not allow this. I've still to push a fix for the online detection feature, which was incorrectly handled from the command output. |
Okay, that's the fix. I have also added the default value |
Thank you! Will look at the regex approach and merge it probably over the weekend |
What it is
IPNEIGH
is a new device discovery plugin that uses theip neigh
command to read from both the ARP and NDP table.The main objective of this plugin is to allow for discovery of IPv6 devices which use NDP for address resolution, and aren't detectable by
ARPSCAN
.How it works
The plugin is extremely simple. First it runs a ping on multicast address
ff02::1
which is directed at every IPv6 device from the local network, this causes the network stack to send NDP solicitation requests and populates the NDP table. Note that every device will answer with only one of its addresses, so only those addresses will appear in the table, unless discovered by normal operation.Then using the
ip neigh
command it retrieves every neighbouring IP, both v4 and v6, and adds them to the database. It will not discover names or vendors though.Those tables often contains various multicast addresses that are not real devices. This plugin filters them out and doesn't add them to the database
Note
This does not replace
ARPSCAN
, because it doesn't actively sends ARP requests, so by itself it might miss some IPv4 device. If you have both, realisticallyIPNEIGH
will never find an IPv4 device thatARPSCAN
didn't, unless for some network timing oddity. I could have limited it to IPv6 devices, as it didn't add anything to IPv4 scanning, but there was no reason to.If someone added ARP requests it would make
ARPSCAN
unnecessary.