Предотвращение горячей ссылки на Amazon Cloudfront
Я использую Amazon Cloudfront для размещения всех изображений и видео на моем сайте, чтобы быстрее обслуживать их для своих пользователей, которые довольно разбросаны по всему миру. Я также применяю довольно агрессивное прямое кэширование к элементам, размещенным в Cloudfront, устанавливая Cache-Controlв public, max-age=7776000,
Недавно я, к своему раздражению, обнаружил, что сторонние сайты ссылаются на мой сервер Cloudfront для отображения изображений на своих страницах без авторизации.
Я настроил .htaccessдля предотвращения хотлинкинга на моем собственном сервере, но я не нашел способа сделать это в Cloudfront, который, кажется, не поддерживает эту функцию изначально. И, что досадно, политики Amazon Bucket, которые можно использовать для предотвращения хотлинкинга, действуют только на S3, они не влияют на дистрибутивы CloudFront [ ссылка]. Если вы хотите воспользоваться преимуществами политик, вы должны обслуживать контент с S3 напрямую.
Очистка журналов моего сервера для горячих линкеров и ручное изменение имен файлов на самом деле нереальный вариант, хотя я делал это, чтобы положить конец самым вопиющим преступлениям.
Любые предложения будут приветствоваться.
7 ответов
Вы можете переслать Referer заголовок вашего происхождения
- Перейти к настройкам CloudFront
- Изменить настройки распределения для распределения
- Перейдите на вкладку "Поведения" и отредактируйте или создайте поведение
- Установить заголовки пересылки в белый список
- Добавить Referer в качестве белого списка заголовков
- Сохраните настройки в правом нижнем углу
Обязательно обработайте заголовок Referer на вашем источнике.
Официальный подход заключается в использовании подписанных URL для ваших медиа. Для каждой медиафайла, который вы хотите распространить, вы можете сгенерировать специально созданный URL, который работает с заданным ограничением времени и IP-адресов источника.
Один из подходов для статических страниц заключается в создании временных URL-адресов для носителей, включенных в эту страницу, которые действительны в 2 раза дольше, чем время кэширования страницы. Допустим, время кэширования вашей страницы составляет 1 день. Каждые 2 дня ссылки становятся недействительными, что заставляет горячие линкеры обновлять свои URL-адреса. Это не надежно, поскольку они могут создавать инструменты для автоматического получения новых URL-адресов, но это должно предотвратить большинство людей.
Если ваша страница динамическая, вам не нужно беспокоиться о том, чтобы очистить кеш вашей страницы, чтобы вы могли просто генерировать URL-адреса, которые работают только для IP-адреса запрашивающей стороны.
У нас было много проблем с горячими ссылками. В конце мы создали CSS спрайты для многих наших изображений. Либо добавляя пробел внизу / сторонам, либо комбинируя изображения вместе.
Мы правильно отображали их на наших страницах, используя CSS, но любые горячие ссылки отображали изображения неправильно, если они также не копировали CSS/HTML.
Мы обнаружили, что они не беспокоятся (или не знают как).
По состоянию на октябрь 2015 года вы можете использовать AWS WAF для ограничения доступа к файлам Cloudfront. Вот статья из AWS, которая объявляет WAF и объясняет, что вы можете с ней сделать. Вот статья, которая помогла мне настроить мой первый ACL для ограничения доступа на основе реферала.
По сути, я создал новый ACL с действием по умолчанию DENY. Я добавил правило, которое проверяет конец строки заголовка реферера для моего доменного имени (в нижнем регистре). Если он проходит это правило, он разрешает доступ.
После назначения моего ACL для моего дистрибутива Cloudfront, я попытался загрузить один из моих файлов данных непосредственно в Chrome, и я получил эту ошибку:
Насколько я знаю, в настоящее время нет решения, но у меня есть несколько, возможно, соответствующих, возможно, не относящихся к делу предложений...
Во-первых: многие люди спрашивали об этом на форумах поддержки Cloudfront. Смотрите здесь и здесь, например.
Очевидно, что AWS извлекает выгоду из хотлинкинга: чем больше хитов, тем больше они взимают за нас! Я думаю, что мы (пользователи Cloudfront) должны начать какую-то жестко организованную кампанию, чтобы они предлагали проверку реферера в качестве функции.
Другое временное решение, о котором я подумал, - это изменение CNAME, которое я использую для отправки трафика в cloudfront/s3. Допустим, вы в настоящее время отправляете все свои изображения на:
cdn.blahblahblah.com (который перенаправляет на некоторое облако / S3 Bucket)
Вы можете изменить его на cdn2.blahblahblah.com и удалить запись DNS для cdn.blahblahblah.com
Как изменение DNS, это выбило бы всех людей, которые в настоящее время осуществляют хотлинкинг, прежде чем их трафик попадет где-нибудь рядом с вашим сервером: запись DNS просто не сможет найти. Вам нужно будет изменить cdn CNAME, чтобы сделать это эффективным (скажем, раз в месяц?), Но это сработает.
На самом деле это более серьезная проблема, чем кажется, потому что это означает, что люди могут гораздо легче обрабатывать целые копии страниц вашего сайта (включая изображения) - так что не только изображения, которые вы теряете, но и не только то, что вы платите за обслуживание этих изображений. Поисковые системы иногда приходят к выводу, что ваши страницы - это копии, а копии - оригиналы... и трафик уходит.
Я думаю отказаться от Cloudfront в пользу стратегически расположенного, сверхбыстрого выделенного сервера (обслуживающего весь контент для всего мира из одного места), чтобы дать мне гораздо больший контроль над такими вещами.
Во всяком случае, я надеюсь, что у кого-то есть лучший ответ!
Как насчет использования подписанных куки? Создайте подписанный файл cookie, используя настраиваемую политику, которая также поддерживает различные виды ограничений, которые вы хотите установить, а также подстановочный знак.
В этом вопросе упоминаются файлы изображений и видео.
Проверка реферира не может использоваться для защиты мультимедийных ресурсов от хотлинкинга, поскольку некоторые мобильные браузеры не отправляют заголовок реферера при запросе аудио или видео файла, воспроизводимого с использованием HTML5.
Я уверен в этом насчет Safari и Chrome на iPhone и Safari на Android.
Очень плохо! Спасибо, Apple и Google.