Hacker News Reader

Comment by dhess | Hacker News Reader

For those of us who go to the trouble of attempting to lock down our internal networks by changing the default passwords; setting up guest wireless networks; and running SSH and Kerberized NFS/AFP; what do you recommend as a reasonable set of measures to defend against internal attacks? What does Matasano do? I'm particularly interested in strategies for layer 2.

View on HN

Most "enterprise" level switches (eg, Cisco) actually have a reasonable number of features which can be enabled to protect against things like ARP Poisoning. It doesn't need to be as inflexible as a one-to-one static mapping, they can be configured to determine whether ARP requests are valid and respond accordingly.

Extra work, but it is possible.

NAC, sticky mac, max mac/port, trusted DHCP, root guard, bpdu guard, multicast and broadcast storm control, they're all features that can help. Most people don't enable all of them because of management overhead, but each solves a problem that can happen in basically any network. It just a matter of weighing security risk vs the cost of managing the features.

I'm guessing he'll charge for those kinds of answers. :)

I'm not asking him to pentest my network, just some recommended practices :)

Locking down network ports to the mac-address makes this kind of attack in-feasible, but it's rarely done.

It's also really frustrating at a hardware company to have to submit a ticket to IT and wait several days to add a new device to the network or create a private, non-MAC-secured VLAN for testing prototypes.

The little white box could incorporate an Ethernet switch. Then just reconnect an existing device on the network through it, and sniff traffic to find out the MAC.

Whilst possible, this is a) more unsubtle and b) still limited to a single device - but good point.

Reply on news.ycombinator.com