Argus: a hijacking alarm system

Mailman List Mirror (Read Only)
1

Hi,

I build a system ‘Argus’ to real-timely alert prefix hijackings.
Argus monitors the Internet and discovers anomaly BGP updates which caused
by prefix hijacking.
When Argus discovers a potential prefix hijacking, it will advertise it in
a very short time,
both in our website (http://argus.csnet1.cs.tsinghua.edu.cn) and the
mailing list (argus@csnet1.cs.tsinghua.edu.cn).

Argus has been running in the Internet for more than eight months,
it usually can discover potential prefix hijackings in ten seconds after
the first anomaly BGP update announced.
Several hijacking alarms have been confirmed by network operators.
For example: http://argus.csnet1.cs.tsinghua.edu.cn/fingerprints/61544/ has
been confirmed by the network operators of AS23910 and AS4538,
it was a prefix hijacking caused by a mis-configuration of route filter.

If you are interest in BGP security, welcome to visit our website and
subscribe the mailing list.
If you are interest in the system itself, you can find our paper which
published in ICNP 2011 (FIST workshop)
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=6089080.

Hope Argus will be useful for you.

2

But the big question of 2012 [*] is: does it do IPv6.

The last 99 anomalies don't show any info there.

Greets,
Jeroen

[*] We got a http://ipv6week.org/ and http://www.worldipv6launch.org/
this year :wink:

4

Jeroen is just the guy to suggest where you can find them :slight_smile:
Till then, if google is an acceptable substitute -
http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_route_servers

Enjoy - your system sounds great. And of course gong xi fa cai!

6

Please note that automated polling of route servers without prior
consent of the owner of said route server might not be completely
acceptable as it puts serious loads on them.

A better way is to get proper BGP sessions set up towards various locations.

You might also want to look at
http://www.ripe.net/data-tools/stats/ris/ris-raw-data which describes
how to get access to RIPE's RIS system raw data, this is what BGPMon
also uses.

Greets,
Jeroen

7

You could use RPKI and origin validation as well.

  We have an application that does that.

  http://www.labs.lacnic.net/rpkitools/looking_glass/

  For example you can periodically check if your prefix is valid:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/valid/cidr/200.7.84.0/23/

  If it were invalid for a possible hijack it would look like:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/invalid/cidr/200.31.18.0/24/

  Or you can just query for any state:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0/22/

Regards,
as

9

RPKI is great.

But, firstly, ROA doesn't cover all the prefixes now,
we need an alternative service to alert hijackings.

secondly, ROA can only secure the 'Origin AS' of a prefix,
while Argus can discover potential hijackings caused by anomalous AS path.

After ROA and BGPsec deployed in the entire Internet (or, in all of your
network),
Argus will stop the service :slight_smile:

10

RPKI is great.

But, firstly, ROA doesn't cover all the prefixes now,
we need an alternative service to alert hijackings.

  Or to sign your prefixes.

secondly, ROA can only secure the 'Origin AS' of a prefix,

  That's true.

while Argus can discover potential hijackings caused by anomalous AS path.

  Can you explain how?

After ROA and BGPsec deployed in the entire Internet (or, in all of your network),
Argus will stop the service :slight_smile:

  I was just suggesting to add a more deterministic way to detecting hijacks.

Regards,
as

11

> RPKI is great.
>
> But, firstly, ROA doesn't cover all the prefixes now,
> we need an alternative service to alert hijackings.

        Or to sign your prefixes.

Sign prefixes is the best way.
Before sign all prefixes, it is better if we have a detection service.

>
> secondly, ROA can only secure the 'Origin AS' of a prefix,

        That's true.

> while Argus can discover potential hijackings caused by anomalous AS
path.

        Can you explain how?

Only a imprecisely detection.

Section III.C in our paper
http://argus.csnet1.cs.tsinghua.edu.cn/static/Argus.FIST11.pdf

A brief explanation is:
If an anomalous AS path hijacked a prefix,
I can get replies in normal route-server, and can not get reply in abnormal
route-servers.

Here we only consider hijackings that black-hole the prefix.
If a hijacking doesn't black-hole the prefix (i.e., redirect, interception,
...), is hard to detect :frowning:

I think network operators are only careless, but not trust-less,
so black-hole hijacking is the majority case.

