Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы администрирования и системного программирования в операционной системе Linux. В 2 частях. Ч.2. Учебное пособие.pdf
Создадим программный код для генерации файлов конфигурации с релевантными сертификатами, ключами и файлами шифрования:
nano ~/client-configs/make_config.sh
#!/bin/bash
# First argument: Client identifier
KEY_DIR=~/client-configs/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf
cat ${BASE_CONFIG} \
<(echo -e '<ca>') \
${KEY_DIR}/ca.crt \
<(echo -e '</ca>\n<cert>') \
${KEY_DIR}/${1}.crt \
<(echo -e '</cert>\n<key>') \
${KEY_DIR}/${1}.key \
<(echo -e '</key>\n<tls-auth>') \
${KEY_DIR}/ta.key \
<(echo -e '</tls-auth>') \
> ${OUTPUT_DIR}/${1}.ovpn
Сгенерируем конфигурацию для этих файлов перейдя в директорию
~/client-configs и используем скрипт выше:
cd ~/client-configs
./make_config.sh client1
3.3.9. ЗАПУСК У КЛИЕНТА
Установка OpenVPN у клиента:
sudo apt update
sudo apt install openvpn
Полученный файл необходимо передать клиенту и запустить с помощью
следующей команды:
openvpn --config client1.ovpn
После подключения проверим доступность компьютера, который находится в одной сети с сервером (рис. 3.21).
51
Рис. 3.21. Проверка доступа к компьютеру VPC
52
4. АДМИНИСТРИРОВАНИЕ СИСТЕМЫ ИНСПЕКЦИИ ТРАФИКА DNS
Интернет – это физические устройства (серверы, компьютеры, планшеты
и т.д.), связанные между собой в сеть. Любой сайт в Интернете находится на
физическом устройстве. Каждое устройство имеет свой уникальный номер –
IP-адрес вида 123.123.123.123.
DNS представляет собой распределенную службу с данными. В рамках
этой модели один сервер хранит данные для ресурсов, о которых знает именно
он, другой хранит данные для своего собственного набора устройств, между
этими серверами происходит обмен данными. Взаимодействие между клиентом
и сервером происходит по схеме «запрос–ответ».
По умолчанию запросы и ответы DNS-сервера отправляются по сети в
виде обычного текста. Это означает, что злоумышленник может перехватить
такие данные и выполнить перенаправление трафика пользователя в другое
4.1. ТИПОВЫЕ ОПЕРАЦИИ DNS
место назначения. Простые текстовые DNS-запросы также позволяют администраторам сети получать информацию о том, какие сайты посещают пользователи.
На рисунке 4.1 изображён процесс разрешения имени сервером DNS.
Приложение отправляет запрос локальному DNS-серверу (шаг 1), который затем перенаправит запрос рекурсивному DNS-серверу, пока тот не вернёт нужный ресурс доменного имени (шаги 2 – 4). DNS-запрос включает в себя имя и
тип запрашиваемой записи. Возвращаемый ответ представляет собой набор
«ресурсных записей», которые являются ответами на запрос (или, в качестве
альтернативы, ответами, указывающими на то, что имя и тип записи, которые
были запрошены, не существуют). DNS-запись возвращается на локальное устройство сервером рекурсивного поиска. После того, как браузер получает результаты запроса DNS, приложение может осуществить запрос данных у Webсервера (шаг 5).
DNS-трафик уязвим перед злоумышленниками, так как появляется возможность «прослушать» канал связи и перехватить незащищённые данные.
Интернет-провайдеры также могут осуществлять наблюдение за трафиком и
собирать данные о том, какие сайты посещают его клиенты.
Для защиты DNS-трафика были реализованы специальные протоколы
DNS over TLS (DoT) и DNS over HTTPS (DoH). Их основная задача – выполнять
шифрование DNS-трафика для предотвращения его перехвата и обеспечения
53
Рис. 4.1. Схема процесса разрешения имени DNS
дополнительной конфиденциальности и безопасности. Протокол DoT обеспечивает безопасность и даёт администраторам сетей больше контроля под трафиком, а протокол DoH обеспечивает конфиденциальность пользователей. Для
пользователей различия между протоколами DoH и DoT не заметны, но при
анализе трафика разница существенна.
В современных сетях используются протокол защиты транспортного
уровня (Transport Layer Security, TLS) для безопасного обмена данными, например, для просмотра Web-страниц, передачи файлов, VPN-подключений, сеансов
удалённого рабочего стола и передачи голосового трафика средствами
IP-телефонии. Одна сторона соединения, обычно сервер, имеет сертификат с
цифровой подписью, выданный доверенным центром сертификации. Другая
сторона соединения, обычно клиент, использует сертификаты для проверки того, с кем он обменивается данными.
54
4.2. СПОСОБЫ ШИФРОВАНИЯ DNS-ТРАФИКА
Рис. 4.2. Схема работы протокола DNS over TLS
На рисунке 4.2 показано, что DoT может функционировать подобно традиционному DNS (рис. 4.1) за исключением передачи данных через TCP-порт
853 в качестве метода для разрешения имён согласно RFC 7858. Оператор сети
может легко заблокировать трафик порта 853, чтобы предотвратить использование DoT в сети. Дальше будет показано, что DoT может функционировать
подобно традиционному DNS.
Поскольку протокол TLS уже широко используется для обеспечения конфиденциальности, аутентификации и целостности данных, расширение протокола для работы с DNS является вполне логичным. DNS поверх TLS (IETF RFC
7858) определяет, как DNS-пакеты будут шифроваться с помощью TLS и передаваться по широко используемому протоколу управления передачей TCP.
Данные протокола DNS передаются сервисами, задействующими номер
порта 53, по протоколу TCP или UDP. При использовании DNS поверх TLS все
зашифрованные пакеты отправляются через порт 853. Большинство общедоступных DNS-серверов, включая Cloudflare, Quad9 и Google, уже поддерживают
DNS поверх TLS, и компании, использующие собственную DNS-инфраструктуру, также могут использовать такое шифрование.
55
Рис. 4.3. Схема работы протокола DNS over HTTPS
Google включил поддержку DNS поверх TLS в Android Pie (Android 9),
чтобы пользователи могли настраивать шифрование DNS как для Wi-Fi-соединений, так и для мобильной сети, и многие приложения и устройства уже умеют работать с этой опцией.
DNS поверх HTTPS (IETF RFC8484) в значительной степени разработан с
оглядкой на принципы работы современного Интернета, поскольку он передаёт
данные внутри потока HTTPS вместе с другим зашифрованным Web-трафиком.
В отличие от своего конкурента, DNS поверх HTTPS не шифрует отдельные запросы, а вместо этого пропускает их через зашифрованный туннель между клиентом и сервером.
Поддержка DNS over HTTPS есть в браузере Mozilla Firefox для Windows,
Linux и Android. Кроме того, в репозиториях Ubuntu 18.04 есть прокси-сервер
dnss, позволяющий организовать проксирование DNS-запросов к DoH-серверу.
На рисунке 4.3 продемонстрирована работа протокола DoH. Браузер напрямую отправляет DNS-запрос публичному серверу (шаг 1). Публичный сервер запросит у сервера имен запись DNS (шаг 2) и возвратит эту информацию.
Как только браузер получит ответ DNS, он сможет получить доступ к Web-
56
серверу по IP-адресу (шаг 3). Процесс поиска DoH устраняет необходимость в
кеше DNS и локальном рекурсивном сервере. Это означает, что эти системные
процессы больше не будут регистрировать DNS-запрос для браузеров с поддержкой DoH.
4.2.1. ПЛЮСЫ И МИНУСЫ РЕАЛИЗАЦИЙ
Для сторонников конфиденциальности DNS через TLS недостаточно хорош, потому что любой, кто контролирует сеть, будет знать, что любая активность на 853-ем порту связана с этой реализацией DNS. Хотя наблюдатель не
будет знать фактическое содержание запроса, поскольку и ответ, и запрос зашифрованы, тот факт, что сетевой администратор или провайдер будут знать,
что существует такая активность, уже может привести к последствиям для
пользователя (в худшем случае этот порт может быть вообще закрыт). Хотя
DNS поверх TLS безопасен, он не так удобен с точки зрения конфиденциальности, как DNS поверх HTTPS.
Ещё один недостаток DNS поверх TLS заключается в том, что разработчикам программного обеспечения и производителям устройств необходимо
внести изменения, чтобы их приложения и оборудование поддерживали этот
протокол. И если такой поддержки нет, даже если указанный DNS-сервер может работать с таким шифрованием, оно не будет защищать данные пользователя.
Пользователь, использующий Web-браузер, поддерживающий протокол
DoH, автоматически получает возможность использования шифрования в этом
протоколе. DNS поверх HTTPS лишает любые третьи стороны – в том числе поставщиков интернет-услуг и правительственные учреждения – возможности
просматривать информацию о том, какие сайты посещает пользователь.
DNS-сервер – это приложение, предназначенное для ответов на DNSзапросы по соответствующему протоколу. Также DNS-сервером могут называть
хост, на котором запущено соответствующее приложение. Популярные DNSсерверы представлены в табл. 4.1.
У популярных производителей программного обеспечения, связанного с
защитой данных, есть собственные DNS-серверы: Comodo Secure DNS и Norton
ConnectSafe, цель которых – предоставление доступа к любым сайтам. Данные
4.3. ОТКРЫТЫЕ DNS-СЕРВЕРЫ
серверы поддерживают анонимное посещение сайтов. В таблице 4.2 представлены IP-адреса и особенности серверов.
57
4.1. Публичные DNS-серверы
Level
DNS.WATCH
Провайдер IP-адрес
Google DNS 8.8.8.8
8.8.4.4
OpenDNS 208.67.222.222
208.67.220.220
3 DNS 209.244.0.3
209.244.0.4
Yandex DNS 77.88.8.8
77.88.8.1
88.8.88
77.88.8.1
84.200.69.80
84.200.70.40
4.2. DNS-серверы популярного ПО
Провайдер IP-адрес Особенности
Comodo Secure DNS 8.26.56.26
8.20.247.20
Norton ConnectSafe
199.85.126.10
199.85.127.10
199.85.126.30
199.85.127.30
199.85.126.20
199.85.127.20
Фильтрация вредоносных сайтов
Стандартный уровень фильтрации
(фишинг сайты, вирусные сайты,
вредоносное ПО)
Родительский контроль
Продвинутый уровень защиты
которыми публичными поставщиками DNS. В таблице 4.3 предлагаются следующие DNS-серверы, реализующие DoT.
58
Реализация сервера DNS поверх TLS уже предоставляется бесплатно не-
Серверы, реализующие DNS поверх HTTPS, представлены в табл. 4.4.
4.3. Общедоступные DNS-серверы, реализующие DNS поверх TLS
Провайдер IP-адрес Фильтрация Особенности
Cloudflare 1.1.1.1
1.0.0.1
104.16.249.249
104.16.248.249
Google Public
DNS
8.8.8.8
8.8.4.4
Quad9 9.9.9.9
9.9.9.10
149.112.112.112
149.112.112.9
149.112.112.10
4.4. DNS поверх HTTPS – общедоступные DNS-серверы
Провайдер IP-адрес Фильтрация
Нет Порт 853
Нет Порт 853
Опасные домены Порт 853
Cloudflare 1.1.1.1
Нет
1.0.0.1
104.16.249.249
104.16.248.249
Google Public DNS 8.8.8.8
Нет
8.8.4.4
4.4. НАСТРОЙКА ZEEK
Следующим этапом в реализации системы обнаружения зашифрованного
трафика будет установка и настройка системы Zeek, предназначенной для мониторинга сети и выявления вторжений.
Перед установкой Zeek нужно будет убедиться, что некоторые зависимости установлены. Для установки необходимых зависимостей используется команда:
sudo apt-get install cmake make gcc g++ flex bison libpcap-dev libssl-dev
python-dev swig zlib1g-dev
Пакеты с зависимостями займут достаточно дискового пространства, поэтому перед установкой система запросит подтверждение выполнения операции, как показано на рис. 4.4.
59
Рис. 4.4. Предварительная установка зависимостей
После предварительных действий Zeek можно загрузить как в предвари-
тельно собранном бинарном пакете, так и в виде исходного кода. Двоичные установки на базе Linux обычно выполняются путём добавления информации о
пакетах Zeek в соответствующий инструмент упаковки системы. Затем для выполнения установки используются обычные системные утилиты, такие как apt,
dnf, yum или zypper. Основным установочным префиксом для бинарных пакетов
является либо /opt/bro, либо /opt/zeek (в зависимости от того, какая версия используется).
Для удобства пользователей релизы Zeek упакованы в пакеты исходных
текстов и доступны на странице скачивания. Кроме того, последнюю версию
для разработки Zeek можно получить через Git-репозитории, размещенные на
сайте https://github.com/zeek. Команда для загрузки исходного кода для Zeek через Git:
git clone --recursive https://github.com/zeek/zeek.
В данной работе установка Zeek осуществлялась через репозитории Git.
Процесс клонирования репозитория изображён на рис. 4.5.
Рисунок 4.5. Установка Zeek
60