I am setting out to build a router from scratch, and document the journey in such a way that anybody can follow along. But it’s not interesting enough to build a guide on IP Tables and a couple Network Cards, (albeit in this part we won’t get far beyond that). I will work to satisfy my demands for a simple system using only the most trusted software packages that grants ultimate control (see “Goals” below) to a very paranoid home network owner.
I’m growing disappointed with the high cost, bland flexibility and stability of consumer network equipment. At the same time I’m growing wary of the increasing number of network-connected devices that are accumulating in my home. Botnets are growing in numbers and strength. Meanwhile our risk increases at a magnitude of average vulnerabilities per software package times average packages on a device times the number of devices on our home network! You should take a perimeter walk around your home and see who’s connected, or if your router has a listing of DHCP clients, see how that list has grown beyond your expectations. If you forgot to disable UPnP on your router, go take a look at how many things took it upon themselves to open up inward access from the Internet. Do you know why they’ve done this? How much do you trust those devices? Do you even recognize all of them? Do you have anything on your network that could be accessed without authentication (network-attached storage, printers, chromecast, security cameras)?
If you think I’m a paranoid lunatic, then you simply haven’t been following the news.
At the risk of dating this article into obsolescence, the references I’m linking above are all extremely recent to this writing, and to be honest quite cursory. Anybody who follows tech news is fatigued by the nonstop onslaught of terrible mistakes.
This project isn’t going to solve those problems, but it will empower you to discover them with statistics & reporting, and shelter yourself at least while in your own home (assuming your phone is actually willing to stop routing traffic over the cellular network while on your WiFi).
Earlier in the section I mentioned the cost of equipment. A functionally good router is going to be a couple hundred dollars. Some people might think that’s a lot, and some might not. But we also need to look at the hidden costs of these devices.
I have a TP-Link Archer C7 which actually has some pretty nice features and flexibility. Way cooler than anything I’ve ever had before, except for customized WRT firmwares, which brings me to my next point! The importance of your firewall should not be overlooked. Being able to run firewall software on commodity hardware is (in my opinion) way more sustainable. When you buy any device, you’re actually buying a computer–and let’s be honest you’re buying a really crappy computer. We’re talking weak CPUs, very little RAM, and you can’t update software packages without replacing the entire system by flashing firmware.
If you think you own a machine that has no bugs you are wrong. They may not yet be discovered, but they are present. Meanwhile, corporations want to operate on their scheduled pace. If a flaw shows up in some library they depend on, you will not receive that patch until they get around to analyzing it, implementing it, building it, testing it and finally putting it to distribution. All of that comes after other business priorities. You also have to be curious about which hardware models the business prioritizes, which takes me to one more question–how old is your router anyway? You may never even be afforded the updates you need to keep your bank accounts safe.
In all fairness…
Non-commodity hardware is designed to do its very specific function, and to not be error prone. Sure, you can misconfigure it or lose your password and get locked out or brick your unit altogether. You can also go several years without upgrading your firmware and ultimately be assimilated into a botnet (or several).
Notes on surveillance
Yes everybody hates being under constant surveillance… and yet surveillance grows. At the same time we are filling our homes with devices that are at least as capable as mischievous gnomes. The aim of this project is gaining insight into what your machines are doing to the Internet on your behalf–or what the Internet is doing to you through your machines. If you’re a sketch ball and worried about the data you collect being compromised or coerced from you, remember you have the power to configure your own retention policy.
Something like a decade ago I acquired too many roommates and and started having performance problems with an already aging linksys WRT. I solved the problem by taking an incredibly more aging HP pavilion and set it up as my router gateway and firewall. It was one of those goofy looking micro towers, but with a 50-watt power supply it seemed like a good choice for a computer that would be always on unattended. I don’t remember a lot of details of that machine’s set up, but primarily it was barebones, with fail2ban and shorewall running on Debian (probably Debian 3.1).
Goals & Requirements
Keep in mind that these are the goals for this entire series project. Especially with regards to features, we will not solve everything in this Part 1.
- Depend on only trusted packages available in and supported by official Linux distributions.
- Depend on as few packages as possible.
- Any assets developed for this project must be easily understood, and the distribution of them must be trustworthy.
- Management and configuration of the solution must be easy to operate.
- Management of various separated network zones
- Ex. Network equipment, Personal Computers, Cameras, Misc IOT, Guest networks, Sandbox & Lab networks etc.
- Collection and reporting of usage statistics–Dare I say surveillance?
- TCP connection setups, durations, peers involved
- UDP packet incidents
- Hackability (As in customization, not vulnerable)
- User-defined triggers
- User-defined blocking triggers
- See below for “Identify the nature of outbound traffic”
Concepts and Applications
If this project doesn’t produce a hackable customizable platform for truly owning your own network traffic, then it just isn’t worth doing (simple router solutions are already available). Let’s describe some potential applications.
Origin management reporting
Collecting stats and building data sets and graphics that can be queried and filtered to expose who’s communicating through your network. Leverage DNS queries to further identify peers and who owns them.
Aggressive outbound peer identification
Be able to enable a system of triggers that will disallow outbound connections to any IP address unless there was a recent DNS query seen associated with that address.
Origin blocking, ad blocking, or aggressive white listing
Use the firewall to keep AdBlock and uBlockOrigin extensions absolutely idle.
Conditional packet capture
If a traffic pattern is observed matching a particular set of conditions, begin recording it.
Before We Begin
I’m going to make some things clear. I am not a security expert! Not even close. If you choose to roll out your own system based on the information detailed here, you do so at your own risk.
This project is not even close to my main focus, I pull it off the back burner when the following conditions are met: (1) I’m not at my full-time job. (2) I’m not doing household responsibilities. (3) I’m not enjoying the company of friends. (4) I’m not indulging in media. (5) I’m not tired. (6) I feel like working on this now. This is a rare cross section of circumstances. I expect severe consequences of this.
If you see me doing something dumb, please tell me. I plan to revise this series as needed in order to harden the design, but not to keep it up with cutting edge technology. If the technological landscape changes and I’m still interested, I would probably write a different edition of the series for that technology. I’m also considering doing an edition for FreeBSD (with which I have no meaningful experience).
Expect revisions to this section until the series matures.
Part 1: Philosophy
You are here. Explain the design goals and problem domain.
Part 2: Essential Functionality
We lay the ground work for building this firewall platform. This remedial yet necessary process gets a machine up and running and able to route packets as a rudimentary gateway & firewall. It will show how to describe separate network zones using several network interfaces and ip tables. It will lay the foundation for the rest of our platform.
Part 3: Telemetry, Reporting, Observing
We figure out how to identify meaningful network events, and emit stats. Stats can be shunted to some data-back end or processor. We look some existing industry solutions to retain, query and present stats. We look at techniques to discover odd traffic patterns, like a significant influx of traffic at a time when people should be sleeping or at work, or outliers like that one camera who just started going nuts.
Part 4: Triggering
We figure out how to get in the way of traffic matching a particular rule. Once in the way, we can do whatever analysis is necessary and decide whether that traffic should be allowed to flow (or translated).
Part 5: Distribution
We go through the pain of taking our efforts and producing distributable packages that can easily be deployed and managed.
Part 0: Development Journal
Not exactly part of the series everyone will want to read, this article will be a heavily edited log of trials and tribulations throughout the development of this series. It is meant to help me verify that I’m documenting everything in a complete fashion and in an appropriate chronological order.