WPA2と802.1x-サーバー証明書はどのように検証されますか？
現在のWPA2/PSKセットアップをWPA2 + 802.1xにRADIUS authenticationに置き換えます。そのために使用できるさまざまなアルゴリズムがあり、大きく2つのグループに分けられます。
ユーザーは証明書を使用してサーバーを認証します。
ユーザーには、認証用のユーザー名とパスワードがあります。
（1）はユーザーに証明書を配布する必要があるため、オプション（2）を使用します。
さて、問題は：どうすれば不正AP攻撃を緩和できますか？
RADIUSのサーバー証明書をすべてのクライアントに配布できます。しかし、これはオプション（2）を実装したい理由全体を打ち消します。
自己署名証明書を使用する場合、ユーザーはこの自己署名証明書を手動で受け入れる必要があります。攻撃者は自分の自己署名証明書を使用して不正なAPを簡単にセットアップできるため、ユーザーの資格情報を非常に簡単に盗むことができます（ユーザーが指紋を確認することはありません）。
しかし、RADIUSサーバーにCA（Let's Encrypt、またはほとんどのデバイスにある他のCAなど）によって署名された証明書を使用するとどうなりますか？クライアントはそれを自動的に受け入れますか？
攻撃者が同じパブリックCAにアクセスして、自分の有効な証明書を取得するのを阻止するものは何ですか？ （特定のドメインの証明書のみを受け入れるように指定する方法はありますか？）
前の質問への回答は、サーバー認証を提供するすべての802.1xメソッドに有効ですか？
その他の考慮事項：
WiFi-APとRADIUSサーバー間の通信をキャプチャおよび/またはスプーフィングする攻撃など、自分のネットワーク内に攻撃がある可能性があることを認識しています。私の設定では、この種の攻撃は直接（物理的に）接続されているか、直接のIPSec VPN接続があるため、無視できます。
RADIUSのサーバー証明書をすべてのクライアントに配布できます。しかし、これはオプションBを実装したい理由全体を打ち消します。
配布する必要があるRADIUSサーバーの証明書ではないことを言ってみましょう。これは、RADIUSサーバー証明書に署名したCAの証明書です。私は答えの少し後でこれに戻ります。
自己署名証明書を使用する場合、ユーザーはこの自己署名証明書を手動で受け入れる必要があります
一部のサプリカントは、証明書の検証が無効になっていない限り、自己署名サーバー証明書を受け入れません。
しかし、RADIUSサーバーにCA（Let's Encrypt、またはほとんどのデバイスにある他のCAなど）によって署名された証明書を使用するとどうなりますか？クライアントはそれを自動的に受け入れますか？
サプリカントによって異なります。一部はします、他はしません。なんらかの追加の構成（手動、GPO、MDMなど）がなければ、ほとんどの場合、それらの大部分が依然としてユーザーに証明書の承認を求めると言うこともできます。
攻撃者が同じパブリックCAにアクセスして、自分の有効な証明書を取得するのを阻止するものは何ですか？ （特定のドメインの証明書のみを受け入れるように指定する方法はありますか？）
同じパブリックCAですか？証明書を生成する前に、ドメイン所有者であることを確認しようとする合理的な試みを行うものを1つ選択してください。
ただし、主要なCAからの有効な証明書は多くの場合、同じ「保証」を提供し（EAPサプリカントが既知の有効なCAを使用している場合）、攻撃者が別の有効な証明書を取得する方が簡単な場合があるので、それは重要な点です。取得したCAからのCA（CAがすでに組織の正当な連絡先を持っている場合は、それらを使用して要求を検証する可能性があります）。
前の質問への回答は、サーバー認証を提供するすべての802.1xメソッドに有効ですか？
802.1Xで何が行われているのかについての簡単な入門書が役に立ちそうです。
一般的に言って、EAPサプリカント（選択したEAPメソッドに関係なく）は、ユーザー名/パスワードまたはその他の資格情報を認証サーバーに送信するかどうかを決定する必要がありますネットワークに接続せずに。つまり、接続前に持っていた情報と、認証サーバーから提供された情報しか処理できません。 EAPサプリカントは認証された後になるまでインターネットに出て別のソースをチェックできず、資格情報を保留するには遅すぎます。
EAPサプリカントは、主に2つのことをチェックすることでこれを実行します（WindowsやOSXのネイティブサプリカントなど、多くのEAPサプリカントにいくつかのオプションが存在しますが、タブレットや電話などのモバイルデバイスにはありません）。
- 認証サーバーによって提供された証明書は、クライアントデバイスによって信頼されたCAから発行された有効な証明書ですか？
- （オプション）証明書はEAPサプリカントの指定されたCAから発行されますか？
- 証明書に記載されているホスト名は、認証サーバーによって指定されたホスト名と一致していますか？
- （オプション）認証サーバーによって指定されたホスト名は、EAPサプリカントの構成で許可されているホスト名の1つですか？
サプリカントは、上記の1と3を通過した場合、ユーザーに証明書の承認を求めることもできます。または、EAPサプリカントは上記をスキップして、OSに証明書の「確認と承認」を求めるプロンプトを表示する場合があります（悪い考え）、または資格情報を送信する前に証明書をまったく検証しない（悪い考え）ように構成されている場合があります。
A）はユーザーに証明書を配布する必要があるため、オプションBを使用します。
何らかの証明書の配布は避けられない場合があります。多くの場合、クライアント証明書も配布するかどうかだけの問題です。 （EAP-TLSなどのクライアント証明書を使用してEAP方式を選択する場合は、共有クライアント証明書ではなく、ユーザー/デバイスごとに個別のクライアント証明書を強くお勧めします。）
多くの組織は、独自のCAをセットアップしてRADIUSサーバー証明書（および該当する場合はクライアント証明書）を生成します。これには、クライアントにもCA証明書をインストールする必要があります。
なぜ彼らはこれをするのでしょうか？ここにいくつかの理由があります：
- 費用-特に組織が多数の認証サーバーを実行している場合（通常、サーバーごとに証明書が必要なため）、認証サービス（HTTPS Webトラフィックだけでなく）を提供する証明書を取得すると負荷がかかる可能性があります。
- エンドユーザーへの影響の軽減-ほとんどのCAは証明書を最大3年間のみ発行します（現在は2年間のみ）。ワイヤレス認証サーバーの証明書が変更されると、少なくともエンドユーザーに変更が通知され、新しい証明書を受け入れるように求められます。場合によっては、EAPサプリカントは、再構成されるまでワイヤレスネットワークへの接続に失敗するだけです。独自のCAを実行している組織は、有効期限が3年を超える証明書を発行することを選択でき、エンドユーザーが証明書の変更によって影響を受ける頻度を減らします。
- セキュリティの強化-組織がパブリックCAを使用して認証証明書を発行する場合、「攻撃者」は組織のネットワークを「偽装」するのが簡単になります。攻撃者が自分の「認証サーバー」のホスト名と一致する有効な証明書をパブリックCAから取得するのは簡単です（場合によっては完全に無料です）。認証サーバーの特定のホスト名がEAPサプリカントで構成されていない場合（多くの場合、構成されていないかできない）、指定されたCAが構成されていてパブリックCAである場合でも、攻撃から証明書を取得する必要があります。同じパブリックCA。組織のCAのみが構成されている場合、他の証明書は受け入れられないため、攻撃者はCAを侵害して証明書を生成する必要があります。
どうすればルージュAP攻撃を緩和できますか？
どのようにアプローチしても、802.1Xはワイヤレス接続により高いレベルのセキュリティを追加しますが、クライアントデバイスの安全な構成をより困難にするという犠牲を払います。
Active Directory環境でWindowsのみに関心がある場合は、グループポリシーを使用して、正しい構成を適用し、証明書をインストールできます。
それ以外の場合（そして、今日Windowsのみを心配している人は？）、この問題に対処する最良の方法は、クライアントの大多数を最高レベルのセキュリティで構成できる多くの802.1Xオンボーディングソリューションの1つを使用することです。ただし、これらは取得や運用にコストがかかり、市場にあるほとんどの製品は、CA、NAC、およびRADIUSソリューションの一部としてバンドルされています。
Cisco ISE、SecureW2、Ruckus Cloudpath、Aruba Clearpath/QuickConnect、Impulse SafeConnectなどのソリューションは、この目的のために導入されたソリューションの一部です。または、選択した検索エンジンを使用して、「802.1Xオンボーディング」または「BYODオンボーディング」を検索します。
注：この回答の一部は、このサイトまたは他のサイトの他の場所から得られた自分の回答から得られました。
サーバー証明書とクライアント証明書を混同しています。ユーザー名とパスワードの代わりにクライアント証明書を認証に使用できますが、RADIUSサーバーのサーバー証明書はサーバーで認証される前に検証され、他の誰かのAPが盗んでいないことを確認します認証情報。
ユーザーに決定を任せると、一般的なユーザーは接続を確立することを目的としているため、実際には確認せずに常に証明書を受け入れます。したがって、グループポリシーを使用して設定を適用することをお勧めします。同じGPOを使用して、サーバーの公開証明書を配布できます：署名に使用したCA証明書RADIUSサーバー証明書または自己署名、テスト中に学んだように RADIUSサーバー証明書がWindows 10で実際に検証される場合 なので、この答えはWindowsに適用されますActive Directory環境。
例としてradius.example.comを使用してみましょうRADIUSサーバー。これに必要なすべての設定は、共通のグループポリシーパスの下にあります：コンピューターの構成>ポリシー> Windowsの設定>セキュリティ設定。
署名に使用するCA証明書またはRADIUSサーバーの自己署名証明書をグループポリシーを使用してすべてのクライアントコンピューターにインストールします。これは公開証明書である必要があります。サーバーキーをエクスポートしないでください！
セキュリティ設定>公開鍵ポリシー>信頼されたルート証明機関アクション：インポート...
Wireless Network（IEEE 802.11）Policiesに移動します
- アクション：Windows Vista以降のリリース用の新しいワイヤレスネットワークポリシーを作成します。
- ポリシーに名前を付け、追加...>インフラストラクチャ。
- ネットワーク名（SSID）を追加します。
- Securityタブに移動し、認証と暗号化を設定します。
- ネットワーク認証方法を選択し、プロパティを押してください...必要なもの：
- [x]証明書を検証して、サーバーのIDを確認します。
- [x]次のサーバーに接続します：
radius\.example\.com。 - 信頼されたルート証明機関：
[x] radius.example.com。 （certmgr.mscを使用して個人の信頼されたルート証明機関ストアに証明書をインポートした後、証明書はリストに表示されますが、最終的にはストアからコンピューターアカウントに使用されます。） - 接続前の通知：新しいサーバーや信頼できるCAを承認するようユーザーに要求しないでください。
- 認証方法の選択：EAP-MSCHAP v2の場合、構成... Windows資格情報を使用するかどうか。 （個人的には、コンピューター認証またはクライアント証明書、あるいはその両方を好みます。）