A PC connected to a switch port should only be able to see traffic that is destined for the PC or is broadcast/multicast traffic. You should not see any other unicast traffic to other PC on different ports ( except for unknow unicast flooded packets ).
There are a number of things you can do to tighten security in this respect eg
blocking multicast/ broadcast
Attached is a link to a Vlan security paper which goes into a lot more detail on layer 2 security issues
There is not much you can really do. There will be a degree of traffic visible on the switch port that is not really aimed at the PC, and if someone downloads ethereal or similar the can see that.
There are two ways you can approach this. You can look at it from a policy position, and tie down user PCs such that they cannot install unauthorised software. In any enterprise, there should be this sort of policy, as even though your admins may have to do a little more install work that would possibly be done by a user, they will have less work in sorting problems when someone has installed anything that takes their fancy and messed up their PC.
That stops them running capture software, the other side is to reduce the amount of traffic seen on a port.
The first step is look at the size of your VLANs. Keep them small and there is less opportunity for traffic to be seen.
Bear in mind that they should see nothing of active conversations, all they should see us broadcast, some multicast and unknown addresses.
Broadcast stuff will be things like ARP, routing hellos/updates, CDP and BPDUs, and *anything* that may decide to ue broadcast as a destination.
CDP is easy - turn it off on any end user port.
Reducing other traffic is more awkward. Routing updates can be supressed by using passive interfaces on end user subnets. This could be fun if you have multiple routers though - in that case you may want an extra VLAN to be a routing VLAN so they can become aware of each other, but not send hellos or updates to users.
BPDUs can be supressed by using BPDU-filter, but that is risky if someone joins two ports together.
Other stuff - that all depends on how well you know your network and the applications running on it. If you *know* there is no peer to peer traffic then look at private VLANs - you can effectivley make it that the only traffic a PC will see is traffic from the router. The router would of course need to be on a promiscuous port!
Port security - if users are all "fixed" eg desktop PCs rather than mobile note books port security will effectively create permannent static CAM entries, meaning traffic to a known address will always be dropped from other ports.
ACLs - they can be useful, but you need to know what you want to acheive. IP ACLs will not be that useful, as they would be applied to the router, and if a PC can see traffic from the other seide of a router, you have a more pressing issue to sort out! The ACLs that may be of use are the mac address ACLs, but there can be quite an admin overhead once you get into that territory - entries will tend to be added, people will ask for access fr a new PC, and not tell you they are scrapping the old one...
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...