DDoS攻撃の対策を考えてみる » 履歴 » バージョン 1
健二 酒井, 2018/07/08 01:28
| 1 | 1 | 健二 酒井 | # 金銭的DDoS攻撃の対策を考えてみる |
|---|---|---|---|
| 2 | 1 | 健二 酒井 | |
| 3 | 1 | 健二 酒井 | ### 背景 |
| 4 | 1 | 健二 酒井 | |
| 5 | 1 | 健二 酒井 | 仕事で考えなきゃいけなくなった。とりあえず試算もしてみたし諦めて考えてみる。 |
| 6 | 1 | 健二 酒井 | |
| 7 | 1 | 健二 酒井 | ## 金銭的DDoS？ |
| 8 | 1 | 健二 酒井 | |
| 9 | 1 | 健二 酒井 | 通常のDDoS攻撃はサービス断を狙ってくる。パブリッククラウドを利用したらこれらは解消されるかもしれない。 |
| 10 | 1 | 健二 酒井 | ただ、ネットワークの従量課金やリクエスト数に対する従量課金があるのでそこの金銭的被害を減らしたい。 |
| 11 | 1 | 健二 酒井 | |
| 12 | 1 | 健二 酒井 | ### 攻撃手法と切り口 |
| 13 | 1 | 健二 酒井 | |
| 14 | 1 | 健二 酒井 | まずは攻撃方法を知らないと対策建てられん。以下から引用： |
| 15 | 1 | 健二 酒井 | |
| 16 | 1 | 健二 酒井 | https://www.shadan-kun.com/blog/measure/1426/#05 |
| 17 | 1 | 健二 酒井 | |
| 18 | 1 | 健二 酒井 | > DDoS攻撃の概要 |
| 19 | 1 | 健二 酒井 | > SYNフラッド攻撃、FINフラッド攻撃 |
| 20 | 1 | 健二 酒井 | > ACKフラッド攻撃 |
| 21 | 1 | 健二 酒井 | > UDPフラッド攻撃 |
| 22 | 1 | 健二 酒井 | > |
| 23 | 1 | 健二 酒井 | > UDPフラッド攻撃 — ランダム・ポート・フラッド攻撃 |
| 24 | 1 | 健二 酒井 | > UDPフラッド攻撃 — フラグメント攻撃 |
| 25 | 1 | 健二 酒井 | > |
| 26 | 1 | 健二 酒井 | > HTTP GET/POST Flood攻撃 |
| 27 | 1 | 健二 酒井 | > Slow HTTP DoS Attack |
| 28 | 1 | 健二 酒井 | > Connection Exhaustion攻撃 |
| 29 | 1 | 健二 酒井 | > Stream Flood攻撃 |
| 30 | 1 | 健二 酒井 | > DNS Flood attacks（DNSフラッド攻撃） |
| 31 | 1 | 健二 酒井 | > |
| 32 | 1 | 健二 酒井 | |
| 33 | 1 | 健二 酒井 | #### レイヤー |
| 34 | 1 | 健二 酒井 | |
| 35 | 1 | 健二 酒井 | SYNフラッド、ACKフラッド、UDPフラッドなどはL4を狙った攻撃。 |
| 36 | 1 | 健二 酒井 | HTTP GET/POST Flood、Slow HTTP DoSなんかはHTTPとついている通りL7を狙った攻撃。 |
| 37 | 1 | 健二 酒井 | |
| 38 | 1 | 健二 酒井 | L4の攻撃だとWebアプリ側まで到達しないのでファイアウォールとか使ったネットワーク的な対処がメインになる感じ。 |
| 39 | 1 | 健二 酒井 | L7の攻撃だとTCP的には正常なのでWAF入れるとか、Webサーバの設定とかそこら辺が登場してくる感じ。 |
| 40 | 1 | 健二 酒井 | |
| 41 | 1 | 健二 酒井 | #### 洪水と旱魃 |
| 42 | 1 | 健二 酒井 | |
| 43 | 1 | 健二 酒井 | どっちもリソースの枯渇を狙ってくるのには違いないけど、面白いことに2種類ある。技術的には、 |
| 44 | 1 | 健二 酒井 | 「大量の要求を送り付けて相手の資源枯渇させる」パターンと、「長期間使い続けて資源を相手の資源を枯渇させる」パターン。 |
| 45 | 1 | 健二 酒井 | 前者のパターンは〇〇フラッド攻撃全般が該当する。後者のパターンはSlow HTTP DoSが該当かな。HTTPだけじゃなくてTCPのパターンもあったはず。 |
| 46 | 1 | 健二 酒井 | 今回問題になるのは前者かな、後者はトラフィックは自体が少なくなる金銭的な被害は少なくなる。 |
| 47 | 1 | 健二 酒井 | |
| 48 | 1 | 健二 酒井 | ### ネットワークとサーバ |
| 49 | 1 | 健二 酒井 | |
| 50 | 1 | 健二 酒井 | 通常はサーバを狙ってくる攻撃だけど、その前段にあるネットワークが先に枯渇するケースもある。 |
| 51 | 1 | 健二 酒井 | ロードバランサやファイアウォールが高級でも接続されてる回線がしょぼいと意味がない。 |
| 52 | 1 | 健二 酒井 | 今回はパブリッククラウドが想定なのでどっちも枯渇はしない。枯渇するのはお財布。 |
| 53 | 1 | 健二 酒井 | |
| 54 | 1 | 健二 酒井 | ## ポイントと対策 |
| 55 | 1 | 健二 酒井 | |
| 56 | 1 | 健二 酒井 | L4以下の攻撃はWAF（AWS WAF、GCP Cloud Armor）なんかを挟むことで対処できそう。パブリッククラウド事業者が元々敷いてるセキュリティで対処してくれたりするっぽい。 |
| 57 | 1 | 健二 酒井 | |
| 58 | 1 | 健二 酒井 | 金銭的に問題になるのはDNSやHTTP POST Floodを利用するケース。なんでかっていうと、パブリッククラウドの課金は |
| 59 | 1 | 健二 酒井 | |
| 60 | 1 | 健二 酒井 | * 利用回数・リクエスト回数 |
| 61 | 1 | 健二 酒井 | * ネットワーク使用容量・ネットワークの使用帯域 |
| 62 | 1 | 健二 酒井 | |
| 63 | 1 | 健二 酒井 | に対して発揮されるから。大量のDNSリクエストとか、大量データの送付とかされるとそれが金銭的な攻撃になる。 |
| 64 | 1 | 健二 酒井 | ネットワークの料金はおおざっぱに言って「クラウドの内側同士は無料」、「外側が関わると有料」なケースが多い。被害を減らすには通信自体を減らす。 |
| 65 | 1 | 健二 酒井 | なので以下が主な対策になるかと思う。 |
| 66 | 1 | 健二 酒井 | |
| 67 | 1 | 健二 酒井 | * 受け口のトラフィック料金を安くする。 |
| 68 | 1 | 健二 酒井 | * 敵対的なトラフィックは受け口に近い部分で遮断する。 |
| 69 | 1 | 健二 酒井 | |
| 70 | 1 | 健二 酒井 | 前者はサービス・料金表とにらめっこするしかないかなぁ。関係してくるのはDNS、CDN、ロードバランサ、インターネットからの接続を受けるサーバあたりだと思う。 |
| 71 | 1 | 健二 酒井 | 後者は、例えばサービスへのトラフィックがCDN→ロードバランサ→サーバって受け渡されるとすると、CDN部分で締め出せばトラフィックがロードバランサまで到達しなくなるから、ロードバランサの料金が増えなくなる。 |
| 72 | 1 | 健二 酒井 | |
| 73 | 1 | 健二 酒井 | ### まとめ |
| 74 | 1 | 健二 酒井 | |
| 75 | 1 | 健二 酒井 | やれそうなことは。 |
| 76 | 1 | 健二 酒井 | |
| 77 | 1 | 健二 酒井 | * 課金アラームの設定。検知しなければそもそも対処できない。 |
| 78 | 1 | 健二 酒井 | * L4以下はクラウド事業者で弾いてもらうような構成 |
| 79 | 1 | 健二 酒井 | * WAFを適応的に（アクセス過多なIPを検知したら、そのイベントでWAFルールを自動で変更（ブラックリストに追加）） |
| 80 | 1 | 健二 酒井 | * CDNの利用する。 |
| 81 | 1 | 健二 酒井 | * クラウド側ネットワークのファイアウォールを設定 |
| 82 | 1 | 健二 酒井 | * 金銭補償サービスの導入（ひらたく言えばサイバー保険） |
| 83 | 1 | 健二 酒井 | * 受け口となるサービスを解除（当然サービス断） |
| 84 | 1 | 健二 酒井 | |
| 85 | 1 | 健二 酒井 | とかだろうか。根絶とか被害ゼロを目指すのは不可能だと思うなぁこれ…。 |
| 86 | 1 | 健二 酒井 | |
| 87 | 1 | 健二 酒井 | http://www.digitalattackmap.com/ |
| 88 | 1 | 健二 酒井 | ただ、こういうの見ると、DDoS攻撃はL4以下を狙うのが主流っぽいのでこれらを排除するだけでも被害にあう可能性が減るんじゃないかなぁ。 |
| 89 | 1 | 健二 酒井 | |
| 90 | 1 | 健二 酒井 | ## 参考 |
| 91 | 1 | 健二 酒井 | |
| 92 | 1 | 健二 酒井 | https://www.shadan-kun.com/blog/measure/1426/#05 |