Hardening uhttpd - default settings

Hi all,

I'm a little confused about something. After digging through the OpenWrt documentation to harden my router setup, I read that uhttpd listens to all interfaces by default, including a WAN interface.

Would it not be safer to have uhttpd by default only listen on LAN interfaces? Is there a reason why it is not setup in this way? Is this something that the developers will look to change? :stuck_out_tongue:

For example, dropbear is configured to listen on LAN by default, despite the default firewall being set to reject connections to uhttpd or dropbear from the WAN.

Edit: elaborated more on what I'm asking above.

Yes, it would help. Moving to luci-ssl-nginx on master would be even a better idea, as uhttpd isn't really "hardened" for public exposure.

I wonder about this myself..
When somehow the firewall is failing all services will be exposed to the internet.
(if they listen on all interfaces/wildcard)
Not only luci....
Also Unbound has the same problem, the uci scripts even add the public interface IP addresses to the trusted IP addresses. (access-control in unbound.conf)
By default unbound allows any requests... (deny-any in unbound.conf)

Interface binding affects fault tolerance leading to a potential race condition or a deadlock state:

  • The service init-script requires to wait until the interface is ready otherwise it will fail.
  • Restarting the interface requires restarting the service.
  • Renaming the interface requires modifying the service configuration.

It is not.

2 Likes

This is one of the many reasons that security-conscious people/organizations don't run any services on their firewalls that they don't need to.

Edit:

Another reason to “bind to wildcard” is the desire of people to manage through LuCI on a step-by-step basis. Change your LAN IP and, if you’re listening to a fixed IP, no more LuCI, SSH, ... It’s a usability trade-off for non-CLI users.

1 Like

Indeed.

There should be in option in the unbound luci interface to let the user specify the listen interfaces
and way to manage the allowed networks/IP-Ranges that unbound should answer queries for.

Also there seems to be a bug with uhttpd or netifd? I have configured uhttpd to listen on a ipv4 and ipv6 address. For ipv4, it works fine. For ipv6 it does not. I have to restart uhttpd manually after boot to make it listen on that address.

@vgaetera My mistake. You are correct.

Doesn't LuCI also prevent access from SRC RFC1918 IP to a DST Public IP?

Most secure would be to have LuCI bound only on localhost then ssh or VPN tunnel to it.

1 Like

@lleachii Yes, but my concern is about WAN machines attempting to access LuCI.

@mk24 Perhaps, but my post is inquiry regarding the default configuration.

wouldn't luci from WAN is needed for extender type device, as it only has 'WAN' wired port and wifi is disabled in default?

Single-port devices typically are configured to have their single port configured as "LAN" on first boot.

See, for example, target/linux/ath79/base-files/etc/board.d/02_network

ath79_setup_interfaces()
{
        local board="$1"

        case "$board" in
        aruba,ap-105|\
        avm,fritz300e|\
        devolo,dvl1200i|\
        devolo,dvl1750c|\
        devolo,dvl1750i|\
        engenius,ecb1750|\
        glinet,ar300m-lite|\
        netgear,ex6400|\
        netgear,ex7300|\
        ocedo,koala|\
        ocedo,raccoon|\
        pcs,cap324|\
        pisen,wmm003n|\
        pqi,air-pen|\
        tplink,cpe210-v2|\
        tplink,cpe210-v3|\
        tplink,re350k-v1|\
        tplink,re450-v2|\
        tplink,tl-mr10u|\
        tplink,tl-mr3020-v1|\
        tplink,tl-mr3040-v2|\
        tplink,tl-wa901nd-v2|\
        tplink,tl-wr703n|\
        ubnt,bullet-m|\
        ubnt,bullet-m-xw|\
        ubnt,lap-120|\
        ubnt,nanobeam-ac|\
        ubnt,nanostation-ac-loco|\
        ubnt,rocket-m|\
        ubnt,unifiac-lite|\
        ubnt,unifiac-mesh|\
        ubnt,unifi|\
        wd,mynet-wifi-rangeextender|\
        winchannel,wb2000)
                ucidef_set_interface_lan "eth0"
                ;;
[...]