Здравствуй, уважаемый читатель моего блога!
Сегодня я расскажу о своём небольшом проекте автоматизации оповещения администратора безопасности при попытках подключения незарегистрированных носителей информации к информационной системе без выхода в сеть «Интернет».
Начнём с того, что ограничение использования личных носителей информации — это фундамент защиты информации. Если каждый сотрудник может скопировать на рабочий компьютер принесённый из дома файл, а ещё хуже — вынести его за пределы организации, дело совсем плохо.
Именно поэтому во всех защищённых программных продуктах (будь то защищённая операционная система, антивирусная программа корпоративного уровня или специализированное средство защиты информации) есть соответствующий функционал.
Так как мой проект работает в операционной системе Astra Linux 1.7, рассказывать буду применительно к ней.
По умолчанию администратор данной системы входит в группу floppy, которая позволяет монтировать носители информации без ограничений.
В свою очередь, пользователи, не входящие в эту группу, подчиняются правилам udev, которые генерируются с помощью утилиты fly-admin-smc.
Кроме того, в составе операционной системы есть утилита astra-mount-lock, которая запрещает монтирование съемных носителей с помощью службы fly-reflex-service / fly-admin-reflex непривилегированным пользователям.
Работают эти механизмы достаточно надёжно и со временем избалованные вседозволенностью пользователи (если до этого мероприятия по защите информации в организации не выполнялись) перестают пытаться подключать к компьютерам личные технические средства.
К слову сказать, важно не только технически запретить осуществлять противоправные действия, но и подкрепить этот запрет разработанным регламентом организации.
Далее остаётся только контролировать выполнение регламента, своевременно выявлять попытки его нарушить и наказывать нарушителей.
Для оперативного выявления таких попыток и создана моя автоматизация.
К слову сказать, вариантов решения этой задачи бесчисленное множество, и каждый из Вас может реализовать эту задачу по-своему.
Я же показываю, как это реализовано у меня.
На компьютере пользователя в каталоге /etc/udev/rules.d/ создано правило 60-flash.rules:
ENV{DEVTYPE}=="disk", ENV{ID_BUS}"=="usb", ACTION=="add", OPTIONS+="event_timeout=3600", RUN+="/bin/bash -c '/etc/udev/scripts/flash.sh %E{ID_SERIAL_SHORT} %E{ID_SERIAL}'"
Суть правила проста – при подключении usb устройств выполняется скрипт flash.sh, размещённый в каталоге /etc/udev/scripts/:
#!/bin/bash
serial="$1"
model="$2"
user="$(who | awk '{print $1}' | sort -u | xargs echo $x)"
host=$(hostname)
logger "USB connect+$host+$user+$model+$serial"
Переменная serial – это серийный номер устройства, model – его модель, user – логин пользователей, работающих за ПЭВМ, host – наименование ПЭВМ.
Получив эти значения, команда logger отправляет их в syslog-ng.
В свою очередь в каталоге /etc/syslog-ng/conf.d/ размещен конфигурационный файл flash.conf со следующим содержимым:
filter usb_flash { message('USB connect.*'); };
destination d_security_server { udp("192.168.12.88" port(514) log_fifo_size(1000)); };
log { source(s_src); filter(usb_flash); destination(d_security_server); };
Здесь так же всё просто, первая строка отбирает сообщения, начинающиеся на USB connect (как и отправляет logger из скрипта).
Вторая строка указывает сервер назначения.
Третья строка указывает, что отобранные сообщения нужно отправить на сервер безопасности.
Собственно, на компьютере пользователя это всё.
Далее рассмотрим конфигурацию сервера безопасности, она немного интересней.
На сервере у меня пока используется Astra Linux 1.6.12 с rsyslog, поэтому правило отбора поступающих сообщений хранится в /etc/rsyslog.d/ и выглядит так:
40-flash.conf:
if ($msg contains 'USB connect') then /var/spool/flash
/var/spool/flash – это FIFO (именованный каналы), который создаётся соответствующей службой в systemd (/etc/systemd/system/flash.socket):
[Unit]
Description=flash
Requires=flash.service
[Socket]
ListenFIFO=/var/spool/flash
SocketMode=0600
[Install]
WantedBy=sockets.target
Данный канал использует одноимённая служба flash.service, которая соединяет поступающие строки лога со стандартным вводом скрипта:
[Unit]
Description=flash
Requires=flash.socket
[Service]
ExecStart=/opt/scripts/flash.sh
StandardInput=socket
[Install]
WantedBy=multi-user.target
Ну и осталось разобрать сам скрипт /opt/scripts/flash.sh, который выполняет обработку:
#!/bin/bash
cache=''
function control {
log="$1"
serial=$(echo $log | awk -F+ '{print $5}')
user=$(echo $log | awk -F+ '{print $3}')
model=$(echo $log | awk -F+ '{print $4}')
host=$(echo $log | awk -F+ '{print $2}')
data=$(echo $log | awk '{print $1" "$2" "$3}')
if [[ "$cache" != "$log" ]] && [[ $serial != '' ]] && ! grep $serial <<< $(cat /etc/udev/scripts/flash_serial)
then
message="Факт НСД. Подключен незарегистрированный МНИ к компьютеру $host.\nДата и время подключения - $data.\nРаботают пользователи - $user.\nМодель $model, серийный номер $serial."
/opt/sendmsg/send-server.py marukhin@ipa1.domain "$(echo -e "$message")"
echo -e "$message" | mutt -s "Факт НСД" -- marukhin_ipa@domain
cache="$log"
fi
}
while true
do
read line
control "$line"
done
В нижней части скрипта бесконечный цикл – при поступлении входных данных от rsyslog запускается функция control.
Данная функция “парсит” входной лог и проверяет условия.
Первое условие – это проверка на дубликат сообщения, для этого используется переменная cache – в ней хранится предыдущий обработанный лог.
Второе условие – проверка наличия серийного номера.
Третье условие – отсутствие серийного номера в списке разрешённых устройств (как отметил один из читателей ранее я не пояснил, что список данных устройств размещён в /etc/udev/scripts/flash_serial – каждая строка, новый серийный номер разрешённого устройства).
Если все условия выполняются, администратору отправляется уведомление.
В моём примере уведомления отправляются на xmpp клиент и адрес электронной почты – но на самом деле всё ограничивается Вашим воображением.
Так как сеть изолирована, о telegram уведомлении нет и речи, но при желании можно подать звуковой сигнал (запустив аудиофайл через cvlc), включить красную лампу тревоги или произвести звонок на номер телефона (если используется IP телефония).
В конце функции лог сохраняется в переменной cache.
Ну и в виде заключения расскажу историю из практики, когда этот скрипт позволил выявить нарушителя. В общем, работал я за компьютером, и тут появляется сообщение о подключении запрещённого устройства (устройство было нашей организации, но из другой изолированной сети, поэтому в списке разрешенных отсутствовало). Сразу пошёл к компьютеру из сообщения — по горячим следам, так сказать.
Захожу в кабинет, а там два сотрудника, один из которых из моего отдела (недавно пришёл). С его слов его ввели в заблуждение.
Как говорится,главное при проведении расследования – не выйти на самих себя. Провели повторный инструктаж – сработались.
На этой хорошей ноте я прощаюсь с Вами, до новых встреч!
Прошу прощения, по-моему тут неточность..
Вначале шла речь о скрипте flash.sh, размещённом в каталоге /etc/udev/scripts/, затем появляется скрипт с таким же названием: /opt/scripts/flash.sh, внутри которого читается некий файл /etc/udev/scripts/flash_serial, который вроде бы нигде не создается..
Видимо flash_serial – файл, в который как-то автоматически заносятся серийные номера зарегистрированных флэшек.. Этот момент не освещен..
И еще вопросик..
Можно ли таким образом организовать сбор логов на локальной машине с Астрой 1.7.6 в виде, например, /var/log/flash.log?
Спасибо!
Здравствуйте! По тексту я рассказываю сначала о скрипте flash.sh размещённом на компьютере пользователя (рабочая станция), а потом разбираю, как настроен сервер (который отвечает за анализ поступающих данных о подключении носителей). То есть второй flash.sh находится на сервере. Касательно списка устройств – Вы правы, сейчас добавлю описание).
По поводу сбора логов подключений на локальной машине – конечно можно.
destination local_usb { file(“/var/log/usb.log”); };
log { source(s_src); filter(usb_flash); destination(local_usb); };