
How to Make Your Own NSA Bulk Surveillance System - lisper
http://www.wired.com/2016/01/how-to-make-your-own-nsa-bulk-surveillance-system/
======
nickpsecurity
Good point. Another way of looking at it is how the cost of surveillance goes
down all the time. Collection and storage particularly. This is one of reasons
NSA and private companies are doing so much of it. Yet, people fail to make
the connection that this means _anyone_ can do more of it. Including
adversaries.

Getting specific numbers would reinforce this if they allowed for disposable
surveillance. I'd love to see what one could do with custom devices, SOC's
designed specifically for this with flash storage, or little VIA Artigo-style
PC's that have that plus a HD. I wonder what the real cost is for (a) just
metadata collection on a fully utilized store or branch office plus (b) full
data collection on one.

------
dawnbreez
Hm. I wonder how hard it would be to make a drone that lands on the roof of a
Starbucks, automatically connects to the wifi, then autonomously runs airpwn?

The tricky bit would be power; solar panels are too bulky, wind power too
intermittent.

~~~
justinclift
Maybe have it be battery powered, and fly "home" for a recharge during the
hours the store is closed?

~~~
dawnbreez
Possibly. It'd have to be a huge battery, though.

New idea: Solar panels in a pyramid arrangement with a roll-cage to ensure
that they land faceup. Throw on roof, leave. Let it autoconnect to Starbucks'
wifi, then airpwn away.

------
trimtab
If every DC Starbucks is serving WiFi via a single network vendor like AT&T
etc. then the surveillance is already in place. Particularly, if only metadata
is being collected.

A specialized device is not really needed. Just a Mitm position between the
stores and the Internet.

~~~
efes
You need access to LANs themselves to get ethernet addresses which would
easily map to people on many devices. De-anonymizing based on traffic in a
cafe is going to be a bit more complicated than average for some users and the
random passerby who accidentally connects.

Besides, how can I be sure the people I am tracking actually work for the NSA?
I refuse to do blanket tracking just to catch a few criminals, that is
unethical.

------
unknownknowns
> "When national security programs are hobby-level, you really have to worry
> that anybody else can do them."

It's not really surprising that bulk surveillance is simple, in my opinion.
The act of collection/surveillance itself isn't the hard part. It's doing it
on a much larger scale.

Wardriving a Starbucks as a hobby is slightly different than installing a
specialized device into every downtown DC Starbucks, even if functionally both
do the same thing (collect data and/or injection).

~~~
gonzo
>It's not really surprising that bulk surveillance is simple, in my opinion.
The act of collection/surveillance itself isn't the hard part. It's doing it
on a much larger scale.

Sampled netflow at 100k connections/sec is straight-forward. You won't do it
with BPF, but it's straight-forward with technologies like netmap or DPDK.

Using "the web" as an example TCP session requires a 3 phase handshake (SYN ->
SYN ACK -> ACK), then the client can make a request (GET / HTTP/1.0) followed
by the response.

The SYN/SYN+ACK/ACK packets are 40 byte each (IP + TCP headers), plus another
18 bytes (DST, SRC, length, CRC), plus another 20 bytes of 'overhead'
(preamble, SFD, IPC).

Unfortunately, minimum payload on Ethernet is 46 bytes ('octets'), so the
actual on-the wire SYN/SYN+ACK/ACK exchange is 84 bytes each (includes all
overhead). Even 1G Ethernet has bandwidth sufficient for 1.488 million packets
per second at this size.

Even if all the frames on a 1Gbps link are 1538 bytes (includes all overhead),
you still have to deal with 81,274 packets per second.

The HTTP GET request is likely between 100 and 1500 bytes (depends on
headers), and, if we figure that the response fits in a 1500 byte frame, (1460
bytes of actual content, plus headers and overhead), we then have a 4 phase
close (FIN/ACK from each side). These, again are minimum 84 bytes on the wire.

So the reality is that given a web server that doesn't spend too much time
sending actual data (maybe several packets for the page data), it's easy to
get to 100K connections per second.

However, 100K connections / sec (remember that's _sampled_ ) is 8.640 billion
connections per day, and now you have a classic "big data" problem.

