Managed switches typically have ACL support. I get the KISS principle, but this setup seems to be trading security for simplicity.
It is true that an attacker could flood the MAC table, spoof their MAC, etc, after compromising a layer-2 adjacent host and use that to manipulate traffic flows. That's somewhat disturbing, but no Customer backup data should be hitting their network outside of SSH anyway. I think the potential is more for DoS than compromise of confidentiality or integrity.
I really admire rsync.net's simplicity, but dumb switches give me the willies. I feel blind not having per-interface counters, at the very least. If nothing else, I'd like to be able to reconcile the counters coming from my OS interface with the switch in troubleshooting scenarios.
I'm sure those packets (consisting entirely of OpenSSH) will be very useful to them
Quantum computing is improving everyday, and new methods of defeating RSA are being researched:
Multicast and broadcast sure, but dumb switches will still keep mac-address>port mapping. If the router sends to 52:54:00:ad:ra:a7, the dumb switch will remember that's on port 7 (having seen traffic from it recently - if only an arp reply) and only send the packet to port 7.
Hubs (remember them!) will blast every packet to every port.
Which are encrypted in flight...if they aren't then anyone on the 30 machines between customer and final destination can also see the backups coming in from customers.
It's a choice--everything in security is a risk-management assessment, but I'm surprised rsync.net was able to get so many security certifications with this setup.
Same applies if someone takes over the firewall, machine on the last hop before they hit port 22.
In a world where stuff like this https://www.helpnetsecurity.com/2020/09/01/zero-day-cisco-en... routinely happens there is a benefit to forgoing all of that when it makes sense.
tcpdump: eth0: You don't have permission to capture on that device
(socket: Operation not permitted)