Безопасно ли полагаться на «X-Forwarded-For» для ограничения доступа по IP в Apache при использовании Cloudflare? - PullRequest
Новая
       57

Безопасно ли полагаться на «X-Forwarded-For» для ограничения доступа по IP в Apache при использовании Cloudflare?

2 голосов
/ 10 октября 2019

Я ограничиваю доступ к каталогу определенными IP-адресами, используя файл .htaccess, например так: 

AuthType Basic
AuthName "Protected"

<RequireAny>
    Require ip 1.2.3.4
</RequireAny>

Это нормально работает при обычной настройке сервера, однако при использовании Cloudflare в качестве прокси WAF,он перестает работать, поскольку сервер получает все запросы, переданные через IP-адрес Cloudflare.

В качестве обходного пути можно использовать заголовок «X-Forwarded-For» для идентификации «реального» IP-адреса клиента, поскольку Cloudflare проходитэто со всеми его запросами: 

AuthType Basic
AuthName "Protected"

SetEnvIf X-Forwarded-For 1.2.3.4$ allowed

<RequireAny>
    Require env allowed
</RequireAny>

Это безопасный подход или есть лучший / более безопасный способ ограничения доступа по IP-адресу клиента в Apache при использовании Cloudflare?

1 Ответ

2 голосов
/ 10 октября 2019

Согласно IETF RFC 2616, раздел 4.2 , заголовок может содержать разделенный запятыми список значений, и это случай X-Forwarded-For, поскольку Cloudflare использует его .

Если заголовок X-Forwarded-For уже присутствовал в запросе к Cloudflare, Cloudflare добавляет IP-адрес прокси-сервера HTTP к заголовку: 

Example: X-Forwarded-For: 203.0.113.1,198.51.100.101,198.51.100.102

ВВ приведенных выше примерах 203.0.113.1 - это исходный IP-адрес посетителя, а 198.51.100.101 и 198.51.100.102 - это IP-адреса прокси-сервера, предоставляемые Cloudflare через заголовок X-Forwarded-For.

Обычновыберите самый левый IP-адрес как реальный, но это не всегда так.

Если вы пойдете этим путем, вы должны проверить регулярное выражение, соответствующее вашему IP-адресу, как 

SetEnvIf X-Forwarded-For ^1\.2\.3\.4 allowed

(крайний левый IP-адрес, исключая точки)

Лучший способ (IMHO)

Cloudflare также отправляет заголовок cf-connecting-ip (который должен быть последним IP-адресом, обратившимся к cloudflare перед отправкой нана вашем компьютере), и я бы лучше использовал его.

Это безопасный подход или есть лучший / более безопасный способ ограничения доступа по IP-адресу клиента в Apache при использовании Cloudflare?

ЕстьподвохВ этом сценарии вы говорите Apache:

"у нас есть cloudflare в середине, поэтому вместо вашего собственного способа сказать IP посетителя давайте посмотрим на этот пользовательский заголовок".

Этот пользовательский заголовок может быть подделан . Абсолютно. Поэтому вы также должны сказать:

«этот пользовательский заголовок следует считать надежным, если и только запрос исходит от Cloudflare IP».

Cloudflareявно перечисляет их диапазоны IP-адресов

Наконец, вы должны использовать mod_remoteip вместо того, чтобы вручную создавать правило SetEnvIf.

В основном: 

# /etc/apache2/conf-enabled/remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
...
RemoteIPTrustedProxy 2606:4700::/32
RemoteIPTrustedProxy 2803:f800::/32

В качестве альтернативы, поместите список IP в отдельный файл: 

# /etc/apache2/conf-enabled/remoteip.conf
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxyList conf/trusted-proxies.lst

и 

# conf/trusted-proxies.lst
173.245.48.0/20
103.21.244.0/22
...
...
2803:f800::/32
2606:4700::/32

Если указанный заголовокне приходит в запросе, Apache возвращается к REMOTE_ADDR. То же самое касается запросов от ненадежных IP-адресов. Если заголовок присутствует и поступает из Cloudflare, вы можете просто сделать: 

Require ip 1.2.3.4

Этот подход заменяет IP-адрес везде, где вам нужно его использовать (журналы, аутентификация и т. Д.), И постепенно возвращается к исходному REMOTE_ADDR вкрайние случаи.

...