Comments 22
А нужно то было просто свой VPN/любая Zerotrust сеть/ поднять и не публиковать домашние сервисы наружу по IP.
Конечно входить только по VPN это лучше всего. Но у HA есть подключение с мобильного приложение и передачи некоторых данных. Я например это использую в автоматизациях. Так же есть внешние сервисы которые должны пробиваться на сервер. Яндекс например. Так что в статье описано много интересного. Я на 70% настраивал так же. Новое тоже почерпнул! Спасибо автору!
На порт 8443 с высокой вероятностью не сможете зайти с корпоративного или публичного Wi-Fi. Мне из-за этого наоборот пришлось перевесить все сервисы, даже те которые изначально были на нестандартном порту, на порт 443.
Использовать VPN и не публиковать наружу, как предложили в соседнем комментарии, не подойдет. Мне, например, нужно постоянная передача геолокации устройства в Home Assistant. А постоянно включенный VPN сильно потребляет батарею. Да и не забываем, что VPN внезапно может оказаться заблокированным, даже внутри РФ.
Ограничение доступа по стране, возможно имеет смысл для домашнего сервиса в том случае, если вы не выезжаете заграницу. Но в целом тенденция возводить границы в интернете мне определенно не нравится. Лучше уж старый добрый fail2ban прикрутить.
Не нравится VPN, можно старый добрый port knocking использовать. Благо knockd прикручивается легко и просто.
port knocking - это когда нужен разовый периодический доступ. Вот вам понадобилось зайти, вы стучитесь на нужный порт, после чего заходите.
У меня устройства постоянно и круглосуточно в фоновом режиме отправляют в HA свою геолокацию и другие данные, для этого нужен постоянный доступ без каких-либо дополнительных условий.
На счет fail2ban, как я и писал в статье, если ваш сервер уже попал в базу, и в какой то момент злоумышленники нашли дыру в определенной версии HA, например http запрос с sql инъекцией(самое банальное что на ум пришло), то fail2ban тут не поможет. Не помешает ограничить хотя бы по странам, это уже огромный кусок ботов отлетает не в ущерб не вам не вашей семье. Ну добавьте в firewall турцию, и тай, и нормально. Если часто путешествуете вообще по всему миру, тогда конечно моя статья не для вас. В принципе каждому свое
Отключить IPV6
и предоставить права администратора/запуск сервиса от рута. Индусячьи поделки и советы прям прут изо всех щелей.
Сделайте наконец доступ "во внутрь" через VPN, он-то для этого и предназначен, и не балуйтесь со всякими клауд-фларами, мой Вам дружеский совет. Вы всегда контролируете AS или диапазоны адресов, которые Вам даст Ваш провайдер? А то и они блекхолить умеют, пошло движение в сторону атаки на любой(!) ими защищаемый ресурс, и "ввиду криволапости наших админов мы залочили полмира" (с) было дело, тут неоднократно описывали
Вы лично теряете доступ к своим, подчеркиваю еще раз своим(!) ресурсам.
И да, можно в мануале всегда(!) использовать порт 77777 (помогает от явных копирастеров), как и замена одного из октетов своего айпишника на 321 (как в статье) (тут был тег сарказм, но его съел редактор)
ip.geoip.asnum lt 29092 … or … ip.geoip.asnum gt 29337Мы указали правило, при котором мы блокируем все AS, которые не входят в диапазон
29092-29337…
Гораздо читабельнее было бы обернуть инклюзивное условие в оператор not. Иначе вообще непонятно, по какой логике построен код, без чтения изначальной задачи.
Смена портов от сканеров в наше время помогает примерно никак. А если уж порты переносятся по соображениям безопасности - имеет смысл включить tarpit.
Блокировка по странам/провайдерам приведёт к отвалу приложения при каждом включении зарубежного vpn.
Использование домена уровня 3 и выше имеет смысл только с wildcard сертификатом.
В итоге вся защита свелась к настройке CloudFlare :-(
Как уже указали в комментариях, изменение порта отсрочит старт перебора паролей на несколько секунд, а 8443 это примерно как додуматься задать пароль не password, а passw0rd (букву o заменить на цифру 0), но при этом может добавить проблем, поэтому, сейчас менять порт только для повышения безопасности смысла нет.
Поддомены не особо отличаются от домена по безопасности, особенно если это hass и www
С 1 марта у нас запрещено рекламировать эти сервисы, но если параносить по безопасности и фильтровать по странам и ip, то намного надежней инкапсулировать трафик в более безопасный протокол надежно полключаться к своему инстансу из любой точки мира.
IPv6 сомнительно отключать, по мне так, минусов больше, чем плюсов от отключения, а безопасность все равно не увеличит лучше, чем предыдущий пункт
Еще надо учитывать, что к HA можно подключить Google Home или Алису, тогда надо обеспечивать доступ к HA от этих серверов, причем, они очень сильно любят ходить по IPv6 и при наличии DNS записи AAAA даже не будут пытаться подключиться по ipv4 (в отличие от браузера)
Ну и в плане надежности и отзывчивости, особенно для того, чтобы управлять HA из яндекс станции, cloudflare даст пусть и небольшую, но задержку
А чем не устроил basic authentication и/или mTLS на nginx'е?
Воу, наконец то одобрили мою первую статейку, и комментариев уже столько, чтож, нужно ответить
Использовать VPN самый надежный вариант, но как уже другие юзеры отписали, это не всегда удобно. Я ранее пробовал сидеть с OpenVPN на мобилке на постоянку, но часто отлетало и да, батарею кушало, поэтому метод с VPN лично для меня был не актуален, ну и как оказывается не только для меня
Сменить порт, это защита ни о чем, согласен. Но я в свое время проверял, она отсеивает приличное кол-во тупых ботов, которые запрограммированы на порты 80 и 443. И так как у меня везде в округе разрешено юзать 8443, я так и сделал, хуже уж точно не будет и стоит об этом упомянуть, а дальше уже каждый сам решит, менять или оставить 443
IPV6. В целом мои знания ограничены в этом. Я лишь испытывал одни трудности, создавая сайты с поддержкой IPV6. Мне он не нужен, скорее всего не нужен и многим, отключить его не сразу понятно как, поэтому решил уместным отписать как это сделать. Если вдруг окажется, что ipv6 жизненно необходим, то обязательно дополню статью, пока что не вижу в нем смысла
Про подключение к HA алисы и гугла, я уж не стал писать, разумеется нужно будет добавить их AS в белый список
При использовании cloudflare, задержка увеличится на ~30 милисекунд. Мы не в кс играем, чтобы вообще думать об этом мгновении. Однако повторюсь, что находясь дома, я бы хотел чтобы задержка стремилась к нулю, чего мы и добиваемся, используя дома локальный адрес (см настройки приложения HA)
Ну и разумеется, все что я описывал выше как идею, можно перенести непосредственно в nginx. Я реализовал на cloudflare, потому что: почему бы и нет? Просто и быстро
Провайдеры могут косякнуть, может произойти так, что вы на своем мобильнике выйдите в сеть под другим AS и попадете в блок, на этот случай как я уже и писал в статье, должен быть VPN поднят. Потом приедете домой и добавите новый блок AS в правила WAF. Не думаю что это будет частым явлением, но время покажет
Обязательно ставить HA на поддомен. Вы вот шутите, а за последние 24 часа у меня на корневой домен ломилось 70 ботов, а на поддомен не одного. Как я и писал, задача сузить круг, сделать так, чтоб никто вообще не знал о самом существовании вашего HA.
Не все родственники могут поднять на своих девайсах VPN/Zerotrust по инструкциям. А тут человек применяя свои скиллы сделал все достаточно удобно, организовав доступ по единой ссылке. Такая конфигурация чаще используется чв продакшене в организациях, чтобы ничего руками не настраивать на устройствах.
вот рекомендации разработчиков про securing:
Я если честно не очень понял как происходит взаимодейтсвие ha с cloudfire, cf рабоатет как прокси, или как dns ресолвер? а то выглядит так как будто ha все равно выставил свой порт наружу - сканbруй не хочу.
Wireguard или тотже l2tp до своего роутера, доступ к ha только из локалки и все. Не надо параноить
Вместо того, чтобы ограничивать доступ к nginx-прокси по подсетям Cloudflare лучше настроить доступ к nginx только по клиентскому сертификату Cloudflare: https://developers.cloudflare.com/ssl/origin-configuration/authenticated-origin-pull/.
Защита Home Assistant