问限制对AWS上特定域的访问

EN

备选案文1。

将ALB的默认目标组设置为空目标组，不包含实例。这是一个有效的配置。

发送给该目标组的请求中，100%将始终失败，因此这些请求将受到503 Service Unavailable的欢迎。

然后添加第二个目标组，即“真正的”目标组，并附加实例，并配置平衡器，只向该组发送匹配所需的Host的请求。

https://serverfault.com/a/868017/153161类似，但与这种情况相反，默认组处理大多数请求，但虚拟/黑洞目标组处理要阻止的请求，从而导致相同的行为--阻止的请求从未发送到实例。

备选案文2。

亚马逊网络应用防火墙 (WAF)也可以这样做，方法是创建一个字符串匹配规则，用于与传入请求的Host头进行比较。WAF与ALB集成。

这种设置可能意味着成本的增加，因为您将不得不支付WAF (每百万个web请求0.60美元，并不是在所有地区都有).但是，如果您已经在此ALB上使用WAF用于其他目的(速率限制、XSS、SQL、字符串匹配等)，则根据当前配置，附加规则的成本将为零或可忽略。

有一种误解认为您的流量“通过”WAF，但它没有。ALB从每个请求中克隆前几KB，并向WAF发送一个数据包，请求对是否允许该请求作出裁决。如果它通过，该请求将被允许，并且WAF不在流量循环中。如果失败，ALB将返回一个403。如果ALB根本无法从WAF获得答案(例如，由于系统故障)，则始终允许请求，从而防止WAF成为故障点。

备选案文3. (h/t @ceejayoz)

使用默认配置配置web服务器的虚拟宿主行为，以便在传入请求中出现意外/未知的Host头时返回错误响应。作为最佳实践，您的服务器不应该对这样的请求作出有利的响应。

这些选项没有特别的顺序。

如果您正在使用cloudflare，这里是您可以使用的terraform模块。https://github.com/orzarchi/terraform-aws-cloudflare-security-group

只需在此处更新您的ALB安全组ID，https://github.com/orzarchi/terraform-aws-cloudflare-security-group/blob/master/vars.tf#L1-L3

并更改cron作业启动的时间，以删除除cloudflare端点之外的所有其他访问。

那么您的EC2将得到充分的保护。