Route 53 Resolver DNS Firewall で疑似的にSMTP通信を制御してみた

エンタープライズクラウド部の山下(祐)です。
私事で大変恐縮ですが、本日5月12日は私の誕生日です。
皆様、誕生日はどのように過ごされますでしょうか。家族や恋人・友人と一緒にお祝いしたり、プレゼントを買いに行ったり…。色々な過ごし方があるとは思いますが、中でも一番メジャーな過ごし方といえば、やはり技術ブログの執筆ではないでしょうか。ええ、そうでしょうとも。ですので、私もご多分に漏れず、一筆書きたいと思います。

というわけで今回は、Route 53 Resolver DNS Firewall（以下、DNS Firewall）を使って、DNSクエリを制限することで、疑似的にSMTP通信を制御してみようと思います。

今回やること
はじめにまとめ
検証環境
検証前の事前動作確認
DNS Firewall用ドメインリスト
DNS Firewallルール設定
DNS Firewall動作検証
注意点
おわりに

今回やること

以前のブログで、AWS Network Firewall（以下、NFW）でSMTP通信を制御しようとして出来なかった旨をご紹介しました。

blog.serverworks.co.jp

そこで今回は、次善の策として、DNS Firewallを利用した制御を行ってみます。 Gmailに関するDNSクエリは許可するが、他メールのドメインに関するDNSクエリは拒否し、Gmail以外へのメール送付を出来ないようにしてみます。

具体的には、以下のように制御を行います。

No.	ドメイン	許可/拒否
1	Gmail送付に関連するドメイン	許可
2	メール以外のアプリやEC2を動作させるのに必要なドメイン	許可
3	上記以外の全てのドメイン	拒否

なお、DNS Firewall については、以下ブログで詳細に解説されていますので、よろしければ合わせてご参照ください。

blog.serverworks.co.jp

はじめにまとめ

はじめに、今回の検証を通じて分かった点について簡単にまとめます。詳細は後述します。

メールアドレスレベルでの制御は出来ない。
hostsファイルを利用されたり、参照先のDNSサーバを変更されると制御が出来ない。
ホワイトリスト方式は精査が大変。精査期間を設けることを推奨。

2、3はメール制御に限らず、DNSクエリの制御全般に関する話となります。

検証環境

検証構成

今回の検証構成です。EC2からNFWを経由してEメールを送信します。名前解決は Route 53 Resolver を利用します。

Route 53 Resolver については、以下ブログで大変分かりやすく解説されていますので、よろしければ合わせてご参照ください。

blog.serverworks.co.jp

EC2の設定

EC2は下記ブログで使用したものを流用しますので、詳細はそちらをご参照ください。

https://blog.serverworks.co.jp/network-firewall-cannot-control-smtp#EC2%E3%81%AE%E8%A8%AD%E5%AE%9A

NFWの設定

NFWも下記ブログで使用したものを流用します。下記ブログで使用したSuricataルールは、今回は使用しません。

https://blog.serverworks.co.jp/network-firewall-cannot-control-smtp#NFW%E3%81%AE%E8%A8%AD%E5%AE%9A

加えて、今回はSMTP通信を全て許可するルールを入れています。名前解決後のSMTP通信は、NFWを通過するためです。

Route 53 Resoloverクエリログの記録

クエリログ記録を有効にすることで、Route 53 Resoloverのクエリログ結果を記録することが出来るようになります。
設定は Route 53 Resolover の画面から行います。今回はAthenaでログを分析したいのでログ送信先にはS3を指定し、検証用のVPCを指定します。

Athenaの設定

今回は、NFWログと、DNSクエリログをAthenaで分析します。
NFWログ用の設定は以下ブログをご参照ください。

https://blog.serverworks.co.jp/network-firewall-cannot-control-smtp#Athena%E3%81%AE%E8%A8%AD%E5%AE%9A

DNSクエリログ用には、以下のSQLでテーブルを作成します。

クリックすると展開されます

