Multiple ASNs/networks per IP?

certtools / intelmq

IntelMQ is a solution for IT security teams for collecting and processing security feeds using a message queuing protocol.

https://docs.intelmq.org/latest/

GNU Affero General Public License v3.0

975 stars 296 forks source link

Multiple ASNs/networks per IP? #543

Open sebix opened 8 years ago

sebix commented 8 years ago

How to deal with IPs with multiple Network-mappings, like the one, we use in our tests:

dig +short 192.50.189.origin.asn.cymru.com TXT
"28333 | 189.50.192.0/20 | BR | lacnic | 2007-08-10"
"28333 | 189.50.192.0/22 | BR | lacnic | 2007-08-10"

This is the reason, why the tests fail in about 50% of runs*.

We could for example select the network which is bigger, or has a more recent date.

* additionally to another runtime-dependent bug which will be fixed by #542

aaronkaplan commented 8 years ago

On Tue, Jun 14, 2016 at 07:48:42AM -0700, Sebastian wrote:

How to deal with IPs with multiple Network-mappings, like the one, we use in our tests:
dig +short 192.50.189.origin.asn.cymru.com TXT
"28333 | 189.50.192.0/20 | BR | lacnic | 2007-08-10"
"28333 | 189.50.192.0/22 | BR | lacnic | 2007-08-10"

In this case, the most specific / best match wins. So the smaller the netblock size (/22) (as long as the IP address falls into this netblock), the better. That usually wins on the routing level.

This is the reason, why the tests fail in about 50% of runs*.

We could for example select the network which is bigger, or has a more recent date.

use the smaller one (if the IP is inside the smaller range)

additionally to another runtime-dependent bug which will be fixed by #542

You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/certtools/intelmq/issues/543

sebix commented 8 years ago

Okay, and what about multiple ASNs?

$ dig +short 8.43.0.192.origin.asn.cymru.com TXT "16876 40528 | 192.0.43.0/24 | US | arin | 2009-06-29"

aaronkaplan commented 8 years ago

This could be an anycasted netblock (?)

Variant 1: take the first ASN and put keep the original list of ASNs somewhere (extra?) Variant 2: duplicate the event for each ASN (ugly).

dmth commented 8 years ago

I'd go for Variant 2. In Addition: a UUID-Field would be interesting to, If an event is splitted, the UUID will be duplicated. This enables the detection of events which are identical.

sebix commented 8 years ago

Variant two is the way we agreed on later ago, e.g. in #373.

sebix commented 8 years ago

Conclusion (offline): Currently we just take one of the ASNs, and solve the problem in a later release together with #373

ghost commented 7 years ago