Observing packets on the wire flying by

Anyone who has ever tried to install a modem or configure an Internet connection has almost certainly wondered if there’s any traffic flowing back and forth from networks. Observing network traffic that is generated by a PC or Mac is pretty easy with wireshark. When doing so, you’ll not only see traffic caused by the operating system, but also from any program running on it, which is probably the result of your personal preferences or interaction with them; such as an email client checking for new messages, or instant messaging sending keep alive requests to a server. Separating host from human, from within a single PC environment requires some preparation, but is still fairly easy using a virtual machine. The following post will go quite deep into the internals of IP-networks examining network traffic with tcpdump/wireshark from within a virtual machine, a guest OS, and make both guest and host almost invisible to the network.

First things first

But before doing or connecting anything; Let me be clear on intent and goal. Depending on the network you are connected to and how you are connecting to it, the analysis of network traffic as described in this article can potentially expose or even present data or information that was not intended for you. Be advised to only analyze network traffic of networks that you have a reason to connect to. To put another way: Do not analyze traffic from networks that you have no reason to connect to in the first place. Further: Do not store any data that you retrieved from any network that you do not own – I’m referring to the data here(!), and get rid of temporary data afterwards. It is not the goal to eavesdrop on other users of the network, but only to learn how the network works and how it could be improved. The “debugging” that is done in this article will be “read-only” and I’ll try to not leak any data of my own system, so some first things first:

Preparation

To look at traffic without interfering with it, there are some precautions that need to be taken before connecting to any network. So after installing virtualization software on the host OS and having installed a guest OS using that, don’t connect to any network yet! A “clean” way of doing that is to physically detach any network cable and disabling any wireless interface and reboot the host computer. Once the host has booted, empty its network settings so you know for sure that you won’t interfere with anything on the wire later on. That means disabling DHCP and not specifying an IP-address. Disable IPv6 too. On the host, you will need to use a bridged interface for the guest OS. Depending on your host OS, this may look like this:

bridge-only

I’m using Kali (Debianistic linux flavor) as guest OS; It has all the tools I need installed and comes with a nice desktop environment. The network interface for the guest OS to the outside world is interface #4, which should also be configured as a bridge (As shown as “Network bridge adapter” in the picture below). In Kali, this will be eth3. So before allowing it to full access to the network, clear the default configuration just the same so you know for sure nothing will interact with the network that is being analyzed.

vbox-nics

Once the guest OS has booted, use a “normal” account to login to your operating system and use root only when you have too. I assume you have a normal account so you now can become root:

 myself@kali:~$ sudo su -
 Password:
 root@kali:~#

Check and disable IPv6:

root@kali:~# sysctl -a | grep -i ipv6 | grep -i disable
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.eth1.disable_ipv6 = 0
net.ipv6.conf.eth2.disable_ipv6 = 0
net.ipv6.conf.eth3.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0
root@kali:~# sysctl net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.all.disable_ipv6 = 1

root@kali:~# ip addr show dev eth3
5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 08:00:27:6e:0d:63 brd ff:ff:ff:ff:ff:ff

Ok, no sign of IPv6. Now make sure nothing automagically would happen that could interfere; This means disabling the auto-pilots:

root@kali:~# service --status-all 2>&1 | grep -i network
[ + ]  network-manager
[ + ]  networking

root@kali:~# service network-manager stop
root@kali:~# service networking stop

…That last one can be tricky as it will bring every interface down. No problem, there’s no connection anyway.

One last thing; kill nameresolving completely:

root@kali:~# cat /etc/resolv.conf > /etc/resolv.conf.OLD && > /etc/resolv.conf; cat /etc/resolv.conf

There! This copies the existing /etc/resolv.conf in /etc/resolv.conf.OLD and empties the original only if that succedeed. You should not see any output from ‘cat /etc/resolv.conf’. As I don’t want to do this time and time again, I wrote a small shell script around this here. If you place this on a filesystem make sure the guest OS can access it, and set the execution-bit (chmod +x). If you named it ‘nics.sh’, you should be able to start it with ./nics.sh -v [start|stop]. Please note that the script is yet another hack, and may hang waiting for services to stop or start.