CREATE EXTERNAL TABLE r53_rlogs (
  version string,
  account_id string,
  region string,
  vpc_id string,
  query_timestamp string,
  query_name string,
  query_type string,
  query_class
    string,
  rcode string,
  answers array<
    struct<
      Rdata: string,
      Type: string,
      Class: string>
    >,
  srcaddr string,
  srcport int,
  transport string,
  srcids struct<
    instance: string,
    resolver_endpoint: string
    >,
  firewall_rule_action string,
  firewall_rule_group_id string,
  firewall_domain_list_id string
 )
     
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://dns-query-logs-xxxxxxxxxxxx/AWSLogs/xxxxxxxxxxxx/vpcdnsquerylogs/vpc-xxxxxxxxxx/'

検証前の事前動作確認

DNS Firewallの検証を行う前に、以下を確認してみます。

メールが問題なく送信できること
どのようなDNSクエリが発生しているのか

メール送信テスト

まずは DNS Firewall を設定していない状態で、Gmail・Yahooメールにテストメールを送ってみます。

クリックすると展開されます

#Gmailへのメール送信テスト
[ssm-user@ip-10-0-0-150 bin]$ sendmail xxxxx@gmail.com
From:sendmail@yamashita-kensho.net
To:xxxxx@gmail.com
Subject:テスト_20240511_01

Gmailへのテスト送信1回目です。
本日は2024年5月11日です。

AWS Network Firewallは設定済みです。
DNS Firewall は設定していません。

.
[ssm-user@ip-10-0-0-150 bin]$
#
#
#Gmailへのメール送信結果確認
[ssm-user@ip-10-0-0-150 bin]$ sudo tail -n 6 /var/log/maillog
May 11 11:10:46 ip-10-0-0-150 postfix/pickup[2117]: 459D94447: uid=1001 from=<ssm-user>
May 11 11:10:46 ip-10-0-0-150 postfix/cleanup[2327]: 459D94447: message-id=<20240511111046.459D94447@sendmail.yamashita-kensho.net>
May 11 11:10:46 ip-10-0-0-150 opendkim[2028]: 459D94447: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 11 11:10:46 ip-10-0-0-150 postfix/qmgr[2118]: 459D94447: from=<ssm-user@yamashita-kensho.net>, size=540, nrcpt=1 (queue active)
May 11 11:10:47 ip-10-0-0-150 postfix/smtp[2330]: 459D94447: to=<xxxxx@gmail.com>, relay=gmail-smtp-in.l.google.com[142.251.170.26]:25, delay=13, delays=12/0.01/0.41/0.94, dsn=2.0.0, status=sent (250 2.0.0 OK  1715425847 41be03b00d2f7-634103f7265si5676234a12.388 - gsmtp)
May 11 11:10:47 ip-10-0-0-150 postfix/qmgr[2118]: 459D94447: removed
#
#
#Yahooメールへのメール送信テスト
[ssm-user@ip-10-0-0-150 bin]$ sendmail xxxxx@yahoo.co.jp
From:sendmail@yamashita-kensho.net
To:xxxxx@yahoo.co.jp
Subject:テスト_20240511_01

Yahooメールへのテスト送信1回目です。
本日は2024年5月11日です。

AWS Network Firewallは設定済みです。
DNS Firewall は設定していません。

.
[ssm-user@ip-10-0-0-150 bin]$
#
#
#Yahooメールへのメール送信結果確認
[ssm-user@ip-10-0-0-150 bin]$ sudo tail -n 6 /var/log/maillog
May 11 11:11:33 ip-10-0-0-150 postfix/pickup[2117]: 641DF4447: uid=1001 from=<ssm-user>
May 11 11:11:33 ip-10-0-0-150 postfix/cleanup[2327]: 641DF4447: message-id=<20240511111133.641DF4447@sendmail.yamashita-kensho.net>
May 11 11:11:33 ip-10-0-0-150 opendkim[2028]: 641DF4447: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 11 11:11:33 ip-10-0-0-150 postfix/qmgr[2118]: 641DF4447: from=<ssm-user@yamashita-kensho.net>, size=550, nrcpt=1 (queue active)
May 11 11:11:37 ip-10-0-0-150 postfix/smtp[2330]: 641DF4447: to=<xxxxx@yahoo.co.jp>, relay=mx5.mail.yahoo.co.jp[202.93.78.240]:25, delay=14, delays=10/0/0.01/4.2, dsn=2.0.0, status=sent (250 ok dirdel)
May 11 11:11:37 ip-10-0-0-150 postfix/qmgr[2118]: 641DF4447: removed
[ssm-user@ip-10-0-0-150 bin]$

