Post #BruCON Network Analyzis

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

Internal Traffic

Incoming Traffic

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

Network Mapping 2011/09/19
(Click to view in full size)
Network Mapping 2011/09/20
(Click to view in full size)

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:

Protocol Detected Occurrences
SMB 4894
IMAP 1159
HTTP 481
FTP 340
POP 63

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:

URLs Detected Occurrences 2751 2624 2392 2137 1761 1546 1331 1546 1065 882 791 729 710 681 679 662 660 623 613 598 586 553 515 506 495 472 465 465 461 454

The top URL ( 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 ( during the conference? 😉


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

Signatures Occurrences
MS-SQL probe response overflow attempt 9162
POLICY access 2343
DNS SPOOF query response with TTL of 1 min. and no authority 875
MISC MS Terminal Server no encryption session initiation attempt 288
MISC MS Terminal server request 150
NETBIOS SMB-DS repeated logon failure 103
MS-SQL version overflow attempt 48
RPC portmap status request UDP 30
NETBIOS DCERPC ISystemActivator path overflow attempt little endian 18
WEB-CLIENT PNG large image height download attempt 10
ATTACK-RESPONSES id check returned root 6
MISC AFS access 6
MS-SQL ping attempt 6
WEB-CLIENT Windows Media Player directory traversal via Content-Disposition attempt 6
INFO Connection Closed MSG from Port 80 4
WEB-CLIENT PNG large colour depth download attempt 2
MISC Source Port 20 to <1024 1

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:

BruCON IPv6 Traffic
(Click to view in full size)

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


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.