5 ms·

Don't know if running a dumb switch connected to your ISP is the best infosec policy: https://blogs.cisco.com/manufacturing/the-top-5-reasons-to-avoid-unmanage

Don't know if running a dumb switch connected to your ISP is the best infosec policy: https://blogs.cisco.com/manufacturing/the-top-5-reasons-to-avoid-unmanaged-switches-on-your-machines https://blogs.cisco.com/manufacturing/the-top-5-reasons-to-a...

Jonnax 6y ago
I'm not sure those reasons really apply to their case. Especially since they're running the boxes that it's connected to. They can do resiliency, network segmentation, and monitoring on their platform. What's a Cisco box going to do for them?
- sideshowmel 6y 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.
  - noir_lord 6y ago
    > 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.
    - sideshowmel 6y ago
      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.
      - noir_lord 6y ago
        > 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-enterprise-routers/ 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.
      - mcosta 6y ago
        # tcpdump -i eth0 tcpdump: eth0: You don't have permission to capture on that device (socket: Operation not permitted)
  - ptomato 6y ago
    > 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
    - sideshowmel 6y ago
      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 https://eprint.iacr.org/2021/232
      - anthk 6y ago
        OpenSSH now uses eliptic curves, not RSA.
  - dividuum 6y ago
    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.
  - iso1631 6y ago
    > 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.
  - EvanAnderson 6y ago
    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.
  - deleted 6y ago
    [deleted]
  - fomine3 6y ago
    You may mean repeater hub.
  - deleted 6y ago
    [deleted]
iso1631 6y ago
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. > Disadvantage #3 – Unmanaged switches cannot prioritize traffic 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. > Disadvantage #4 – Unmanaged switches cannot segment network traffic 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)

Jonnax 6y ago

I'm not sure those reasons really apply to their case. Especially since they're running the boxes that it's connected to. They can do resiliency, network segmentation, and monitoring on their platform. What's a Cisco box going to do for them?

sideshowmel 6y 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.
- noir_lord 6y ago
  > 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.
  - sideshowmel 6y ago
    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.
    - noir_lord 6y ago
      > 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-enterprise-routers/ 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.
    - mcosta 6y ago
      # tcpdump -i eth0 tcpdump: eth0: You don't have permission to capture on that device (socket: Operation not permitted)
- ptomato 6y ago
  > 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
  - sideshowmel 6y ago
    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 https://eprint.iacr.org/2021/232
    - anthk 6y ago
      OpenSSH now uses eliptic curves, not RSA.
- dividuum 6y ago
  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.
- iso1631 6y ago
  > 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.
- EvanAnderson 6y ago
  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.
- deleted 6y ago
  [deleted]
- fomine3 6y ago
  You may mean repeater hub.
- deleted 6y ago
  [deleted]

iso1631 6y ago

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. > Disadvantage #3 – Unmanaged switches cannot prioritize traffic 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. > Disadvantage #4 – Unmanaged switches cannot segment network traffic 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)