Under a default or "dumb" switched environment, both the switch and the victim hosts will digest the phony ARP broadcasts sent by tools like Cain or Ettercap. Static ARP entries on a server should be enough to prevent session hijacking, but in order to stop eavesdropping, both victims need static ARP entries. Of course, if you're finding that your static ARP entries are being overwritten by the phony broadcasts, that's something your vendor needs to know about.
A more manageable defense against ARP poisoning attacks is to configure your switches to prevent against MAC address spoofing. Cisco switches, for example, can statically map the MAC address of the interface connected to a given port (good for servers), as well as limit the number of MAC addresses that can appear on a given port (good for workstations, conference rooms, hotel rooms, etc.). More info specific to Cisco switches here: http://www.cisco.com/en/US/products/hw/switches/ps4324/products_configuratio n_guide_chapter09186a0080379add.html PaulM PS - You may find that certain clustering/HA products will use multiple MAC addresses and thus give you headaches in conjunction with Cisco port security configurations. ________________________________ Subject: [Full-Disclosure] Re: Cain and Abel Hi, I have been reading this list for some time now. Haven't contributed much because I am still learning but recently stumbled into a security issue that bothered me. A friend of mine showed me Cain and Abel, after giving it a few runs on my network the results were scary. I have been trying to find a decent solution on how to prevent the main in the middle attack with it however I wasn't able to come up with a good working solution. I have tried to set up static arp mappings on my system however the new ones overwrote the old ones. Also I am not sure but does it also screw with switch's arp tables or just the client ones? Any feedback would be nice _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html