Router Security About This Site Website by     
Michael Horowitz 
Home | Site Index | Router Bugs | Security Checklist | Tests | Resources | Stats | About | Search |

I used to be like you. That is, I would buy a router, it would work fine and I would ignore it for years. As Nathan Kirsch wrote recently, "routers are the woeful wallflowers of computer components that are usually forsaken after the initial setup, only to be brought out for some violent shaking or tapping whenever the WiFi signals are unstable".

My first wake-up call came at the end of 2011 with the disclosure of the security flaw in the design of WPS. The router I was using at the time was so old, it pre-dated WPS, so I felt safe. But, router flaw after flaw seemed to be in the news and eventually one, having to do with HNAP, hit home. This, finally, sent me in search of a new, more secure router.

Since all consumers routers support WPS, I was into new territory, that is, the time had come to step up in class. But to what?

The only business class router that I had experience with was a Peplink Balance 20. It cost about $300 and didn't do WiFi. It's claim to fame was handling multiple concurrent Internet connections, load balancing and failing-over between them. But I had only a single ISP and wanted WiFi.

It turned out that Peplink had recently introduced a low-end router called the Pepwave Surf SOHO that did WiFi and sold for far less than the Balance 20. So, I tried it, liked it and have been a happy customer ever since. The funny thing is, Peplink doesn't focus on security at all. For example, for quite a while, the best WiFi encryption option on the Surf SOHO was a combination of WPA and WPA2, you could not opt for WPA2 exclusively (this has since changed). But, they don't support WPS and, unlike consumer routers, Peplink cares about their software.

Before I gave up on consumer routers, I would recommend Asus to people I knew. Then one day I tried to remotely administer an Asus router and was presented with an error message that made no sense. This was unacceptable. The router was in the home of a client and its failure reflected on me. Even ignoring security issues, for many of us, Internet access is important. We need the router to work flawlessly and this Asus was buggy.

An important lesson that I've learned is that when you buy a consumer router you are buying the hardware. When you buy a business class router, you are buying the software. Companies like Peplink sell the software capabilities of their routers, not the hardware. With consumer routers the goal is to provide the software as cheaply as possible. That's not good Defensive Computing. It's the software that either makes you secure or vulnerable.

If nothing else, I hope this site convinces you not to use a consumer router, and by the way, not to use hardware provided by your ISP. No need to listen to me, just take a look at the router bugs page and decide for yourself.

The configuration advice offered here is geared towards home routers. I have almost no experience configuring higher end devices from vendors like Sonicwall, Fortinet, WatchGuard, Sophos or Check Point. These devices do so much more than a home router that they fall into another category entirely - Unified Threat Management (UTM) and/or Next-Gen Firewall (NGFW) devices.

As noted on the home page, this site has no ads. It's a public service from me, Michael Horowitz. I am the sole author and developer.

I started this site at the end of January 2015 and it is still incomplete. I update it as time allows. Its like a hobby.

The site grew out of a talk I gave on Securing a Home Router in July 2014 at the HOPE (Hackers on Planet Earth) conference. A PDF of the slides is available. Thanks to 2600, audio of the talk is also available. An article about the talk appeared in Toms Guide.

On July 29, 2017 this site became secure. All HTTPS all the time. Good-bye HTTP.


What might improve router security? No one can force programmers to create fewer bugs. No one can force router vendors to care more about security. But, the documentation can certainly be improved. Here are my suggestions.

  1. The documentation for a router should note any ports that are, by default, purposely left open. In a perfect world, there should be none on the WAN side. On the LAN side, there would typically be one or two for the web interface. Each port needs to say if it is open for TCP or UDP or both.
  2. A number of protocols are known to have security issues. Router vendors should be required to offer a GUI interface to disable these potentially vulnerable protocols. Among them: HNAP, UPnP, WPS, SNMP, NAT-PMP, SSH and Telnet.
  3. Router vendors have to do a better job of notifying their customers about updated firmware. For passive notification, each vendor should have a single, unchanging URL that lists all the available firmware versions for each of their routers. The list should include the release date and a description of changes. The URL should be simple and obvious. For example, For active notification, customers that register with the router manufacturer should always be emailed about the availability of new firmware. Both of these proposals should apply to routers that self-update their firmware.
  4. We can't expect router manufacturers to support their routers with bug fixes for ever. However, their policy should be a public thing so that potential customers can take it into consideration. Routers should have a sticker with the expiration date of software support for the firmware. It should also be on the outside of retail boxes. And, in case a company changes their policy, there needs to somewhere that anyone can learn the expiration date for software fixes for each router model. The public URL from the above suggestion would be a perfect place to document software expiration dates.
  5. Router firmware is not a single blob, it contains main different programs. Typically many of the included programs are never updated and, even new routers can contain some very old software. If router manufacturers want to be lazy, fine. But they should be required to externalize a full list of the software, and the version numbers, included in their firmware.
  6. Here is a sample of what this new documentation might look like.

Along the same lines, we have Internet connected devices should be sold with best before dates by Daniel Aleksandersen (May 2017) who argues:

Would you buy a $200 USD phone or a comparable $205 USD model if you knew the more expensive version would receive software and security updates longer than the cheaper option? ... Today, customers have no idea how to ascertain how long an internet connected product will receive critical updates ... Devices that connect to the internet ... should be sold with best before labels indicating how long customers will receive updates for the device, including firmware and any bundles software.

This page was last updated: July 29, 2017 11PM CT     
Created: June 5, 2015
Viewed 10,794 times since June 5, 2015
(13/day over 810 days)     
Website by Michael Horowitz      
Feedback: routers __at__ michaelhorowitz dot com  
Copyright 2015 - 2017