[FEATURE REQUEST] Restrict emHTTP to IANA private

[NAS]

We have seen a few crazy people intentionally put unRAID web gui (emHTTP) on the internet and I will guess others do it by mistake not really knowing how to config NAT and firewall rules etc

 

This is doubly true in the post v6 docker world.

 

I suggest that we consider making emHTTP reject any source IP that isnt in one of the IANA private ranges.

 

For clarity this is just unRAIDs control interface not dockers etc

[Helmonder]

Might be an idea if it is easy to do...

 

Ofcourse those systems would still be possibly reachable thru telnet, so its not a real extra layer of security.. But its something.. that is true...

[limetech]

Doesn't help much if someone uses port forwarding in their router to access their server right?

[NAS]

Doesn't help much if someone uses port forwarding in their router to access their server right?

 

Port forwarding typically only translates the destination IP and/or port (NAT/PAT) so it should work just the same.

 

It makes sense to extend this idea to Telnet as well although an arguemnt for another day is that windows doesnt ship with telnet anymore but Win10 does ship with SSH.

 

The only two scenarios I can think of where this doesnt benefit us are:

 

1. Institutions that use public IP address space internally. Typiclly these a mega corps (rare now days)  and academic institutions (less rare)

2. IPv6

 

No one else should even notice so IMO if it saves 1 person its worth considering.

 

 

[JonathanM]

The only two scenarios I can think of where this doesnt benefit us are:

 

1. Institutions that use public IP address space internally. Typiclly these a mega corps (rare now days)  and academic institutions (less rare)

2. IPv6

 

No one else should even notice so IMO if it saves 1 person its worth considering.

As long as it can be unblocked by a setting in a config file somewhere, then Tom can tell the effected licensee how to unblock that machine. Yes, it's a form of security by obscurity, but at least the default condition would be more secure.

[NAS]

I doubt it will have an impact on any supported use cases. In the last 10 years I have only see two client that had servers on public space and even then the clients were on private. As with all lock down features though you need to give users the ability to turn it off as those that want to do something silly still need to be able to.

 

For clarity though technically it is not "security through obscurity". This is when you hide something but it is still available. In this case we will be actively dropping connections from non IANA private address space either through iptables, hosts.deny, hard coded emHTTP lock downs or some other means.

 

I freely admit this isnt the be all and end all of security but its not a unique idea either. Plenty of enterprise products on initial setup make you define trusted hosts that are allowed to access the control interface, we are in essence just doing a lax "no internet" version of this by default.

[JonathanM]

For clarity though technically it is not "security through obscurity". This is when you hide something but it is still available.

I was referencing hiding the setting to turn it back on, where the insecure setting is still available, but the option to enable it is hidden.

 

Clumsy reference, sorry.

[NAS]

all good