Hacker News new | ask | show | jobs
by sideshowmel 1915 days ago
Dumb switches will blast packets to all interfaces that are connected. If there's a machine on the switch that's in promiscuous mode, it can see all the packets on the local network (including the backups coming in from customers).

Managed switches typically have ACL support. I get the KISS principle, but this setup seems to be trading security for simplicity.

6 comments

Thie first paragraph is incorrect. A hub will "blast packets to all interfaces that are connected". A switch, even a dumb one, still switches packets. Broadcasts and frames addressed to unknown destinations will flood out all ports, but not unicast frames with destinations currently in the MAC table.

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.

> it can see all the packets on the local network

I'm sure those packets (consisting entirely of OpenSSH) will be very useful to them

Don't be so sure :)

Quantum computing is improving everyday, and new methods of defeating RSA are being researched:

https://eprint.iacr.org/2021/232

OpenSSH now uses eliptic curves, not RSA.
> Dumb switches will blast packets to all interfaces that are connected

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.

They only support SSH (legacy FTP was sunset a year ago), so there's nothing to gain (except for maybe the volume and IP of the customer) by observing other traffic. Which happens to be the same information you can observe anywhere in the path from a customer to their machines.
> including the backups coming in from customers.

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.

True, but the packets in-flight can take different routes. If you have a machine on the switch, you know you've captured all the packets that were in-flight. This make it easier to break the encrypted packets.

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.

> If you have a machine on the switch, you know you've captured all the packets that were in-flight.

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 -i eth0

tcpdump: eth0: You don't have permission to capture on that device

(socket: Operation not permitted)

You may mean repeater hub.