この時点では、どちらにも問題なくメール送信できました。メールが届いている事も確認しました。

NFWログ

NFWのフローログにも、想定通りSMTP通信が記録されていました。

SQLクエリ（クリックすると展開されます）

SELECT event.timestamp,
       event.event_type,
       event.src_ip,
       event.src_port,
       event.dest_ip,
       event.dest_port,
       event.proto,
       event.alert.action,
       event.alert.signature,
       event.tls.sni
FROM <table_name>
WHERE (event.src_port = 25 or event.dest_port = 25)
GROUP BY event.timestamp,
         event.event_type,
         event.src_ip,
         event.src_port,
         event.dest_ip,
         event.dest_port,
         event.proto,
         event.alert.action,
         event.alert.signature,
         event.tls.sni
ORDER BY event.timestamp DESC

DNSクエリログ

AthenaでDNSクエリログを分析し、どのようなドメインにどのようなクエリを出しているか確認してみます。

SELECT query_name,
       query_type
FROM r53_rlogs
GROUP BY query_name,query_type
ORDER BY query_name

46件ヒットしました。想像以上に多かったです。

今度はドメインに絞って検索してみます。

SELECT query_name
FROM r53_rlogs
GROUP BY query_name
ORDER BY query_name;

それでも28個のドメインがヒットしました。結構多いですね。

ドメインとレコード、用途を一覧でまとめてみました。用途については一部不明のものがありますが、ご容赦ください。

No.	ドメイン名	レコード	用途
1	__cloud_init_expected_not_found__.	A AAAA	？？？
2	__cloud_init_expected_not_found__.ap-northeast-1.compute.internal.	A AAAA	？？？
3	0.amazon.pool.ntp.org.	A AAAA	Amazon Time Sync Service のNTPサーバ
4	1.amazon.pool.ntp.org.	A AAAA	Amazon Time Sync Service のNTPサーバ
5	2.amazon.pool.ntp.org.	A AAAA	Amazon Time Sync Service のNTPサーバ
6	2.amazon.pool.ntp.org.ap-northeast-1.compute.internal.	A AAAA	Amazon Time Sync Service のNTPサーバ（EC2内部用？）
7	alt1.gmail-smtp-in.l.google.com.	A	Gmail用のSMTPサーバ
8	alt2.gmail-smtp-in.l.google.com.	A	Gmail用のSMTPサーバ
9	alt3.gmail-smtp-in.l.google.com.	A	Gmail用のSMTPサーバ
10	alt4.gmail-smtp-in.l.google.com.	A	Gmail用のSMTPサーバ
11	amazonlinux-2-repos-ap-northeast-1.s3.dualstack.ap-northeast-1.amazonaws.com.	A AAAA	yumリポジトリ
12	does-not-exist.example.com.	A AAAA	テスト用？
13	ec2messages.ap-northeast-1.amazonaws.com.	A AAAA	SSM用エンドポイント
14	example.invalid.	A AAAA	テスト用？
15	gmail-smtp-in.l.google.com.	A	Gmail用のSMTPサーバ
16	gmail.com.	A MX	Gmail
17	instance-data.	A AAAA	EC2インスタンスのシステムメトリクス用?
18	ip-10-0-0-150.ap-northeast-1.compute.internal.	A AAAA	EC2のプライベートDNS名
19	ip-10-0-0-150.ap-northeast-1.compute.internal.ap-northeast-1.compute.internal.	A AAAA	EC2のプライベートDNS名？
20	logs.ap-northeast-1.amazonaws.com.	A AAAA	CloudWatch Logs
21	mirrors.fedoraproject.org.	A、AAAA	yumリポジトリ
22	mx1.mail.yahoo.co.jp.	A	Yahooメール用SMTPサーバ
23	mx2.mail.yahoo.co.jp.	A	Yahooメール用SMTPサーバ
24	mx3.mail.yahoo.co.jp.	A	Yahooメール用SMTPサーバ
25	mx5.mail.yahoo.co.jp.	A	Yahooメール用SMTPサーバ
26	ssm.ap-northeast-1.amazonaws.com.	A AAAA	SSM用エンドポイント
27	ssmmessages.ap-northeast-1.amazonaws.com.	A AAAA	SSM用エンドポイント
28	yahoo.co.jp.	MX	Yahoo

