本文の内容は、2022年6月26日にBrett Wolmaransが投稿したブログ(https://sysdig.com/blog/how-to-secure-aws-route-53-with-sysdig/)を元に日本語に翻訳・再構成した内容となっております。
人為的なミスや意図的なものであっても、クラウド上の設定変更により、突然攻撃対象が増えることがあります。AWS Route 53は、リスクのある変更を継続的に追跡する必要があるサービスの一例です。クラウドの最初の防御線として、Amazon Route 53を保護し、リスクのある設定変更を監視して、予期せぬ事態を回避することが必要です。
ご存知の方も多いと思いますが、AWS Route 53はもちろんAWSが提供する非常に人気のあるDNSサービスで、数百万のトップレベルドメインが存在します。各ドメインには、www、finance、login、supportなど、多くのサブドメインが存在すると思われます。
Route 53は、あらゆる規模の組織の多くのDNSユースケースに適用できますが、多くの作業が必要であり、実際に正しく設定されていない場合、クラウドアカウントを危険にさらす可能性があります。
Amazon Route 53のリスク
DNS攻撃を大規模なサービス拒否攻撃と同一視する人もいるかもしれませんが、クラウドで大きな問題を引き起こすには、全面的な攻撃は必要ありません。AWS ShieldとAWS Shield Advancedは、DDOS攻撃からAmazon Route 53リソースを保護するのに役立ちますが、基本的な構成に対するリスクの高い変更からは保護されません。インターネット上の私たちのDNSの姿勢に対する高レベルのリスクは、新しいドメインの登録、ドメインの削除、DNSレコードの作成または削除が含まれます。私たちのアカウントでRoute 53の変更に目を光らせておく必要があります。
AWS Route 53の現実的な問題は多くあります。
例えば、BGPハッキングによりAWS Route 53のドメインが2時間にわたって再ルーティングされ、15万ドルの暗号通貨が盗まれるという事件が発生しました。この事件ではAmazon Route 53自体の侵害はありませんでしたが、Route 53で作成されるドメインをいかに注意深く追跡する必要があるかを示しています。
もし、このような事態が発生し、AWSクラウド上の別のチームによって作成されたため、いくつかのドメインについてさえ知らなかったとしたらどうでしょう？
恐ろしいPOC
イギリス在住のセキュリティリサーチャーPatrik Hudakは、恐ろしいProof-of-Conceptで、S3バケットの登録ドメイン名をスキャンすると、バケットが乗っ取られる可能性があることを示しました。このPoCでは、列挙のための番号付けの技術を使って、攻撃者は、もはや存在しないS3バケットからコンテンツを提供しようとする孤児となったCloudfrontディストリビューションとDNSレコードを発見することができることを示しています。
これは、Route 53 DNSレコードとAWSインフラの残りの部分との間の接続を示しています。
AWS Route 53セキュリティのベストプラクティス
基本的なレベルでは、Route 53にどのドメインがあるのかを知ることは、リストの最上位にあります。誰かが、または何かが、あなたのドメインの1つを作成または削除したときに、リアルタイムで知ることもそうです。AWSは、最良の結果を得るための基本を概説する一般的なベストプラクティスのページを維持し、それに加えて、Center for Internet SecurityにおけるオープンスタンダードCIS Amazon Web Services Three-tier Web Architecture Benchmarkで見つけることができる他のベストプラクティスを提供します。
そのベストプラクティスとは、たとえば次のようなものです：
- TTLを適切に設定し、変更が反映されるのを待つ余裕を持たせる。
- ルートドメインのエイリアスレコードがELBを指すようにする。
- ルートドメインのDNSエイリアスレコードを確保する。
Sysdigは、ベストプラクティスとして監視する必要があるリスクの高い変更を特定しました。
これらは以下の通りです：
- VPCとホストゾーンの関連付け
- リソースレコードセットの変更
- ドメインの登録
CloudTrailでリスクを検索する
AWSは私たちの変更を追跡する方法なしに私たちを放置することはありません。幸いなことに、CloudTrailは本質的にすべてのための巨大な監査ログとして機能します。AWS CloudTrailは、ユーザー、ロール、AWSサービスによって実行されたすべてのアクションを追跡します。ユーザーとサービスの両方からのアクティビティは、CloudTrailイベントとして記録され、これは基本的に監査ログエントリです。AWSコンソール、AWS CLI、AWS APIのいずれでアクティビティが行われたかに関係なく、CloudTrailは動きを見逃しません。
これだけで私たちの問題は解決するのでしょうか？
CloudTrailは素晴らしいです。しかし、CloudTrailは有罪か無罪かを判断するようには設計されていません。CloudTrailは、我々のアカウントにおける完全に正当な変更と、我々の攻撃対象領域を突然拡大するような変更を区別することができません。また、たとえできたとしても、CloudTrailには警告と報告のメカニズムがありません。CloudTrailは巨大な干し草の山と考えることができ、AWSアカウントにおけるリスクのある変更は本当に小さな小さな針と考えることができます。
これらの針を手動で（手で！）見つけるのは骨が折れますし、スケールもしません。
他のAWSサービスと同様に、AWS Route 53に関しても、必要なのはリアルタイムのアラート、レポート、可視化のためのダッシュボード、セキュリティチームのための役割ベースのアクセスコントロール、そしてリスクの高いイベントを把握するための多くのサポート専門機能などのための自動化されたソリューションで す。
AWSが提供するネイティブなツールを使って、これらの欠けている部分の多くを腕まくりして構築することは楽しそうに聞こえるかもしれませんが、私たちのテストでは、多くの苦労をした後でも、やや複雑な結果になることに驚かされました。
クラウド開発者のチームがあればいいのですが、残念ながらそのような贅沢はあまりできません。それ以外の人は、すぐに使えるものが欲しいのです。そこで、Sysdig Secureの出番となります。
Sysdig SecureとCloudTrailでリスクを発見する
SysdigはCloudTrailを監視することで、家を見守る防犯カメラのように、CloudTrailが何かを見た瞬間にSysdigもそれを見ています。しかし、CloudTrailとは異なり、Sysdigは善悪を判断し、誰が、何を、いつ、どこで、どのように行ったかを通知し、私たちが行動を起こせるようにします。
Sysdig Secureは、以下のリスクの高いAWS Route 53イベントに対して、これらのルールを含んでいます：
| Sysdig Falco ルール | 説明 | なぜそれが重要なのか？ |
VPCとホストされたゾーンの関連付け | このルールは、Amazon VPCとプライベートホストゾーンの関連付けを検出します。 | これにより、VPC内のIPアドレスがDNSプロービングによって解決されるようになります。 |
リソースレコードセットの変更 | ウェブサイトの名前などのリソースレコードセットの作成、変更、削除を検出します。 | 新しいDNSエントリーを追跡する必要があります。最も重要なサイトのDNSは、知らない間に変更または削除されてはなりません。 |
ドメイン登録 | 新しいドメインの登録を検出します。 | ドメインにはすべてのリソースレコードが含まれており、ドメインの登録は正当なビジネス上の理由なしに行われるべきではありません。 |
リスクのあるAWS Route 53イベントを見つけるには、まずCloudTrailで、次にSysdig Secureで試してみて、その違いをご自身の目で確かめてください：
CloudTrail + Sysdig：より良いコンビネーション
CloudTrailのどこかに、イベントが埋もれた宝物のように隠れています。しかし、本物の宝物と同じように、これは攻撃者を玄関先まで引き寄せることができます。私たちはすでに、AWS RDSとAWS EC2の興味深いCloudTrailイベントの例を示すブログを公開しています。SysdigはCloudTrailをマイニングし、クラウドアカウントを保護するために必要な誰が/何を/いつ/どこで/どのようにを提供します。
AWS Route 53を保護するためのルールがすぐに利用でき、オープンソースのFalco構文を使ってルールセットを簡単に拡張することができます。
Sysdigは、深い可視性と豊富なコンテキストでリスクを一望できるため、問題を迅速に発見し修正することができます。
しかし、私たちの言葉を鵜呑みにしないでください。もしお時間があれば、今日から無料で始めて、ご自分の目でその証拠を確かめてください。