As you are probably aware following the news this morning, a serious flaw has been found in WPA2 implementations on all devices/operating systems.
For further information on this, the white paper highlighting the flaw can be found here:
https://papers.mathyvanhoef.com/ccs2017.pdf
A synopsis on the problem here (good place to start):
And a higher level description by the Guardian Newspaper here:
It’s useful to be able to monitor devices on our network for a variety of reasons including security and performance issues. In this post we are going to provide a brief introduction on ow to do this. This post will form the foundation for future ones which dive into the subject further.
Our pfSense firewall supports the protocol known as SNMP (Simple Network Management Protocol) which allows us to do exactly that over a TCP/IP network. Many tools exist out there, but we will be experimenting with this one in particular since it is easy to install for learning purposes.
For those interested it operates at Layer 7 of the OSI-7 Layer model (the Application layer). A range of devices from servers to printers support the protocol and this list of devices also includes pfSense.
There are many use cases for SNMP. If we build out our own server which acts as the management console for our home automation devices, it would be good to gather data on it and alert us if we need to administer it in some fashion. Or perhaps we wish to perform the same task on a firewall!
Each of these devices represent agents on our network. Once we have the SNMP client software installed on the agent it will expose a set of variables to the management console which then allows us through these variables to update configuration and similar.
In this instance pfSense will act as the agent and will be administered by a management system running on a Linux based device.
For the purposes of this series of articles we will be using a simple Raspberry Pi 3 running Linux as an example of how to build out a management device and collection point for TRAPs.
Once you have the basics in place and are comfortable with how SNMP works you can roll it out to intelligent thermostats you may have built with the Raspberry Pi or similar devices.
To recap we therefore four components in this project:
Let’s take a quick look at the SNMP protocol before we start configuring our devices to familiarize ourselves with the features.
Version 1 of the SNMP protocol introduced three important operations to interact with managed devices on an IP networks. These are GET, SET and TRAP
GET – This allows the management station to retrieve an object from an entity
SET – Allows the management station to SET objects on a managed entity
TRAP – Allows the entity to notify the management console of significant events.
SNMP version 1 also introduced the MIB. The Management Information Base contains configuration data and operational information. You’ll see a bit more about this later when we use a tool to walk through it, however here is an example of the data:
iso.3.6.1.2.1.1.1.0 = STRING: “pfSense pfSense.localdomain 2.3.2-RELEASE pfSense FreeBSD 10.3-RELEASE-p9 amd64”
Another important feature is the community name. Devices in the same community could authenticate with each other using this method.
There are a number of flaws in SNMP version 1. Security is very weak with the community name acting as a user group and password rolled into one.
In addition to this freshness checks e.g. nonce or timestamps are absent so replay attacks are possible and finally none of the data is encrypted.
SNMP version 2c is almost identical to version 1, but has subsequently been superseded by SNMP version 3 which beefed up security relative to version 1. Version 2c added in the support for 64 Bit counters.
In version 3 of the protocol we now have keys which are used to encrypt traffic from one device to another. The device whose keys are used to provide auth/confidentially is known as the authoritative entity.
For GET/SET the receiver is the authoritative entity.
For TRAP the sender is the authoritative entity.
Another feature of SNMP version 3 is the SNMPEngineID which acts as a unique identifier for an entity on the network.
Those that’s a quick overview of the protocol. You can read more about here if you want to learn more.
Our Raspberry Pi will eventually end up being our management console. However first we will install some basic tools on the device so we can monitor it from itself for learning purposes as well as review the MIB on the pfSense appliance.
Log in to your Raspberry Pi (or similar Debian based Linux device) and run the following commands:
sudo apt-get update
sudo apt-get install snmpd
sudo apt-get install snmp
Once the installation has finished we can edit the configuration file that contains the settings for SNMP on your device.
Using vim or a similar tool edit the snmpd.conf file e.g.
sudo vim /etc/snmp/snmpd.conf
Find and comment out the line with agentAddress and change it to the following:
agentAddress udp:161
Then change the rocommunity to mysnmptext
rocommunity mysnmptest
Save the file and exit.
We now have our agent running on port 161 which is standard and using UDP (User Datagram Protocol).
Let’s now restart the services.
sudo service snmpd restart
We can check the process if running by running the following command:
ps -A | grep snmpd
You should see an output similar to the following
2232 ? 00:00:00 snmpd
We can walk the MIB on the Raspberry Pi using a tool called snmpwalk.
To do this we need to run it using the community name (mysnmptest) then version (1) and the target machine (localhost).
Run the following command from you terminal:
snmpwalk -Of -c mysnmptest -v 1 localhost
You should now see some output similar to the following which is the OID and its value :
iso.3.6.1.2.1.1.1.0 = STRING: “Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l”
The labels aren’t much help in defining what each of these output items mean in many cases. Therefore we are going to install the snmp-mibs-downloader library to resolve the OID to their text description.
From the command line run:
sudo apt-get install snmp-mibs-downloaderAfter this has completed, edit the conf file:
sudo vim /etc/snmp/snmp.conf
We don’t need the mibs value, so go ahead and comment this out
#mibs
Save and exit the file.
Now let’s try rerunning the command again:
snmpwalk -Of -c mysnmptest -v 1 localhost
We should see the OID resolve to a string prefix now:
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: Linux raspberrypi 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 armv7l
Here we can see the sysDescr i.e. System Description is the Raspberry Pi as expected.
Now we have tested this on the Raspberry Pi, let’s enable the option on pfSense.
Enabling SNMP on pfSense is fairly straight forward.
You can access the SNMP settings through Services > SNMP
The following screen will be displayed
First select the Enable option. This turns the daemon on.
Next in the System Location assign value e.g. “firewall”. Following this you can also add a System Contact e.g. yourself.
We are now going to change the Read Community String to mysnmptest which is what we assigned to community value on the Raspberry Pi.
Scroll down to the bottom option and set the Bind Interface to LAN. We only want this enabled on our local network, and certainly not the WAN.
Don’t worry about the other settings. We will re-visit the TRAP options in a later post.
Save the updates.
We can use the tools we installed on the Raspberry Pi to query the pfSense box. return back to the command line and run the following:
snmpwalk -Of -c mysnmptest -v 1 192.168.1.1
This is the same as we did with the Raspberry Pi, however we have changed localhost to the be the IP of the firewall.
You should see a response similar to:
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: pfSense pfSense.localdomain 2.3.2-RELEASE pfSense FreeBSD 10.3-RELEASE-p9 amd64
In this case the sysDescr is the pfSense firewall description.
So there we have it. SNMP clients setup in two locations and a method to review each devices MIB.
This post briefly introduced us to SNMP and installing it on the pfSense firewall and a secondary Raspberry Pi. We explored version 1 of the protocol. Future posts will cover how we can use this data for monitoring and more information on the OIDs.
In addition to this we will set up SNMP TRAPs and also look and SNMP version 3.
So far we have setup pfSense and connected up our WAP to it. This has formed the basics of our home network.
However it would be good if we could use multiple access points each running on their own network, but sharing the pfSense router, firewall and WAN. We also need to consider locking down the network to improve security.
In this post we will expand our network further to incorporate these items by:
To start with we will do a little digging into how switches work to provide some context for when we later setup the VLANs.
A switch is a hardware tool (located at the Data Link Layer on the OSI-7 layer model) which is responsible for routing packets from one machine to another. A switch relies on knowledge of the networked machines MAC addresses.
Typically a hardware unit will consist of multiple Ethernet ports that devices can be plugged into. Our setup so far relies on using the WAP connected to a single Ethernet port to assign IP addresses to machines on the network. Once a machines has connected to the switch via the WAP, a record of its MAC/IP combo is stored on the pfSense appliance.
Switches were a replacement to what are known as Hubs (found at Layer 1 of OSI-7 Layer model). A Hub broadcasts messages out the whole network and any device connected to the Hub can read the packets. If a NIC was placed into promiscuous mode, then sniffing the packets and viewing the data was possible. A switch on the other hand only routes traffic to the target machine.
Of course this also mean your network speed is affected by the speed of the switch! A faster switch with the right Ethernet cable and newer NICs for the devices running on the network, improves overall speed.
If you cast your mind back to an earlier post you will remember we discussed the ARP protocol. One issue some switch configurations are susceptible to is what is known as ARP and IP spoofing.
Each machine on the network will keep a copy of the IP/MAC combo in their ARP cache. An attacker can therefore use its own copy of the ARP cache to try and eavesdrop on communications between machines.
The way this works is to send out a Gratuitous ARP message to the machines on the network and replace the portion of the MAC mapping, with the MAC of the attacker. The attackers machine then sits in the middle (man-in-the-middle) eavesdrops on incoming messages, and then forwards them on to the other party.
If you are interested in trying this out yourself then take a look at the dsniff tool.
At the switch level there is another issue we need to be aware of – MAC flooding.
The switch as you will remember contains a table mapping MAC’s to IPs. We can see this mapping in pfSense under the Diagnostics > ARP Table link.
A MAC flooding attack attempts to overwhelm the switch so that no new MAC/IP pairs can be generated (a DoS attack), or worst the switch reverts into acting like a hub, thus allowing eavesdropping.
Thankfully aspects of the 802.11 protocol defend against MAC flooding. When a device associates with a WAP it is MAC-based. Therefore the WAP bridges traffic coming only to/from known MACs.
Therefore if a MAC flooding attack is directed from a wireless device to the network, any 802.11 frames with a random MAC address in the source not associated with the WAP are discarded.
So now we have a little understanding of how switches work and some of the security considerations, let’s look at VLAN compatible switches.
VLAN Switches
For this portion of the post I will be referring to a Dell PowerConnect 2808 VLAN compatible switch. The 2800 series switches start at around $129.00 USD. If you are using a different device, then modify the instructions below as applicable.
VLAN stands for Virtual LAN. As it’s name may suggest, the concept behind it is to take one set of hardware i.e. ‘n’ machines and one switch and create multiple LANs from this. Each LAN being its own subnet. The traffic on each of these LANs is then tagged so we know which VLAN it belongs to.
pfSense allows us to configure VLAN interfaces and then assign DHCP servers to each of them. We therefore can use our VLAN switch as a method for connecting multiple AP’s (or wired devices) and let the configuration of the IP range etc. be handled by pfSense.
Our first task is going to be to move our WAP off the LAN interface on pfSense. Going forward we would like the LAN to only be accessible for devices connected directly to the switch.
We therefore need to come up with an IP range for WAP to use, since it will no longer using 192.168.1.0/24.
Let’s start by plugging out laptop/PC directly into the pfSense appliance, as the WiFI will shortly stop working. You can also power down the WAP for the moment.
We are going to use the range 192.168.3.0/24 for our new VLAN.
Let’s start by navigating to Interfaces > (assign)
On the screen that pops up select the VLANs option. You’ll now be presented with a list of VLANs which currently will probably be none.
Select the Add button from the bottom right.
The VLAN Configuration screen will now be presented. On this screen we can create our new VLAN and tag it.
From the Parent interface drop-down, select the LAN option.
Below this you will see the VLAN Tag input field
Set this value to an integer between 1 and 4094. I like to use a value derived from the subnet. So if the subnet is 192.168.3.0/24 I use the tag 3. Do not enter the value 1 however. This will become apparent why later.
You can ignore VLAN Priority for now. If you wish to add a Description now is your chance. For example “HomeAutomation”.
Return back to the Interface Assignments screen under Interfaces. This will be updated with an Available network ports drop-down. Listed here you will see your VLAN.
Select it and click the green Add button. Once added you will see it has a name similar to ‘Opt7’
Next navigate to the Interfaces drop-down. Your new VLAN interface with the Opt7 (or whatever was auto generated) will now appear.
Select this option to go to the interfaces configuration.
We have now going to select the Enable interface checkbox.
Following this change the Opt7 value to something more intuitive e.g. HomeAutomation.
The IPv4 Configuration Type should be changed to Static IPv4.
Our final task is to scroll down the screen to the Static IPv4 Configuration.
Change the value of IPv4 Address to 192.168.3.1 and ensure the ‘/’ value is set at 24.
Save these values.
Now navigate to the Interfaces > Interface Assignments screen. Here you should see the new Interface HomeAutomation (or whatever you called it) and the Network port should be similar to: VLAN 3 on igb1 – lan (HomeAutomation) .
We now have an Interface setup for our VLAN. This will work over our LAN connection allowing us to run a virtual LAN with the 192.168.3.0 subnet.
Currently our WAP is setup however to use 192.168.1.0/24 so we will need to change this.
First let’s get the DHCP server running on the VLAN interface.
Navigate to Services > DHCP Server from the list of available interfaces, select the one corresponding to your VLAN e.g. HomeAutomation.
When this screen loads you will see some General Options.
Here you will need to do the following:
Save these changes.
Now we are finally ready to update that static mapping we created before for our AP.
So navigate to Status > DHCP leases.
Next edit the Static mapping you added for the WAP. Change the IP address to a new one in the new subnet 192.168.3.0/24.
Make a note of the IP address you selected, as we now need to update the WAP.
Save the changes.
You can now unplug the laptop from the pfSense appliance, unplug the WAP from the LAN port and power up the WAP again.
Once it is up, login to the web interface and change the IP address for the AP to the one you selected above.
So we now have a VLAN configured on pfSense and the WAP configured with an IP address for the new VLAN. That leaves us with our final task – setting up the VLAN switch so we can plug our WAP back in.
Our final task is going to be to configure the VLAN switch. As mentioned for this I have selected a Dell PowerConnect 2808, so you will need to tweak the following instructions to your specific switch.
First we are going to plug the VLAN switch from LAN port 1 into the Ethernet port where the WAP was originally, then power up the VLAN switch. Also plug your laptop/PC into one of the other free ports on the pfSense appliance.
Once it has booted up, the LAN DHCP server will assign it an IP address in the 192.168.1.0/24 subnet. You can check on the DHCP leases screen in pfSense to find out what was assigned to it.
Navigate to the web console for your switch and log in. Remember after you login to change the username and password from the default values to something more secure.
Once logged in we need to configure a VLAN for our HomeAutomation interface.
Within the GUI located the VLAN configuration screen. In the Dell PowerConnect this is:
Switch > VLAN > VLAN Membership
Under this screen we can select an existing VLAN or configure a new one. By default you should need a VLAN tagged with 1 available. This acts as a the Trunk, that all traffic is sent over and is the configuration associated with the Ethernet port (1), you plugged the pfSense appliance into.
The Dell switch comes preconfigured with the VLAN tagged as 1 and will not allow you to edit any of the details here. This configuration is needed in order for the switch to communicate with a router etc. once plugged in.
Use the Add button to load up the screen for configuring a new VLAN.
Let’s enter the tag value we set in pfSense for the VLAN ID. I recommended using 3 earlier, but this can whichever value you chose.
For the name enter HomeAutomation, or whatever you decided upon when setting up the VLAN interface.
You can leave the final value as is and click the Apply Changes button.
Back on the VLAN Membership screen select the Show VLAN drop-down and select VLAN 3 (or whatever you chose).
You’ll see a small table now appear which is called Ports.
Clicking on a square will insert a character (this is on the Dell machine, other switches will have a different interface).
Select the square for port 3 (this is where we will plug the WAP into) and click it until a U appears. Port 1 should show a T, if it doesn’t click it until a T appears.
On other models of switches you will need set port 1 as the Trunk where the tagged data passes over, and associate the physical Ethernet port you will plug your WAP into with the VLAN.
Save/Apply these changes.
Our final task is going to be to update the Port settings. On the Dell PowerConnect 2808 switch these settings can be reached via Switch > VLAN > Port Settings.
Select the relevant Ethernet port, in our case 3. Make sure the PVID is tagged as 3 and finally make sure the Frame Type is Admit All.
Save these changes.
Our VLAN switched is now configured so that Ethernet port 3 can be used for the WAP and all traffic running over it through the Dell switch to pfSense will be on VLAN 3 with IP addresses assigned from 192.168.3.0/24 subnet.
Let’s now power everything down.
Hook the WAP to Ethernet port 3 on the VLAN switch. Next make sure that the VLAN switch Ethernet port 1 is connected to the LAN on the pfSense appliance.
Now let’s start everything up.
Once booted, connect your laptop/PC to the WiFi SSID and bingo you should now have an Internet connection.
If you log into pfSense and check the DHCP leases – your laptop/PC should appear in the list.
To add a second WAP and VLAN to your network, repeat the steps above and this time use a VLAN tag of 4 (or other acceptable value from the range). Associate this VLAN with the 192.168.4.0/24 subnet and assign the WAP a static IP from this subnet.
You absolutely must assign a different VLAN tag and subnet for this to work. If you encounter problems with VLAN not working with the second WAP ensure that:
In this post we hooked up our VLAN compatible switch. In addition to this, we connected up our existing WAP and saw how we could add a second one by following the steps for configuring the first.
We now have a home network with:
In the next post we will look at the WAPs in a little more detail and discuss security.
I’m excited to announce Modus Create will be hosting a DevOps event in NYC at LMHQ on March 3rd 2017.
You can read more about it over at the Modus Create website.
Everyone,
The blog has been on a hiatus for the best part of a year. This has allowed me to concentrate on wrapping up my current degree and finish up my fourth Raspberry Pi book.
Internet Of Things @ Home will be re-launched this spring with a new look, new feel and a lot more articles.
Watch this space for more details.
Everyone,
I’m glad to announce that a second edition of Raspberry Pi Home Automation with Arduino is being planned for release next year.
There will be a major overhaul of some chapters. Based upon the excellent feedback I received you can expect to see:
1.) More home automation projects
2.) Inclusion of projects using the Arduino Uno shield
3.) A look at the Arduino YUN
4.) Revised content on the Raspberry Pi
5.) An update to the code based upon Cooking Hacks latest ArduPi library
Keep your eyes on this space for updates on progress!
Introduction
In my post on Y-Hack I touched upon a Python based technology called BreakfastSerial. Some of you Arduino fans out there may already be familiar with it, but for those who are not I have provided short guide below.
BreakfastSerial is a Python based library that allows you to write Python code that can be run on the Ardunio.
The technology
The library runs on top of a technology called Firmata.
Firmata is a generic protocol for communicating with Microcontrollers from software running on a host computer.
You can read more about the Arduino implementation of Firmata at the Arduino.cc website:
http://arduino.cc/en/Reference/Firmata
BreakfastSerial works by allowing you to interact with Firmata loaded onto your Arduino by writing Python code.
You simply upload Firmata to your Arduino board, and then can start writing Python applications that use it.
We will look at an example next.
Setting up Firmata
In this post I will only be covering the steps for the older boards such as the Uno. There is a separate post in the works for the YUN. I will also be assuming you are using a Linux like environment (Ubuntu, Mac terminal window, Cygwin etc.)
To start with you will need to open up the Arduino IDE sketch pad, if you haven’t download it already you can find it at:
http://arduino.cc/en/Main/Software
Note, that depending on your Arduino model (e.g. Uno versus YUN) there are different versions of the IDE.
Once you have the IDE installed, you can find the Firmata software under:
File -> Examples -> Firmata -> StandardFirmata
Next connect your board up to your computers USB port and upload the sketch.
Once uploaded you can then move onto the testing out BreakfastSerial.
Installing BreakfastSerial
Open a terminal window on your machine and using pip grab the latest version of BreakfastSerial from PyPi
pip install BreakfastSerial
I tend to work in a virtual environment when using Python. If you wish to do the same, you can create a virtual environment as follows
virtualenv --system-site-packages Ardunio
This will create a new directory called Arduino with a Python virtual environment in. From within this, you can activate it using
./bin/activate
If you don’t have virtualenv on your machine you can grab it using pip:
pip install virtualenv
Next we can create a test project using Python. Before we do this though, take an LED and attach it to digital Pin 13 and Ground on your Arduino – yes you guessed it we are going to make the LED blink.
Once you have your hardware hooked up, create a new Python file called blink.py for example:
vim blink.py
Inside this file we are going to add the following code:
from BreakfastSerial import Arduino, Led
Here we are importing Arduino and Led from the BreakfastSerial library.
Next let’s add the following code:
board = Arduino()
pin = 13
led = Led(board, pin)
This sets up a variable board with an instantiation of Arduino and a
pin variable set to 13 (where you attached your LED). Finally the
led variable is declared with a copy of Led(), which we pass board
and pin to as arguments.
Once you have added the above, we can include the final piece of code that creates the blinking action:
led.blink(200)
the above is pretty self explanatory. The led is switched on, we wait two seconds and then it is switch off.
Save the file and exit.
We can now test our application. From the command line run:
python blink.py
You should now see your LED blink.
And that’s all there is too it really.
There are a host of examples you can try located on the BreakfastSerial site:
https://github.com/theycallmeswift/BreakfastSerial/tree/master/examples
have fun!
Then Arduino YÚN is out now. Check it out at Adafruit:
http://www.adafruit.com/products/1498
It will set you back $89.95.
Iothome.org is now up and running.
Internet Of Things @ Home 