时间戳

首页 > 解决方案 > 直接 IP 攻击，ElastickBeanstalk/NGINX

amazon-web-services - 直接 IP 攻击，ElastickBeanstalk/NGINX

问题描述

我的网站有点问题。所以设置是 ElasticBeanstalk(NGINX) + Cloudflare

但是每天凌晨 4 点左右，我都会对我的服务器进行直接 IP 攻击。大约 300 个请求在 1-2 分钟内。机器人尝试访问一些资源，例如

GET /phpMyadmi/index.php HTTP/1.1
GET /shaAdmin/index.php HTTP/1.1
POST /htfr.php HTTP/1.1

现在他们都去80或8080端口。并由 Nginx 配置成功处理，将其重定向到 example:443

server {
        listen 80 default_server;
        listen 8080 default_server;
        server_name _;
        return 301 https://example.com$request_uri;
      }

      server {
        listen 443 ssl;
        server_name example.com;
        ssl on;    
...

所以问题是，

  1. 有许多网站所有者/devOps 面临同样的攻击。您采取了哪些措施来防止此类攻击。
  2. 目前处理得很好，不影响服务器工作，我应该担心吗？或者只是使用 /phpmy/ 模式过滤掉日志并忘记它。
  3. 在此攻击之前，我使用 PROPFIND 方法请求，出于安全原因，我应该阻止它吗？它现在由默认服务器处理。

我知道我可以使用 Cloudflare Argotunel 或 ELB + WAF。但我现在并不想这样做。

我在stackoverflow上找到了一种解决方案。是所有 cloudflare ip 的白名单。但我认为这不是一个好的。

我猜另一个应该可行的解决方案是检查主机标头，并将其与“example.com”进行比较。

标签： amazon-web-servicessecuritynginxdevopsddos

解决方案

要回答您的具体问题：

  1. 每个公共 IP 都会收到您所描述的不需要的流量，遗憾的是这很正常。这并不是真正的攻击，它只是一个寻找特定弱点迹象的机器人，或者试图引发包含有用数据的响应。毫无疑问，这些数据后来被用于实际攻击，但它基本上是在潜在的大规模上自动识别。

  2. 这种脚本可能不会试图造成任何损害，所以只要您的服务器配置良好并完全修补它就不是一个大问题。然而，这些类型的扫描是发起攻击的第一步——通过识别具有已知漏洞的服务和应用程序版本——因此保留日志以供分析是明智之举。

  3. 您应该遵循最小特权原则。PROPFIND 与 WebDAV 相关 - 如果您不使用它，请禁用它（或者更好地将您支持的动词列入白名单并忽略其余部分）。

如果您的站点已经在 CloudFlare 之后，那么您确实应该通过防火墙访问您的 IP，以便只有 Cloudflares IP 可以与您的服务器通信。这些 IP 确实会发生变化，因此我建议使用脚本从https://www.cloudflare.com/ips-v4下载最新版本，并让它定期更新您的防火墙。CloudFlare 有一篇关于这个主题的稍微有点语言的帮助文章：https: //support.cloudflare.com/hc/en-us/articles/200169166-How-do-I-whitelist-Cloudflare-s-IP-addresses-in -iptables-

如果由于某种原因您无法对 IP 进行防火墙保护，那么您的下一个最佳选择是类似 fail2ban (www.fail2ban.org) - 它是一个日志解析器，可以根据您的日志中找到的模式操作防火墙以临时或永久阻止 IP 地址文件。

最后的想法 - 建议不要从你的 IP 重定向到你的域名 - 你告诉机器人/黑客你的 URL - 然后他们可以使用它绕过 CDN 并直接攻击你的服务器。除非您有某些理由允许 HTTP/HTTPS 流量到您的 IP 地址，否则请在请求到达您的 IP 时返回 4XX（可能是 444 “连接关闭而没有响应”）而不是重定向。然后，您应该创建一个单独的服务器块来处理您的重定向，但只让它响应真正的命名 URL。

推荐阅读