来自Amazon应用程序负载均衡器的异常命中

Question

我有多个Amazon应用程序和弹性负载均衡器，它们背后有多个服务器。问题是负载均衡器将请求刷新到具有以下urls的服务器

    app-0 (out): info: GET /administrator/pma/ 200 1261.343 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /administrator/PMA/ 200 1287.396 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /administrator/admin/ 200 1180.192 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpMyAdmin2/ 200 1184.603 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpMyAdmin3/ 200 1262.463 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpMyAdmin4/ 200 1297.300 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpMyAdmin-3/ 200 1188.261 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /php-my-admin/ 200 1183.684 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /PMA2011/ 200 1258.948 ms - 19185
    app-0 (out):
    app-0 (out): info: HEAD /PMA2013/ 200 1290.279 ms - 19185
    app-0 (out):
    app-0 (out): info: HEAD /PMA2014/ - - ms - -
    app-0 (out):
    app-0 (out): info: GET /PMA2015/ 200 1182.416 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /PMA2016/ 200 1261.733 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /PMA2017/ 200 1289.620 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /PMA2018/ 200 1185.837 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2011/ 200 1178.948 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2012/ 200 1229.194 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2013/ 200 1320.295 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2014/ 200 1185.979 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2015/ 200 1180.451 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2016/ 200 1181.597 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2017/ 200 1271.013 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /pma2018/ 200 1185.556 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2011/ 200 1224.569 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2012/ 200 1177.819 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2013/ 200 1261.961 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2014/ 200 1184.600 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2015/ 200 1186.763 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2016/ 200 1177.270 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2017/ 200 1253.435 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmyadmin2018/ 200 1300.840 ms - 19185
    app-0 (out):
    app-0 (out): info: GET /phpmanager/ 200 1184.614 ms - 19185

像这样的urls还有很多。我没有在我的服务器上安装sql或类似的东西。这有时会让我的服务器卡住。80端口在服务器上未直接打开。只允许负载均衡器使用80端口访问服务器

Answer 1

您将无法在ELB本身中修复此问题。造成服务器阻塞的原因是，您的应用程序实际上似乎在处理请求，并且花费了相当长的时间(超过1秒)，这可能会消耗大量的CPU能力，甚至可能会消耗内存(当然，这完全取决于应用程序)。

您可以通过在ELB前面放置某种过滤器或缓存层( CloudFlare等服务可能能够处理此问题)来减轻服务器上的负载，从而缓解此问题。您还可以向您的are服务器引入一些逻辑，以确保这些调用不会传递到您的应用程序。最后，您还可以确保这些调用不会使您的设置过载，方法是确保此请求触发404消息(可能应该如此)，并且404消息是及时和轻量级的，或者(自动)扩展您的设置(扩展可能是一个实际的短期解决方案，直到您可以用另一种方式修复它，如果主要考虑的是防止停机)。

Answer 2

此攻击特征看起来像Jorgee。它是一种漏洞扫描程序。以下是我在服务器上进行Jorgee扫描的日志：

Sep 20 09:36:50 "HEAD http://x.x.x.x:80/administrator/PMA/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/administrator/admin/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin2/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin3/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin4/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpMyAdmin-3/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/php-my-admin/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2015/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/PMA2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2015/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/pma2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2011/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2012/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:36:50 "HEAD http://x.x.x.x:80/phpmyadmin2013/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2014/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2016/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2017/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmyadmin2018/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"
Sep 20 09:37:00 "HEAD http://x.x.x.x:80/phpmanager/ HTTP/1.1" 302 0 "-" "Mozilla/5.0 Jorgee"

这篇文章有一些建议，但它们都适用于服务器级别，而不是ELB级别。

您不能使用安全组阻止访问，因为安全组没有拒绝机制，只能允许。

您可以尝试使用带有自定义fail2ban过滤器的网络ACL来自动拦截IP。

Answer 3

在我的应用程序中，有一些关于AWS弹性负载均衡器级别的解决方案。我们在AWS Elastic Beanstalk环境中使用requests to the ELB are failing with 5xx之类的消息报告健康警告时遇到了问题。我们调查了这个问题，这是因为Jorgee机器人和一些更标准的扫描仪。

我所做的基本上是创建带有规则的Web，使用string condition将Host标头与我的应用程序的某个定义的域进行匹配。因此，如果bot尝试使用其IP地址请求ELB (它们通常会这样做)，它将得到403。在EB环境级别上没有更多的健康警告，我们仍然可以使用Cloudwatch轻松跟踪这些请求，所以我们仍然知道机器人发生了什么。

我在https://www.mkubaczyk.com/2017/10/10/use-aws-waf-block-bots-jorgee-500-status-elastic-beanstalk上做了一些指导，一步一步地说明如何创建这样的规则。希望它能帮上忙！它只需要亚马逊网络服务应用程序负载均衡器，但这不是一个大问题，因为你可以很容易地创建新的环境与eb-cli使用--elb-type application标志。:-)