ドメインによるファイアウォール下りフィルタリング
実稼働環境では、APIを介していくつかのコア外部サービスプロバイダーに接続しており、他のすべてのサービスをブロックする必要があります（PCI DSS）。
現在、IPアドレスによる出力フィルタリングをサポートするファイアウォールがあるため、静的に作成されたファイアウォールルールに基づいてすべての非必須アドレスがブロックされます（すべて拒否、1.2.3.4：443を許可するなど）
これまでのところすべてが順調です。ここに問題があります。サービスプロバイダーの1つ（大手銀行）が、そのサービスの1つであるEdge/cdnがホストするAPIとサービスのIPに移行していますIS 1日に数回交換する。
出力フィルタリングに関する他の記事を読みました： ファイアウォール出力フィルタリング/クイックホワイトリスト
...また、可能であればスクリプトを使用して、DNSクエリに基づいてiptablesベースのファイアウォールを変更します。 https://stackoverflow.com/questions/14096966/can-iptables-allow-dns-queries-only-for-a-certain-domain-name
...しかし、これらのソリューションはハッキリしているようです
IPベースではなく、ドメインベースのルールを使用できるファイアウォールはありますか？APIリクエストは中断されずに到着し続けますが、他のすべての送信接続をブロックし続けますか？
IPベースではなく、ドメインベースのルールを使用できるファイアウォールはありますか？APIリクエストは中断されずに到着し続けますが、他のすべての送信接続をブロックし続けますか？
はい、ただし通常は従来のファイアウォールルールではなくプロキシ機能を使用します
たとえば、 チェックポイントURLフィルタリングソフトウェアブレード を使用すると、アクセスを要求するDNS名に基づいて、発信HTTPおよびHTTPS接続を制限できます（例：GET http://example.com/ HTTP/1.0またはCONNECT example.com HTTP/1.1は、example.comへのアクセスを許可するルールが存在する場合にのみ成功します。
プロキシの側面は、問題空間の結果です。逆引きDNSは、何らかの形、形、または形式で信頼することはできません。そのため、ファイアウォールは、クライアントが接続したいIPを逆引きしてそれに基づいて決定することはできません。クライアントから名前を渡され、それに基づいて決定を下す必要があります。暗号化された接続の場合でも、クライアントは接続を確立する前にプロキシに名前を渡すため、HTTPスタイルのプロキシはこれでうまく機能します。
このアプローチの問題は、リモートドメインに対するDNSクエリの結果に基づいて効果的にセキュリティを確立することです。逆引きDNSは、所有するIPに誰でも任意の名前を付けることができるため、信頼できない決してできません。しかし、フォワードDNSでも必要なセキュリティが不足しています。中程度の動機を持つ攻撃者が、データセンターからPCIデータを盗み出すことを許可すれば、DNSをスプーフィングまたはポイズニングできると安全に想定できます。
（これは、QSAによってこれを祝福できなかったという意味ではありません。これは妥当な代償制御です。完全に安全だとは思わせたくないだけです！）
私 同じ問題に近づきました -あなたと同じ理由で-1年以上前、「安全な」方法ではリモートサイトを保証するためにDNSよりも何かが必要であり、SSL証明書はセキュリティを固定するための合理的なものでした。私はそのようなプロキシを実装し、それを私の目的に使用することになりました。 mr.spuraticが提供した回答 は同じことを約束します（私がまだそれを受け入れていない唯一の理由は、最初にテストする必要があると感じているためです）。
証明書によるプロキシホワイトリスト化のアイデアは、このシナリオではこれまで私が個人的に考えたこともなかった、非常に興味深い/きちんとしたアイデアです。私は間違いなくそれを一目見て、それがあなたの状況で機能するかどうかを確認します。
ただし、あなたが言った古い、やや単純なソリューションについて少しお話ししましょう。DNSチェックを定期的に実行するスクリプトを設定して、現在どのIPアドレスが機能するかを確認します。特に： 関連する質問 が数年前にUnix＆Linux SEで質問された場合、crontabルールを使用してIPをチェックするiptablesのサンプルスクリプトがいくつか生成されました。 5分ごとに特定のドメイン（特定のケースではDynamicDNSから）を作成し、そのIPからのinboundトラフィックを許可するルールを作成します。このような既存のスクリプトを使用できなかった理由はわかりません。ルールタイプをoutboundに設定し、その他の有用な加算または減算を行います。それにあなたが好きで、あなたが行く。理想的にはエレガントではありませんが、このアプローチをハッキーまたはギミックと呼ぶことはありません。
そのLinux SEの質問 からサンプルコードを直接コピーして貼り付けることが適切かどうかわからないので、私はしません。ただし、質問ページには2つの回答しかなく、それぞれにスクリプトサンプルが1つあります。読むことも、並べ替えることもまったく難しくありません。
最後に、DNSルックアップ自体のセキュリティを強化するためにできることを実際に検討する必要があります。理論的には、支払いソフトウェアがhttpsを介してのみ金融機関と通信し、受信サーバーが有効な証明書を持つことによって正当なものとしてクライアントに認証されている場合。その場合、悪意を持って変更されたDNS結果（ ローカルのMitM DNSスプーフィング、接続先の解決サーバーに対して行われたDNSキャッシュポイズニングに関係なく など） されません攻撃者が安全な接続に侵入できるようにするのに十分です あなたが財務情報を送信していること。 （攻撃者によって設定された偽のサーバーの証明書はドメイン名と一致しないためです。）しかし、多層防御について考えており、1つのレイヤーで何か問題が発生する可能性があると想定しているためです。セキュリティ（おそらく Certificate Authorityの秘密署名キーが危険にさらされているように 攻撃者が任意のドメイン名で任意のサーバーに署名できるようにするため）、DNSクエリに対するある種の強力な保護が必要だと仮定しましょう。残念ながら、これは（a）実際にDNSサーバーを実行している DNSSec を有効にし、ポイズニング攻撃を防ぐために適切に構成されている-接続を行うローカルマシンで直接実行するか、または（b） DNSCrypt を使用して、暗号化された接続を OpenDNS またはローカルネットワーク内に設定した信頼できるDNSサーバー（DNSSecがオン）に接続します。
したがって、少なくとも1つまたは2つのオプションがあります。