Argus: a hijacking alarm system
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. _________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On 2012-01-20 10:47 , Yang Xiang wrote:
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).
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 ;)
_________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn 2012/1/20 Jeroen Massar <jeroen@unfix.org>
On 2012-01-20 10:47 , Yang Xiang wrote:
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).
But the big question of 2012 [*] is: does it do IPv6.
The last 99 anomalies don't show any info there.
Yes, it's only v4 now :( But I'm trying to do so. It needs enough (dozens of) public IPv6 router-servers to do the job. Actually the system only need to execute 'ping6' and 'show ipv6 bgp' in the IPv6 route-server. Hope I can find enough v6 route-servers before Jun 6 :)
Greets, Jeroen
[*] We got a http://ipv6week.org/ and http://www.worldipv6launch.org/ this year ;)
On Fri, Jan 20, 2012 at 4:09 PM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
Hope I can find enough v6 route-servers before Jun 6 :)
Jeroen is just the guy to suggest where you can find them :) 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! -- Suresh Ramasubramanian (ops.lists@gmail.com)
_________________________________ Yang Xiang . about.me/xiangyang 2012/1/20 Suresh Ramasubramanian <ops.lists@gmail.com>
On Fri, Jan 20, 2012 at 4:09 PM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
Hope I can find enough v6 route-servers before Jun 6 :)
Jeroen is just the guy to suggest where you can find them :) Till then, if google is an acceptable substitute - http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_route_servers
Thanks very much. I will check these servers.
Enjoy - your system sounds great. And of course gong xi fa cai!
Gong xi fa cai, happy Chinese New Year :)
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On 2012-01-20 12:01 , Yang Xiang wrote:
2012/1/20 Suresh Ramasubramanian <ops.lists@gmail.com <mailto:ops.lists@gmail.com>>
On Fri, Jan 20, 2012 at 4:09 PM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn <mailto:xiangy08@csnet1.cs.tsinghua.edu.cn>> wrote: > Hope I can find enough v6 route-servers before Jun 6 :)
Jeroen is just the guy to suggest where you can find them :) Till then, if google is an acceptable substitute - http://www.bgp4.net/wiki/doku.php?id=tools:ipv6_route_servers
Thanks very much. I will check these servers.
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
_________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn 2012/1/20 Jeroen Massar <jeroen@unfix.org>
On 2012-01-20 12:01 , Yang Xiang wrote:
2012/1/20 Suresh Ramasubramanian <ops.lists@gmail.com <mailto:ops.lists@gmail.com>>
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.
Argus receives BGP update from BGPmon, and only access route servers when it find one BGP update is 'anomalous'. We also controlled the load to these route servers. After login to the route server, Argus only execute 'ping' for a given IP address, and 'show ip bgp' for a given prefix, and will logout from the route server after two minutes.
Greets, Jeroen
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.... 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.... Or you can just query for any state: http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0... Regards, as On 20 Jan 2012, at 07:47, Yang Xiang wrote:
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. _________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
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 :) 2012/1/20 Arturo Servin <aservin@lacnic.net>
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....
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....
Or you can just query for any state:
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0...
Regards, as
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On 20 Jan 2012, at 10:38, Yang Xiang wrote:
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 :)
I was just suggesting to add a more deterministic way to detecting hijacks. Regards, as
2012/1/20 Arturo Servin <aservin@lacnic.net>
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....
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....
Or you can just query for any state:
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0...
Regards, as
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
2012/1/20 Arturo Servin <aservin@lacnic.net>
On 20 Jan 2012, at 10:38, Yang Xiang wrote:
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 :( 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 :)
I was just suggesting to add a more deterministic way to detecting hijacks.
Sorry for my poor English :( What I want to say is, RPKI is really good, Argus is just an alternative, before we can protect ourself using signatures, honestly :-) Best regards!
Regards, as
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On Jan 20, 2012, at 8:08 AM, Yang Xiang wrote:
I think network operators are only careless, but not trust-less, so black-hole hijacking is the majority case.
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
On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
2012/1/20 Arturo Servin <aservin@lacnic.net>
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 :(
I think network operators are only careless, but not trust-less, so black-hole hijacking is the majority case.
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
Hi chris, 2012/1/23 Christopher Morrow <morrowc.lists@gmail.com>
On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
2012/1/20 Arturo Servin <aservin@lacnic.net>
while Argus can discover potential hijackings caused by anomalous AS path.
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)
yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of <prefix, origin_AS> mappings, neighbor data: a history of every "adjacent two ASes" in all AS paths received from BGPmon, policy data: a history of every "adjacent three ASes" (AS triple) in all AS paths. origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all "adjacent three ASes" in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement.
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?
yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., "show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB:
-chris
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
Hi chris,
2012/1/23 Christopher Morrow <morrowc.lists@gmail.com>
On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote:
2012/1/20 Arturo Servin <aservin@lacnic.net>
while Argus can discover potential hijackings caused by anomalous AS path.
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)
yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of <prefix, origin_AS> mappings, neighbor data: a history of every "adjacent two ASes" in all AS paths received from BGPmon, policy data: a history of every "adjacent three ASes" (AS triple) in all AS paths.
origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all "adjacent three ASes" in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement.
ok, that seems squirrelly still :(
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?
yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., "show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB:
so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :( -chris
2012/1/23 Christopher Morrow <morrowc.lists@gmail.com>
ok, that seems squirrelly still :(
so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :(
it is not a serious problem, I think. 1). we do not use routeviews-like routeservers for hijacking identification, we only use router. 2). there is a high possibility that, the 'best path' is the path in FIB table. 3). if the 'best path' is not the path in FIB, there is still a high possibility that the 'best path' is the path in the FIB of other routes in the same AS. 4), our criterion is a threshold of a fingerprint, not a extremum. the fingerprint evaluated the possibility. hope I'm not wrong. :)
-chris
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On 1/23/2012 7:28 AM, Christopher Morrow wrote: > On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang > <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote: >> Hi chris, >> >> 2012/1/23 Christopher Morrow <morrowc.lists@gmail.com> >>> On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang >>> <xiangy08@csnet1.cs.tsinghua.edu.cn> wrote: >>>> 2012/1/20 Arturo Servin <aservin@lacnic.net> >>>>>> while Argus can discover potential hijackings caused by anomalous AS >>>>> path. >>> 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) >> yes, we use history as a baseline for both the origin, neighbor and policy >> data. >> origin data: a history of <prefix, origin_AS> mappings, >> neighbor data: a history of every "adjacent two ASes" in all AS paths >> received from BGPmon, >> policy data: a history of every "adjacent three ASes" (AS triple) in all AS >> paths. >> >> origin and neighbor data is intuitive. >> for policy data, we do not gather the exact routing policies, >> since they are usually private. >> In Argus, we use all "adjacent three ASes" in all AS paths as the policy >> data. >> this is because: >> 1), AS triples reflect the import/export routing policies; >> 2), while monitoring BGP updates, we only need to discover 'possible’ >> hijackings, but not 'exact' hijackings. >> after figure out a possible hijacking, the hijacking identification >> process will be launched and make the final judgement. > ok, that seems squirrelly still :( > >>> >>> 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? >> yes, each route-server usually has several route to the target prefix. >> In Argus, we use the commands (i.e., "show route exact active-path”) to get >> the 'best routes' of the prefix, >> and consider it as the route in FIB: > so, take routeviews for example, they peer almost exclusively > ebgp-multi-hop, so any 'best path' you see there isn't actually usable > by the route-server... all traffic has to take the local transport out > of the routeviews system, off to the internet and beyond. So, your > blackhole testing isn't actually testing what you want, I think :( > > -chris > Minor correction there. If you are talking about our IX collectors (LINX, PAIX, EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering directly. The collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are multi-hop. Doesn't detract from your point, but I think it helps if people are aware of whether they are on the exchange or on a multihop when using routeviews collectors. Only other thing to add, I don't think anyone mentioned Cyclops in this thread. Just as another data point, see also: http://cyclops.6watch.net or http://cyclops.cs.ucla.edu John Kemp (kemp@routeviews.org)
2012/1/24 John Kemp <kemp@network-services.uoregon.edu>
Minor correction there. If you are talking about our IX collectors (LINX, PAIX, EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering directly. The collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are multi-hop. Doesn't detract from your point, but I think it helps if people are aware of whether they are on the exchange or on a multihop when using routeviews collectors.
We talk about routeservers, not collectors. Argus doesn't use routeservers in RouteViews to identify hijacking.
Only other thing to add, I don't think anyone mentioned Cyclops in this thread. Just as another data point, see also: http://cyclops.6watch.net or http://cyclops.cs.ucla.edu
John Kemp (kemp@routeviews.org)
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
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 On 20 Jan 2012, at 13:08, Arturo Servin wrote:
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....
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....
Or you can just query for any state:
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0...
Regards, as
On 20 Jan 2012, at 07:47, Yang Xiang wrote:
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. _________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
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> On Fri, Jan 20, 2012 at 9:39 AM, Alex Band <alexb@ripe.net> wrote:
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
On 20 Jan 2012, at 13:08, Arturo Servin wrote:
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....
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....
Or you can just query for any state:
http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/cidr/200.31.12.0...
Regards, as
On 20 Jan 2012, at 07:47, Yang Xiang wrote:
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. _________________________________ Yang Xiang . about.me/xiangyang Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
On Fri, Jan 20, 2012 at 05:47:21PM +0800, Yang Xiang wrote:
I build a system ?Argus? to real-timely alert prefix hijackings.
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". ;-) ---rsk
On 20 January 2012 07:53, Rich Kulawiec <rsk@gsp.org> wrote:
On Fri, Jan 20, 2012 at 05:47:21PM +0800, Yang Xiang wrote:
I build a system ?Argus? to real-timely alert prefix hijackings.
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". ;-)
---rsk
Ha, there are already two with the name Argus: http://argus.tcp4me.com/ also been around for years... .r'
On Fri, Jan 20, 2012 at 10:45 PM, RijilV <rijilv@riji.lv> wrote:
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". ;-)
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] --srs
2012/1/21 Suresh Ramasubramanian <ops.lists@gmail.com>
On Fri, Jan 20, 2012 at 10:45 PM, RijilV <rijilv@riji.lv> wrote:
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". ;-)
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 :) panopticon
--srs
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
ah, bad news ~ too many Argus :) 2012/1/21 RijilV <rijilv@riji.lv>
On 20 January 2012 07:53, Rich Kulawiec <rsk@gsp.org> wrote:
On Fri, Jan 20, 2012 at 05:47:21PM +0800, Yang Xiang wrote:
I build a system ?Argus? to real-timely alert prefix hijackings.
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". ;-)
---rsk
Ha, there are already two with the name Argus:
also been around for years...
.r'
-- _________________________________________ Yang Xiang. Ph.D candidate. Tsinghua University Argus: argus.csnet1.cs.tsinghua.edu.cn
participants (11)
-
Alex Band -
Arturo Servin -
Christopher Morrow -
Danny McPherson -
Jeroen Massar -
John Kemp -
Rich Kulawiec -
Richard Barnes -
RijilV -
Suresh Ramasubramanian -
Yang Xiang