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

时间：2017-09-20 13:00:21

标签： amazon-web-services

我有多个亚马逊应用程序和弹性负载均衡器，后面有多个服务器。问题是对具有诸如

等网址的服务器的负载均衡器刷新请求 
    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

还有很多这样的网址。我的服务器上没有安装sql或类似的东西。这有点呛我的服务器。端口80未在服务器上直接打开。只允许Loadbalancer使用端口80访问服务器

3 个答案:

答案 0 :(得分：1)

您将无法在ELB中修复此问题。这会扼杀你的服务器的原因是你的应用程序实际上似乎处理请求并花了很长时间才能做到这一点（超过1秒），这可能会消耗大量的CPU能力，甚至可能消耗内存（这一切都取决于应用程序的当然）。

您可以通过在ELB前放置某种过滤器或缓存层（CloudFlare之类的服务可能能够处理此问题）来减轻问题，从而减轻服务器的负担。您还可以向Web服务器引入一些逻辑，以确保这些调用不会传递给您的应用程序。最后，您还可以通过确保此请求触发404消息（可能应该）以及404消息提示和轻量级，或通过（自动）扩展设置来确保这些调用不会使设置过载（扩展可能如果能够以其他方式解决问题，那么这是一个实际的短期解决方案，如果防止停机是主要问题的话。）

答案 1 :(得分：0)

此攻击签名看起来像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。

答案 2 :(得分：0)

我的应用程序中的AWS Elastic Load Balancer级别有一些解决方案。我们在AWS Elastic Beanstalk环境中遇到问题，使用requests to the ELB are failing with 5xx等消息报告运行状况警告。我们调查了这个问题，那是因为Jorgee机器人和一些更标准的扫描仪。

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

我在https://www.mkubaczyk.com/2017/10/10/use-aws-waf-block-bots-jorgee-500-status-elastic-beanstalk上做了一些指导，一步一步地指示创建这样的规则。希望能帮助到你！它只需要AWS Application Load Balancer，但这不是一个大问题，因为您可以使用--elb-type application标志轻松创建具有eb-cli的新环境。 ： - ）

相关问题
最新问题