Liveness collisions and bugs #114
Comments
jmwample
added a commit
that referenced
this issue
Dec 8, 2021
This fix attempts to address two contributing factors to a relatively
large number of live phantoms seen in a multi-station deployment.
* refactor, simplify, and add test for detector filter list checks in detector
* add EnableV{4,6} check before continuing with a liveness scan for IPv{4,6}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Station B is seeing a large number of live phantom responses from subnets past multiple other stations that are definitively not live. This indicates that the stations themselves are responding to the liveness testing which should not be possible. Also, registrations shared over the registration API are not subject to some block-list / IP version settings meaning stations that do not support IPv6 and have EnableV6 set to false are reporting many failed liveness tests because IPv6 phantoms are unreachable.
Station A is receiving these registrations - sharing them over the API.
Station B is receiving the registrations as an API registration and scanning. It generates both v4 and v6. This would be filtered at the generation phase typically, but since it came from the API it isn't generated locally. So there are a bunch of scans that just fail because station B doesn't even have IPv6.
May only be when decoy registrar shares over API
This is true for ipv4 and ipv6 and somehow bypasses the local correctness / blocklist checks.
Solution
detector_filter_listis applied in detector properlyKeep PR #75 in mind while fixing this issue.
The text was updated successfully, but these errors were encountered: