71–80 of 158 posts
I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.
Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/
I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.
Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/
Network engineer here: I'm going to guess that this is a mistaken effort on the part of a Chinese ISP or the GFW to hijack traffic to 1.1.1.1 internally within China, but probably not intended to propagate beyond the major Chinese international-transit-ISP's connections to the global Internet. BCP38 is your friend.
They used AS55994 in China mainland.
In fact, China's ISP do filter via prefix and they all enable URPF. In China, IDC can't announce non-cnnic addresses
Earlier quoted context omitted.
Well, if you control the host behind the IP, you could have any CA issue a challenge, and successfully pass it (e.g. if Let's encrypt uses the erroneous routes). So no. The only thing protecting you would be to have the expected hash of the certificate you expect to see (TOFU - Trust on First use, though you're screwed if you didn't contact 1.1.1.1 before the incident!).
Is there a CAA equivalent for ARIN assignments?
Earlier quoted context omitted.
Traffic meant to go to 1.1.1.1 (cloudflare DNS) could be routed elsewhere. Since this is a common DNS server, this could be used to alter domain resolution for people that use it.
I'm assuming this would/could be done by a malicious party in order to substitute different IP addresses for some sites in an attempt to direct traffic for nefarious purposes. If my host is configured to use DNSSEC would that prevent sites from resolving? If DNSSEC is not employed and a connection is directed to a malicious site (using https) wouldn't that prevent the connection? (I'm afraid I'm out of my depth on th…
Earlier quoted context omitted.
It shouldn't really matter who is currently using that net, it's not a private range :/
Tell Cisco.
I doubt that this is a genuine hijacking attempt. All it takes is a Cisco router and some IT admin making up an address.
Agreed. As many pointed out when the 1.1.1.1 DNS service was introduced, it's an address that is often used (incorrectly) as an internal or temporary IP. Then all it takes is a slight mistake in your route redistribution and suddenly you can find yourself accidentally announcing the prefix to eBGP. I wouldn't be surprised if this becomes a semi-regular occurrence.
Earlier quoted context omitted.
Tell Cisco.
Both Cisco and Juniper use the standardized documentation IP ranges in their example/lab configurations and training materials. https://tools.ietf.org/html/rfc5735 https://tools.ietf.org/html/rfc5737
Earlier quoted context omitted.
1.1.1.1 is a DNS resolver that does not track activity. A BGP compromise means that someone could have compromised it and redirect/intercept traffic of those trusting it to be Cloudflare.
A BGP attack does not compromise the destination host. It reroutes (some) traffic destined for the host. Any traffic using TLS to establish destination authenticity (e.g DNS TLS, DNS over HTTP) or content authenticity (e.g. DNSSEC) would detect the attack, while other types of traffic (traditional DNS) could be exploited.