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:
- A Raspberry Pi – the manager
- The agent – the software running on pfSense
- pfSense firewall hardware -the managed device
- NMS (Network Management System) – the software component on the Raspberry Pi
Let’s take a quick look at the SNMP protocol before we start configuring our devices to familiarize ourselves with the features.
SNMP version 1.
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.184.108.40.206.220.127.116.11 = 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.
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.
SNMP version 3.
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.
Setting up the Raspberry Pi.
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:
Then change the rocommunity to mysnmptext
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.18.104.22.168.22.214.171.124 = 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-downloader
After 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
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.
Testing our setup
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.