Будучи загруженным, выполняет периодические проверки и уведомляет администратора о подозрительной активности. Тестировать tyton будем в Fedora 28, на ядре 4.19.4-200, для CentOS 8 установка должа быть аналогичной.

Установка и работа.

1. Для начала, ставим всё необходимое для сборки модуля:

# dnf install git kernel-devel gcc make libnotify libnotify-devel systemd-devel gtk3-devel gtk3

2. Забираем исходники для сборки и собираем:

# cd /usr/local/src/
# git clone https://github.com/nbulischeck/tyton.git
# cd tyton
# make

3. В случае успешной сборки, мы получим файл модуля tyton.ko. Запускаем его в работу, передав при этом параметр timeout=1 — параметр, который задаёт периодичность проверки в минутах.

# insmod /usr/local/src/tyton/tyton.ko timeout=1

При этом, в логе у нас появляются записи вида:

[ 76.782706] tyton: INFO: Inserting Module
[ 76.800993] tyton: INFO: Analyzing Module List
[ 76.814005] tyton: INFO: Analyzing Syscall Hooks
[ 77.096357] tyton: INFO: Analyzing Netfilter Hooks
[ 77.097650] tyton: INFO: Analyzing /proc File Operations
[ 77.110116] tyton: INFO: Analyzing /proc Inodes
[ 77.112172] tyton: INFO: Analyzing Interrupt Hooks

Проверка работы tyton.

Для проверки детекта руткита, я взял самый простой — reptile. Собрал его, вставил модуль, убедился что он работает, а затем заглянул в логи:

Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing Module List
Dec 01 11:29:12 rtkt kernel: tyton: ALERT: Module [reptile] hidden.
Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing Syscall Hooks
Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing Netfilter Hooks
Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing /proc File Operations
Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing /proc Inodes
Dec 01 11:29:12 rtkt kernel: tyton: INFO: Analyzing Interrupt Hooks

Проблемный модуль был определён:

Dec 01 11:29:12 rtkt kernel: tyton: ALERT: Module [reptile] hidden.

Помимо записи в логах, tyton умеет посылать и графические уведомления (там где это возможно).

Подробнее о проекте можно узнать на соответствующей Github странице и сайте. Проект из разряда «нужно последить за развитием», так что загляните, возможно вам покажется интересным.

А ещё, возможно, вам будет интересен проект LKRG.

Сообщение Tyton появились сначала на Записки админа.

Заметка обновлена 27.02.2020.

В рамках этой заметки, мы запустим в работу простой WireGuard VPN сервер и настроим подключение из Linux клиента к нему. Работать мы будем в CentOS 8, но инструкция вполне подойдёт и для других дистрибутивов, разве что пакетные менеджеры и репозитории будут отличаться.

Сервер wireguard.

Подготовка и установка.

1. Для начала, подключаем репозитории EPEL и RPMFusion Free. Cтавим доступные обновления и запускаем систему с новым ядром.

# dnf install epel-release
# dnf install https://download1.rpmfusion.org/free/el/rpmfusion-free-release-8.noarch.rpm
# dnf clean all; dnf update;
# reboot

2. Далее, ставим на сервер всё необходимое и собираем модуль для Wireguard. После, убеждаемся, что модуль запущен в работу:

# dnf install akmod-wireguard wireguard
# akmods --force
# modprobe wireguard && lsmod | grep wireguard

Вывод последней команды будет примерно таким:

# modprobe wireguard && lsmod | grep wireguard
wireguard 229376 0
ip6_udp_tunnel 16384 1 wireguard
udp_tunnel 16384 1 wireguard

Настройка сервера.

3. Генерируем ключи для клиента и сервера:

# mkdir ~/wireguard; cd ~/wireguard
# wg genkey | tee server_private_key | wg pubkey > server_public_key
# wg genkey | tee client_private_key | wg pubkey > client_public_key
# chmod 600 ./*_private_key

В результате, здесь мы получаем четыре файла — приватный и публичный ключ для сервера, и аналогичные для клиента, которым будем подключаться.

4. Создаём конфигурационный файл для сервера /etc/wireguard/wg0.conf со следующим содержимым:

[Interface]
Address = 10.8.0.1/24
PrivateKey = SERVER_PRIVATE_KEY
ListenPort = 35053

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Разумеется, вместо SERVER_PRIVATE_KEY и CLIENT_PUBLIC_KEY мы прописываем ключи, из созданных ранее файлов. Далее, комментарии по конфигу:

