community real-time BGP hijack notification service
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. Following the discussion on NANOG a couple of weeks ago on what to do if your prefix is hijacked, people mentioned that detection-wise, free services are limited (to certain communities or by not being real-time). The current fully public and free services will alert you with a few hours delay. Over labor day weekend we built a free real-time service. We invite people to try it out during our beta stage. Register for alerts at: http://www.watchmy.net/ We hope you find it useful, Avi Freedman, Andrew Fried && Gadi Evron.
Hello Gadi, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Very good initiative. You can count on me as one of your users. Note that apparently it doesn't seem to be working as expected yet. Indeed I already received two false alerts: 1. Subject: watchmy.net BGP Alert - seeing {91.198.99.0/24, 6450 3737 701 702 43751} Body: Hello, we are seeing 91.198.99.0/24 being advertised with aspath 6450 3737 701 702 43751. We are alerting you because of the rule you set that is watching for prefixes that match or are more specific than 91.198.99.0/24, and are originated with any origin AS other than one of 702,6661,8220 Thanks, watchmy.net's jack-o-meter 2. Subject: watchmy.net BGP Alert - seeing {93.191.216.0/21, 6450 4436 3257 6661 43751} Body: Hello, we are seeing 93.191.216.0/21 being advertised with aspath 6450 4436 3257 6661 43751. We are alerting you because of the rule you set that is watching for prefixes that match or are more specific than 93.191.216.0/21, and are originated with any origin AS other than one of 702,6661,8220 Thanks, watchmy.net's jack-o-meter Is this normal? Regards, APN-RIPE.
On Fri, 12 Sep 2008, Arnaud de Prelle wrote:
Hello Gadi,
Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Very good initiative. You can count on me as one of your users.
Note that apparently it doesn't seem to be working as expected yet. Indeed I already received two false alerts:
<snip two issues>
Is this normal?
Avi is flying right now, when he lands he will reply directly. We will probably fix all glitches in a day or two. We appreciate you using the service, and helping us get it right! Gadi.
Regards, APN-RIPE.
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Hi Gadi, I just had a quick play with this, as I've been considering hacking together something similar. It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify. To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified. My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet. This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds.. -- Nathan Ward
I've been using IAR and PHAS, but I've noticed IAR seems to work a bit better and much faster. Recently we changed our ASN, and seconds after we started announcing prefixes under thew new ASN I received the email alerts from IAR. I did not receive anything from PHAS. Although I have in the past, PHAS seems to be unreliable at times. As for alerting on AS_PATH changes, I think that more false alarms would be generated given certain 'techniques' used to 're-route' traffic to use the best available path. (Internap/FCP). Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000). Christian On Fri, Sep 12, 2008 at 8:49 AM, Nathan Ward <nanog@daork.net> wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Hi Gadi,
I just had a quick play with this, as I've been considering hacking together something similar.
It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify.
To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified.
My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet.
This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds..
-- Nathan Ward
On Fri, 12 Sep 2008, Christian Koch wrote:
I've been using IAR and PHAS, but I've noticed IAR seems to work a bit better and much faster. Recently we changed our ASN, and seconds after we started announcing prefixes under thew new ASN I received the email alerts from IAR. I did not receive anything from PHAS. Although I have in the past, PHAS seems to be unreliable at times.
As for alerting on AS_PATH changes, I think that more false alarms would be generated given certain 'techniques' used to 're-route' traffic to use the best available path. (Internap/FCP).
Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000).
To that I don't need to wait for Avi to land and reply: Absolutely, but that requires another weekend of hacking. :)
Christian
On Fri, Sep 12, 2008 at 8:49 AM, Nathan Ward <nanog@daork.net> wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Hi Gadi,
I just had a quick play with this, as I've been considering hacking together something similar.
It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify.
To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified.
My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet.
This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds..
-- Nathan Ward
On 13/09/2008, at 1:14 AM, Christian Koch wrote:
Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000).
Again, that is trivially easy to falsify. My best quick hack solution so far is to fire off a traceroute and make sure that the traceroute gets ICMP TTL expire messages from IP addresses that are in prefixes originated from all the ASes in the ASPATH. Still forgeable, but a bit more difficult.. still far from perfect though. -- Nathan Ward
It is, agreed. But what is more likely; a simple a prefix hijack or an all out attack, manipulating origin as, and as_path? While the 2nd is possible, the first is the most likely, and the basis for all these "hijack alert" services. Christian On Fri, Sep 12, 2008 at 9:27 AM, Nathan Ward <nanog@daork.net> wrote:
On 13/09/2008, at 1:14 AM, Christian Koch wrote:
Maybe a better idea would be if you were able to input your origin asn and define your upstreams and/or peers, to be alerted on as well. (ie: Do not alert me on any paths containing 123_000, 456_000, 789_000).
Again, that is trivially easy to falsify.
My best quick hack solution so far is to fire off a traceroute and make sure that the traceroute gets ICMP TTL expire messages from IP addresses that are in prefixes originated from all the ASes in the ASPATH. Still forgeable, but a bit more difficult.. still far from perfect though.
-- Nathan Ward
On Sat, 13 Sep 2008, Nathan Ward wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time.
Hi Gadi,
I just had a quick play with this, as I've been considering hacking together something similar.
Thank you for taking a look, and if you like to join in and help develop it, you are welcome to.
It is trivially easy for an attacker to falsify the origin AS. If 'they' are not doing it already, then I'm quite surprised. This isn't really a good thing to alarm on, in my opinion. Or, maybe it is, but there should be big bold text explaining that it's not reliable as it's trivially easy to falsify.
To be honest, I can't think of anything better, all the attributes you can monitor can easily be falsified.
My best idea is looking at the AS_PATH for changes, and alerting whenever that happens. You'd obviously get a different path whenever there is churn in the network though. I'm sure there's a way to do this, and I suspect having BGP feeds from many many places is the most reliable way for it to happen, I just haven't figured out why yet.
You are possibly right, and you are absolutely right that verbosity and documentation need to be better. We'll get there, and hopefully not too long from now. This is a weekend project, although we definitely intend to get through out TO-DO list.
This seems like a service that Renesys etc. could/should (or maybe do?) offer, they seem well placed with all their BGP feeds..
Probably so, but they are a commercial effort.
-- Nathan Ward
On 12 Sep 2008, at 13:49, Nathan Ward wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. I just had a quick play with this, as I've been considering hacking together something similar.
Everyone with any interest in this topic should look at the MyASN service from the RIPE NCC (which I use and think is brilliant). http://www.ris.ripe.net/myasn.html " The MyASN service notifies network operators when a prefix is announced with an incorrect AS path. An AS path is seen as incorrect when it does not match with a regular expression. As not everyone is familiar with regular expressions, MyASN provides several easy ways to define typical checks, like "the origin of this prefix must be AS x" or "the origin of this prefix must be AS x and transit may be provided through y or z". However, as any AS path regular expression can be set, the MyASN service is suitable for regular expressions gurus as well. " To address Nathan's point, I recommend the RIPE service because for such a service to be ubiquitously useful, it needs to have many eyes (a view of routing tables at lots of points on the internet) which is where the very well peered situation of RIS comes into effect. At the last RIPE meeting I think i saw RIS had over 600 peers, which it collects at internet exchange points all over the world. best wishes Andy
Andy Davidson wrote:
On 12 Sep 2008, at 13:49, Nathan Ward wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. I just had a quick play with this, as I've been considering hacking together something similar.
Everyone with any interest in this topic should look at the MyASN service from the RIPE NCC (which I use and think is brilliant).
I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring. So the more we get the best it is and that's why I'll be using Gadi's BGP monitoring tool (and any other that might come) in parallel with the one provided by the RIPE. Note that MyASN will soon be replaced by IS Alarms which is simpler and as efficient as MyASN: http://tinyurl.com/46kfd7 http://ripe.net/is/alarms/ Regards, Arnaud.
Arnaud de Prelle wrote:
I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring.
In this case it's very important to have a lot of collectors broadly distributed listening in many ASes. For example: If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path.
So the more we get the best it is and that's why I'll be using Gadi's BGP monitoring tool (and any other that might come) in parallel with the one provided by the RIPE.
Hear hear for Gadi and others offering these tools. MMC -- Matthew Moyle-Croft - Internode/Agile - Networks
On 13/09/2008, at 5:48 PM, Matthew Moyle-Croft wrote:
Arnaud de Prelle wrote:
I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring.
In this case it's very important to have a lot of collectors broadly distributed listening in many ASes.
For example:
If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path.
Note that the attack becomes less and less effective if you're path stuffing ASes, as it will be preferred by fewer and fewer networks. Put collection points in say 10 networks, and the attack becomes pretty useless. Unless of course you are announcing a more specific prefix than the authentic one. -- Nathan Ward
Nathan Ward wrote:
On 13/09/2008, at 5:48 PM, Matthew Moyle-Croft wrote:
Arnaud de Prelle wrote:
I think that most of us (me included) are already using it but the problem is that they don't have BGP collectors everywhere in the world. This is in fact a generic issue for BGP monitoring.
In this case it's very important to have a lot of collectors broadly distributed listening in many ASes.
For example:
If I know there are two BGP collectors driving this service, and they're in, say, AS701 and AS1239, then if I wanted to do a partial hijack (which might be good enough for my evil purposes) then I could advertise a path which had those ASes stuffed in it and prevent downstream collectors in AS701 and AS1239 from learning the hijack path.
Note that the attack becomes less and less effective if you're path stuffing ASes, as it will be preferred by fewer and fewer networks. Put collection points in say 10 networks, and the attack becomes pretty useless. Unless of course you are announcing a more specific prefix than the authentic one. Absolutely - but it depends how wide you want the hijack - a global one is very obvious, but you can see that a very narrow one of some sites it might be harder (take longer) to detect and live longer.
ie. If I just wanted to disrupt a website to a country or region for political reasons or just to get the ad revenue for a small amount of time, then it might be acceptable to limit the scale in order to evade detection. I'm not saying this is the end of the world, just reenforcing that widely distributed BGP monitors are necessary for detection. It might be that various projects which have these distributed tools etc can help by becoming feeds for these kinds of notification projects. MMC
-- Nathan Ward
i am occasionally asked if there have been real bgp attacks (not slips). the answer is, of course yes, but there are none which can be publicly described. when bucks and embarrassment are involved, security through obscurity seems to rule. but tony and alex did us an enormous favor by publicly conducting such an attack, see http://www.merit.edu/mail.archives/nanog/msg10357.html so, what i want to know is which, if any of the tools being discussed on this thread *actually* did or could detect and/or mitigate the tony/alex defcon attack. i appreciate the dozens of tools that detect and mitigate finger or brain fumbles. but those are not where the black hats are gonna go to make the big bucks. randy
On 13/09/2008, at 7:21 PM, Randy Bush wrote:
i am occasionally asked if there have been real bgp attacks (not slips). the answer is, of course yes, but there are none which can be publicly described. when bucks and embarrassment are involved, security through obscurity seems to rule.
but tony and alex did us an enormous favor by publicly conducting such an attack, see http://www.merit.edu/mail.archives/nanog/msg10357.html
so, what i want to know is which, if any of the tools being discussed on this thread *actually* did or could detect and/or mitigate the tony/ alex defcon attack.
i appreciate the dozens of tools that detect and mitigate finger or brain fumbles. but those are not where the black hats are gonna go to make the big bucks.
Yep, that was my point before. My concern is that unless there is big bold text saying that it's not a solution, and then reference to longer optional text for those that care about why, people will get a false sense of security. -- Nathan Ward
At 03:07 PM 12-09-08 +0100, Andy Davidson wrote:
On 12 Sep 2008, at 13:49, Nathan Ward wrote:
On 12/09/2008, at 10:42 PM, Gadi Evron wrote:
Hi, WatchMy.Net is a new community service to alert you when your prefix has been hijacked, in real-time. I just had a quick play with this, as I've been considering hacking together something similar.
Everyone with any interest in this topic should look at the MyASN service from the RIPE NCC (which I use and think is brilliant).
http://www.ris.ripe.net/myasn.html
" The MyASN service notifies network operators when a prefix is announced with an incorrect AS path. An AS path is seen as incorrect when it does not match with a regular expression. As not everyone is familiar with regular expressions, MyASN provides several easy ways to define typical checks, like "the origin of this prefix must be AS x" or "the origin of this prefix must be AS x and transit may be provided through y or z". However, as any AS path regular expression can be set, the MyASN service is suitable for regular expressions gurus as well. "
To address Nathan's point, I recommend the RIPE service because for such a service to be ubiquitously useful, it needs to have many eyes (a view of routing tables at lots of points on the internet) which is where the very well peered situation of RIS comes into effect. At the last RIPE meeting I think i saw RIS had over 600 peers, which it collects at internet exchange points all over the world.
I have used IAR, PHAS and MyASN and I can say I would not recommend myASN. It is a cumbersome system and very non-intuitive. It is based on an ASN-centric model, whereby each ASN is in its own realm. So if you manage *one* ASN, perhaps this system might work for you. But if you have about 10 ASNs you want to manage, in one central spot, you are out of luck here. Also, you would expect the system to "auto-learn" what prefixes exist under your ASN and then you would have perhaps check boxes to disable or enable monitoring for specific prefixes. With myASN you have to manually type in each and every prefix you have. The same holds true for the newer http://ripe.net/is/alarms/. They also differentiate between origin and transit ASN. Their summary view doesn't show which prefixes are being monitored. No help or FAQ available yet on the beta alarms system. PHAS doesn't look at ASNs just prefixes. You have to register each and every prefix via their site at: http://phas.netsec.colostate.edu/subscribe.html Problem is to remove prefixes you have to totally unsubscribe via: http://phas.netsec.colostate.edu/unsubscribe.html You can't manage/unsubscribe individual prefixes. And if you registered years ago before they instituted the ID and key factor for unsubscribing (as I did), you have no way to figure out how to unsubscribe from their email notices. Their notices provide many false alarms based on my observation over the past few years. The best system so far would be IAR: http://iar.cs.unm.edu/ The email notices are pretty much on time and accurate. Problem is they have changed the system and I believe some forum page/link has gone lost that allows one to manage existing subscriptions as per: http://iar.cs.unm.edu/alerts.php#email Now for the new boy in town - Watchmy.net. When you register it doesn't say you need at least an 8 char pswd. I did 7. So it wipes out all form data entered (name, phone number, etc.) and makes you start again from scratch. The Web interface seems the most intuitive of all 4 but since I am just starting to use it - I will only discover the warts over the next week. In general, academic systems like UNM and Colostate are the baby of some post-doc and then disappear after they leave or move on. By nature, CS and EE departments don't like ot care to run production systems. That is why I had high hopes for the RIPE system, which unfortunately, IMHO, is the worst. It is funded via membership dues and one would expect that the authors would poll the RIPE community for what functionality they would need. That has not been done. Even when they get feedback (as far back as 2003) they just ignore it and continue doing the development based on what they *believe* is what we need, rather than *asking* what we need. That is why I am hoping that Watchmy.Net will not only listen to the community needs, but also have a committment for long term maintenance. Regards, Hank
best wishes Andy
On Sun, 14 Sep 2008, Hank Nussbacher wrote:
I have used IAR, PHAS and MyASN and I can say I would not recommend myASN. It is a cumbersome system and very non-intuitive. It is based on an ASN-centric model, whereby each ASN is in its own realm. So if you manage *one* ASN, perhaps this system might work for you. But if you have about 10 ASNs you want to manage, in one central spot, you are out of luck here. Also, you would expect the system to "auto-learn" what prefixes exist under your ASN and then you would have perhaps check boxes to disable or enable monitoring for specific prefixes. With myASN you have to manually type in each and every prefix you have. The same holds true for the newer http://ripe.net/is/alarms/. They also differentiate between origin and transit ASN. Their summary view doesn't show which prefixes are being monitored. No help or FAQ available yet on the beta alarms system.
I think I'll need to chime in here, being a user of myASN. I have not tested other systems. To me it seems to work OK. Manual typing etc. is minimized because you can export and import XML; this is the way I entered our prefix information in the database (though if the prefixes change often, maybe updates would be a chore). The database itself AFAIR does not have any restriction on what it's monitoring when you use the advanced interface -- you can insert any AS-path regexes you want, and that way we're managing prefixes from some ~5-10 ASNs. AFAICS, the ASN in login form is only used for identification purposes and in some shortcuts in the basic interface. I agree that to kickstart monitoring, an auto-learning feature could be used. And that documentation is somewhat sparse :-). I've gotten a couple of alarms which may or may have been bogus. One academic site was purpotedly advertising one of our prefixes duing one day for a couple of 1-2 hour periods. Upon asking they said they had not done anything special, and said that their upstreams wouldn't accept that kind of prefix from them anyway. Not sure if that was true, but I didn't purse this further. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that. For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought. - S -----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Mail being what it is today, testing message delivery is an excellent idea. I'll implement that feature this weekend. Andy Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Fri, 12 Sep 2008, Andrew Fried wrote:
Mail being what it is today, testing message delivery is an excellent idea. I'll implement that feature this weekend.
I think he meant he wants to be able to get an example alert to his inbox on registration/on request so he can special filters which can wake him up. Gadi.
Andy
Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Ah, both reasons really; setup mail flow rules, verify mail delivery, and create appropriate whitelist entries if need be to make sure that notifications tend not to mysteriously vanish. All general things that I like to do for any new mail-based monitoring system. - S -----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:50 PM To: Andrew Fried Cc: Skywing; Kevin Oberman; nanog@merit.edu Subject: Re: community real-time BGP hijack notification service On Fri, 12 Sep 2008, Andrew Fried wrote:
Mail being what it is today, testing message delivery is an excellent idea. I'll implement that feature this weekend.
I think he meant he wants to be able to get an example alert to his inbox on registration/on request so he can special filters which can wake him up. Gadi.
Andy
Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Fri, 12 Sep 2008, Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
Good point. Any suggestions from folks here on how they would like it to be built?
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Gadi Evron wrote:
On Fri, 12 Sep 2008, Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
Good point. Any suggestions from folks here on how they would like it to be built?
Could you throw up a page that tells a little about what logic is used, what you check, where you get feeds from and how often, so that people can evaluate the differences between checkmy.net, phas, IRU and MYAsn? --Heather
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Fri, 12 Sep 2008, Heather Schiller wrote:
Gadi Evron wrote:
On Fri, 12 Sep 2008, Skywing wrote:
It might be useful to have an option to generate an example alert mail for purposes of setting up necessary mail processing rules and that sort. Just a thought.
Good point. Any suggestions from folks here on how they would like it to be built?
Could you throw up a page that tells a little about what logic is used, what you check, where you get feeds from and how often, so that people can evaluate the differences between checkmy.net, phas, IRU and MYAsn?
--Heather
I don't see why not. But whilw we take this very seriously and so release only when a phase is done, it is a free-time based project. Therefore, while we will definitely do so... I can't commit it will be very soon. Much like other coders, while we appreciate documentation.. being very busy theorizing on what we already did will take some motivational coffee or a free evening. Comparing ourselves to other services... well, maybe some magazine will run a comperative testing. :) Gadi.
- S
-----Original Message----- From: Gadi Evron [mailto:ge@linuxbox.org] Sent: Friday, September 12, 2008 3:13 PM To: Kevin Oberman Cc: nanog@merit.edu Subject: Re: community real-time BGP hijack notification service
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
I am sure we can fix that, Thanks for the comment!
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer.
Please let us know if you encounter any issues.
-- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
On Fri, 12 Sep 2008, Kevin Oberman wrote:
Looks interesting, but it only takes a fairly short list of ASNs for a prefix. For our big CIDR blocks, we have WAY too many ASNs to enter them all, so it's pretty useless for me. I need to be able to enter at very least a dozen ASes and I suspect may folks have a LOT more then that.
We made many fixes over the last few days, as well as added a few more feeds. Any volunteers to give us more feeds? :) One of the fixes is that you can add many more ASs now, which should resolve your previous issues. Please let us know if you find any other problems or think of any suggestions, big and small. Gadi.
For now, I'll enter some shorter pieces from the block, but I'm most concerned with the pieces that are not currently assigned, so are available for hijack. I have added the larger, unassigned blocks. I'll start adding assigned bits and pieces as well as unassigned pieces, but being able to put all valid origin ASes in the list for the full blocks would be a lot nicer. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
participants (13)
-
Andrew Fried -
Andy Davidson -
Arnaud de Prelle -
Christian Koch -
Gadi Evron -
Hank Nussbacher -
Heather Schiller -
Kevin Oberman -
Matthew Moyle-Croft -
Nathan Ward -
Pekka Savola -
Randy Bush -
Skywing