对于企业来说，通往云的旅程并不像云提供商的营销视频所描述的那么容易和简单。这篇文章详细介绍了我们旅程中某个阶段的一些背景故事。
我们首先设置由ACM管理的ELB负载平衡器w/ certificates来处理面临HTTPS流量的客户。这些流量最终代理到运行WAF的现有web服务器，然后再代理到应用服务器。
我们从列出所有的NAT网关IP地址开始，这些地址会从我们的VPC攻击我们现有的WAF，这样如果我们现有的WAF阻塞了流量，它就不会避开作为我们NAT网关的IP。在这一点上，我们仍然会403恶意请求，但我们没有办法防火墙关闭IP完全停止他们的流量。
我们在AWS WAF上测试了几家供应商提供的一些托管规则，但说实话，我们只是觉得我们不了解这个产品，不知道如何配置它来真正阻止某些东西，等等。要完全取代我们现有的WAF，学习它们的WAF需要花费更多的时间。
我们仍然有一个问题，就是想要在一段时间内阻止恶意流量，一旦攻击被检测到，就像我们可以用我们的内部基础设施一样。我们需要在流量进入VPC之前阻止它。是时候写一些胶水代码了…
因此，让我们深入研究一下我们如何通过ModSecurity和AWS WAF进一步实现这一点。ModSecurity是可用的最流行的WAF (web应用程序防火墙)之一。Apache的ModSecurity已经存在很长时间了，最新的libmodsecurity 3也是如此。x把这个功能带到Nginx。ModSecurity提供的规则集范围从免费到付费和专业维护:
我们的组织长期以来一直是Atomicorp Secure Linux (ASL)的用户，因此我们非常熟悉他们的规则集、对它们进行调优，并与他们的支持进行交互。很好的合作组织。
所以让我们来看看我们今天是如何探索事物的核心。ASL管理web服务器的Apache和ModSecurity组件。当恶意请求发生时，将一个条目输出到/var/log/httpd/audit_log，然后在/var/asl/audit/data/…下面写入一个文件，处理流程如下所示。
- 我们的web服务器监视程序跟踪audit_log，读取单个事件记录，执行一些正则表达式解析，然后通过HTTPS将事件数据发送到AWS API网关
- API网关将数据推送到SQS“shun”队列中。
- 我们将“SHUN”Lambda函数连接到SQS队列，以便立即调用它。它读取有效负载(提取ELB头，等等)，与RDS数据库交互，以确定应该为给定的规则和IP的历史做什么，然后如果需要，我们更新一个绑定到黑名单规则的AWS WAF IP集。将IP放在黑名单规则的IP集中，相当于ASL运行iptables命令来避开linux防火墙级别的IP。lambda函数还将modsecurity事件有效负载的副本存储在S3中，以便以统一的方式进行进一步检查。
- 就像标准的ASL一样，您通常希望在一段时间后解除IP阻塞。因此，我们为“unshun”发送另一个SQS队列，但是这个队列被配置为有10分钟的交付延迟。
- 我们的“UNSHUN”lambda由SQS队列调用，然后决定是否应该解封IP地址。如果是这样，则从AWS WAF IP集中删除它。这个lambda函数还执行一些审计工作，以确保AWS WAF IP集中反映了我们希望基于跟踪数据库阻塞的IP。有时候，如果您有一批IP，并且必须一个接一个地重试，那么从IP集中删除一个IP将会失败。经过一些尝试和错误，使审计例程健壮。
所以我们用
- 1 API Gateway
- 1 S3 bucket
- 2 SQS queues
- 2 Lambda functions
- 1 RDS cluster (3 tables)
- AWS WAF
- ASL ModSecurity WAF
是一个基于云的WAF，具有业界领先的规则，可以在几毫秒内响应恶意请求，并在所有的esb中使用AWS WAF避开流量。
我们希望ASL能够更新他们的产品，提供与AWS WAF的直接集成来提供这个功能。在我们的理想世界，ASL会:
- 不运行本地数据库，而是所有实例都能够使用RDS Aurora MySQL数据库进行跨多个web服务器的所有事件跟踪、规则配置、IP信誉等，而无需进行glass部署。
- 通过一个简单的配置选项(当然还有分配给允许它的实例的IAM角色)管理AWS WAF IP集，将其列入黑名单
- 向SNS公开事件流信息，以便将其路由到其他各种AWS服务进行集成和分析。
我们还进行了一些实验，以构建尽可能轻的web服务器，并实现类似的阻塞功能。我们测试了下列各项:
- 从源代码编译modsecurity，在CentOS上支持JSON。这并不像你想象的那么糟糕，一旦你找到了依赖关系。
- 配置modsecurity和mlogc，直接将HTTPS PUT执行到API网关(因为它是JSON，我们可以直接进入API网关，而无需修改任何代码)
这个场景可以很好地使用OWASP核心规则集或ASL规则集，但是我们必须编写一个规则集升级引擎来自动化它，因为在那个特定的场景中我们没有完整的ASL安装。
我们做的另一件非常有效的事情是阻塞流量，其中主机头是一个数字IP地址，URL以.php结尾。这些只不过是恶意扫描器通过IP在internet上逐个查找易受攻击的PHP安装。它们会向您的服务器发出数百个请求。因此，我们现在对fire请求发出一个block，防止它们滥用我们的基础设施。
我们发现另一个有用的场景是，我们的应用程序使用403响应代码阻塞请求(这将导致生成modsecurity事件)，并包含一个HTTP响应头和一个附加的原因代码。我们的shun lambda函数看到这些事件并执行块，就像触发了实际的modsecurity规则一样。这允许我们通过利用现有的管道将应用程序级安全代码绑定到AWS WAF。
在我们的跟踪数据库中，我们也完全禁止ip在他们绊倒一定数量的块之后。这些都是持续的不良行为ip，所以我们会在很长一段时间内禁止它们。
这个管道场景的操作成本是多少?最昂贵的部分将是RDS Aurora数据库集群，但大多数AWS客户至少有一个可以利用的数据库集群。其余的API网关、SQS和Lambda处理可能是< $1/mo。编写的代码量可能少于1000行。通过WAF传输的成本将根据您正在处理的请求的数量而变化。底线是这是一个廉价的解决方案。
你能把这个解扩展到多高?AWS WAF ACL可以有10条规则，如果这些规则都是黑名单规则，那么您可以同时阻塞多达100,000 (10 x 10,000)个ip。
我们和ASL的人分享了这个想法，他们都很兴奋。我非常希望在不久的将来，我们会在ASL或OSSEC中看到对此的原生支持。
原文：https://medium.com/@jonathantew/integrating-modsecurity-with-aws-waf-f26b5af4c1a8
本文：http://pub.intelligentx.net/node/573
讨论:请加入知识星球或者小红圈【首席架构师圈】