Статья Обеспечение безопасности некоторых аспектов Linux системы посредством нестандартного мониторинга сети сервера

[Admin]

Обеспечение безопасности некоторых аспектов Linux системы посредством нестандартного мониторинга сети сервера​

И снова здравствуйте, уважаемые форумчане! На этот раз, в качестве небольшого отступления от основного курса из массива статей по реализации защищенных VPN инфраструктур, было принято решение представить отдельную статью, демонстрирующую гибкие возможности некоторых технологий, способных практически из коробки и без лишних трудозатрат обеспечить весьма серьезный уровень безопасности даже специалистам подготовленным на среднем уровне и без дополнительных навыков в области разработки

Многие специалисты не понаслышке знают и понимают, что практически любая информационная система нуждается в качественном и своевременном обслуживании. В этот процесс обязательно включены такие действия, как защита, мониторинг и оперативное реагирование на различные события, в первую очередь аварийные либо критическим образом влияющие на основные бизнес-процессы. Для этих целей разработаны специальные инструменты. Обычно это громоздкие и ресурсоёмкие системы мониторинга, построенные по модели клиент-сервер, которые требуют значительных вычислительных мощностей. При этом классические системы мониторинга и реагирования расчитанные главным образом на большие и масштабированные инфраструктуры нередко плохо подходят для более тонких и легковесных задач, например, для незаметного наблюдения за событиями и их обработки. В первую очередь по причине своей сложности и как было выше обозначено, избыточного ресурсопотребления. Поэтому в ряде ограниченных случаев можно применять более простые, эффективные и изящные решения и их самые разные, в том числе нестандартные и элегантные комбинации.Попробуем же представить практический пример в одном из возможных вариантов

В этой статье мы с вами рассмотрим настройку двуххостовой конфигурации и традиционно на базе операционной системы linux. Первый узел(сервер) в представленной схеме выполняет мониторинг файловой системы, отслеживая интересующие события, реагируя ни них в соответствие с установленной конфигурацией, и, в случае возникновения передаёт информацию о них на второй узел. На первом сервере мониторинг указанных событий ведёт программа incron основанная на механизме inotify, а отправку уведомлений на второй серверный хост осуществляет клиентская часть утилиты knock из программного пакета knockd, предназначенного для сетевого кнокинга (простукивания) портов. Второй же хост, принимая такие запросы от первого, в качестве реакции на поступающие уведомления о событиях реагирует на них и инициирует сбор информации с первого узла. Для этого на втором хосте используется серверная часть knockd, а сбор данных с первого хоста по сети выполняет программа tcpdump путем сниффинга трафика через автоматически устанавливаемое соединение ssh. Автоматизация работы всех утилит в процессе функционирования схемы реализована с помощью возможностей скриптового языка оболочки bash в контексте linux


Вот так выглядит взаимодействие в нашей нехитрой двухузловой связке. Теперь давайте максимально кратко и по пунктам перечислим и опишем используемые в нашем решении средства и инструмент, для чтобы иметь общее понимание того, как все это устроено и работает:


1. tcpdump - пожалуй самый известный и наиболее часто используемый в среде linux сетевой сниффер для захвата и анализа трафика. Чтобы не перегружать текст, скажу лишь что очень много подробной информации о его использовании и возможностях можно узнать как из официальных источников проекта разработки, так и в многочисленных статьях в сети Интернет. В нашем случае сниффер размещен на втором хосте схемы

2. knockd - это клиент-серверная система, реагирующая на специальные последовательности сетевых пакетов, которые клиент посылает серверу. Сервер перехватывает пакеты, интерпретирует и выполняет заранее определенные настройками действия. Функционирует аналогично программе incron, но вместо событий файловой системы триггером служит сетевой трафик и его параметры и особенности. Подробности точно так же можете найти в документации knockd. Установлена программ на обоих хостах, но серверная часть работает только на втором узле

