ER605 ルーターからセカンダリ ネットワークが 1 つあります。これを使用して、接続されたデバイスである Raspberry Pi を隔離できます。これを使用して、疑わしいソース (義理の両親のマルウェアに常に感染しているコンピューターなど) からの受信ファイルを隔離およびスキャンします。Pi にアクセスして、スキャンしたファイルをプライマリ ネットワークに持ち出す必要があります。アクセスには VNC を使用し、SMB 共有を介して、承認されたファイルを直接 QNAP NAS に配置する予定です。
ACL ルール 5 は、隔離ネットワークからプライマリ ネットワークへの通信をブロックします。プライマリ ネットワークから隔離 pi に VNC を渡すために、最初はルール 4 を追加しましたが、これでは不十分でした (オンラインで読んだところ、返信メッセージには ACL が必要だと示唆されていました)。そこで、VNC サービスを参照するルール 3 のバージョンを追加しましたが、それでも失敗しました。思いつきで、送信元ポートと送信先ポートを入れ替える VNC_duplex サービス定義を作成し、ルール #3 を VNC サービスから VNC デュプレックスに変更してみたところ、なんと VNC が動作しました。
これが機能していることにとても満足していますが、なぜ機能するのか、また安全であるかどうかはわかりません。ACL ルール 3 では、悪意のあるスクリプトが Raspberry Pi の任意のポートからプライマリ ネットワーク上の任意のデバイスのポート 5900 にメッセージを送信できると理解してよろしいでしょうか。これを意味論的に理解するにはどうすればよいでしょうか。また、より安全にすることはできますか。
私のネットワークとVLAN:
セグメント化/アクセスを許可したいネットワーク領域を説明するために、いくつかの IP 範囲も設定しました。
私のサービスの種類 (最後の 4 つは私がカスタム入力したものです):
そして最後に私の ACL です:
答え1
オンラインで読んだところ、返信メッセージには ACL が必要だと示唆されていたので、VNC サービスを参照するルール 3 のバージョンを追加しましたが、それでも失敗しました。思いつきで、送信元ポートと送信先ポートを入れ替える VNC_duplex サービス定義を作成し、ルール #3 を VNC サービスから VNC デュプレックスに変更してみたところ、なんと VNC が動作しました。
Piがコンピュータに返信を送信すると、Pi がソースです。
「戻り」パケットには「送信元IP」としてPiのIPアドレスが含まれているだけでなく、対応するポート番号も含まれています。Pi側「送信元ポート」として。
Connection: 192.168.0.PC:54321 <--> 192.168.2.10:5900
Packets from PC: src = 192.168.0.PC:54321, dst = 192.168.2.10:5900
Packets from Pi: src = 192.168.2.10:5900, dst = 192.168.0.PC:54321
ファイアウォールの元のサービス テンプレートはすべて、「転送」方向のみに定義されています。たとえば、「VNC」テンプレートは宛先ポートとして 5900 と一致します。これは、説明したように、宛先が VNC サーバーであるパケットのみと一致し、「戻り」パケットには一致しません。
ACL ルール 3 では、悪意のあるスクリプトが Raspberry Pi の任意のポートからプライマリ ネットワーク上の任意のデバイスのポート 5900 にメッセージを送信できると理解してよろしいでしょうか?
いいえ。その逆です。スクリプトがメッセージを送信できるのです。ポート5900からラズベリーパイでどの港へもプライマリネットワーク上。（「送信元ポート = 5900」の「送信元」本当に意味するパケットの送信元。
接続の送信元ポートはできる任意に選択できる（希望する場合）ということは、プライマリネットワークが誰にでも開かれていることを意味します。知っているこの例外の存在について知っている人は、OSにローカルポート5900への接続をバインドするように依頼するだけでよい。（しかし、一方で、送信元ポートは通常ランダム化されており、範囲は5900をはるかに超えるところから始まるため、しないこの例外について知っている人は、偶然にそれを発見する可能性は低いでしょう。
これを意味論的に理解するにはどうしたらいいでしょうか？
「ソース」は実際には個人のソースを意味しますパケット接続全体ではなく、ポートの一部です。(実際には、ポートはパケットの「トランスポート層」アドレスの一部と見なすことができ、実際、他のいくつかの非 IP プロトコルでは、ポートは文字通りアドレスの一部でした。)
各ポートは、各 IP アドレスが特定のエンドポイントに関連付けられているのと同じように、特定のエンドポイントに関連付けられています。つまり、Pi に接続した場合、Pi からの「戻り」パケットに Pi の IP アドレスが「宛先」として表示されることは想定されません。同じことがポート番号にも当てはまります。
さらに安全にすることはできるでしょうか?
通常のアプローチは、このような反射的なACLを完全に避け、ステートフルファイアウォール。ほとんどのルーターはアクティブな接続（「状態」または「フロー」）を追跡することができます。しなければならない典型的な 1:多の NAT を実装している場合はこれを実行します。ファイアウォール フィルターには、「確立された」接続に対応するすべてのパケットを許可する特別なルール (iptables/nftables の場合など) があるか、そのようなパケットを暗黙的に許可する (pf の場合など) 場合があります。
ER603はステートフルACLのサポートを獲得したようだファームウェア2.1（しかし、効果がないと言う人もいるようです。）
もし、あんたがしなければならないステートレスACLを使用する場合、代替アプローチは、TCP「ACK」フラグ設定。TCP接続の最初のパケット一度もない他のすべてのパケットにはこのフラグが設定されていますが、TCP ACK パケットにはこのフラグが設定されていません。任意のポートで TCP ACK パケットを許可する単一のルールがあれば十分です。
当然ながら、このアプローチは TCP にのみ機能します。状態追跡なしで UDP についてできることはほとんどなく、再帰 ACL によってできた穴を誰も発見しないことを願うしかありません。
また、ICMPの「戻り」パケットも許可する別のルールも必要です（例：エコー応答やさまざまなICMPの「エラー」メッセージなど）。最低でも「断片化が必要」は許可される必要がありますが、「到達不能」などの他のエラーも許可されることが望ましいです。