Перейти к основному содержанию

​
Выявление подозрительных всплесков трафика на Linux-серверах 🚨

Неожиданные всплески трафика часто вызваны фоновой активностью. Скрытые задачи или процессы могут незаметно занимать канал:
  • Нежелательные скрипты: скрытые или забытые команды, постоянно передающие данные.
  • Криптомайнеры: несанкционированное ПО, использующее процессор и сеть сервера для майнинга.
  • Некорректно работающие процессы: обычные сервисы, застрявшие в циклах или повторных попытках и перегружающие сеть.
Раннее обнаружение помогает избежать лишнего расхода трафика, падения производительности и неожиданных сетевых затрат. 📘 По теме: разница между трафиком и пропускной способностью описана в этом руководстве EDIS Global.

​
  1. Следите за сетевой активностью в реальном времени

Сначала выясните, какие IP-адреса или процессы используют сеть. Для этого подходят лёгкие утилиты iftop и nload. Перед запуском уточните имя сетевого интерфейса. Это не всегда eth0: возможны ens3, ens18, eno1 и другие. Активные интерфейсы можно найти командой:
Замените eth0 в следующих командах именем своего интерфейса:
В iftop сопоставьте адреса отправителей и получателей со скоростями передачи. Параметр -n оставляет адреса в числовом виде, чтобы их было проще сравнить с выводом ss. Уточните, относятся ли самые активные соединения к ожидаемой работе: незнакомый адрес сам по себе не доказывает злоупотребление.
Пример iftop с выделенным наиболее активным исходящим соединением

Воссозданный пример с вымышленными адресами и скоростями. Столбцы 2s, 10s и 40s — интервалы усреднения.

Для более простого графического представления:
Пример nload со сравнением входящего и исходящего трафика интерфейса

Воссозданный пример. Сравните входящую и исходящую скорости; итоговые значения не определяют процесс.

​
  1. Определите процесс, создающий трафик

Обнаружив необычную активность, используйте современную утилиту ss или, по желанию, netstat, чтобы найти процесс, которому принадлежат соединения.
Если предпочитаете netstat, сначала установите net-tools:
В примере ниже удалённый адрес 198.51.100.40 из статистики трафика найден в соединении процесса с PID 28799. Имя показано как xray-linux-amd6: в этом представлении оно может быть обрезано.
Пример ss с выделенным удалённым адресом и PID 28799 процесса-владельца

Воссозданный вывод ss с переносами строк и вымышленными адресами. Найдите удалённый адрес, затем запишите PID.

ss определяет сокеты и их процессы, но не измеряет текущую скорость передачи. VPN-программы, например Xray, могут открывать такие соединения совершенно законно. Используйте nethogs, описанный ниже, для сравнения скоростей по процессам и сверьтесь с сервисами, которые вы намеренно запустили. См. руководство ss.

​
  1. Изучите подозрительный процесс

Получив подозрительный PID из ss или netstat, выясните, что это за процесс и откуда он запущен.
💡 Замените 28799 на PID процесса, который вызвал подозрения на предыдущем шаге. Сравните путь к исполняемому файлу и аргументы с установленным вами ПО. Пути в /tmp, /dev/shm и /var/tmp требуют проверки, но само расположение файла ещё не доказывает взлом.
Пример вывода readlink и proc cmdline для PID 28799

Один процесс, две проверки: расположение исполняемого файла и аргументы запуска. Этот пример не является заключением о вредоносности.

​
  1. Сохраните свидетельства и остановите подтверждённую нежелательную активность

Имя процесса, незнакомый IP или путь в /tmp — повод для проверки, а не доказательство взлома. Сначала установите назначение процесса и его принадлежность установленному вами ПО. До остановки запишите PID, путь, командную строку, время запуска, соединения и соответствующие журналы. Если для анализа нужен исполняемый файл, сохраните его, пока он доступен: после завершения процесса /proc/PID/exe может исчезнуть. Не запускайте подозрительный файл. См. справку Linux по /proc/PID/exe. Если нежелательная активность подтверждена:
  • По возможности остановите процесс через приложение или менеджер служб. Иначе управляющая программа может перезапустить завершённый процесс.
  • Для отдельного процесса команда sudo kill -TERM 28799 запрашивает штатное завершение. Замените пример PID на только что проверенный. Прежде чем применять принудительную остановку, проверьте, завершился ли процесс.
  • Отключайте только подтверждённую нежелательную запись автозапуска, предварительно сохранив её копию для исследования.
Не удаляйте Xray, задание cron или исполняемый файл лишь потому, что он похож на пример в статье. Если сервер взломан, остановка одного процесса только сдерживает инцидент и не доказывает, что система очищена.

​
  1. Проверьте cron и записи автозапуска

Многие нежелательные скрипты пытаются запускаться после перезагрузки через cron или файлы автозапуска. Внимательно проверьте:
Также проверьте распространённые пути:
Если обнаружите подозрительную запись такого вида:
или ссылку на временный каталог:
проверьте, относится ли она к ожидаемому сервису. Если нежелательность подтверждена, сохраните копию и удалите или отключите именно эту запись. Пример с Xray также может быть корректной конфигурацией VPN. 💡 Совет: обычные задания cron часто выполняют обслуживание системы — резервное копирование или ротацию журналов. Запуск из /tmp, /dev/shm или /var/tmp особенно подозрителен.

​
  1. Отслеживайте трафик процессов через nethogs

Для непрерывного наблюдения за процессами, больше всего использующими сеть:
Вы увидите обновляемый список процессов со скоростями отправки и приёма. Это помогает замечать отклонения до того, как они станут серьёзными.
Пример NetHogs с выделенным PID 28799 и скоростями отправки и приёма

Воссозданный пример с вымышленными скоростями в KB/sec. Высокая скорость указывает, что проверить, но не доказывает вредоносность.

Сравните PID с предыдущим выводом ss. Учитывайте единицы: KB/sec — килобайты в секунду, а iftop обычно показывает скорость в битах в секунду. См. проект NetHogs.

​
  1. Проверьте общий расход трафика

Если подозреваете, что уже потрачено слишком много данных, посмотрите статистику в панели EDIS. Там доступны общий расход за месяц, ежедневные графики и сроки пополнения. 📘 Как EDIS Global измеряет расход сети и определяет циклы пополнения.

​
  1. Восстановите систему и предотвратите повторение

При сбое приложения исправьте его настройки или обновите его, затем убедитесь, что трафик вернулся к ожидаемому уровню. При подтверждённом взломе сохраните нужные свидетельства, ограничьте работу затронутого сервиса, смените раскрытые учётные данные с доверенного устройства и запланируйте чистое восстановление из проверенных программ и данных. Снижение трафика не означает, что весь несанкционированный доступ устранён. Проверьте обновления, доступные извне службы и настройки доступа SSH. Правила межсетевого экрана должны разрешать только действительно нужный трафик; UFW не определяет вредоносность процесса по имени. Изменения вроде монтирования с noexec не заменяют расследование причины активности. О суммарном расходе, пополнении и общем резерве читайте в статьях Статистика трафика и Traffic Pool.
Последнее изменение 7 ноября 2026 г.