☰

Найти локальные процессы, запускающие TCP-соединения

tag-icon • tag-icon linux tcp ipv4
Найти локальные процессы, запускающие TCP-соединения

С помощью tcpdump я вижу много SYN-пакетов... а исходный IP-адрес — Localhost.

Я хочу выяснить, какие процессы пытаются соединиться.

Обратите внимание, что соединения не достигают состояния ESTABLISHED, похоже, что это случайное сканирование портов.

решение1

Недавно я оказался в такой же ситуации на Linux (виновником был adb). Мой подход заключался в использовании системы аудита для регистрации connect()системных вызовов.

sudo auditctl -a exit,always  -F arch=b64  -S connect -k who-connects

Чтобы указать системе аудита регистрировать все connect()системные вызовы (здесь 64-битный вариант, вы можете добавить еще один для 32-битных вариантов, если вы работаете в многоархитектурной системе с 32- и 64-битными приложениями)

Более поздний запуск:

sudo ausearch -i -k who-connects

Чтобы увидеть, какие связи существуют.

По-прежнему будет возможно устанавливать TCP-соединения без использования API сокетов. Например, путем реализации стека TCP в пользовательском пространстве и использования API более низкого уровня для отправки пакетов, но это не будет распространено (особенно на интерфейсе обратной связи).

решение2

Предполагая, что у вас установлен SystemTap

probe begin {
    printf("ok\n");
}
probe syscall.connect {
    # connect however may fail or flail around in a EINPROGRESS state;
    # this log only indicates that a connect was attempted
    if (uaddr_af == "AF_INET" || uaddr_af == "AF_INET6")
        printf("%s[%d]: %s\n", execname(), pid(), argstr);
}
probe syscall.connect.return {
    printf(" -> %s[%d]: %s\n", execname(), pid(), retstr);
}

сохранено как whomakeconnect.stpпокажет connectвызовы при запуске с помощью stapasroot

# stap-prep
... fix anything reported, it requires debug kernels ...
# stap whomakeconnect.stp

решение3

Вы можете использовать команду netstat. Она показывает состояние пакета. Но вам нужно перехватить вывод, потому что он появляется только во время отправки. Это не похоже на прослушивающий сокет tcp. Вот почему вы можете попытаться перехватить его с помощью команды watch. Я предполагаю, что соединение осуществляется через ipv4.

watch -n 0.1 'netstat -4pn | grep -F "SYN_SENT"'

флаги нестата

p флаг: идентификатор/имя процесса

флаг n: числовой вывод (без разрешения DNS)

4 флаг: показывать сокеты ipv4

Команда watch заставляет команду netstat выполняться повторно с периодом 0,1 секунды.

Связанный контент