I’ve searched for more information but could not find anyhing according to a local firewall on HA. Is there any reason why there was never a local firewall inplemented into HA? I mean, I am aware that I can separate my network into different subnets and VLANs and then use my cental router/firewall to controll traffic between them, but a critical device like HA should have the possibility to enable a local firewall in my opinion. There sometimes are reasons having specific devices on the same subnet as HA and therefore it would make sense to have the possibility to only allow the according services locally via HA firewall. And people who don’t want/need it could disable it completely anytime.
But -as always- there may be some good reasons why there is no firewall implemented.
I’m just curious and want to be constructive, no trying to troll here 
I know @agners is mostly the man here who could answer this question, so if he is willing to take his time to answer this, that would be very appreciated.
Thanks!
Local, personal (or what I would call it desktop) firewalls are mostly useful on general purpose operating system, where it is unknown what type of software is running on, or the software which runs on is not fully trustworthy.
Home Assistant OS is designed as an appliance, where we largely know what software is run on. There is no random port open, it is Home Assistant frontend on 8123 and the observer on 4357. Furthermore, add-on are containers, which are in a separated network (this is a feature of the underlying container technology implemented by Docker). Docker than uses iptables, which is a firewall, to setup what ports are publicly accessible. An add-on needs to explicitly tell the system through it’s config what port should be open to the public.
So in a way, there is some firewall functionally already built-in, but it’s largely transparent.
That said, the system could be extended with more (default) rules to increase security still. But so far this hasn’t really come up as a necessary or a problem.
Fair enough, thanks a bunch for your response. I did not know about add-ons being abstracted by Docker and therefore iptables do come in.
Well, security most always unfortunately is not a concern, until it hits in. So personally I would always appreciate to increase security wherever it is possible. You surely know better than me where there are potentially thing to improve in HA, maybe something to keep in mind for the future.
Thanks again man, your answer is very appreciated!
Hello!
I have just installed HAOS and I’m disappointed by the absence of configurability on that regard, for a tool that prides in having the data be rather private. That is a security concern for me, considering how much data Home Assistant has (location…).
My issue specifically is that add-on containers are always exposed to 0.0.0.0, even if they are actually only needed by HomeAssistant itself, and that HomeAssistant seems to expose a lot of ports which I doubt are all regularly necessary.
nmap reports no less than 11 exposed ports on a default install with only Mosquitto & SSH added.
I would expect that number to be something like 3, for HTTP(s), SSH, and maybe some service discovery.
Look at Mosquitto for example. Installing the add-on opens an unencrypted MQTT server port on whatever local network the Home Assistant controller is running on, but I really only need it to be accessible to zigbee2mqtt and Home Assistant, both of which are running on the same device.
This is bad security practice simply because it unnecessarily increases the attack surface of the system: assuming somewhat untrusted or potentially compromised devices may connect to the local network HAOS is running on, the attack surface is now not only the Home Assistant HTTP server, but also MQTT, hassio-observer, rpcbind, llmnr, as well as ports 18555, 40000 and 40567 which I don’t even know what they are, and any other random addon’s internal services. This is unreasonably hard to audit. There are released vulnerabilities on tons of services very regularly, which may then allow pivoting to VM escape and compromising the entirety of HA. For example Mosquitto itself has quite the collection of security vulnerabilities.
A very basic yet very effective countermeasure is to not expose services that don’t need to be exposed, the idea being that even if they are vulnerable if you can’t access them you can’t exploit them.
My understanding is that currently, when HAOS reads the configuration file related to ports, it always binds to 0.0.0.0:port and :::port (ipv6), in turn leaking the plugin’s interface on any network the device is connected to. (This is what docker ps says.)
It looks like this could be fixed reasonably easily by either:
- Adding a new global option for add-ons (similar to “Start on boot” and “Watchdog”) called “local only” that would make it so that it only binds addons ports to
127.0.0.1,::1and thehassiodocker network (172.30.32.1/23). (Alternatively this could also be made configurable per port.) - Being able to firewall, with e.g. a firewall addon, and opt-in exposed ports for physical interfaces at the system level. (e.g. only 22 and 443 can leak through ethernet and wifi interfaces)
WDYT? Has anyone worked on making such a thing work with HAOS so far?
Thanks,