Catalyst 9800-CLのPublic Cloud版 (AWS, Azure, GCP)では、導入方式としてFlexConnectのLocal Switchingのみ (Cisco FlexConnect (local switching only))をサポートしています。
ドキュメント上ではData Sheetの Deployment modes supported に記載があります。
Public Cloudだと主にInternet越しの通信が想定されたり、通信量の従量課金があるので、無線LAN端末からの通信フローが必ずPublic Cloud経由となってしまうCentral Switcihingが適していない側面が一端にあると思われます。
なお、Catalyst 9800-CLの中でもPrivate Cloud版 (VMware vSphere ESXi等)では、Central Switching方式もサポートしているので混同しないように留意してください。
Palo Alto Networks製品資格の学習のためのStudy Guideは、Beaconと呼ばれる学習プラットフォームからダウンロードできるようになっています。 (以前は別のWebページからログイン不要でダウンロードができました。)
Beaconへは下記のページからログインができます。
無償で作成可能な LIVEcommunity のアカウントでもBeaconへログインして、Study Guideをダウンロードできるのは筆者が確認しました。
LIVEcommunity のアカウントの登録は、下記ページの Register for a LIVEcommunity account から行ってください。フリー メールでも登録が可能でした。
Beaconへのログインが可能になったら Study Guide と検索すると、各種Study Guideがヒットするので見つけやすいと思います。
https://beacon.paloaltonetworks.com/student/catalog/list?search=Study+Guide
学習プラットフォームの形態になっているので学習コース内のページ遷移が必要になります。
参考程度にPCNSAの場合のページ遷移を掲載しておきます。Study Guideの種類によっては一部ページの構造が変わっています。
Study Guideは体系的に学べる学習リソースなので活用してみてください。
Meraki MRにおいてSplash pageでのGoogle Workspace (旧G Suite)のOAuth認証の設定方法を整理しました。
SSIDへの接続タイミングでの認証ではなく、SSIDに接続した後のSplash page (Captive Portal)による認証であるため、混同しないように注意してください。
本内容は2023年09月頃に検証を行っております。
要件や設計に依存するものもありますが、大きく分けて3つの設定が関連します。
必須: Google OAuthの認証設定
必須: Splash pageのWalled Garden
任意: Splash pageの認証セッションのタイマー (Splash frequency)
Security の設定でSSID接続タイミングの認証設定を要件に合わせて修正します。
2023年09月頃の時点では下記がGoogle OAuthの設定に対応しております。
Open (no encryption)Opportunistic Wireless Encryption (OWE)PasswordIdentity PSK without RADIUS 筆者の場合は Password 設定によるPSK (Pre Shared Key)の認証を指定して、部外者が接続できないようにしました。
Splash page の挙動の設定を Sign-on with にしてパラメータに Google OAuth を指定します。
Allowed domains では任意で許可対象のドメインを絞れます。業務で社員のアカウントを認証する場合は、管理外のアカウントで認証をバイパスできないようにドメインを指定するのが好ましいと考えられます。
Advanced splash settings で Splash page (Captive Portal)に関わる設定をチューニングします。
Captive portal strength では認証前のユーザーの通信がブロックされるように Block all access until sign-on is complete を選択します。(デフォルト値です。)
Walled garden を Enabled にして、Google WorkspaceのOAuthの認証に必要な通信を許可します。Walled garden ranges には Gmail firewall settings / Gmail のファイアウォールの設定 の最新状況を確認した上で設定を行います。
2023年09月頃の時点では下記のようにリストされていました。しかしながら、clients*.google.com の文字列中にワイルド カード (*)があるため、そのままでは Walled garden ranges に登録できません。
*.client-channel.google.com accounts.google.com apis.google.com clients*.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
確実的に許可するのであれば、下記のように clients*.google.com を *.google.com に読み替えるのが良いと思われます。
*.client-channel.google.com accounts.google.com apis.google.com *.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
筆者は clients*.google.com の通信先を展開 (clients1, clients2, clients3, clients4)して下記のように登録しました。
Set up a hostname allowlist / ホスト名の許可リストを設定する のドキュメントなどを参考にして筆者が独自にカスタマイズしたので問題が出る可能性は残ります。
*.client-channel.google.com accounts.google.com apis.google.com clients1.google.com clients2.google.com clients3.google.com clients4.google.com contacts.google.com *.googleusercontent.com mail.google.com ssl.gstatic.com www.google.com www.gstatic.com ogs.google.com play.google.com
公式情報の通りに登録すると www.google.com のGoogle検索のドメインが登録されます。
Google検索した後のリンク先への通信は弾かれるので大した問題にはならないとは思いますが、通信要件を厳格に絞りたい要望が想定されるので、アクセス先を更に絞るパターンも実験的に検証してました。
あくまでも参考情報であり、この設定を推奨してるわけではありません。
また、GoogleのOAuthの認証処理で通信が発生するドメインを実機動作から調べています。 ソース コードのレベルでの解析は行っておりません。
アクセス先を更に絞る場合は下記のドメインをまず登録します。
accounts.google.com www.gstatic.com ssl.gstatic.com
そして下記のリージョン別のドメインも登録する必要がありました。アクセス先の国などによって登録対象が変わる可能性があります。
accounts.google.co.jp
そもそもアクセス先を厳格に管理したいのであれば、Guest Wi-Fi向けによく使われるSplash page (Captive Portal)を厳格な通信制御が求まれる企業LANなどの環境に採用して、更に追加でセキュリティ要件を無理やりにでも実現させようとするのは、機能の用途に反する好ましくない設計だと筆者は考えております。
Controller disconnection behavior の設定は、Meraki MRがMeraki Cloud Controllerに接続できない状態の挙動を設定します。認証済みデバイスのみが接続できるように Restricted に設定します。
Meraki Dashboardの i アイコンをマウスオーバーした際に表示される Controller disconnection behavior の説明は下記の通りです。
Login attempts on this SSID will be processed by the Meraki Cloud Controller. What should happen to new clients if your Internet uplink is down or the controller is otherwise unreachable?
メニュー: Wireless > Splash page から設定対象のSSIDを選択します。
Splash behavior セクションにある Splash frequency が認証セッションのタイマーになるため要件に応じて修正します。デフォルトは Every day です。
筆者は検証で認証セッションが切れやすくなるように Every half hour を指定して短くしています。
Splash pageによるOAuth認証は、無線LAN接続端末のHTTP (80/tcp)通信をトリガーにしてSplash pageに誘導します。
Windows系のOSの場合は、SSIDへの接続後に http://www.msftconnecttest.com/redirect への通信がリダイレクトされてSplash pageに誘導されるケースが想定されます。
Google Workspace側でアプリのアクセス制御をしている場合は、メニュー: セキュリティ > API の制御 > アプリのアクセス制御 (URL: https://admin.google.com/ac/owl/list?tab=apps )の情報を参照して状況を確認してください。
アプリ名: Splash でアクセス履歴が表示されます。
SSIDへの接続タイミングでは、OSやWebブラウザの動作によってCaptive Portalの検知動作が入るケースがあります。 しかし、SSID接続中に30分のような短い間隔で認証セッションのタイマーが切れると、ユーザーが再認証の必要性に気づかない可能性があり、ユーザー体験 (UX: User eXperience)に影響が出る可能性があります。
実際に筆者が検証で30分の間隔にしていた際の話となりますが、WebサイトにHTTPS (443/tcp)で通信した際に、Splash pageのHTTP (80/tcp)通信のリダイレクト処理が行われず、ロード時間が長いように見えてしまいました。
一般的な会社員であれば24時間以上の連続稼働はないと思われますので、業務時間に合わせて24時間 (1日)の間隔で設計する良いかと考えられます。
一般的な会社の従業員向けの無線LANでは、Captive Portalによる認証は挟まないケースが多いかと思われます。 そこに「運用を楽にしたい」目的や要望のために「無線LANの接続時にGoogle Workspaceの資格情報を用いる」手段を意地でも実現しようとSplash page (Captive Portal)による実装を行うと、Forward ProxyやSWG (Secure Web Gateway)の存在が設計の足かせになる可能性があります。 特に日本ではForward Proxyが多くの会社で利用されていると思います。
Captive PortalとForward ProxyやSWGは通信フローに影響を与えるので、相互に競合する可能性があります。
本記事で扱っている設定は、Splash page (Captive Portal)でGoogle WorkspaceのOAuth認証を通す必要があります。
しかし、Forward ProxyやSWGが存在しているとMeraki MRはOAuthの認証前なのでProxy Server宛の通信を通しません。
そうなると、Splash page (Captive Portal)でWalled Gardenで許可設定を行う必要があります。ただし、「Proxy除外による直接通信」と「Proxy Serverを介す通信」の設計依存となる2パターンの考慮が発生します。
「Proxy Serverを介す通信」では、Walled GardenにProxy ServerのIPアドレスを設定するため、宛先対象がOAuth認証の通信であるか否かに関わらず通信が許可されてしまいます。そのため、Proxy Serverの設計へ依存性が出てきます。
「Proxy Serverを介せばどこにでも接続できる」状態を避けようとすると、Proxy Serverでの認証制御も必要になってくるため、当初の「無線LANの接続時にGoogle Workspaceの資格情報を用いたい」から別の問題に派生していきます。
「Proxy除外による直接通信」に関してはPACファイルでの制御が想定されます。Forward ProxyやSWGを介さない通信となり、Firewallは直接宛先 (例: *.client-channel.google.com)の通信制御をしなければならないため、FQDNやワイルドカードの制御に対応した製品選定や設計が必要になるかもしれません。
このようにして通信フローを踏まえながら様々な要素を考慮する必要が出てくるので、無理やりにでも実装しようと躍起になると、本来の目的を忘れて複雑性の高い代物が出来る上がってしまうかもしれません 。
また機能が想定している用途の側面で考えてみます。 Captive PortalをGuest Wi-Fi用途で利用するのであれば、不特定多数の端末に対する設定の考慮が難しくなるForward ProxyやSWGは利用しないケースが多くなると思います。 しかし、Captive Portalを従業員向けに提供する場合は、要求されるセキュリティ要件が異なってくるため、Forward ProxyやSWGによるアクセス制御が必須になるかもしれません。 そのため、Captive Portalの一般的なユース ケースから逸脱した状態で更に高度なセキュリティ要件が発生すると、機能の組み合わせが想定されておらず破綻しやすくなる可能性があります。
本機能の利用にあたって不安が残るようであれば、ユーザー利便性などを加味してのPoCの実施を検討してください。
MerakiをCLIから扱うためのMeraki-CLIと呼ばれるツールがあります。
Meraki Dashboard APIを利用したサード パーティーのツールで、REST APIによる操作をCLIでWrapper化したような使い勝手になります。
Meraki-CLIの利用にあたっては、Python環境の構築と、コマンド補完で利便性を高めるための python3-argcomplete パッケージの導入が必要だったので手順を整理しました。
使い方は下記のドキュメントに体系的に整理されています。
GitHubでソース コードが公開されています。
Meraki-CLIで対応しきれていない機能も出てくる可能性があります。 そのため本番環境で利用するならば、必要に応じてソース コードの改修による機能追加の検討や、未対応機能は手動対応による実施を前提に置くか等を導入前に決めた方が好ましいと思われます。
CML-P (Cisco Modeling Labs - Personal)上のUbuntu 22.04.1 LTSで実行環境を構築しました。
Meraki-CLIは Version 1.5.0 で検証を行っております。
(.venv) cisco@ubuntu-0:~/meraki-cli$ meraki --version Meraki-CLI v1.5.0 | Meraki API Library v1.36.0 | Python 3.10.12 (.venv) cisco@ubuntu-0:~/meraki-cli$
python3-argcomplete パッケージのインストールは任意です。
筆者が触った限りではMeraki-CLIのコマンド補完時に処理がモッサリするため、何度も何度も補完に頼るような使い方だとストレスが溜まるように感じました。
それもあって筆者の場合は、何度も使うようなコマンドは書き留めるようにして、補完の利用を最小限になるようにしています。
apt コマンドの利用時に needrestart によって対話形式のメッセージが表示される場合があります。検証用途でのコマンドの流し込みに向かないため、非対話になるように事前設定を行います。
apt コマンドの利用時に needrestart によって、必要なサービスは自動的 (automatically)に再起動されるようにします。
sudo sh -c "cat << 'EOF' > /etc/needrestart/conf.d/99_restart.conf
# Restart mode: (l)ist only, (i)nteractive or (a)utomatically.
#
# ATTENTION: If needrestart is configured to run in interactive mode but is run
# non-interactive (i.e. unattended-upgrades) it will fallback to list only mode.
#
\$nrconf{restart} = 'a';
EOF"
cat /etc/needrestart/conf.d/99_restart.conf
sudo apt -y update sudo apt -y install python3-argcomplete
python3-argcomplete をアクティベートします。/etc/bash_completion.d/python-argcomplete.sh にスクリプトがインストールされます。sudo activate-global-python-argcomplete3
~/.bash_profile に補完設定を読み込みためのコマンドを書き込みます。(リダイレクトによる追記のため、コマンドを何度も実行しないように注意してください。)echo 'eval "$(register-python-argcomplete3 meraki)"' >> ~/.bash_profile cat ~/.bash_profile eval "$(register-python-argcomplete3 meraki)"
pwd mkdir ./meraki-cli/ cd ./meraki-cli/ pwd
sudo apt -y install python3-venv python3 -m venv .venv source .venv/bin/activate pip install --upgrade pip
pip3 install meraki-cli
YOUR_API_KEY の部分は自身のAPI Keyに書き換えてください。bash_history)に残らないように、行頭にスペースを入れています。echo $HISTCONTROL が ignorespace もしくは ignoreboth になっている想定の使い方です。export MERAKI_DASHBOARD_API_KEY='YOUR_API_KEY'
meraki organizations getOrganizations
(.venv) cisco@ubuntu-0:~/meraki-cli$ meraki organizations getOrganizations ┏━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ id ┃ name ┃ url ┃ ┡━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩ │ 1234567890******** │ Org_Test │ https://n480.meraki.com/o/********/manage/o… │ └────────────────────┴──────────┴──────────────────────────────────────────────┘ (.venv) cisco@ubuntu-0:~/meraki-cli$
Terraformの実行環境をAzure Cloud Shellでbashを用いて準備する手順をまとめました。 できるだけコマンドをそのまま流し込めばセットアップが完了するように調整しております。
TerraformからAzureへのService Principalを介した接続は証明書による認証としています。
Azure Cloud Shellは検証用途で利用していて定期的に環境を破棄する想定とし、消し忘れたService Principalの不正利用を防ぐために証明書の有効期限を90日としています。
検証時に権限周りの制約に悩まされないようにService Principalに割り当てるRoleは Contributor にしています。しかしながら権限の強さに比例して悪用時のリスクが高まるので適宜調整してください。
Terraformの環境構築自体はMicrosoftのドキュメントを参考にしています。 固有情報のような書き換えが必要な個所があったので、できるだけAzure Cloud Shellからコマンドを流し込めばよい状態に調整しております。
Configure Terraform in Azure Cloud Shell with Bash | Microsoft Learn
https://learn.microsoft.com/en-us/azure/developer/terraform/get-started-cloud-shell-bash?tabs=bash
認証情報に関してはTerraformのAzure Providerのドキュメントを参考にして、証明書認証で設定しております。
Azure Provider: Authenticating via a Service Principal and a Client Certificate | Guides | hashicorp/azurerm | Terraform Registry
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_certificate.html
terraform version
v1.3.2 だったので、検証時の最新版をインストールする方針としました。sysadmin [ ~ ]$ terraform version Terraform v1.3.2 on linux_amd64 Your version of Terraform is out of date! The latest version is 1.5.5. You can update by downloading from https://www.terraform.io/downloads.html sysadmin [ ~ ]$
~/bin/ に格納しています。LATEST_URL=$(curl -sL https://releases.hashicorp.com/terraform/index.json | jq -r '.versions[].builds[].url' | grep -E 'terraform_[0-9]\.[0-9]{1,2}\.[0-9]{1,2}_linux.*amd64' | sort -V | tail -n 1)
echo ${LATEST_URL}
curl -O ${LATEST_URL}
ls ~/terraform_*_linux_amd64.zip
unzip ~/terraform_*_linux_amd64.zip
mkdir ~/bin
mv ~/terraform ~/bin/
${PATH} に ~/bin/ が通っていますが、新しい実行ファイルが優先されないケースがありました。この場合はMicrosoftのドキュメントに従ってShellを開き直します。sysadmin [ ~ ]$ echo ${PATH}
~/.local/bin:~/bin:~/.dotnet/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/istio-latest/bin:/usr/local/linkerd/bin:/usr/lib/golang/bin:/opt/mssql-tools18/bin:~/bundle/bin:~/bundle/gems/bin
sysadmin [ ~ ]$
sysadmin [ ~ ]$ which terraform
/home/sysadmin/bin/terraform
sysadmin [ ~ ]$
sysadmin [ ~ ]$ terraform version
Terraform v1.3.2
on linux_amd64
Your version of Terraform is out of date! The latest version
is 1.5.2. You can update by downloading from https://www.terraform.io/downloads.html
sysadmin [ ~ ]$
exit
terraform version
SP_NAME='sp_terraform'
SUBSCRIPTION=/subscriptions/`az account show | jq -r .id`
echo ${SUBSCRIPTION}
$$ や ~ の扱いには注意してください。CERT_PASSWORD=`openssl rand -base64 18`
echo ${CERT_PASSWORD}
openssl コマンドの -days オプションで90日としています。mkdir ~/credentials
cd ~/credentials
pwd
openssl req -subj '/CN=myclientcertificate/O=MyCompany, Inc./ST=CA/C=US' -new -newkey rsa:4096 -sha256 -days 90 -nodes -x509 -keyout ./client.key -out ./client.crt
openssl pkcs12 -export -password pass:${CERT_PASSWORD} -out ./client.pfx -inkey ./client.key -in ./client.crt
az ad sp create-for-rbac --name ${SP_NAME} --role Contributor --scopes ${SUBSCRIPTION} --cert '@./client.crt'
動作確認用にResource Groupを作成するTerraformのサンプルを実行します。
mkdir ~/Sample cd ~/Sample pwd
cat > ./variables.tf << EOF
variable "subscription_id" {
description = "Subscription ID"
type = string
sensitive = true
}
variable "tenant_id" {
description = "Tenant ID"
type = string
sensitive = true
}
variable "client_id" {
description = "Client ID"
type = string
sensitive = true
}
variable "client_certificate_password" {
description = "Client Certificate Password"
type = string
sensitive = true
}
EOF
cat ./variables.tf
cat > ./secret.tfvars << EOF
subscription_id = "`az account show | jq -r .id`"
tenant_id = "`az account show --subscription 'Pay-As-You-Go' | jq -r .tenantId`"
client_id = "`az ad sp list --display-name ${SP_NAME} | jq -r .[].appId`"
client_certificate_password = "${CERT_PASSWORD}"
EOF
cat ./secret.tfvars
cat > ./main.tf << EOF
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~>3.44.1"
}
}
}
data "local_file" "client_certificate" {
filename = pathexpand("~/credentials/client.pfx")
}
provider "azurerm" {
features {}
client_id = var.client_id
client_certificate_path = data.local_file.client_certificate.filename
client_certificate_password = var.client_certificate_password
tenant_id = var.tenant_id
subscription_id = var.subscription_id
}
resource "azurerm_resource_group" "rg-sample" {
name = "rg-sample"
location = "japaneast"
}
output "OUTPUT_TEST" {
description = "Test Message"
value = "Hello, World!"
}
EOF
cat ./main.tf
terraform init
terraform plan -var-file="./secret.tfvars"
terraform apply -var-file="./secret.tfvars"
cd ~/Sample terraform destroy -var-file="./secret.tfvars"
検証作業を終えてTerraformからAzureへのデプロイ作業も不要になったら、不正アクセスの要因にならないようにService Principalの設定を削除しておきます。
az ad sp create-for-rbac コマンドを用いてService Principalを作成した際に、Enterprise ApplicationとApp Registrationの設定が作成されているので、2つ分の設定の削除が必要になります。
CLIからの作業だけだと、Enterprise ApplicationとApp Registrationの2つの設定個所を意識しにくいので、Web UIからの作業手順も用意しました。
SP_NAME='sp_terraform'
az ad sp list --display-name ${SP_NAME}
az ad sp delete --id `az ad sp list --display-name ${SP_NAME} | jq -r .[].id`
az ad sp list --display-name ${SP_NAME}
az ad app list --display-name ${SP_NAME}
az ad app delete --id `az ad app list --display-name ${SP_NAME} | jq -r .[].id`
az ad app list --display-name ${SP_NAME}
Azure Active Directoryから Enterprise applications に移動します。
Application type == Enterprise Applications の検索フィルタを削除して、sp_terraform の設定を探して移動します。
sp_terraform の Manage セクションにある Properties を開いて、Delete ボタンから削除します。
Azure Active Directoryから App Registrations に移動します。
All applications のタブに切り替えた後に sp_terraform の設定を探して移動します。
Overview から Delete ボタンから削除します。
GCIH (GIAC Certified Incident Handler)対応のSANS SEC504 (SECURITY 504)コースを個人で受講したため、自身の振り返りと参考情報として記録を残しておきます。
トレーニングや試験の内容には守秘義務で深く触れられないため、個人で受講する方の参考になりそうな情報をメインで書き残しております。
SEC504コースはセキュリティ業界では世界的に有名なSANSのトレーニングになります。
高度な内容を体系的に学べる機会をトレーニングを通して得れる点が魅力であり、SEC504コースではセキュリティにおける攻撃と防御の両側面を学べます。 そして、GIAC試験のGCIH (GIAC Certified Incident Handler)資格に対応しています。
専門性が高くなるほど体系的に学べる機会が少なくなると常々感じていたので、貴重な機会を得るために筆者は2022年頃01月頃に受講しました。
受講費用はオプションがあるため選択によって異なってきます。
筆者はトレーニングとオプションのGIAC試験を申し込みました。 資格試験の受講費用を抑えたかったので早期申し込みのキャンペーンを活用しています。
トレーニング: 790,000円 (税込み 869,000円) ※キャンペーン価格
GIAC試験 (GICH資格の試験): 105,000円 (税込み 115,500円)
合計金額は 98万4千500円 となりました。
その他に、NetWars Continuousや英語教材もありますが、費用が掛かりすぎるので必要最低限にしておきました。 また、NetWars Continuousに関しては下記サイトの紹介が分かりやすそうでした。
なお、GIAC試験をトレーニングと同時に申し込む場合の注意点ですが、トレーニング完了処理が走ってから4ヶ月以内に試験を受験する必要が出てきます。
GIAC試験には2回分のPractice Test (模擬試験)の受講権利もついてくるため、試験の出題傾向を知るのに適しております。 GCIHの試験に関しては重箱の隅をつつくような問題は特に見当たらなかったのでPractice Testで十分に試験対策ができると感じました。
筆者は昔からSANSのトレーニングに興味があったのですが、お金がないことには受講できないので、検証用のネットワーク機器を買い漁りたくなる衝動を抑えて貯金試験から挑んでいました。
また受講資金の用意だけでなく、トレーニングの受講のために1週間もの有給休暇の取得が必要になるため早い段階から上長に相談して仕事の調整をしておりました。
会社による指示でのトレーニング受講であれば業務時間としての調整になると思いますが、私は個人として受講したので有給休暇による調整でした。
もし既婚者の方が個人受講するとなると、家族会議で稟議を通す必要もあるかと思います。(業務にいくら活きるとしても大金の出費となるので、家計を圧迫するとしてご家族から平手打ちを喰らって張り倒されるかもしれませんが...。)
筆者の受講時はオンラインでの開催になりました。 Zoomで講義が配信されており、ラボの進捗状況や、質問のやり取りにSlackを併用しました。 講義は録画されて期間限定でアーカイブされます。ストリーミング再生のみ可能でダウンロードはできないようになっておりました。
教材は紙のテキストと電子版テキスト (パスワード保護 & 電子透かし付きPDF)が提供されており、テキストは日本語スライドと、英語による補足から構成されていました。
月曜日から金曜日はテキスト ベースの講義とラボによるハンズオンです。 ラボに関しては仮想マシン 2台 (Linux & Windows)を手元で立ち上げての実習になります。
土曜日はCTF (Capture The Flag)が開催されチーム戦で挑みます。 1位になったチームにはその証としてSANSのコインが贈呈されるので筆者は技量試しに躍起なりました。 筆者はペネトレーション テストの実務経験がないためCTFと聞くとレベルが高いイメージでしたが、自分が思ってたよりかは問題を解けた気がします。
CTFではラボでも使っていた仮想マシン上からOpenVPNでCTF環境に繋ぎます。 仮想マシンとして論理的に分離されているとは言っても、CTFで競い合うネットワークに繋ぐため、業務用PCのような機密情報が含まれる端末での受講は避けるべきです。
GIACは専門性が高いため全体的に高度な内容を扱うコースが多いですが、その中でもSEC504コースは上位のコースへ繋がる基礎的な内容になります。 基礎的な内容と言うと簡単に思えるかもしれませんが、あくまでもGIACのコースの中で見た場合の話になります。
表現を変えると、他の資格と比べた尺度では、ある程度の事前知識が必要なレベル感になります。 仮に新卒入社の方が新人研修の一環で受けるとすると、少なくともレベルが高めに感じるはずです。
筆者の感覚では、同じ分野に属するCompTIA PenTest+やEC-Council社のCEH (Certified Ethical Hacker)と同等かそれ以上になると感じました。 (例に挙げた2つの資格は、当時の時点で筆者は取得済みです。)
ラボではLinuxのCommand Lineを普通に叩くので、LPICもしくはLinuCのLevel 1～2くらいの知識はあった方がいいと思います。
筆者は割り引きを目当てにGIAC試験をトレーニングと一緒に同時に申し込んだので、4ヶ月以内に試験の受験が必要になりました。 しかしながら、仕事のキャッチアップの都合などもあり、試験直前のPractice Test以外はほとんど準備していない状況で受験しました。
資料の持ち込みが可能なので、筆者は公式テキストをリュックに背負って持ち込みました。 公式テキストだけでもそれなりの重さになるので、試験会場まで長距離移動になる方は体への負担に留意してください。
試験中に持ち込み資料を参照できると言っても、そもそも予め公式テキストを読み込んでおかないと何処に何が書いてあるか分からない状態なので、筆者の場合は持ち込んだ意味をあまり成さなかったです。 GIAC試験では公式テキストから効率的に目当ての内容を見つけるためのインデックスの作成が重要になってくるのは知っておりましたが、それを実際に思い知らされる形になりました。
試験自体は1回目で合格ラインは突破しましたが、後に再テストを要求されましたので2回目の受験が必要になりました。 筆者はCompTIA PenTest+とCEHを長らく勉強していた時期があったので、合格ラインの突破は基礎知識が活きたのが一因にあったと自己分析しております。
まず話の前提として、世間には流出した試験問題集を売っている不正な業者が居ます。
出回っている試験問題の内容や流出時期などの情報と、正答した問題の傾向などが機械的に分析されてチェックに引っかかったようで、受験から1～2ヵ月後に筆者は再テスト (Retest)対象者に選ばれた旨がメールで通知されました。 機械的に分析しているようなので、受験者の誰しもが再テストの対象者に選ばれる可能性があるようです。
資格試験の品質を保つ上でやむを得ない仕組みであるので、再テストが発生してしまったことには筆者は納得しております。 しかしながら、合格したと思っていた状態で再テストが発生するのはとても厄介です。
例えば、筆者の所属会社ではGCIHの資格を保持していると資格手当として毎月 3万円ほど支給されたり、資格取得補助金として受験費用や資格評価に応じた報奨金が支給されます。 所属会社に資格合格の申請を丁度行っていたタイミングでの再テストの通知が来たので、事情説明 (申請の保留)のやり取りの手間が増える結果となりました。 説明の仕方によっては「疑わしきは罰せよ」で試験で不正をするような人だと思われかねないのと、意図しない資格手当の不正受給に繋がる可能性があったので冷や汗をかきました。 それもあって当時は「許すまじ不正業者」と憤ったものです。
再テスト自体は無料となり、2回分のPractice Testも合わせて追加されました。 テキストを読み込みなおす時間もなかったので、Practice Testで傾向対策を万全にして挑んで合格できました。
結果的にPractice Testを計4回 (初回申し込み分の2回 + 再テスト分の2回)ほど受けれたので、試験問題の傾向対策が十分にできたと本当に実感しております。
再テストによって試験対策をやり直さざるを得なくなったので、Practice Testメインに偏ってはいましたが、他のGIACの資格に今後挑む上での収穫になったと考えております。
SEC504のトレーニングを受けてからのGCIH資格の試験受験までの一連の流れで、資格試験の合格に必要な要素はカバーされていると感じました。
例えば、他の資格だとサードパーティから発売されている問題集による出題内容の傾向対策が有用になるケースがあると思います。 具体的には、筆者がEC-Council社のCND (Certified Network Defender)のトレーニングと資格試験を受けた際だと、資格試験がリリースされてから年月の経過が少ないのと、マイナーすぎて米国のamazon.comでもサードパーティーの問題集が見当たらなかったため、CNDの上位資格であるCEHの方が問題集があって傾向対策がしやすい状況になっておりました。 それと対比すると、SANSのトレーニングでは重箱の隅をつつくような問題は特に見当たらなかったので、Practice Testで必要な傾向対策はできたと感じております。
トレーニングによって体系的に効率的に学んだうえで、その内容を理解した証跡が資格試験の合格となると、お金はかかりますがとても合理的なカリキュラムになっていると感じます。
トレーニングと資格受験のタイミングから時間が経ちましたが、当時の状況をまとめていたので振り返りのために書き記しました。
本記事の執筆時点 (2023年08月頃)では、GSX社がEC-Council系の上位資格の国内トレーニングを扱い始めたので、専門性が高い内容を体系的に学べる方法が増えております。
Azure版のCatalyst 9800-CLにおいてSerial Console接続を有効化するには Boot diagnostics の設定を有効化する必要があります。
Boot diagnostics が有効化されていると、Virtual Machineの設定メニューから Help セクションにある Serial Console より接続ができます。
検証時はCatalyst 9800-CLの Version 17.7.1 で、2023年08月頃に検証を行っております。
Serial Console接続時には、下記のようなAAA関連の設定が入っているため、UsernameとPasswordの組み合わせによる認証がかかります。
aaa new-model aaa authentication login default local
そのため、Passwordによる認証でログイン可能なUserをデプロイ時もしくはデプロイ後に作成しておいてください。
Azure版のログイン方法はいくつか種類があるため、下記を参考にしてください。
筆者の場合は下記のコマンド例のようなUserをCustom Dataの設定領域にデプロイ時に書き込んで検証を行っておりました。
username admin privilege 15 password 0 TODO_CHANGE_PASSWORD
privilege 15 を指定すると特権モード (# プロンプト)に直接入れますが、必要に応じて権限レベルを調整して enable secret の設定も忘れないようにしてください。
Catalyst 9800-CL (Virtual Machine版)のデプロイ画面では、Monitoring タブの Diagnostics セクションより Boot diagnostics にて
Enable with managed storage account (recommended)
もしくは
Enable with custom storage account
のいずれかを選択してStorage Accountを有効化します。
Catalyst 9800-CLをVirtual Machineとしてデプロイした後でも設定変更は可能です。
対象Virtual Machineの設定メニューから Help セクションにある Boot diagnostics に移動して Settings を押下します。
Boot diagnostics の設定画面にて
Enable with managed storage account (recommended)
もしくは
Enable with custom storage account
のいずれかを選択してStorage Accountを有効化します。
AzureのVirtual MachineにSerial Console接続するには Boot diagnostics の有効化が必要になるので、Catalyst 9800固有の設定と言うわけではありません。
Azure Serial Console - Virtual Machines | Microsoft Learn
https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/serial-console-overview
Boot diagnostics must be enabled for the VM
Catalyst 9800のドキュメントにAzureでSerial Console接続を有効化する方法の記載があります。
Cisco Catalyst 9800 Wireless Controller for Cloud on Microsoft Azure Deployment Guide - Cisco
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-7/deployment-guide/Azure_Deployment_Guide.html
Diagnostics Storage account is recommended, it is for connecting and screening the serial console.
Cisco Catalyst 9800-CL Cloud Wireless Controller Installation Guide - Installing the Controller in Microsoft Azure Cloud Service [Cisco Catalyst 9800 Series Wireless Controllers] - Cisco
https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/9800-cloud/installation/b-c9800-cl-install-guide/m_install_using_azure.html
Step 16
To make the Serial console accessible, navigate to Boot diagnostics in Support + troubleshooting.Step 17
Choose the Enable with custom storage account settting.Step 18
Choose an existing storage account or create a new one.
You can now navigate to the Day 0 configuration using either serial console, SSH to the controller, or Web UI.
startup-config を削除しても、SSH鍵の設定やCustom Dataが startup-config として保存されて起動してくるようなので、Serial Console接続ができても初期化状態にはできないようでした。
Public CloudのVirtual Machineへの管理接続はIP Reachabilityがあるのを前提にしているケースが多いと思います。 Serial Console接続できるのをいいことに、IP Reachabilityを失うような作業をして、開発者が想定していないような状態にするのは避けた方が無難です。
Azureと異なり、AWSではSerial Consoleのサポート状況が変わりますので、下記の記事を参照してください。