Address — адрес виртуального интерфейса wg0 на сервере.
ListenPort — порт, на котором будет работать VPN.
AllowedIPs — виртуальные IP клиентов, которые будут подключаться к нашему серверу.

При необходимости, мы можем так же указать параметры PostUp и PostDown — команды, которые будут выполнены при включении и отключении интерфейса.

5. Включаем форвардинг пакетов:

# cat /etc/sysctl.conf 
net.ipv4.ip_forward = 1
# sysctl -p

6. Настраиваем фаервол:

# firewall-cmd --permanent --zone=public --add-port=35053/udp
# firewall-cmd --permanent --zone=public --add-masquerade
# firewall-cmd --reload

7. Запускаем сервис в работу:

# systemctl enable wg-quick@wg0.service
# systemctl restart wg-quick@wg0.service

Клиент wireguard.

Пишем конфиг.

8. На основе сделанной настройки, пишем простой конфиг для клиента. Этот конфиг подойдёт и для десктопа, и для, например, android приложения:

[Interface]
Address = 10.8.0.2/24
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = SERVER_REAL_IP:35053
PersistentKeepalive = 20

В данном случае, вместо CLIENT_PRIVATE_KEY и SERVER_PUBLIC_KEY мы опять же, подставляем ключи, сгенерированные ранее, а вместо SERVER_REAL_IP прописываем IP адрес нашего сервера, на котором установлен VPN.

Wireguard и десктоп клиент.

— Создаём директорию /etc/wireguard, а в ней сохраняем наш конфигурационный файл под именем wg0-client.conf.
— Пробуем подключиться к серверу с помощью wg-quick:

# wg-quick up wg0-client

