mirror of
https://github.com/home-assistant/home-assistant.io.git
synced 2025-05-27 21:36:51 +00:00

* 🔥 Removes octopress.js * 🔥 Removes use of root_url var * 🔥 Removes Octopress generator reference from feed * 🔥 Removes delicious support * 🔥 Removes support for Pinboard * 🔥 Removes support for Disqus * 🔥 Removes support for Google Plus * ↩️ Migrate custom after_footer to default template * ↩️ Migrate custom footer to default template * ↩️ Migrate custom header to default template * 🔥 Removes unused template files * 🚀 Places time to read directly in post template * 🚀 Removes unneeded capture from archive_post.html template * 🔥 🚀 Removes unused, but heaving sorting call in component page * 🚀 Merged javascripts into a single file * 🔥 Removes more uses of root_url * 🚀 Removal of unneeded captures from head * 🔥 🚀 Removal of expensive liquid HTML compressor * 🔥 Removes unneeded templates * 🚀 Replaces kramdown with GitHub's CommonMark 🚀 * 💄 Adds Prism code syntax highlighting * ✨ Adds support for redirect in Netlify * ↩️ 🔥 Let Netlify handle all developer doc redirects * ✏️ Fixes typo in redirects file: Netify -> Netlify * 🔥 Removes unused .themes folder * 🔥 Removes unused aside.html template * 🔥 Removes Disqus config leftover * 🔥 Removes rouge highlighter config * 🔥 Removes Octopress 🎉 * 💄 Adjust code block font size and adds soft wraps * 💄 Adds styling for inline code blocks * 💄 Improve styling of note/warning/info boxes + div support * 🔨 Rewrites all note/warning/info boxes
55 lines
4.0 KiB
Markdown
55 lines
4.0 KiB
Markdown
---
|
|
title: "Securing"
|
|
description: "Instructions on how to secure your Home Assistant installation."
|
|
redirect_from: /getting-started/securing/
|
|
---
|
|
|
|
One major advantage of Home Assistant is that it's not dependent on cloud services. Even if you're only using Home Assistant on a local network, you should take steps to secure your instance.
|
|
|
|
## Checklist
|
|
|
|
Here's the summary of what you *must* do to secure your Home Assistant system:
|
|
|
|
- Configure [secrets](/docs/configuration/secrets/) (but do remember to back them up)
|
|
- Regularly keep the system up to date
|
|
|
|
If you only want to use integrations supported by [Home Assistant cloud](/cloud/) then you don't need to enable remote access. This is obviously the most secure option, but does mean that you're relying on a cloud service for that functionality.
|
|
|
|
- For remote access to the UI, use a [VPN](http://www.pivpn.io/), [Tor](/docs/ecosystem/tor/) or an [SSH tunnel](/blog/2017/11/02/secure-shell-tunnel/)
|
|
- For remote access for components, use a [TLS/SSL](/docs/ecosystem/certificates/lets_encrypt/) certificate
|
|
|
|
### You should
|
|
|
|
As well as the above we advise that you consider the following to improve security:
|
|
|
|
- For systems that use SSH set `PermitRootLogin no` in your sshd config (usually `/etc/ssh/sshd_config`) and to use SSH keys for authentication instead of passwords. This is particularly important if you enable remote access to your SSH services.
|
|
- Lock down the host following good practice guidance, for example:
|
|
* [Securing Debian Manual](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) (this also applies to Raspbian)
|
|
* [Red Hat Enterprise Linux 7 Security Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf), [CIS Red Hat Enterprise Linux 7 Benchmark](https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v1.0.0.pdf)
|
|
|
|
<div class='note warning'>
|
|
|
|
If you've forwarded *any* ports to your Home Assistant system from the Internet, then it *will* be found by others. Whether through services like Shodan, or direct port scanning, all systems on the Internet are routinely probed for accessible services. If you fail to set a password then it is simply a matter of time before somebody finds your system and starts abusing it - potentially as little as a few hours.
|
|
|
|
</div>
|
|
|
|
### Remote access for just the UI
|
|
|
|
If you only want remote access for access to the web UI then we advise that you follow the [Installation](/docs/installation/) section, then set up one of:
|
|
|
|
- A VPN such as [PiVPN](http://www.pivpn.io/) or [ZeroTier](https://www.zerotier.com/), which will give you access to your whole home network
|
|
- [Tor](/docs/ecosystem/tor/), which also avoids the need for port forwarding
|
|
- An [SSH tunnel](/blog/2017/11/02/secure-shell-tunnel/) to connect to your frontend
|
|
|
|
### Remote access for integrations
|
|
|
|
For remote access for a component, for example, a device tracker, you have to enable access to the API by:
|
|
|
|
1. Following the steps in [Installation](/docs/installation/), then
|
|
2. Forwarding a port and protect your communication with one of:
|
|
* A [TLS/SSL](/docs/ecosystem/certificates/lets_encrypt/) certificate (you can use one from Let's Encrypt, or any commercial SSL certificate vendor)
|
|
* A [self-signed certificate](/cookbook/tls_self_signed_certificate/) - be warned though, some services will refuse to work with self-signed certificates
|
|
3. Optionally use a proxy like [NGINX](/docs/ecosystem/nginx/), [Apache](/docs/ecosystem/apache/), [HAproxy](/docs/ecosystem/haproxy/) or another. These allow you to provide finer-grained access. You could use this to limit access to specific parts of the API (for example, only `/api/owntracks/`)
|
|
4. Enable IP Filtering and configure a low [Login Attempts Threshold](/components/http/)
|
|
5. If you use a proxy then install [fail2ban](https://www.fail2ban.org/wiki/index.php/Main_Page) to [monitor your proxy logs](/cookbook/fail2ban/) (or Home Assistant logs) for failed authentication
|