アジェンダ：
01 - はじめに
02 - IEEE802.1X認証の概要
03 - IEEE802.1X認証の構成要素と動作フロー
04 - IEEE802.1X認証の設定・確認方法
05 - IEEE802.1X認証：動作フローのキャプチャ
01 - はじめに
ネットワーク環境では、LANポートにケーブルを接続するだけで通信できる状態では、不正な端末の接続や意図しないネットワーク利用を防ぐことが困難です。
このような課題に対して利用される技術の一つが IEEE802.1X認証 です。
IEEE802.1X認証を導入することで、ネットワークへ接続する端末やユーザを認証し、認証に成功した端末のみ通信を許可するアクセス制御を実現できます。
また、一般的なIEEE802.1X認証の検証では、Windows PCなどの端末を認証クライアント(通常Supplicantと呼びます)として利用します。しかし、PCを利用した検証では、OS側の認証設定やGUI操作が必要となり、ネットワーク環境によっては認証処理の詳細な動作確認が難しい場合があります。
そこで本シリーズでは、CiscoルータをIEEE802.1XのSupplicantとして動作させ、CLIベースで認証処理を確認する方法を紹介します。
本シリーズの構成
本シリーズでは、IEEE802.1X認証を基本動作から応用機能まで段階的に確認します。
| 主な内容 | |
|---|---|
| 第1回 | IEEE802.1X基本動作(EAP-MD5認証)★今回の内容 |
| 第2回 | Dynamic VLANによる認証後のVLAN制御 |
| 第3回 | Per-User ACLによる認証ユーザ単位のアクセス制御 |
対象読者
本シリーズは、以下のような方を対象としています。
・ネットワークエンジニア、インフラ管理者の方
・Cisco Catalystスイッチを利用したネットワークアクセス制御について理解したい方
・IEEE802.1X認証の基本動作や認証フローを学習したい方
・RADIUSを利用した認証連携について理解したい方
・Dynamic VLANやPer-User ACLなど、認証後のアクセス制御について学習したい方
Cisco Catalyst、RADIUS、認証ネットワークに関する基本的な知識を前提としていますが、IEEE802.1Xをこれから学習する方にも理解できるよう、認証フローや実際のパケットキャプチャを用いて説明します。
02 - IEEE802.1X認証の概要
IEEE802.1Xとは
IEEE802.1Xとは、ネットワークへ接続する端末やユーザを認証し、認証された端末のみ通信を許可するためのポートベースネットワークアクセス制御の規格です。
一般的なLAN環境では、LANケーブルを接続するとネットワークへアクセスできる構成が多くありますが、IEEE802.1Xを導入することで、接続時に認証処理を実施し、不正な端末や許可されていないユーザの接続を制御できます。
なぜIEEE802.1X認証が必要なのか
企業ネットワークでは、社内LANへの不正接続や未管理端末の接続を防止することが重要です。
MACアドレスによる制御やWeb認証などの方式もありますが、IEEE802.1Xでは認証サーバ（RADIUS）と連携することで、ユーザや端末単位で柔軟なアクセス制御を実現できます。
また、認証結果を利用することで、接続先VLANの変更（Dynamic VLAN）やアクセス制御（Per-User ACL）など、認証後のネットワーク制御にも利用できます。
従来のCatalystスイッチではIEEE802.1X認証を「dot1x」と表記します。設定コマンドもdot1xという名称が使用されています。また他の認証方法としてMAB(MAC Authentication Bypass)やブラウザベースのWEB代理認証などが提供されています。それぞれの特徴としては以下があります。
| 項目 | IEEE802.1X認証 | MAB認証 | WEB認証 |
|---|---|---|---|
| 認証開始 | 端末(Supplicant) | Switch | Switch/WLC |
| 端末操作 | 手動・自動 | 不要 | ブラウザ操作 |
| IP取得前認証 | 可能 | 可能 | 通常IP取得後 |
| 認証情報 | ID,パスワード、証明書等 | MACアドレス | ID/パスワード |
| プロトコル | EAP | MACアドレス照合 | HTTP/HTTPS(認証ページ) |
| 主な用途 | 企業LAN | 802.1X非対応機器(プリンタ、IoT等) | ゲスト環境 |
IEEE802.1Xで利用される主な認証方式
IEEE802.1Xでは、認証処理にEAPを利用します。
EAPには複数の認証方式があり、利用環境やセキュリティ要件に応じて使い分けます。
代表的な認証方式として、以下があります。
| 項目 | MD5 | PEAP | TLS |
|---|---|---|---|
| 認証方式 | ID/パスワードによるチャレンジレスポンス認証 | TLSトンネル内でID/パスワード認証 | 電子証明書による相互認証 |
| 暗号化 | なし | あり | あり |
| 証明書 | 不要 | サーバ証明書 | クライアント・サーバ証明書 |
| セキュリティ | 低い | 高い | 非常に高い |
| 導入難易度 | 低 | 中 | 高 |
| 主な用途 | 検証・学習用 | 企業LAN | 高セキュリティ要件 |
*EAP - Extensible Authentication Protocol
*MD5 - Message Digest 5
*PEAP - Protected Extensible Authentication Protocol
*TLS - Transport Layer Security
IEEE802.1Xで実現できること
IEEE802.1X認証を導入することで、以下のような制御が可能になります。
・認証された端末のみネットワーク利用を許可
・ユーザや端末単位でのアクセス管理
・RADIUSによる認証情報の集中管理
・認証結果に応じたVLAN制御（Dynamic VLAN）
・認証ユーザ単位のアクセス制御（Per-User ACL）
03 - IEEE802.1X認証の構成要素と動作フロー
IEEE802.1X認証は、単一の機器だけで動作するものではなく、以下の3つの要素で構成されます。
Supplicant（サプリカント）
Authenticator（オーセンティケータ）
Authentication Server（認証サーバ）
それぞれが異なる役割を持ち、EAP（Extensible Authentication Protocol）を利用して認証処理を実行します。
今回の検証環境では、以下の機器が各役割を担当します。
| 役割 | 機器 | バージョン | feature-set/ソフトウェア |
|---|---|---|---|
| Supplicant | Cisco1921 | 15.7(3)M8 | IP-Base |
| Authenticator | Catalyst3560G | 15.0(2)SE11 | IP-Services |
| Authentication Server | 汎用サーバ | CentOS6.10 | FreeRADIUS |
※検証機器はすべてサポート終了済環境です。また、現行のIOS-XEではshow access-sessionなどコマンド体系が異なる部分があるかと思います。
Supplicant（サプリカント）
Supplicantとは、ネットワークへ接続する端末側の認証機能を指します。
IEEE802.1X認証では、Supplicantが自身の認証情報をAuthenticatorへ送信し、ネットワーク利用許可を得ます。
一般的には、以下のような端末がSupplicantになります。
・Windows PC
・Mac PC
・スマートフォン
・IP 電話
・ネットワーク機器等
今回の検証では、通常利用するWindows PCの代わりにCisco1921ルータをSupplicantとして利用します。
Cisco IOSでは、dot1x pae supplicant設定を有効化することで、Ciscoルータ自身がIEEE802.1X認証を受ける側として動作します。
Authenticator（オーセンティケータ）
Authenticatorとは、SupplicantとAuthentication Serverの間で認証処理を中継するネットワーク機器です。
一般的には、以下の機器がAuthenticatorになります。
・Catalystスイッチ
・無線LANアクセスポイント
・Wireless LAN Controller（WLC）等
Authenticatorの主な役割は以下です。
・Supplicantからの認証要求を受信
・EAPフレームの転送(EAP over LAN: EAPOL～RADIUS)
・認証サーバへの問い合わせ
・認証結果に応じたネットワークアクセス制御
今回の検証では、Catalyst3560GがAuthenticatorとして動作します。
Cisco Catalystでは、IEEE802.1X認証機能をdot1x pae authenticatorとして設定します。
Authentication Server（認証サーバ）
Authentication Serverとは、Supplicantから送信された認証情報を確認し、認証結果をAuthenticatorへ通知するサーバです。
IEEE802.1X認証では、一般的にRADIUSサーバを利用します。
今回の検証では、CentOS Linux上に構築したFreeRADIUSをAuthentication Serverとして利用します。
RADIUSとTACACS+の違い（参考）
RADIUS (Remote Authentication Dial-In User Service)とTACACS+（Terminal Access Controller Access-Control System Plus）は、どちらもAAAを提供するプロトコルですが、利用目的が異なります。
| 項目 | RADIUS | TACACS+ |
|---|---|---|
| 主な用途 | ネットワークアクセス認証 | ネットワーク機器管理者認証 |
| 利用例 | IEEE802.1X, VPN, 無線LAN | Cisco機器へのログイン等 |
| 認証対象 | 利用者・端末 | 管理者 |
| 通信方式 | UDP | TCP |
| ポート番号 | 1812/1813 | 49 |
| 暗号化 | 認証情報を保護 | 通信全体を暗号化 |
| AAA制御 | 認証と認可、アカウンティングを処理 | 認証・認可・アカウンティングを分離して制御可能 |
※古い環境ではRADIUSはUDP 1645(認証と認可), 1646(アカウンティング)が利用される場合があります。
IEEE802.1Xでは端末がネットワークへ接続する際の認証が目的となるため、RADIUSが標準的に利用されます。
今回の検証ではIEEE802.1X認証サーバとしてCentOS上のFreeRADIUSを利用します。
IEEE802.1X認証の動作フロー
認証処理の基本的な動作フローは以下になります。これを元に実機に設定を実施し確認を行います。
1．端末（Supplicant）とスイッチ（Authenticator）間でEAPOLによる認証処理を開始する
端末がネットワークへ接続すると、SupplicantとAuthenticator間でEAPOL（EAP over LAN）による認証処理が開始されます。
2．SupplicantからIdentity情報を送信する
AuthenticatorからのIdentity要求に対して、Supplicantはユーザ識別情報（Identity）を応答します。
3．AuthenticatorはEAP情報をRADIUSへ転送する
Authenticatorであるスイッチは、SupplicantとのEAPOL通信を受信し、EAPメッセージをRADIUSのEAP-Message属性としてカプセル化してAuthentication Serverへ転送します。
4．Authentication Serverは認証方式に応じた認証処理を実施する
Authentication Serverでは、設定されているEAP認証方式に応じて認証処理を行います。
今回利用するEAP-MD5では、RADIUSサーバからChallengeが送信され、SupplicantはChallengeを利用してResponseを生成します。
5．EAP認証方式に応じたユーザ認証を実施する
EAPには複数の認証方式があり、方式によって利用する認証情報が異なります。
例：
・EAP-MD5 → ユーザ名、パスワードによる認証
・PEAP → TLSトンネル内でユーザ認証
・EAP-TLS → 電子証明書による認証
6．認証成功後、端末はネットワーク通信が可能となる
認証成功時、Authentication ServerはAuthenticatorへRADIUS Access-Acceptを返します。
AuthenticatorはSupplicantへEAP-Successを通知し、対象ポートをAuthorized状態へ変更します。これにより、端末はネットワーク通信が可能になります。
04 - IEEE802.1X認証の設定・確認方法
次に以下の基本構成図を元に各機器の設定を実施します。
※今回は効率よく検証するための目的ですのでclients.conf 0.0.0.0/0全宛先からの許可や共有シークレット"cisco"、EAP-MD5認証や後述のPer-User ACLで利用するtelnet等を使用しています。本番環境では送信元の限定やセキュリティ面を考慮した共有シークレットやEAP認証方法、SSHなどの確認方法をご検討頂いた方がよろしいかと思います。
・C1921-1：Supplicantの設定を実施します。
Cisco1921の設定 [hostname C1921-1]
eap profile EAP
method md5
!
dot1x system-auth-control
!
dot1x credentials USER01
username user01
password password1
!
interface GigabitEthernet0/1
mac-address 0000.0000.1111
ip address 10.0.10.101 255.255.255.0
dot1x pae supplicant
dot1x credentials USER01
dot1x supplicant eap profile EAP
!
・C1921-1：Supplicantの状態を確認します。
C1921-1#sh dot1x
Sysauthcontrol Enabled
Dot1x Protocol Version 3
C1921-1#sh dot1x interface Gi0/1
Dot1x Info for GigabitEthernet0/1
-----------------------------------
PAE = SUPPLICANT
StartPeriod = 30
AuthPeriod = 30
HeldPeriod = 60
MaxStart = 3
Credentials profile = USER01
EAP profile = EAP
・C3560G：Authenticatorの設定を実施します。
Catalyst3560Gの設定 [hostname Cat3560G]
aaa new-model
aaa authentication dot1x default group radius
!
radius server RADIUS
address ipv4 192.168.1.101 auth-port 1812 acct-port 1813
key cisco
!
dot1x system-auth-control
!
interface GigabitEthernet0/7
no switchport
ip address 192.168.1.254 255.255.255.0
!
interface GigabitEthernet0/23
switchport mode access
authentication order dot1x
authentication port-control auto
dot1x pae authenticator
shutdown
!
・CentOS6：Authentication Serverの設定を実施します。
FreeRADIUSの設定
NIC設定：/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.101
NETMASK=255.255.255.0
AAAクライアントの設定：/etc/raddb/clients.conf
client 0.0.0.0/0 {
secret = cisco
shortname = Cat3560G
}
認証ユーザの設定：/etc/raddb/users
user01 Cleartext-Password := "password1"
FreeRADIUSの確認：一旦サービスをリスタートしておきます。
[root@localhost raddb]# /etc/init.d/radiusd restart
Stopping radiusd: [ OK ]
Starting radiusd: [ OK ]
・C3560G：認証を開始します。
Cat3560G(config)#int g0/23
Cat3560G(config-if)#no shutdown
IEEE802.1X認証が成功し以下のステータスになります。
Cat3560G#sh authentication sessions
Interface MAC Address Method Domain Status Session ID
Gi0/23 0000.0000.1111 dot1x DATA Authz Success C0A801FE000000B746A95E4A
Cat3560G#show authentication sessions interface gigabitEthernet 0/23
Interface: GigabitEthernet0/23
MAC Address: 0000.0000.1111
IP Address: 10.0.10.101
User-Name: user01
Status: Authz Success
Domain: DATA
Security Policy: Should Secure
Security Status: Unsecure
Oper host mode: single-host
Oper control dir: both
Authorized By: Authentication Server
Vlan Policy: N/A
Session timeout: N/A
Idle timeout: N/A
Common Session ID: C0A801FE000000B746A95E4A
Acct Session ID: 0x000000B9
Handle: 0x430000B8
Runnable methods list:
Method State
dot1x Authc Success
05 - IEEE802.1X認証：動作フローのキャプチャ
採取したキャプチャーを元に確認します。
-
EAPOL-Start
SupplicantであるCisco1921から、IEEE802.1X認証開始を通知するEAPOL-Startが送信されます。
このフレームにより、AuthenticatorであるCatalyst3560Gに対して認証処理の開始を通知します。
-
EAP-Request/Identity
Catalyst3560GからIdentity情報を求めるEAP Requestが送信されます。
-
EAP-Response/Identity
Cisco1921からIdentity情報を含むEAP Responseが送信されます。
Authenticatorは、このEAPメッセージを受信し、認証サーバへ転送するための処理を行います。
-
RADIUS Access-Request
Catalyst3560Gは、Supplicantから受信したEAP情報をRADIUSのEAP-Message属性へ格納し、認証サーバへAccess-Requestを送信します。
-
RADIUS Access-Challenge
認証サーバはEAP-MD5認証に必要なChallenge情報を生成し、Catalyst3560Gへ返します。
-
EAP-Challenge Request（MD5 Challenge）
Catalyst3560Gは、認証サーバから受信したRADIUS Challenge情報をEAP RequestとしてCisco1921に転送します。
-
EAP-Challenge Response（MD5 Challenge Response）
Cisco1921は、受信したChallenge情報と自身の認証情報を利用してResponseを生成します。生成したResponseをCatalyst3560Gへ送信します。
-
RADIUS Access-Request
Catalyst3560Gは、Cisco1921から受信したEAP Responseを再度RADIUS Access-Requestとして認証サーバへ送信します。
-
RADIUS Access-Accept
認証成功の場合、FreeRADIUSはCatalyst3560GへRADIUS Access-Acceptを返します。
-
EAP-Success
Catalyst3560Gは認証成功を確認し、Cisco1921へEAP-Successを通知します。
その後、認証ポートはAuthz Success状態となり、通信が許可されます。
まとめ
IEEE802.1X認証では、AuthenticatorがSupplicantとの認証処理を仲介し、認証サーバと連携して端末の認証を行います。認証が成功するとAuthenticatorによって通信が許可され、Supplicantはネットワーク接続できるようになります。
今回のCisco1921をSupplicantとして利用した実機検証では、Cisco1921からのEAPOL-Startを契機にCatalyst3560GからEAP-Request/Identityが送信され、Cisco1921がEAP-Response/Identityを応答する動作を確認しました。
その後、Catalyst3560GがEAP情報をRADIUSへ中継し、Authentication Serverとの間で認証処理が行われることを確認し、一般的なIEEE802.1Xの認証フローと同様に動作することを確認しました。
次回は、IEEE802.1X認証による認証成功後の制御として、Dynamic VLANについて確認します。
認証ユーザごとに異なるVLANへ自動的に割り当てる仕組みを、今回と同じ検証環境を利用して確認します。