About a month ago, I was presented with a unique network and security challenge. A friend of mine asked me to be part of a hackathon in the local area dubbed ETHDenver. Specifically, he was asking me to help support the network and security monitoring during the conference. My first question was: what is ETHDenver? If you’re involved in any cryptocurrency, you’ve probably heard of Ethereum. ETHDenver is a new event in the Denver Colorado area that brings together some of the foremost blockchain researchers, entrepreneurs, businesses, artists and coders the world over. In some regards, it was a “choose-your-own-destiny” event. Some were there to just be part of the hackathon, where others were there to hear the various speakers. More on the hackathon in a few but suffice it to say is that our challenge was to setup, support, and monitor the network and security of that network for over 3000+ individuals over the course of 3 days. One of the biggest lessons learned for me, was that the blockchain has immense capability beyond just cryptocurrencies.
The Block Chain: Much More than Crypto Currencies
When I talk to people about the blockchain, Bitcoin is typically referenced and rightfully so. Bitcoin is the leading crypto currency that operates via a blockchain. There are more crypto currencies than you can shake a stick at and all promise some differentiating factor. At ETHDenver, the focus was on the Ethereum block chain. According to the Ethereum website, Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference. These apps run on a custom built blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of property. Blockgeeks provides a great background on the blockchain in simple terms if you’re looking for a more detailed explanation. Figure 2 illustrates what the distributed ledger looks like as compared to a centralized or decentralized model. Ethereum’s claim to fame is the smart contract and ETHDenver was all about how that contract can be used in innovative ways, other than just cryptocurrencies. That was what the event was all about and the focus of the hackathon.
As a security professional, the thought of a hackathon usually entails a weekend of caffeine, exploits, and the painful persistence of trying to compromise a target system. But hacking is so much more than just computer hacking, as you may already know. In the context of the event, this hackathon was about hacking code together to achieve your desired goal of leveraging the blockchain for a novel function. At the end of the weekend, seven winners were announced out of hundreds who participated. The seven winners all had varying uses for the blockchain. From a security and infrastructure perspective, the one that stood out to me was a project dubbed Canteen. It was touted as a decentralized container orchestrator. Possibly put another way: a peer-to-peer self-healing container network. If one node were to go down, the “stack” could be simply be rebuilt from a trusted peer in the blockchain, minimizing downtime. If only we had that for the internet connection…
Monitoring Challenges and Other Woes
With a large conference, and especially a tech conference, there will be issues. I think that might be a universal law somewhere. The first challenge was that of time. Little time was provided to get infrastructure and security monitoring in place. With about a two-week window to work in, Internet, wireless infrastructure and security monitoring were needed. Thankfully, the internet circuit was ordered and delivered prior to the event. The wireless Access Points (APs) of choice were Cisco Meraki. With 3000+ users, there were approximately 45 APs in use at the Denver infamous Sports Castle.
The other area that required attention was network security monitoring (NSM). Based on our time and options, we opted to use USM Anywhere, by AlienVault. If you’re unfamiliar with this platform, it is essentially a Cloud hosted version of the USM Appliance. The main UI is hosted and the sensors are deployed on site. This setup permitted NSM for the local network via the sensor and a centralized view into the traffic from virtually anywhere. We ended up setting up a SPAN port of the switch where all of the wireless traffic eventually traversed. That traffic was sent to the USM sensor. USM Anywhere permitted the monitoring of the network from other locations and not just from the physical conference location. All in all, the setup was a breeze and it took less than about an hour to get up and running (plus or minus a few minutes to download the on-site sensor). Figure 3 illustrates the USM UI dashboard.
Finally, the largest challenge that plagued day one was that of an Internet outage. It was eventually solved, but due to network congestion and faulty business class cable modems, we had our work cut-out for us. True to the distributed blockchain nature of the conference, we ended up having to further segment the networks, on the fly, via dedicated cable modems (as seen in figure 4).
It wouldn’t be complete if I didn’t mention that some of the alerts we received via USM was Ethereum traffic (figure 5).
Deception to Add Context
As an added area of research, I ended up deploying two instances of MazeRunner Community Edition. For my own edification, but also because in an untrusted network, it was an area to help with early detection of nefarious behavior. Essentially, this technology was deployed to various segments of the network and acted much like a high-interaction honeypot. The alerts from the system were directed to the USM sensor, which allowed for centralized monitoring. Aside from scanning, no one seemed to want to discover more about these systems—probably too focused on hacking some code together.
Observations and Conclusion
All that said, here are some of the takeaways and things to think about if you’re ever in a position where you need to provide similar services for a hackathon or other conference:
- Plan appropriately for bandwidth (both Internet and wireless). If 2.4 GHz is not needed, consider forcing clients to use 5GHz for quicker speeds.
- Have a back-up internet connection and especially if the conference is doing live streaming.
- Ensure your network can be monitored from a utilization and security perspective.
- Incident Response looks a lot different on an untrusted network. Knowing if something is up being a big priority (via NSM and possibly deception technology). Being able to ban or restrict an end user might be your only defense or containment option.
- Setting up secure remote access helps un-tether you from the physical conference location.
Overall, it was a great learning experience and one way to give you confidence in your abilities. From my perspective, it was also great to learn about new and emerging technology, but that’s what it’s all about, isn’t it?