[OpenWrt-Devel] OpenWRT www version banner a security risk
Daniel Dickinson
openwrt at daniel.thecshore.com
Mon Sep 14 00:35:32 EDT 2015
On 2015-09-14 12:30 AM, Daniel Dickinson wrote:
> On 2015-09-13 11:39 PM, Florian Fainelli wrote:
>> On Sep 13, 2015 2:00 PM, "Etienne Champetier"
>> <champetier.etienne at gmail.com <mailto:champetier.etienne at gmail.com>>
>> wrote:
>> >
>> > Hi Daniel,
>> >
>> > Le 13 sept. 2015 22:04, "Daniel Dickinson"
>> <openwrt at daniel.thecshore.com <mailto:openwrt at daniel.thecshore.com>> a
>> écrit :
>> > >
>> > > I do think allowing to choose to disable the banner is a minor
>> benefit, however, as I've said, there are much more effective means of
>> preventing accidential exposure, and quite frankly if the user is
>> *choosing* to open the web interface I think an warning and disabling
>> the banner if the user foolishly insists on opening the interface
>> despite the warning is more useful thank disabling the banner by default.
>> > >
>> > > If you're going to argue it prevents against internal threats than
>> I would argue that if your internal network is hostile enough that you
>> need to worry about attacks on openwrt from your internal network AND
>> you're not skilled enough to limit access to LuCI (or better, build an
>> image without LuCI and just use SSH) to the specific trusted hosts
>> (preferably by combination of MAC address and IP address) in the
>> firewall, or (better) to use a 'management' VPN or VLAN that only
>> trusted hosts can get on, then you're in a lot more trouble than
>> eliminating the banner for LuCI will solve.
>> > >
>> > >
>> > > Regards,
>> > >
>> > > Daniel
>> > >
>> > > On 2015-09-13 10:21 AM, MauritsVB wrote:
>> > >>
>> > >> At the moment the OpenWRT www login screen provides *very*
>> detailed version information before anyone has even entered a password.
>> It displays not just “15.05” or “Chaos Calmer” but even the exact git
>> version on the banner.
>> > >>
>> > >> While it’s not advised to open this login screen to the world,
>> fact is that it does happen intentionally or accidentally. Just a Google
>> search for “Powered by LuCI Master (git-“ will provide many accessible
>> OpenWRT login screens, including exact version information.
>> > >>
>> > >> As soon as someone discovers a vulnerability in a OpenWRT version
>> all an attacker needs to do is perform a Google search to find many
>> installations with versions that are vulnerable (even if a patch is
>> already available).
>> > >>
>> > >> In the interest of hardening the default OpenWRT install, can I
>> suggest that by default OpenWRT doesn’t disclose the version (not even
>> 15.05 or “Chaos Calmer”) on the login screen? For extra safety I would
>> even suggest to leave “OpenWRT” off the login screen, the only people
>> who should use this screen already know it’s running OpenWRT.
>> > >>
>> > >> Any thoughts?
>> > >>
>> > >> Maurits
>> > >>
>> >
>> > For me listenning only on lan will break all my setups (15+):
>> > - On most of my openwrt there is no lan, it's management, or
>> 'name-of-the-site' ...
>> > - on some of them i can access from multiple interface (VPNs + ...)
>> >
>> > You can't prevent people from shooting themselves in the foot (maybe
>> port openning was on purpose),
>> > but you can:
>> > -Put a huge warning in luci when you set firewall default to 'ACCEPT'
>> > -add robots.txt (i think the router will still end up on shodan)
>> > -add a big warning if robots.txt is accessed (reliable way to know
>> that you're open on the internet)
>> >
>> > Also you are talking about luci but what about dropbear (ssh)? There
>> is no anti brute force, and maybe there is a banner (on my phone, can't
>> check)
>>
>> For that you could setup different things ranging from using iptables'
>> mlimit match per protocol all the way to having something like fail2ban
>> (written in python though) which can do more complex
>> blacklisting/blackholing.
>>
>> All of that is more of a security policy that you deploy rather than
>> want it by default, even though it may seem very sensible for a default
>> use case.
>>
>> The bottom line is that if you are exposed to the wild internet, just
>> brace yourself, it is only a matter of time before your host gets
>> scanned, brute forced or even penetrated.
>
> Hence my suggestion to make the default configuration luci and ssh on
> lan only. If that doesn't work because you're changing the network
> config then you're already making configuration changes, it's not that
> much harder to also change the ssh and luci config (although perhaps it
> would be useful for this, and for other 'tied' configs (sorry can't
> think of an example right now, but there are a few times where I've
> thought it would have been convenient) to have some sort of unified
> interface for changing all relevant sections at once; I'm not sure that
> kind of thing is worth the effor though).
>
> Also, if the user really wants to enable wan access to ssh and/or luci
> and can't figure out out to change ssh and luci network config (once
> appropriate gui fields are added) then I'm not sure they're competent
> enough to be making that choice.
>
> With one caveat - I think the uhttp config would need to have (e.g.)
> 'http_listener' and 'https_listener' config sections with network and
> port options rather than specifying ip, and have the uhttpd initscript
> substitute the ip of the interface (so that it would work with dynamic
> ips (e.g. dhcp, pppoe, etc)) and use the procd interface triggers for
> when the address changes (and of course the option to have 'custom'
> network option where you can specify the ip instead the network).
>
> If this concept is simply going to be a waste of my time to create the
Obviously I mean ...is not going to simply be a waste of my time...
> necessary patches, I'd be happy to put that on my to-do list (along with
> new image makefile format for my powercloud patches, for which I am
> waiting for lynxis to give the promised time-saving info on how the new
> makefile format works, and which I've agreed to help with wiki pages).
>
> Regards,
>
> Daniel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list