はじめに

Amazon Route 53 Resolver DNS Firewall は VPC からのアウトバウンド方向の DNS リクエストを保護するためのサービスで、特定のドメイン名以外の名前解決をさせない、良くないと判定されているドメイン名の名前解決をさせない、といったことができる保護機能のサービスです。

以前から東京リージョンでも利用できたサービスですが、A レコード、NS レコード等のクエリタイプでのフィルタリングができるようになりました。

Amazon Route 53 Resolver DNS Firewall で、クエリタイプフィルタリングのサポートを開始

このアップデートに興味があったため、実際に検証環境を作って確認してみたいと思います。
VPC 内に EC2 インスタンスを起動し、DNS Firewall の導入前後での DNS クエリの挙動確認を行います。

 

検証に使用した環境

EC2 インスタンスの OS は何でも問題ありませんが、今回は Amazon Linux 2023 にしました。

AMI名 AMI ID
Amazon Linux 2023 AMI 2023.4.20240401.1 x86_64 HVM kernel-6.1 ami-0bdd30a3e20da30a1 
~ $ ssh s-takahashi_ec2-1
Warning: Permanently added '18.181.202.7' (ED25519) to the list of known hosts.
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
[ec2-user@ip-10-0-1-98 ~]$
[ec2-user@ip-10-0-1-98 ~]$ cat /etc/system-release
Amazon Linux release 2023.4.20240401 (Amazon Linux)

 

DNS Firewall導入前の動作確認

まずは DNS Firewall を構築する前に、弊社サイト https://cloudpack.jp/ の A レコード、NS レコードを引きました。

A レコードは 54.168.234.169 および 13.112.148.66 が返ってきています。

DNS レコードを取得 (A レコード)

[ec2-user@ip-10-0-1-98 ~]$ dig A cloudpack.jp

; <<>> DiG 9.16.48-RH <<>> A cloudpack.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52750
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloudpack.jp.                  IN      A

;; ANSWER SECTION:
cloudpack.jp.           60      IN      A       54.168.234.169
cloudpack.jp.           60      IN      A       13.112.148.66

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 09 09:08:39 UTC 2024
;; MSG SIZE  rcvd: 73

DNS レコードを取得 (NS レコード)

[ec2-user@ip-10-0-1-98 ~]$ dig NS cloudpack.jp

; <<>> DiG 9.16.48-RH <<>> NS cloudpack.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34470
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloudpack.jp.                  IN      NS

;; ANSWER SECTION:
cloudpack.jp.           86400   IN      NS      ns-607.awsdns-11.net.
cloudpack.jp.           86400   IN      NS      ns-1495.awsdns-58.org.
cloudpack.jp.           86400   IN      NS      ns-1784.awsdns-31.co.uk.
cloudpack.jp.           86400   IN      NS      ns-282.awsdns-35.com.

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 09 09:08:56 UTC 2024
;; MSG SIZE  rcvd: 181

  

DNS Firewall ルールグループを作成

Amazon Route 53 Resolver DNS Firewall は Route 53 の機能の一部なので Route 53 のコンソールから作成画面に入ることができます。

また、VPC と関連付けて利用するサービスであるため VPC のコンソールからも確認が可能です。

ルールグループ名は s-takahashi-rulegroup としました。

次にルールを追加します。
今回の検証では 弊社サイト https://cloudpack.jp/ の A レコードを引けないように遮断するシンプルなルールを作成しました。

スクリーンショット中段の「クエリの種類-オプション」という部分があり、ここが今回のアップデートで追加された機能です。

Action は ALLOW / BLOCK / ALERT があり、本番稼働している VPC に適用する場合は、BLOCK にしてしまうと意図しない障害を起こしてしまう可能性があるため、まずは ALERT で設定するのが良いと考えます。

本記事は自社サイトへの DNS クエリを拒否するのみの検証なので最初から BLOCK で設定していきます。
ルールグループ内で複数個のルールを作ることができ、優先順位も設定可能です。


 

VPC への関連付け

ルールグループ作成後に、任意の VPC には関連付けます。
関連付けは数十秒ほど要するようで、1分未満で完了していました。


 

DNS Firewall 導入後の動作確認


DNS レコードを取得 (A レコード)

DNS Firewall のルールグループと関連づけたことで、A レコードの値(54.168.234.169 および 13.112.148.66)が返ってこず、取得できなくなった様子がわかります。

先ほどのルールを作成した際に、BLOCK アクションで送信する応答を NODATA を選択していたため、クエリ自体は成功したが、利用可能な応答がない (IP アドレスが返ってこない) という挙動をしています。

ドメイン名が存在することすらも応答したくない場合は NXDOMAIN を選択します。

[ec2-user@ip-10-0-1-98 ~]$ dig A cloudpack.jp

; <<>> DiG 9.16.48-RH <<>> A cloudpack.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55219
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloudpack.jp.                  IN      A

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 09 09:32:54 UTC 2024
;; MSG SIZE  rcvd: 41

DNS レコードを取得 (NS レコード)

一方で NS レコードを BLOCK するルールは作成していませんでしたので、DNS Firewall を作成する前と同じく4つのネームサーバーを取得できています。

[ec2-user@ip-10-0-1-98 ~]$ dig NS cloudpack.jp

; <<>> DiG 9.16.48-RH <<>> NS cloudpack.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31067
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cloudpack.jp.                  IN      NS

;; ANSWER SECTION:
cloudpack.jp.           86400   IN      NS      ns-1495.awsdns-58.org.
cloudpack.jp.           86400   IN      NS      ns-1784.awsdns-31.co.uk.
cloudpack.jp.           86400   IN      NS      ns-282.awsdns-35.com.
cloudpack.jp.           86400   IN      NS      ns-607.awsdns-11.net.

;; Query time: 0 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Tue Apr 09 09:33:12 UTC 2024
;; MSG SIZE  rcvd: 181

 

最後に

一般的にレイヤー3,4 の保護は AWS Shield (Standard/Advanced) を、レイヤー7 の保護は WAF を、脅威の検知は GuardDuty 等、必要に応じて対策が講じられていると思いますが、DNS のセキュリティまでご相談をお受けすることはあまり多くはありません。

DNS はデータ転送用のプロトコルではないため、多くの企業では DNS トラフィックを監視して、悪意のあるアクティビティの有無を調べることまでは意識していないのが実情かと思います。

DNS に対する攻撃はいくつかありますが、DNS トンネリングのような攻撃もあるため、対策の一歩として Amazon Route 53 Resolver DNS Firewall は有効かと考えます。

DNSトンネリングとは