web-dev-qa-db-ja.com

802.1XとRADIUSは不正なAPを防ぎますか?

今日、同僚と話し合っていたところ、802.1Xを使用すると、ユーザーが不正なアクセスポイントに接続しているかどうかを認識できると彼は考えていたようです。

私はこれを理解していませんが、確かに、不正なアクセスポイントが最初から本物であると信じている場合は、元のアクセスポイントではなく、不正なRADIUSサーバーに対して認証しているだけでしょうか。

802.1Xが偽のネットワークへの接続をどのように阻止できるかわかりませんか?

4
Jason

802.1X認証(およびその後のWPAキー生成)には、サプリカント(クライアント)、オーセンティケーター(アクセスポイント)、および認証サーバーの3つのエンティティが含まれます。

Zoredacheが言ったように、クライアントと認証サーバー間の通信は、公開鍵暗号化によって保護されています(少なくともEAP-TTLSまたはEAP-PEAPを使用している場合)。元の認証サーバーを装うことはできません。

ただし、AP(802.1X言語のオーセンティケーター)のクライアント(サプリカント)への直接認証、またはその逆はありません。オーセンティケーターは、サプリカントと認証サーバーの間でのみメッセージを中継します。一部のEAPメソッドによって提供されるすべての高度な公開鍵暗号化と相互認証は、オーセンティケーターに対して透過的であるため、理論的には、不正アクセスポイント(MITM)によって傍受されて再生される可能性があります。

基本的な802.1Xでは、不正なオーセンティケーターに対する保護は実際にはありませんが、802.1Xを「WPAエンタープライズ暗号化」(EAP)に使用すると、追加のセキュリティが提供されます。

接続用のWPA暗号化キー(特に、クライアントとAP間の相互認証を有効にします-これは不正なAPから保護したいものです!)はアクセスポイントによって生成されません、ただし認証サーバーによって、セキュリティで保護された内部EAPチャネルを介してクライアントに中継されます。もちろん、アクセスポイント(=認証者)がクライアントと通信するには、キーについても知っている必要がありますが、クライアントではなく、認証サーバーからのキー。

通常の構成では、サーバーはサードパーティによる認証要求を受け入れません。通常、認証システムの限られたセットとのみ通信し、通信は通常暗号化されます(ペアワイズRADIUSシークレット))。したがって、MITMが適切なアクセスポイントを正常に模倣するには、攻撃者は次のようになります。認証サーバーに対する有効なアクセスポイントの役割を模倣します。

簡単に言うと、不正なAPに対する保護は、オーセンティケーター(APなど)と認証サーバー間の認証と暗号化と同じくらい優れています。

不正なAPを作成した場合、実際には802.1X認証の中継に成功する可能性があります。ただし、WPAキーが不明)で暗号化されるため、クライアントトラフィックを読み取ることはできません。同様に、不正APによってクライアントに送信されるものはすべて次のようになります。 WPAキーはメッセージ認証にも使用されるため、クライアントによって拒否されました。

2
lxgr

802.1xでは、一部の構成でPKIを使用した相互認証が可能です。これは [〜#〜] tls [〜#〜] を使用できます。これは、安全なWebブラウジングに使用されるプロトコルです。

クライアントとAPの両方に秘密鍵と公開鍵のペアがあります。公開鍵は、クライアントとAPの両方で信頼されるように構成された3番目のシステムによって暗号で署名された証明書に含まれています。秘密鍵とCAが危険にさらされていない限り、両方のマシンがプロトコルを使用して 相互に認証 相互に認証できます。

欠点は、すべてのPKIの管理に、単純な共有キーよりもはるかに多くの労力がかかることです。

1
Zoredache