Amazonのアプリケーションロードバランサの珍しいヒット

私は複数のAmazonアプリケーションとそれらの背後に複数のサーバーを持つ伸縮性のあるロードバランサを持っています。問題は、ロードバランサのようなURLを持つサーバーへのリクエストです。Amazonのアプリケーションロードバランサの珍しいヒット

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

これらのようなURLがたくさんあります。私はSQLや何かこれは私のサーバーにインストールされているようなことはありません。これは私のサーバーを何度か窒息させます。ポート80はサーバー上で直接開かれません。ポート80を使用してサーバーにアクセスできるのはLoadbalancerのみです

出典

2017-09-20 Asif Saeed

https://unix.stackexchange.com/questions/374756/how-to-handle-aggressive-http-requests-from-the-same-ip – titogeo

なぜサーバーが200に戻るのですか？あなたのサーバー上で実行されている他のプロセスはありません。過去に私たちのサーバーにハックしてミニクラフトサーバーを起動したところ、これはあまりにも多くのhttp要求 – titogeo

これはELB自体では解決できません。これがあなたのサーバーを窒息させる理由は、あなたのアプリケーションが実際に要求を処理しているように見えるので、それを実行するのにかなりの時間がかかります（おそらくCPUパワーを多量に消費し、おそらくメモリを消費します））。

ELBの前に何らかの種類のフィルタやキャッシュレイヤー（CloudFlareなどのサービスがこれを処理できる可能性があります）を配置して、サーバーの負荷を軽減することで、問題を緩和できます。これらの呼び出しがアプリケーションに渡されないように、Webサーバーにいくつかのロジックを導入することもできます。最後に、これらの呼び出しが、この要求によって404メッセージ（おそらくすべきです）と404メッセージが迅速かつ軽量であることを保証するか、（自動）設定をスケールすることによってセットアップが過負荷にならないようにすることもできます停止時間を防ぐことが主な関心事である場合は、別の方法で修正するまで実際の短期的な解決策になります）。

出典

2017-09-20 14:40:40

この攻撃シグネチャは、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レベルでの作業をいくつかの提案を持っていますが、それらすべてのこと：ここに私のログは私のサーバー上でスキャンJorgeeからです。

セキュリティグループを使用してアクセスをブロックすることはできません。拒否メカニズムを持たないため許可されません。

カスタムfail2banフィルタを使用してネットワークACLを使用して、IPを自動ブロックすることができます。

出典

2017-09-20 15:03:41

私のアプリケーションには、AWS Elastic Load Balancerレベルのいくつかの解決策があります。 requests to the ELB are failing with 5xxのようなメッセージでAWS Elastic Beanstalkの環境に関する警告メッセージに問題がありました。問題を調査したところ、それはJorgeeボットといくつかの標準的なスキャナが原因でした。

基本的に、string conditionを使用してHostのヘッダーと私のアプリケーション用の定義済みドメインを一致させてWeb ACLを作成していました。したがって、ボットがELBにIPアドレス（一般的には）を要求しようとすると、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で新しい環境を簡単に作成できるため、大きな問題はありません。 :-)

出典

2017-10-10 16:24:54 mkubaczyk

Amazonのアプリケーションロードバランサの珍しいヒット

答えて

関連する問題