Franck Nijhof c464056402
Making our website faster, cleaner and prettier (#9853)
* 🔥 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
2019-07-15 22:17:54 +02:00

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