Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Friends don't let friends run stock firmware



MBR wrote:
> 5. WHAT ROUTERS CAN BE TRUSTED?
> 
>    ...I quickly learned that about
>    2 years ago, Cisco/Linksys had pushed out their Cloud Connect
>    firmware to all their routers without the router owners' permission,
>    and in order for the owner to continue using his own router, he had
>    no choice but to sign an agreement that allows Cisco to spy on his
>    Internet use...
> 
>    ASUS: The next router I've been considering is the ASUS RT-N66U.   
>    It sounds like ASUS was informed of a major security flaw in their
>    firmware, and chose to bury their head in the sand instead of fixing
>    the problem.
> 
>    Have any of you seen other router manufacturers trying to seize
>    control of the hardware, either like Cisco tried to do, or in some
>    other fashion?  If so, which manufacturers, and what have they done?

Well, there was the well publicized backdoor that appeared in several
router models. I mentioned it in this June BLU posting:
http://www.mail-archive.com/discuss%40blu.org/msg09068.html

I've been meaning to write up some notes from Jim Gettys talk I
mentioned here also in June:
http://www.mail-archive.com/discuss%40blu.org/msg09114.html

He's trying to spread the line, "Friends don't let friends run stock
firmware."

But there's more to it than that. For a very long time I've ran 3rd
party firmware on my consumer routers, but that alone isn't a great
solution if the community around those third party firmware builds is
small and fragmented, as has happened with the Tomato firmware.

Jim's main takeaway from the talk is that whatever firmware you go with,
make sure it is one that is getting regular updates, and apply the
updates. He recommended OpenWRT and felt it was being well maintained.

I've previously mentioned the Ubiquiti EdgeRouter here:
http://www.mail-archive.com/discuss at blu.org/msg09064.html

which I still don't have first-hand experience with, and thus can't
recommend it, but it continues to look interesting based on specs and
reviews. It runs a fork of Debian, but I haven't been able to get an
answer as to how frequently it receives updates.


Years ago I used to have a router separate from a WiFi access point
(which was just another consumer-grade router reconfigured). I'm
planning to switch back to that model. One reason is that one of the big
stumbling blocks in getting third party firmware to support a router is
getting the wireless radio to work. Often this requires using a binary
blob supplied by the chipset vendor and borrowed from the commercial
firmware that came on the router. Another reason is that the more
complication you add to your border router, the more opportunities for
vulnerabilities there are. (While technically WiFi is on the border of
your network, the requirement for physical proximity vastly reduces the
number of potential attackers.)

So determine what software you want to run on your border router and
then select appropriate hardware. (OpenWRT has good hardware guides.)
Perhaps you can optimize for a box with more RAM so you can run
intrusion detection tools, rather than having that money go to fancy
radios. Focus on keeping this router always up to date.

Run wires to your 1st floor and install a couple of consumer-grade
routers with OpenWRT configured to act as access points. These you can
be a bit more lackadaisical about updating.

 -Tom

-- 
Tom Metro
The Perl Shop, Newton, MA, USA
"Predictable On-demand Perl Consulting."
http://www.theperlshop.com/



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org