機密データを含む内部アプリを展開する予定です。一般的なインターネットには公開されておらず、内部ネットワークのみに公開されているマシンに配置することを提案しました。IT 部門は、1 つのアプリケーションのためにマシン全体を確保する価値はないと言って、この提案を拒否しました。（関連する場合に備えて、アプリには独自のドメインがありますが、URLに基づいてリクエストをブロックできないと言われました。）
アプリ内で、内部 IP アドレスからのリクエストのみを尊重するようにプログラムしました。私たちの内部アドレスはすべて異なるパターンを持っているため、リクエスト IP を正規表現と照合しています。
しかし、私はこの戦略に神経質になっています。なんだかジャンキーな感じです。これは合理的に安全ですか？
IP フィルタリングは何もないよりはましですが、2 つの問題があります。
IP アドレスはスプーフィングされる可能性があります。
内部マシンが侵害された場合 (トロイの木馬のインストールなどによってクライアント ワークステーションを含む)、攻撃者はそれをジャンプ ホストまたはプロキシとして使用してシステムを攻撃できます。
これが本当に機密データである場合、専用のマシンは必ずしも必要ではありません (ベスト プラクティスですが) が、少なくとも何らかの方法でユーザーを認証する必要があり、機密性の低い (そして攻撃されやすい) アプリをサーバー上で実行しないでください。同じマシン。
そして、それが本当に機密性の高いものである場合は、セキュリティの専門家に自分の行っていることを確認してもらいます。
編集：ちなみに、可能であれば、正規表現を捨てて、OS内のtcpwrappersまたはファイアウォール機能などがある場合はそれを使用してください。または、アプリに別の IP アドレスを使用できる場合は、ファイアウォールを使用して外部アクセスをブロックします。（そして、ファイアウォールがない場合は、あきらめて、データを攻撃者にメールで送信することもできます:-)
IPフィルタリングの代わりに、SSLといくつかの証明書、または単純なユーザー名/パスワード保護を使用したいと思います.
それは、本当に必要な安全性に正確に依存します。
サーバーが外部でホストされており、VPN 経由で接続されていないと想定しています。したがって、HTTPS (HTTPS を使用していますよね??) サイトの要求アドレスが組織のネットワーク内にあることを確認しています。
正規表現を使用して IP アドレスを照合するのは難解に聞こえますが、他の人と同じようにネットワーク/ネットマスクを使用することはできませんか?
本当に必要な安全性は？IP アドレスのスプーフィングは簡単ではありません。スプーフィングされたパケットを使用して HTTPS 接続を確立することはできません。上流のルーターも操作して、戻りパケットを攻撃者にリダイレクトできるようにする場合を除きます。
本当に安全にする必要がある場合は、IT 部門に VPN をインストールしてもらい、プライベート IP アドレス空間を介してルーティングしてもらいます。これらのプライベート アドレスの IP アドレス制限を設定します。ルーティングがホストベースの VPN 経由である場合の IP アドレス制限は、上流のデフォルト ゲートウェイが侵害された場合でも安全です。
アプリケーションが IP アドレスをチェックしている場合、非常に脆弱です。その時点で、IP フィルタリングが本当に必要なルーターでの保護はありません。あなたのアプリケーションはおそらく送信 IP アドレスの HTTP ヘッダー情報をチェックしていますが、これは非常に簡単になりすますことができます。ルーターで IP アドレスをロックダウンする場合、それは別の話であり、誰がどこからサイトにアクセスできるかについて、いくらかの本当のセキュリティを購入できます.
アプリケーションに内部的にアクセスしている場合、組織の内部関係者からの情報を保護しようとしているか、クライアント証明書が必要でない限り、SSL はあまり役に立ちません。これは、外部接続からサイトにアクセスしないことを前提としています (VPN はカウントされません。これは、内部ネットワークにトンネリングしており、技術的にはその時点でその一部であるためです)。害はなく、セットアップもそれほど難しくありませんが、それがすべての問題の解決策になるとは思わないでください.
他の人が述べたように、IP ホワイトリストは、IP スプーフィングや中間者攻撃に対して脆弱です。MITM では、一部のスイッチまたはルーターが侵害され、「応答」が表示されると考えてください。それらを監視したり、変更したりすることさえできます。
SSL 暗号化の脆弱性も考慮してください。努力に応じて、これは MITM や素数の再利用などのよく知られたギャフで失敗する可能性があります。
データの機密性にもよりますが、私は SSL で満足することはありませんが、セキュリティを強化するために StrongSWAN または OpenVPN を使用します. これらを適切に処理すれば、MITM に対する脆弱性は大幅に軽減されます。
ホワイトリストへの依存のみ (SSL を使用している場合でも) は「低グレード」と考えますが、ニーズには十分かもしれません。その意味を痛感し、「誤った安心感」の罠にはまらないようにしてください。
IP アドレスで制限されている場合、IP アドレスを偽装することはできますが、応答を取得することはできません。もちろん、インターネットに公開されている場合でも、アプリ以外の攻撃を受ける可能性はあります。
すべての内部 IP が特定の正規表現に一致するからといって、特定の正規表現に一致するすべての IP が内部のものであるとは限りません。したがって、正規表現はセキュリティ障害の可能性のあるポイントです。
サイトの構築にどのようなテクノロジを使用したかはわかりませんが、Windows/ASP.net の場合は、要求が行われたときに Windows 資格情報に基づいて、要求元のマシンのアクセス許可を確認できます。
適切なファイアウォールは IP スプーフィングから保護できますが、それは発信者 ID のスプーフィングと言うほど簡単ではありません。セキュリティはレイヤーで適用するのが最適であるため、1 つのメカニズムだけに依存することはありません。そのため、WAF システム、ユーザー名とパスワード、レイヤー 3 ファイアウォール、レイヤー 7 ファイアウォール、暗号化、MFA、SIEM、およびその他のセキュリティ対策のホストがあり、それぞれが保護を追加します (コストは増加します)。
これがあなたが話している Web アプリケーション (あなたの質問からは明確ではありませんでした) である場合、ソリューションは高度なセキュリティ システムのコストなしでかなり単純です。IIS や Apache などを使用しているかどうかに関係なく、アプリへの接続を特定のターゲット URL とソース IP アドレスに制限することができます。アプリを変更する必要はありません。アプリケーションごとに変更する必要はありません。アプリの IP ベースの Web ブラウジングを防止し、IP ソースの制限を組み合わせることで、カジュアルなブラウジングや攻撃から大幅に保護できます。これが Web アプリでない場合は、OS ベースのセキュリティ (他の人が提案しているように) が唯一の選択肢かどうかを人々が知ることができるように、より具体的にする必要があります。
リソースの問題について私が最初に考えたのは、仮想マシンで何らかの魔法を働かせることができないかということです。
それ以外 - チェックする IP アドレスが、アプリケーションにアクセスすることになっているコンピュータまたはローカル IP 範囲に属している既知の IP のいずれかである場合、それがどのように十分に安全ではないのかわかりません (私は実際に使用していますプロジェクトでの同様のアプローチ atm ですが、サイトが「非表示」に保たれていることはそれほど重要ではありません)。
多分これは役立つでしょうか？私は同じ答えを探していましたが、このスタックオーバーフローと Red Hat Linux Ent からのこのアイデアを見つけました。早速やってみます。お役に立てば幸いです。
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP
0/24 は、保護する LAN 範囲です。これは、「インターネット」に面している (Forward) デバイスがローカル IP ネットワークを偽装できないようにすることを目的としています。
参照: http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-firewall-ipt-rule.html
セキュリティは、最も弱いリンクと同じくらい強力です。物事の壮大な計画では、IP のスプーフィングは子供の遊びです。SSL を使用し、クライアント証明書を要求します。