Большое количество соединений в SYN_RECV, а не SYN-флуд, это атака отражения?
По крайней мере, через несколько месяцев после выполнения команды netstat -t на нашем веб-сервере, который имеет порты TCP 22, 80 и 443, открытые для Интернета, часто обнаруживаются десятки соединений в SYN_RECV status:
$ netstat -nt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 128.1XX.XX.X:22 142.93.230.186:50603 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.89.196:36332 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 167.71.79.217:40430 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.235.90:36742 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.128.243.146:35451 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.253.100:43994 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 188.166.91.16:42461 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 178.62.242.138:33381 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 142.93.235.90:57784 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 165.22.198.207:36181 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 68.183.11.83:63899 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.93.253:41816 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.85.129:48833 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.62.207.43:59050 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 128.199.55.152:55891 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.205.23:52978 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 165.22.198.135:36668 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 165.22.203.65:65273 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 68.183.15.91:46722 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.4.136:55194 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 142.93.228.103:60458 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.253.100:52599 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.89.56:46283 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.250.235:43637 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.7.181:37556 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 104.248.89.200:64128 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.139.213:38821 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 104.248.92.161:63004 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 68.183.15.91:46210 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 104.248.92.138:39651 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 178.62.241.74:43953 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 142.93.224.74:42996 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 165.22.196.167:38597 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.128.254.3:36751 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 104.248.93.27:32904 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 167.71.78.255:60529 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 165.22.201.209:45397 SYN_RECV
tcp 0 0 128.1XX.XX.X:80 178.62.207.205:39291 SYN_RECV
tcp 0 0 128.1XX.XX.X:22 165.22.198.207:61967 SYN_RECV
tcp 0 0 128.1XX.XX.X:443 178.62.234.81:39309 SYN_RECV
[---cut---]
Первое, что у меня было, было то, что это была атака SYN-флуда, однако (а) сервер, похоже, совсем не страдает от «атаки», (б) скорость SYN довольно низкая , чуть более 2 пакетов / сек., и (c) я обычно наблюдаю, что эти SYN-пакеты поступают из одного и того же сетевого блока как на этом сервере (веб-сервер университетской лаборатории, размещенный в нашей университетской сети), так и на домашнем сервере, который находится на совершенно другой сетевой блок (подключенный через обычное жилое оптоволоконное соединение с общедоступным динамическим IP-адресом), и (d) ядро Linux никогда не соответствует ab возможен SYN-поток (файлы cookie TCP SYN включены).
Что мне интересно, так это то, какова может быть реальная цель этих пакетов SYN. Похоже, они не связаны с проблемами сети (плохо настроенными межсетевыми экранами или аналогичными проблемами). Они почти всегда поступают из IP-пространств центров обработки данных, которые меняются день за днем (это может быть Amazon EC2, Serverius, DigitalOcean и т. Д.). Иногда это всего один или несколько IP-адресов, иногда десятки. Иногда IP отвечает, если я пингую его, иногда нет. Хотя я тестировал только время от времени, я почти никогда не находил доступный веб-сервер на этих IP-адресах на портах 80 или 443 (никогда не пытался сканировать больше портов, чем это), но см. Ниже первый из них, который я нашел сегодня. Они появляются всплесками примерно в течение часа, а затем исчезают; Я еще не пробовал автоматически определять их, чтобы иметь почасовой график, чтобы увидеть, есть ли какое-то «расписание».
Я также думал, что это может быть какая-то атака с усилением с использованием поддельных IP-адресов источников (каждый получил SYN пакет в конечном итоге создаст 5 пакетов SYN ACK до истечения времени ожидания сервера), но это не имеет особого смысла, поскольку (а) обычный сервер быстро ответил бы пакетом RST, таким образом останавливая дальнейшие SYN ACK, и (б) как упоминалось, на этих серверах не размещаются общедоступные веб-сайты, которые могут стоить атаки DDoS-усиления.
Исходные адреса (возможно, подделанные?) в большинстве случаев не имеют записи PTR или общей записи, но в некоторых случаях они дают фактические имена хостов ( например, в приведенном выше списке 142.93.230.186 означает parimatchklub.com, по-видимому, российский сайт ставок на спорт). Доступ к сайту происходил очень медленно, так что, возможно, это действительно какая-то форма отражения атаки против очевидных адресов источника?
Кто-нибудь еще это заметил? Любое объяснение фактического назначения этих пакетов?
Какое-либо объяснение о фактической цели тех пакетов?
вывод netstat шоу, что Ваш сервер был неспособен к ESTABLISH соединение, которое могло быть должными временными проблемами возможности соединения или имитировало (подделанные) конечные точки источника IP —, отвечает, что это отправило, просто не достиг никакого инициатора (инициаторов).
, Если бы мы выбираем "spoofing version", я предложил бы пытаться отследить те соединения, по крайней мере, с каналом, от которого сервер получает их. Это могло бы быть не восходящим, но Ваша LAN (быть этим реальная сеть LAN или VMs, и т.д.).
Затем, если это является восходящим, Вы могли бы передать свои проблемы их NOC (начинающий с поддержки, более вероятно конечно). Если это - Ваша сторона, хорошо — разрешают его.
Это похоже на место, оставленное позади чем-то как исследование хоста nmap. Nmap является инструментом исследования хоста и сканером портов.
фаза исследования хоста nmap’s может отправить syn пакеты в порты веб-сервера для обнаружения серверов, какой блок icmp проверяют с помощью ping-запросов. Кто-то может использовать nmap для обнаружения живых хостов в диапазоне IP (или даже 0.0.0.0/0) и не может иметь никакого интереса вообще к хосту.
Вы могли, вероятно, обнаружить это пакетом, осуществляющим сниффинг SYN и пакетов ICMP и сравнивающим их со сканированиями, описанными в: https://nmap.org/book/man-host-discovery.html
можно также видеть если they’re, добивающийся более широкого сканирования портов. Они могут искать хосты с конкретным портом с уязвимостью, известной им.
Это могло быть HTTP Evasion для обхода безопасности вашего сервера. IP-адреса являются возможными вредоносными хостами, поскольку они являются бюджетными хостинг-провайдерами, которые, как известно, размещают вредоносное ПО и участвуют в активности ботнета.