Rolling My Own Router

[Quantum`]

I want complete control over my wifi router so I'm looking at building my own. I know there's OpenWRT for embedded equipment, but I want the best radio possible, and I'm sick of all these vulns.

I've looked around, and it seems I'm doing New Science. What I have in mind is creating a Xen VM to serve as my router, running OpenWRT or OpenElec. (or why not CentOS Minimal? Yeah, that's what I'll use) It will have the Asus PCE-AC66 hardware passed through to the VM, as well as the ethernet NIC. It will run a firewall, like Shorewall, and maybe Suricata & Snorby to monitor network traffic. WAN will connect to one ethernet port, and the other ethernet port connects to a Netgear GS108P, for my other LAN devices and PoE for security cameras.

Has anyone done this, or even heard of this? Would OpenElec or OpenWRT or CentOS be better suited? Also not sure how much tuning under-the-hood would be required. And don't know if it would be possible to use one ethernet port for both WAN and LAN, but segregated in some highly-secure partitioned way.

 

[sfx2000]

Look here first - we've collectively chatted about things...

CentOS - probably not a good path to go down - been there.. done that, got all the cool tshirts - I use RHEL in the enterprise/carrier space, but when getting in the kernel and development there, I do appreciate how Debian does things, so maybe consider Debian 8 "Jessie" as a baseline - it's a little bit closer to the tip of the cutting edge, but still stable..

For routing daemons, consider Quagga and BIRD - these'll get you pretty much there...

The challenge at the moment is WiFi chipsets that;

a) have good HostAPD support
b) good drivers for newer kernels - e.g. 3.11 and later - 3.10 brought in some major changes there...

Without an NDA, it's going to be a challenge to find suitable drivers for any 11ac chipset, just saying...

x86_64 is perhaps a good way forward when rolling one's own IMHO - true there are some good ARM cores out there, but considering toolchains and self-hosting for builds, x86 is the way to go...

Why debian 8 - two words - systemd and docker - these are the future - I know a lot of folks have philosphical issues with systemd, but at the same time, it's very easy to build and set up multiple jails with busybox, and they're all pretty small footprint - and they can all talk to each other at RAM speed across virtual interfaces..

KVM and QEMU - another choice, just remember that there are a price to pay for KVM/QEMU - and that is memory - but that can be well spent as each guest is a full blown host... but in a small memory footprint, it's better to look at chroot jails instead...

 

[Quantum`]

Interesting, thanks.

I'll check into drivers for the Asus. Likely I'll use Shorewall to masquerade wlan through to the WAN, filtering as it goes -- quick and fast performance. Only thing I don't know is how to securely partition the WAN and LAN on the same NIC, if that's even possible. It's a cinch that the NIC has to be for the WAN, but I have LAN devices that aren't wireless without extra expense. Maybe I'll just have to get ethernet-to-wifi for them.

I'd run Debian Testing exclusively at home for 22 years and finally gave up on it at v8 because Debian is just getting too creaky. No true innovation for years, and things break too often. CentOS has been a relief WRT reliability; I use my OS' pretty rigorously. And actually I'd written a blog article about getting systemd running in Debian over a year ago before most were aware of systemd and when it was quite busted on Debian. I like systemd alot.

As to Docker and KVM, these are not secure. This is why I run Xen, as it is a microkernel-based architecture. I know Docker and KVM are popular and all, and Xen has a learning-curve, but I go with the best tech no matter what. Debian's Xen packages are a trainwreck and will not work unless you actually compile all of Xen instead. That was the final straw for me and Debian. Now I discover that the fglrx driver will not run on anything except Ubongo, at least for OpenCL functions, so I have to have a special Xen VM for that. Thanks AMD... :[

 

[sfx2000]

As to Docker and KVM, these are not secure. This is why I run Xen, as it is a microkernel-based architecture. I know Docker and KVM are popular and all, and Xen has a learning-curve, but I go with the best tech no matter what. Debian's Xen packages are a trainwreck and will not work unless you actually compile all of Xen instead. That was the final straw for me and Debian. Now I discover that the fglrx driver will not run on anything except Ubongo, at least for OpenCL functions, so I have to have a special Xen VM for that. Thanks AMD... :[

How is KVM/Docker insecure? Perhaps with bad planning..

Xen is a RHAT initiative, and it's not bad... Xen is not a microkernel - it's a low level hypervisor, and it runs on the linux kernel... it has certain advantages, but usability isn't one of them in a lightweight environment...

In any event, it's more that most folks can use here...

KVM/QEMU - a bit faster perhaps, and easier to use... security issues are mostly with the host...

Docker (and other containers) - really depends on the host environment - good news here is that we can patch either side, but like XEN/KVM, KVM more so, a reboot can be interesting...

jails/chroot - probably the best way in a small footprint environment, simplistic, and old school, but fast - and we still have appropriate separation of users/tasks/privileges - but again, anything can be a security issue I guess...

I've been doing jails for some time, they work, Docker is one level up - it's smart stuff...

sfx

 

[sfx2000]

Debian is just getting too creaky. No true innovation for years, and things break too often. CentOS has been a relief WRT reliability

I use RHEL in production, but I find in tiresome for development - Debian (and derivatives) is easier to work with - I think perhaps is more about APT vs. RPM, as userlands aren't that much different..

I run on both sides, and see advantage for both...

 

[Quantum`]

If you look around a bit you'll find all kinds of vulns in KVM and Docker, past and present, and they are not secure -- at least the way trained infosec people define it. Xen is not a RedHat initiative, it's a community initiative, contributed to by Amazon, Citrix, and Rackspace.

And please. Xen is a microkernel architecture, which is the closest we can get, and vastly safer than KVM or Docker. There are no production-ready microkernel OS', seL4 and Minix notwithstanding.

I know that chroot jails work, but they can and have always been broken out of and are -not- secure.

 

[sfx2000]

in any case, it sounds like you know what you want

Everything has vulns, even Xen...

http://xenbits.xen.org/xsa/

sfx

 

[sfx2000]

And don't get me wrong - it's not that I'm anti-Xen - it has it's places... if one has the HW, and the time to climb the learning curve (which Quantum` has), then it's a perfectly workable solution...

In the hosting community it's huge - Got a Rackspace VPS? Yep, it's likely running on Xen..

Nice thing there is that one can run something above it, as proposed Centos7 minimal, and still run docker or jails or KVM - given enough memory, one can build task specific guests purpose built..

It's all good stuff...

 

[Quantum`]

Sure. But a list of vulns says nothing about their relative severity compared with Docker or KVM, nor the relative likelihood of compromise.

Yes I've figured out what I want now. This has not been a very useful conversation for me. Out.

 

[sfx2000]

Sure. But a list of vulns says nothing about their relative severity compared with Docker or KVM, nor the relative likelihood of compromise.

Yes I've figured out what I want now. This has not been a very useful conversation for me. Out.

Best of luck.. you asked questions, good questions, and you got a response - perhaps not the one you were looking for