Measuring IP address hijacking with RIPE Atlas?
Currently I work with Greenhost, which is a RIPE LIR that was recently the recipient of a malicious route advertisement, as described here: https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/ IP address hijacking is a real problem. How often does it happen? Which networks are being spoofed, and which networks are the victims? My sense is that we don't have solid up-to-date answers to these questions. I have some thoughts about how to detect successful IP hijacking, using empirical measurements taken from multiple network vantagepoints. I'll hold off on details for now, but I'm aware that the answer is *not* simple analysis of AS paths or traceroute output, both of which are increasingly spoofed. It seems like the RIPE Atlas probe network would be an ideal platform for this type of study. Does such a study already exist? How does one begin to propose a RIPE Atlas project? Regards, Anatole Shaw
Hi Anatole, I agree that hijacking is a problem. The IETF SIDR working group has been developing extensions to BGP to help deal with it [1]. However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack? I wonder if analyzing some of RIPE's passive data sets might be a better approach. Best, --Richard On Apr 17, 2013, at 10:01 AM, Anatole Shaw <ripemat@omni.poc.net> wrote:
Currently I work with Greenhost, which is a RIPE LIR that was recently the recipient of a malicious route advertisement, as described here:
https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/
IP address hijacking is a real problem. How often does it happen? Which networks are being spoofed, and which networks are the victims? My sense is that we don't have solid up-to-date answers to these questions.
I have some thoughts about how to detect successful IP hijacking, using empirical measurements taken from multiple network vantagepoints. I'll hold off on details for now, but I'm aware that the answer is *not* simple analysis of AS paths or traceroute output, both of which are increasingly spoofed.
It seems like the RIPE Atlas probe network would be an ideal platform for this type of study. Does such a study already exist? How does one begin to propose a RIPE Atlas project?
Regards,
Anatole Shaw
On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
If you look at the behavior of a service on a remote host from the vantagepoint of network A, and that behavior is especially distinct from how it appears from network B, then you can infer that it's not the same remote host. Aside from the possibility that it's an anycast address reaching differently-configured hosts, this would serve as an indicator of a hijack. More or less an automated version of what we did at Greenhost to unravel the hijacked Spamhaus name server case. When I talk about "behavior" I'm including everything under the umbrella of OS fingerprinting, network service fingerprinting, etc. And I think there are plenty more possibilities besides.
I wonder if analyzing some of RIPE's passive data sets might be a better approach.
Likely also a valuable approach. Regards, Anatole
On Apr 17, 2013, at 12:51 PM, Anatole Shaw <ripemat@omni.poc.net> wrote:
On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
If you look at the behavior of a service on a remote host from the vantagepoint of network A, and that behavior is especially distinct from how it appears from network B, then you can infer that it's not the same remote host. Aside from the possibility that it's an anycast address reaching differently-configured hosts, this would serve as an indicator of a hijack. More or less an automated version of what we did at Greenhost to unravel the hijacked Spamhaus name server case.
When I talk about "behavior" I'm including everything under the umbrella of OS fingerprinting, network service fingerprinting, etc.
And I think there are plenty more possibilities besides.
Thanks, that actually sounds like a very interesting approach, assuming you can find proper test addresses in the relevant prefixes. (That could be hard, especially for IPv6.) Is this sort of fingerprinting something you could do with the current Atlas UDM capability?
I wonder if analyzing some of RIPE's passive data sets might be a better approach.
Likely also a valuable approach.
It might also be worthwhile to look at combining active and passive measurements. For example, you might observe a change in behavior in Atlas measurements, and check whether there is a change in BGP. --Richard
Regards,
Anatole
When I talk about "behavior" I'm including everything under the umbrella of OS fingerprinting, network service fingerprinting, etc.
some folk consider these invasive randy
Maybe it could be set up on a voluntary basis, so that you would have to opt in to get hijack protection? That would also bound the scope of the measurements you would need, and make the fingerprinting simpler. Notional design 1. ISP that wants to be protected publishes an IP address and a public key for a test host 2. Probe node sends a packet to test host IP address with a nonce 3. Test host responds with signature over nonce 4. Probe node knows hijack is not happening if (1) Signature over nonce is valid under the public key, and (2) Latency is not significantly higher The signature would guarantee that the hijacker wouldn't be able to trivially fake responses. The latency check helps address the case where the hijacker can get real signatures from the real test host (e.g., via a peer). I went ahead and threw a prototype up on GitHub. Only 43 lines of python! <https://github.com/bifurcation/hijack-nonces> On Apr 18, 2013, at 10:21 AM, Randy Bush <randy@psg.com> wrote:
When I talk about "behavior" I'm including everything under the umbrella of OS fingerprinting, network service fingerprinting, etc.
some folk consider these invasive
randy
On Apr 17, 2013, at 12:51 PM, Anatole Shaw <ripemat at omni.poc.net> wrote:
On Wed, Apr 17, 2013 at 11:24:42AM -0400, Richard Barnes wrote:
However, it's not clear to me how Atlas could help measure hijacking. Atlas is an active measurement network. What sort of probes would detect a hijack?
If you look at the behavior of a service on a remote host from the vantagepoint of network A, and that behavior is especially distinct from how it appears from network B, then you can infer that it's not the same remote host. Aside from the possibility that it's an anycast address reaching differently-configured hosts, this would serve as an indicator of a hijack. More or less an automated version of what we did at Greenhost to unravel the hijacked Spamhaus name server case.
I agree getting consistent data about route hijacks is important. But in many cases a prefix hijack will result in blackholing the traffic and no service availability at all. Besides, for the authenticity check of the DNS service we have DNSSEC and I wonder how difficult it'd be for Spamhaus to use it. I heard about the idea of using RIPE Atlas for testing of the ISP anti-spoofing capabilities, similar to what the spoofer project (http://spoofer.csail.mit.edu/) is doing, and I like it. (Although, it might make Atlas look too alike a botnet ;). Andrei
participants (4)
-
Anatole Shaw -
Andrei Robachevsky -
Randy Bush -
Richard Barnes