web-dev-qa-db-ja.com

ファイアウォールで定義されたアカマイのIP範囲

幅広い範囲のIPを開くことの明らかな危険性があるため、AkamaiのIP範囲のソースを取得する方法を誰かが知っていますか?

アカマイに話しかけると、彼らは「不可能」だと言いますが、これは驚くべきことです。

米国/テキサス/アーリントン(地域)で提供される一連のIPが必要です

これにどう対処するか考えましたか? AkamaiサーバーのIPで「範囲」や回答を見つけることができないようで、セキュリティチームが送信トラフィックを承認できません。

だから問題は、セキュリティ上の懸念としてこれに取り組んだ人はいますか?私の唯一の考えは、アウトバウンド接続にプロキシサーバーを使用することでリスクを軽減し、アウトバウンド攻撃の可能性を制限することです。

11
Jakub

Akamai Technologies、Inc.は現在、次の14の下でIP範囲を公開しています [〜#〜] asn [〜#〜] s(リストを米国ベースのオペレーションに限定):

AS3618AS35994AS3599AS30675AS23455AS23454AS22207AS20189AS18717AS1868AS17334 、- AS16702AS16625AS12222

ただし、IP範囲のリストは数千にも及びます(約4000)ので、- 逆DNSルックアップ に基づいてファイアウォールルールを定義することをお勧めします(機器で可能であれば)、またはインポートリストをコンパイルします"How to get info on company、company ownsite etc…?"への回答で説明するアプローチを使用します。

問題は、これらのASNとIP範囲が絶えず変化する可能性があり、リストを定期的に更新する必要があることです。

または、ネットワークが割り当てられているASNの下で公開されているIP範囲(IPv4またはIPv6、あるいはその両方)のみを抽出し、うまくいけば、そのリストをより扱いやすい範囲の数に制限できます。


追加して編集します:質問へのコメントで、rDNSは安全でないため質問外だと言っています。これらのレコードは、DNSの逆引き参照でチェックされるため、簡単に偽装される可能性があります。これをチェックする1つの方法がありますが、これは、途方もなく長いIP範囲リストに頼らずにファイアウォールフィルターを自動化することも可能であることを意味します: Forward-confirmed reverse DNS Look-up

ファイアウォールアプライアンスが実際にこのチェックを実行できるかどうかはわからないので、それは不可能かもしれませんが、実行できる場合は、接続しているクライアントのIPを取得し、逆DNSルックアップを実行します。次に、返されたDNS名をAまたはAAAAレコードに対してクエリします。返されたリストにクライアントIPが含まれている場合、FCrDNSは成功しました。それ以外の場合は成功しませんでした。このFCrDNSがどのように使用され、それが何に適しているかについてのもう少し詳しい説明は、私の この質問 を参照してください。

14
TildalWave