3. incron(Inotify) - приложение, использующее подсистему inotify ядра операционной системы linux, которая оповещает об изменениях в файловой системе, таких как создании, изменении и удалении файлов и директорий. Так как согласно архитектурной политике linux в системе "всё является файлом", то это касается и специальных типов файлов, таких как конвееры, сетевые и файловые сокеты, файлы устройств, итд, соответственно область применения данного механизма с использованием указанной утилиты весьма широк. Incron выступает прикладной оболочкой для inotify и выполняет заданные настройками команды при наступлении событий, подобно cron, но триггером здесь служат практически любые изменения в файловой системе и которые мы с вами рассмотрим далее. Установлен соответственно он только на первом узле

Все три инструмента хорошо дополняют друг друга, обеспечивая мониторинг, передачу и реагирование как на уровне файловой системы, так и сетевого взаимодействия. Но мы с вами на данный момент не учитывали другую сторону нашей инфраструктуры и важную часть конфигурации призванную обеспечить должный уровень безопасности. Для этого нам потребуется еще пара инструментов:

4. iptables - понятное дело что все кто имел дело с системами linux в любом исполнении и назначении почти наверняка сталкивался с ее штатным файерволом, дополнительных пояснений здесь не нужно. С его помощью мы будем оборонять нашу сетевую часть схемы
5. fail2ban - разумеется, нам с вами понадобится банальный инструмент защиты от не менее банальных попыток создать отказ в обслуживании. В данном случае, для наглядности и простоты, его использование будет наиболее приемлемым и логичным


Настройки первого хоста который является контролируемым сервером и о котором велась речь выше по тексту статьи в общем описании. Адрес сервера делаем таким: 192.168.10.1, ssh сервер при этом размещаем на нестандартном порту, к примеру 44222.

Необходимо разрешить пользователю root использовать сервис incron:
# echo root >>/etc/incron.allow

Редактируем конфигурацию службы incron следующим образом:
# incrontab -e:

Содержимое файла конфигурации incron:

/run/systemd/sessions           IN_CREATE        /home/user/knocking.sh create $@/$#      №1
/run/systemd/sessions           IN_DELETE        /home/user/knocking.sh delete $@/$#      №2

Пояснения по сноскам:

№1 Сервис incron в перманентом режите отслеживает появление любых файлов в директории /run/systemd/sessions. В этой папке система в процессе работы создаёт файлы сессий ключевых сетевых служб. При создании в данной директории файла (IN_CREATE) автоматически запускается скрипт knocking.sh, которому передаются два аргумента: слово create и комбинация $@/$#

Данная комбинация состоит из двух внутренних переменных:

$@ - абсолютный путь к отслеживаемой директории
$# - имя объекта наблюдения

То есть, при появлении файла его имя передаётся в скрипт через указанную переменную

№2 второе правило конфигурационного файла incron, похожее на первое и делающее примерно то же самое, за исключением того, что его срабатывание происходит в ответ на другой триггер, который задействуется при удалении какого-либо объекта файловой системы в наблюдаемой директории (ответственна директива IN_DELETE). И тут передается другая переменная в качестве первого параметра - delete


Ну и в качестве небольшого дополнения приведу таблицу с основными триггерами файловой системы, которые возможно использовать в системе incron:

IN_OPEN открытие файла
IN_CLOSE_WRITE закрытие файла, ранее открытого для записи
IN_CLOSE_NOWRITE закрытие файла без записи
IN_MODIFY изменение файлы
IN_DELETE удаление файла
IN_MOVE_SELF перемещение файла или директории
IN_MOVED_FROM перемещение файла из наблюдаемой директории
IN_CREATE создание файла в наблюдаемой директории
IN_ACCESS получение доступа к файлу (чтение)
IN_ATTRIB изменение служебных данных-метаданных объекта
IN_MOVED_TO перемещение объекта в наблюдаемый контекст (директорию)
IN_DELETE_SELF удаление наблюдаемого файла или директории

Перечень специальных внутренних переменных системы incron:

$& код события в виде числа
$% наблюдаемое событие - в текстовом виде
$$ собственный символ доллара, тип экранирования
$@ наблюдаемый абсолютный путь - чаще директория в качестве контекста
$# имя файла, напрямую связанное с событием


Содержание bash-скрипта knocking.sh:

#!/bin/bash

