防止Amazon Cloudfront热链接

| 我使用Amazon Cloudfront托管我所有站点的图像和视频，以便更快地向分布在全球各地的用户提供它们。我还将相当积极的正向缓存应用于Cloudfront上托管的元素，将，0ѭ设置为public, max-age=7776000。我最近很生气，发现第三方站点正在热链接到我的Cloudfront服务器，以在未经授权的情况下在自己的页面上显示图像。我已经配置了“ 2”以防止在我自己的服务器上进行热链接，但是还没有在Cloudfront上找到实现此目的的方法，该方法似乎并不原生支持该功能。而且，令人讨厌的是，可以用来防止热链接的亚马逊存储桶策略仅对S3有效，而对CloudFront发行版则无效。如果要利用这些策略，则必须直接从S3提供内容。确定服务器日志中的热链接并手动更改文件名并不是一个现实的选择，尽管我一直在这样做以结束最公然的攻击。欢迎大家提出意见。

已邀请:

7 个回复

才脊烽馈低

官方方法是对媒体使用签名的URL。对于要分发的每个媒体，您都可以生成一个特制的URL，该URL在给定的时间和源IP约束下起作用。静态页面的一种方法是为该页面中包含的媒体生成临时URL，该URL的有效期是页面缓存时间的2倍。假设您网页的缓存时间为1天。每两天，链接将失效，这使热链接程序有义务更新其URL。这不是万无一失的，因为他们可以构建工具来自动获取新的url，但这应该阻止大多数人。如果您的页面是动态的，则无需担心浪费页面的缓存，因此您只需生成仅适用于请求者IP的网址即可。

师埠女

您可以将Referer标头转发到您的来源转到CloudFront设置编辑分配的分配设置转到“行为”选项卡并编辑或创建行为将转发标题设置为白名单将Referer添加为白名单标头将设置保存在右下角确保也处理原始来源的Referer标头。

琶竞捆栓

我们有许多热链接问题。最后，我们为许多图像创建了css精灵。在底部/侧面添加空白或将图像组合在一起。我们使用CSS在页面上正确显示了它们，但是任何热链接都将错误地显示图像，除非它们也复制了CSS / HTML。我们发现他们不会打扰（或不知道怎么做）。

筷啸够对铅

自2015年10月起，您可以使用AWS WAF限制对Cloudfront文件的访问。这是来自AWS的一篇文章，其中宣布了WAF，并说明了您可以使用它进行的操作。这是一篇文章，帮助我设置了第一个ACL以基于引荐来源网址限制访问。基本上，我创建了一个默认动作为DENY的新ACL。我添加了一条规则，用于检查我的域名的引荐来源标头字符串的结尾（小写）。如果通过该规则，则允许访问。在将ACL分配给Cloudfront发行版之后，我尝试直接在Chrome中加载我的数据文件之一，但出现此错误：

皇小福另届

据我所知，目前尚无解决方案，但我有一些可能相关，可能不相关的建议... 第一：许多人在Cloudfront支持论坛上提出了这个问题。例如，请参见此处和此处。显然，AWS从热链接中受益：点击量越大，他们向我们收取的费用越多！我认为我们（Cloudfront用户）需要启动某种精心策划的活动，以使他们能够提供引荐检查。我想到的另一个临时解决方案是更改用于将流量发送到cloudfront / s3的CNAME。假设您当前将所有图像发送到： cdn.blahblahblah.com（重定向到某些cloudfront / s3存储桶）您可以将其更改为cdn2.blahblahblah.com并删除cdn.blahblahblah.com的DNS条目作为DNS更改，这将淘汰所有当前热链接的人员，直到他们的流量到达您的服务器附近为止：DNS条目将完全无法查找。您必须不断更改cdn CNAME才能使其生效（例如每月一次？），但它可以工作。实际上，这是一个比看起来要大的问题，因为这意味着人们可以更轻松地抓取您网站页面的整个副本（包括图片）-因此，不仅是您丢失的图片，还不仅仅是您需要付费来提供这些图像。搜索引擎有时会得出结论，认为您的页面是副本，而副本是原始副本……而轰动您的访问量。我正在考虑放弃Cloudfront，转而使用战略定位的超快速专用服务器（从一个地方向整个世界提供所有内容），以便让我对这些事情有更多的控制权。无论如何，希望其他人有更好的答案！