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.etie...@gmail.com <mailto:champetier.etie...@gmail.com>>
wrote:
>
> Hi Daniel,
>
> Le 13 sept. 2015 22:04, "Daniel Dickinson"
<open...@daniel.thecshore.com <mailto:open...@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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
