Sunday, July 22, 2018

802.11n monitoring

Today I learned that from the perspective of monitoring wireless networks, 802.11n differs from 802.11b/g in a couple of important ways:

First, there's an option to use 40 MHz channels, where, if I understand correcty, 802.11b/g are limited to 20 MHz.

Second, there's the option to use multiple data streams to increase performance.

Why am I talking about this?

I'm talking about these differences because if you want to monitor 802.11n communications, you need to match the negotiated capabilities between the AP and client you intend to monitor. I've been doing some work involving monitoring a wireless network, and I spent longer than I'd like to admit trying to understand why my AWUS036NH/airmon-ng/wireshark monitoring setup was failing to capture all of the packets. Eventually I came across this question on Superuser about a similar topic. Some smart person responded with a wonderful enumeration of some reasons why I may not see all of the traffic, which made me remember that I used a different client for my initial work.

Specifically, using my AWUS036NH I'm able to capture all wireless traffic from the AP to/from a Samsung Galaxy Tab A (SM-T280), but almost none of the traffic (except some TCP retransmits once in a while) to/from a Motorola Z. My guess is that the Moto Z has more advanced capabilities than the AWUS036NH has, which means the AWUS036NH can't see all of the traffic. As soon as I switched back to the Tab A, I was able to see all of the traffic again.

I'd like to dig up the details of these devices to try to confirm my suspicion, but a quick googling didn't turn up the specifications I was looking for.

Thursday, July 19, 2018

Phantom 3 telemetry post 2

In my last post I documented my progress with decoding the DJI Phantom 3 telemetry protocol between the controller, aircraft, and DJI Go app. This post picks up where I left off, attempting to reverse engineer the Phantom 3 protocol, focusing on data stream from the controller. Unfortunately the controller data is minimally useful for my goal of writing a ground station program, but it's interesting and it helps me further understand the protocol.

Follow-up


A fellow named David was kind enough to leave a comment on my previous post, linking his own protocol reverse engineering work with the DJI Phantom 3. He seems to have discovered some additional details about the protocol through reverse engineering the DJI Go Android app, which I've used to accelerate my work.

Message Header


In my preliminary analysis, I observed that byte 3 seems to correlate with message length. This made me think it may have been a message ID field, but apparently it's an 8-bit CRC of the first three bytes of the message. This makes sense, since the only field in the header that varies is message length! This also explains my observation that byte 2 never changes; It's mostly a version number and the most significant bits of the message length (which are usually zero, since I haven't observed any messages with lengths greater than 255).

Here's the structure of the four-byte DJI message header, thanks to David:
+-------+----------+------------+--------+----------+
| Bit   | 00000000 | 0111111111 | 122222 | 22222233 |
|       | 01234567 | 8901234567 | 890123 | 45678901 |
+-------+----------+------------+--------+----------+
| Field | magic    | length     | ver    | CRC      |
+-------+----------+------------+--------+----------+

Message Source/Target


The first two bytes of the payload describe the source and target systems for this message.

Source/Destination fields:
+-------+----------+-----------+
| Bit   | 00000000 | 011111111 |
|       | 01234567 | 890123456 |
+-------+----------+-----------+
| Field | msg src  | msg tgt   |
+-------+----------+-----------+

The source/target bytes contain two fields: system and subsystem. The system field is 7 bits wide and the subsystem field is 3 bits wide. The system field describes a major component in the system. This includes things like the hand controller, flight controller, camera, mobile app, etc. I'm not really sure what the subsystem field means yet.

Sequence Number


The next field in the payload is a 16-bit counter that seems to increment independently for different types of messages. For example, I've observed that each source/target combination has a distinct counter. In some cases, this counter seems to be used as an acknowledgement.

Flags


The next field contains 8 bits of flags. Two of these seem to have somewhat clear meanings, but the rest I'm not sure about. The flag in bit 0 seems to indicate that the message is an acknowledgement to a previous message, and the flag in bit 1 seems to indicate that this message requires an acknowledgement.

I'm guessing about these meanings because of observations like the following:
Message N:
Source(sub-source): 3(3)
Target(sub-target): 2(0)
Sequence Number: 429
Flags: 0100 0000

Message N+1:
Source(sub-source): 2(0)
Target(sub-target): 3(3)
Sequence Number: 429
Flags: 1000 0000

Command Set/Command


Following the Flags byte, there are two bytes that represent a Command Set and Command, respectively. It seems reasonable that a system/subsystem may have more than one type of message to send (or receive), but I haven't tried to make sense of this field yet. So far the messages that I've looked closely at are defined well-enough by the source, target, and length.

Payload


The payload field is a variable length string of bytes whose meaning changes depending on the context. I've only been able to fully decode one of these, which I'll talk about shortly.

CRC


Finally there's the CRC. I had the right idea initially with the 16-bit CRC field following the payload field, but I couldn't seem to find a match for a CRC algorithm and initialization value. I tried using some online CRC calculators (this one, and this one) by manually entering the byte sequences for some small packets that I had observed, but I couldn't find a match. It turns out that DJI actually has the code for their CRC algorithm on Github.

Discovering Field Boundaries - The Controller


I've never really attempted protocol reverse engineering before this project, but in my fumbling around in the dark I learned something: My assumption that decoding static data would be easier than dynamic data was wrong. The problem with static data (e.g. things like switch positions, camera mode, and other status information that doesn't often change) is that it's very hard to see the field boundaries in the data, particularly in the case of fields that cross byte boundaries.