Start observing network packets

Ok! That should do it! Both guest and host should now be “invisible” on layer 3 and up, and not speak unless spoken to on layer 2. Plug in the ethernet cable, bring the interface ‘up’ (ifconfig eth3 up) and let’s see how deep this rabbit hole is… Start wireshark or tcpdump and see what’s on the wire!

root@kali:~# tcpdump -lni eth3
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth3, link-type EN10MB (Ethernet), capture size 262144 bytes
13:35:28.387890 IP 192.168.178.158.54271 > 239.255.255.250.1900: UDP, length 133
13:35:28.571590 IP 192.168.178.215.63657 > 239.255.255.250.1900: UDP, length 133
13:35:28.674157 IP 192.168.178.3.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=active group=2 addr=192.168.178.1
13:35:29.078589 IP 192.168.178.189.60559 > 224.0.0.252.5355: UDP, length 26
13:35:29.081987 IP 192.168.178.199.52700 > 239.255.255.250.1900: UDP, length 133
13:35:29.176322 IP 192.168.178.189.60559 > 224.0.0.252.5355: UDP, length 26
13:35:29.305095 IP 192.168.178.214.56575 > 255.255.255.255.1947: UDP, length 40
13:35:29.466449 STP 802.1w, Rapid STP, Flags [Learn, Forward], bridge-id c20e.00:19:0a:4d:16:82.80cd, length 42
13:35:30.010704 IP 192.168.178.149.17500 > 255.255.255.255.17500: UDP, length 191
13:35:30.013834 IP 192.168.178.224.56162 > 192.168.178.255.1947: UDP, length 40
13:35:30.014811 IP 192.168.178.149.17500 > 192.168.178.255.17500: UDP, length 191
13:35:30.015046 IP 192.168.178.149.17500 > 255.255.255.255.17500: UDP, length 191
13:35:30.015050 IP 192.168.178.149.17500 > 255.255.255.255.17500: UDP, length 191
13:35:30.020534 IP 192.168.178.2.1985 > 224.0.0.2.1985: HSRPv0-hello 20: state=standby group=2 addr=192.168.178.1
13:35:30.600418 IP 192.168.178.50.54393 > 239.255.255.250.1900: UDP, length 133
13:35:30.743610 IP 192.168.178.97.53404 > 239.255.255.250.1900: UDP, length 133
...

Whoa! That’s a lot! The output here depends on the network you’re connected to, and may vary depending on purpose and usage of that network; public, home, office or data center. But, look at the timestamps: This all happened within 2 seconds! Let’s narrow this down a bit, but first, let’s look at what we have here. Since the host – and guest OS for that matter – is connected to the network as a dead-end ethernet connection, I’m very likely to only see my own generated traffic or broadcasted traffic from hosts that are in the same network or even on the same network switch. But in this particular case, I’m connected to a network that has some network device talking HSRP. This is a router redundancy protocol and therefor very likely generated by a router (duh!) or firewall. Second, rapid spanning tree (IEEE 802.1w RSTP) is on the wire which is used to prevent ethernet loops on switches. There are more protocols flying by, most – but certainly not all – are listed in /etc/services:

root@kali:~# grep 17500 /etc/services
db-lsp 17500/tcp # Dropbox LanSync Protocol

As you can see from 2 seconds sniffing the network, this network segment has quite some bio-diversity! Interesting destination port numbers show up here. Dropbox is active in this network and causing quite some broadcasts, which is a big hint to the presence of workstations and/or laptops. And from the HSRP protcol output, it seems there are at least 3 ip-addresses allocated to routers, one active 192.168.178.3 and one standing by at 192.168.178.2. They are sharing a virtual IP-address, .1. The trick of HSRP is, that hosts on the network use the virtual address as the address of the router and that the actual traffic is handled by just one of the routers that is in the HSRP group, making it behave as if there was just one router. Narrowing traffic output down can be done by excluding unwanted traffic, like this:

