Man in The Middle Attack, или что-то еще?
Мне было интересно, может ли кто-нибудь помочь мне с этой проблемой.
У нас есть веб-сервис, который доступен только через https: // порт 443.
Используя netstat, я вижу, что есть определенный IP-адрес, который пытается подключиться к серверу.
Например, все остальные подключения подключаются к серверу со своего порта на порт сервера 443 (нормальное поведение https).
Этот конкретный ip: 192.0.73.2, пытается открыть соединение с удаленного порта 443 на локальный порт. (Его состояние всегда TIME_WAIT, оно исчезает, а затем возвращается как TIME_WAIT через минуту или около того.
Я сообщаю об этом ip в открытом виде, потому что о нем сообщалось здесь раньше:
У нас есть веб-сервис, который доступен только через https: // порт 443.
Используя netstat, я вижу, что есть определенный IP-адрес, который пытается подключиться к серверу.
Например, все остальные подключения подключаются к серверу со своего порта на порт сервера 443 (нормальное поведение https).
Этот конкретный ip: 192.0.73.2, пытается открыть соединение с удаленного порта 443 на локальный порт. (Его состояние всегда TIME_WAIT, оно исчезает, а затем возвращается как TIME_WAIT через минуту или около того.
Я сообщаю об этом ip в открытом виде, потому что о нем сообщалось здесь раньше:
У нас есть веб-сервис, который доступен только через https: // порт 443.
Используя netstat, я вижу, что есть определенный IP-адрес, который пытается подключиться к серверу.
Например, все остальные подключения подключаются к серверу со своего порта на порт сервера 443 (нормальное поведение https).
Этот конкретный ip: 192.0.73.2, пытается открыть соединение с удаленного порта 443 на локальный порт. (Его состояние всегда TIME_WAIT, оно исчезает, а затем возвращается как TIME_WAIT через минуту или около того.
Я сообщаю об этом ip в открытом виде, потому что о нем сообщалось здесь раньше:
Этот конкретный ip: 192.0.73.2, пытается открыть соединение с удаленного порта 443 на локальный порт. (Его состояние всегда TIME_WAIT, оно исчезает, а затем возвращается как TIME_WAIT через минуту или около того.
Я сообщаю об этом ip в открытом виде, потому что о нем сообщалось здесь раньше:
Этот конкретный ip: 192.0.73.2, пытается открыть соединение с удаленного порта 443 на локальный порт. (Его состояние всегда TIME_WAIT, оно уходит, а затем возвращается как TIME_WAIT через минуту или около того.
Я сообщаю об этом ip в открытом виде, потому что о нем сообщалось здесь раньше: https://www.abuseipdb.com/check/192.0.73.2
Существует брандмауэр CISCO, который защищает сеть компании, и мой системный администратор сказал мне, что он не может найти никаких обращений с этого IP-адреса на сервер . Но инструмент netstat сообщает об обратном.
Вы можете мне что-нибудь предложить? Или скажите, что происходит? Спасибо!
Вот что показывает команда netstat:
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 server_ip:32884 192.0.73.2:443 TIME_WAIT
tcp6 0 69000 server_ip:443 remote_ip:65045 ESTABLISHED
tcp6 0 0 server_ip:443 remote_ip:20467 TIME_WAIT
tcp6 0 0 server_ip:443 remote_ip:55430 TIME_WAIT
tcp6 0 0 server_ip:443 remote_ip:65248 ESTABLISHED
Спасибо всем за помощь в решении этой проблемы. В конце концов, это был вызов gravatar
Обычное попадание в 192.0.73.2 перенаправляет на https://en.gravatar.com/ . Это определенно не атака MITM.
Ваш веб-сайт использует модуль gravatar и пытается подключиться к своему серверу для сбора данных, то есть аватара пользователя , который будет использоваться для комментариев. Вам не нужно беспокоиться об этом, и поскольку он умирает после TIMED_WAIT, он не может подключиться к серверу.
Не стоит беспокоиться, так как IP-адрес не определяется брандмауэром. Было бы лучше исправить модуль, пытающийся получить доступ к граватару, и разрешить доступ к нему.
Это исходящее соединение, ваш сервер подключается к удаленному адресу, а не к другому наоборот.Обычно это означает: у вас есть фоновая служба, которая куда-то отправляет данные. Чтобы выяснить, что это за процесс, используйте netstat (с правами root):
netstat -tulpn
Если вы не видите его в выводе, попробуйте (также как root):
lsof -i tcp
Это покажет вам все соединения с соответствующими Имя процесса. Найдите свое исходящее соединение, посмотрите процесс.
Например, мой сервер регулярно поддерживает исходящее соединение с чужим https-портом, потому что у меня запущен Nginx Amplify, и ему необходимо сообщать ему статистику сервера.
Вы можете увидеть пример этого здесь, в текущий вывод моего сервера (отредактировано):
joe@testbed~$ sudo lsof -i tcp
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
amplify-a 6355 user-nam 14u IPv4 7657189 0t0 TCP testbed.avx.local:36970->ec2.us-west-1.compute.amazonaws.com:https (ESTABLISHED)
Мой сервер устанавливает исходящее соединение со случайного порта на порт https, как и ваш. Запустите команды, найдите процесс и решите, вредоносный он или нет.
Вероятно, никто не пытается подключиться с 443 в локальный верхний порт. Соединения обычно происходят из динамического диапазона портов (с 49152 по 65535). Всегда ли 32884 32884 или это всегда что-то в пределах этого диапазона?
IP-адрес 192.0.73.2 hosts wordpress.com и gravatar.com и т. Д. Более вероятно, что ваш сервер подключается к этому серверу для сбора некоторой информации. Мы не могли знать подробностей, потому что не знаем ваш сайт и его назначение.
IP 192.0.73.2 также оказался сегодня в моем брандмауэре. Это действительно от gravatar.
Причина перехвата IP в том, что TCP-соединение имеет флаги syn и fin, и мой брандмауэр добавляет эти соединения в список. Из https://www.juniper.net/documentation/en_US/junos/topics/concept/tcp-syn-fin-flags.html
Флаги управления SYN и FIN обычно не устанавливаются одинаково. Заголовок сегмента TCP. Флаг SYN синхронизирует порядковые номера с инициировать TCP-соединение.Флаг FIN указывает на конец данных передача для завершения TCP-соединения. Их цели взаимно эксклюзивный. Заголовок TCP с установленными флагами SYN и FIN является аномальным Поведение TCP, вызывающее различные ответы от получателя в зависимости от в ОС