How to Make Your Own NSA Bulk Surveillance System | Hacker News Reader

How to Make Your Own NSA Bulk Surveillance System

wired.com

63 pointslisper9 comments

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.

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.

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

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.

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.

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.

I believe the article was suggesting foreign intelligence agents could set up an ad-hoc surveillance network this way. It would be much more difficult for them to gain a position directly between the stores and the Internet.

> "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).

>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.

Reply on news.ycombinator.com