企業はどのようにしてパケットのなりすましへの露出を減らすことができますか？どのようなソリューションが存在する必要がありますが、存在しませんか？
着信パケットを検証するために、どのようなパケット偽装テクノロジーが存在する（または存在する必要がある）かを理解したいと思います。たぶん、これはネットワーク境界で実装されたCisco ACL、ファイアウォールルールと同じくらい簡単です。しかし、問題はもう少し複雑かもしれません。
一般に、これらの一連の考え方を使用して、ソースIPブロッキングから開始します。
- 使用されていないIP範囲を削除する（インターフェイスごと）
- 使用中のIP範囲を削除しますが、そのインターフェイスでは送信者として表示されません。
たとえば、10.x以降のすべての送信元アドレスを削除するようにパブリックインターフェイスが構成されている可能性があります。 192.xネットワークと172.xネットワークをルーティングすることもできます。各アドレス空間全体を制御するため、ルーターのエッジを通過するスプーフィングを制御できます。
しかし、インターネットからのトラフィックのブロックには問題があります。
ISPからのインバウンドトラフィックには、ソースアドレスに適用されるルールがない可能性があります。 ISPの遅延とコスト削減の努力からIPスプーフィングが許可されているか、または（奇妙なIPモビリティ機能を有効にするために）正当な技術的理由がある可能性があります。しかし、IPスプーフィングがインターネットのユーザーの大多数にとって関連するテクノロジーであるとは私は思いません。
IPスプーフィングが実際にインターネットの「機能」である場合、テクノロジーを廃止し、そのまれなソフトウェアをより高いレベルのプロトコルを使用するように再構成する必要があると思います。 （IPスプーフィングが必要な理由について このリンク で説明してください）
[質問]
インターネットに接続している企業はどのようにしてIPスプーフィングへの露出を減らすことができますか？それはどのように実装されますか？
存在しない代替案はありますか？
私の質問の2番目の部分は、インターネット上でIPスプーフィングが不自由になったりブロックされたりした理想的な「グリーンフィールド」の希望から来ています。 IPスプーフィングを減らすことで、さまざまな種類の攻撃（DDOS、UDP/DNSハッキングなど）への露出も大幅に減ると思います。おそらく、リアルタイムルーティングテーブル、サブスクリプションベースのサービス、またはその他のテクノロジーを利用しています。
一般的なケースでは、アドレスを偽装したパケットを区別することは非常に困難です。ほとんどのシステム（サーバーまたはネットワークデバイス）にはNICが1つしかないため、すべてのトラフィックが同じポートに着信します。静的MACエントリは、付随的な損傷を軽減するのに役立ちますが、すぐに管理の悪夢になります。スプーフィングされたトラフィックを検出してフィルタリングできる数少ない場所の1つはルーターです。
ネットワークボーダーは、間違いなく、このフィルタリングを行う最も簡単な場所です。ここでは、IPアドレスがどの方向に流れるべきかveryの良いアイデアがあるはずです。最初にすべてのBogonアドレスをブロックします。 BGPを使用している場合、Team Cymruは Bogon Route Server Project についてよく書いています。また、ASAの例（X.X.X.Xを割り当てに置き換え、Y.Y.Y.Yをネットマスクに置き換えます）の外で独自のアドレススペースをブロックするためのACLを含めます。
access-list outside_access_in extended deny ip X.X.X.X Y.Y.Y.Y any
ホストレベルで、厳しく制限されたファイアウォールルールを設定します。ここでは、オーディエンスとサービスを厳密に定義し、続いてデフォルトの拒否を定義する必要があります。
最新のファイアウォールとルーターは、さまざまな基準に基づいてフィルタリングできます（他の人が指摘したとおり）。
- プライベートアドレス範囲-これらはパブリックインターフェイスでは表示されません。
- 内部アドレスが外部から到着しないようにする必要があります（入力フィルタリング）
- 出力フィルタリング：組織は、ネットワークを出るパケットに有効な内部アドレスを知っている必要があります
- パックで言及されているBogons。
- MACアドレスをIPアドレスに（サブネット/ブロードキャストドメインごとに）照合できるため、内部アドレスは簡単に検証できます。
- ルーター：対称ルーティングでは、送信元アドレスが着信したインターフェースとは異なるインターフェースをルーティングする場合、偽装されているか、対称的ではありません。
- DNSシーケンス攻撃から保護する-シーケンス番号がランダム化されていることを確認する-DNS攻撃のスプーフィングの影響を最小限に抑える
- ブロードキャストアドレスへの外部アクセスを防止します（一般的な安全、スマーフ攻撃）
IPスプーフィングはISPの遅延とコスト削減の努力から許可されているようです、または正当な技術的理由がある可能性があります
技術的/コスト上の理由は、一部のコアルーターが非常に大量のトラフィックを処理するため、（少なくとも5年前は）フィルタリングのパフォーマンスが低下するためです。
IPスプーフィングが減少すると、さまざまなタイプの攻撃（DDOS ...）への露出も大幅に減少すると思います。
DDoSは一般にスプーフィングを使用しません。攻撃を行うゾンビを保護する必要はありません。私見、インターネット全体のなりすましは、コストが攻撃の軽減をはるかに上回るため、成功していません。なりすましを使用する標的型攻撃者は、おそらく他の多くの方法を使用するスキルを持っており、ゾンビに簡単にアクセスして有効なIPアドレスを使用することができます。 （私はここでも時代遅れです）
その他の参考資料
物理または仮想の1つまたは複数のインターフェイスへのネットワークトラフィックを管理することに関心がある場合は、実行可能なソリューションがいくつかありますが、ファイアウォールでこれを行うのは非常に簡単です。たとえば、同じネットワークに接続された2つの物理インターフェイスを持つマシンがあり、そのうちの1つでポート80トラフィックのみを受け入れたい場合、ファイアウォールルール（この場合はiptables）を次のように作成できます。
DROP all - anywhere non-80-IP tcp dpt:80
これは非常に大まかな例ですが、TCPを介してポート80で受信した要求に、IPで指定されたインターフェイスに送信されるパケットは送信されません。
もちろん、問題のネットワークの上流ルーターを制御またはアクセスしている場合、望ましくないトラフィック（上記の例ではTCPポート80）を問題のインターフェースです。明らかに、これは内部ネットワークアクセスを制限しません。
火星の制御に興味がある場合は、いくつかのオプションがありますが、次のように構築された別のファイアウォールルールがあります。
DROP all - 10.0.0.0/8 iface-IP
これは、10.0.0.0/8ネットワークから発信されたすべてのパケットをドロップし、応答を送信しません。明らかに、これは特定のネットワーク構成には強すぎるかもしれませんが、最小限の調整で、問題のネットワークの悪魔を排除するのに役立つはずです。
私はあまりネットワークの人ではありませんが（大きなベンダーのファイアウォールの1つを開発しているチームにいたときに知っていたもののほとんどを忘れました）、私はほとんどのファイアウォール（おそらくルーターも）を少なくとも考えているようです）明示的に設定しない限り、インターフェース間を自動的にルーティングしません。
自己尊重するファイアウォールまたはルーターは、間違ったインターフェースからのパケットをルーティングしてはなりません。しかし、そのためのルールを簡単に確認できるはずです...
繰り返しになりますが、これは、ホストではなくネットワークの境界でこの検出を行っていることを前提としています。
正当なトラフィックが同じ送信元IPからのスプーフィングされたトラフィックと混合されると、スプーフィングに対してアプリケーションを強化することを試みる以外にできることはほとんどありません。したがって、スプーフィングされたトラフィックの効果的なブロックは、ソースに近い必要があります。
手動ルールは、単純なネットワークを持つ小規模な顧客やピアからのなりすましトラフィックの侵入を防ぐのに効果的ですが、大規模な顧客/ピアにはうまく拡張できません。
より自動化されたオプションは、リバースパスフィルタリング（urpf）です。基本的には、既知のルートに対して送信元アドレスをチェックし、送信元と予想される場所から送信されていないパケットをドロップします。
リバースパスフィルタリングには「厳密」と「実行可能」の2つのバリアントがあり、どちらにも問題があります。
「strict」モードでは、ソースへの「最適な」パスと比較します。問題は、これが複雑なネットワーク（インターネットを含む）に対して厳しすぎることです。ルーティングはしばしば非対称です
「実行可能」モードでは、現在の最適なパスでなくても、ソースへの実行可能なパスと比較します。これは正当なトラフィックをドロップする可能性は低くなりますが、実装するのは困難です（ルーターは通常、高速テーブルに最適パスを保持し、低速テーブルに他の実行可能なパスを保持します）。