Using Raspberry Pi’s for Network Monitoring and Health Status – Part 1 : Dual NIC Network Connectivity

I have recently been able to spend sometime working with Raspberry Pi’s both for personal projects as well as a few things for work. This seems like a great opportunity to do a series of posts on them! The first post will be around utilizing both NICs at the same time to allow for “Out Of Band” management of the Pi while using the other NIC for network testing.

This will be one of hopefully many posts around this topic.

First a quick background:
The Raspberry Pi is an interesting mini computer that comes in a few different form factors and a very low price point. The GPIO (General Purpose Input/Output) connectivity allows for some really neat projects. The Raspberry Pi can run any OS that will run on the CPU, but the primary OS is Raspbian. Raspbian is a version of Linux optimized to work efficiently on the Raspberry Pi hardware platform. The newest version (3 Model B+) includes both built in Gigabit Ethernet NIC and a Dual Band wireless AC NIC.


***As always, make sure to have appropriate backups prior to making any changes. It is also highly recommended to do all development work in a test environment not attached to any production environment. Following any of the provided steps or using any of the provided information is at the users own risk.***

Now for the good stuff:
This setup is intended to utilize the Wired NIC as the management interface while all testing will be performed through the wireless NIC. This allows for remote wireless connectivity testing at locations without having to have a onsite tester, as well as provides the ability to perform general RF spectrum health analysis. This is accomplished by having the primary preferred default route over the wireless NIC and a more specific route to the management endpoint (or subnet) over the wired NIC.

The default behavior when connected to both a wired and wireless NIC is to allow both connections with each having a default route, wired having a lower metric and preferred over the higher metric of the wireless NIC:2018-01-12-014702_1824x984_scrot

To start off, and to make sure connectivity is never lost, configure the static route that forces traffic destined to the management PC / subnet over the wired NIC. To do this a new file called “40-route” needs to be created in “/lib/dhcpcd/dhcpd-hooks/” that contains the static route entry:2018-01-12-033146_1824x984_scrot

After the file is created and saved restart dhcpcd services and make sure the route entry is added into the route table:2018-01-12-033626_1824x984_scrot

To prefer a specific interface (such as the Wireless NIC, for testing of the Wireless environment) the metric for the interface needs to be set to a lower value. I also recommend setting the management interface to a higher value so that it is always higher then the preferred testing interface. To do this edit the file “dhcpcd.conf” using your favorite editor to include the interface metric configurations as shown below:2018-04-08-171319_1920x1080_scrot

Once the file is edited and saved, restart dhcpcd services and make sure the new metrics are shown in the route table:2018-04-08-171508_1920x1080_scrot

Once setup and verified all primary traffic not destined for any directly connected subnets or the static route assigned will use the more preferred (lower metric) interface.

Now that the Raspberry Pi is setup, you can deploy a low cost network monitor probe using tools such as iperf, IP SLA, or any other responder software that you want to be forced over a specific medium for testing at a location.




Attacking HSRP and how to protect it

I covered HSRP (Hot Standby Router Protocol) in a previous post that went into great detail on how HSRP functioned and a few enhancements to it. This time around I figured it would be fun to see what we could do to a typical HSRP deployment, and then research ways to further protect it.

For this scenario the following topology will be used:


. The topology includes a basic HSRP configuration between two routers (R01 and R02), a basic layer 2 switch (sw1) and a webserver sitting on the “Internet”. For verification purposes, the active HSRP router is checked:  12

With the verification completed its now time to start the reconnaissance. For this Kali Linux was used along with a hand full of tools running on it. This post is not intended to explain how to use the tools and will not go over them, a simple Google search will give you all the information you need for that…

A quick wireshark trace shows there is in fact HSRP traffic flowing on the subnet:Screenshot from 2015-07-19 09_37_13

The attack is launched and a new HSRP takes over as active:

Screenshot from 2015-07-19 09_41_253

Executing the attack alone is enough to cause a DDoS event for that subnet. All traffic is routed to the rouge Active HSRP “router” and if it is not setup properly will cause all traffic destined for an outside subnet to be dropped:4

For some a DDoS is the end goal of the attack, but that’s not as fun as being able to be in the middle of the traffic without users even knowing. For the MITM to be successful a few things needed to be configured on the kali Linux device in order to get traffic flowing properly. Once setup traffic was able to leave the subnet:


Now that the attacker is in the middle of all traffic leaving the subnet, it is possible to sniff any traffic going through with wireshark. If anything is sent in clear text (unencrypted) the attacker is able to see it in wireshark including login information:Screenshot from 2015-07-19 10_05_10

The easiest way to add a layer of protection onto HSRP is to utilize MD5 authentication. This can be accomplished through key chains, key strings, or a mixture of the two. The configuration to use a key string is very straight forward. On all routers participating in HSRP for that group add the single command line: standby [HSRP group #] authentication text  [Authentication String]. Once configured, all devices will use the string to hash message data. If a router attempts to join the HSRP group with a incorrect key the following warning is seen:


SNMP traps can be setup so that an alert is sent immediately if the bad authentication is seen allowing for network staff to investigate the issue.

Lets just go ahead and use DTP & VLAN 1… Part 1: Attacking DTP – getting those server files

In my previous post, I discussed the vulnerabilities introduced from using the defaults of DTP and VLAN1 along with ways to mitigate the vulnerabilities. In this post a basic example of attacking DTP will be reviewed.

To make things easier to follow the following diagram will be used throughout the series:VH

Before the attack, for demonstration purposes, we verify that the attacker’s switchport (fa 0/14) is not a trunk:


We will also verify the inability of the attacker to access the target server (due to the router’s ACL):a1

Now that we have verified the inability for the attacker to gain access to the server we can begin the attack.

The first phase of the attack will be to trick the switch into thinking its connected to another switch and negotiate a trunk link. This will be completed through spoofing DTP packets, which can be seen below:at1

We can see the switch port flap as it resets, and then its verified that the attacker’s port is now a trunk:Untitled3

Now that the switch believes its connected to another switch via a trunk connection its now possible to create virtual interfaces for any VLAN allowed across the trunk (all by default):at2

As can be imagined, with the attacker able to successfully trick the connected switch into thinking s/he is also a switch almost anything is possible. For today, we will simply pull a file off of the server which is supposed to be protected by an ACL on the router:


With DTP enabled on a port it takes a matter of seconds to trick a switch into thinking its connected to another switch, this is why its very important to configure any port that is not a trunk port in use as an access port with other appropriate security configurations.