Коротко — возможные причины, шаги диагностики (инструменты/команды) и метрики для отличия неисправности от атаки.
1) Повторные SYN / SYN-ACK + RST — что это может значить (шаги анализа)
- Потеря пакетов / перегрузка канала: клиент посылает повторные SYN из‑за таймаутов; сервер получает/отправляет SYN‑ACK, но клиент не завершает (или ACK теряется) → повтор. Проверять: высокая доля пересылок (retransmits), увеличенное RTT/SRTT.
- Асимметричная маршрутизация / балансировщик: пакеты от клиента и ответы идут разными путями -> различающиеся TTL и задержки; состояние на пути (NAT/load‑balancer) ломает handshake.
- Проблемы MTU / PMTU blackhole: большие пакеты не проходят, ICMP "Fragmentation needed" отсутствуют → повторные передачи, задержки. Посмотреть MSS в SYN; если MSS уменьшено/клиент не получает ICMP — проблемы.
- NAT / conntrack: переводы портов/адресов или истечение записи conntrack во время handshake -> RST или разорванные соединения; порт меняется между попытками.
- Middlebox / firewall / IPS / инъекция RST: устройство на пути целенаправленно отправляет RST (или модифицирует флаги) — часто RST имеет отличный TTL/IPID/адрес источника.
- Целенаправленная атака (SYN flood / RST injection / сканирование): много источников, высокая частота, spoofed IPs, однотипные пакеты.
2) Какие инструменты и конкретные команды использовать (быстро и по пунктам)
- Захват пакетов и анализ:
- tcpdump: tcpdump -i eth0 -w capture.pcap 'tcp'
- tshark счётчики/фильтры: tshark -r capture.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e ip.src (подсчёт SYN)
- Wireshark для анализа handshake / TCP stream / TCP Expert Info.
- Сравнить захваты с обеих сторон:
- Запустить tcpdump на клиенте и сервере одновременно, сравнить sequence numbers, TTL и timestamps.
- Маршрутизация / асимметрия:
- traceroute -T -p хост (tcptraceroute на некоторых системах), mtr -T хост; для UDP/ICMP/паркового трассирования использовать Paris‑traceroute.
- TTL/источник RST:
- В pcap смотреть ip.ttl, ip.id, mac адреса RST-пакета; RST с необычным TTL/ID/MAC — признак инъекции.
- MTU / PMTU:
- tracepath хост, ping -M do -s хост (последовательно уменьшать размер); смотреть ICMP "Fragmentation needed" в pcap; проверять MSS в TCP опции SYN.
- NAT / conntrack / firewall:
- Linux: conntrack -L (или sudo apt-get install conntrack), iptables -t nat -L -v, nft list ruleset, ss -tn sport = : / ss -s, netstat -antu. На сетевом оборудовании — show ip nat translations, ASAs logs.
- Проверка на инъекции / источники RST:
- tcptraceroute / hping3 --traceroute с разными TTL; hping3 -S -p --flood для тестов (с осторожностью в production).
- Сопоставление времени появления RST: RST, пришедший раньше реального SYN‑ACK или с TTL, который указывает, что он не от сервера — подозрителен.
- Логирование/IDS:
- Suricata/Snort, firewall logs, dmesg/kern logs на NAT/балансировщике.
3) Какие метрики и признаки помогут отличить неисправность от атаки
- Темп/частота: SYN rate устойчиво высокий (сотни/тысячи в секунду) и множество источников → вероятна атака; одиночные/редкие повторы → ошибка/потери. Считать: SYN/sec > $1000$ — подозрительно.
- Соотношение SYN : SYN‑ACK : ACK (handshake completion rate): при неисправности — высокий процент повторных SYN, но часть handshakes завершается; при SYN‑flood — много SYN и мало завершённых handshakes. Вычислять ratio = $\frac{\text{completed handshakes}}{\text{SYNs}}$.
- Источники (entropy): большое разнообразие исходных IP (или spoofed IP с высокой энтропией) → атака; небольшое ограниченное число источников или стабильные адреса → неисправность/конфиг.
- TTL / hop‑count variance: RST/ответы с резко отличающимся TTL/различным ip.id/mac → инъекция/middlebox; при реальной сетевой ошибке TTL обычно стабилен (изменяется при асимметрии, но не аналога инъекции). Оценивать стандартное отклонение TTL: std(TTL).
- Время прихода RST относительно SYN/SYN‑ACK: RST, приходящий быстрее, чем реальный RTT (например RST через $<10$ ms в глобальных сетях) — вероятна инъекция.
- Поведение MSS/packet sizes/ICMP: наличия ICMP "Fragmentation needed" и изменённого MSS указывают на PMTU или MTU проблему, но не на атаку.
- Conntrack/NAT churn: высокая скорость создания/удаления записей nat/conntrack → либо DDoS либо некорректная конфигурация (слишком маленькие тайм‑аута). Считать количество conntrack per second.
- Последовательность TCP опций и SEQ/ACK валидность: при инъекции часто отсутствует согласование SEQ/ACK или TCP options отличаются (timestamps, SACK, window scale).
4) Алгоритм действий при диагностике (шаги)
1. Захватить pcap с обеих сторон: клиент и сервер (временная синхронизация).
2. Подсчитать: число SYN, SYN‑ACK, завершённых handshakes, retransmits, RST; рассчитать throughput и SYN/sec.
3. Сравнить TTL/ip.id/MAC RST‑пакетов, искать несоответствия (инъекция).
4. Запустить traceroute/mtr/tcptraceroute по тому же порту, проверить асимметрию.
5. Проверить MSS в SYN и наличие ICMP "frag needed" → тест ping -M do -s для PMTU.
6. Посмотреть conntrack/iptables/nat логи и тайм‑ауты.
7. При подозрении на атаку — собрать метрики: источник/entropy, скорость, повторяемость; при необходимости включить rate limiting / ACL / блокировку и продолжить пассивный мониторинг.
Короткие примерные команды (избранное)
- tcpdump: tcpdump -i eth0 -w /tmp/a.pcap 'tcp and host 1.2.3.4 and port 80'
- tshark: tshark -r a.pcap -q -z conv,tcp
- подсчёт SYN: tshark -r a.pcap -Y "tcp.flags.syn==1 && tcp.flags.ack==0" | wc -l
- traceroute TCP: tcptraceroute target 80 или traceroute -T -p 80 target
- ping PMTU тест: ping -M do -s 1472 target (убавлять размер пока не пройдёт)
- conntrack: sudo conntrack -L | wc -l; iptables -t nat -L -v
Главное различие: неисправность даёт ограниченные по объёму, воспроизводимые и локализованные по источнику признаки (MSS/ICMP/асимметрия), атака — массовая, быстрый рост SYN/sec, высокая энтропия источников и наблюдаемая инъекция/спуфинг.