Yahooメールは最終的にブロックするので無視して良いですが、それ以外のものは一旦許可しておいた方が良さそうです。

DNS Firewall用ドメインリスト

上記を踏まえ、以下のようにドメインリストを作成してみました。

Google

Gmailを許可するためのドメインリストです。

gmail.com
*.google.com

AWS

SSM等のAWSサービスを利用するためのドメインリストです。

*.amazonaws.com
*.amazon.pool.ntp.org

EC2-Internal

EC2内部で使われているドメインリストです。テスト用と思われるドメインもここに入れます。

*.compute.internal
__cloud_init_expected_not_found__.
does-not-exist.example.com
example.invalid

External-Service

AWS以外が公開しているリポジトリ等、外部サービス向けのドメインリストです。

*.fedoraproject.org

All-Domains

上記以外の全てのドメインです。DNS Firewallのドメインリストで全てのドメインを指定する場合、アスタリスクを使用します。

DNS Firewallルール設定

先ほど作成したドメインリストを許可するルールと、全てのドメインをBlockするルールを作成します。Blockルールは優先度が最も低くなるように設定します。

許可ルールでは、ドメインリダイレクトの設定を「信頼リダイレクトドメイン」に設定します。これにより、CNAMEやエイリアスレコードで他ドメインにリダイレクトされる場合でも、最初のドメインのみが検査対象となります。自組織で管理していない外部のドメインにクエリを出す場合、こちらの設定を行うと良いかと思います。外部組織のドメインですと、CNAMEやエイリアスの内容が予告なく変わってしまうケースもあり得るので、変更に追従するのが大変なためです。

信頼リダイレクトドメインは、2024年5月1日のアップデートで利用可能になりました。詳細は下記公式アナウンスをご参照ください。

aws.amazon.com

DNS Firewall動作検証

前置きが長くなりましたが、ここからDNS Firewallの動作検証を開始します。

メール送信テスト

改めて、EC2からGmailおよびYahooメールにメールを送信してみます。

クリックすると展開されます

#Gmailへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sendmail xxxxx@gmail.com
From:sendmail@yamashita-kensho.net
To:xxxxx@gmail.com
Subject:テスト_20240512_02

Gmailへのテスト送信2回目です。
本日は2024年5月12日です。

AWS Network Firewallは設定済みです。
DNS Firewall も設定済みです。

.
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Gmailへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sudo tail -n 6 /var/log/maillog
May 12 06:08:11 ip-10-0-0-150 postfix/pickup[2120]: 329F04447: uid=1001 from=<ssm-user>
May 12 06:08:11 ip-10-0-0-150 postfix/cleanup[2362]: 329F04447: message-id=<20240512060811.329F04447@sendmail.yamashita-kensho.net>
May 12 06:08:11 ip-10-0-0-150 opendkim[2028]: 329F04447: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 12 06:08:11 ip-10-0-0-150 postfix/qmgr[2121]: 329F04447: from=<ssm-user@yamashita-kensho.net>, size=534, nrcpt=1 (queue active)
May 12 06:08:12 ip-10-0-0-150 postfix/smtp[2365]: 329F04447: to=<xxxxx@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.188.26]:25, delay=12, delays=11/0.01/0.39/0.81, dsn=2.0.0, status=sent (250 2.0.0 OK  1715494092 41be03b00d2f7-638b16cf3c0si4565579a12.517 - gsmtp)
May 12 06:08:12 ip-10-0-0-150 postfix/qmgr[2121]: 329F04447: removed
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Yahooメールへのメール送信テスト
[ssm-user@ip-10-0-0-150 ~]$ sendmail xxxxx@yahoo.co.jp
From:sendmail@yamashita-kensho.net
To:xxxxx@yahoo.co.jp
Subject:テスト_20240512_02

Yahooメールへのテスト送信2回目です。
本日は2024年5月12日です。

AWS Network Firewallは設定済みです。
DNS Firewall も設定済みです。