if [[ $# -eq 2 ]]; then           # №1
if [[ $1 = create ]]; then    # №2
if [[ $(ps -eo comm,pid -A | grep $(fuser $2 | sed -e "s/\s.* \([0-9].*\)$/\1\n/g") | cut -d ' ' -f -1) = xrdp ]]; then  # №3
knock -d 5 192.168.10.2 21411:tcp 31235:tcp 43123:tcp 15476:tcp   # №4
else
fi
elif [[ $1 = delete ]]; then  # №5
if [[ $(ps -eo comm,pid -A | grep $(fuser $2 | sed -e "s/\s.* \([0-9].*\)$/\1\n/g") | cut -d ' ' -f -1) = xrdp ]]; then  # №6
knock -d 5 192.168.10.2 23556:tcp 16321:tcp 43123:tcp 13426:tcp   # №7
else
fi
else
fi
exit (0)

Пояснения по сноскам в скрипте:

№1 В начале скрипт knocking.sh проверяет, что ему передано ровно два аргумента. Если условие выполнено, скрипт продолжает работу
№2 Затем первый аргумент $1 сверяется на совпадение с ключевым словом create, и в зависимости от результата управление передаётся далее
№3 При помощи bash фильтров анализируется имя созданного файла сессии с целью определить, связано ли имя со службой rdp (в нашем случае проверка на ключевое слово xrdp), то есть производится ли инициирование сессии через rdp клиент
№4 Если все проверки пройдены, запускается клиентская программа knock, которая отправляет заданные сетевые пакеты на удалённый хост. Параметр -d 5 задаёт паузу в 5 секунд между пакетами
№5 Так же, как в пункте №2, проверяется первый аргумент скрипта, но теперь на совпадение с ключевым словом delete. При совпадении инициируется выполнение команды knock (смотри пункт №6)
№6 Тут повторяется проверка файла по аналогии с пунктом №3, с той же целью выявить удаление сессии rdp
№7 Затем запускается команда knock, аналогично пункту №4, однако последовательность отправляемых пакетов отличается. При настроке будьте внимательны


Настройки второго хоста, тоесть контролирующего сервера мониторинга, о котором также шла речь выше по тексту. Адрес сервера делаем таким: 192.168.10.2, ssh сервер при этом размещаем на нестандартном порту, так же 44222.


Редактируем файл:
# vi /etc/default/knockd


И приводим указанный ниже параметр к такому виду:
START_KNOCKD=1
Это настойка автузапуска данной службы. Не везде она включена по умолчанию


Далее, правим(или дополняем) основной файл конфигурации сервера knockd:

Блок конфигурации файла knockd.conf:

[SSH_start_service]
sequence = 21411:tcp 31235:tcp 43123:tcp 15476:tcp      #№1
seq_timeout = 5                                         #№2
tcpflags = syn
command = /usr/bin/ssh -p 44222 [email protected] < /home/monitoring/copy_sessions.sh > /home/user_monitor/sessions.log   #№3

[SSH_stop_service]
sequence = 23556:tcp 16321:tcp 43123:tcp 13426:tcp      #№4
seq_timeout = 5
tcpflags = syn
command = /usr/bin/killall $(pidof xrdp)                #№5

Пояснения по сноскам:

[SSH_start_service] и [SSH_stop_service] - разные последовательности портов для запуска и завершения ssh сессии

№1 Пакеты посылаются на указанные порты TCP в заданной последовательности. И данная конкретная строка указывает на последовательность, которую ожидает сервер knockd от клиента
№2 Время задержки между отправкой пакетов в последовательности, соответствует параметру -d 5 в команде knock на первом хосте. А tcpflags = syn в следующей строке указывает на то, что для простукивания используется пакет с флагом syn сегмента tcp
№3 Команда, запуск которой происходит при получении ожидаемой последовательности (в сноске №1). При старте rdp сессии на удалённом сервере incron посылает сигнал второму хосту, где knockd с помощью ssh сессии запускает скрипт sessins.sh через созданное с ним соединение ssh на первом хосте(не забываем про нестандартный ssh порт: 44222). Результат выполнения скрипта сохраняется опять таки локально на втором хосте в файле sessions.log
№4 Последовательность, которая приходит с первого хоста в случае разрыва ранее установленной rdp сессии
№5 Команда, вызываемая при получении последовательности описанной в пункте №4. Как вы могли догадаться, это команда завершения процесса ssh, установленного ранее. Проверка ведется посредством команды pidof

Важное замечание:

Для корректной работы автоматического подключения по ssh и создания сессии не забываем предварительно произвести безопасный обмен ключами между двумя хостами.

Например таким образом:

# ssh-copy-id -i ~/.ssh/pub_key.pub user@server
Параметры доступа - пользователя и адрес сервера разумеется следует использовать актуальные.

Содержание bash скрипта copy_sessions.sh:

#!/bin/bash
tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and (port 25 or port 80 or port 443 or port 44222 or port 3389)'  #№1

Это скрипт на bash, который запускает утилиту tcpdump для захвата tcp пакетов с установленными флагами syn или ack

Пояснения по сноскам:

№1 строка запуска процесса перехвата сетевого трафика с помощью tcpdump, выполняемая вторым хостом, но через установленное в соответствиями с описанными ранее правилами соединение ssh между первым и вторым хостом. В качестве примера мы использовали правило перехвата всего сетевого трафика, относящегося к протоколам smtp, http, https, ssh(на нестандартном порту) и rdp. Пример как и в случае с установлением триггера на подключение по rdp к первому хосту взят совершенно случайным образом


Отдельно опишем настройки безопасности для каждого из двух серверов.


Давайте приведем конфигурацию к такому виду, чтобы каждый из наших двух серверов имел доступ к сети исключительно в том конткесте который ему необходим в части взаимодействия как внутри схемы, так и с внешним миром. Итак, исходя из выполненных нами ранее настроек, мы с вами может составить список используемых хостами портов. Давайте это сделаем:

На первом сервере должны быть открыты следующие tcp порты:
44222, 25, 80, 443, 3389

А на втором сервере дожны быть открыты такие tcp порты:
44222, 21411, 31235, 43123, 15476, 23556, 16321, 43123, 13426

Разумеется мы перечислили только те порты, которые должны быть открыты только на вход в узел со стороны сети Интернет. Потому как политику исходящих соединений в нашем случае мы оставим как открытую по умолчанию, так как каждый их узлов может выступать произвольным клиентом. Политику по умолчанию для входящих соединений мы сделаем как запрещенную по умолчанию для всего, кроме явно разрешенных исключений в виде вышеприведенного перечня открытых портов. Любой транзитный трафик так же по дефолту запретим.

Политики fail2ban:

На первом сервере:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
bantime = 1d
findtime = 600
maxretry = 5
backend = systemd
usedns = warn
loglevel = INFO
logtarget = /var/log/fail2ban.log

[PORTS-ACCEPT-ATEMPTS]
enabled = true
logpath = /var/log/fail2ban.log
backend = systemd
filter = recidive
action = iptables-multiport[name=PORTS-ACCEPT-ATEMPTS, port="44222 25 80 443 3389", protocol=tcp]
bantime = 1d
findtime = 1d
maxretry = 5

Задаем конфигурацию на втором сервере:
Код:Скопировать в буфер обмена

[DEFAULT]
ignoreip = 127.0.0.1/8
bantime  = 1d
findtime = 600
maxretry = 5
backend  = systemd
usedns   = warn
loglevel = info
logtarget = /var/log/fail2ban.log

[PORTS-ACCEPT-ATEMPTS]
enabled  = true
logpath  = /var/log/fail2ban.log
backend  = systemd
filter   = recidive
action   = iptables-multiport[name=PORTS-ACCEPT-ATEMPTS, port="44222 21411 31235 43123 15476 23556 16321 13426", protocol=tcp]
bantime  = 1d
findtime = 600
maxretry = 5

Основная суть правил fail2ban заключается в процессе анализа fail2ban файлов журналов, ведущихся в нашем случае файелволом iptables, выявляющим установленные конфигурацией аномалии, с целью обнаружения совпадений и принятия мер по блокированию аномального трафика. Соответственно критерии аномальности выбираются и закладываются самим пользователем системы. Как вы уже наверное догадались, основной параметр у нас action, который при обнаружении записи в логах применяет установленное правило iptables-multiport, блокируя сразу целую группу портов.

Политики iptables:

На первом сервере:

#Сбрасываем цепочки и чистим правила
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -t nat -X

# Политики файервола по умолчанию
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Перечень портов
ALLOWED_PORTS="44222 25 80 443 3389"

# Разрешаем обратную петлю на узле
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Разрешаем обмен данными для уже установленных соединений
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Блокируем поврежденные пакеты
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP

# Отработка аномальной сетевой активности и помещаем в логи fail2ban те пакеты, которые удовлятворяют условиям аномальности.
iptables -N f2b-PORTS-ACCEPT-ATEMPTS
iptables -A INPUT -p tcp -m multiport --dports ALLOWED_PORTS -m conntrack --ctstate NEW -m hashlimit \
--hashlimit-name f2b-PORTS-ACCEPT-ATEMPTS --hashlimit 20/min --hashlimit-burst 40 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports ALLOWED_PORTS -m conntrack --ctstate NEW -m hashlimit \
--hashlimit-name f2b-PORTS-ACCEPT-ATEMPTS --hashlimit-above 20/min --hashlimit-burst 40 \
-j LOG --log-prefix "[PORTS-ACCEPT-ATEMPTS]" --log-level 4

Настройки второго сервера:

#Сбрасываем цепочки и чистим правила
iptables -F
iptables -X
iptables -Z
iptables -t nat -F
iptables -t nat -X

# Политики файервола по умолчанию
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Перечень портов
ALLOWED_PORTS="44222 21411 31235 43123 15476 23556 16321 13426"

# Разрешаем обратную петлю на узле
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Разрешаем обмен данными для уже установленных соединений
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Блокируем поврежденные пакеты
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP

# Отработка аномальной сетевой активности и помещаем в логи fail2ban те пакеты, которые удовлятворяют условиям аномальности.
iptables -N f2b-PORTS-ACCEPT-ATEMPTS
iptables -A INPUT -p tcp -m multiport --dports ALLOWED_PORTS -m conntrack --ctstate NEW -m hashlimit \
--hashlimit-name f2b-PORTS-ACCEPT-ATEMPTS --hashlimit 20/min --hashlimit-burst 40 -j ACCEPT
iptables -A INPUT -p tcp -m multiport --dports ALLOWED_PORTS -m conntrack --ctstate NEW -m hashlimit \
--hashlimit-name f2b-PORTS-ACCEPT-ATEMPTS --hashlimit-above 20/min --hashlimit-burst 40 \
-j LOG --log-prefix "[PORTS-ACCEPT-ATEMPTS]" --log-level 4

Тут все просто, стандартная настройка файервола, что не так трудно интерпретировать исходя из самих правил. Но ключевым моментом пожалуй можно обозначить то, что данное правило логирует попытки установления новых tcp соединений к тем портам, которые перечислены в переменной ALLOWED_PORTS. Но при этом запись логов происходит только в том случае, если частота таких попыток превышает пороги hashlimit (более 20 попыток в минуту, с максимальным порогом кратковременного пика до 40 одновременных совпадений, что-то типа диапазона порогов). Правило не блокирует трафик напрямую, а предназначено для аудита и дальнейшего использования fail2ban через парсинг и анализ журналов.

Итоги

Вот и пришло время подводить итоги. Если обобщить все проделанное нами выше, то с использованием отдельных готовых утилит в системах linux была организована комплексная цепь реагирования на динамически возникающие события файловой системы и сетевого трафика, причем либо создаваемые случайным образом, либо генерируемые по определенным условиям. Целенаправленно, но отдельно были рассмотрены некоторые вопросы обеспечения безопасности создаванной нами инфраструктуры с целью демонстрации их широких и гибких возможностей в рамках построения подобных схем, при этом не были учтены некоторые другие, второстепенные вопросы о которых будет рассказано в общей канве VPN тематики представляемой мной в серии статей посвященной конкретно данному вопросу. Цель данной статьи имеет совершенно иную задачу, а именно научиться и научить искать и применять в некоторых случаях более простые и эфективные инструменты для выполнения сложных и нетривиальных задач, нежели использовать сложные и дорогостоящие во всех смыслах разработки для решения вопросов различной степени сложности. Для чего и как это может пригодиться именно в вашем случае, пусть каждый уже решает для себя самостоятельно.


Спасибо за внимание-)