Live data from Hacker News

Possible BGP hijack of 1.1.1.1

bgpstream.com

131–140 of 158 posts

Re: Possible BGP hijack of 1.1.1.1

#131

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've worked in two shops that used 1/8 space for loopback addresses for iBGP and nobody that worked there was a dummy.

It is/was not uncommon either[1]. It was never a concern since it wasn't allocated. It being a concern is a very recent phenomenon.

[1] https://www.cisco.com/c/en/us/about/press/internet-protocol-...

Re: Possible BGP hijack of 1.1.1.1

#132

Earlier quoted context omitted.

1) would take about 20 seconds, thanks to Let's Encrypt, but probably only marginally more time for some other CA with an API. 2) Who exactly is staring at CT logs and going "oh, I don't remember this domain using this CA, maybe I should investigate this" ? Sure there's a record of it. Doesn't really matter during an attack, because public attacks like this aren't intended to last long. All you need is a half hour or…

Ok ye the CA system isn't great, but as far as I'm aware, letsencrypt do DNS queries from multiple POPs, so that the route would have to propagate extremely widely to convince them to issue a cert.

A representative of LE commented on HN recently that they do not verify from multiple POPs. But even if they did, that would not stop this attack.

There are hundreds of CAs, and not all of them are going to verify from multiple POPs. You only need your attack to work on one CA for it to be effective against every client on the web.

Even if all CAs verified from multiple POPs (not likely) the attacker will just increase their attack to advertise from multiple ISPs/POPs. The attack is virtually the same, the only thing you need is more network access, which is not hard to get.

Re: Possible BGP hijack of 1.1.1.1

#133

Earlier quoted context omitted.

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've worked in two shops that used 1/8 space for loopback addresses for iBGP and nobody that worked there was a dummy. It is/was not uncommon either[1]. It was never a concern since it wasn't allocated. It being a concern is a very recent phenomenon. [1] https://www.cisco.com/c/en/us/about/press/internet-protocol-...

I'm going to say "yes they were dummies", what made them think that they were going to run out of space in 172.16/12 for router ID /32 loopbacks? If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice.

Re: Possible BGP hijack of 1.1.1.1

#134

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? :-/

It could also be an ISP leaking a loopback identifier into their routes. A lot of ISP's will give their BGP routers lo0 interfaces named things like 1.1.1.1 and 2.2.2.2. It serves as a label and not as an address.

It's been a while, but I can't count the number of times that I've seen that.

Re: Possible BGP hijack of 1.1.1.1

#135

Earlier quoted context omitted.

I've worked in two shops that used 1/8 space for loopback addresses for iBGP and nobody that worked there was a dummy. It is/was not uncommon either[1]. It was never a concern since it wasn't allocated. It being a concern is a very recent phenomenon. [1] https://www.cisco.com/c/en/us/about/press/internet-protocol-...

I'm going to say "yes they were dummies", what made them think that they were going to run out of space in 172.16/12 for router ID /32 loopbacks? If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice.

>"If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice."

Yeah, no. It sounds like you don't really know the history of that block. Or maybe you missed the part where I said it was used as a loopback address. Maybe both.

1.0.0.0/8 was unallocated and was also part of many peoples bogon filters at their edges.

Re: Possible BGP hijack of 1.1.1.1

#136

Earlier quoted context omitted.

I'm going to say "yes they were dummies", what made them think that they were going to run out of space in 172.16/12 for router ID /32 loopbacks? If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice.

>"If there are properly defined private IP space blocks, use those, not some random /8 you think looks nice." Yeah, no. It sounds like you don't really know the history of that block. Or maybe you missed the part where I said it was used as a loopback address. Maybe both. 1.0.0.0/8 was unallocated and was also part of many peoples bogon filters at their edges.

I do know the history of that block, and have been subscribed to the relevant mail lists for bogon filters since 1998. It has never been a good idea to start using a currently unallocated /8 for internal purposes, when plenty of rfc1918 space exists. 1/8 is not the first block to ever be taken out of the bogons list and actually used. Some of the "newer" /8s that were in the last few handed out to the RIRs also had reachability issues when arin, ripe and APNIC started giving out /14 to /22 sized pieces of space to ISPs, because a number of people out there had stale bogon filters handcoded into their routers. It is mostly fixed now.

Re: Possible BGP hijack of 1.1.1.1

#137
post #116

Earlier quoted context omitted.

To be fair, unallocated or unassigned IP space isn't fair game to use for testing outside of an air gapped lab. I've never in my career thought it would be a good idea to "test" unallocated public unicast address space on my edge routers.

On an airgapped lab it is bad practice. Same -though DNS related- with using *.local as a LAN TLD We just should not.

.local is perfectly fine according to the IETF https://tools.ietf.org/html/rfc6762

Re: Possible BGP hijack of 1.1.1.1

#138
post #137
post #116

Earlier quoted context omitted.

On an airgapped lab it is bad practice. Same -though DNS related- with using *.local as a LAN TLD We just should not.

.local is perfectly fine according to the IETF https://tools.ietf.org/html/rfc6762

As you linked, it is reserved for mDNS.

Re: Possible BGP hijack of 1.1.1.1

#139
Are people here really using 1.1.1.1 as a DNS server...? Do people here _really_ think that Cloudflare isn't giving your data away to _someone_? I have been using DNS servers from OpenNIC for sometime now, and I will continue to.

Re: Possible BGP hijack of 1.1.1.1

#140
post #125

Earlier quoted context omitted.

> enormity What's enormous about an IPv4 /12? :) When the German army requested an allocation of IPv6 address space, they were given a /28, but complained that 2^100 IPs is not enough for them and they actually need a /22.

Thats mind boggling... I'd like to read that reasoning about that! (I'm sure there's some German-language publication somewhere...) Did they want each bullet to have a /64?

Well, bullets might move between routers, so they might change the Layer-2 network they are on, and thus might need their own independently routable address. Afaik it is bad practice to route anything smaller than a /64.
Post reply on HN