Некоторые приложения (неизвестно) делают спорадические нерегулярные редкие короткие исходящие HTTP(S) запросы к известному хосту/порту/url (это WAF honeypot, хост/url/порт известны) с использованием протокола HTTPS. Запросы могут происходить раз в 3-5 дней. Это буквально один короткий запрос в 3-5 дней. Цель состоит в том, чтобы определить, какое приложение (путь к двоичному файлу, PID и т. д.) делает эти запросы. На сервере установлено множество программного обеспечения, включая nginx
, php
, mariadb
, redis
, docker
и т. д.
Для простоты IP-адрес приманки здесь будет иметь вид 7.7.7.7.
Что я пробовал до сих пор:
- tcpdump
$ sudo tcpdump -i any dst host 7.7.7.7 and "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) == 0" &> /tmp/out_7.7.7.7_$(date "+%Y.%m.%d-%H.%M.%S").log &
Похоже, он tcpdump
не позволяет определить идентификатор процесса или исполняемого файла, который выполняет исходящие http-запросы.
- аудитctl/auditd
sudo auditctl -a exit,always -F arch=b64 -S connect -k connectLog
auditctl/auditd
кажется, может выводить путь и pid, но у него нет функции фильтрации. Если я запущу правило аудита на 3-5 дней, мой диск будет заполнен журналом аудита. Или, если журналы аудита ротируются, я могу пропустить необходимые данные журнала в файле журнала, который уже ротируется и удаляется. Если auditctl
бы была функция фильтрации при записи (не при анализе журналов) по целевому IP, это, вероятно, был бы лучшим кандидатом. Может быть, я что-то упускаю и у него есть функция фильтрации?
Другой вариант, который я придумал, — это создать некий bash-скрипт, который:
- начал аудит
connect
- начал процесс мониторинга следующим образом:
( tail -f -n0 /var/log/audit/audit.log & ) | grep -q "7.7.7.7"
- как только монитор обнаружит это, прекратите аудит
auditctl -d...
Проблема в том, что это событие может произойти через 3–5 дней, когда все диски будут заполнены.
- нетстат
$ sudo netstat -tupnc | grep 7.7.7.7
Кажется, что netstat
с -c
опцией (continuos) повторяет чтение каждую 1 секунду. Поскольку запросы очень короткие, он мог пропустить этот запрос.
- SS
ss
похоже, не отображается процесс, инициировавший исходящее соединение.
- lsof
lsof -i TCP:80,443 -r 1
Исходящее соединение очень короткое и быстрое, его можно не регистрировать, запуская lsof каждую секунду.
wireshark Wireshark обладает хорошими функциями фильтрации (по IP), но, похоже, он не отображает имя процесса-инициатора соединения или pid.
В настоящее время я застрял с решением: объединить
syslog-ng
(с возможностью фильтрации при получении журналов через TCP/сеть) в качестве получателя иauditd
отправителя событий журнала. Мне удалось начатьsyslog-ng
с порта 2222, получая данные из сети и фильтруя их по некоторой строке (проверено с помощьюcurl
). Но я не могу управлятьauditd
отправкой журналов в сеть.
Что я наделал:
7.1) Установлено audisp-remote-plugin
:
$ sudo apt install audispd-plugins
7.2) Включено audisp-remote plugin
:
в файле /etc/audit/plugins.d/au-remote.conf
: наборactive = yes
7.3) Настроенный audisp-remote
плагин:
в файле /etc/audit/auditsp-remote.conf
:
remote_server = 127.0.0.1
port = 2222
7.4) Отключена запись в локальный log_file
в файле /etc/audit/auditd.conf
:
write_logs = no
и перезапустил Auditd:
$ sudo systemctl restart auditd
7.5) Добавлено правило аудита для перехвата соединений ( connect
системных вызовов):
$ sudo auditctl -a exit,always -F arch=b64 -F saddr_fam=2 -S connect -k sckt
7.6) Ротация журналов для очистки предыдущих данных в auditd
журналах
$ service auditd rotate
7.7) Сделан тестовый HTTP-вызов:
$ curl -v https://7.7.7.7/api/v1/t
7.8) Проверил syslog-ng
журнал, но в нем нет ожидаемых записей.
Если кто-то знает наиболее подходящий, легкий и простой способ сделать это, любая помощь будет оценена по достоинству!
решение1
Вероятно, вы могли бы загрузить журнал аудита, используя исходный файл в syslog-ng, а затем использовать относительно короткое время хранения для журналов аудита.
Благодаря этому вы можете применить фильтрацию на стороне syslog-ng и вывести интересные записи в отдельный файл журнала.