In order to find field boundaries in the data streams, I need to make the data change. Ideally, I need to make it change one field at a time so that I can see the field boundaries and begin decoding the data. Where should I start? I need some data that I can control. Aircraft position and attitude are really the targets that I want to go after, but I think those are going to be changing pretty much constantly. The buttons and joysticks on the controller are an obvious choice, since these won't change unless I move them, and I can make them change one at a time.

By playing with the controller one axis at a time, I was able to determine the following payload layout for messages with source 6(1) and a length of 26 bytes:
+--------+-------------------------------+
| Bytes  | Field                         |
+--------+-------------------------------+
| 12, 13 | right stick - left/right axis |
+--------+-------------------------------+
| 14, 15 | right stick - up/down axis    |
+--------+-------------------------------+
| 16, 17 | left stick - up/down axis     |
+--------+-------------------------------+
| 18, 19 | left stick - left/right axis  |
+--------+-------------------------------+
| 20, 21 | camera elevation              |
+--------+-------------------------------+

Next Steps


Now that I have a technique for discovering field boundaries for fields that I can control, I'd like to try to find the aircraft attitude fields next. I should be able to control pitch, roll, and compass heading fairly easily.

Monday, May 28, 2018

Living with NetwokManager: Configuring an 802.11 Monitoring Interface

Background


In a previous post about reverse engineering a network protocol, I included some information about monitoring 802.11 wireless networks. After configuring a monitoring interface more than a few times, I started looking for ways to streamline the setup.

I'm using an EliteBook 8570p running Fedora 27 for my analysis work. I'd like to use my laptop's internal wifi card to stay connected to my home wifi network while monitoring another network with a USB wifi adapter. After reading some blog posts [1] and the terrible NetworkManager documentation, I was able to get this working and I thought I'd share. These modifications are probably specific to Fedora, but I suspect any distribution using NetworkManager could be configured similarly.

When I connect my USB adapter, the output from nmcli dev status indicates that NetworkManager wants to control it.



The first time I tried to automate disabling NetworkManager control of a wireless device, I went down the path of configuring NetworkManager to ignore the device by its MAC address. In order to do that, I had to disable NetworkManager's built-in MAC randomization for wireless devices, and after some thought I decided I'd rather not do that. The method described below uses a UDEV rule to tell NetworkManager to leave my USB wifi adapter alone, which seems simpler and safer.

UDEV Rule