[#] ip link add wg0-client type wireguard
[#] wg setconf wg0-client /dev/fd/63
[#] ip address add 10.8.0.2/32 dev wg0-client
[#] ip link set mtu 1420 dev wg0-client
[#] ip link set wg0-client up
[#] mount `8.8.8.8' /etc/resolv.conf
[#] wg set wg0-client fwmark 35053
[#] ip -4 route add 0.0.0.0/0 dev wg0-client table 35053
[#] ip -4 rule add not fwmark 35053 table 35053
[#] ip -4 rule add table main suppress_prefixlength 0

Проверяем подключение, и если всё сделано верно, то весь наш трафик теперь будет проходить через VPN сервер.

Для отключения от VPN просто выполняем команду wg-quick down wg0-client:

# wg-quick down wg0-client

[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0-client
[#] umount /etc/resolv.conf

При необходимости, мы можем управлять сервисом через systemd:

# systemctl restart wg-quick@wg0-client.service

Wireguard на android.

Для использоания wireguard на android, достаточно скачать клиента из Play Market или из F-Droid репозитория, а для подключения просто выполнить импорт подготовленного wg конфига для клиента.

И, собственно, всё. Вот так, очень просто (куда проще чем тот же OpenVPN) мы можем настроить защищённый VPN туннель и использовать его в повседневной работе.

Дополнительно.

Быстрая установка.

wireguard-manager — инструмент для быстрой установки и настройки Wireguard на сервере.
wireguard-install — ещё одна реализация быстрого установщика.

Использование iptables.

Для случаев, когда в системе не оказывается firewalld (либо его не хочется ставить по какой-то причине), можно настроить обработку подключений с помощью iptables, для этого, конфиг на сервере нужно модифицировать так:

[Interface]
Address = 10.8.0.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 35053
PrivateKey = SERVER_PRIVATE_KEY

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

Несколько клиентов.

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

[Interface]
Address = 10.8.0.1/24
PrivateKey = SERVER_PRIVATE_KEY
ListenPort = 35053

[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.2/32

[Peer]
PublicKey = ANOTHER_CLIENT_PUBLIC_KEY
AllowedIPs = 10.8.0.3/32

Просто, для истории.

В дополнение — на видео ещё один пример быстрой настройки WireGuard, но уже вручную:

Сообщение WireGuard появились сначала на Записки админа.

Состоит Falco из двух частей — модуль ядра falco_probe, и непосредственно сам демон, который обрабатывает собранную информацию, генерирует отчёты и т. д. Настройка выполняется из нескольких .yaml файлов. Мы на Falco в рамках этой заметки посмотрим в CentOS 7.

Установка и базовая настройка.

Для установки, выполняем одну команду. В процессе, скрипт доустановит заголовки ядра, необходимые для сборки модуля пакеты, соберёт модуль ядра и запустит его в работу:

# curl -s https://s3.amazonaws.com/download.draios.com/stable/install-falco | sudo bash

Как только процесс будет завершён, убеждаемся что модуль работает:

# lsmod | grep falco
falco_probe 614337 0

Далее заглянем в основной конфигурационный файл — /etc/falco/falco.yaml Здесь мы можем указать какие файлы с правилами необходимо использовать при мониторинге, в каком формате выводить уведомления, куда выводить их и с каким приоритетом. По умолчанию, уведомления отправляются в stderr, stdout и syslog. Если мы хотим настроить запись уведомлений в отдельный лог, обращаем внимание на секцию:

file_output:
enabled: false
keep_alive: false
filename: ./events.txt

Для настройки уведомлений на email, спускаемся в нижнюю часть конфига и там находим соответствующую возможность:

program_output:
enabled: false
keep_alive: false
program: mail -s "Falco Notification" someone@example.com

Вносим нужные нам изменения, если это требуется, сохраняем файл. Для этой заметки я у себя ничего не менял, оставив дефолтные настройки.

Правила Sysdig Falco.

Посмотрим сразу на простой пример — правило, для мониторинга сетевой активности системных бинарников:

- rule: system_binaries_network_activity
  desc: network activity by system binaries that are not expected generate any network traffic
  condition: ((inbound or outbound) and (fd.sockfamily = ip)) and (fd.name != '')
  output: "Binary generate network traffic by (user=%user.name command=%proc.cmdline connection=%fd.name type=%evt.type)"
  priority: WARNING
  tags: [filesystem, network]

• Начинается правило с rule, далее указывается название, которое будет использоваться falco при обработке.
• desc — описание правила в свободной форме.
• condition — условие для срабатывания правила. Пишется с использованием синтаксиса sysdig.
• output — строка, которая будет записываться в лог.
• priority — приоритет для правила.
• tags — теги для правила.

О самом Sysdig я уже писал ранее, в отдельной заметке.

Мониторинг сетевой активности.

При установке Falco на сервер, в файле /etc/falco/falco_rules.yaml уже прописано некоторое количество правил, стоит заглянуть туда, прежде чем писать что-то своё. Наши кастомные правила мы будем записывать в /etc/falco/falco_rules.local.yaml.

Сохраним приведённое выше правило, перезапустим сервис:

# systemctl restart falco

Теперь просто пингуем любой домен, а затем проверяем /var/log/messages. Там у нас обнаружится следующее:

Oct 11 12:59:50 centos-2gb-hel1-1 falco: 12:59:50.343148030: Warning Binary generate network traffic by (user=root command=ping -c1 ya.ru connection=95.216.162.218:32820->213.133.98.98:53 type=connect)
Oct 11 12:59:50 centos-2gb-hel1-1 falco: 12:59:50.343197498: Warning Binary generate network traffic by (user=root command=ping -c1 ya.ru connection=95.216.162.218:32820->213.133.98.98:53 type=sendto)
Oct 11 12:59:50 centos-2gb-hel1-1 falco: 12:59:50.345198065: Warning Binary generate network traffic by (user=root command=ping -c1 ya.ru connection=95.216.162.218:32820->213.133.98.98:53 type=ioctl)
Oct 11 12:59:50 centos-2gb-hel1-1 falco: 12:59:50.345205363: Warning Binary generate network traffic by (user=root command=ping -c1 ya.ru connection=95.216.162.218:32820->213.133.98.98:53 type=recvfrom)

Мониторинг файловой системы.

В стандартном наборе правил добавлены условия, позволяющие выполнить мониторинг изменений в директории /etc:

- rule: Write below etc
  desc: an attempt to write to any file below /etc
  condition: write_etc_common
  output: "File below /etc opened for writing (user=%user.name command=%proc.cmdline parent=%proc.pname pcmdline=%proc.pcmdline file=%fd.name program=%proc.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4])"
  priority: ERROR
  tags: [filesystem]

Для проверки его работоспособности можно, например, модифицировать /etc/resolv.conf, а затем проверить /var/log/messages, где осядет запись:

Oct 11 13:16:46 centos-2gb-hel1-1 falco: 13:16:46.994403084: Error File below /etc opened for writing (user=root command=nano -w /etc/resolv.conf parent=bash pcmdline=bash file=/etc/resolv.conf program=nano gparent=sshd ggparent=sshd gggparent=systemd)
Oct 11 13:16:48 centos-2gb-hel1-1 falco: 13:16:48.967124902: Error File below /etc opened for writing (user=root command=nano -w /etc/resolv.conf parent=bash pcmdline=bash file=/etc/resolv.conf program=nano gparent=sshd ggparent=sshd gggparent=systemd)

Мониторинг работы в контейнере.

Для этой заметки я работаю на тестовом сервере, так что ставим Docker, и запускаем простой контейнер с CentOS:

# yum install docker
# systemctl restart docker
# docker pull centos

Возьмём приведённое выше правило, и немного модифицируем его, для мониторинга сетевой активности в контейнере:

- rule: system_binaries_network_activity_docker
  desc: network activity by system binaries that are not expected generate any network traffic in container
  condition: ((inbound or outbound) and (fd.sockfamily = ip)) and fd.name != '' and container
  output: "Binary generate network traffic from container %container.id by (user=%user.name command=%proc.cmdline connection=%fd.name type=%evt.type)"
  priority: WARNING
  tags: [container, network]

Добавим правило в /etc/falco/falco_rules.local.yaml, сохраним изменения, перезапустим сервис.

# systemctl restart falco

Теперь просто зайдём в контейнер, попингуем ya.ru и выйдем обратно в ОС на хосте.

# docker run --rm -it centos /bin/bash
[root@0a6ed013ee29 /]# ping -c1 ya.ru
...
[root@0a6ed013ee29 /]# exit
exit
#

В очередной раз проверим /var/log/messages, где по указанному нами правилу будут доступны предупрждения:

Oct 11 13:43:58 centos-2gb-hel1-1 falco: 13:43:58.887939368: Warning Binary generate network traffic from container 0a6ed013ee29 by (user=root command=ping -c1 ya.ru connection=172.17.0.2:49217->213.133.98.98:53 type=sendto)
Oct 11 13:43:58 centos-2gb-hel1-1 falco: 13:43:58.888361623: Warning Binary generate network traffic from container 0a6ed013ee29 by (user=root command=ping -c1 ya.ru connection=172.17.0.2:49217->213.133.98.98:53 type=ioctl)
Oct 11 13:43:58 centos-2gb-hel1-1 falco: 13:43:58.888382571: Warning Binary generate network traffic from container 0a6ed013ee29 by (user=root command=ping -c1 ya.ru connection=172.17.0.2:49217->213.133.98.98:53 type=recvfrom)

Вот так достаточно просто мы можем взять под контроль практически любое действие в системе, причём как на хосте, так и в контейнерах.

• Больше примеров и правил можно найти на соответствующей странице проекта.
• Ещё, очень рекомендую заглянуть на katacoda.com и пройти там короткий курс по работе в Sysdig Falco.
• Ещё несколько видео с примерами работы.

Сообщение Sysdig Falco появились сначала на Записки админа.

Проблема заключается в том, что к скрипту wp-admin/load-scripts.php, можно сформировать специальный запрос, в ответ на который скрипт вернёт большое количество данных. Соответственно, любой может взять какой-нибудь doser.py скрипт и сгенерировать им большое количество таких вот обращений.

Закрываем CVE-2018-6389.

Пока что, разработчики WordPress на данный момент не сочли проблему серьёзной, и нашедший уязвимость Barak Tawily сделал форк WP, где поправил проблему так, как счёл верным. Дополнительно, он подготовил BASH скрипт, который патчит текущую установку CMS. Минус применения такого скрипта в том, что внесённые им изменения, при обновлении WP могут быть удалены, так что вполне разумным здесь выглядит поиск другого решения, и оно было найдено — CVE-2018-6389 можно закрыть с помощью ModSecurity. Правило для модсека выглядит так:

SecRule REQUEST_URI "@rx (?i:/wp-admin/load-scripts.php?.*?(load%5B%5D|load\[\]|load%5B\]|load\[%5D)=([^&,]*,){20,})" "id:1,msg:'Potential use of CVE-2018-6389',deny"

Т. е. при попытке вызвать через скрипт load-scripts.php более 20 файлов, ModSecurity такой запрос заблокирует. Лимит в 20 файлов можно изменить на любое другое значение. Такой подход позволяет избежать проблем на сервере в случае, если кто-то решить воспользоваться уязвимостью и положить сайт на WP с её помощью.

О том как поставить ModSecurity на Nginx.
О найденной уязвимости, там же есть ссылки на все нужные скрипты.
О применении ModSecurity для защиты от CVE-2018-6389.

@SysadminNotes | https://sysadmin.pm

Сообщение Закрываем CVE-2018-6389 c помощью ModSecurity появились сначала на Записки админа.

Linux Kernel Runtime Guard.

На сайте для загрузки (на момент написания заметки) уже доступна версия 0.1, проект в разработке, так что на прод его тащить не стоит конечно же, но любопытства и интереса ради, в тестовом окружении его уже можно использовать. Перед использованием LKRG нужно сразу же прояснить некоторые моменты:

• LKRG — не волшебная таблетка и не панацея от всего. Тесты показали что например, попытки эксплуатации CVE-2017-5123 и CVE-2017-6074 были обнаружены, но в то же время, CVE-2016-5195 (Dirty COW) сработал и детектирован не был. Так что возможность использования эксплойтов, нацеленных на юзерспейс всё же остаётся.
• В данный момент замечено, что использование LKRG может понизить производительность системы примерно на 6.5%. В этом ключе предстоит ещё много работы. На сколько такая просадка окажется критичной, каждый решает для себя сам. Думаю что для тестовых стендов это не такое уж и страшное число.

Из положительного у нас есть вот что:

• Непосредственно защита ядра от атак на него нацеленных. Потенциально — защита в том числе и от неизвестных пока что эксплойтов (целенаправленно не пытающихся LKRG обойти).
• Поддержка популярных операционных систем. Заявлены в данный момент RHEL7, Ubuntu 16.04 и даже OpenVZ 7, Virtuozzo 7.
• Простота установки и использования. LKRG собирется и ставится как модуль ядра, а не патч, что значительно упрощает работу с ним.

Установка и запуск LKRG.

1. Не является обязательным требованием, но для меня выглядит вполне логичным — обновляем ядро до последней актуальной версии доступной в репозиториях, запускаем сервер в работу с ним.

2. Для сборки потребуются make и C компилятор. Кроме того, ставим в систему -devel пакеты ядра (команда в зависимости от ОС):

# yum install kernel-devel

$ sudo apt-get install linux-headers-$(uname -r)

3. Собираем сам модуль. Его можно либо скачать в архиве, либо забрать c Github’а (сделаем так):

# cd /usr/local/src/
# git clone https://bitbucket.org/Adam_pi3/lkrg-main.git
# cd lkrg-main/
# make -j8

4. И запускаем его в работу как и любой другой модуль ядра:

# insmod output/p_lkrg.ko p_init_log_level=3

В системном логе, при этом, осядет следующая информация:

Feb 9 08:39:49 pm kernel: p_lkrg: loading out-of-tree module taints kernel.
Feb 9 08:39:49 pm kernel: p_lkrg: module verification failed: signature and/or required key missing - tainting kernel
Feb 9 08:39:49 pm kernel: [p_lkrg] Loading LKRG...
Feb 9 08:39:49 pm kernel: [p_lkrg] LKRG initialized successfully!
Feb 9 08:40:04 pm kernel: [p_lkrg] System is clean!
Feb 9 08:40:19 pm kernel: [p_lkrg] System is clean!

Теперь, с учётом настроенного log level, система будет сообщать в лог о том, что с ней всё в порядке сообщением «System is clean!»

Настройки для LKRG.

С загрузкой модуля, в sysctl у нас появляются несколько параметров, которыми мы можем управлять:

# sysctl -a | grep lkrg
lkrg.block_modules = 0
lkrg.clean_message = 1
lkrg.force_run = 0
lkrg.hide = 0
lkrg.log_level = 3
lkrg.timestamp = 15

lkrg.block_modules — блокировать (1), или не блокировать (0) загрузку модулей в ядро.
lkrg.clean_message — выводить ли сообщение «System is clean», если значение log_level позволяет это делать.
lkrg.force_run — при передаче сюда единицы, будет произведён запуск проверки целостности. Функция проверки будет запущена, при этом, значение будет вновь изменено на 0.
lkrg.log_level — уровень детализации логов, которые ведёт LKRG.
lkrg.timestamp — частота вызова функции целостности в секундах. Сюда можно передать значение от 5 до 1800.
lkrg.hide — механизм сокрытия модуля в системе. О нём немного подробнее ниже.

Скрываем LKRG.

С помощью параметра lkrg.hide мы можем скрыть присутствие модуля в системе, выглядит это так:

# lsmod | grep lkrg
p_lkrg 122402 0 
# sysctl lkrg.hide=1
lkrg.hide = 1
# lsmod | grep lkrg
#
# sysctl lkrg.hide=0
lkrg.hide = 0
# lsmod | grep lkrg
p_lkrg 122402 -2 
#

Важный момент здесь — допустим модуль был скрыт, а нам потребовалось выгрузить его. Перед выгрузкой необходимо сделать unhide, а затем уже отключить сам модуль с опцией —force:

# sysctl lkrg.hide=0
lkrg.hide = 0
# lsmod | grep lkrg
p_lkrg 122402 -2 
# rmmod --force p_lkrg

О загрузке, выгрузке модуля в логе будут оставаться соответствующие сообщения:

Feb 9 09:42:10 pm kernel: [p_lkrg] Unloading LKRG...
Feb 9 09:42:10 pm kernel: [p_lkrg] LKRG unloaded!
Feb 9 09:42:20 pm kernel: [p_lkrg] Loading LKRG...
Feb 9 09:42:20 pm kernel: [p_lkrg] LKRG initialized successfully!

Обнаружение эксплойта.

О попытках применения эксплойтов, ядро нам так же будет сообщать, например вот так:

Feb 9 10:09:38 tst kernel: traps: p_write8[20820] general protection ip:400dd0 sp:7f018cc05f00 error:0 in p_write8[400000+2000]
Feb 9 10:09:38 tst kernel: [1026127.772356] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different UID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772365] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different EUID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772368] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different SUID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772370] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different FSUID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772372] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different GID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772374] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different EGID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772376] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different SGID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772378] [p_lkrg] <Exploit Detection> process[19633 | procrop] has different FSGID! [504 vs 0 :(
Feb 9 10:09:38 tst kernel: [1026127.772380] [p_lkrg] <Exploit Detection> Trying to kill process[procrop | 19633]!19633

Кроме того, если система была скомпрометирована до загрузки модуля и это будет обнаружено, при запуске LKRG сообщит об этом.

Промежуточный итог.

На этом, пока что, можно остановиться. Что в итоге? Linux Kernel Runtime Guard оставляю работать на одном из своих серверов, где размещены несколько сайтов и сервисов. Посмотрим как он покажет себя в дальнейшем, ну и за самим проектом, конечно же буду следить, а по возможности пополнять заметку дополнительным материалом.

@SysadminNotes | https://sysadmin.pm

Сообщение Linux Kernel Runtime Guard появились сначала на Записки админа.

Virusgotal.

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

# wget https://github.com/moldabekov/virusgotal/releases/download/v.1.0.1/virusgotal-linux-amd64.zip
# unzip virusgotal-linux-amd64.zip
# mv virusgotal-linux-amd64 /usr/local/sbin/virusgotal

Для работы нам потребуется API ключ, его мы получаем в настройках профиля, после регистрации на virustotal.com. Экспортируем ключ в переменные окружения:

# export VT_API_KEY=a1b13825344ae124ffe4eab5236564d8744ab7541e6ef5d5fa809bdfc32ac93b

И отправляем файл на проверку:

# virusgotal file my-test-file 

Your file was submitted and scan was queued. Here are details:
sha256 hash: a54f75458a65651a9636108e433d1b734b140838cb9757f1eaebd1f309b7811
VirusTotal link: https://www.virustotal.com/file/a54f75458a65651a9636108e433d1b734b140838cb9757f1eaebd1f309b7811/analysis/1516784675/

Для получения результатов мы можем пройти по ссылке, а можем просто проверить статус сканирования по хешу:

# virusgotal hash a54f75458a65651a9636108e433d1b734b140838cb9757f1eaebd1f309b7811

Scan with given hash is still in progress

Через некоторое время статус изменится:

# virusgotal hash a54f75458a65651a9636108e433d1b734b140838cb9757f1eaebd1f309b7811

Given hash is KNOWN by VirusTotal and has no positive results
Direct link: https://www.virustotal.com/file/a54f75458a65651a9636108e433d1b734b140838cb9757f1eaebd1f309b7811/analysis/1516784675/

Вот так просто и быстро мы можем проверить нужный нам файл прямо на сервере, без загрузки его на ПК, в браузер и т. п.

Меня справедливо дополняют, что у утилиты есть дополнительные ключи для запуска, которые значительно упрощают жизнь. Так например, проверять файл по хешу не обязательно, можно просто выполнить его повторную проверку, утилита сама посчитает хеш и выдст результат по нему. Если файл хочется перепроверить, то нужно запустить virusgotal с параметром --force.

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

@SysadminNotes | https://sysadmin.pm

Сообщение Virusgotal появились сначала на Записки админа.