Note: This page is under active development. Feel free to visit often for updates and to send comments & recommendations via our web contact form.
Overview / Purpose / Objectives / Audience
This document serves as a single-(web)page overview of a home lab construction together with practical recommendations for study, service deployment, hardware, software, etc. The lab should mimic a typical small/medium-sized office deployment for two primary reasons: (1) this is where equipment beings to support the basic network segmentation technologies needed for offices, labs, and security research; and, (2) we will deploy the typical services that we might be called upon to deploy, support, troubleshoot, and protect. From here, the foundation is set to investigate practical topics such as virtualization, service hosting, infrastructure redundancy, hybrid architectures (i.e., including “The Cloud”), software development (e.g., the typical dev, test, prod-type lifecycle), malware detection & analysis, and so forth. Wherever possible, our preference is to use Free & Open Source Software (FOSS), particularly to make investigations affordable for the student. Finally, this is a “living document,” to be updated periodically with new developments in technology, pricing, and so forth.
First & Second-Level Requirements
As a first objective, we will want to create separate home and guest wireless networks. The home network will hold the family laptops, the printer, and the baby photos; while the guest network, which only allows any attached device access to the internet–not even to each other–can be available for the Xbox, the Alexa, the Smart TV, your teenagers with a habit of visiting hackme.com, and even actual house guests. If you had no other objective than this basic separation, you could stop here — the improved performance over the devices on the shelves at Walmart and the improved security posture would be worth the effort. With this know-how, you’ll see quickly how to add others as necessary.
While not strictly required in our recommended build, we’re going to pretend it is: We’re going to need a server running to host a wireless controller. The wireless controller does the initial configuration of your wireless access point(s) to handle those two networks, keeps track of who’s coming and going, and it helps with keeping the firmware up to date. We’re going to want to put the controller and the access point(s) on a separate administrative network segment to isolate them from folks and devices on the home and guest networks .
We’re going to want to run our own email server, if for no other practical reason than to collect the different alerts and notices generated everywhere inside our network–for instance, by the wireless controller. And while also not strictly necessary, why not let that email server send and receive messages from the public internet as well? Running a mail server is a practical, educational, and fun rabbit hole to explore that will definitely require you to register a domain name so it can be found, likely require you to establish a cloud services account to set up a server with a fixed public IP address, handle public DNS recores–including some email-particular aspects, … Again, it’s optional but highly recommended.
As the network builds in complexity and additional servers and services are added, we’ll want to include centralized log collection (syslog) as well as a centralized monitoring service. The monitoring service gives us a dashboard to see what servers and services are up–generating alerts (emails, text messages, etc.) when something derails–while the centralized logging gives you a quick peak into what was going on everywhere at the time. We’ll also recommend standing up a version control system to track configurations across the different servers. In much the way software developers track changes to their applications, it is a convenient way to track and test changes to service configurations while also allowing you to roll-back to a last known good state if necessary.
It becomes quickly cost-prohibitive to stand-up new boxes for each new server that we’d like to run, especially for some low activity servers and other test servers that we’d like to spin up for experiments. To handle this, we’ll need to stand up one box as a a virtualization server. We can deploy that earlier wireless controller, log collection, monitoring services, and others here, and–if our email server is strictly internal–we may put that here as well. Running the servers virtualized allows such things as easy checkpointing via virtual machine snapshots: If an update or an experiment goes awry, it can be an easy matter simply to roll-back the entire server to the last known good state. Later, if service redundancy is a concern, additional virtualization servers can be put in place and fail-overs established.
It’s likely that we’re going to want to access our network securely while we’re out & about. For that, we’ll want to establish our own VPN services. With some planning, that basic access can be extended, for instance, to make it appear that you are browsing from home while on public wifi somewhere, or make it appear that you are browsing from a cloud server somewhere else while you are home.
As the number of servers increases, we will want to consider centralized Identity Management (IdM) or, Authentication, Authorization, and Audit (AAA) services. Generally speaking, all network gear above what you might pick up at Walmart and all servers can be configured to use some type of centralized identity management for determining who’s allowed to login with what privileges. That, for instance, allows you a single place to change your password and have it applied to all of your servers and devices right through more sophisticated capabilities such as single sign-on (SSO). As a bonus, it even enables things such as individual logins to your home wifi. If you intend to develop software services, identity management may provide the foundation for the service logins and access controls.
If you’re particularly hard-core, you’re interested in supporting office environments, or you’re simply tech-curious, we’ll recommend you establish in-house VoIP telephony services as well. Give yourself and your family members individual lines and extensions for a dollar or two a month, establishing a private voice (& video, if you like) network behind the scenes. Host conference calls and schedule wake-up calls. Set up the “Press 1 to speak to the Service Department”-type menus. Undoubtedly your eyes will be opened the the world of telephone security, seeing just what is possible in a commercial environment. It may even give you some insight into how different telemarketing, collection, scam, and other call centers operate.
Finally, if you’re the type to jump the proverbial shark while sipping your morning coffee, you might consider adding sensors and actuators to your network. We’ve been known to deploy Raspbery Pi’s & Arduinos to environments with heat & humidity sensors to monitor closets, motion detectors & cameras for security, and we’ll monitor for trouble with flashing LEDs. Eventually you may want to control them all and monitor everything through your own web server & custom applications, maybe even adding custom voice controls (e.g., Alexa Skills).
The lab is your oyster… but we’ll start with the assumption that we have an internet connection at the wall available through the loose end of a CAT5 or CAT6 ethernet cable and that you’ll have some angry family members if they can’t hit Netflix, YouTube, or Facebook for too long. 🙂