По крайней мере, через несколько месяцев выдача netstat -t на нашем веб-сервере, который имеет TCP-порты 22, 80 и 443, открытые для Интернета, часто выявляет десятки подключений в SYN_RECV положение дел:
$ 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 никогда не учитывает возможный поток 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, по-видимому, российский сайт ставок на спорт) . Доступ к сайту происходил очень медленно, так что, возможно, это действительно какая-то форма отражения атак против очевидных адресов источника?
Кто-нибудь еще это заметил? Любое объяснение фактического назначения этих пакетов?
Похоже, что след, оставленный чем-то вроде обнаружения хоста nmap. Nmap - это инструмент для обнаружения хостов и сканер портов.
На этапе обнаружения хоста nmap может отправлять пакеты syn на порты веб-серверов для обнаружения серверов, которые блокируют пинг icmp. Кто-то может использовать nmap для обнаружения активных хостов в вашем диапазоне IP (или даже 0.0.0.0/0) и может вообще не интересоваться вашим хостом.
Вероятно, вы могли бы обнаружить это, анализируя пакеты SYN и ICMP и сравнивая их со сканированиями, описанными в: https://nmap.org/book/man-host-discovery.html
Вы также можете увидеть, продолжают ли они более широкое сканирование портов. Они могут искать хосты с определенным портом с известной им уязвимостью.
Любое объяснение фактического назначения этих пакетов?
Выход netstat показывает, что ваш сервер не смог ESTABLISH соединение, которое может быть связано с временными проблемами с подключением или поддельными (поддельными) конечными точками IP-источника - отправленные им ответы просто не достигли ни одного инициатора (-ов).
Если мы выберем «спуфинговую версию», я бы посоветовал попытаться отследить эти соединения хотя бы на канале, с которого сервер их получает. Это может быть не апстрим, а ваша локальная сеть (будь то настоящая локальная сеть или сеть виртуальных машин и т. Д.).
Затем, если это апстрим, вы можете передать свои опасения им. NOC (начиная с поддержки, скорее конечно). Если это твоя сторона, хорошо - проясни.
Это может быть HTTP Evasion для обхода безопасности вашего сервера. IP-адреса являются возможными вредоносными хостами, поскольку они являются бюджетными хостинг-провайдерами, которые, как известно, размещают вредоносное ПО и участвуют в активности ботнета.