Post #BruCON Network Analyzis

BruCON is over! As usual, when I attended a security conference, I’m trying to write a small wrap-up for me followers. With BruCON, it’s completely different: I’m on the other side of the stage. For the “0x03” edition, I was again involved in the “bits & bytes” stuff. I did not attended talks always between two requests or small problems to solve… and I like this!

So, building a network for a security/hackers conference is a great challenge. You have to provide a (as much as possible) free Internet access but, for legal reasons, you have to keep an eye (even both!) on the visitors behavior. To achieve this, we kept a trace of all network flows generated during the conference. For privacy reason, we do not keep the payloads, just the IP headers (source IP/port & destination IP/port with timestamps). The audience of a security conference are normally good skilled people regarding security. I analyzed the data captured during the two days (Monday 19th and Tuesday 20th). Here are some facts…

First, a few words about our setup. We provided three different networks: A public Wi-Fi available to all the visitors, a private Wi-Fi dedicated to the crew, speakers and “VIP’s” and a wired network for trainings, workshops, the crew. Our Internet pipe (1Gbits) was provided by Belnet, the Belgian national research network with IPv4 as well as IPv6. The traffic was captured and analyzed in real time by a network sniffer which provided interesting statistics:

The “Internet traffic” is the traffic exchanged between the different networks. The “Incoming traffic” represents the traffic from the Internet (the users downloads) and the “Outgoing traffic” represents the traffic sent to the Internet. The peaks are the tests performed by our video team with higher quality streaming.

What about the flows between hosts and the Internet? The following maps represents the traffic exchanged on Monday and Tuesday.

Were our visitors aware of their own security? For the second time, we run a wall of sheep during the conference. We sniffed the public Wi-Fi network (and only this one!) for interesting traffic. Again and again, some people still use unsafe protocols! A visitor sent thousands of SNMP requests over the network during the event. I suppose this guy was using a corporate laptop with a running network tool in the background. Note that the traffic capture was executed live and no data was saved nor divulged outside of the BruCON network team.

Here are the top detected protocols:

The web traffic was also analyzed. The traffic sent over the well-known ports (80, 8000, 8080, 3128, 443)  was inspected to extract URLs. Here again, only the URLs were extracted, the HTTP content was not inspected nor stored.

Here is the top-30 of the most visited sites:

The top URL (pwn3d.be) was in fact the wall of sheep. I saw lot of people keeping an eye on this page. The IP address was an address from the DHCP pool used by visitors. Otherwise, nothing fancy, the classic websites remains the same. Interesting to see how many people are using Dropbox!

But, it is sometimes interesting to search for the most obscure URLs (read: accessed only one time) or what occurs below the radar. Funny: did a visitor make some only shopping (c-and-a.com) during the conference? 😉

Of course, we installed an IDS to capture suspicious traffic. The top detected events follow:

Did we face security incidents? For sure, I detected classic stuff:

• Rogue access points (broadcasting the “brucon” SSID)
• Port scans
• Gateway ARP spoofing

A few words about IPv6? We offered IPv6 via router advertisements. 10% of the visitors accepted the RA and got an IPv6. As the BruCON website is running on IPv6, it was the preferred protocol during the event:

To conclude, some tips if you are to deploy a network during a security conference in a “wild environment“:

• Internet is mandatory. Your visitors expect to have a powerful and reliable Internet access. Be prepared to the worst! Our DNS/DHCP crashed in the middle of the conference! Have backup plans and alternative solutions!
• Do not offer open Wi-Fi. Protect it via a WPA(2) key. The goal is not to avoid people to use it. The goal is to prove your “due care” in case of problems.
• In the same way, capture the traffic (via netflow, tcpdump or any other tool) to keep a trace of who did what and when. Don’t store the packets payload for privacy and performance (storage requirements) reasons.
• Keep an eye on your network, all the time. It’s like leaving hot milk on the fire.
• Try to keep control of all the infrastructure from A to Z. Ex: have access on a core router will help you to quickly implement basic access-lists to drop offensive users or protocols.
• Be reachable: broadcast a phone number and/or e-mail address where people could report suspicious activities.
• After the conference, burn a DVD with all your evidences (with SHA1/MD5 hashes).