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