.
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Yahooメールへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sudo tail -n 9 /var/log/maillog
May 12 06:09:24 ip-10-0-0-150 postfix/pickup[2120]: F1ABB4447: uid=1001 from=<ssm-user>
May 12 06:09:24 ip-10-0-0-150 postfix/cleanup[2362]: F1ABB4447: message-id=<20240512060924.F1ABB4447@sendmail.yamashita-kensho.net>
May 12 06:09:24 ip-10-0-0-150 opendkim[2028]: F1ABB4447: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 12 06:09:25 ip-10-0-0-150 postfix/qmgr[2121]: F1ABB4447: from=<ssm-user@yamashita-kensho.net>, size=544, nrcpt=1 (queue active)
May 12 06:09:25 ip-10-0-0-150 postfix/smtp[2365]: F1ABB4447: to=<xxxxx@yahoo.co.jp>, relay=none, delay=11, delays=11/0/0.01/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=yahoo.co.jp type=A: Host found but no data record of requested type)
May 12 06:09:25 ip-10-0-0-150 postfix/cleanup[2362]: 0DB1D4449: message-id=<20240512060925.0DB1D4449@sendmail.yamashita-kensho.net>
May 12 06:09:25 ip-10-0-0-150 postfix/bounce[2374]: F1ABB4447: sender non-delivery notification: 0DB1D4449
May 12 06:09:25 ip-10-0-0-150 postfix/qmgr[2121]: 0DB1D4449: from=<>, size=3081, nrcpt=1 (queue active)
May 12 06:09:25 ip-10-0-0-150 postfix/qmgr[2121]: F1ABB4447: removed
[ssm-user@ip-10-0-0-150 ~]$

Gmailへはメール送信できましたが、Yahooメールには送信できませんでした。 /var/log/maillog の以下メッセージから、名前解決が出来なかったことが読み取れます。
Host or domain name not found. Name service error for name=yahoo.co.jp type=A: Host found but no data record of requested type

NFWログ

再度、NFWのログを確認します。Athenaで事前動作確認と同様のクエリを実施します。余計なログが出ないように、時間帯で結果を絞ります。

今回は、Gmail宛ての通信のみ記録されました。Yahooメール宛ての通信は、Route 53 Resolverでの名前解決に失敗しているため、そもそもNFWまで到達していない事が分かります。

DNSクエリログ

DNSクエリログも確認します。以下のSQLクエリをAthenaで実行します。

SELECT query_timestamp,
       query_name,
       query_type,
       firewall_rule_action
FROM r53_rlogs
AND firewall_rule_action='BLOCK'
ORDER BY query_timestamp DESC;

Yahooに対する名前解決がBlockされている事が確認できました。

念のため、Gmailに関する名前解決が出来ている事も確認してみます。

SELECT query_timestamp,
       query_name,
       query_type,
       firewall_rule_action,
       answers
FROM r53_rlogs
WHERE (query_name LIKE '%google.com.' OR query_name='gmail.com.')
ORDER BY query_timestamp DESC;

問題なく名前解決が出来ているようです。DNS Firewallのルールで許可している場合、firewall_rule_action には何も記録されないようです。

注意点

さて、一応、DNS Firewallで名前解決を制限することで、メール送信を制御することが出来ましたが、このやり方にはいくつか注意点があります。

メールアドレス単位での制御はできない

今回のやり方では、Gmailへのメール送信は許可し、Yahooメール等の他ドメインへのメール送信はBlockすることができます。
ただし、Gmailであれば、どのアドレスにもメール送信できてしまいます。「Gmailの特定メールアドレスへの送信だけ許可する」といった制御はできません。
あくまでドメインレベルでの制御であることを念頭に置く必要があります。

Route 53 Resolver 以外を使って名前解決されると制御ができない

Route 53 Resolver DNS Firewall は、その名の通り、Route 53 Resolverでの名前解決に対して制御を行うファイアウォールです。
そのため、OS設定を変更して、問い合わせ先のDNSサーバを変更されたり、hostsファイル等を使われると制御ができなくなります。
これは、メール送信に限らず、全ての名前解決に関して同様です。

EC2のDNS参照先を変更して動作検証

試しに、EC2のDNS参照先を変更してメール送信してみます。
今回のEC2はAmazon Linux2なので、以下ドキュメントを参考にDNS設定を変更します。

repost.aws

blog.serverworks.co.jp

実際に変更した際のログが以下です。

クリックすると展開されます

