【NGINX--7】安全控制--2

1、HTTPS 重定向

将未加密的请求重定向到 HTTPS。

使用 rewrite 指令将所有 HTTP 流量发送到 HTTPS：

server {
    listen 80 default_server;
    listen [::]:80 default_server; 
    server_name _;
    return 301 https://$host$request_uri;
}

此配置用于侦听 IPv4 和 IPv6 以及任何主机名的默认服务器的 80 端口。return 语句向使用同一主机和请求 URI 的 HTTPS 服务器返回 301 永久重定向。
详解
在适当的情况下始终重定向到 HTTPS，这是非常重要的。您可能会发现，不需要重定向所有请求，而只需要重定向在客户端和服务器之间传递敏感信息的请求。在这种情况下，您可能希望只将 return 语句放在特定的位置，例如/login。

2、在 NGINX 之前终止 SSL/TLS 后重定向到HTTPS

需要重定向到 HTTPS，然而，您已在 NGINX 之前的某个层终止了 SSL/TLS。

使用常见的 X-Forwarded-Proto 请求头确定是否需要重定向：

server {
    listen 80 default_server;
    listen [::]:80 default_server; 
    server_name _;
    if ($http_x_forwarded_proto = 'http') { 
        return 301 https://$host$request_uri;
    }
}

这种配置与 HTTPS 重定向十分相似。然而，在这个配置中，我们只在请求头X-Forwarded-Proto 与 HTTP 相同时进行重定向。
详解
在 NGINX 前面的某个层终止 SSL/TLS 是一种常见的做法，为的是节省计算成本。但是，您需要确保每个请求都是 HTTPS 请求，而终止 SSL/TLS 的层面不具有重定向能力。但它可以设置代理请求头。这种配置适用于 Amazon Web Services Elastic Load Balancer（AWS ELB）等层面，这些层可免费卸载 SSL/TLS。这是一个小技巧，可保护 HTTP 流量的安全。

3、HTTP 严格传输安全协议

指示浏览器永远不通过 HTTP 发送请求。

设置 Strict-Transport-Security 请求头，使用 HTTP 严格传输安全协议（HSTS）增强功能：

add_header Strict-Transport-Security max-age=31536000;

此配置将 Strict-Transport-Security 请求头的使用时间设置为最长一年。如 HTTP 请求尝试访问该域，这将指示浏览器始终进行内部重定向，这样所有请求都将通过 HTTPS 发出。
详解
对于某些应用来说，一个 HTTP 请求遭到中间人攻击就可能会摧毁整个公司。如果一个包含敏感信息的表单通过 HTTP 发送，势必会造成损害，就算是通过 NGINX 进行HTTPS 重定向也于事无补。这个可选的安全增强功能可指示浏览器，永远不要发出HTTP 请求，因此请求始终都在加密后发出。
参考资料
RFC HTTP 严格传输安全协议标准文档
OWASP HTTP 严格传输安全协议备忘单

4、提供多种安全方法

需要提供多种方法将安全性传递到封闭的站点。

使用 satisfy 指令，指示 NGINX 您想要满足所用的任何或所有安全方法：

location / {
   satisfy any;
   allow 192.168.1.0/24;
   deny all;
   auth_basic "closed site";
   auth_basic_user_file conf/htpasswd;
}

此配置告知 NGINX 请求 location/ 的用户需要满足其中一种安全方法：请求需要来自192.168.1.0/24 CIDR 代码块，或者必须能够提供可以在 conf/htpasswd 文件中找到的用户名和密码。satisfy 指令带两个选项：any 或 all。
详解
satisfy 指令是一个不错的方法，它提供了多种验证 Web 应用的方法。在 satisfy 指令中指定 any，代表用户必须满足其中一个安全要求。在 satisfy 指令中指定 all，代表用户必须满足所有安全要求。这个指令可以与【NGINX–6】安全控制–1 中详述的 http_access_module、【NGINX–5】身份验证-1 中详述的 http_auth_basic_module、、【NGINX–5】身份验证-2 中详述的http_auth_request_module 及、【NGINX–5】身份验证-3 中详述的 http_auth_jwt_module 一起使用。只有通过多层才能真正实现安全性。satisfy 指令可帮助您为需要深度安全规则的位置和服务器实现这个目标。

