Martian Packets and Monitoring: Do They Come From Outer Space?”

Martian Packets: The concept and relationship with Monitoring

Such a weird name, Martians Packets, was coined in the RFC 1812 norm and it talks about Martian Directions (contained, of course, in a Martian Packets In the last century, the possibility of finding life on the planet Mars was widely publicized by the media, and so engineers defined this category for packages that are not supposed to arrive and that we do not “know” where they come from. As reality always surpasses fiction, today we have devices perched on the red planet that send the collected data -we speculate that in UDP packages, which do not need recognition of arrival, due to the enormous distances- directly to the National Aeronautics and Space Administration (NASA), so it is completely ruled out that they could reach us, or at least not directly.
One of the monitoring jobs also involves observability equipment of a system.

IP Addresses and Martian Packets

In a previous article we explained in detail what private and public networks are, assigning IP addresses to each of our devices (IPAM) and we made some numerical examples in binary system to determine if an IP address belonged to a certain subnet. We did all this in a very simplified way and not at all academic, but in a didactic and pragmatic way; here we will do the same.

Computers belonging to a private or public network communicate by means of data packets through Ethernet technology, well known and implemented throughout the world. Each data packet contains the destination address and other specific fields, such as the useful life time (Time To Live or TTL), from which it is subtracted as it is passed and forwarded by each computer or device until it reaches its destination. If it is resent many times the time will come when the packet “dies” and is simply discarded (this helps to decongest the network, packets should not wander infinitely). If the packet was UDP type there is no problem, because there is no need to return response as is the case with TCP. Due to this, there is another field that is the source address, to which the package is returned indicating if it could be delivered, if the TTL was finished, etc..

Although this is fully valid for both private and public networks, we are going to place ourselves in a public network, that is, our computer connected directly to a modem and from there to the Internet.

“Given this scenario, a Martian Packet is anyone who reaches one of our devices and contains a destination address and/or source address that belongs to a set of IP addresses reserved for special use.”

We have already seen that private networks have three specially reserved groups that are well known, but there are other addresses reserved for very special purposes such as 192.88.99.0/24, which was intended to be used to redirect traffic between IPv4 and IPv6. Any package that reaches us with that address, 192.88.99.X (for X between 0 and 254), including other special addresses, is simply a Martian Packet that should be discarded immediately.

Routers and bridges

A device usually has only one IP address assigned to it, but it may have two or more. Our laptops are the best example: they can be wired to one network and wirelessly connected to a different network.

Now let’s imagine that through Ethernet our computer is connected to the Internet and with a public IP address and through Ubuntu we place a wireless access point, we assign IP addresses to the rest of our computer, and so on (this is a good but hard job). We’ve drawn you an outline:

Our computer connected to the modem works as a bridge and at the same time as a router, which receives the requests to the Internet from our computers because we have configured it as the default gateway (192.168.1.1 in our graphic example): we will take the packets and in the source address field we will place the public IP address and send the packet. We’ll also keep track of who asked for what, so that when they respond we can forward that packet result to our local area network team. This is what is called network address translation and any GNU/Linux distro can be configured for it; in our personal case we use Debian/Ubuntu.

Now, our brand-new network printer was, by our error, configured and fixed with an IP address 192.168.0.70 (our simplification is to the maximum), because there we will have an excellent example that causes Martian Packets. Generally, this type of packages appear by incorrect configurations of the most diverse devices: refrigerators, video cameras, televisions, etc.. (everything we know as the Internet of things).

Viewing network traffic with iptraf

One program we can use to display packets and addresses -and network traffic in general- is iptraf. With the command sudo apt-get install iptraf we will bring it to our machine and then with sudo iptraf-ng -i eth0 (if we want to see the wireless card instead of eth0 we will use wlan0) we will see something like this:

Keeping track and record of Martian Packets

Although RFC 1812 recommends that upon receiving a Martian Packets, its data should be registered and then discarded, however in the different GNU/Linux distributions it is not always enabled by default. A way to check if the system is registering them:

grep [01] /proc/sys/net/ipv4/conf/*/log_martians|egrep "default|all"

The result, two lines, both, must end in “1”. We will also be able to see how it is configured for all network interfaces. It’s a simpler command, but more powerful:

sysctl -a | grep martian

If they don’t end in “1”, we can activate them; in the file /etc/sysconfig/sysctl we add them:

net.ipv4.conf.all.log_martians=1
net.ipv4.conf.default.log_martians=1

Finally, we must restart the service with “sudo sysctl -p”

To display them:

grep -i --color martian /var/log/messages*

What causes Martian Packets?

In order of frequency:

• The most common cause: a computer with two or more network interfaces connected to the same switch, hub, or router.
• A badly configured router.
• IP addresses misconfigured, or for example using a Class E network (IP addresses 240.X.X.X.X). Some router operating systems such as Juno, based on FreeBSD, can be configured to include this Class E within Martian Packet recognition.
• Dynamic MAC addresses.

Tracking Martian Packets

It seems like a contradiction: if we don’t know where the Martian Packet comes from, how can we trace it?

As we told you, if we already activated its registry, we should look in the logs the lines where it will inform us the destination address, the source address, the network interface where it was received and last but not least: bytes 7 to 12 that represent the MAC address, which is a more reliable data to deliver to the System Administrator.

Monitoring in large companies

Martian Packets (and, in general, network traffic) are the entire responsibility of the Systems Administrator; however, the monitoring team must always be ready and attentive to your support and be your right hand in the daily work. The flexibility of Pandora FMS is demonstrated with facts, and since our version 4 (year 2013) we implement the command capture monitoring or “MCC” (in Pandora FMS Wiki it describes how to enable it), which we affirm is a tool in today’s observability work. We will be able to create in Pandora FMS a group called “System Administrators”, with the rights to access the MCC feature and execute the netstat program (just one of the tools that every System Administrator must know):

Although Pandora FMS has a function of automated discovery of new devices in a network, which allows it to generate spectacular network maps, the Martian Packets actually fall into the category of network monitoring and in this article, in this blog, we explain it in detail.

Pandora FMS: “To infinity and beyond”

With everything we have to deal with in the present and future monitoring area, we can always count on a powerful tool like Pandora FMS. We constantly work on analyzing scenarios located at the limit -Martian Packets included-, because our job is to bring you the solutions and also the improvements from these analyses! Do you have a monitoring scenario that is a challenge for Pandora FMS? Contact us and we will help you!