Public | Automated Build

Last pushed: 7 months ago
Short Description
Build feed data for SITCH sensor (Mk3)
Full Description

Sitch feed builder

Another stab at verifying the GSM network around us

Given that cell phone companies are perfectly entitled to mess with their own
internal addressing, things like LAC and CID should be expected to change.

Without a relationship with each provider, it is nearly impossible to ascertain
the legitimacy of a BTS without programmatic access to each provider's asset
management system, in one way or another. The OpenCellID project is compiled
from observations, not from an asset system; simply that it has been observed
before is not a great criteria for ascertaining that a BTS is trustworthy. It
may just be persistent, and bad.

This approach is a little bit different. We start with FCC records and
licensed frequencies. From that we derive what ARFCNs we should see, as well
as the operators (allowed HNI, or MCC-MNC) that should be operating on those
licensed ARFCNs. While this is a little looser, it does give us a clear picture
of where cell towers are licensed to operate and the frequencies they are
allowed to transmit on. So we do a match based on geolocation and ARFCN, then
compare the HNI to the licensee to determine whether or not a BTS is evil.

This is intended to support the SITCH sensor Mk III.

What it does

This tool runs in a Docker container and requires the following environment
variables to be passed in:

Variable Name Purpose
TWILIO_SID Twilio SID, for API access
TWILIO_TOKEN Twilio token, for API access

You should also mount your web root directory into the container's filesystem
at /var/production/. This will ensure that when the container dies, it
will leave behind your feed files to be served by your web server. Make sure
you remove the container after it's run, or you kick the job off with --rm in
the arguments for docker run. If not, you'll quickly subscribe the disk
in your instance running the Docker engine. This takes quite a while to run.
See below for details.

You can run the feed builder process after checking out this repo by doing
something like the following (change /opt/shared/feed to some Docker-writable
output directory on your machine):

docker build --pull -t feed_builder .
docker run -it --rm \
   -v /opt/shared/feed:/var/ \

While the Docker image itself is a humble <64MB, the running container
can use beyond 12.5GB of disk storage and nearly 2GB of RAM as it creates the
feed files. It seems less than ideal, but without this process the individual
download size of the intel feed would be multiple gigabytes per sensor, per
feed refresh. This is an unfortunate but necessary evil. The feed data will be
dropped at /opt/shared/feed/production.

Docker Pull Command
Source Repository