First I gathered some info about the device by running udevadm info /sys/class/net/wlp0s20u4 (replace wlp0s20u4 with the name of your interface). The parts I'm interested in are ID_VENDOR_ID and ID_MODEL_ID.

P: /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/net/wlp0s20u4
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/net/wlp0s20u4
E: DEVTYPE=wlan
E: ID_BUS=usb
E: ID_MM_CANDIDATE=1
E: ID_MODEL=802.11_n_WLAN
E: ID_MODEL_ENC=802.11\x20n\x20WLAN
E: ID_MODEL_FROM_DATABASE=RT2870/RT3070 Wireless Adapter
E: ID_MODEL_ID=3070
E: ID_NET_DRIVER=rt2800usb
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=wlp0s20u4
E: ID_NET_NAME_MAC=wlx00c0ca96aee3
E: ID_NET_NAME_PATH=wlp0s20u4
E: ID_OUI_FROM_DATABASE=ALFA, INC.
E: ID_PATH=pci-0000:00:14.0-usb-0:4:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_4_1_0
E: ID_REVISION=0101
E: ID_SERIAL=Ralink_802.11_n_WLAN_1.0
E: ID_SERIAL_SHORT=1.0
E: ID_TYPE=generic
E: ID_USB_DRIVER=rt2800usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=Ralink
E: ID_VENDOR_ENC=Ralink
E: ID_VENDOR_FROM_DATABASE=Ralink Technology, Corp.
E: ID_VENDOR_ID=148f
E: IFINDEX=36
E: INTERFACE=wlp0s20u4
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp0s20u4 /sys/subsystem/net/devices/wlp0s20u4
E: TAGS=:systemd:
E: USEC_INITIALIZED=129405399440

I used this info to write the following UDEV rule, which I saved in a file called /etc/udev/rules.d/99-alfa.rules, that sets the NM_UNMANAGED environment variable to 1:

SUBSYSTEM=="net", ACTION=="add", ENV{ID_VENDOR_ID}=="148f", ENV{ID_MODEL_ID}=="3070", ENV{NM_UNMANAGED}="1"

That's it. Now when I plug my USB wifi adapter in, NetworkManager shows it as "unmanaged".


Follow up


Now that my USB wifi adapter won't be misconfigured by NetworkManager, I should have an easier time setting up my system for monitoring. As a follow up, I'm working on configuring UDEV to execute a script to automatically put this interface into monitor mode as soon as it's connected. I'll share that in my next post.

Sunday, April 29, 2018

Oracle JDK on Fedora 27

This post explains how I install the Oracle JDK on Fedora 27.

1. Download


Validate the checksum against the published values listed here: https://www.oracle.com/webfolder/s/digest/10-0-1checksum.html
$ shasum -a 256 jdk-10.0.1_linux-x64_bin.tar.gz

2. Install

I like to install the JDK in /opt/java.
$ cd /opt/java
$ tar -xf jdk-10.0.1_linux-x64_bin.tar.gz

Now there should be a directory on the system that looks like /opt/java/jdk-10.0.1. In order to make updating the JDK easier in the future, create a symlink at /opt/java/latest that points to the latest installed version. This way we won't have to update the alternatives every time we update!
$ ln -s jdk-10.0.1 latest

3. Update alternatives

Fedora ships with OpenJDK installed by default and there are a bunch of packages that depend on it. However, we can use the alternatives command to allow the Oracle JDK and OpenJDK to coexist.

First let's tell alternatives about the Oracle JDK binaries:
$ alternatives --install /usr/bin/java java /opt/java/latest/bin/java 1000
$ alternatives --install /usr/bin/javaws javaws /opt/java/latest/bin/javaws 1000
$ alternatives --install /usr/bin/javac javac /opt/java/latest/bin/javac 1000
$ alternatives --install /usr/bin/jar jar /opt/java/latest/bin/jar 1000

Now we can make sure the correct version of the java command is selected, and update the configuration if necessary:
$ alternatives --config java

4. Verify

