84 lines
7.7 KiB
Markdown
84 lines
7.7 KiB
Markdown
# Production275 — SYN и задержки API arn-gw01 (2026-10-16)
|
||
|
||
Поручение: исследовать предупреждения SYN flooding на80/443 и периодически
|
||
медленный HTTPS REST на `arn-gw01.rtnt.top`. Выполнены только чтение и короткие
|
||
диагностические подключения. Конфигурация production/RouterOS не менялась.
|
||
|
||
## Результаты
|
||
|
||
Устройство ID1, DNS IPv4 `62.182.194.146`, REST HTTPS443 с проверкой сертификата.
|
||
RouterOS7.24.5 stable,1 CPU. В разовом resource: CPU6%, свободно933036032 байт
|
||
из1207959552, uptime5m41s. Перезапуск выполнен до диагностики, не агентом.
|
||
|
||
1. Первый диагностический GET system/resource завершился тайм-аутом10с.
|
||
Следующие чтения: system/clock2307мс, ip/settings638мс, ip/service145мс,
|
||
log160мс; отдельный полный resource1170мс. Неверная авторизация не наблюдалась.
|
||
2. В первоначальном журнале41 событие: первая отметка02:43:13, оба SYN warning
|
||
на80/443 —02:43:20. Совпадение с uptime указывает на события первых секунд
|
||
запуска. Позднее часы используют Europe/Stockholm/+02:00, в журнале есть
|
||
скачок02:43→04:44; ранние отметки нельзя механически переводить как уже
|
||
синхронизированное местное время. Непрерывную SYN-атаку из этих двух записей
|
||
вывести нельзя. Последующее кольцо1000 записей уже не содержало предупреждений.
|
||
3. Четыре последовательных GET system/identity с новым TCP/TLS, один за раз:
|
||
|
||
| Замер | DNS | TCP установлен | TLS завершён | Заголовки ответа | Всего |
|
||
| --- | --- | --- | --- | --- | --- |
|
||
| 1 | 6 | 1042 | 1141 | 1161 | 1162 |
|
||
| 2 | 2 | 3071 | 3189 | 3208 | 3208 |
|
||
| 3 | 3 | 3088 | 3233 | 3254 | 3254 |
|
||
| 4 | 2 | 5136 | 5254 | 5273 | 5274 |
|
||
|
||
Значения — накопленные миллисекунды от начала запроса. Все HTTP200;
|
||
после TLS до ответа19–21мс. Основная задержка находится до TCP connect.
|
||
4. Захват только SYN/SYN-ACK заголовков на eth0 production-хоста,20с,
|
||
фильтр строго target IPv4/TCP443. Полезная нагрузка не сохранялась.
|
||
Два наших контрольных GET прошли155/149мс; SYN-ACK через18–21мс.
|
||
Затем в обычном опросе приложения зафиксированы повторения исходящих SYN:
|
||
один исходный порт — первое SYN1792119069.651615, SYN-ACK1792119073.773299
|
||
(4.122с, несколько повторов); другой —1792119069.713556→1792119071.757179
|
||
(2.044с). При полученном ответе на SYN RTT около18мс. Захват16 пакетов,
|
||
dropped by kernel0, завершён автоматически через timeout20s.
|
||
5. В02:52:33 UTC (09:52:33 Новосибирск) среди239 TCP conntrack записей4 к
|
||
локальным80/443: time-wait1/syn-sent2/syn-recv1. Две от приложения,
|
||
две с других внешних адресов — по одной80 и443. Массовый текущий SYN flood
|
||
этим одиночным снимком не подтверждён. В этой версии адрес и порт — отдельные
|
||
поля; для итогового подсчёта использованы dst-address **и** dst-port.
|
||
6. tcp-syncookies=false. www80/www-ssl443/reverse-proxy443 включены,
|
||
max-sessions20; FTP/Telnet/SSH уже выключены. В input есть блокировка EVOFW_DENY,
|
||
drop UDP53 и accept WireGuard; отдельных ограничений80/443 доверенными
|
||
источниками и завершающего drop input в прочитанных правилах нет. RAW пустой.
|
||
Правила не менялись; обратный прокси потенциально использует те же порты,
|
||
поэтому закрывать их без проверки потребителей нельзя.
|
||
7. Scheduler20минут на02:49 UTC: traffic4 error/36 ok, gre_bgp4 error/36 ok.
|
||
Выборка последних ошибок называет arn и тайм-аут10с; последние в02:43:49–50 UTC,
|
||
рядом с запуском устройства. Успешные задания иногда занимают9–11с суммарно.
|
||
Это не доказательство медленного SQL или обработки REST на RouterOS.
|
||
|
||
## Вывод
|
||
|
||
Воспроизведены задержки TCP-handshake и повторные SYN **до** TLS/REST.
|
||
Разовые низкие CPU и conntrack не показывают постоянного истощения ресурсов.
|
||
Причину нужно различать между сетью/фильтрацией по пути и обработкой SYN на CHR;
|
||
захват только на отправителе не определяет точное место потери. Историческое
|
||
предупреждение при запуске само по себе не доказывает текущую DDoS-атаку.
|
||
|
||
Приложение сейчас создаёт новые соединения (keepAlive=false, maxSockets2 на origin).
|
||
Это увеличивает количество TCP/TLS-handshake, но не доказывает, что приложение
|
||
создаёт SYN flood. Менять поведение пула вслепую нельзя: прежние проверки273 касались
|
||
также отказов входа. Повышение API timeout лишь скроет часть проявлений.
|
||
|
||
## Подготовленный следующий шаг
|
||
|
||
После отдельного разрешения владельца проверить ID1/host и исходный
|
||
tcp-syncookies=false, изменить **только** `/ip/settings tcp-syncookies=true`
|
||
через REST PATCH. Без перезагрузки, изменения паролей, служб, правил firewall
|
||
и маршрутов. Повторно прочитать значение, повторить небольшой последовательный
|
||
замер TCP/TLS/HTTP и сверить штатные опросы. Откат — вернуть исходное false после
|
||
решения владельца; не объявлять положительный краткий замер доказательством
|
||
устранения причины. Это пока предложение, изменение не применялось.
|
||
|
||
[IP Settings MikroTik](https://help.mikrotik.com/docs/spaces/ROS/pages/103841817/IP%2BSettings)
|
||
описывает SYN cookies при переполнении SYN backlog и ограничения TCP extensions.
|
||
Это защита от переполнения очереди, она не устраняет потери в сети провайдера.
|
||
Точный scope изменения и проверка должны быть согласованы до записи в production.
|