こんにちは、ソリューションアーキテクトのtakiponeこと大瀧です。
先日、 AWS より新しいマネージドファイヤーウォールサービスであるAWS Network Firewallがリリースされました。 SORACOM には AWS とプライベート接続するサービス SORACOM Canal があり、この Network Firewall と組み合わせることができます。これにより SORACOM IoT SIM のセルラー通信でインターネットアクセスを行うときに、デバイスのデータを送信する特定のドメインや通信のみに制限したり、危険なサイトや予期しない通信を防ぐためにそれらへのアクセスを禁止できます。一方でSORACOMには、通信先を制限する機能として VPG アウトバウンドルーティングフィルターがあり、 IP アドレス帯域ごとのアクセス許可/禁止設定ができます。 今回の構成は、アクセス先の IP アドレスが変化したり IP アドレスの特定が難しい場合の補完としておすすめです。
本ブログでは、その設定手順と実際にフィルタする様子をご紹介します。 SORACOM と AWS の構成概要は以下の通りです。
必要なもの
- SORACOMアカウント
- SORACOM IoT SIM
- セルラー通信のための機器(今回はRaspberry Pi 4 B+とUSBドングル Huawei MS2372h-607)
- AWSアカウント
SORACOMの構成
SORACOM Canal は、Amazon VPC とプライベート接続するために VPC ピアリング構成と Transit Gateway 接続構成(以下 TGW構成 )の2つから選択できます。 VPC ピアリング構成ではインターネット接続のデフォルトルートを VPC に向けるために、 SORACOM Gate と SORACOM Junction の追加構成が必要です。 TGW 構成ではそれらの追加構成が不要ですので、今回は TGW 構成で試してみます。以下の手順に従い Canal TGW 構成をステップ2-4.まで行ってください。
今回の構成に合わせるために、以下の点に留意します。
- VPG 作成時の「インターネットゲートウェイを使う」を
OFF
にする - SORACOM に申請する CIDR を
0.0.0.0/0
(デフォルトルート)で申請する
ステップ 2-5. は次の手順「 AWS の構成」で代用します。
AWSの構成
Transit Gateway の構成
AWS Network Firewall は現時点で利用できるリージョンが限定されているため、VPGのリージョンとNetwork Firewallを利用できるリージョンの両方に Transit Gateway(以下 TGW) を作成し、TGW ピアリング接続で相互接続します。今回は VPG を 東京リージョン(ap-northeast-1)、 Network Firewall をオレゴンリージョン(us-west-2)に配置するので、それぞれ TGW tgw-tokyo
、tgw-oregon
を作成し TGW ピアリング接続しました。同一リージョンに置ける場合は、1つの TGW で問題ありません。
VPC サブネットの構成
Network Firewall を構成する VPC には、それぞれのルーティングテーブルを指定するために以下の VPC サブネットを作成します。今回は構成をシンプルにするために 1AZ(アベイラビリティゾーン) 分で説明していますが、実用時はゾーンの冗長性を考慮するために複数アベイラビリティゾーンにそれぞれ VPC サブネットを作成してください。
- Transit Gatewayアタッチメント用 VPCサブネット
- NAT Gateway用(
nat-XXXX
) VPCサブネット - Network Firewall用(
vpce-XXXX
)VPCサブネット
ここでNAT Gatewayが登場していますが、Transit GatewayからInternet Gatewayを経由してインターネットに接続するために必要なコンポーネントですので、Internet Gateway と合わせて作成します。
Network Firewall の構成
Network Firewallで設定できる項目は、以下のブログが参考になります。
今回はドメイン単位のアクセス制限を設定したいので、ステートフルルールグループに以下を設定してみました。
- キャパシティ :
10
- ドメイン名 :
.soracom.jp
(soracom.jp
のサブドメイン) - 検査するトラフィック :
Https
,Http
- アクション :
Deny
ルーティングテーブルの構成
なんだかパズルみたいな複雑さですが、以下で Network Firewall の動作を確認できました。
以下の2点がポイントです。
- SORACOM Canalからのトラフィックは VPG で NAT されるため、VPGに向けるルーティングのTarget および Destination は VPG が配置される SORACOM 管理の VPC とその CIDR(
100.x.x.x/x
) になる - Internet Gateway に Edge associations で紐付ける VPC のローカルルート(
192.168.x.x/x
)を Network Firewall(vpce-XXXX
) に向ける
動作確認
それでは、 SORACOM IoT SIM からインターネット接続を試して Network Firewall の動作を確認します。今回は Raspberry Pi に USBドングルをセットして、以下のページのステップ3で SIM グループの設定を行った SIM で試します。
以下のコマンドで確認しました。
$ curl -I https://soracom.jp
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 55472
Connection: keep-alive
:(略)
$ curl -I https://blog.soracom.jp
(レスポンスなし)
^C
$
soracom.jp
への HTTPS アクセスが成功する一方で、サブドメインの blog.soracom.jp
への HTTPS アクセスが Network Firewall のフィルタ条件に引っかかってレスポンスが返ってこない様子が確認できました。 Network Firewall にはフィルタ時のログを Alert ログとして Cloudwatch Logs に記録する機能があります。以下のログが確認できました。
{
"firewall_name": "fw1",
"availability_zone": "us-west-2a",
"event_timestamp": "1605772363",
"event": {
"timestamp": "2020-11-19T07:52:43.361038+0000",
"flow_id": 949070269719365,
"event_type": "alert",
"src_ip": "192.168.0.20",
"src_port": 10039,
"dest_ip": "65.9.42.18",
"dest_port": 443,
"proto": "TCP",
"tx_id": 0,
"alert": {
"action": "blocked",
"signature_id": 1,
"rev": 1,
"signature": "matching TLS denylisted FQDNs",
"category": "",
"severity": 1
},
"tls": {
"sni": "blog.soracom.jp",
"version": "UNDETERMINED",
"ja3": {},
"ja3s": {}
},
"app_proto": "tls"
}
}
フィルタされた様子がわかりますね。
まとめ
AWS Network Firewall を利用して、 SORACOM IoT SIM からのインターネットアクセスにドメイン単位のフィルタを設定してみました。構成がやや複雑ですが、いずれもマネージドサービスの組み合わせですのでサーバーの運用などが不要で、便利に使っていただける仕組みだと思います。