Let's make sure the Oracle JDK version of /usr/bin/java is being used:
$ java -version
java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

Final Thoughts

When a new Oracle JDK is released, we can just install it in /opt/java and update the symlink!

Sunday, January 29, 2017

Monitoring Telemetry for the DJI Phantom 3

I picked up a DJI Phantom 3 Standard drone about 6 months ago, and since the first time I flew it around my yard using the controller and DJI Go Android app, I've wondered about the possibility of using some kind of PC-based ground station software to control it.

If the DJI Go app uses WiFi to communicate with the drone, then in theory so could an application running on a laptop, right?

I did a little searching and found out that, at least for this model, DJI doesn't offer any official ground station software. That's when my gears started turning; Could I write some software to control the Phantom 3? We'll see, but the first step is trying to understand how the DJI Go app and the drone communicate, which is the subject of this post.

Recon


The first thing I needed to do is understand what systems are present on the Phantom 3 WLAN.

Note: Remove the propellers before turning the system on indoors!

I powered up the Phantom 3 and remote controller, then I connected my laptop to the PHANNTOM_240536 network. This network uses WPA pre-shared key authentication with a default password of 12341234 (which I should probably change). Once connected, I noticed that my laptop was given the IP Address 192.168.1.21 with a netmask of 255.255.255.0. Knowing the subnet in use on the Phantom 3 WLAN, I used an nmap ping sweep to find active hosts.

[user@eb8570p dji_re]$ nmap -sP 192.168.1.0/24

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-29 16:40 EST
Nmap scan report for 192.168.1.1
Host is up (0.0016s latency).
Nmap scan report for 192.168.1.2
Host is up (0.011s latency).
Nmap scan report for 192.168.1.3
Host is up (0.020s latency).
Nmap scan report for 192.168.1.20
Host is up (0.042s latency).
Nmap scan report for 192.168.1.21
Host is up (0.00020s latency).

My laptop is .21, the tablet is .20, so the .1-.3 addresses must be parts of the DJI system. Next I tried to see if there was anything else nmap could tell me. To do that I used an nnap port scan for each of the Phantom 3 system hosts.

