Ryan Hamel

@mrhamel
2 Followers
101 Following
460 Posts
Senior Network Admin, Was Linux Sysadmin | Autistic, ADHD, cPTSD | He/Him/They/That SOB | Disclaimer: Opinions are my own.
Contacthttps://ryanhamel.com/contact
PronounsHe/Him/They/That SOB
Websitehttps://ryanhamel.com
Dear #YouTube creators. We really, really, really, really, really, really, don't need a rambling introduction followed by "without further ado" or "let's get into it." Just do it.
I come back to Mastodon to check up on everything, then see the annoying rate limited popups again. I really need to get that rack deployed for CalcKey.
@jolyonralph CalcKey is a much better UI. calckey.social, or run your own instance fairly easily.

Is FlexOptix's price worth it? I've never ran into issues with FS SFP's for both 1G/10G, however 80km DWDM has had interesting failure rates.

For my personal rack I'm looking for 40G/100G QSFP's and AOC/DAC that will last forever, as in no spares kept in the drawer.

@briankrebs Same thing can be done with CTRL+Shift+A or on a Mac Cmd+Shift+A

@kwf Fun Fact: NAT was created to quickly get companies onto the Internet without renumbering from whatever public IP space they squatted on.

https://youtu.be/GLrfqtf4txw

THE UNTOLD STORY: How the PIX Firewall and NAT Saved the Internet

YouTube
@encthenet It can depend on the load at the regional DCs, or if an outage is going on too.
In tech we use the term "dogfooding" to refer to eating your own software before throwing up and then chasing your tail / licking yourself 👍🏻

AMD's EPYC Rome Chips Crash After 1044 Days of Uptime

AMD's latest processor revision guide for the EPYC 7002 'Rome' server chips reveals an interesting new bug (errata) that can cause a core on the chip to hang after 1,044 days of uptime (~2.93 years), after which you'll have to reset the server for the chip to run correctly. AMD says it will not fix the issue.

https://www.tomshardware.com/news/amds-epyc-rome-chips-could-hang-after-1044-days-of-uptime

Ouch.

AMD's EPYC Rome Chips Crash After 1,044 Days of Uptime

A clock timer bug brings second-gen EPYCs to a halt.

Tom's Hardware

Gmail's BIMI implementation only requires SPF to match, the DKIM signature can be from any domain.

This means that any shared or misconfigured mail server in a BIMI-enabled domain's SPF records can be a vector for sending spoofed messages with the full BIMI ✅ treatment in Gmail.

Until today, there was a Microsoft 365 configuration that would happily forward messages with a spoofed RFC5321.MailFrom (envelope) address intact, which allowed spoofing messages from any of the 775 domains that are both BIMI-enabled and allow outlook.com in their SPF.

More vectors like this almost certainly exist, the implementations and configurations of email forwarding are extremely complicated, as discussed in the recent Forward Pass paper: https://arxiv.org/abs/2302.07287

BIMI is worse than the status quo, as it enables super-powered phishing based on a single misconfiguration in the extremely complicated and fragile stack that is email.

Other BIMI implementations:

iCloud: properly checks that DKIM matches the From domain
Yahoo: only attaches BIMI treatment to bulk sends with high reputation
Fastmail: vulnerable but also supports Gravatar and uses the same treatment for both so the impact is minimal
Apple Mail + Fastmail: vulnerable with a dangerous treatment

Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy

The critical role played by email has led to a range of extension protocols (e.g., SPF, DKIM, DMARC) designed to protect against the spoofing of email sender domains. These protocols are complex as is, but are further complicated by automated email forwarding -- used by individual users to manage multiple accounts and by mailing lists to redistribute messages. In this paper, we explore how such email forwarding and its implementations can break the implicit assumptions in widely deployed anti-spoofing protocols. Using large-scale empirical measurements of 20 email forwarding services (16 leading email providers and four popular mailing list services), we identify a range of security issues rooted in forwarding behavior and show how they can be combined to reliably evade existing anti-spoofing controls. We further show how these issues allow attackers to not only deliver spoofed email messages to prominent email providers (e.g., Gmail, Microsoft Outlook, and Zoho), but also reliably spoof email on behalf of tens of thousands of popular domains including sensitive domains used by organizations in government (e.g., state.gov), finance (e.g., transunion.com), law (e.g., perkinscoie.com) and news (e.g., washingtonpost.com) among others.

arXiv.org