Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
> On 20210917, at 21:20, Bjørn Mork wrote: > [..] >> Leaking packets from addresse that do not belong to you does. > > Yes. And the point is that you cannot tell if there is a leakage unless > you are able to detect the network borders. Which you can't by counting > traceroute hops. In the example I gave it is all quite obvious actually... as there are multiple ASNs in the path and then RFC1918... Noting again, that seeing RFC1918 a few hops away is a clear indicator that there is likely a possibility to spoof as they don't even bother to filter the obvious. Greets, Jeroen
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
> On 20210916, at 16:28, Max Grobecker wrote: > > Hi Jeroen, > > >> We got CAIDAs spoofer project, but that primarily afaik checks that by doing >> connections, not by checking ICMP returns. >> >> I just saw towards 213.244.71.2 : >> [...] >> Which means the whole path till that IP was not doing any kind of RPF >> thus spoofing anything else would be possible too. > > > Maybe I have a wrong imagination on how this spoofing testing is done, but... > If you spoof the source address you simply can't get any return. Your > traceroute proves, that your packet leaves the network, > but it's not proof for, that BCP38 was not implemented. A traceroute with a spoofed address indeed would not return anything, as you are not the source. This is about doing a traceroute, from whatever your host/probe is configured for, and thus also means that a NAT would change that source address. For instance a result (towards the above IP) could look like; ... 11 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.672 ms 31.720 ms Bundle-Ether42.br03.mrs01.pccwbtn.net (63.223.38.78) 29.302 ms 12 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.549 ms 31.094 ms 31.863 ms 13 63.222.97.82 (63.222.97.82) 76.494 ms 10.74.42.53 (10.74.42.53) 81.986 ms 63.222.97.90 (63.222.97.90) 77.033 ms 14 * * * 15 * * 10.74.19.109 (10.74.19.109) 87.029 ms 16 * * * which shows that hop 15 was able to respond with RFC1918, all the hops upto that point are thus not bothering to check if the source was allowed to send; I can tell you RFC1918 should never be visible there... Yes, the ISP that allowed this traceroute is very aware of this problem, at least they filter prefixes at the edge, thus hosts cannot spoof, but their transit/peering links they can spoof what they want. Which leads to them having big issues when a spoofed DNS amp DDoS comes in as they have little clue where it comes from, thus they understand they need to fix this. but likely many places, while one can convert this to a dollar amount lost (when a DDoS happens), there are other more urgent things for them. > Because IF your packets were forwarded with spoofed source, you won't got any > response, not even from the first hop. Correct, but this is more about recognizing where filtering does not happen, as that indicates that other paths over that route can also spoof if their edges do not filter at source. > Obviously, because your false source IP would get the ICMP returns, not your > probe. > > So, IMHO, it's more likely to me your traceroute is proof for a NAT and not > for spoofing. If one sees RFC1918 in a traceroute (especially >5 hops away, thus just not the client->CPE hops), it indicates that every hop in the middle is not filtering at least RFC1918; more likely they are thus just doing any kind of reverse prefix filtering aka the largest part of BCP38. Greets, Jeroen
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
> On 20210915, at 19:25, Stephen Strowes wrote: > > > On 9/15/21 11:32 AM, Jeroen Massar via ripe-atlas wrote: >> Hi Folks, >> >> Has anybody ever run a all-probe traceroute and then to detect any RFC1918 >> addresses in there? (though many probes will have locally some RFC1918) > > > Since probes are running measurements to many targets already, the full > dataset will uncover a lot without having to run more measurements. > > A quick query: > https://gist.github.com/sdstrowes/e9d4a3c7c03dd1aafa3198333cc39ffa > > Out of ~106M IPv4 traceroutes, this finds ~6M that contain 10.0.0.0/8 in an > ICMP response more than 4 hops from the origin. That's not the smartest > approach, but it's a good ballpark of what's in the data. > > It'd be reasonably easy to take that and whittle it down to a set of probes > and/or probe ASNs that see this. With more work it'd be possible to identify > ASNs on the forward path as a strong hint (asymmetric routing to one side) of > where these pass through. Good one. Indeed, if one can go through the existing traceroute data, one would have the possibility to detect these. Any way we could automate this into a nice warning page along with the probability that an ASN is the cause of passing on RFC1918 (and thus likely not filtering at all)? Greets, Jeroen
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
> On 20210915, at 21:59, Bjørn Mork wrote: > > Philip Homburg writes: > >> As far as I know, this a well known Juniper bug where their routers >> forward errors ICMPs without checking whether the source address is >> link local. > > Thinking about this... If you can't verify the source, which with LL you cannot as they are on every interface around the world, it is spoofable. Do you really want to receive a fe80::/10 at your recursive DNS service as a request (which could be valid, locally). fe80::/10 should never have a TTL other than 1... it is link-local. The whole point of the thread is to find networks that allow non-routed addresses, the standard BCP38 trick. Detecting RFC1918 in traceroutes might just be a cheap-ish way to identify these kind of networks (especially when outbound NAT happens, thus spoofing gets killed). Greets, Jeroen
[atlas] All-Probe Traceroute + detect RFC1918 addresses
Hi Folks, Has anybody ever run a all-probe traceroute and then to detect any RFC1918 addresses in there? (though many probes will have locally some RFC1918) We got CAIDAs spoofer project, but that primarily afaik checks that by doing connections, not by checking ICMP returns. I just saw towards 213.244.71.2 : 11 Bundle-Ether42.br03.mrs01.pccwbtn.net (63.223.38.78) 29.068 ms 29.301 ms 29.129 ms 12 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.462 ms 31.410 ms 31.459 ms 13 10.74.42.10 (10.74.42.10) 77.574 ms 63.222.97.82 (63.222.97.82) 73.651 ms 63.222.97.90 (63.222.97.90) 73.514 ms 14 10.74.42.129 (10.74.42.129) 82.789 ms * 10.74.19.29 (10.74.19.29) 78.695 ms 15 * * 10.74.25.22 (10.74.25.22) 78.914 ms 16 * * 10.74.25.22 (10.74.25.22) 78.875 ms 17 * * * Which means the whole path till that IP was not doing any kind of RPF thus spoofing anything else would be possible too. At least one could kick PCCW in this case... but likely there are others. And as we are in 2021... a hall of shame might be appropriate... Of course, one should also do that for IPv6; though I expect outside the stray ULA address (thank you apple; though they are fixing that ULA issue with homepods apparently) very little of it, though "meten is weten" (measuring is knowing). Greets, Jeroen
