"Undersecretary of State for Political Affairs Victoria Nuland previously said at a hearing in Congress that the US has "biological research facilities" in Ukraine and she said "we are now in fact quite concerned that Russian troops… may be seeking to gain control of [those labs], so we are working with the Ukrainians on how they can prevent any of those research materials from falling into the hands of Russian forces should they approach."
Ukraine has 26 of these biolabs, all of them funded by the Pentagon. Ukraine is the poorest country in Europe, and isn't exactly a hotbed for scientific research, so you've got to wonder why there are so many of these supposedly harmless biolabs.
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.
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.
> 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.
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.
The only "security risk" i see there is number 1, and that is all to do with physical security.
> Disadvantage #1 – Open ports on unmanaged switches are a security risk
Why? Is there something that would prevent an attacker with physical access from unplugging an existing cable? Does the average managed switch config have mac limits and auto shutdown if a link is lost for just a few seconds? Mac limits are easilly bypassed, even without (permanently) disconnecting the legimate device by inlining an active device, maybe some mac spoofing.
I don't include 802.1x or automatically shutting down a port that loses an uplink as a "simple and effective security precaution", it would be a right pain for many situations. Is the latter even a feature? I certainly haven't come across it (unlike normal portsecurity like limiting number of mac addresses, which just adds to overhead with limited effective security).
> Disadvantage #2 – No resiliency = higher downtime
If my device has one ethernet cable into one switch, how does that help? If my unmanaged switch goes pop, I have a spare that I can put in and be back running in a minute. My managed cisco edge switches take 10+ minutes just to reboot.
If my device has two ethernet cables, one into one unmanaged switch, one into another, losing that switch isn't a problem.
Correct they can't. Managed switches without qos set up can't prioritise traffic either. If your switch is dropping packets, you don't have enough bandwidth. I've seen packet loss when sending 500mbit down a 1G uplink on managed switches, even on QOSed traffic. Indeed I've seen higher priority traffic drop and lower priority not drop. QOS isn't trivial. Ultimately it comes down to how big your buffers are whether your packet gets through or not, so your application should cope with some loss, and if you get too much loss you need more bandwidth. If you have 48 devices connected at 1Gbit each, each firing 100mbit of traffic every second, all bang on the second, with a 10gbit uplink, on paper you only need 4.8gbit of uplink. You'll also need a 600MB packet buffer and expect a lot of delay on your packets, whether you have managed or unmanaged, QOS or no QOS.
Correct, but then if I have 8 desktops in a cluster why wouldn't I pop in a desktop switch with 8 1G ports? I want them all on the same vlan anyway.
> Disadvantage #5 – Unmanaged switches have limited or no tools for monitoring network activity or performance
They don't, but again do I want that for a specific use case?
If I want a managed switch (which I usually do), then I'll spec a managed switch. It's unlikely it will be cisco. If my requirements don't need features of a managed switch then I won't bother.
I find it interesting that there's no mention of preventing broadcast storms, or IGMP snooping - both of which are far more useful for a typical edge switch than qos.
Personally, I tend to use managed switches - indeed I just bought a couple of 24 port TP Link POE switches for an event I'm planning. I'm not 100% sure I'd go for an unmanaged switch in rsync's case, but from your list
1) Doesn't apply -- servers are in a secure location
2) Doesn't apply -- servers are either single connected (so need a physical visit, and replacing an unmanaged switch is far quicker and easier than a managed switch), or they're dual connected to two different switches
3) If they're doing inline management then you might want to carve out a small part of your uplink to prevent yourself from being dossed by a dodgy server (if your server is saturating your uplink bandwidth and you ssh session can't establish that could be an issue. If you've got OOB access on a separate link though, not a problem, and clearly they don't have that problem)
4) Doesn't matter -- they don't want different vlans
5) They presumably measure the bandwidth use of each of their servers. The question thus is "does the ISP give me logs I can rely on for the wan". Personally I wouldn't, but I can see the idea
Spanning tree: Secure network, they aren't going to connect one port to another to cause a storm
IGMP: They presumably aren't using multicast for anything major so bitrates would be very low even if they were there
Reasons to use a firewall or a switch with an ACL in this specific case that I can think of:
1) 2 points of control -- a zero-day on freebsd's firewall could open a port to an unintended source which was listening but blocked by iptables (or bsd's version). If you had a non-bsd firewall it's unlikely the same zero-day would work
2) Port 22 is only open to a specific IP range, again there's a zero-day, and TTL of outbound packets is high enough to establish a session
Reasons to use a managed switch even ignoring firewalling:
1) Reliable traffic stats -- you could guess at these by summing the uplinks of all the connected devices although some packets will be dropped and some may be going to other devices on the network
Reasons to use QOS on a managed switch:
To allow inband managment if something goes wrong. A separate ilo/ipmi/kvm connection would be better for that though.
I don't think they'd need features like span ports (I personally use them all the time, and fibre taps, but I have a different use case which is UDP heavy and loss-intollerent)
> Correct they can't. Managed switches without qos set up can't prioritise traffic either.
> If your switch is dropping packets, you don't have enough bandwidth.
this isn't true, there exist more bottlenecks than just bandwidth, e.g. try sending 10 byte packets instead of 1500 byte packets and watch as your switch starts dropping due to CPU exhaustion
> Ultimately it comes down to how big your buffers are whether your packet gets through or not
not really, traffic prioritisation is about deciding which packets you drop when hitting your limits (or close to), not making sure that you never drop anything
obviously if you're never hitting any bottlenecks: the prioritisation does nothing
Dunno how you'd make a 10 byte packet, the smallest valid ethernet packet was 64 bytes, and I'd expect my switch to forward those at line speed just fine, and drop any runt packets just fine too. Maybe you could hack a network driver to deliver some really nasty frames, but that doesn't seem a likely situation for rsyncs use case -- not compared with a switch failure for other means.
The point about QOS is that it often isn't necessary because you shouldn't be hitting those limits, and if you do you often don't care (because you've got half a dozen identical desktop computers talking to an unmanaged network not doing any relevant dscp marking). In rsyncs case the traffic they're sending is all ssh traffic - what's going to be doing the tagging and differentiation?
802.1x is trivially proxied anyway, unless you don't reconnect when the link is lost. So an attacker with physical access is going to be able to inspect your packets regardless.
The beauty of SSH-only is that you can assume that all of your traffic is being inspected all the time, but you have a protection against that: ssh-encryption and key fingerprints.
If you wanted to confirm ssh host-key validity, I'm sure rsync.net would perform an out-of-band verification. When they emailed me a request to do some server maintenance, I asked for a verification, and they placed a GPG-signed confirmation on their web-server for me to verify.
Used to be you couldn't visit a health-food store without finding that posted somewhere. Then it completely vanished, as if it had never existed, and channelers took over. Even ST-TNG had to get a Ship's Channeler (whom the writers clearly despised). Then channelers evaporated, a fitting end.
https://www.youtube.com/watch?v=fvRpntmUIxs