Введение
В этой статье я хочу углубиться в некоторые дополнительные меры к тем, которые я раскрыл в своей первой статье, которые добавляют достаточно высокий уровень контроля и защиты систем внутри нашего дома. Я оставлю за читателем выбор применять их или нет, в зависимости от его потребностей.
Внутренний SSL
Зачастую, когда у нас есть разнообразная экосистема приложений внутри внутренней сети дома, поскольку они обычно являются частью личных проектов, мы недооцениваем внутреннюю безопасность в пользу простых решений, таких как использование VPN.
Одна из вещей, о которой часто забывают, — это создание SSL-сертификатов для внутренних служб. Давайте вспомним, что польза SSL-сертификата заключается не только в том, что он позволяет браузерам показать, что удостоверяющему центру доверяют, но и в том, что он позволяет использовать шифрование при обмене данными между службами.
Некоторые из возможных вариантов управления внутренними SSL-сертификатами:
- Создание SSL-сертификата с помощью командной строки: Это вариант, который требует наименьших первоначальных усилий. По сути, мы создаем SSL-сертификат для любого домена, используя, например, OpenSSL. Мы даже можем создать сертификат, срок действия которого истекает через 100 лет. Конечно, нам придется установить этот сертификат в наших внутренних службах, добавить исключения в браузеры, чтобы не появлялись предупреждения, и понять, что у нас нет части «доверия», которая обычно ассоциируется с протоколом HTTPS.
- Внедрите автоматизацию генерации сертификатов: Одним из них является certbotwhich, который теоретически позволяет автоматизировать генерацию, а иногда и установку SSL-сертификатов (например, сертификатов Let’s Encrypt). Его можно даже установить в качестве сервиса в docker.
Простукивание портов
Все мы знаем, что для того, чтобы подключиться к серверу, нам нужно пойти на некоторые уступки в плане увеличения поверхности атаки внутри этого сервера. Одним из таких примеров является открытие портов. Чтобы безопасно подключиться к серверу, мы можем использовать подключенный к нему ssh-сервер с открытым портом. Поскольку мы не знаем, когда захотим подключиться, мы должны постоянно оставлять этот порт открытым.
Можем ли мы, по предварительному соглашению между клиентом и сервером, уменьшить эту поверхность атаки? Именно на этот вопрос пытается ответить концепция пробивания портов.
Мы видели эту идею в фильмах о мафиози и нелегальных клубах. Закрытая дверь, без каких-либо пометок, чтобы войти, нужно постучать определенное количество раз, иначе не откроют. В случае со стуком в порт, у нас будут закрыты все порты сервера, и только при выполнении определенной последовательности «ударов», в данном случае, отправки пакетов на определенные порты, мы откроем порт (обычно порт ssh сервера).
А как сервер узнает, что к нему «стучатся»? Простым способом — записывая в журнал пакеты, приходящие на пустые порты, и анализируя этот журнал.
Для того чтобы настроить стук в порт, предположим, на сервере ubuntu, мы выполним следующие действия:
sudo apt install -y knockd
Далее откроем файл конфигурации:
sudo nano /etc/knockd.conf
[options]
UseSyslog
[openSSH]
sequence = 7000,8000,9000
seq_timeout = 5
command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags = syn
[closeSSH]
sequence = 9000,8000,7000
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
tcpflags = syn
Здесь мы можем наблюдать:
- sequence: последовательность портов, которые должны быть вызваны для активации данного правила.
- seq_timeout: общее количество секунд, в течение которых вся последовательность должна быть выполнена
- command: открытие порта, в формате выполнения iptables
- OpenSSH, closeSSH: идентификационные имена правил (вы можете поставить все, что захотите).
Обычно мы изменяем список портов (конкретный протокол может быть даже указан на каждом порту, например, 2222:udp,5736:tcp) и, если мы не уверены в возможных проблемах с задержкой при удаленном подключении, мы увеличиваем таймаут.
После того как все это настроено, у нас есть несколько вариантов, чтобы сделать «звонок». Существуют мобильные приложения для стука по порту, а из коробки пакет knockd, установленный на другой машине, поставляется с клиентом knock, который можно запустить командой вроде этой:
knock –v ip_servidor 7000 8000 9000
Минимизация DNS и Qname
Во многих случаях решения о теоретической безопасности связаны с двумя другими понятиями — конфиденциальностью и контролем.
Как мы хорошо знаем, существуют машины, которые помогают существованию Интернета, называемые DNS, которые переводят веб-адреса, которые мы пишем в браузере, или через которые мы получаем доступ к различным API, в IP-адреса.
Существует тип атаки под названием DNS spoofing или DNS cache poisoning, заключающийся в том, чтобы контролировать или обманывать DNS-сервер, заставляя его предоставлять неверный IP-адрес для веб-адреса, обычно указывающий на вредоносную копию оригинального сервиса, чтобы перехватить данные, которые вводит пользователь.
Как мы можем защититься от этой атаки? Один из возможных ответов — контроль.
Если мы вспомним мою предыдущую статью, у нас есть система фильтрации DNS под названием PiHole, которая блокирует потенциальные угрозы на уровне веб-адреса. Но Pi-Hole ниже, со стандартной конфигурацией, использует проприетарный DNS, как Cloudflare.
Мы можем получить немного больше контроля, установив (например, на той же машине, что и Pi-Hole, или в другом контейнере) наш собственный DNS, в данном случае с Unbound. Я не буду вдаваться в подробности установки, поскольку существует официальное руководство.
После настройки Unbound у нас уже есть собственный DNS, но есть возможность еще большего контроля (а в данном случае еще и конфиденциальности) — QName Minimization.
Чтобы объяснить это, мы воспользуемся примером. Наш DNS получает информацию с глобальных серверов TLD (доменов верхнего уровня). Представим, что мы запрашиваем веб-сайт foo.bar.com, чтобы получить IP-адрес этого веб-сайта, допустим, мы должны обратиться к следующим TLD:
- TLD 1, который знает о домене .com
- TLD 2, который знает о .bar
При обычном использовании мы отправим обоим серверам полный адрес, foo.bar.com. Но если мы включим функцию QName Minimization, мы отправим только тот фрагмент адреса, который относится к каждому из них:
- TLD 1, «.com»
- TLD 2, «.bar»
Таким образом, мы избегаем отправки ненужной информации в ДВУ, а также избегаем того, чтобы все задействованные ДВУ знали полный адрес, по которому ведется поиск.
Заключение
В этой статье я хотел рассмотреть некоторые продвинутые моменты защиты и контроля над нашей локальной инфраструктурой. Как я уже говорил, в большинстве случаев нет необходимости достигать такого уровня безопасности и контроля (хотя это может быть хорошим упражнением для расширения знаний). Для тех случаев, в которых вы считаете это необходимым, я надеюсь, это поможет вам.