If I was an ISP had networks from UA and RU and my Cogent peering was removed from Russia, I might move some of my traffic through my partner in Ukraine, who does have a peering arrangement with Cogent. I haven't confirmed that is what happened, but you would see this kind of shift I think if they did that.
I'm a security guy and not a CCIE so perhaps a Cisco engineer here can weigh in.
What's interesting (to me, at least) is that there's an (signed) ROA for 31.148.149/24 and AS212463 is listed (IRR) as a valid origin AS -- AS35004 isn't.
All things considered, though, I'd find an explanation of "yeah, didn't have time to update the route objects yet" to be completely acceptable.
Same situation with 95.47.59/24, by the way.
(I let my Cisco certs lapse a decade or so ago, although I've certainly originated a prefix or two over the years.)
I highly recommend Kurose/Ross' Computer Networking book for a place to start. As the title suggests, it's a "top down approach" starting at the application layer, so if you're familiar with application network programming (and especially HTTP) you can probably skip the early parts of the book. It then details routing protocols, of which there are 2 major kinds: interior routing protocols (RIP, OSPF, EIGRP, iBGP, et al) and exterior routing protocols (eBGP). The former is for routing within your "autonomous system", the latter is for routing between autonomous systems.
It goes into detail. If you're just starting out, get a Network+, Security+ or any other systems administration, security or networking certification that covers the basics of networking and internetworking.
The advertising ASN does not share any upstream peers. So it might not be a hijack, but it is an interesting event and could be related to the conflict.
Untangling ISPs that have operated in both countries or with subsidiaries is going to get messy while infrastructure is also getting destroyed.
The issue isn't the particular show or analogy. It's the implication of your comment that everyone should, unrealistically, try to be an expert in everything and thereby never seek a more concise "intuition" when a few hundred hours of research and self-study could be had.
Yeah, someone new and experienced should have all the effort possible put into them by others trying to catch them up..
on the other hand the whole 'ELI5' phenomenon really has no place in niches that really have no point to be generalized for the average population.
'ELI5' breaks down when comprehension of multiple topics is required for elucidation; i.e.: a layman's explanation of quantum chromodynamics requires many other base level comprehensions before it can be tidily explained.
The 'ELI5' thing is cute, and it has a place -- but it shouldn't be generalized to all education across the board.
I feel this way whenever I have to explain that, no, sex is not a binary related to XX or XY, there's lots of genetic variations (many of which don't fall neatly into male or female).
There's lots of stuff like that across a wide range of disciplines -- computer science, biology, sociology, physics, economics, etc.
For sure. Life is beautiful and nuanced. Anything significant is complex, and quantizing a spectrum, or at worst, making it monochromatic, takes something from its beauty.
Mayor Goodway is the mayor of fake-San-Francisco ("Adventure Bay") in the kids' show "Paw Patrol". Also, she is a woman, so I'm not sure why Mayor Goodway is referred to as "he"
It is quite plausible that Russia would try to take down parts of Ukraine internet given everything going on.
Alternatively, could simply be someone fat-fingering things, given the insane numbers of blocks that RosKomNadzon has been putting in today (Facebook, Twitter, etc)
I read an article (in Russian, will link later) outlining a plan to copy current BGP tables, update them so that the Russian internal internet space is encircled with government-controlled ASes, and filter or block any outside access, while making the BGP inside Russia look synchronized with the rest of the world. Of course this applies to all BGP announcements from outside the perimeter.
Not exactly a great firewall with packet inspection, but still something to prevent any possibility to access any resources except whitelisted ones, or to run a VPN to the outside.
If Russia is preparing to up its information warfare game does this give them better defenses against inbound attacks? While letting FSB selectively allow outbound attacks?
Gentle reminder: You can still generate valid TLS certificates for arbitrary domains with BGP hijack. Hide yo logins, hide yo passwords, and hide yo persistent sessions too, they hijackin' errrbudy up in here
I'm not sure CT logs would help in practice. Assuming a site owner religiously monitors CT logs (who actually does that?), notices a cert they didn't mean to issue, and then issues a CRL or OCSP change (do most people even know how to do that?), the client application has to download the lists and respect it, and many (most?) clients do not.
The site owner may know about the compromised cert, but the users/clients will be blissfully ignorant and unable to do anything about it.
If you can hijack the traffic you can respond to http challenges from CAs and they will give you a valid certificate. In theory the certificate owner should spot this via CT, but it’s not automatic.
- You own the domain trust.org pointing to IP address 2.3.4.5.
- Someone performs a BGP hijack on 2.3.4.5 and now hosts their own server on 2.3.4.5.
- They then ask Letsencrypt for a certificate to prove they are trust.org. Letsencrypt provides them a token to host on their website to prove they control it.
- Letsencrypt does a DNS lookup, sees trust.org resolves to 2.3.4.5, and performs a http request to that website to check for a token which the hijacker has duly placed on their server at 2.3.4.5.
- Letsencrypt issues a certificate for trust.org, which is now valid and controlled by the hijacker.
None of this requires access to CAs installed on anyones machine, because Letsencrypt is widely trusted and they are the ones issuing the cert.
When the CA is giving you, supposedly the owner of someguy.example, a new certificate, how do they verify that you're you first?
One common way is they tell you a magic, unique string and you serve it under someguy.example/.well-known/whatever and they connect to you and verify it's there and matches. But if BGP is being hijacked, when they connect to you, they could really be connecting to some scammer. How would they know? So now some scammer has proved they're you and they'll be given a valid cert for someguy.example.
The other common verification methods have similar holes.
CA's verify the person that the domain is pointing to. If the domain is pointing to a malicious server (due to bgp making IP addresses belong to an evil person), then the CA will verify the malicious server instead.
E-mail, DNS, and HTTP validation are all vulnerable (so, all the methods besides ACME). As for DNS validation, DNSSEC is opt-in; if one of the 350 different Certificate Authorities doesn't do mandatory stub validation, then the hijack still works on them.
There's actually multiple attacks using BGP. You can either hijack the DNS or E-mail server's IP and spoof records, or you can hijack the IP of the target host and spoof an HTTP response. Or you could try all 3 to maximize your chances.
DNSSEC is, unsurprisingly, designed to secure DNS only. It only tells you that the answer you received is authentic. DNSSEC would prevent a DNS server being hijacked via BGP being evil in that it couldn't give bad answers.
It however doesn't typically help in a BGP hijack. The DNS answer is authentic, but the server at the answer given isn't.
As tptacek will tell you, there's never any situation where DNSSEC would help. For instance, it doesn't mean your own DNS lookups to 1.1.1.1 are secure, but it does mean Libya is a CA for bit.ly.
Although trying to turn it on did take Slack and HBO down in the past, so someone out there cares.
Never helps. Causes outages. Route all your DNS through 1.1.1.1 or 8.8.8.8 instead. Sheesh. In Ancient Rome, weren't dictators expected to vacate office once their task had been accomplished and decentralized solutions were ready to once again take hold? Why is it that I always feel the heat whenever I voice words of support for DNSSEC?
DNSSEC worked mostly fine for Slack, except that their DNS provider, Route 53, initially had a bug where wildcard records on DNSSEC would not get correctly signed. It was when Slack panicked and tried to turn off DNSSEC when they completely bungled it and borked their whole setup.
This is the funniest apology for DNSSEC I've ever read. It's fine, as long as you never try to turn it off! Or use Route53! Don't do that, or your whole site will fall off the Internet for a day. Got it!
As a well-known person on HN, that amount of snark is unbecoming of you. FWIW, you can bork your own system just as much, if not even more so, with HSTS headers. And also with DNS in general; how many people have mucked up a DNS setting and then have no recourse but to wait it out? The issue was not DNSSEC, but Slack who panicked and pulled the plug on themselves.
It's not snark if you're mocking the person you're talking to. That's just disrespect. Maybe he's had bad experiences in the past with DNSSEC that are causing him to forget himself. I feel like he's been talking down to me too.
Read it again. I'm not "mocking the person I'm talking to". I don't even know the person I'm talking to. I'm mocking the statement they made, that DNSSEC is fine, and when it blows your whole site off the Internet because you dared turn it off after it immediately caused problems the moment it was turned on, well, you were just holding it wrong. It really is funny! Read their comment again, too!
I suppose I could be less snarky, but my snark here is substantive, and I'm comfortable with what it says about my seriousness. You're going to have to do better than trying to work the refs here.
DNSSEC could be used to protect against it, if TLS cert issuing policies were tightened by folks who mandate the minimum verification requirements for CAs, but this is not currently done. (eg Let's Encrypt supports DNS verification as one mechanism currently, but it also supports plaintext HTTP which is vulnerable to BGP hijack)
This says the prefix being announced by two ASNs is only a /24, which is kind of narrow for a hijack? Considering the countries involved, reporting this as a hijack will inevitably lead to people assuming it is related to the current conflict.
A /24 wouldn't propagate much farther than the nearest IX and immediate peers, as presumably peers have learned to aggregate and filter in the last 20 years. At face value, it really seems like a shift to backup routes. Also, state level attacker view, hijacking a route from another ASN is a bit 3rd world, as if you were a superpower, you'd have already hacked the routers in question and would just loop traffic through and MPLS tunnel to your analysis centre.
> A /24 wouldn't propagate much farther than the nearest IX and immediate peers, as presumably peers have learned to aggregate and filter in the last 20 years.
... and yet the global BGP table is absolutely full of /24s.
AS212463 only announces 2 /24 prefixes in total so it being only 1 isn't a big sway one way or the other. The company being the same just across the 2 countries makes it less likely to be something militarily malicious but doesn't necessarily mean it's unrelated to the current conflict.
Is now being announced by AS35004 which HE shows is Ukrainian hosting provider https://netgroup.ua/
But the "Country of origin" of the AS is listed as Russian, which is perhaps where the confusion comes from. https://bgp.he.net/AS35004
About 95% of new AS35004's traffic goes through this peer: (which is Ukrainian) https://bgp.he.net/AS13249
And this peer: (which is Ukrainian) https://bgp.he.net/AS3326
Both of which Peer with Cogent.
What is interesting is that Cogent today decided to cut service to Russia. https://www.reuters.com/technology/us-firm-cogent-cutting-in...
If I was an ISP had networks from UA and RU and my Cogent peering was removed from Russia, I might move some of my traffic through my partner in Ukraine, who does have a peering arrangement with Cogent. I haven't confirmed that is what happened, but you would see this kind of shift I think if they did that.
I'm a security guy and not a CCIE so perhaps a Cisco engineer here can weigh in.