Короткий ответ

Резкий исходящий трафик с 10.0.10.55 / WS-042 / host.example: найдите кто, куда, каким портом, какой объём. Три рабочих гипотезы: backup/реплика, утечка данных, C2/эксфильтрация malware. Не рубите весь WAN до 30-секундного снимка ss/netflow — иначе потеряете адреса. Не глушите firewall целиком. Pcap точечный, не «зеркало всего ЦОД на ноут».

Связанные: DNS (туннель), процесс, backup если «бэкап» на неизвестный IP.

Симптомы и как отличить

  • SNMP/график: TX на WAN или на NIC сервера.
  • Пользователи: сайты не открываются, ping шлюза жив.
  • Backup job в том же окне или job нет.
  • На WS-042 OneDrive/Chrome не объясняют гигабитный TX всю ночь.
ПризнакСкорее backupСкорее leak/C2
Назначение = известный Repo/PBS/облако backupданет
TCP 445/NFS на свой FSвнутренний, не WANсмотрите другой NIC
Много коротких сессий на чужие VPSнетда
DNS TXT штормнетDNS
TLS на *.windows.com Windows Updateвозможносмотрите объём

Возможные причины

  1. Легитимный backup, реплика, Windows Update, синхронизация облака.
  2. Пользователь качает/отдаёт торрент на WS-042.
  3. Утечка: scp/rclone на чужой хост, архив шары.
  4. C2 или загрузчик тянет модули / отправляет данные.
  5. Циклический лог/дамп на внешний SIEM без лимита.
  6. Петля маршрутизации/шторм (редко выглядит как «один IP»).

Диагностика

1. Кто говорит на узле

Linux host.example (10.0.10.55 как этот сервер):

ss -tnpb
sudo iftop -t -s 10 -n 2>/dev/null || sudo nethogs -t | head
sudo nstat -az | head
ps aux --sort=-%cpu | head

Windows:

Get-NetTCPConnection -State Established |
  Sort-Object RemoteAddress |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess
Get-Process | Sort-Object -Property @{e='CPU'} -Descending | Select-Object -First 15
Get-Counter '\Network Interface(*)\Bytes Sent/sec' | Select-Object -ExpandProperty CounterSamples

2. Netflow / шлюз

Топ talkers на firewall за последние 15 минут: src, dst, bytes, dst port. Экспорт в IR. Не нужен полный payload, чтобы сказать «90% на 1.2.3.4:443».

3. Точечный pcap

sudo timeout 30 tcpdump -i eth0 -w /var/ir/tx.pcap host 10.0.10.55 and 'not port 22'

Пишите на локальный диск с местом, не в /tmp 100% . Не захватывайте сутки.

4. Сопоставить dest

Известный backup endpoint / CDN обновлений / неизвестный VPS. Резолв имени, ASN. Не атакуйте dest.

Решение

Сценарий A. Это backup/реплика

Ограничьте QoS, не инцидент безопасности. Если backup идёт в интернет на личный S3 ключ админа — уже политика секретов, но не C2.

Сценарий B. Утечка своим инструментом (rclone, scp, браузер)

Оборвите процесс после фиксации командной строки. Изолируйте учётку ivan.petrov. Оцените, что ушло (имена файлов в cmdline, не содержимое в тикет). Юридический трек — по объёму персональных данных.

Сценарий C. Malware / C2

Изоляция хоста, не всего офисного WAN (если можем резать один IP). Сохраните pcap. Дальше процесс/троян. Не «лечить» канал выключением DNS для всей фирмы.

# временный стоп исходящего с хоста (пример) — лучше порт коммутатора
# New-NetFirewallRule -DisplayName 'IR block outbound WS-042' -Direction Outbound -Action Block
# только если понимаете, что отрежете и IR-коллектор, и DC

Предпочтительнее quarantine VLAN / shutdown access-порта.

QoS, NAT и несколько NIC

Топ talker на WAN после NAT — это внешний IP офиса, не 10.0.10.55. Без netflow/conntrack вы будете глушить весь канал. На Linux-шлюзе conntrack -L / nft list с counters покажет src внутренний. На WS-042 второй NIC/Wi‑Fi/USB-модем даёт исходящий в обход корпоративного QoS: смотрите все адаптеры, не только Ethernet.

Легитимный backup ночью на объектное хранилище может выглядеть как C2 по «много 443». Отличие: dest = известный endpoint job, процесс = veeam/proxmox-backup-client/rclone с документированным конфигом. Чужой VPS и powershell/curl с домашней папки ivan.petrov — изоляция. Не храните pcap на том же хосте, который утекает: IR-носитель.

Если saturates iSCSI/реплика СХД, это не WAN-инцидент: смотрите storage VLAN, иначе потеряете массив «лечением интернета».

Как проверить, что проблема устранена

  • График TX вернулся к базе.
  • Топ dest объяснён или заблокирован.
  • Хост-источник изолирован или job нормализован.
  • Pcap/ss сохранены, не только скрин графика.
  • Если leak — учётка и ключи ротированы.

Если не помогло

  • После kill трафик жив — другой PID, второй хост, или сеть (DDoS reflection — входящий vs исходящий, сверьте направление).
  • Шифрованный поток на 443, процесс svchost — смотрите PID точно, не имя.
  • Backup в тот же канал, что пользователи, без QoS — это архитектура, не IR; вынесите.
  • Трафик с шлюза, не с хоста — NAT скрывает много внутренних; без netflow не угадаете.

Профилактика

  • Egress filtering: с users VLAN нельзя на произвольный SSH/SMB наружу.
  • Отдельный канал backup.
  • Алерт топ talker.
  • Запрет неучтённого rclone на серверах.
  • QoS, чтобы IR было видно, а не «просто всё умерло».

FAQ

Резать сразу порт коммутатора?

Если TX уже шифрует шары / явный malware — да. Если может быть единственный nightly backup — 2 минуты на dest IP.

Нужен ли полный dump диска из‑за всплеска?

Не из‑за графика. Нужен, если гипотеза leak/C2 подтверждена и это сервер с данными.

OneDrive «Files On-Demand» внезапно отдал 50 ГБ

Легитимно, если пользователь синхронизировал библиотеку. Сверьте UPN и время. Всё равно: не должно сатурировать WAN без лимита.

Linux host.example — это шлюз, TX всегда большой

Смотрите per-flow, не общий TX NIC. Иначе всегда «инцидент».

Можно ли включить Wireshark на проде с GUI?

Нет, с админ-ПК в прод. tcpdump на hop, ограничение по времени и BPF.