[user@eb8570p dji_re]$ sudo nmap -p 1-65535 -sS 192.168.1.1

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-29 17:09 EST
Nmap scan report for 192.168.1.1
Host is up (0.0051s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
2345/tcp open  dbm
MAC Address: 60:60:1F:24:05:36 (SZ DJI Technology)

Nmap done: 1 IP address (1 host up) scanned in 22.29 seconds

The numerical part of the Phantom 3 WLAN SSID seems to be three of the octets from the MAC address of this host.

[user@eb8570p dji_re]$ sudo nmap -p 1-65535 -sS 192.168.1.2

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-29 17:09 EST
Nmap scan report for 192.168.1.2
Host is up (0.066s latency).
Not shown: 65533 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
5678/tcp open  rrac
MAC Address: 60:60:1F:10:1B:E3 (SZ DJI Technology)

Nmap done: 1 IP address (1 host up) scanned in 35.70 seconds

[user@eb8570p dji_re]$ sudo nmap -p 1-65535 -sS 192.168.1.3

Starting Nmap 7.40 ( https://nmap.org ) at 2017-01-29 17:10 EST
Nmap scan report for 192.168.1.3
Host is up (0.074s latency).
Not shown: 65532 closed ports
PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
23/tcp open  telnet
MAC Address: 4E:EC:D3:3F:BB:B3 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 33.35 seconds

Well, nothing earth shattering there. I'll just keep this info for reference. After some googling, I was able to learn from [1] and [3] that the systems above have the following assignments:

192.168.1.1 - Controller
192.168.1.2 - Aircraft
192.168.1.3 - Camera

This is really helpful information, because it allows me to focus on what I'm really after: telemetry from the aircraft itself.

Passive Monitoring


Now that I had some understanding of the network, the next step was to monitor the WLAN and see who's talking to who. For this part I used my trusty Alfa USB WLAN adapter and Wireshark. Something I didn't realize right away is that WPA-PSK uses information other than just the pre-shared key to encrypt communications between hosts. This means that simply authenticating to the access point doesn't grant me access to all the traffic on the WLAN. In order to do that, I'll have to monitor the WPA client authentication sequence to grab all of the crypto material necessary to decrypt communications between the Phantom 3 and the DJI Go app running on the Android tablet. That all sounds super complicated, but luckily Wireshark and aircrack-ng can do most of the work.

I needed to put the Alfa card into Monitoring mode, and as a prerequisite step I had to disable some conflicting services.

[user@eb8570p dji_re]$ sudo airmon-ng check kill
[user@eb8570p dji_re]$ sudo airmon-ng start wlp0s20u2 6

The 6 here is the channel we want to monitor. My Phantom 3 seems to be configured to use channel 6.

With the WLAN adapter in Monitor mode, it's time to get Wireshark set up. First we need to tell wireshark about the WPA pre-shared key for the PHANTOM_240536 SSID. To do that, the Key can be entered in the IEEE-802.11 preferences dialog. This dialog can be accessed by navigating to Edit -> Preferences-> Protocols -> IEEE-802.11. Then click the Edit button to edit decryption keys. In the WEP and WPA Decryption Keys dialog, click the New button, then select wpa-psk, and enter your key in the form: psk:ssid. For me this looked like: 12341234:PHANTOM_240536.

Now that the interface is in Monitor mode and Wireshark is ready to listen, we need to make sure Wireshark is able to capture the client authentication handshake from the tablet. The easiest way to do this is to kick the tablet off the WLAN to force it to re-authenticate. This is done with aireplay-ng.

sudo aireplay-ng -0 1 -a 60:60:1f:24:05:36 -c bc:76:5e:6a:d4:b3 wlp0s20u2mon
The -a argument specifies the MAC address of the access point, and the -c argument specifies the MAC address of the client.

With airmon-ng and Wireshark ready to monitor the WLAN, I powered on the drone and controller, then started the DJI Go app on the tablet.


Right away the app connects to 192.168.1.1 on port 2345, and shortly thereafter also connects to 192.168.1.2 on port 5678. At a glance, both of these conversations seem to be mostly the Phantom 3 talking to the tablet, with a packets going the other direction every once in a while. My guess is that once the app connects, .1 and .2 stream status information to the app, while the app occasionally sends commands.


Finally, there's a UDP (UDT) handshake with 192.168.1.3, followed by a constant stream of data from 192.168.1.3 to the tablet, which I'm guessing is the encoded video.

Protocol Analysis


Assuming the UDP traffic is video, I focused my attention on the two TCP connections. Furthermore, I focused on the packets going from the Phantom 3 to the tablet. I figured if I can write a program to connect to these TCP servers and report telemetry for the drone, that would be pretty cool. I can always add command and control capabilities later... I've included the first 8 bytes of some received payloads below (I stripped out beyond that because some of the packets probably include location data).

55 1A 04 B1 0E 02 4C 2D
55 1A 04 B1 0E 02 4D 2D
55 1A 04 B1 0E 02 4E 2D
55 19 04 E4 1B 02 7D 0A
55 1A 04 B1 0E 02 4F 2D
55 1A 04 B1 0E 02 50 2D
55 1A 04 B1 0E 02 51 2D
55 12 04 C7 0E 02 52 2D
55 1A 04 B1 0E 02 53 2D
55 0D 04 33 1B 02 7E 0A
55 1A 04 B1 0E 02 54 2D
55 0E 04 66 1B 02 7F 0A
55 0E 04 66 1B 02 80 0A
55 1A 04 B1 0E 02 55 2D
55 1A 04 B1 0E 02 56 2D
55 1A 04 B1 0E 02 57 2D
55 1A 04 B1 0E 02 58 2D
55 1A 04 B1 0E 02 59 2D
55 19 04 E4 1B 02 84 0A
55 1A 04 B1 0E 02 5A 2D

After exporting the payloads and staring at them for a while, a couple patterns emerge. First, there's some kind of preamble or magic byte (0x55) at the beginning of each payload. Next, the second byte always matches the length of the payload in bytes. Also, the last two bytes of the payloads seem to vary randomly for each packet. I'm guessing there's a 16 bit checksum or CRC at the end of the messages, but I've been unable to figure out exactly how that's calculated. So there are preamble, length, and integrity check fields in the PDU; pretty normal stuff, and that's a good start.

I can see that the 3rd and 6th bytes never change. I've disconnected the app and reconnected several times, and these are always the same. I'm guessing these bytes include some flag bits. After looking at lots of data, I've concluded that byte 4 is probably some kind of message type indicator. In my collected data, I only see about 10 different values here, and they always correspond to the same payload lengths. Byte 5 is interesting because it changes, but only between a couple observed values. It could be flags, or it could be part of a multi-byte field that I don't understand yet.

Interestingly, byte 7 seems to increment two distinct counters.

Next Steps


The remainder of the payloads are going to be tough to decode. I think my best bet is to go for the low-hanging fruit, and try to find the position and attitude data. With the drone sitting on the table, that data should be relatively static, and if I were designing this protocol I'd probably use either 16 or 32 bits to represent angles. If I hold the drone steady and rotate just one axis, the data might give the fields away.

More to come in follow up posts...

References


I found the following useful sources of information while researching the Phantom 3 protocol:
[1] http://dronesec.xyz/2017/01/25/hacking-the-dji-phantom-3/ This blog post includes a lot of the same information as my research, except that it's written from an information security perspective.
[2] https://github.com/noahwilliamsson/dji-phantom-vision GitHub project for the Phantom 2 protocol, which has some similarities to what I've observed, but seems to be a different protocol.
[3] http://forum.dji.com/thread-55122-1-1.html Forum post about discovery of the Phantom 3 WLAN hosts and their roles in the system.
[4] https://github.com/hardening/Cave/blob/master/phantom3-video.cpp GitHub - C++ program to grab Phantom 3 UDT video.
[5] https://wiki.wireshark.org/HowToDecrypt802.11 How to decrypt 802.11 packets in Wireshark.
[6] https://www.aircrack-ng.org/doku.php?id=deauthentication How to disassociate wireless clients.

Monday, November 4, 2013

Suricata on CentOS 6

This post will cover building and installing the Suricata IDS on CentOS 6.4.  This procedure is adapted from the following documentation from openinfosecfoundation.org:

https://redmine.openinfosecfoundation.org/projects/suricata/wiki/CentOS_56_Installation
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Basic_Setup

The following procedure assumes at least a minimal CentOS 6.4 installation with the base package group installed.

Not all of the prerequisite packages for building suricata are included in the CentOS repositories, so the EPEL package repository will fill in the gaps.

Add the EPEL repo to your system if you haven't already:

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Start by installing the prerequisite packages: (may take some time depending on your system and internet connection)

# yum install gcc gcc-c++ make automake autoconf libtool pcre pcre-devel libyaml libyaml-devel libpcap libpcap-devel file-libs file-devel libpcap libpcap-devel zlib zlib-devel libnet libnet-devel libcap-ng libcap-ng-devel
I've chosen to install gcc and autotools individually rather than install the Development Tools package group.  I think it's a good practice to limit unnecessary software on internet-accessible systems or systems with security-related roles, so I don't want a lot of the packages that come in the Development Tools group.  In fact, if you're really serious about security you would probably want to compile suricata on a development machine and leave gcc and autotools off of your production systems altogether.

Download and extract the suricata source tarball from openinfosecfoundation.org:

# wget http://www.openinfosecfoundation.org/download/suricata-1.4.6.tar.gz # tar -xzf suricata-1.4.6.tar.gz
Now build and install suricata:
# cd suricata-1.4.6 # ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var # make # make install-full
I've chosen the install-full target for installation, because this will create directories and install some rules and configuration files for us.

Now that suricata is built and installed we can go about configuring it and installing some support scripts.  I'm using oinkmaster set up to take care of updating the rules on my system.  Download the oinkmaster tarball from http://oinkmaster.sourceforge.net/download.shtml.  (I don't want to post a direct link because I'd have to choose a mirror for you, and I'd rather not)

Extract the files and install oinkmaster.conf and oinkmaster.pl on your system.
# tar -xzf oinkmaster-2.0.tar.gz # cd oinkmaster-2.0 # cp oinkmaster.pl /usr/bin # cp oinkmaster.conf /etc
Edit /etc/oinkmaster.conf and correct the url:
url = http://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz
We can now test oinkmaster:
# oinkmaster -C /etc/oinkmaster.conf -o /etc/suricata/rules
If all went well you should have a whole bunch of *.rules files in /etc/suricata/rules.  You probably want oinkmaster to update your IDS rules automatically, so something like the following in your crontab will do the trick.  For more information see: http://oinkmaster.sourceforge.net/readme.shtml.

30 2 * * * oinkmaster.pl -C /etc/oinkmaster.conf -o /etc/suricata/rules 2>&1 | logger -t oinkmaster
In order to make suricata process these rules we'll have to update its configuration.  First get a list of all the rules in /etc/suricata/rules with something like:
# ls /etc/suricata/rules/*.rules
We need to make sure all these rule files are listed in the suricata configuration, so open up /etc/suricata/suricata.yaml and check the rule-files section against the list of rule files.

The rule-files section in my suricata.yaml looks like this:

rule-files: - botcc.rules - ciarmy.rules - compromised.rules - decoder-events.rules - drop.rules - dshield.rules - emerging-activex.rules - emerging-attack_response.rules - emerging-chat.rules - emerging-current_events.rules - emerging-deleted.rules - emerging-dns.rules - emerging-dos.rules - emerging-exploit.rules - emerging-ftp.rules - emerging-games.rules - emerging-icmp_info.rules - emerging-icmp.rules - emerging-imap.rules - emerging-inappropriate.rules - emerging-info.rules - emerging-malware.rules - emerging-misc.rules - emerging-mobile_malware.rules - emerging-netbios.rules - emerging-p2p.rules - emerging-policy.rules - emerging-pop3.rules - emerging-rpc.rules - emerging-scada.rules - emerging-scan.rules - emerging-shellcode.rules - emerging-smtp.rules - emerging-snmp.rules - emerging-sql.rules - emerging-telnet.rules - emerging-tftp.rules - emerging-trojan.rules - emerging-user_agents.rules - emerging-voip.rules - emerging-web_client.rules - emerging-web_server.rules - emerging-web_specific_apps.rules - emerging-worm.rules - files.rules - http-events.rules - rbn-malvertisers.rules - rbn.rules - smtp-events.rules - stream-events.rules - tls-events.rules - tor.rules While we're editing suricata.yaml, the classification-file and reference-config-file fields also need to be updated:

classification-file: /etc/suricata/rules/classification.config reference-config-file: /etc/suricata/rules/reference.config

At this point, suricata is configured and can be tested with the following command:

# suricata -c /etc/suricata/suricata.yaml -i eth0

For a real IDS setup, we also need an init script for suricata, but I'm going to cover that in a follow up post.

Hope this has been helpful, thanks for reading!


Friday, June 22, 2012

efw-upgrade behind a proxy

The efw-upgrade command will fail for an EFW living on a network that requires use of an HTTP proxy.  To make it work efw-upgrade needs to be configured to use the proxy to download updates and repo data, but there doesn't appear to be any official documentation on how to do this.  EFW uses the Smart Package Manager, and luckily there's good documentation for smart. 

To make efw-upgrade work, use SSH or the console of the EFW to log in as root then run this command:

smart config --set http-proxy=proxyurl

My proxy url looks something like: http://a.b.c.d:8080