I assume I can configure most routers to only assign IP addresses to specific MAC addresses, as is possible with wireless routers.
However what if a computer is connected via Ethernet and does not ask for an IP address? What can they skim off the network with a standard network card?
How can I prevent someone from skimming data off of an Ethernet line? e.g. would I use IPSec for that?
802.1x-2010 will provide authentication to the network switch and encrypt traffic exchanged. Older 802.1x specifications do not encrypt traffic.
IPsec can be a useful solution or layer on top of older 802.1x, but the increase in configuration work to allow only desired clients may be notable.
However what if a computer is connected via Ethernet and does not ask for an IP address? What can they skim off the network with a standard network card?
I think you're asking if it's possible, like it is on a wireless network, to connect to a wired network and sniff packets just like the likes of aircrack allow for promiscuous mode wireless traffic.
The answer is - not to the same extent if the ethernet network is switched. Specifically, in order to ensure every client gets their wireless packets, wireless routers by nature have to use omnidirectional antennas (well, actually, you can get directional antennas for "wireless bridges" between networks) and broadcasting. Effectively, your wireless hardware then ignores packets not addressed to it; however, promiscuous mode settings available on some wireless cards allow you to suppress this functionality. In which case you can view all network connections, even supposed unicast transmissions.
The same does not apply to Ethernet. Routers/switches have no need to broadcast information in the same way, since they should be able to route traffic along the appropriate cable. The wireless equivalent would be if they sent the packet down every attached wire and let the ethernet adapters filter out the redundant packets (which can also happen, but shouldn't).
The big exception to this rule is the design of applications and services running on top of ethernet. Many require the use of multicast or broadcast functionality and will therefore request packets be sent out to all clients in the relevant group (either the mcast group or the entire subnet). Anyone plugging in to a wired network will receive all broadcast packets by design.
This happens a lot more than you think - any service involving sharing discovery tends to do this. The ARP protocol does this too - common examples I've seen include Windows Media player/iTunes blasting out broadcast messages looking for devices to talk to. Windows File Sharing makes announcements of workstation availability, too. So this gives away information regarding the configuration and location of hosts on the network, which can be a problem.
Summary: on a switched network, they really ought to only be able to skim off broadcast traffic and any multicast traffic addressed to the host they're on.
The wireshark page for ethernet discusses this in fantastic amounts of detail, with nice diagrams.
As for solutions - IPSec will help enormously. Subnetting and routing will also help and you can do this on subnets of private IP ranges as much as you like. In essence, each sub-network has its own broadcast address, so if you use routing as opposed to ethernet bridging, you won't receive broadcast messages except for your subnet.
Can an attacker eavesdrop on Ethernet data, if they can connect to it? Yes. An attacker who is physically connected to your Ethernet network can probably eavesdrop upon all of the packets sent upon that local-area network.
You might think that switched Ethernet would prevent that, but in fact on many/most Ethernet switches, it does not. An attacker can use MAC flooding to force the switch into a degraded mode where it sends a copy of all packets to the attacker, thus allowing the attacker to eavesdrop on all traffic sent on that local-area Ethernet network. Similarly, ARP spoofing may allow an attacker to cause some packets to be routed to him. Not all routers are known to be vulnerable, but these attacks can be pretty subtle, and I'm not confident that the community has fully explored the space of possible attacks in this vein. Therefore, I recommend that you conservatively assume that this attack is possible.
In other words, I recommend you assume that anyone who can plug into your Ethernet network can probably eavesdrop on all packets sent on that local-area network.
These attacks do not require a special network interface card. Any Ethernet card suffices. The attacker just needs to run a packet sniffer program, which sets the Ethernet card to promiscuous mode and asks it to show all Ethernet packets that are visible to that Ethernet card.
How can you defend against this? The strongest defense is to use strong cryptography to encrypt all communications, and make sure that only trusted/authorized individuals receive the crypto keys. Using IPSec to encrypt all traffic would be sufficient. So would any other VPN or link-layer encryption software. The main downside is that these solutions can require considerable configuration and thus be clumsy to use.
Another defense is to do your darndest to ensure that untrusted individuals cannot plug into your Ethernet network. For instance, if you want to expose Ethernet ports in public spaces, you might create a separate guest network -- firewalled off from your internal corporate network -- and ensure that all Ethernet jacks in public spaces are connected to the guest network. You should complement this with physical security, to ensure that unauthorized individuals do not gain access to your workspace, to network closets, to server rooms, etc.
You can also firewall off internal networks from each other, following the "least privilege" principle. For instance, if payroll has particularly sensitive information on their systems and local Ethernet networks, then you might arrange that their local-area Ethernet network is limited to their building or their offices -- so that other employees who aren't part of the payroll department don't have a connection to that local-area Ethernet network.
A third defense is to encourage users to use encryption for all sensitive communications. This provides a fallback in case an attacker does gain access to your internal Ethernet network. For instance, you might ensure that sensitive internal web services are set up to use SSL sitewide, and other sensitive internal services are configured to use encryption. You might prohibit cleartext passwords on your internal network (e.g., require SSH and SFTP instead of telnet and FTP). You might encourage users to use HTTPS Everywhere to protect their web traffic, where supported by web servers.
A fourth defense is to enable features on your Ethernet switches to defend against such attacks. You can use client authentication (e.g., 802.1X) to ensure that only authorized clients can connect to the Ethernet network. (MAC address filtering is a poor man's version of this which provides only a low level of security.) You can also enable "port security" and similar security features that are specifically designed to prevent MAC flooding and ARP spoofing attacks.
I was just about to write a lengthy answer when I remembered I had a lengthy article explaining sniffing in depth even when connected directly to your ethernet cabling. All in all, a great beginners article with some a lot of good stuff. If you have any other questions just shoot em this way.
Welcome to security stackexchange.
http://www.windowsecurity.com/whitepapers/Sniffing_network_wiretap_sniffer_FAQ_.html
Another possible approach is isolating segments (LAN switches) vulnerable to unauthorized access with the filtering Ethernet bridge. In the simplest case you have a trusted Ethernet segment isolated from non-trusted one using filtering Ethernet bridge. Exact filtering rules can be specific to your environment and requirements. I'm not aware if there are any ready to use solutions on the market, but you build your own filtering Ethernet bridge using a computer with two Ethernet adapters and a piece of software. For Windows bridging you may check here: https://www.ntkernel.com/bridging-networks-with-windows-packet-filter/
We solved this problem with an appliance: NetClarity.
It uses dynamically assigned VLANS and reconfigures our switch ports when a new device is discovered. You can set it up to redirect the traffic anywhere, but because we have outside users needing internet access, we simply shunt them to an outside connection.
It discovers new devices in under a second and it works for us very well. It also has other value added things like a stripped down Snort engine, but the big thing for us was the automatic switch reconfigure.
Ask yourself what are you trying to protect?
What hardware is in your network now to do so?
What sort of access are you willing to allow?
How much can you realistically spend (time AND money) to
achieve the desired level of access control to
the critical resources.
The articles above are a solid starting point but do not
forget about whitepapers on cisco, microsoft, etc website.
Hope that helps,
iceberg
