Meta had(has?) a similar bug with one of their business manager features, the attacker has complete control of the initial body text which makes it highly convincing.
Trying to report this was an exercise in futility, I guess they get so much beg bounty spam that their security submission process filters out the occasional legitimate issue.
I've started to assume that any non-chain hotel is compromised after losing $2k to hackers that completely owned the hotel's email system. Thankfully DMARC made it irrefutable that it was their system at fault and they assumed liability. BEC is shockingly common and difficult to detect until it's too late.
I recently had to go through the recovery flow for an admin account and it was wild. Despite Google manually unlocking the account and giving me a reset link, every login was forced to authenticate via SMS using the (removed) phone number. Luckily I was able to get a hold of it and get the code, but even after adding a TOTP and security key 2FA, further logins still required SMS.
It feels like the security team made this change to reduce account hijacking but it's at complete odds with the recovery flow and modern security practices. Better hope your phone number doesn't get hijacked or recycled because it's the key to your account now, security keys be damned.
Every shared hosting provider has this risk. Critical projects should be using dedicated or VPS hosting, preferably with encrypted filesystems too as even datacenter techs can fall victim to social engineering.
I'm pretty surprised that they got away with unsigned updates and shared hosting as long as they did. I wonder how many similar popular projects are out there on dodgy infrastructure.
Yes, that's standardized but is only rated for up to 30 meters at the higher speeds you get from it, so it's not very useful outside of server room / data center applications and you probably want to be using fiber at that point.
The bottleneck with SFTP / SCP / SSH is usually the server software - SSH can multiplex streams, so it implements its own TCP-style sliding windows for channel data. Unfortunately OpenSSH and similar server implementations suffer from the exact same problems that TCP did, where the windows don't scale up to modern connection speeds, so the maximum data in-flight quickly gets limited at higher BDPs.
HPN-SSH[1] resolves this but isn't widely deployed.
OP mentions using "Cat 7" cables - please don't buy these. Cat 7 isn't something that exists in TIA/EIA standards, only in ISO/IEC and it requires GG45 or TERA connectors. Cat 7 with RJ45 connectors isn't standardized, so you have no idea what you're actually getting. Stick with pure copper Cat 6A.
Cloudflare will actually slow down TTFB for small, less popular sites since they don't maintain a keepalive connection to the origin. This means you pay an additional TCP/TLS setup cost from the Cloudflare POP to the origin which is worse than a direct connection. I also tried testing a smart-placed worker and cloudflared, neither of which seemed to help.
This is the same direction that Microsoft is taking Windows. Smart App Control is already rolling out to some regions - no .exe will run without a code signing certificate.
I'm a big fan of flashing OpenWRT on supported APs. You lose central management and setup takes time, but I'm very happy with the stability and no worries about cloud services or vendor lock-in etc.
They're great devices even with the stock firmware, but their wireless drivers are quite dated (no wave2 support, no WPA3, no 802.11r/k/v). They do have a beta package with wave2 support but it's not supported on the low RAM devices like cAP / wAP AC.
If you can live with only 802.11ac, I've had great results flashing OpenWRT onto Mikrotik wAP AC boards. Performance peaks at about ~400mbps TCP throughput at 2x2 MCS-9. WPA3 works without problems. For multi-ap, setting up 802.11r is fairly straightforward, k/v requires some custom scripting to generate the neighbor reports. Be careful not to get the new revision with the two chain radio as the chipset is different and not yet supported by OpenWRT.
Yeah don't do this - I did this once and I ended up having to reinstall since it broke enough stuff that the control panel wouldn't even work afterwards.
"Pretty poor coverage" sounds like the author was relying on Wi-Fi for connectivity. I wouldn't trust an ISP-provided combo modem/router to do anything more than the bare minimum when it comes to wireless, most likely a single chain 2.4 GHz network (and 5 GHz if you're lucky). Replacing it with Google Wifi which is a Wave2 802.11ac 5 GHz device with Beamforming will make a world of difference.
Intentionally supplying old hardware that can't reach high speeds (eg a DOCSIS 2 modem) is actually bad for them as it wastes frequency.
Trying to report this was an exercise in futility, I guess they get so much beg bounty spam that their security submission process filters out the occasional legitimate issue.