[OpenWrt-Devel] OpenWRT IPv6 firewall
s.L-H at gmx.de
Fri Jul 18 21:26:43 EDT 2014
On Saturday 19 July 2014, David Lang wrote:
> On Fri, 18 Jul 2014 10:21:56 -0700, Bill wrote:
> > Gert Doering wrote:
> > On Thu, Jul 17, 2014 at 10:20:09AM +0200, Steven Barth wrote:
> > P.S. No, my printer is not v6-ready, either, but let's assume there
> > are some that are...
If you're looking for real world examples, consider a 2009 vintage
"OKI B430dn" black&white laser printer (which was targetted relatively
cheaply (<160 EUR) between advanced desktop tasks and small
workgroups), something I would call quite representative for embedded
- it comes with an embedded printserver
- supports IPv4 and IPv6
- it defaults to using DHCP for IPv4.
- the IPv6 implementation is enabled and uses SLAAC by default.
- it does not support DHCPv6, but does support fully manual
configuration (in a very, very limited way and not beyond the limits
depicted for the SLAAC case below).
- via SLAAC, it binds to the globally routable IPv6 address (and to
its link local address (fe80::/10)), it does not support ULA
prefixes, privacy extensions or anything more advanced. Within these
constraints, IPv6 support works surprisingly well (and reliably).
- this printer does have rather advanced user access controls for an
embedded device, including a local static user/ password store and
802.1X (EAP). but, like pretty much any embedded device, it ships
without any of this this enabled --> fully open for printing, default
username and password for administration and everything else.
- it does offer a plethora of protocols (SNMP, telnet, ftp, NetBEUI,
Ethertalk, (LPR, Port9100, IPP, NetWare PServer/ RPrinter, etc.)),
with at least the common ones (IPP, LPR, Webinterface, SNMP) enabled
- there are no intrusion detection methods, nothing stops you from
painstakingly brute forcing your way into it (if the default
username/ password don't happen to work and if you really don't find
a simpler way in).
On paper, the access controls are pretty advanced (if you bother to
configure them), but would I trust its security if exposed to the open
internet? Of course not.
To the best of my knowledge there hasn't been any security problem
published, but at the same time there has never been a firmware update
either, nor would I expect any after 2, or 5, years - even leaving
alone the likelyness that an enduser (or the resident (network-) admin
for a small to medium office or company) would find one, if it existed,
or risk flashing it.
> that's a real example that has been exploited in the past, especially
> with the very expensive, high-end printer/copiers sold to businesses.
> Again from companies that "should know better"
Like David Lang mentioned, there are tons of network enabled devices,
increasingly with some kind of IPv6 support. Why, because supporting
it essentially comes for free (especially if you base your firmware on
linux, one of the BSDs, etc.) and allows the manufacturer to tick a few
more bullet points in their product description. Security is usually
being an afterthought at best, you can be happy if IPv6 support
actually works in the first place (see the limited configuration
options for the printer mentioned above).
While probably not printers, many of these will need a globally
routable address for outgoing services (think NAS and downloading
functions), but fewer need to provide incoming services to the internet
at large (while you may want to connect to them via a VPN) - and very
few can be expected to be (and remain-) secure over their whole
effective life time (which can easily be 5-10 years or longer for
printers, wireless security cameras, simple NAS boxes and other
embedded devices). This even ignoring that pretty much all networked
appliances (including OpenWrt itself) default to open access (with weak
default passwords at best) after firstboot, because that and binding to
all available network addresses is the only way to configure them in
the first place.
With IPv6, you naturally get end-to-end connections, but this (imho)
shouldn't imply unfiltered, incoming connections by default. Unlike
with IPv4 and NAT, you do have all the options to allow incoming
connections easily, for all your devices, without having to fight with
managing portforwardings within the acceptable range of your service.
If you're in an ISP-like position, you certainly need to provide
unfiltered access to your clients, but CPE devices (which OpenWrt
certainly is) better error on the side of caution and provide the
ingrained expectation of having a secure local net.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel