使用 AWS WAF2 限制对 WordPress 管理后台的访问

 

通过 CloudFront 分发 WordPress 站点时，我们将不得不更多地考虑缓存控制，但现在我们已经了解了如何将其与 CloudFront 结合起来，是时候考虑控制 WordPress 管理后台了。

 

如果您独立运行 WordPress 站点，这不是一个特殊问题，因为您可以简单地使用“.htaccess”根据 IP 地址或域限制对管理屏幕的访问，但如果您使用 CloudFront 如果您这样做，所有源HTTP服务器的HTTP流量将来自CloudFront，因此HTTP服务器将无法根据用户的IP地址或域信息执行简单的访问控制。

 

当然，像“.htaccess”这样简单的访问控制是不可能的，但是通过在CloudFront端为源请求创建自定义策略，您可以获取客户端的IP地址信息，将该信息放入HTTP标头信息中，然后发送由于可以将信息传递到端的HTTP服务器，因此源服务器端可以巧妙地根据用户的IP信息来控制访问。

 

参考文章：“ [更新] CloudFront-Viewer-Address 标头允许您检查客户端的 IP 地址和连接端口现在在 Amazon CloudFront 中可用 ” 开发人员 IO

 

使用AWS WAF2（有两种类型，旧版本和新版本，所以我将新版本称为WAF2），可以轻松与CloudFront链接）以限制对WordPress管理页面的访问。

 

尝试设置 AWS WAF2

 

除了 CloudFront 之外，AWS WAF2 是一项可以与负载均衡器 (ALB) 服务、API 网关等结合使用的服务，每个 Web ACL 每月 5 美元，每条规则每月 1 美元，另外，即用即付率为每百万个请求 0.6 美元（美元）。

 

使用这个WAF服务来达到这样的目的有点夸张，但既然只是为了测试，我就尝试一下，不用担心成本。

 

在 AWS WAF & Shield 管理控制台中，您可以通过单击“开始”以向导格式继续设置过程，但这一次，我们将首先以“IP 地址”的形式输入您的家庭或组织的 IP 地址信息从注册开始。

 

注册IP集

 

从 AWS WAF 管理控制台的最左侧窗格中选择“IP 集”，然后选择要创建的区域。 这次我们与CloudFront合作，所以选择“全球(CloudFront)”而不是东京区域。

看来IPv4和IPv6不能混合在一个“IP集”中，所以为IPv4和IPv6创建两个“IP集”。 IP 地址（CIDR 格式）可以同时写入多行。

 

 

 

注册 WebACL

 

注册 IP 集后，继续创建 WebACL，这是此 WAF 配置的主要部分。 如果您有设置防火墙等的经验，您就会知道在屏幕上的设置项中要进行哪些设置。

 

在这种情况下，管理注册者使用的IP地址已注册在IP集中，因此如果访问IP地址包含在IP集中，则将无条件授予访问权限。 如果这个地址没有注册，则说明访问是来自一般用户，所以如果访问目的地是WordPress管理区域，则访问会被拒绝；否则，是正常的内容访问，所以会进行允许访问的设置。就是这样做。

 

为了简化这个判断，默认行为设置为访问权限（ALlow），并且按照以下顺序进行判断。

 

1. 匹配IP组⇒访问权限（Allow）
 ↓
   2. 匹配管理 URI ⇒ 访问被拒绝（阻止）
 ↓
   3. 访问权限（Allow）

 

[步骤1.创建WebACL并将其与AWS资源关联]

 

为您要创建的 WebACL 指定适当的名称，并将“资源类型”设置为 CloudFront。 在“关联的 AWS 资源 – 可选”下，链接到您已创建的 CloudFront 分配。

 

 

[第2步.创建规则]

 

将之前定义的访问条件定义实现为 WebACL 规则。 在规则设置中，从“添加规则”下拉菜单中选择“添加我自己的规则和规则组”。 对于底部的“对不匹配任何规则的请求的默认 Web ACL 操作”，选择“允许”，因为默认操作是允许。

 