root@kali:/var/tmp# tcpdump -lvni eth3 udp port 1985
<<output filtered>>

If you’re not too comfortable on keyboards and command lines, with grep as a companion to plough through /etc/services, you can also use wireshark, but you’d still need to apply a filter once you’ve started to sniff the interface. This controversy appears to almost identical to tcpdump…

udp.dstport == 1985

…unless you use the short form:

hsrp

The advantage with wireshark is that you can apply these filters without interupting the ongoing session; it filters the display, not the input from wire as with tcpdump.

Epilogue

You can learn a lot from a network just by observing packets fly by. Getting to know the tools to do just that has been briefly touched in this article. Here, I simply hooked up to a network without any IP connectivity to it, both host and guest, and just listened for packets on the wire. As it turned out: the network I was connected to had actually quite some interesting traffic on it in those 2 seconds!

Note that a computer that is connected to an ethernet switch – not hub – will not see all the network traffic, but will be limited to traffic the host (or guest) generated itself and broadcast traffic. The network I connected to is apparently “switched” and could have been configured with a little more thought and consideration to very basic network hackery as described here. Zooming in on ARP, STP and HSRP, you could potentially abuse the network here. Tools that instantly come to mind are yersinia, ettercap and dsniff. These tools have been around for a long time, but apparently weren’t considered much of a problem at the time this network went online which – if you’d ask me – is asking for trouble. But since this blog will remain “mostly harmless” I will stop right here.

You may wonder: “Why go through all the trouble of sniffing the network from within a VM? You could have looked at that from the host just the same!”

Yes, true. Well, there are 3 reasons behind removing the interface configuration and using a VM/guest OS instead of the host:

First, regarding the network interface configuration: I don’t necessarily want to chase network traffic that I – or the OS I’m using – generated. To be very honest: In the past I’ve been staring way to long at “my own” traffic when I was actually looking for other network/IP traffic.  And instead of analyzing traffic, I noticed that I started to write and debug complex filters, losing valuable time (and traffic!) by doing so. The method used in this article has the advantage that the host itself is “silenced” as it has no IP configuration, and the actual network sniffer is running in a contained environment, the guest OS. You can use filters to narrow down your search, which is especially handy if your host has just one interface and IP address. But if you have more than one NIC and multiple addresses, the chances are that you might lose interesting other traffic – unless you know exactly what you’re looking for. Filtering out or bypassing “noise” from a host that has more than one interface and IP address may make it difficult to use filters. If you’re not sure what you are looking for, it is probably easier to use plain tcpdump or dumpcap to store network traffic as a packet capture file (cap-file), and examine those files with wireshark later on.

Second, using a VM: I don’t want to replace the OS of the host. A VM with many more nifty network tools is easily created and disposed of. Why install just one tool if you can have an entire toolshed inside a VM? So there’s no need to install these tools on the host. I might also change my mind about my Linux-distro-du-jour I’m using now and switch to the next best *nix. The side-effect of using a VM is that the resulting pcap files are likely stored inside the virtual environment, which may limit the chances of leaking private data if the virtual disk is stored inside a truecrypt container.

Third: Imagine that the guest VM was running a popular desktop OS for normal day-to-day use, then you could observe the network just the same from the host as was done from the guest in this article. In that particular case, the host would be able to see all the traffic from the guest VM, which is exactly what upstream network providers are able to see – if they would eavesdrop on your network traffic.

Ever wondered what you are leaking to the outside world? Well, you now have the tools and skills to examine this. Try and compare that with running Whonix as a guest!

Oh, and by the way: Disabling IPv6 isn’t a good idea, but should force the OS to use IPv4 instead (or otherwise fail to communicate).

Using Wireshark from within a virtual machine

Using Wireshark from within a virtual machine

This entry was posted in Computer network, IT Security, Linux, Shell script and tagged , , , , , , , . Bookmark the permalink.