Как определить, какой модуль ядра отвечает за конкретное соединение, отображаемое в NetHogs?

Как определить, какой модуль ядра отвечает за конкретное соединение, отображаемое в NetHogs?

В настоящее время я арендую выделенный сервер у OVH и просматриваю nethogs, чтобы узнать, какую пропускную способность соединения использует конкретный процесс. Однако в итоге я нашел там множество процессов, которые я не авторизовал, которые взаимодействуют с IP-адресами по всему миру (на данный момент список включает Китай, Бразилию, США (несколько штатов), Швецию, Великобританию и Нидерланды), основываясь на их именах. Полные строки в таблице для этих процессов имеют вид ? root <my server's ip>-<some other ip>. Запуск nethogs от имени root не меняет этого. Использование netstat для попытки выяснить PID этих процессов приводит к тому, что PID/Команда равны -. Некоторое лихорадочное гугление, после того как я подумал, что мой сервер был взломан, навело меня на мысль, что это модули ядра, использующие сеть во многом так же, как это делает NFS. Заглянув в lsmod, я вижу большое количество легитимно звучащих имен, которые я не узнаю, так что это бесполезно. Тем не менее, мошеннический модуль может называть себя как-то иначе. В связи с этим я хотел бы спросить, как я могу связать эти соединения с конкретными модулями ядра, а затем провести дальнейшее исследование, чтобы выяснить, что происходит.

Спасибо

решение1

Сервер NFS в ядре не подрывает сетевую отчетность таким образом, и модули обычно не демонстрируют такого рода связь с сетью или ее отчетностью, которую вы описываете. Вы можете описывать невозможность увидеть детали процесса привилегированных или защищенных команд, и это может быть результатом того, что вы не запускаете свое расследование как пользователь root или что-то подобное.

Прочерки в полях PID или команд означают, что, хотя там есть данные, которые можно увидеть, вы к ним не имеете доступа. Повторно запустите свои исследовательские команды как root, и вы должны увидеть, что эти прочерки заменены на пригодные для использования данные.

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

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