Building Out A Prototyping And Promotion Methodology On Hardened, Localized SoCSs

I’m certain that as enthusiasts in technology, you have heard a lot about systems on a chip (Or SoCs). They are what power our smartphones, connect our homes (For instance, the NEST thermostat uses a SoC), and help operate our vehicles.

So it’s no surprise that Raspberry Pis (And their kin, such as the ODRoid C1) are fantastic devices. For an incredibly small up-front amount you get what amounts to a bit less than an AWS T2 micro instance (In terms of raw compute- for now anyways) for substantially less cost annual cost[1]. They’re also great for prototyping- trying out ideas in a smaller space and refining the process before moving into a larger environment.

Having a physical prototype structure such as this allows for a few things:

  1. Greater transparency of systems architecture – instead of yelling at the people who do provisioning, if you need another box you get another pi stood up.
  2. Visibility of failure points – Building a rad new webapp that routes through some tomcat-based reverse proxy? You have literally all of the pieces in your prototyping space. There are no “black holes” to hinder initial development.
  3. Closed-circuit development – If there’s no external network connectivity into the prototype there’s minimal risk of IP getting into the wild before deployment.
  4. Reusability – The only thing keeping hardware from not being re-utilized is the SDXC card, which can be swapped out rapidly. New functionality is a power cycle away!
  5. Minimal footprint – Entire clusters can be built for less than most development laptops.

And of course, there are some issues with this prototyping methodology:

  1. ARM architecture – Pis are ARM, and modern server infrastructure is most decidedly not on ARM. This means writing native code and expecting it to work elsewhere is a no-go.
  2. FAT Format – SDXC relies on FAT (exFAT, FAT32). No ZFS for you, hope you weren’t developing around that.
  3. Roll your own – You have to have an understanding of every piece of network gear or application you run. External expertise is minimal in closed-system prototyping.
  4. CapEx versus OpEx – By taking this route you effectively shift non-productive environments to being a capital expense. While you might not care, your accountants might.
  5. Scale and availability – It’s easy to get a hold of a few dozen pis for a couple developers at a small development group. A couple thousand, with accouterments? Well…
  6. Minimal footprint – Got your project on a Raspberry Pi cluster, spread across their SDXC cards and not backed up anywhere? Well, if it walks off you’re back at square one. Asset management becomes an issue. A big issue.

So far I’ve found this home-prototyping approach to be extremely handy. However, let’s say you want your prototype work to be available on the road- meaning you need to make it available to the internet. So what about attackers to this prototype, ready and willing to explore, exploit, and potentially steal what you’re working on right off of the drive?

Well, this is where hardening efforts come in- and given that linux runs quite well on the Raspberry Pi, this makes it possible to construct a hardened environment. In future articles I hope to detail steps to help lock down the “Default” Raspberry Pi environment (Raspbian) as well as offer some general use cases for the Raspberry Pi in a SOHO/Medium-size business.