AWSでお勧めのF5アタック対策
- 評価
- クリップ 3
- VIEW 2,940
前提・実現したいこと
タイトルにf5アタックとしたのは今回想定しているのは
いわゆるプログラムなどの攻撃ではなく通常の閲覧や
サイト更新者の操作で問題が発生している可能性が高いためです。
AWSでサイトを表示させるところまではできたのですが
f5キーを連打するとロードバランサの状態がOut Of Serviceになり
サイト自体も応答しませんとなります。
EC2のインスタンスの状態、ステータスチェックはOK(緑のチェック)です。
そこで以下のような構成の場合どのように、どの部分で対策を取るのがお勧めでしょうか。
環境、アプリケーション
route53→ELB→EC2→nginx→phpfpm→RDSの構成でwordpressを動かしています。
centosは7です。
EC2、RDS共にインスタンスタイプ(CPUスペック)は一番低いものに設定しております。
DNSでのキャッシュ、wordpressプラグインを用いたサーバ側でのキャッシュも
まだ設定していない状態です。(将来的にはcloudfront,s3も絡めたキャッシュを予定しています)
試したこと
【1】nginxのconfファイルでDDos対策として紹介されていた以下の設定をしてみました。
リロードを連打するときちんと503を返してくれるものの
ページ読み込み速度が10倍近く遅くなりました。
(複数読み込んでいる画像のロード時間が顕著に遅くなっていました。)
http {
limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=1r/s;
limit_req_log_level error;
limit_req_status 503;
}
server {
location / {
limit_req zone=limit_req_by_ip burst=10;
...
}
}
【2】linuxの/etc/sysctl.confファイルに以下を設定しましたがこちらも効果はありませんでした。
net.ipv4.tcp_fin_timeout=15
追記後以下実行
sysctl -p
【3】route53のRouting Policyのgeolocationでjapanの設定をしてみましたがgoogleのボットがはじかれてしまいやめました。
疑問点
・現在cloudfrontの導入も検討しており調査しておりますが情報が見つけられませんでした。
こちらで上記nginxのような設定が可能なのでしょうか。またroute53等でも可能なものなのでしょうか。
・上記nginxでも実現はできたのでページが遅くならない方法がありましたらご教授願います。
・nginxで設定した場合、もし仮にDDOSを大量に浴びてしまった場合通信量(パケット料金)は比例して増えてしまうのでしょうか。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+1
通常の閲覧やサイト更新者の操作
攻撃ではなく通常の観閲、操作でヘルスチェックが失敗する原因は以下が考えられます。
1.nofileが不足
2.各M/Wの同時接続数(nginx, mysql)
3.アプリが動作するのにEC2のスペックが不足(1コネクションあたりの処理が遅くなり、詰まっている)
ログ等を確認し、ヘルスチェックに失敗している原因をまず確認してから対策について検討すべきです。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
通常の閲覧やサイト更新者の操作で問題が発生している可能性が高い
ユーザビリティを考えると、アプリケーションで対応するのが良いのではないでしょうか?
連続アクセスをアプリケーションでカウントして、一定時間内のアクセスが想定するものより多すぎる場合、警告ページに飛ばすことで対応できるかと思います。
故意の攻撃を防ぎたいのであれば、別の対策が必要かと思いますが。
どちらの対応が必要なのか整理して下さい。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう!
- ただいまの回答率 88.10%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2017/09/14 23:02
アドバイスいただきました項目につきまして
nofileというのは初めて聞きました、またその他の項目に関しても
調査が必要という認識も薄かったためあらためて調査してみます。
ログの見方も現在独学で勉強中という状況で
linuxに関してもまだまだ初心者の域を出られず少し時間がかかりそうですので
また不明点が出てきた際はご質問させていただきたいと思います。
参考になりました!ありがとうございました!