If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.-- Sun Tzu in The Art of War
While I was at university, I once discussed the topic of sniffers with an experienced network administrator. He casually mentioned that he was not bothered by sniffers, as all his machines were connected to switches. This was someone who was paranoid about security and read almost all security newsgroups religiously, but he was living in complete ignorance about the threat to his network. Unfortunately, he is not alone as many experienced systems and network administrators feel switches are immune to being sniffed. Switches may be difficult to sniff, but they are certainly not immune.
A computer connected to the LAN has two addresses. One is the MAC (media access control) address that uniquely identifies each node in a network and is stored on the network card itself. Each network card has a unique MAC address. It is the MAC address that gets used by the Ethernet protocol while building `frames' to transfer data to and from a machine. The other address is the IP address, which is used by applications.
The Ethernet header uses the MAC address of the destination machine and not the IP address. It is the job of the network layer to map a particular IP address to the corresponding MAC address, as required by the Data Link Protocol. It does this by initially looking up the MAC address of the destination machine in a table, usually called the ARP cache. If no entry is found for the IP address, the Address Resolution Protocol broadcasts a request packet (ARP request) to all machines on the network. The machine with that address responds to the source machine with its MAC address (ARP reply). This MAC address is added to the source machines ARP cache, and it is then used by the source machine in all its communications with the destination machine.
Two basic types of Ethernets environments exist, and how sniffers work in each of them is different.
Shared Ethernet: In a shared Ethernet environment, all hosts are connected to the same bus and compete with one another for bandwidth. In such an environment packets meant for one machine are received by all the other machines. Thus, any machine in such an environment placed in promiscuous mode will be able to capture packets meant for other machines and can therefore listen to all the traffic on the network.
Switched Ethernet: An Ethernet environment in which the hosts are connected to a switch instead of a hub is called a Switched Ethernet. The switch maintains a table keeping track of each computer's MAC address and delivers packets destined for a particular machine to the port on which that machine is connected. The switch is an intelligent device that sends packets to the destined computer only and does not broadcast to all the machines on the network, as in the previous case. This switched Ethernet environment was intended for better network performance, but as an added benefit, a machine in promiscuous mode will not work here. As a result of this, most network administrators assume that sniffers don't work in a Switched Environment.
As mentioned earlier, a switch is certainly more secure than a hub when it comes to sniffing, but it is certainly not immune. The following methods are used to sniff the traffic on a switch:
ARP Spoofing: We have explained earlier how ARP is used to obtain the MAC address of the destination machine with which we wish to communicate. The ARP is stateless, you can send a ARP reply, even if one has not been asked for and such a reply will be accepted. Ideally, when you want to sniff the traffic originating from a machine, you need to ARP spoof the gateway of the network. The ARP cache of that machine will now have a wrong entry for the gateway and is said to be "poisoned". This way all the traffic from that machine destined for the gateway will pass through your machine. Another trick that can be used is to poison a hosts ARP cache by setting the gateway's MAC address to FF:FF:FF:FF:FF:FF(also known as the broadcast MAC). There are various utilities available for ARP spoofing. An excellent tool for this is the arpspoof utility that comes with the dsniff suite. Using arpspoof to poison the ARP cache of a machine is accomplished by giving the command:
[root@tachyon dhar]# arpspoof -t 184.108.40.206 220.127.116.11 0:80:ad:7c:7:3a 52:54:5:f3:95:1 0806 42: arp reply 18.104.22.168 is-at 0:80:ad:7c:7:3a 0:80:ad:7c:7:3a 52:54:5:f3:95:1 0806 42: arp reply 22.214.171.124 is-at 0:80:ad:7c:7:3a
The -t flag specifies the target whose ARP cache we wish to poison, and the other argument is the IP address of the gateway that we wish to spoof. Now all the data destined for the gateway from the target machine will have to pass through our machine. Before you ARP spoof the gateway, however, it is essential to turn on IP Forwarding for your machine. This can be done by giving the command:
[root@tachyon dhar]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@tachyon dhar]# cat /proc/sys/net/ipv4/ip_forward 1 [root@tachyon dhar]#
If the cat command returns a value of 1, then IP Forwarding has been enabled; if it returns 0, it means IP Forwarding has not been enabled.
MAC Flooding: Switches keep a translation table that maps various MAC addresses to the physical ports on the switch. As a result of this, a switch can intelligently route packets from one host to another, but it has a limited memory for this work. MAC flooding makes use of this limitation to bombard the switch with fake MAC addresses until the switch can't keep up. The switch then enters into what is known as a `failopen mode', wherein it starts acting as a hub by broadcasting packets to all the machines on the network. Once that happens sniffing can be performed easily. MAC flooding can be performed by using macof, a utility which comes with dsniff suite.
[root@tachyon dhar]# macof 77:6b:e1:6e:5e:8c 93:2d:ed:45:f9:e3 0.0.0.0.45702 > 0.0.0.0.11000: S 1847390231:1847390231(0) win 512 84:a4:d3:57:ef:8 12:56:52:42:dc:95 0.0.0.0.16630 > 0.0.0.0.3031: S 1484147693:1484147693(0) win 512 88:f0:9:3f:18:89 d:86:53:53:d7:f8 0.0.0.0.15535 > 0.0.0.0.7466: S 293820390:293820390(0) win 512
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Home, My Backup Data Center
- Please correct the URL for Salt Stack's web site
1 hour 21 min ago
- Android is Linux -- why no better inter-operation
3 hours 36 min ago
- Connecting Android device to desktop Linux via USB
4 hours 5 min ago
- Find new cell phone and tablet pc
5 hours 3 min ago
6 hours 32 min ago
- Automatically updating Guest Additions
7 hours 40 min ago
- I like your topic on android
8 hours 27 min ago
- This is the easiest tutorial
15 hours 2 min ago
- Ahh, the Koolaid.
20 hours 41 min ago
- git-annex assistant
1 day 2 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?