UniFi Network Application 8.3.32

投稿日 編集日 カテゴリ

この記事で実現すること

米国Ubiquiti（ユビキティ）社のUniFi製品のコントローラーとして利用するUniFi Network Application（以下、UNA）の8.3.32(Official)が提供されています。特にゲートウェイにおけるNAT機能において機能強化が図られています。この記事は本バージョンで強化されたNATのセキュリティ対応を纏めています。

UNA8.3

以下の機能が追加されています。

  • 柔軟なNAT設定
    マスカレード、ソース、およびデスティネーションNATでトラフィックを制御します。さらに、すべてまたは特定のネットワークでNATを無効にできます。
  • 検査モニタリングの一元化
    侵入防止、トラフィックおよびファイアウォールルール、広告ブロッキングなどのセキュリティサービスの詳細なアクティビティログを1つのインターフェースで表示します。
  • より詳細なスイッチ分離設定
    ACLルールを使用して、同じネットワーク内または異なるネットワーク間の特定のトラフィックをブロックします。

UNA8.3.32でダブルNATを回避できるようになりました。これはホームユーザーにとっても期待されていた機能です。

NATの種類

一般的にNATというと、自宅で利用するIPv4プライベートIPアドレスをグローバルIPアドレスに変換してインターネットに接続する技術ですが、これは厳密にはソースNAT（Source NAT、SNAT）またはIPマスカレードと呼ばれます。単に送信元のIPアドレスをプライベートからパブリックに変換するだけならSNATですが、IPアドレスとTCP Portの組み合わせでセッションを管理（紐付け）されているのがIPマスカレードです。これに対して、宛先を変換する宛先NAT（Destination NAT、DNAT）という機能があります。DNATは宛先のIPアドレスを別のIPアドレスに強制的に変更するものです。

負荷分散装置で複数あるサーバーに一定ルールで振り分けたり、パブリックIPアドレスを持つサーバーにプライベートネットワークから接続するよう強制的に向き先を変更することなど、DNATは様々な場所で活用されています。

今回はセキュリティの観点からホームユーザーにも使い道のあるDNATを紹介します。

クライアントに強制的にUniFi GatewayのDNSを参照させる

この記事の実例は、IoTなど、DHCPでDNSを指定してもそれを無視してクラウドDNS（GoogleDNSなどの8.8.8.8）を参照する機器や行儀の悪いアプリケーションへの対策になります。企業や個人向けのルータでは一般的にHTTPSやDNSが許可されていることを前提に攻撃者はDDos攻撃のシナリオを作成します。また、IoTの許可のない情報収集などは、クラウドのファイルサービスに対して行われるケースもありますが、セキュアなDNSやFirewallで阻止される可能性もあるため、クラウドDNS（Port53）を使って遮断を回避する手口はよく使われます。クラウドDNS（Port53）へのアクセスをFirewallでRejectできますが、IoTのサービスそのものが機能しなくなるのは困ります。そこでクラウドDNSにアクセスしているように騙し、リクエストを横取りするのがこれから説明するDNATによる宛先IPアドレスの変換です。

つまり、セキュリティを守るために行われる正当かつ原始的な中間者攻撃（Man-in-the-middle Attack）となります。

なお、今回はDNSについて書いていますが、UNAのネットワーク->「コンテンツフィルタリング」やセキュリティ->広告ブロックを有効にすると自動的にUniFi Gateway自身のDNS参照が強制されます。ですので、IoT向けにこの2つの機能を外してUCG-Ultraで検証します。

DNATの設定

ここではUniFi GatewayのLANを192.168.1.1として設定しています。

インタフェースをDefault、Internetに出ていく宛先、つまり0.0.0.0/0の宛先、Port53/TCP,UDPを対象に変換されたIPアドレスとしてGatewayのIPアドレスを指定することで宛先IPアドレスが変換されます。
なお、IPv6のNAT機能はまだ実装されていないようなので、DefaultセグメントのIPv6は無効にしておきます。

検証

  • WindowsPCをIoT機器と見立て、LANに接続の上、WindowsのDNSの設定を8.8.8.8に変更します
  • UniFiのDNS設定で、仮のホスト”test.home”のエントリを作成します
  • nslookup test.homeを実行します

実行結果

1
2
3
4
5
6
C:\Users\yoshi>nslookup test.home
サーバー:  dns.google
Address:  8.8.8.8

名前:    test.home
Address:  192.168.100.200

このようにクライアントはGoogle DNSを参照しているつもりでいますが、DNSからの回答としてプライベートIPアドレスを返します。
このDNAT設定をオフにすると以下のようになります。

1
2
3
4
5
C:\Users\yoshi>nslookup test.home
サーバー:  dns.google
Address:  8.8.8.8

*** dns.google が test.home を見つけられません: Non-existent domain

このようにDNSを強制的にUniFi Gatewayに向けることができます。

応用編

UniFi GatewayのDNSを利用せず、独自にLAN内にセキュアなDNSや内部向けDNSを構築されている環境ではどうでしょうか？別のLANセグメントにDNSがある場合はDNATが有効に機能しますが、UniFi GatewayのLANと同じセグメントにDNSがある場合、少し工夫が必要です。

IoTからリクエストされたDNSクエリは最初にUniFi Gatewayを経由し、DNATされ、DNSにリクエストされます。但し、返りのパケットは、DNSからの応答が直接IoTに返って来ることになり、（IoTがリクエストしていない機器からの）パケットを受信できません。

この対策として、IPマスカレードを追加することになります。

このようにDNSへのリクエストはクライアントからではなく、UniFi GatewayであるようにIPマスカレードすることによって、DNSはクエリの結果をUniFi Gatewayに返し、GatewayはクライアントにDNSクエリの結果を返します。これでエラーが発生せず、クライアントのInternet向けDNSクエリは横取りする事が可能となります。

設定例です。ここでは、UniFi Gatewayを192.168.2.2、内部DNSを192.168.2.100とします。

最初にDNATを構成します。

ここでは、DNATの宛先として、DNSサーバーのIPアドレスを指定します。

続いてマスカレードの設定です。

ここで、送信先のIPグループで新しいリンクをクリックし、新しいIPアドレス、つまりDNSサーバーのIPアドレスを登録します。さらに、ポートグループで新しいリンクをクリックし、DNSのPort53を登録します。

２つの登録を行った結果、DNAT→Masqueradeの順序に並びます。

これでクライアントからInternetに向けたDNSリクエストは全てLAN内のDNSに強制的に参照されることになります。行儀の悪いIoTやアプリケーションからは「卑怯だぞ」という声が聞こえてきそうです😁。

ご参考

Ubiquiti JapanからのUNA8.3の記事では、NAT機能の概要のみが記載されていましたので具体例を記載してみました。なお、まだ発売されていませんが、Cloud Gateway Maxにも言及されていますね。今度は全て2.5Gbpsポートを持つゲートウェイということに加え、監視カメラ（Protect）に対応することにもなり（動画保存用にNVMe SSDというのが素敵です）、個人向けとして楽しみなプロダクトになりそうです。

UI Japan UniFi Networkの進化: Site Manager | Network Application8.3 | クラウドゲートウェイマックス
https://note.com/ui_japan/n/n503fc31a3442