Подтвердить что ты не робот

Предотвращение hotlinking Amazon Cloudfront

Я использую Amazon Cloudfront для размещения всех моих изображений и видео сайтов, чтобы быстрее их обслуживать моих пользователей, которые довольно разбросаны по всему миру. Я также применяю довольно агрессивное кэширование вперед к элементам, размещенным на Cloudfront, устанавливая Cache-Control в public, max-age=7776000.

Недавно я обнаружил, что сторонние сайты горячо ссылаются на мой сервер Cloudfront для отображения изображений на своих страницах без разрешения.

Я настроил .htaccess, чтобы предотвратить hotlinking на моем собственном сервере, но не нашел способ сделать это на Cloudfront, который, похоже, не поддерживает эту функцию изначально. И, что досадно, Amazon Bucket Policies, которые могут быть использованы для предотвращения hotlinking, действуют только на S3, они не влияют на дистрибутивы CloudFront [ ]. Если вы хотите воспользоваться политиками, которыми вы должны напрямую управлять своим контентом с S3.

Очистка журналов сервера для хотлинкеров и ручное изменение имен файлов на самом деле не является реалистичным вариантом, хотя я делаю это, чтобы прекратить самые вопиющие нарушения.

Любые предложения приветствуются.

4b9b3361

Ответ 1

Официальным подходом является использование подписанных URL для ваших медиа. Для каждой части медиа, которую вы хотите распространять, вы можете создать специально созданный URL-адрес, который работает в заданном ограничении времени и исходных IP-адресов.

Один подход для статических страниц - генерировать временные URL-адреса для медиа, включенных в эту страницу, которые действительны для 2x продолжительности в качестве времени кэширования страницы. Скажем, время кэширования вашей страницы - 1 день. Каждые 2 дня ссылки будут признаны недействительными, что обязывает hotlinkers обновлять свои URL-адреса. Это не безупречно, поскольку они могут создавать инструменты для автоматического получения новых URL-адресов, но это должно предотвратить большинство людей.

Если ваша страница динамична, вам не нужно беспокоиться, чтобы избавиться от кеша страницы, чтобы вы могли просто генерировать URL-адреса, которые работают только для IP-адреса запрашивающего.

Ответ 2

У нас было много проблем, связанных с хотлинками. В конце мы создали css спрайты для многих наших изображений. Либо добавьте пустое пространство к нижней части, либо объедините изображения вместе.

Мы правильно отображали их на наших страницах с помощью CSS, но любые горячие ссылки отображали изображения некорректно, если они не скопировали CSS/HTML.

Мы обнаружили, что они не беспокоят (или не знают, как).

Ответ 3

Вы можете перенаправить заголовок Referer в исходное состояние с 26 июня!

  • Перейдите в настройки CloudFront.
  • Изменить настройки распределений для распространения
  • Перейдите на вкладку "Поведение" и отредактируйте или создайте поведение.
  • Переместить заголовки в белый список
  • Добавить Referer в качестве заголовка с белым цветом
  • Сохранить настройки в нижнем правом углу

Убедитесь, что вы также обрабатываете заголовок Referer в начале координат.

Ответ 4

По состоянию на октябрь 2015 года вы можете использовать AWS WAF для ограничения доступа к файлам Cloudfront. Вот статья из AWS, которая объявляет WAF и объясняет, что вы можете с ней сделать. Здесь статья, которая помогла мне настроить мой первый ACL для ограничения доступа на основе реферера.

В принципе, я создал новый ACL со стандартным действием DENY. Я добавил правило, которое проверяет конец строки заголовка рефератора для моего имени домена (в нижнем регистре). Если он передает это правило, он ДОПУСКАЕТ доступ.

После присвоения моего ACL моему распределению Cloudfront я попытался загрузить один из своих файлов данных непосредственно в Chrome, и я получил эту ошибку:

Сообщение об ошибке Chrome при попытке получить доступ к файлу Cloudfront непосредственно после применения WAF ACL

Ответ 5

Насколько я знаю, в настоящее время нет решения, но у меня есть несколько возможных, возможно, нерелевантных предложений...

Во-первых: Многочисленные люди задавали это на форумах поддержки Cloudfront. См. здесь и здесь, например.

Ясно, что AWS выигрывает от hotlinking: чем больше хитов, тем больше они требуют от нас! Я думаю, что мы (пользователи Cloudfront) должны начать какую-то тщательно организованную кампанию, чтобы заставить их предлагать проверку референта как функцию.

Еще одно временное решение, о котором я думал, это изменение CNAME, которое я использую для отправки трафика на облачный /s 3. Итак, скажем, вы в настоящее время отправляете все свои изображения:

cdn.blahblahblah.com(который перенаправляется на некоторый ведро облачного /s 3)

Вы можете изменить его на cdn2.blahblahblah.com и удалить запись DNS для cdn.blahblahblah.com

Как изменение DNS, это выбило бы всех людей, которые в настоящее время хотлинкируют до того, как их трафик приближается к вашему серверу: запись DNS просто не сможет найти. Вам нужно будет продолжать изменять CNAME CND, чтобы сделать это эффективным (раз в месяц?), Но это сработает.

На самом деле это большая проблема, чем кажется, потому что это означает, что люди могут быстрее соскабливать целые копии страниц вашего сайта (включая изображения) - так что это не только те изображения, которые вы теряете, а не только то, что вы платите за услугу эти изображения. Поисковые системы иногда заканчивают ваши страницы копиями, а копии - оригиналами... и удары идут по вашему трафику.

Я думаю об отказе от Cloudfront в пользу стратегически позиционированного супер-быстрого выделенного сервера (обслуживающего весь контент во всем мире с одного места), чтобы дать мне гораздо больший контроль над такими вещами.

В любом случае, я надеюсь, что у кого-то есть лучший ответ!

Ответ 6

Этот вопрос касается изображений и видеофайлов.
Проверка ссылок не может использоваться для защиты мультимедийных ресурсов от hotlinking, потому что некоторые мобильные браузеры не отправляют заголовок референта при запросе аудио- или видеофайлов, воспроизводимых с использованием HTML5.
Я уверен в этом о Safari и Chrome на iPhone и Safari на Android.
Очень жаль! Спасибо, Apple и Google.

Ответ 7

Как насчет использования подписанных файлов cookie? Создайте подписанный файл cookie с помощью настраиваемой политики, которая также поддерживает различные типы ограничений, которые вы хотите установить, а также подстановочный знак.