It is possible to only (network) bind influxdb/weather to localhost?

[hulkster]

Per #357 , I have Powerwall-Dashboard setup on a public server. As typical, I'm running firewalld and the default policy is DROP ALL except for specified opened ports, such as ssh, http, https. So I dutifully opened up port 9000 for Grafana to public access.

But when I did an nmap, I also saw port 8086 (influxdb) and 8676 (weather) open ... again, this is on the public side. So after saying WTF, I went down a deep rabbit hole ... and it's a well known "problem/complaint" that docker effectively bypasses the firewalld rules.

While there is some IPTABLES "black magic" using DOCKER-USER to restrict this, I'm wondering if it would make sense for there to be an option such that influxdb/weather only binds to the localhost.

For instance, I noticed that influxdb.conf has this line at the top:
"bind-address = "127.0.0.1:8088"
but in the http section, it just has:
bind-address = ":8086"

Semi-similarly, weather.conf has:
PORT = 8676

I realize not much of a concern if you are running internally on your house LAN. I also understand why it's useful to directly query these (some examples in the README), but there should be some way of restricting access to these services.

So is it possible to address this security concern by only binding influxdb/weather to localhost, which should still (?) allow Powerwall-Dashboard (running on same machine) to internally query these?

[hulkster]

I'm new to Docker and not a Python coder, but here's a good writeup from Docker themselves about the network security problem ... and how to (mostly) solve it specifying the loopback 127.0.0.1 interface:

_Publishing container ports is insecure by default. Meaning, when you publish a container's ports it becomes available not only to the Docker host, but to the outside world as well.

If you include the localhost IP address (127.0.0.1) with the publish flag, only the Docker host can access the published container port.

$ docker run -p 127.0.0.1:8080:80 nginx_

I do understand why people want (and are comfortable) with the various Powerwall-Dashboard services being available from other machines, but this would be a nice option to have for those of us that don't want to expose the underlying services outside the local machine.

Is this simply a matter of modifying the "ports" and/or "published" lines in powerwall.yml?

[jasonacox]

Hi @hulkster , it is working as intended. The following web services are part of what we wanted to expose (TCP Ports):

• 8086 (InfluxDB) - Technically could be localhost but I personally uses tools from my laptop to interface with this as I know others do as well.
• 8675 (pyPowerwall) - This must be exposed if you want the power flow animation in the dashboard. The browser goes directly to this port. I also have many other devices that uses this endpoint to get Powerwall data (e.g. Powerwall Display)
• 8676 (weather411) - Technically could be localhost, but as with pypowerwall, I have other systems hit this for current weather data and displays.
• 9000 (Grafana) - This must be exposed if you want to see the dashboard.

If you are using the docker compose that is installed by default via setup.sh, it creates a localized network for routing and likely could be used for further restrictions instead of using the docker run command you mention.

Now... I'm a bit more concerned about your network setup. My router will allow me to expose systems on the public internet, but I would never allow ALL ports. If it is hosted in the cloud, it would be a security group (SG) or other method for controlling access. I would highly recommend controlling the access to ports on the system using an external control like a router or SG instead of using the OS or application changes. An update or some accidental install may open a new port and you would be exposed. Personally, I'm not comfortable putting Grafana or pyPowerwall on the open internet and would always use a VPN method. Anyway, my $0.02. :-)

I do understand why people want (and are comfortable) with the various Powerwall-Dashboard services being available from other machines, but this would be a nice option to have for those of us that don't want to expose the underlying services outside the local machine.

Understood. I'm happy to entertain updates and any PRs you want to send. I do want to make sure the default installation is open by default and to not encourage direct public internet exposure. I think we could also document the details on what you are able to come up with in this discussion for anyone else to follow.

[hulkster]

Thanks for the good info @jasonacox . I'm just proposing that if there was an EASY way to optionally restrict access, that might be a handy feature.

I AM using setup.sh (really appreciate your clean install tools) and tried fiddling with .yml's, etc. - basically just want "127.0.0.1:8676:8676" ... but no luck due to my lack of docker/python knowledge.

My network setup at home is behind a router and yes, default is DROP/DENY all ... and then you punch through as needed.

The system I have this running on is just a dedicated server at a hosting provider on the Public Internet. So there is no networking gear to put a layer between it ... but firewalld takes care of things. But docker (basically) bypasses firewalld - a decent summary from a Docker Software Engineer here.

So this should eventually be "fixed" by the Docker folks ... and that's the "best" solution since it is global ... rather than per-application as I'm asking about here since I thought it might be something easy to do. Don't mean to make a big deal about it

P.S. Speaking of security stuff, a minor thing that is maybe worth mentioning is that if someone doesn't have weather411 locked down, it does show your API key. Easy enough to modify server.py to fix that ... plus increase the 5 second refresh which seems pretty fast for weather data ... albeit you'd like to know soon if it clouds up.

[mcbirse]