[ssm-user@ip-10-0-0-150 ~]$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no
[ssm-user@ip-10-0-0-150 ~]$ sudo vim /etc/sysconfig/network-scripts/ifcfg-eth0
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Ethernet
USERCTL=yes
PEERDNS=yes
DHCPV6C=yes
DHCPV6C_OPTIONS=-nw
PERSISTENT_DHCLIENT=yes
RES_OPTIONS="timeout:2 attempts:5"
DHCP_ARP_CHECK=no
DNS1=8.8.8.8  #DNS参照先を8.8.8.8 に変更
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$ sudo cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 10.0.0.2  #まだDNS参照先が Route 53 Resolver のまま
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$ sudo systemctl restart network
[ssm-user@ip-10-0-0-150 ~]$
[ssm-user@ip-10-0-0-150 ~]$ sudo cat /etc/resolv.conf
options timeout:2 attempts:5
; generated by /usr/sbin/dhclient-script
search ap-northeast-1.compute.internal
nameserver 8.8.8.8  #DNS参照先が 8.8.8.8 に変更された
[ssm-user@ip-10-0-0-150 ~]$

また、NFWに、DNS通信を許可するルールを追加します。DNS参照先を外部のDNSサーバーに変更したので、DNSクエリがNFWを通過するためです。

設定変更後、再度GmailとYahooメールにメール送信してみます。

クリックすると展開されます

#Gmailへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sendmail xxxxx@gmail.com
From:sendmail@yamashita-kensho.net
To:xxxxx@gmail.com
Subject:テスト_20240512_03

Gmailへのテスト送信3回目です。
本日は2024年5月12日です。

AWS Network Firewallは設定済みです。
DNS Firewall も設定済みです。
EC2のDNS参照先を 10.0.0.2 から 8.8.8.8 に変更しました。

.
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Gmailへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sudo tail -n 6 /var/log/maillog
May 12 08:50:52 ip-10-0-0-150 postfix/pickup[2769]: 30F9D444B: uid=1001 from=<ssm-user>
May 12 08:50:52 ip-10-0-0-150 postfix/cleanup[3693]: 30F9D444B: message-id=<20240512085052.30F9D444B@sendmail.yamashita-kensho.net>
May 12 08:50:52 ip-10-0-0-150 opendkim[2028]: 30F9D444B: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 12 08:50:52 ip-10-0-0-150 postfix/qmgr[2121]: 30F9D444B: from=<ssm-user@yamashita-kensho.net>, size=606, nrcpt=1 (queue active)
May 12 08:50:53 ip-10-0-0-150 postfix/smtp[3696]: 30F9D444B: to=<xxxxx@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.204.27]:25, delay=15, delays=14/0.01/0.48/0.98, dsn=2.0.0, status=sent (250 2.0.0 OK  1715503853 41be03b00d2f7-634119043dfsi7204644a12.603 - gsmtp)
May 12 08:50:53 ip-10-0-0-150 postfix/qmgr[2121]: 30F9D444B: removed
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Yahooメールへのメール送信テスト
[ssm-user@ip-10-0-0-150 ~]$ sendmail xxxxx@yahoo.co.jp
From:sendmail@yamashita-kensho.net
To:xxxxx@yahoo.co.jp
Subject:テスト_20240512_02

Yahooメールへのテスト送信3回目です。
本日は2024年5月12日です。

AWS Network Firewallは設定済みです。
DNS Firewall も設定済みです。
EC2のDNS参照先を 10.0.0.2 から 8.8.8.8 に変更しました。

.
[ssm-user@ip-10-0-0-150 ~]$
#
#
#Yahooメールへのメール送信結果確認
[ssm-user@ip-10-0-0-150 ~]$ sudo tail -n 6 /var/log/maillog
May 12 08:52:08 ip-10-0-0-150 postfix/pickup[2769]: E5681444B: uid=1001 from=<ssm-user>
May 12 08:52:08 ip-10-0-0-150 postfix/cleanup[3693]: E5681444B: message-id=<20240512085208.E5681444B@sendmail.yamashita-kensho.net>
May 12 08:52:08 ip-10-0-0-150 opendkim[2028]: E5681444B: DKIM-Signature field added (s=default, d=yamashita-kensho.net)
May 12 08:52:08 ip-10-0-0-150 postfix/qmgr[2121]: E5681444B: from=<ssm-user@yamashita-kensho.net>, size=616, nrcpt=1 (queue active)
May 12 08:52:11 ip-10-0-0-150 postfix/smtp[3696]: E5681444B: to=<xxxxx@yahoo.co.jp>, relay=mx2.mail.yahoo.co.jp[202.93.77.239]:25, delay=12, delays=10/0/0.03/2, dsn=2.0.0, status=sent (250ok dirdel)
May 12 08:52:11 ip-10-0-0-150 postfix/qmgr[2121]: E5681444B: removed
[ssm-user@ip-10-0-0-150 ~]$

