Technology

Previously I had written a guide to using a Banana Pi BPI-R1 as a router. As I write this, I’ve been running the BPI-R1 as my home gateway/firewall for approximately nine months. Initially I had problems with the router freezing and needing to be power-cycled every few weeks. Although this is somewhat commonplace and accepted on consumer commodity routers, it shouldn’t be necessary on a piece of hardware designed for hobbyists. Furthermore, there were other stability and hardware issues that could cause the BPI-R1 to reboot as a switch, with public IPs being assigned to internal machines. This effectively disabled the firewall, leaving internal machines in a potentially vulnerable state.

For some reason, dmesg -w doesn’t continue to follow kernel log messages on Bananian. Eventually I bought a monitor that had HDMI inputs, so I could look at the console following one of these freeze-ups.

I suspected that I may have had a faulty sdcard, causing the router to crash. I also noticed the crashers would occur when pulling large amounts of data over Wi-Fi (i.e. when running a large rsync operation). I replaced the sdcard with a new one, and the crashes did stop. However, the Wi-Fi occasionally stoped responding as an access point. At least now, it no longer takes the rest of the BPI-R1 down with it. I’ve attempted restarting hostapd to fix the Wi-Fi issues, but only a full reboot seems to get it back into a functional state.

One thing that bothered me is that if the BPI-R1 reboots and is unable to load its operating system, its default role is to become a simple switch between every Ethernet port, including the WAN port (they all share the same Ethernet controller and are only separated by VLAN configuration, remember?). This led to my internal machines occasionally getting real, public IP addresses.

This is a pretty big security issue, as now I have internal machines that are unintentionally exposed to the world, because the gigabit Ethernet is shared between all the ports. Wi-Fi devices aren’t affected as they depend on the software bridge which requires a running OS. There isn’t really a fix for this situation from the operating system perspective. The BPI-R1 should simply disable the Ethernet switch if it fails to load an operating system, or require that it be enabled specifically by the operating system after it boots.

I’m currently looking at other solutions to replace my BPI-R1. As it stands, the BPI-R1 is unreliable, and shares physical Ethernet between WAN/LAN ports instead of using dedicated controllers. Its Wi-Fi adapter is not trivial to replace, as it’s soldered onto the board and connected to the USB bus.

Most home routers are terribly insecure to begin with. Many don’t auto-update, or accept unsigned updates, making them a large attack vector for hackers. Even newer devices released this year by major manufactures are still filled with crazy amounts of security holes¹. There is no shortage of attack vectors for this new Internet of Things, as it’s been labeled. Still, I’m curious how many commodity home routers have shared Ethernet between their WAN/LAN ports. What percentage of these home firewalls would reboot as a switch if they failed to load their operating systems? Could this be yet another easily exploitable and difficult to patch attack vector against commodity embedded hardware?