Ни для кого не является секретом, что любая информационная система требует адекватного обслуживания. В контекст обслуживания непременно входят такие операции как мониторинг и реагирование на различные события. Для реализации подобных задач существуют специальные инструменты, часто это громоздкие, неповоротливые и прожорливые системы мониторинга, работающие чаще всего по принципу клиент-серверных приложений, но при том отнимающие большие вычислительные ресурсы. Кроме того, стандартные классические системы мониторинга и реагирования почти никогда невозможно использовать в целях более деликатных, например для более скрытного наблюдения за различными событиями в системе и их обработки. Вполне возможно, в ограниченных задачах, использовать подобные, но на практике гораздо более простые, эффективные и элегантные решения, либо их комплексы.
Итак, представим один из таких примеров.
В данной статье будет рассматриваться конфигурация двух хостов на основе и под управлением операционной системы linux.
Первый хост представляет собой машину, за которой осуществляется мониторинг с целью реагирования на определенные, интересующие нас события в файловой системе, информация о которых передается на второй хост, который и осуществляет дальнейшие действия, связанные с реагированием. Мониторингом событий на первом хосте будет заниматься программа incron, а формированием и отправкой запроса на второй хост - клиентская утилита knock из прикладного пакета knockd, предназначенного для осуществления процесса сетевого "простукивания"(кнокинга) сетевых портов. Второй хост осуществляет собственное реагирование по запросу от первого хоста и инициирует сбор информации с первого хоста в ответ на события. Мониторинг и реагиование на втором хосте реализованы посредством вышеупомянутой системы knockd, только уже ее серверной части, а сбор информации по событию вторым хостом на первом - занимается программа-сетевой сниффер tcpdump через автоматически устанавливаемое соединение ssh. Автоматизацией некоторых операций по использованию утилит будет заниматься оболочка bash и ее одноименный скриптовый язык.
Давайте очень коротко и тезисно разберем перечень используемых средств (комплексный набор утилит), с целью понимания того, что, как и зачем мы делаем, а также как именно все это работает:
1) Incron (в нашем случае установлена работает только на первом хосте) - это прикладное приложение, функционирующее на основе подсистемы inotify ядра linux, которая, в свою очередь позволяет получать уведомления об изменениях в файловой подсистеме. Простыми словами, эта подсистемы выдает информацию о создании, изменении и удалении любого файла, используемого файловой системой, в том числе и директории. Так как в рамках операционной системы linux и в контексте ее файловой системы действует неизменная до сих пор концепция: "все есть файл", к ним относятся в том числе и все виды специальных файлов. Сама же утилита incron это оболчка-обертка inotify, которая выполняет установленную команду в случае наступлении ожидаемого в заданной конфигурации заданием события, аналогично тому, как делает это система cron, но только реагируя по времени. Более подробно о данном инструменте читайте официальную документацию.
2) Knockd (установлена на оба хоста, но в качестве сервера работает только на втором узле) - это система, которая предоставляет механизм реагирования на сформированную по заранее определенным конфигурацией правилам и параметрам комбинацию сетевых пакетов, посылаемых клиентом приложения на сетевой интерфейс сервера, который эти последовательности перехватывает, интерпретирует и реагирует, выполняет определенные действия. Вобщем, примерно то же самое, что делает incron, только в отличие от файловой системы, здесь в качестве триггера используется сетевой трафик. Подробности, опять таки-можно найти в документации и руководствах к данной утилите.
3) Tcpdump - это, собственно, известный сетевой сниффер, и в его более подробном предствалении необходимости нет. Если кому-то интересны подробности, лучше также обратиться к официальной документации. Чтобы не раздувать материал.
Вобщем, с описанием инструментов закончили, теперь приступим непосредственно к реализации. Далее по тексту нашей статьи, я выкладываю готовую конфигурацию и очень коротко даю необходимые пояснения, с возможными альтернативными вариантами, там, где это необходимо и имеет смысл.
Настройки первого хоста (тоесть контролируемого сервера, о котором шла речь выше по тексту статьи в общем описании конфигурации ):
Разрешаем пользователю root использовать сервис incron:
echo root >>/etc/incron.allow
Редактируем конфигурацию службы incron:
incrontab -e:
Файл конфигурации incron:
Пояснения по сноскам:
№1 - сервисом incron ведется наблюдение за содержимым директории /run/systemd/sessions на предмет создания в нем любых файлов. В данной директории система создает файлы сессий некоторых основных сетевых служб. Если в каталоге был создан файл (директива IN_CREATE), то система автоматически выполняет скрипт test_knock.sh, передавая ему в качестве двух аргументов две переменные: слово create, а также специальную комбинацию: $@/$#. Эта комбинация состоит из двух внутренних переменных: $@ - что означает наблюдаемый путь, содержащий абсолютный путь до отслеживаемой директории, а также специальной переменной $#, обозначающей сам объект наблюдения. Коротко, если будет создан некоторый объект(файл), его имя будет содаржаться в указанной переменной.
#2 - это второе правило конфигурационного файла incron, делающее примерно то же самое что первое, за исключением того, что реагирование происходит в ответ на другой триггер, - удаление какого-либо объекта в наблюдаемой директории (директива IN_DELETE). И тут передается иная переменная в качестве первого параметра - delete.
Ну и в качестве небольшого дополнения приведу таблицу с основными триггерами файловой системы, которые возможно использовать в системе incron:
Все что отмечено символом (.) точка - относится непосредственно к параметру-имени файла наблюдения, но в пределах наблюдаемой директории.
Перечень специальных внутренних переменных системы incron:
Содержание bash-скрипта test_knock.sh:
Пояснения по сноскам:
№1 - проверяем количество аргументов, переданных скрипту test_knock.sh. И если их число равно 2, то скрипт продолжает выплнение
№2 - проверяем первый параметр, содаржащийся в аргументе $1 на соответствие ключевому слову create, передавая управление в соответствии с результатом
№3 - проверяем при помощи манипуляций и фильтров в рамках оболочки bash созданный файл сессии на предмет его отношения к службе rdp (проверка на соответствие ключевому слову xrdp), тоесть фактически на предмет подключения к данной системе клиента rdp
№4 - если все условия проверки выше пройдены и удовлетворены, то выполняется клиентская программа knock, осуществляющая отправку/отстук указанных в качестве параметров комбинаций сетевых пакетов на второй хост. параметр -d 5 указывает на временную задержку между отправками сформированных пакетов.
№5 - точно также как в сноске 2, производится проверка на соответствие первого аргумента, но уже другому ключевому слову - delete. Если условие выполняется, то происходит переход к запуску команды knock ( сноска №6 )
№6 - проверка, такая же как в пункте №3, и производимая с той же целью.
№7 - аналогично пункту #4, правда последовательность отправляемых пакетов иная. Будьте внимательны.
Настройки второго хоста (тоесть контролирующего сервера мониторинга, о котором также шла речь выше по тексту):
Редактируем файл:
vi /etc/default/knockd
И приводим указанный ниже параметр к такому виду:
START_KNOCKD=1
Это настойка автузапуска данной службы по умолчанию.
Далее, правим(или дополняем) основной файл конфигурации сервера knockd:
Блок конфигурации файла knockd.conf:
Пояснения по сноскам:
№1 - последовательность, которую ожидает сервер программы knockd
№2 - время таймаута между пакетами ожидаемой последовательности. Соответствует параметру -d 5 указанному в клиентской команде knock первого хоста.
№3 - команда иницирования в ответ на реакцию соответствия пришедшей последовательности в сноске №1, которая будет запущена в случае получения ожидаемой последовательности. Если чуть подробнее, когда на удаленном сервере запускается любая rdp сессия(пример протокола выбран случайно), его incron отстукивает на второй хост, и служба knockd второго хоята запускает локальный bash-скрипт session_dump.sh, который запускается на удаленном, первом хосте через созданное с ним соединение ssh, а вот результат выполнения этого скрипта будет будет перенаправлен опять таки в локально созданный на втором хосте файл sessions.log.
№4 - другая последопательность, которая приходит с первого хоста в случае разрыва ранее установленной rdp сессии
№5 - выполняется команда, инициированная последовательностью в пункте №4. Как вы могли догадаться, это команда завершения процесса ssh, установленного ранее. Проверка ведется командой pidof.
Да, в статье этот момент не обозначен, но для корректной автоматической работы по установлению подключения по ssh созданию сессии, нужно заведомо позаботиться о создании и обмене ключами между первым и вторым хостом.
Содержание bash-скрипта session_dump.sh:
Пояснения по сноскам:
№1 - запуск процесса перехвата сетевого трафика посредством tcpdump, производимая вторым хостом, но через установленное в соответствиями с описанными ранее правилами соединение ssh между первым и вторым хостом. В качестве примера мы использовали правило перехвата всего сетевого трафика, относящегося к протоколам http, https, ssh и rdp. Пример как и в случае с установлением триггера на подключение по rdp к первому хосту - взят совершенно случайным образом.
Ну вот и подошло время подведения итогов. Если обобщить все сделанное нами выше, то с использованием отдельных утилит в систем linux была организована комплексная система реагирования на события/сигнатуры в файловой системе и в сетевом трафике, создаваемые случайным образом, либо генерируемые по другим условиям. Целенаправленно были опущены(но не упущены) многие(или почти все) вопросы обеспечения безопасности создаваемой инфраструктуры, как не были рассмотрены другие второстепенные настройки и вопросы. Так как вцелом статья имеет совершенно иную цель - научиться и научить искать и применять в некоторых случаях более простые и эфективные инструменты для выполнения сложных и нетривиальных задач, нежели использовать сложные и дорогостоящие во всех смыслах разработки для решения простых вопросов. Для чего и как это может пригодиться именно в вашем случае, пусть каждый уже решает для себя самостоятельно.
Спасибо за внимание.
Автор nmap.
Написано специально для xss.pro.
Итак, представим один из таких примеров.
В данной статье будет рассматриваться конфигурация двух хостов на основе и под управлением операционной системы linux.
Первый хост представляет собой машину, за которой осуществляется мониторинг с целью реагирования на определенные, интересующие нас события в файловой системе, информация о которых передается на второй хост, который и осуществляет дальнейшие действия, связанные с реагированием. Мониторингом событий на первом хосте будет заниматься программа incron, а формированием и отправкой запроса на второй хост - клиентская утилита knock из прикладного пакета knockd, предназначенного для осуществления процесса сетевого "простукивания"(кнокинга) сетевых портов. Второй хост осуществляет собственное реагирование по запросу от первого хоста и инициирует сбор информации с первого хоста в ответ на события. Мониторинг и реагиование на втором хосте реализованы посредством вышеупомянутой системы knockd, только уже ее серверной части, а сбор информации по событию вторым хостом на первом - занимается программа-сетевой сниффер tcpdump через автоматически устанавливаемое соединение ssh. Автоматизацией некоторых операций по использованию утилит будет заниматься оболочка bash и ее одноименный скриптовый язык.
Давайте очень коротко и тезисно разберем перечень используемых средств (комплексный набор утилит), с целью понимания того, что, как и зачем мы делаем, а также как именно все это работает:
1) Incron (в нашем случае установлена работает только на первом хосте) - это прикладное приложение, функционирующее на основе подсистемы inotify ядра linux, которая, в свою очередь позволяет получать уведомления об изменениях в файловой подсистеме. Простыми словами, эта подсистемы выдает информацию о создании, изменении и удалении любого файла, используемого файловой системой, в том числе и директории. Так как в рамках операционной системы linux и в контексте ее файловой системы действует неизменная до сих пор концепция: "все есть файл", к ним относятся в том числе и все виды специальных файлов. Сама же утилита incron это оболчка-обертка inotify, которая выполняет установленную команду в случае наступлении ожидаемого в заданной конфигурации заданием события, аналогично тому, как делает это система cron, но только реагируя по времени. Более подробно о данном инструменте читайте официальную документацию.
2) Knockd (установлена на оба хоста, но в качестве сервера работает только на втором узле) - это система, которая предоставляет механизм реагирования на сформированную по заранее определенным конфигурацией правилам и параметрам комбинацию сетевых пакетов, посылаемых клиентом приложения на сетевой интерфейс сервера, который эти последовательности перехватывает, интерпретирует и реагирует, выполняет определенные действия. Вобщем, примерно то же самое, что делает incron, только в отличие от файловой системы, здесь в качестве триггера используется сетевой трафик. Подробности, опять таки-можно найти в документации и руководствах к данной утилите.
3) Tcpdump - это, собственно, известный сетевой сниффер, и в его более подробном предствалении необходимости нет. Если кому-то интересны подробности, лучше также обратиться к официальной документации. Чтобы не раздувать материал.
Вобщем, с описанием инструментов закончили, теперь приступим непосредственно к реализации. Далее по тексту нашей статьи, я выкладываю готовую конфигурацию и очень коротко даю необходимые пояснения, с возможными альтернативными вариантами, там, где это необходимо и имеет смысл.
Настройки первого хоста (тоесть контролируемого сервера, о котором шла речь выше по тексту статьи в общем описании конфигурации ):
Разрешаем пользователю root использовать сервис incron:
echo root >>/etc/incron.allow
Редактируем конфигурацию службы incron:
incrontab -e:
Файл конфигурации incron:
Пояснения по сноскам:
№1 - сервисом incron ведется наблюдение за содержимым директории /run/systemd/sessions на предмет создания в нем любых файлов. В данной директории система создает файлы сессий некоторых основных сетевых служб. Если в каталоге был создан файл (директива IN_CREATE), то система автоматически выполняет скрипт test_knock.sh, передавая ему в качестве двух аргументов две переменные: слово create, а также специальную комбинацию: $@/$#. Эта комбинация состоит из двух внутренних переменных: $@ - что означает наблюдаемый путь, содержащий абсолютный путь до отслеживаемой директории, а также специальной переменной $#, обозначающей сам объект наблюдения. Коротко, если будет создан некоторый объект(файл), его имя будет содаржаться в указанной переменной.
#2 - это второе правило конфигурационного файла incron, делающее примерно то же самое что первое, за исключением того, что реагирование происходит в ответ на другой триггер, - удаление какого-либо объекта в наблюдаемой директории (директива IN_DELETE). И тут передается иная переменная в качестве первого параметра - delete.
Ну и в качестве небольшого дополнения приведу таблицу с основными триггерами файловой системы, которые возможно использовать в системе incron:
Все что отмечено символом (.) точка - относится непосредственно к параметру-имени файла наблюдения, но в пределах наблюдаемой директории.
Перечень специальных внутренних переменных системы incron:
Содержание bash-скрипта test_knock.sh:
Пояснения по сноскам:
№1 - проверяем количество аргументов, переданных скрипту test_knock.sh. И если их число равно 2, то скрипт продолжает выплнение
№2 - проверяем первый параметр, содаржащийся в аргументе $1 на соответствие ключевому слову create, передавая управление в соответствии с результатом
№3 - проверяем при помощи манипуляций и фильтров в рамках оболочки bash созданный файл сессии на предмет его отношения к службе rdp (проверка на соответствие ключевому слову xrdp), тоесть фактически на предмет подключения к данной системе клиента rdp
№4 - если все условия проверки выше пройдены и удовлетворены, то выполняется клиентская программа knock, осуществляющая отправку/отстук указанных в качестве параметров комбинаций сетевых пакетов на второй хост. параметр -d 5 указывает на временную задержку между отправками сформированных пакетов.
№5 - точно также как в сноске 2, производится проверка на соответствие первого аргумента, но уже другому ключевому слову - delete. Если условие выполняется, то происходит переход к запуску команды knock ( сноска №6 )
№6 - проверка, такая же как в пункте №3, и производимая с той же целью.
№7 - аналогично пункту #4, правда последовательность отправляемых пакетов иная. Будьте внимательны.
Настройки второго хоста (тоесть контролирующего сервера мониторинга, о котором также шла речь выше по тексту):
Редактируем файл:
vi /etc/default/knockd
И приводим указанный ниже параметр к такому виду:
START_KNOCKD=1
Это настойка автузапуска данной службы по умолчанию.
Далее, правим(или дополняем) основной файл конфигурации сервера knockd:
Блок конфигурации файла knockd.conf:
Пояснения по сноскам:
№1 - последовательность, которую ожидает сервер программы knockd
№2 - время таймаута между пакетами ожидаемой последовательности. Соответствует параметру -d 5 указанному в клиентской команде knock первого хоста.
№3 - команда иницирования в ответ на реакцию соответствия пришедшей последовательности в сноске №1, которая будет запущена в случае получения ожидаемой последовательности. Если чуть подробнее, когда на удаленном сервере запускается любая rdp сессия(пример протокола выбран случайно), его incron отстукивает на второй хост, и служба knockd второго хоята запускает локальный bash-скрипт session_dump.sh, который запускается на удаленном, первом хосте через созданное с ним соединение ssh, а вот результат выполнения этого скрипта будет будет перенаправлен опять таки в локально созданный на втором хосте файл sessions.log.
№4 - другая последопательность, которая приходит с первого хоста в случае разрыва ранее установленной rdp сессии
№5 - выполняется команда, инициированная последовательностью в пункте №4. Как вы могли догадаться, это команда завершения процесса ssh, установленного ранее. Проверка ведется командой pidof.
Да, в статье этот момент не обозначен, но для корректной автоматической работы по установлению подключения по ssh созданию сессии, нужно заведомо позаботиться о создании и обмене ключами между первым и вторым хостом.
Содержание bash-скрипта session_dump.sh:
Пояснения по сноскам:
№1 - запуск процесса перехвата сетевого трафика посредством tcpdump, производимая вторым хостом, но через установленное в соответствиями с описанными ранее правилами соединение ssh между первым и вторым хостом. В качестве примера мы использовали правило перехвата всего сетевого трафика, относящегося к протоколам http, https, ssh и rdp. Пример как и в случае с установлением триггера на подключение по rdp к первому хосту - взят совершенно случайным образом.
Ну вот и подошло время подведения итогов. Если обобщить все сделанное нами выше, то с использованием отдельных утилит в систем linux была организована комплексная система реагирования на события/сигнатуры в файловой системе и в сетевом трафике, создаваемые случайным образом, либо генерируемые по другим условиям. Целенаправленно были опущены(но не упущены) многие(или почти все) вопросы обеспечения безопасности создаваемой инфраструктуры, как не были рассмотрены другие второстепенные настройки и вопросы. Так как вцелом статья имеет совершенно иную цель - научиться и научить искать и применять в некоторых случаях более простые и эфективные инструменты для выполнения сложных и нетривиальных задач, нежели использовать сложные и дорогостоящие во всех смыслах разработки для решения простых вопросов. Для чего и как это может пригодиться именно в вашем случае, пусть каждый уже решает для себя самостоятельно.
Спасибо за внимание.
Автор nmap.
Написано специально для xss.pro.
Последнее редактирование модератором: