Scapy/Wifi Database

Overview

This page covers the use of Scapy to monitor wifi channels and populate a database with observations. These observations are completely passive and are at the physical layer (hardware) only. No network traffic.

Scripts Required

Capturing wifi data into a database will require two scripts:

• Scapy script to process wifi packets, parse information from them, send data to database
• Database script to create/connect to database, listen for data

Database Creation Process

Overview

When it comes to storing the collected wifi data in a database, you have a couple of options: 1. Store the wifi data in memory (i.e., in a Python list); the database disappears at the end of the program. 2. Store the wifi data in a file (i.e., in a CSV file); the database is now dumped to a file and can be parsed by other programs. Like airomon-ng with the output format option set. 3. Store the wifi data in an SQL database 4. Store the wifi data in a NoSQL database

Now, let's walk through the options.

Option 1 - this is how Aircrack works by default. Option 1 is out. Our end goal with this project will require that we capture data.

Option 2 - this is how Aircrack works when output format option is set. Option 2 is also out - we have tried this already, and it is the last-resort option.

Option 3 is out because types are a headache to deal with - we have tried this option already. In theory it should be easy. In reality, there's so much extra elbow grease required for converting Python types to SQL types, dealing with table schemas, and handling file-splitting logic, that this route became a total unwieldy mess.

Option 4 is in. No types to bother with - straight from Python dict to MongoDB.

Thus, the database creation script will essentially consist of setting up a MongoDB database/tables, running a test, viewing data, removing data, etc.

Preparing MongoDB

Start by installing MongoDB, then install Python bindings (pymodm library). On Mac OS X, you can install using Homebrew, then install Python bindings for MongoDB:

brew install mongodb
pip install pymodm

On Debian Linux, use apt-get, then pip:

# don't do apt-get install mongo-db
# see https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/
pip install pymodm

Once MongoDB is installed, you can start it up with the mongod command (you can specify different options on the command line), or you can run it and point it to a configuration file:

$ mongod -f /usr/local/etc/mongod.conf

Once that's done, MongoDB is installed, running, and ready to rock.

Database Schema

Here we'll explain the implementation of the wifi database (based largely on the information that was available/extractable from Scapy). This includes the schema, as well as the MongoDB commands.

NoSQL Verbiage

Before we talk about putting data into MongoDB, let's clarify how MongoDB refers to different concepts in code.

Nosql/Mongodb Concepts:

• Document - a document is a chunk of related data that represents a single observation or a single record. Equivalent to SQL record.
• Collection - a collection is an assembled group of documents that are all related somehow. Equivalent to SQL table.
• JSON - human-readable format that can be parsed by MongoDB
• Key/value - each Document in MongoDB has a set of key value pairs to store the data

NOTE: The key idea behind NoSQL is that Collections do not impose any requirements on Documents. This makes NoSQL much more flexible than SQL.

Mongodb Implementation:

• Data Model - this refers to the actual nuts-and-bolts schema of how data is structured in the code.
• Normalized Data Model - a data model where certain pieces of data in a database that refer to other pieces of data use cross-references, rather than copying and embedding the data directly.
• Embedded Data Model - a data model where any data that is cross-referenced is copied and embedded directly.

"You should consider embedding for performance reasons if you have a collection with a large number of small documents. If you can group these small documents by some logical relationship and you frequently retrieve the documents by this grouping, you might consider “rolling-up” the small documents into larger documents that contain an array of embedded documents." [1]

Nice guide to example data patterns. [2]

More on DB cross-references: [3]

Data

The AP data we're putting into the database depends on what type of packet is received. The type of packets we might receive from an AP that we would keep are:

• Beacon frames

The data available about an AP in a beacon frame is:

• BSSID
• Channel
• SSID
• Signal strength
• Encryption type

Thus, typical behavior for the Wifi Database program is as follows: Begin listening for packets. When a beacon packet is received, extract BSSID, channel, SSID, signal strength, and encryption information. Create a dictionary following the schema below; this will become the MongoDB document. Insert the MongoDB document into the collection.

{
  'bssid' : 'aa:bb:cc:dd:ee:ff:00:11',
  'channel' : 5,
  'ssid' : 'Nacho Wifi',
  'strength' : -20,
  'encryption' : 'WPA'
}

The data available for clients is:

• Client MAC
• Gateway/destination MAC
• Signal strength
• Channel
• Associated SSIDs

{
  'bssid' : 'aa:bb:cc:dd:ee:ff:00:11',
  'channel' : 5,
  'ssid' : 'Nacho Wifi',
  'strength' : -20,
  'encryption' : 'WPA'
}

Pymongo

More info on pymongo here: [4]

and notes here: Pymongo