#ruby-on-rails #ruby #azure #networking
#ruby-on-rails #ruby #azure #сеть
Вопрос:
Недавно я добавил ведение журнала в rails API, размещенный в Azure, который регистрирует идентификаторы пользователей и IP-адреса, которые Google Recaptcha v3 пометил как подозрительные (v3 присваивает запросам оценку «доверие» от 0.0 до 1.0, не показывая обычного вызова captcha). В конечном итоге я хотел бы использовать Recaptcha v3 для ограничения скорости подозрительных пользователей, но я заметил много помеченных запросов с одних и тех же двух странно выглядящих IP-адресов.
Я вижу запросы от множества пользователей, исходящие от 11.0.2.1 и меньшего подмножества от 11.0.0.1 . В остальном эти пользователи кажутся законными. В журналах нашего стороннего поставщика удостоверений я вижу, что эти пользователи вошли в систему с обычных IP-адресов, которые соответствуют их общим местоположениям, но по какой-то причине наш API получает 11.0.2.1 адреса.
11.0.2.1 похоже, это настройка по умолчанию в некотором программном обеспечении F5 и оборудовании Cisco. Поскольку наш поставщик удостоверений, похоже, может получить правильный IP, я предполагаю, что у нас неправильная конфигурация или ошибка в нашем приложении rails. Однако я не могу воспроизвести эту ошибку самостоятельно и не вижу проблем с вызовом request.ip локально или на тестовой машине.
Я неправильно получаю IP-адреса или мой API каким-то образом неправильно настроен?
Ответ №1:
На самом деле, чтобы получить реальный IP-адрес клиента в rails, вы должны использовать request.remote_ip вместо request.ip . Они отличаются, как показано ниже.
И страница API для класса ActionDispatch::RemoteIp показывает более подробную информацию.
Это промежуточное программное обеспечение вычисляет IP-адрес удаленного клиента, который выполняет запрос. Это делается путем проверки различных заголовков, которые могут содержать адрес, а затем выбора последнего установленного адреса, которого нет в списке доверенных IP-адресов. Это следует прецеденту, установленному, например, сервером Tomcat, с аргументацией, подробно объясненной @gingerlime. Более подробное объяснение алгоритма приведено в ActionDispatch::RemoteIp::GetIp#calculate_ip.
Некоторые стоечные серверы объединяют повторяющиеся заголовки, как того требует HTTP RFC 2616. Некоторые стоечные серверы просто отбрасывают предыдущие заголовки и сообщают только то значение, которое было указано в последнем заголовке. Если вы используете несколько прокси-серверов (например, NGINX, HAProxy и Unicorn), вам следует протестировать свой сервер Rack, чтобы убедиться, что ваши данные в порядке.
ЕСЛИ ВЫ НЕ ИСПОЛЬЗУЕТЕ ПРОКСИ, ЭТО ДЕЛАЕТ ВАС УЯЗВИМЫМ ДЛЯ ПОДМЕНЫ IP. Это промежуточное программное обеспечение предполагает, что существует по крайней мере один прокси-сервер, который устанавливает заголовки с IP-адресом удаленного клиента. Если вы не используете прокси, потому что вы размещены, например, на Heroku без SSL, любой клиент может претендовать на любой IP-адрес, установив заголовок X-Forwarded-For. Если вас это волнует, то вам нужно явно удалить или проигнорировать эти заголовки за некоторое время до запуска этого промежуточного программного обеспечения.
Комментарии:
1. Это похоже на проблему, которую я вижу (предположительно
request.ip, это предоставление мне IP-адреса по умолчанию для прокси-серверов из определенных сетевых инструментов), огромное спасибо. Я протестирую это и отмечу как разрешенное, если все будет выглядеть хорошо.2. Так что это навело меня на правильный путь. Я использую веб-приложение Azure для контейнеров, абстракцию, которая позволяет мне запускать образ Docker на легко масштабируемом ресурсе. Однако после разговора с их службой поддержки, по-видимому, они используют обратный прокси, который не проходит
x-forwarded-for, который является источником запросов 11.0.0.*. Поэтому мне, возможно, потребуется просто переключиться на совершенно другой облачный ресурс, чтобы заставить это работать. Итак, ваш ответ определенно правильный и исправил бы это, если бы был правильно настроенный прокси, но, к сожалению, его нет.