Recording the Horrors of the Defcon Network

Everyone in the security field has heard the horror stories of the Defcon network, this year I want to record some of them.

Part I: In Which Preparations are Made.

My goal is to bring a reasonably hardened computer to Defcon, put it on the convention network, and pretty much just leave there. Not wanting to spend money on a NUC or schlep around a larger machine, I’ve chosen a Raspberry Pi 3 b+and a small TFT screen to stream logs on, both readily available on amazon prime.

The machine will run with SSH enable and accessible.

Initial hardening steps taken:

• Changing the default password
• Disabling password based logins for SSH
• Set up IP Tables to block all traffic except 22 and log all denies

Monitoring steps taken:

• Set up openvpn to securely ship data offsite
• Set up graylog to receive and dashboard data
• Set up rsyslog on the raspberry pi to forward all logs to graylog

Part II: In Which Defcon is Attended

Friday August 10th the raspberry pi is placed on the DefCon-Opennetwork, it gets an ip address, connects to openvpn, and begins to phone home all of its logs. The device did not light on fire.

Saturday August 11th the raspberry pi goes online a second time, after a brief issue requiring that a keyboard be plugged in, its back online and reporting. For a second time the device remains not on fire.

Part III: In Which Logs are Analyzed

Upon returning from the sands of Arrakis, I checked graylog to see what had been recorded.

First stop, check the dashboard to see the amount of failed SSH logins, surely there would be many. To my utter surprise there were none, only the test cases I had logged to verify it was recording. Maybe there were dropped packets or something, openvpn was running on udp.

Second stop, check the firewall deny logs. Here there is a large number of lines, things are looking interesting. Unfortunately I did not setup an extractor to parse firewall denies.

With both of these issues it was time to give up on graylog and go on box to look at the raw logs. First, check /var/log/auth.logto validate that there really were no attempted ssh connections

grep sshd /var/log/auth.log
Aug 11 02:46:56 raspberrypi sshd[501]: Server listening on 0.0.0.0 port 22.
Aug 11 02:46:56 raspberrypi sshd[501]: Server listening on :: port 22.
Aug 12 02:17:23 raspberrypi sshd[463]: Server listening on 0.0.0.0 port 22.
Aug 12 02:17:23 raspberrypi sshd[463]: Server listening on :: port 22.
Aug 14 02:37:34 raspberrypi sshd[1013]: Accepted publickey for pi from 10.0.0.124 port 38886 ssh2: ED25519 SHA256:wXctM00fGjjCDERWO8jMnabjD9SY+MpLkzOYod3R8T0

Checking /var/log/syslog.2 at first seems very promising, the file is 2.8G on disk and running grep "iptables denied" syslog.2 | wc -l gives 539 hits. Digging deeper this becomes much less interesting on Aug 11 almost all of the lines were

Aug 11 00:03:05 raspberrypi kernel: [12680.639869] iptables denied: IN=wlan0 OUT= MAC= SRC=10.65.249.208 DST=224.0.0.251 LEN=241 TOS=0x00 PREC=0x00 TTL=255 ID=54954 DF PROTO=UDP SPT=5353 DPT=5353 LEN=221

with a single line

Aug 11 18:31:40 raspberrypi kernel: [ 7582.225296] iptables denied: IN=wlan0 OUT= MAC=b8:27:eb:71:01:57:a0:36:9f:31:f8:14:08:00 SRC=XXX.XXX.XXX.XXX DST=10.65.249.208 LEN=65 TOS=0x00 PREC=0x00 TTL=49 ID=63679 DF PROTO=UDP SPT=1194 DPT=42071 LEN=45

So Aug 11 was nothing but firewall hits for mdns to multicast and one packet from my openvpn server back to the raspberry pi. Aug 12 was even more disappointing, only mdns hits.

Based on what I saw in these logs, NO ONE TRIED TO DO ANYTHING TO THIS RASPBERRY PI.

Part IV: In Which Testing Methodology is Reviewed

From what the logs have shown on this device, nothing happened while on DefCon-Open. One thing to note before concluding that the Defcon network is totally safe. I did not have any form of packet capture running the,complete picture of what happened is not available. It is surprising that there were no port scans or ssh attempts the entire time.