Вопрос или проблема
Просматривая трафик в Wireshark, я заметил, что мой компьютер отправляет UDP пакет каждые три секунды на широковещательный адрес на порт 8765 с содержимым “*” (42 в ASCII). Это, похоже, не ответ ни на что. Исходный порт меняется с каждым пакетом.
Я попытался выяснить, что генерирует этот пакет, но безуспешно. Я пытался:
- Остановить все непостоянные службы, которые мог вспомнить.
- Добавить правило iptables для сброса пакетов (это остановило пакеты, но не помогло мне узнать, что их генерирует).
- Добавить правило iptables для остановки пересылки, чтобы проверить, не пересылается ли он каким-то образом моим компьютером, но нет.
- Использовать auditd с различными параметрами, но ничего не совпало, и я даже не смог найти
write(*,*,1)/send(*,*,1)/sendto(*,*,1,*,*)/sendmsg/sendmmsgс нужной частотой. Я, однако, не знаком с auditd.auditctl -a exit,always -F arch=b64 -S socket -F a0=2 -F a1=2для поиска создания IPv4 UDP сокетов.auditctl -a exit,always -F arch=b64 -S connectпросто для поиска любых соединений.auditctl -a exit,always -F arch=b64 -S write -S send -S sendto -F a2=1для совпаденияsendиwriteсистемных вызовов с длиной 1.audictl -a exit,always -F arch=b64 -S sendmsg -S sendmmsg- Все вышеперечисленное с
-F arch=b32вместо этого.
- Использовать netstat/ss, но сокет, вероятно, живет очень недолго, поэтому ничего не отображается.
Какие есть другие способы выяснить, что передает этот пакет? Что если это происходит из ядра или модуля ядра? Как я мог бы это узнать?
Много способов сделать это.
Я обычно использую bpftrace, копирую один из скриптов из /usr/share/bpftrace/tools, например, killsnoop.bt, и заменяю tracepoint:syscalls:sys_enter_kill на соответствующие системные вызовы, sys_enter_sendmsg и …_sendmmsg.
Тогда это становится чем-то вроде этого
#!/usr/bin/env bpftrace
BEGIN
{
printf("Отслеживание sendto(x, x, 1, x, x) сигналов... Нажмите Ctrl-C, чтобы закончить.\n");
printf("%-9s %-6s %-16s\n", "TIME", "PID", "COMM");
}
tracepoint:syscalls:sys_enter_sendto
{
if (args->len == 1)
{
time("%H:%M:%S ");
printf("%-6d %-16s\n", pid, comm);
}
}
что, по крайней мере, будет перечислять все вызовы sendmsg и аналогичные в реальном времени, что, вероятно, достаточно для идентификации того, кто что делает.
Если нет системных вызовов, которые отправляют сообщения, вероятно, это поток ядра – возможно, вы занимаетесь wireguard, SMB/CIFS, NFS/sunrpc в ядре и забыли об этом? Большой кандидат, также: сомнительные модули “безопасности конечной точки” от сомнительных антивирусных поставщиков.
Ответ или решение
Для определения источника широковещательного UDP-пакета, отправляемого на порт 8765 с содержимым "*", следует рассмотреть несколько методов, которые могут помочь вам в этой задаче.
1. Анализ системных вызовов с помощью bpftrace
Как уже упомянуто, использование инструмента bpftrace может оказаться очень полезным для отслеживания системных вызовов. Вы можете создать скрипт для мониторинга вызовов sendto, sendmsg и других, что позволит вам увидеть, какие процессы инициируют отправку пакетов. Вот пример скрипта, который можно модифицировать для ваших нужд:
#!/usr/bin/env bpftrace
BEGIN
{
printf("Отслеживание sendto(x, x, 1, x, x)... Нажмите Ctrl-C для завершения.\n");
printf("%-9s %-6s %-16s\n", "ВРЕМЯ", "PID", "COMM");
}
tracepoint:syscalls:sys_enter_sendto
{
if (args->len == 1)
{
time("%H:%M:%S ");
printf("%-6d %-16s\n", pid, comm);
}
}Этот скрипт будет выводить информацию о процессе, который осуществляет отправку пакетов, включая идентификатор процесса (PID) и имя команды (COMM).
2. Использование strace для мониторинга процессов
Если вы подозреваете, что один из процессов инициирует отправку пакетов, вы можете использовать strace, чтобы отслеживать системные вызовы для отдельных процессов. Запустите strace на процессе, который, как вы предполагаете, может быть источником.
strace -e trace=network -p <PID>Эта команда будет выводить сетевые системные вызовы, что возвратит больше данных о том, что конкретно происходит.
3. Проверьте на наличие ядровых модулей
Если пакеты отправляются из ядра или модуля ядра, это может быть сложнее отследить, так как они могут не вызывать системные вызовы, которые вы обычно отслеживаете. Чтобы проверить это, выполните следующие действия:
-
Проверьте загруженные модули ядра с помощью команды
lsmod. Это может помочь найти сомнительные модули, которые могли быть установлены с целью мониторинга или вмешательства в сетевой трафик. -
Просмотрите сообщения ядра через
dmesgили такие инструменты, какjournalctl, на предмет любых сообщений, которые могут указать на сетевые активности со стороны модулей ядра.
4. Используйте tcpdump для подробного анализа
Использование tcpdump может дать более глубокий уровень понимания того, что происходит с сетевым трафиком. С помощью следующей команды, вы можете отфильтровать UDP-пакеты на порт 8765:
sudo tcpdump -i any udp port 8765 -vvvЭто обеспечит более подробный вывод о полученных и отправленных пакетах, что может помочь в дальнейшем анализе.
5. Аудит системных процессов
Вы уже упомянули использование auditd. Чтобы расширить ваши эксперименты, убедитесь, что у вас правильно настроены правила аудита. Например, чтобы следить за действиями созданных процессов, можно использовать:
auditctl -a always,exit -F arch=b64 -S execveЭто правило будет отслеживать любые новые процессы, которые запускаются на системе.
Заключение
Для эффективного решения проблемы необходимо использовать комбинацию различных инструментов и подходов. bpftrace может предоставить вам исчерпывающие данные о системных вызовах, strace может помочь с отслеживанием отдельных процессов и их сетевых активностей, а также стоит обратить внимание на модули ядра и сообщения от системы. Все эти методы в совокупности помогут вам определить источник UDP-пакетов на ваш компьютер.