在预算内处理 Web 服务器安全威胁的正确方法

在预算内处理 Web 服务器安全威胁的正确方法

在我们的年度安全审查中,我想起了今年早些时候发生的一起事件,当时我们收到了针对我们组织网络服务器的威胁。这是针对组织政策的,并威胁要对我们的网站进行 DDoS 攻击。幸运的是,这并没有造成什么不良后果,最终只是一场空洞的威胁。然而,我们仍然立即通知了 CIO、CSO、CEO 和我们的托管服务提供商,他们对我们的反应表示赞赏。由于我们组织的性质(教育领域),先发制人的响应涉及许多人,包括与当地执法部门的协调。

尽管我们的反应足以构成空洞的威胁,但它让我意识到该 Web 应用程序经过的攻击计划是多么的少。目前的设置是:

  • 未受企业防火墙保护的 Linode VPS(这背后有一个很长的故事,不值得解释)
  • 同一服务器上的 PostgreSQL 数据库仅允许本地连接
  • 我们目前正在遵循最佳实践来保护 Nginx 服务器1]
  • 我们正在迁移到证书身份验证的 SSH 访问
  • 具有所有最新服务器设置的备份 VPS,只需要推送最新版本的代码并迁移数据库设置(目前用作测试服务器,但也设想作为地理冗余选项)

我想我的问题可能可以归结为我应该采取哪些其他步骤来锁定我的服务器并防止 DDoS?我们很乐意使用Cloudflare 商业他们的 DDoS 保护功能,但我们并不总是需要它,而且每月 200 美元对组织来说有点高。我是否真的需要这个?是否有允许临时 DDoS 保护的解决方案?如果没有,在攻击期间/之后保持稳定性的最佳方法是什么?最后,应该实施哪些日志记录,以便我们在发生攻击时协助执法?

答案1

我还应该采取什么步骤来锁定我的服务器并防止遭受 DDoS 攻击?

  1. 用防火墙关闭所有未使用的端口和协议。在适用和可能的情况下,仅限制对受信任 IP 的访问。
  2. 及时应用所有安全补丁和更新
  3. 实施网络监视器,可以对可疑活动爆发发出警报

每月 200 美元对于组织来说有点高。我是否真的需要这个?

不,直到它增加了价值并且成为必需品为止。

是否有提供临时 DDoS 保护的解决方案?

是的。他们可能需要投入大量的前期时间来处理实施 DDoS 服务的复杂问题。 http://www.blacklotus.net/protect/emergency-ddos-protection就是这样一种按需服务。

如果不是,那么在攻击期间/之后保持稳定的最佳方法是什么?

就坐在那里接受吧。这就是 DDoS 的本质。你可以尝试用防火墙封锁 IP,但如果攻击真的是分布式的……那就像用水枪扑灭野火一样。

最后,应该实施哪些日志记录,以便我们在发生攻击时能够协助执法部门?

维护传入源 IP 和时间戳以及任何其他相关取证数据的日志。例如,如果它是 Web 服务器,请尝试记录用户代理和所请求的资源。流量速率(例如每秒数据包数和每秒请求数)很有帮助。

DDoS 归根结底是数学分析。如果有人试图敲诈你,他们就认为他们可以破坏你的业务,迫使你支付保护费来防止这种情况发生。规模是一个因素,打倒小运营商更容易,但他们支付的费用更少。如果你收到电子邮件威胁 - 最好的做法是忽略它。发起和维持 DDoS 攻击需要大量的僵尸网络资源 - 他们不能像垃圾邮件发送者那样直接轰炸所有人。他们很可能只是在进行大规模的网络钓鱼攻击,寻找容易恐吓的目标。由于 DDoS 野兽的性质,受害者相当无助,除非他们可以部署复杂的数据包过滤预防方案或有预算来承包外部服务。

答案2

inetplumber 的回答很棒。

我想补充的是,另一个选项是将应用程序配置为可扩展的,这样您就可以处理更大规模的攻击而不会影响您的用户。例如,您可以在 Amazon AWS 上设置虚拟私有云 (VPC),您的 PostgreSQL 服务器只能从 VPC 内部访问。您可以设置负载平衡器前端,以在多个服务器之间分配负载。

这样做的好处是,您可以快速扩展到 100 台(或更多)服务器,无需前期投资,而且速度非常快(如果您已经配置好),使您成为更难攻击的目标。您只需在实际受到攻击的时段支付这些服务器的费用。当您没有受到攻击时,您只需支付一台 Web 服务器和一台数据库服务器的费用。

最难的部分是设置,这肯定比您当前的配置更复杂一些。设置以快速扩展需要做更多工作。但是,如果您正在寻找可以做计划的事情(特别是如果由于其他问题,您认为自己将来可能会成为目标),那就可以了。

答案3

我还应该采取什么步骤来锁定我的服务器并防止遭受 DDoS 攻击?

  1. 如果你的 webapp 不是交互式的,只是显示内容:使用 nginx + proxy-cache 并设置较短的缓存时间(通常 1-5 分钟就可以了)。这可以大大提高性能,并迫使攻击者分配更多资源

  2. 设置一个限制防火墙,过滤掉所有不需要的东西进进出出通过将 INPUT/OUTPUT/FORWARD-Policy 设置为 DROP;确保记录每个传出连接尝试(UPD 端口 53 除外:)

  3. 如果你不能将 SSH 限制到静态管理 IP,请使用备用高端口,如 22222,这将防止出现大量“你好 mcfyl - 有人在那里” - knockers

  4. 此外,使用 fail2ban/denyhosts 保护 ssh 免受暴力攻击

  5. 如果你有管理资源:使用 OSSEC 和轻量级 WAF(nginx 有 naxsi,轻量级,不像 mod_security 那么麻烦),但你需要有人来设置和维护这些安装

  6. 实施备份并使用备用服务器作为备份目标

  7. 保持你的web应用程序代码为最新版本;如果你使用开源项目,请注册他们的安全邮件列表。

  8. 尽量避免使用已知存在大量漏洞的软件

  9. 如果您使用 admin-login 和/或 managament-webapps:为这些登录名 + ssl 建立基本身份验证(自签名证书就可以了)。

  10. 尽可能使用 ssh-tunneling 而不是打开端口,例如用于开发

如果不是,那么在袭击期间/之后保持稳定的最佳方法是什么

  1. 保持冷静
  2. 让有经验的人处理这种情况
  3. 准备好一些应急计划

您已经做的最重要的事情:在事情发生之前考虑它(以及可能的对策)。

相关内容