Having a containers exposed ports only bind to localhost seems like an edge case scenario / requirement to me.

As Jason has explained, the current setup is working as intended. In my opinion the default project configuration should be aimed at the majority - which is, I believe - the majority would expect to be able to connect to the docker services (e.g. grafana) from another host on their LAN.

I had a look into this though, and if you are already modifying the powerwall.yml file directly, then you can modify the ports section and add a host_ip value to force the container to bind to a specific ip address / interface on the host - for example you could do the below for the weather411 service to have it bind to localhost only.

    weather411:
        ports:
            - target: 8676
              published: 8676
              host_ip: 127.0.0.1   # bind to localhost only
              mode: host

Of course, this is done by editing powerwall.yml directly which we want to avoid, as it will break upgrades.

I did some more checking and believe I've come up with a better way of doing this, which adds flexibility allowing the setup to be customised for specific user requirements (relating to the host/port definitions), without the user having to modify the powerwall.yml file directly (so avoids modifying tracked files and therefore upgrades aren't impacted).

For the powerwall.yml file, we change all containers "port" definitions to use an environment variable. So instead of above, we would have the following.

    weather411:
        ports:
            - "${WEATHER411_PORTS:-8676:8676}"

This is using the "short" syntax of the ports definition so we only need one variable. I don't believe we need to use the "long" syntax (I think "mode" is only relevant to replicated services in a docker swarm?).

Note also, the environment variable is using parameter expansion - so when unset or null, it will be set to "8676:8676" anyway, which still allows us to set/control defaults for the project without having to worry about actually defining the variable anywhere.

Now though, the user can override the ports for a container by editing compose.env. For example, below would satisfy your requirement to bind weather411 to localhost only (without needing to edit powerwall.yml).

# compose.env
# Environment variables for docker compose.
#
WEATHER411_PORTS="127.0.0.1:8676:8676"

Testing this shows the container bound to localhost only (also confirmed, I could not connect to http://host:8676/ from another computer on my LAN).

CONTAINER ID   IMAGE                            COMMAND                  CREATED          STATUS          PORTS                                                 NAMES
5ca13c560053   jasonacox/weather411:0.2.2       "python3 server.py"      29 seconds ago   Up 23 seconds   127.0.0.1:8676->8676/tcp                              weather411

And further testing, if the variable wasn't defined, e.g. compose.env contained:

# Environment variables for docker compose.
#
#WEATHER411_PORTS="127.0.0.1:8676:8676"

Then the container will use the default ports defined in the powerwall.yml file and bind to all interfaces (0.0.0.0).

CONTAINER ID   IMAGE                            COMMAND                  CREATED          STATUS          PORTS                                                 NAMES
0244b7b24589   jasonacox/weather411:0.2.2       "python3 server.py"      36 seconds ago   Up 32 seconds   0.0.0.0:8676->8676/tcp, :::8676->8676/tcp             weather411

The more I think about this, the more I believe this is a worthwhile change. It allows the user to change the exposed ports if they need to, without needing to edit the default docker compose configuration file and breaking upgrades.

@jasonacox and others - thoughts? Do you see any potential issues?

Happy to include this in other changes I'm working on (not sure how long this will be though...).

[jasonacox]

I like this @mcbirse ! Can anyone think of a use case where there would be side effects (e.g. Windows OS, MacOS, NAS)?

[hulkster]

That sounds like a very elegant solution. Thank you @mcbirse (and @jasonacox) for looking into this.

I did some VERY quick testing and I seem to get the same results as you. You can no longer connect to the port from the "outside" since binding is to 127.0.0.1 (as seen in docker ps) ... but the Grafana interface is able to do so internally and show data. Two minor things I'll toss out for possible consideration:

• For similar reasons, could you add "GRAFANA_PORTS" and "INFLUXDB_PORTS" to compose.env and powerwall.yml
• The Docker Documention uses the term "IPADDR:HOSTPORT:CONTAINERPORT" when you say something like 127.0.0.1:8676:8676. While fully descriptive, that's pretty darn long to make into a variable name(!) ... so I "get it" that going with just "PORTS" is a heck of a lot shorter/easier ;-)

UPDATE: Using this procedure, I forced all ports to bind locally only ... and then route the Grafana Dashboard out via an Apache Reverse Proxy. Tastes Great AND Less Filling! ;-)

UPDATE2: Forgot to mention for those that stumble upon this thread that Grafana apparently restricts some things you can do when you are reverse-proxy'ing ... even if logged in as admin ... so you may get an "Origin Not Allowed" error message if you try to do things like modify/delete dashboards.

If you are running Apache, the solution for this is to add "ProxyPreserveHost On" in the conf file.

Or you can quickly comment the "GRAFANA_PORTS="127.0.0.1:9000:9000" line in compose.env, run setup.sh (don't change anything) and then do a "direct" connect to port 9000 to make changes. When done, uncomment the line, re-run setup.sh ... and port 9000 is no longer exposed and access is via the reserve proxy.