In project proposal section I stated that for my project I wanted to build an inline Intrusion Detection System (IDS) device using the Raspberry Pi B rev 2 board using a Debian Linux based operating system, an inline IDS device is whether it is placed physically in-between to devices or hosts on a network and incepts all the network traffic that is passed between the two devices. This is instead of a passive IDS device which is connected to a network via a device such as switch and passively attempts to intercept the network traffic. This device should be placed on network links where security is vital such as the following:
- Between a router and a switch device.
- Between a router and another router device.
- Or a critical network device and the rest of the network.
Another part of this inline IDS device was that I wanted this device to be able to capture the network traffic flowing through the device as part of a network audit ability, this would be performed by using a tool such as network sniffer. Along with the network sniffer this inline IDS device would actually need a IDS software installed on it to perform IDS functions. For the above requirements I decided on the following tools:
- The network sniffer would be a command-line tool called TCPdump.
- And the IDS software would a commonly known and used software called Snort.
Raspberry Pi Model B Rev 2 Specifications
SoC: Broadcom BCM2835 (CPU, GPU, DSP, SDRAM, and single USB port)
CPU: 700 MHz ARM1176JZF-S core (ARM11 family)
GPU: Broadcom VideoCore IV, OpenGL ES 2.0 (24 GFLOPS), MPEG-2 and VC-1 (with license), 1080p30 h.264/MPEG-4 AVC high-profile decoder and encoder
Memory (SDRAM): 512 MB (shared with GPU)
USB 2.0 ports: 2 (via the built in integrated 3-port USB hub)
Video outputs: Composite RCA (PAL and NTSC), HDMI (rev 1.3 & 1.4), raw LCD Panels via DSI, 14 HDMI resolutions from 640×350 to 1920×1200 plus various PAL and NTSC standards.
Audio outputs: 3.5 mm jack, HDMI, and, as of revision 2 boards, I²S audio (also potentially for audio input)
Onboard storage: SD / MMC / SDIO card slot (3,3V card power support only)
Onboard network: 10/100 Ethernet (8P8C)
Low-level peripherals: 8 × GPIO, UART, I²C bus, SPI bus with two chip selects, I²S audio +3.3 V, +5 V, ground
Power ratings: 700 mA (3.5 W)
Power source: 5 volt via MicroUSB or GPIO header
Size: 85.60 mm × 53.98 mm (3.370 in × 2.125 in)
Weight: 45 g (1.6 oz)
The above specifications of the Raspberry Pi B board there is only one Ethernet port on the board where in this project I would be requiring two Ethernet ports to perform the desired inline IDS functions, I decided to use a USB to Ethernet adaptor to give me a second Ethernet port on the device as there are two USB ports built-in the Raspberry Pi B board. Along with needing to have two Ethernet ports for the device for the inline functionality, I will need to determine a method in which the Ethernet ports are able to intercept network traffic from multiple subnets over the same link, such as setting the ports into a promiscuous state and also allow the network traffic to continue to flow through the device.
The final part of my planning for my project was if the device has two Ethernet ports and both are in a promiscuous state I would need another method to connect to the device while it is deployed to be able to see the logs of the IDS software as events occur. I decided the way an administrator would be able to connect to the decide was via a USB wireless adaptor where the device uses one of two solutions:
- The device hosts an Ad-hoc network and the administrators connect to the device’s Ad-hoc network and then to the device.
- Or the second option was the device would connect to a specific network that the administrator chooses.
With the final part of the project planning completed the requirements for the project were the following:
- A Debian Linux based operating system
- A USB to Ethernet adaptor
- A USB wireless adaptor
- Install TCPdump and Snort
- A way to set the two Ethernet ports into a promiscuous state while still allowing the network traffic to flow through
- A way for administrators to remotely connect to the device while deployed
Building the IDS device
Operating System Preparation
In this section I write about what I did to prepare the IDS device’s operating system to a baseline starting point to build on. The first part of the preparation was downloading an operating system for the Raspberry Pi device and writing it to an SD card for the device to read, for this I decided to use Raspbian operating system image, as in my project proposal section above I planned to work a Debian based Linux distribution, which can be download from the Raspberry Pi website. Once the Operating system had been written to the SD card, this process can be found in Appendix #3, I began preparing the operating system by completing the following tasks:
- resize partition to use entire SD
- reconfigure timezone
- apt-get update
- apt-get upgrade
- mkdir -p /root/IDS-log/networkdump
- mkdir -p /root/IDS-log/snortdump
- echo “RaspIDS” > /etc/hostname
After completing the above tasks I checked to make sure everything was completed successfully, I checked that the re-sizing of the partition was successful using the “df” Linux command which showed that the re-sizing was successful and is now using the entire SD disk space.
df -h output
root@raspberrypi:~# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 16G 1.9G 13G 13% /
/dev/root 16G 1.9G 13G 13% /
devtmpfs 212M 0 212M 0% /dev
tmpfs 44M 252K 44M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 88M 0 88M 0% /run/shm
/dev/mmcblk0p1 56M 19M 38M 34% /boot
Once the above tasks were completed I made a backup .img file of the operating system in case in the future dealings with my major project a problem arises were the operating system becomes corrupted I would be able to restore from a baseline .img file.
As the Raspbian operating system was a bare minimal operating system, the basic essentials needed for an operating system to run, the tools I had planned to use would not be installed by default in the operating system. This meant I was required to install the tools need, as I was using a Debian based Linux distribution, Raspbian, the package manager I use by default was aptitude. I began with checking the aptitude repository to determine if I could install the tools from aptitude or if I need to compile from source code or another method. I did this by searching the Ubuntu package repository for the tools I wanted to use.
Since I knew the software packages that I want to install exist in the Debian package repository I just used the command “apt-get install <package>” to install the software.
In this section I cover how I planned to configure the interfaces of the in-line IDS device.
Configuring the Ethernet Interfaces
The IDS device has been planned to be an in-line IDS device oppose to being a passive IDS device. An in-line IDS device is meant to have two physical interfaces where both the physical interfaces are connected to a link within a network, the device will act as a man-in-the-middle and any machine or host communication across the link will not notice the device’s presence.
In my research to learn possible solutions to meet the requirements I found an answer in another Raspberry Pi user’s blogpost about their project. The below commands perform the following:
- Sets the IP address 0.0.0.0 to the two physical interfaces (eth0 & eth1).
- Using the command “brctl” creates a virtual bridge interface (bridge0).
- Then adds the two physical interfaces to the virtual bridge interface.
- Finally turns on the virtual bridge interface.
ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0
brctl addbr bridge0
brctl addif bridge0 eth0
brctl addif bridge0 eth1
ifconfig bridge0 up
The reason why the IP address 0.0.0.0 was chosen was because it is a way that “any IPv4-interface at all” can be specify, this is useful as the device could be placed on a link where multiple networks travel through such as Vlans and the two physical interfaces can only be assigned to one network as time which means network traffic could be missed. Along with the IP address the use of a virtual bridge interface was desired because it combines the two physical interfaces together in a central point which is useful when working with tools.
As the command “brctl” is not installed by default in Debian I need to install it before I could configure the virtual interface, this was simply done by use this following:
apt-get install bridge-utils
Configuring the Wireless Interface
In the project planning section I planned that administrators would be able to connect to the IDS device via a wireless network as the physical Ethernet ports are being used in the IDS auditing function. The initial plan was for the IDS device was for it to host an Ad-hoc network which administrators would connect too. Due to unforseen problems, which more information can be found about the problems in Appendix #2, I chose to change the wireless configuration concept from an Ad-hoc hosting network to whether the IDS device connects to a specific wireless network of the administrators choosing, more information about the change can be found in Appendix #1.
The below configuration was used to specific what wireless network the wireless interface will connect to on boot up.
iface wlan0 inet static
address <IP Address>
gateway <gateway IP>
wpa-ssid <ESSID of network>
wpa-psk <key of network>
Once the device has been given an IP address the administrator is then able to use SSH to connect to the device over wireless.
Writing the Autostart bash Script
In the project plan I had planned to use a script which would run when the device boots up which would configure all the necessary requirements for the device to begin performing networking auditing and inspecting with little to no human interaction. This includes the following:
- Set the IP address of physical interfaces of the device (onboard and USB adaptor) to 0.0.0.0.
- Create a virtual bridge interface and add the two physical interfaces to the bridge.
- Begins the auditing tools (TCPdump & Snort) on the bridge interface and output the information to a file in a specific directory with a specific date of when the file was began.
- Starts the Wireless Ad-Hoc network on the device to allow for a remote administrator to connect to the device while active.
The below script was what I created to perform the required tasks.
#!/bin/bash # Configures the virtual bridge between the two physical interfaces. ifconfig eth0 0.0.0.0 ifconfig eth1 0.0.0.0 brctl addbr bridge0 brctl addif bridge0 eth0 brctl addif bridge0 eth1 ifconfig bridge0 up # Configures Snort and TCPdump tools to begin listen and inspecting # the network traffic that travels through the bridge interface. TCPdump -i bridge0 -w /root/IDS-log/networkdump/network-traffic-$(date +%y%m%d).cap & Snort -i bridge0 -v |tee /root/IDS-log/snortdump/Snort-dump-$(date +%y%m%d) &
Once I had finished writing the script I needed it to be executed during the start up process of the device automatically, I found while researching this topic that if I place the location of the script I wanted execute to the end of the /etc/rc.local file it would be executed every time the device is turned on.
Device Testing & Auditing
After configuring the bridge and physical interfaces on the IDS device and tested to see if my two test machines could communicate with each other through the IDS device, I set the IDS device to test whether TCPdump could capture the network traffic flowing through the virtual bridge interface. As this was a test whether TCPdump would work I used the command “TCPdump -i bridge0″, the test showed that TCPdump would work in combination with the virtual bridge interface to capture the traffic flowing through the two physical interfaces without the two end machines aware of the IDS device in the middle.
After testing TCPdump and the virtual bridge interface, I then began testing Snort and working with the virtual bridge interface. In the above section of “Snort Configuration” I showed that I had added a rule to the local.rules file which was “alert icmp any any -> $HOME_NET any (msg:”ICMP test”; sid:10000001; rev:1;)” this rule will alert me if an icmp packet from any source going to any destination was detected, this would allow me to test if Snort was working with the virtual bridge interface, the below screenshot shows the Snort test was successful and Snort was working with the virtual bridge interface.
Autostart Bash Script
Once the testing of the tools and the autostart bash script had been completed, I broke the testing of the script into two parts, the initial testing of the script where I test the functionality of the script and the second part is the autostart feature.
Initial Script test
In the above screenshot as part of the autostart bach script inital test I began the test with checking that the two storage locations for the outputs. Once the locations were checked I ran the script and used the command “ps” to verify that the tools were running in the background as per the design of the script in the Writing the Autostart bash Script section.
Autostart Script Test
As per in the Writing the Autostart bash Script section had add the location of the location of the startup script to the end of the /etc/rc.local file and restarted the device to test if the autostart function of the script worked.
Before restarting the device I made sure that both networkdump/ & snortdump/ directories were empty as well as the bridge0 interface was turned off and then rebooted the device. When the device came back online I used the command “ps” to show the current processes running in the background but didn’t show tcpdump or snort running, I could see the script had configured the virtaul bridge interface and made the dump files, so using the command “ps -aux” I was able to see that tcpdump and snort where in fact running in the background of the device.
Real-Life Test Scenario
The final part of the inline IDS device testing phase was to design a scenario which replicates a real-life case environment or event in which this device would be deployed into. The scenario I came up with was a basic test in which the device is placed in between two laptop devices which are connected together via Ethernet cable one laptop is to be the attacking laptop and the other is to be the victim laptop, in the scenario the attacker will perform a network scan of the victim laptop as part of the enumeration phase, once the scan is returned the attacking laptop will attempt to execute a vulnerability found by the network scan. The role of the inline IDS device is to be able to capture the network traffic for the entire scenario from the enumeration phase to the exploitation phase and post-exploitation phase by using TCPdump, as well as Snort will be used to alert the administrator to events happening in the scenario.
Nmap Scan Detection
From the attacking laptop I scanned the victim using a network scanner called Nmap using the command “nmap -Pn -sS -sV -A 192.168.10.2”, this scan returned the following information.
I checked the tcpdump .cap file, using the command “tcpdump -r [filename]”, to see that it had successfully captured all the packets sent during the network scan of the victim machine.
After checking the tcpdump logfile I checked the Snort logfile to see if Snort had flagged any suspicious packets or network traffic which needed to be checked, when going through the logfile I was able to determine that every packet during the nmap scan was flagged as suspicious.
In the actual exploitation phase of the real-life scenario from the nmap scan above I decided to target the NetBIOS service of the victim machine running on port 445. Using the attacking machine which contains an installed version of Kali Linux I used Metasploit to find a vulnerability for the NetBIOS service, which I found to be ms08_067_netapi, I then successfully exploited the victim machine gaining a reverse meterpreter shell back to my attacking laptop.
Once the service was exploited I then used tcpdump like in the enumeration section above to read the .cap file for the actual attack packets.
And then the final part to see if Snort was able to flag any of the network traffic from the attacking machine to the victim machine.
From the above sections the device was able to perform as expected in a real-life scenario in which an attacker attempts to exploit a vulnerability found in a victim machine in attempt to gain remote access to the victim machine.
As part of my major project I produced several deliverables such reports and backup files of the operating system for the Raspberry Pi device. I’ve added these deliverables to a dropbox directory which can be found here.