DNS Firewallの設定は変えていませんが、Yahooメールへの送信が出来ました。

NFWのログで、SMTP通信とDNS通信を見てみると、どちらも想定通り記録されていました。

DNSクエリログはどうでしょうか。GoogleとYahooに絞って、時間帯も絞って検索してみます。

SELECT query_timestamp,
       query_name,
       query_type,
       firewall_rule_action,
       answers
FROM r53_rlogs
WHERE (query_name LIKE '%google.com.' OR query_name='gmail.com.' OR query_name='yahoo.co.jp.')
AND query_timestamp LIKE '2024-05-12T08%'
ORDER BY query_timestamp DESC;

結果は0件でした。EC2のDNS参照先が変更され、Route 53 Resolver が使われなくなったため、Route 53 Resolver のクエリログにも何も記録されなくなったことが確認できました。

ホワイトリスト方式は精査が大変

今回、事前動作確認でDNSクエリを確認しただけでも、28個のドメインがヒットしました。EC2上で他のアプリケーションを動作させれば、更に多くの名前解決が必要になるかもしれません。普段は意識していなくても、様々な形で名前解決が利用されている事が分かります。

そのため、「必要なドメインだけ許可し、それ以外は全てブロックする」というホワイトリスト方式では、必要なドメインを全て洗い出すのが意外と大変です。

従って、下記公式ドキュメントでも推奨されている通り、まずは「必要なドメインは許可＋それ以外はAlert」という設定で、一定期間試験運用し、Alertで検知されたドメインについて精査を行うと良いかと思います。

ブロックルールを初めて作成する際は、アクションを Alert に設定して、ブロックルールをテストします。次に、ルールが警告するクエリの数を調べて、アクションを Block に設定した場合にブロックされるクエリの数を確認します。

DNS Firewall でのルールアクション - Amazon Route 53

おわりに

以上、DNS FirewallによるSMTP通信制御の検証でした。
許可リストの精査が大変なうえ、EC2でDNS参照先を変更されると制御ができない（しかもOS上の変更なので、AWS Configルールで検知することも難しい）ため、このサービスだけで厳密な通信制御を行うのは難しいという印象でした。

本サービスではAWSマネージドのドメインリスト（脅威リスト）を拒否リストに入れて使用しつつ、名前解決以外の通信はNFW等で制御することが無難かもしれません。もし本サービスでホワイトリスト方式を採用したい場合は、Alertで精査期間を設けると良いでしょう。

いずれにせよ、運用負荷とのトレードオフを考慮のうえ、本サービスの導入を検討いただく事を推奨します。

今回は以上です。最後までお読みいただいた方、ありがとうございました。このブログが少しでもご参考になれば幸いです。

Route 53 Resolver DNS Firewall で疑似的にSMTP通信を制御してみた

今回やること

はじめにまとめ

検証環境

検証構成

EC2の設定

NFWの設定

Route 53 Resoloverクエリログの記録

Athenaの設定

検証前の事前動作確認

メール送信テスト

NFWログ

DNSクエリログ

DNS Firewall用ドメインリスト

Google

AWS

EC2-Internal

External-Service

All-Domains

DNS Firewallルール設定

DNS Firewall動作検証

メール送信テスト

NFWログ

DNSクエリログ

注意点

メールアドレス単位での制御はできない

Route 53 Resolver 以外を使って名前解決されると制御ができない

EC2のDNS参照先を変更して動作検証

ホワイトリスト方式は精査が大変

おわりに

Amazon Neptuneで始める初めてのグラフDB① NeptuneクラスターとNotebookの作成

【ベータ版】【小ネタ】Mermaidで構成図が書けるようになりました

AWS CDK の慣用句的テクニックの紹介 - 特定のデプロイステージにのみ適用する設定を Aspects で実装する

RDS の DBスナップショットにはどの時点までのデータが含まれているのか確認する方法

Jinja を使うほどじゃない場合に使えるかもしれない string.Template クラスの紹介