[规则 #1：管理员 IP 地址确定]

 

第一条规则确定其是否包含在 IP 集中。 为规则指定适当的名称，然后选择“常规规则”作为类型。 下面的“如果请求”下拉菜单中列出了多个条件。

“与表述相符”
“匹配所有语句（AND）”
“至少匹配一个语句 (OR)”
“与陈述不符（NOT）”

从以下四个选项中进行选择。 这次，我们将确定该地址是否与 IPv4 或 IPv6 地址之一匹配，因此我们将选择 OR 条件“至少匹配其中一个语句 (OR)”。

 

结果，“语句2”项将出现在“语句1”的底部，因此按照“语句1”相同的方式设置“IPv6”条件。

 

在 Inspect 下拉项中选择“Originates from an IP address in”，预先注册的 IPv4 IP 集的名称将作为 IP 集出现在下拉项中，因此选择它。

 

对“语句2”进行类似的设置。

 

最后，设置匹配这两个IP集之一时的Action。 本例为管理员访问，因此根据定义设置“允许”。 这样就完成了第一条规则的定义。

 

 

[规则#2：管理屏幕URL访问判断]

 

创建基于管理员IP地址的判断规则后，添加判断是否正在访问Wordpress管理界面的URI的规则。 和以前一样，选择“规则生成器”作为规则类型，并为您以相同方式创建的规则指定一个适当的名称，以便在访问 WordPress 管理屏幕时轻松识别它。

 

这次，我们要判断“wp-login.php”文件的URI是否是“/wp-admin/”目录下的URI，因此我们将在语句1中使用“OR”条件（“/wp -admin”）和语句 2（“wp-login.php”）。

 

确定 URI 比确定 IP 地址稍微复杂一些，并且除非确定用户（客户端 Web 浏览器）实际访问的 URI 类型，否则无法准确确定 URI 访问。 需要进行很多设置，例如大小写处理、URI 编码、字符串匹配条件等。

 

与IP集类似，可以提前注册正则表达式模式，因此注册常用的正则表达式模式是一个好主意。

 

创建这个 URI 判断条件需要一些尝试和错误，直到你习惯为止。

 

【注意】这次的URI判断条件只是为了创建本博客的素材而设置的，因此如果您实际创建规则，则需要创建与您的Wordpress环境相匹配的准确判断条件。 。

 

 

[设置默认动作]

 

在创建 WebACL 的第一阶段，设置了默认操作，但如果您创建的两条规则不适用，则所有规则都将设置为“允许”，因为这是公众对 WordPress 内容的正常访问。

 

 

[步骤3.设置每条规则的优先级]

 

这次，只有两个规则，但第一个管理员 IP 地址确定规则必须优先于第二个 WordPress 管理 URI 确定规则。 如果您按照上面列出的顺序创建了规则，则第一个创建的规则应放置在顶部（高优先级），因此无需更改优先级，但如果您添加规则或更改条件，则在这种情况下。需要考虑规则之间的排序关系。

 

除非您定期配置防火墙，否则可能很难平衡此区域中的规则顺序和默认操作。 在将规则应用于生产环境之前，我们建议您检查它们在测试环境中是否按预期工作。

 

 

[设置各种指标]

 

虽然此设置不是必需的，但可以将 WAF 与 AWS 的 CloudWatch 服务链接以适当监控 WAF2 的运行状态。 在 CloudWatch 指标中注册您这次注册的 WebACL 规则。

 

 

[第 5 步.检查设置]

 

根据WebACL创建向导配置设置的最后一步是检查到目前为止所做的设置并确认设置正确，然后单击屏幕右下角的“创建Web ACL”按钮来创建Web ACL WebACL。注册（链接到 CloudFront）。

 

 

---

 

尝试从家外进行访问（在本例中，使用连接 LTE 的 iPad）并检查对 WordPress 管理屏幕的访问是否按预期工作。

 

---

【禁止直接访问原点】

 

通过到目前为止的设置，我能够使用 CloudFront 和 AWS WAF 的组合为我的 WordPress 站点创建一个环境，并采取一些安全措施，并且还受益于 CloudFront 的缓存，但还有最后一件事很重要。必须采取的安全措施。

 

最后的安全措施是阻止对 AWS EC2 服务器（即我们的源服务器）的外部 HTTP/HTTPS 访问（当然包括其他服务端口）。

 

从外部对源服务器的访问来自世界各地的 CloudFront 边缘，因此您需要了解 CloudFront 的所有 IP 地址范围，并确保仅接受来自这些 IP 地址的 HTTP 访问。

 

AWS 似乎发布了CloudFront边缘服务器的IP列表，但是自己获取它们并将其反映在树脂服务器端是一项相当耗时的任务，并且每次添加CloudFront服务器或更改配置时都会需要这些白名单。必须更新。 を公開している様だが、それらを自分で取得してリジンサーバ側へ反映させるのはかなり手間の掛かる作業であり、CloudFrontサーバの追加や構成変更の度にこれらのホワイトリストを更新しなければならない．

 

除了使用CloudFront的IP白名单之外，还可以修改CloudFront侧向源端发送的请求头，以便源端判断访问来自于CLoudFront。 （“ 配置 CloudFront 以向请求添加自定义 HTTP 标头 ”）

 

看来可以将 Lambda@Edge 应用到 CloudFront 来实现相当细致的控制。 关于这方面的对策，前人的做法已经发表过，值得参考。

 

这次，参考DevelopersIO的“ [更新]阻止不通过Amazon CloudFront的访问现在更容易 ”，我们将在源服务器上禁止来自CloudFront以外的来源的访问。

 

在使用AWS的EC2时，通常的做法是使用安全组来限制访问，但在这种情况下，作为一种禁止CloudFront以外的各方访问的机制，AWS端可以存储CloudFront地址信息，它以一种格式提供托管前缀列表可供安全组使用。

 

首先，访问 AWS 管理控制台并在 VPC 服务最左侧窗格中选择“托管前缀列表”。列表中将显示多个（本例中为四个）前缀列表。 其中，前缀列表pl-58a04531 – com.amazonaws.global.cloudfront.origin-faceing是CloudFront边缘服务器的IP列表。

 

不幸的是，目前，IPv4 地址的前缀列表似乎可用，但我找不到 IPv6 地址的前缀列表。 如果从 CloudFront 到源的通信仅是 IPv4，则没有特别问题。 ．． ．．

 

 

添加设置以允许从 AWS 端创建的托管前缀列表对您提前注册的安全组进行 HTTP 访问。 这次，我们将配置仅允许从家庭访问 VPC 的安全组。

 

添加设置以仅允许从 CloudFront 对目标安全组的入站规则进行 HTTP 访问。 当您将源设置为自定义时，上述 CloudFront 托管 IP 列表名称 (pl-58a05531) 将出现在搜索列表中，因此选择它并将其设置为源地址。

 

现在，CloudFront边缘服务器的HTTP访问权限已添加到安全组中。

 

目前，我能够通过将 AWS 上构建的 WordPress 网站与 CloudFront 和 AWS WAF 相结合，在相对安全的环境中运行它。

 

简单地使用 WordPress 没有问题，但是当你尝试做一些稍微复杂的事情时，你就会立即遇到 WordPress 特有的墙。 由于CMS功能和Web前端是集成的，Wordpress具有FQDN信息，从Web工程师或管理员的角度来看，维护和操作Wordpress环境是一项非常艰巨的任务。

 

很难理解为什么 CMS 内部有 FQDN，但似乎是时候告别我已经使用多年的 WordPress 了。 似乎向静态内容生成的过渡已经成为网络工程领域的主要趋势，所以我不时地考虑将这个网站朝这个方向发展。

 

如果我们这次测试的WordPress + CloudFront + AWS WAF环境能够正常运行，我想将其作为下一个新环境的链接。

 

即便如此，Wordpress 和 CDN 的结合似乎并不兼容。 即使经过几天的测试，我们也遇到了各种问题和奇怪的行为。 我们仔细看看，然后再决定这个验证环境是否有用。