5、NGINX Plus 动态应用层 DDoS 防护

需要动态分布式拒绝服务（DDOS）防护解决方案。

使用 NGINX Plus 构建集群感知型速率限制和自动拦截列表：

   limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync;
              # Cluster-aware rate limit
   limit_req_status 429;
   keyval_zone zone=sinbin:1M timeout=600 sync; 
              # Cluster-aware "sin bin" with 
              # 10-minute TTL
   keyval $remote_addr $in_sinbin zone=sinbin; 
              # Populate $in_sinbin with 
              # matched client IP addresses
   server {
        listen 80;
        location / {
             if ($in_sinbin) {
                   set $limit_rate 50; # Restrict bandwidth of bad clients
              }
             limit_req zone=per_ip; 
                    # Apply the rate limit here
             error_page 429 = @send_to_sinbin; 
                    # Excessive clients are moved to 
                    # this location
             proxy_pass http://my_backend;
         }
        location @send_to_sinbin {
             rewrite ^ /api/3/http/keyvals/sinbin break; 
                   # Set the URI of the 
                   # "sin bin" key-val
            proxy_method POST;
            proxy_set_body '{"$remote_addr":"1"}';
            proxy_pass http://127.0.0.1:80;
        }
       location /api/ {
            api write=on;
            # directives to control access to the API
       }
}

详解
该解决方案通过使用同步键值（key-value）存储来使用同步速率限制，以动态响应DDoS 攻击并减轻其影响。提供给 limit_req_zone 和 keyval_zone 指令的 sync 参数将共享内存区与 NGINX Plus active-active 集群中的其他机器同步。上面的示例标识了每秒发送超过 100 个请求的客户端 —— 无论哪个 NGINX Plus 节点接收请求。当客户端超过速率限制时，将通过调用 NGINX Plus API 将其 IP 地址添加到“sin bin”键值存储中。集群内的 sin bin 是同步的。无论哪个 NGINX Plus 节点接收请求，来自 sin bin 中的客户端的其他请求都会面临非常低的带宽限制。限制带宽比直接拒绝请求更可取，因为它不会向客户端清楚地表明 DDoS 防护已生效。10 分钟后，客户端将自动从sin bin 中移除。

6、安装和配置 NGINX Plus 的 NGINX App Protect WAF 模块

安装和配置 NGINX App Protect WAF 模块。

请参考《NGINX App Protect WAF 管理指南》。请不要跳过有关从单独的仓库中安装NGINX App Protect WAF 签名的部分。
确保 NGINX App Protect WAF 模块由 NGINX Plus 在 main 上下文中使用 load_module 指令动态加载，并使用 app_protect_* 指令启用：

user nginx; 
worker_processes auto;
load_module modules/ngx_http_app_protect_module.so;
# ... Other main context directives 
http {
    app_protect_enable on;
    app_protect_policy_file "/etc/nginx/AppProtectTransparentPolicy.json"; 
    app_protect_security_log_enable on;
    app_protect_security_log "/etc/nginx/log-default.json" 
        syslog:server=127.0.0.1:515;
    # ... Other http context directives
}

在该示例中，app_protect_enable 指令设置为 on，启用了当前上下文的模块。该指令以及下面所有指令在 http 上下文，以及 HTTP 的 server 和 location 上下文中都是有效的。app_protect_policy_file 指令指向一个 NGINX App Protect WAF 策略文件，接下来我们将对其进行定义；如果没有定义，则使用默认策略。接下来配置了安全日志，并需要远程日志服务器。例如，我们将其配置为本地系统日志（Syslog）侦听器。app_protect_security_log 指令带两个参数，第一个参数是一个定义了日志设置的 JSON 文件，第二个参数是日志数据流目的地。日志设置文件将稍后在本节展示。