>
> After ROA and BGPsec deployed in the entire Internet (or, in all of your
network),
> Argus will stop the service :slight_smile:

        I was just suggesting to add a more deterministic way to detecting
hijacks.

Sorry for my poor English :frowning:
What I want to say is, RPKI is really good,
Argus is just an alternative,
before we can protect ourself using signatures,
honestly :slight_smile:

Best regards!

12

This is aligned with the discussion on route leaks at the proposed
interim SIDR meeting just after NANOG.

Even with RPKI and BGPSEC fully deployed we still have this
vulnerability, which commonly manifests itself today even by
accident.

RPKI-enabled BGPSEC would give you some assurances that the
ASes in the AS_PATH represent the list of ASes through which the
NLRI traveled, but nothing about whether it should have traversed
those ASes in the first place -- so we still need something somewhere
to mitigate that threat.

See this draft for more information:

<http://tools.ietf.org/html/draft-foo-sidr-simple-leak-attack-bgpsec-no-help-01>

-danny

13

If you want to play around with RPKI Origin Validation, you can download the RIPE NCC RPKI Validator here: http://ripe.net/certification/tools-and-resources
It's simple to set up and use: just unzip the package on a *NIX system, run ./bin/rpki-validator and browse to http://localhost:8080

EuroTransit have a public one running here:
http://rpki01.fra2.de.euro-transit.net:8080/

You can see it's pointing to several Trust Anchors, downloads and validates all ROA periodically, you can apply ignore filters and white lists, see a BGP announcement validity preview based on route collector data, integrates with existing (RPSL based) workflows and can talk to RPKI-capable routers.

If you want to get an idea of how an RPKI-capable router would be configured, here's some sample config for Cisco and Juniper:
http://www.ripe.net/certification/router-configuration

You can also log into a public RPKI-capable Juniper here: 193.34.50.25, 193.34.50.26
telnet username: rpki
password: testbed

With additional documentation available here:
http://rpki01.fra2.de.euro-transit.net/documentation.html

Have fun,

Alex

14

A suggestion: pick a different name. There's already a network tool
named Argus (it's been around for years): http://www.qosient.com/argus/

I suggest using the name of a different Wishbone Ash album: "Bona Fide". :wink:

---rsk

15

BBN has also released an initial version of their relying party
software. Core features are basically the same as the other
validators (namely, RPKI certificate validation), with
-- more fine-grained error diagnostics and
-- more robust support for the RTR protocol for distributing validated
information to routers.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03854.html>

16

Ha, there are already two with the name Argus:

http://argus.tcp4me.com/

also been around for years...

.r'

17

Argus being a many eyed dog from greek myth .. no surprise a lot of
tools that do this kind of thing have the very same name.

Call it panopticon maybe? [nastier connotations - originally a prison
design by jeremy bentham where a warder sitting in the center could
see everything around him]

--srs

18

ah, bad news ~
too many Argus :slight_smile:

19

>> A suggestion: pick a different name. There's already a network tool
>> named Argus (it's been around for years): http://www.qosient.com/argus/
>>
>> I suggest using the name of a different Wishbone Ash album: "Bona
Fide". :wink:

> Ha, there are already two with the name Argus:
> http://argus.tcp4me.com/

Argus being a many eyed dog from greek myth .. no surprise a lot of
tools that do this kind of thing have the very same name.

Call it panopticon maybe? [nastier connotations - originally a prison
design by jeremy bentham where a warder sitting in the center could
see everything around him]

sounds cool :slight_smile:
panopticon

20

reading the preceding section (III.B) you check 3 things in the AMM
(anomaly monitoring module)
1) proper origin (based on what?)
2) anomalous neighbour (based on what?)
3) policy anomaly (where did you determine the policy?)

later text seems to imply you track some history (1 months worth) and
use that as a baseline, for at least the neighbour and origin data.
The policy data isn't clearly outlined though, where did that come
from? (there's a note about use of whois, which could cover some of
this, but certainly not all)

The data plane testing you propose is from the public route-servers
(eyes), which don't import the path you want, well routeviews I think
doesn't import routes to it's FIB (or maybe I'm mistaken...) but point
being with more than one peer on the routeserver it's not clear you
would be taking the path you actually want to test anyway, is it?

-chris