☰

AWS EC2 实例在被机器人扫描时崩溃

tag-icon • tag-icon amazon-web-services amazon-ec2 apache-2.4 attacks
AWS EC2 实例在被机器人扫描时崩溃

我已经基于 Amazon Linux AMI 创建了一个简单微型 EC2 实例，用于在开发应用程序时对其进行测试，但它每天都会停止响应并出现错误 503。它使用 Cloudfront 设置了自己的域。

在 AWS 上，实例显示为绿色且“正在运行”，但甚至无法通过 SSH 进行连接，直到我停止并重新启动它（而且实例重启选项根本不起作用）。

当我检查 HTTPD 日志时，我看到一大串似乎是机器人试图查找易受攻击的页面的列表：

[Wed May 22 08:10:17.996810 2019] [:error] [pid 26550] [client ...] script '/var/www/html/pop.php' not found or unable to stat
[Wed May 22 08:10:21.276648 2019] [:error] [pid 26550] [client ...] script '/var/www/html/ok.php' not found or unable to stat
[Wed May 22 08:10:21.454696 2019] [:error] [pid 26550] [client ...] script '/var/www/html/test.php' not found or unable to stat
[Wed May 22 08:10:21.641293 2019] [:error] [pid 26550] [client ...] script '/var/www/html/conf.php' not found or unable to stat
[Wed May 22 08:10:22.187275 2019] [:error] [pid 26550] [client ...] script '/var/www/html/dashu.php' not found or unable to stat
...

是否有人知道一个简单的解决方案来避免这种情况并让这个简单的测试服务器正常运行而不必每天重新启动它？

答案1

如果您已经启用了 CloudFront，则可以添加 WAF 保护，尽管对于此用例来说这似乎有些过度。您还可以尝试使用 NGINX 而不是 Apache，因为它更轻量，因此不太可能耗尽资源。

CloudWatch 是否能提供任何有关其崩溃原因的见解？也许您可以确定耗尽了哪些资源。可能是连接数或带宽问题，而不是内存或 CPU。

另一种选择是使用 CloudFlare 而不是 CloudFront，它应该提供更好的反机器人保护并且更便宜。

答案2

在开发过程中，你可以将实例的访问限制为仅允许你的 IP 地址访问 - 在实例中设置它们安全组。这将阻止除您之外的任何人访问。

另一方面，实例不应该仅仅因为收到一些随机请求而失败。您的代码可能有问题 - 可能是内存泄漏？现在是修复它的好时机，因为正如您所说，您仍处于开发阶段。

希望有帮助:)

相关内容