This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] All-Probe Traceroute + detect RFC1918 addresses
- Previous message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
- Next message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at massar.ch
Fri Sep 17 09:47:12 CEST 2021
> On 20210916, at 16:28, Max Grobecker <max.grobecker at ml.grobecker.info> 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
- Previous message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
- Next message (by thread): [atlas] All-Probe Traceroute + detect RFC1918 addresses
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]