In an attack where a compromised device facilitates an attack by infecting other machines on the local LAN
How could such a thing be prevented? On a WLC you can disallow wifi client to wifi client comms but the only thing I could think of on a LAN is pvlan but I'm not sure if it can scale.
HIDS/HIPS
Pvlans would work, but you don't see it very often. Scaling isn't too bad. It depends on how standard you can make your setup. HIDS/HIPS is the main way to do it if you own the end points. However, even there you can't drop an agent on everything. Some of the more sophisticated attacks will target printers, and other IoT stuff. You can also drop port ACLs, and block east/west traffic between clients. If you do this you will piss off your support guys who want to RDP to the cube next to them. You can setup some hosts can talk in the ACL, but you don't want a large ACL, or very many different ones. You can also use 802.1x to put different hosts on different VLANs, and ACL there. I like to use 802.1x to drop port based ACLs instead of moving VLANs but either works.
What I usually see is a combination of 802.1x setting VLANs, and agents installed when they can.
-Otanx
Hello I am the one who NACs. :smug:
Exactly the question I have to answer every day. VLANs with ACLs tends to be a common solution, but then there are compromises on those VLANs if there are lots and lots of device type use cases and a customer simply can't scale out to have 30 more specialized VLANs at every location.
Yep, that is why I like doing port based ACLs instead of VLANs. Everything sits on the same VLAN, and an ACL gets applied to the interface based on your auth status. You authenticated as a printer? Here is the printer ACL that lets you talk to the print server only. You authenticated as a security camera? Here is the camera ACL that lets you talk to the DVR. We keep these ACLs short. We really just need them to block or allow the east/west stuff. There is a firewall between our access layer, and the data center/internet. We do more granular filtering there.
-Otanx
Emphasis on keeping things short, or we'll have a thread on TCAM exhaustion. :D
Quote from: deanwebb on February 10, 2021, 12:55:33 PM
Emphasis on keeping things short, or we'll have a thread on TCAM exhaustion. :D
Yep, there are also limits to how long the total length is in bytes for RADIUS to be able to download it to the switch. With the firewall between clients and the servers we don't need to do much. Almost everything gets a two line ACL. Line one denies east/west traffic, and the second line permits any any. Also you can't use a "log" statement on these ACLs. At least on Cisco. The log does not work. Some limitation on port based ACLs.
-Otanx
ACL doesnt sound too bad in that case, then. Thanks for the info.