构建一个 NGINX App Protect WAF 策略文件，将其命名为 /etc/nginx/AppProtect
TransparentPolicy.json：

{
     "policy": {
         "name": "transparent_policy",
         "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
         "applicationLanguage": "utf-8",
         "enforcementMode": "transparent"
     }
}

该策略文件通过使用模板来配置默认的 NGINX App Protect WAF 策略，将策略名称设置为 transparent_policy，将 enforcementMode 设置为 transparent，这表示 NGINX Plus 将记录日志但不会拦截日志。透明（transparent）模式非常适合在新策略实施之前对其进行测试。

将 enforcementMode 改为 blocking，启用拦截模式。该策略文件可以命名为 /etc/nginx/AppProtectBlockingPolicy.json。要在两个文件之间切换，请在 NGINX Plus 配置中更新 app_protect_policy_file 指令：

{
     "policy": {
          "name": "blocking_policy",
          "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
          "applicationLanguage": "utf-8",
          "enforcementMode": "blocking"
     }
}

要启用 NGINX App Protect WAF 的某些保护特性，需启用一些违规行为：

{
      "policy": {
          "name": "blocking_policy",
          "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
          "applicationLanguage": "utf-8",
          "enforcementMode": "blocking",
          "blocking-settings": {
               "violations": [
                   {
                        "name": "VIOL_JSON_FORMAT",
                        "alarm": true,
                        "block": true
                   },
                   {
                        "name": "VIOL_PARAMETER_VALUE_METACHAR",
                        "alarm": true,
                        "block": false
                   }
               ]
          }
     }
}

在上面的示例中，向策略添加了两种违规行为。注意，VIOL_PARAMETER_VALUE_METACHAR 未设置为 block，而只是设置为 alarm；而 VIOL_JSON_FORMAT 设置为block 和 alarm。当设置为 blocking 时，该功能允许重写默认的 enforcementMode。当enforcementMode 设置为 transparent 时，将优先使用默认的强制设置。

构建一个 NGINX Plus 日志文件，将其命名为 /etc/nginx/log-default.json：

{
     "filter":{
         "request_type":"all"
     },
     "content":{
         "format":"default",
         "max_request_size":"any",
         "max_message_size":"5k"
     } 
}

该文件由 app_protect_security_log 指令在 NGINX Plus 配置中定义，并且是 NGINX App Protect WAF 日志的必要文件。
详解
该解决方案演示了使用 NGINX App Protect WAF 模块配置 NGINX Plus 的基础知识。NGINX App Protect WAF 模块支持完整的 Web 应用防火墙（WAF）定义。这些定义源自 F5 高级应用安全防护功能。这套全面的 WAF 攻击签名已得到广泛的实践测试和证明。通过在 NGINX Plus 安装过程中添加这些签名，可同时获得强大的 F5 应用安全防护功能以及 NGINX 平台的敏捷性。

安装并启用该模块后，大多数配置都在策略文件中完成。本节中的策略文件展示了如何启用主动拦截、被动监控和透明模式，并解释了如何在出现违规时重写该功能。违规行为只是所提供的其中一种防护措施。其他防护措施包括 HTTP 合规、规避技术、攻击特征、服务器技术、数据保护等等。要追踪 NGINX App Protect WAF 日志，需要使用 NGINX Plus 日志格式，并将日志发送到远程侦听服务、文件或 /dev/stderr。
如果您正在使用 NGINX Controller ADC4，那么您可以通过 NGINX Controllers App Security 组件启用 NGINX App Protect WAF 功能，并通过 Web 界面查看 WAF 指标。
参考资料
《NGINX App Protect WAF 管理指南》
《NGINX App Protect WAF 配置指南》
《NGINX Controller App Security 指南》
《NGINX App Protect DoS 部署指南》