Fortinet社がSSL-VPN利用の延命を決定してくれた。
本当によかったです。これ結構インパクトあるからな。
まーセキュリティ的にはSSL-VPNはやめてIP-SEC VPNやゼロトラスト
なんかに移行しないといけないのはわかっているけどお金も時間も
かかるからな。
期限：バージョン7.4 2026/5/11 → 2027/5/11
フォーティネットがSSL-VPNの「廃止」期限を1年延長、5月の終了目前に
日経 X TECH参照
--------------------------------------------------------------------------
米Fortinet(フォーティネット)はセキュリティー製品用OS「FortiOS」
のうち、SSL-VPN(Virtual Private Network)を利用できるバージョン7.4
などの技術サポートの終了(EoES：End of Engineering Support)を1年
延長することを明らかにした。バージョン7.4はこれまで2026年5月11日
までとしていたのを、2027年5月11日に改めた。
ユーザー向けコミュニティーサイトで2026年3月27日(米国時間)に
公表した。日本法人のフォーティネットジャパンも同日、
国内の販売代理店に延長する旨を通知した。
フォーティネットは脆弱性が近年頻発していることなどを背景に、
SSL-VPNの廃止方針を打ち出している。正確には、FortiOS 7.6.3以降では
SSL-VPNのトンネルモードを廃止し、Webブラウザーを使うモードは
「Agentless VPN」に名称を変更してサポートを継続する。ユーザーには
EoESまでに、IPsec(Security Architecture for Internet Protocol)方式のVPNや
ZTNA(Zero Trust Network Access)など別の手段へ移行することを推奨していた。
EoESを迎えると、フォーティネットが重要と判断したケースを除き、
脆弱性や不具合が見つかっても修正プログラム(パッチ)が提供されなくなる。
重要な脆弱性に対する修正プログラムは、問い合わせ対応などもやめる
サポート終了(EoS：End of Support)まで引き続き提供される。
とはいえ、セキュリティー被害のリスクが高まるという懸念があった。
--------------------------------------------------------------------------
皆さん計画的に移行を実施していきましょう！！
スポンサードリンク
Fortigate ldap 認証 失敗
Fortigate ldap 認証 失敗
FortiClientを利用し、証明書認証とLDAPによる
ユーザー認証を組み合わせた二要素認証方式にて
IPsec VPN接続を構成しているのだがうまくVPNが張れない。
だから心も晴れない。
まず事前情報としてわかっていた設定をFortiClient側で実施。
最終的にこの設定は必須ということがわかりました。
■FortiClient設定変更
How to enable EAP-TTLS for IPSec IKEv2 tunnels in
VPN-only (unlicensed) FortiClient
[FortiClient設定変更手順]
1.FortiClientの設定ファイル（configファイル）をバックアップする
2.configファイルを編集し、＜ike_settings＞ 配下に ＜eap_method＞2＜/eap_method＞ を追加する
3.編集後のconfigファイルをリストア（復元）する
この設定は、リストア後は＜authentication_method＞2＜/authentication_method＞に
自動変換され＜eap_method＞2＜/eap_method＞の行はなくなる。
※＜＞は半角に直してください
そしてFortigate側のCLIでdebugしながらFortiClientで接続してみることに。
■デバッグ
[デバッグコマンド]
# diagnose debug reset →デバッグの条件リセット
# diagnose debug application ike -1 →IKE/IPsec VPNなどの情報
# diagnose debug application fnbamd -1 →LDAPサーバへの接続情報
# diagnose debug enable →デバッグ開始
デバッグは機器への負荷が高くなるので必ず止めましょう。
[デバッグ終了コマンド]
# diagnose debug reset
# diagnose debug disable
以下取得したログ
------------------------------------------------------
TEST-FW001# diagnose debug reset
TEST-FW001# diagnose debug application fnbamd -1
Debug messages will be on for 30 minutes.
TEST-FW001# diagnose debug enable
TEST-FW001# [1] handle_req-Rcvd auth_cert req id=7777777, len=2380, opt=8
[2] __cert_auth_ctx_init-req_id=7777777, opt=8
[3] __cert_auth_ctx_init-OCSP resp is found.
[4] __cert_chg_st- 'Init'
[5] fnbamd_cert_load_certs_from_req-3 cert(s) in req.
[6] __cert_init-req_id=7777777
[7] __cert_build_chain-req_id=7777777
[8] fnbamd_chain_build-Chain discovery, opt 0x19, cur total 1
[9] fnbamd_chain_build-Following depth 0
[10] fnbamd_chain_build-Extend chain by builtin CA cache. (good)
[11] fnbamd_chain_build-Following depth 1
[12] fnbamd_chain_build-Extend chain by builtin CA cache. (good)
[13] fnbamd_chain_build-Following depth 2
[14] fnbamd_chain_build-Self-sign detected.
[15] __cert_chg_st- 'Init' -> 'Validation'
[16] __cert_verify-req_id=7777777
[17] __cert_verify-Chain is complete.
[18] fnbamd_builtin_cert_check-Following cert chain depth 0
[19] fnbamd_builtin_cert_check-Following cert chain depth 1
[20] fnbamd_builtin_cert_check-Builtin CRL found: 24b5494
[21] fnbamd_builtin_cert_check-Following cert chain depth 2
[22] fnbamd_builtin_cert_check-Certificate status is unchecked.
[23] __cert_verify_do_next-req_id=7777777
[24] __cert_chg_st- 'Validation' -> 'OCSP-Checking'
[25] __cert_ocsp_check-req_id=7777777
[26] fnbamd_verify_ocsp_response-Cert status: GOOD.
[27] __cert_ocsp_resp_verify-verify_ocsp_response returns 0 -1
[28] __cert_chg_st- 'OCSP-Checking' -> 'Done'
[29] __cert_done-req_id=7777777
[30] fnbamd_auth_session_done-Session done, id=7777777
[31] __fnbamd_cert_auth_run-Exit, req_id=7777777
[32] create_auth_cert_session-fnbamd_cert_auth_init returns 0, id=7777777
[33] auth_cert_success-id=7777777
[34] fnbamd_cert_auth_copy_cert_status-req_id=7777777
[35] fnbamd_cert_auth_copy_cert_status-Cert st 210, req_id=7777777
[36] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 7777777, len=1592
[37] destroy_auth_cert_session-id=7777777
[38] fnbamd_cert_auth_uninit-req_id=7777777
[39] fnbamd_ldaps_destroy-
[40] fnbamd_rads_destroy-
------------------------------------------------------
証明書の認証はうまくいってそうだがldapで失敗していそうである。
ldapsは[39]行目だけでそれ以外のログが見当たらない。
認証にすら確認していないのかもしれない。
ちなみにdestroy自体は破壊や失敗という意味ではなくセッションや
接続の終了という意味です。
[39] fnbamd_ldaps_destroy-
ldap(AD)サーバとしてはPCのドメイン参加やユーザーのログインは
正常に行えることは確認している。そこで今度はFortigateから
ldap接続の確認を行うことにした。
■FortigateGUI操作
ユーザ＆認証＞LDAPサーバ＞[設定しているADサーバ]選択＞LDAPサーバの編集画面
各項目を設定した上でバインドタイプ レギュラー
ユーザー名/パスワードを入力して＞接続をテスト
接続ステータス →成功
ユーザクレデンシャルテスト＞ユーザクレデンシャルをテストの編集画面
ユーザ名/パスワードを入力して＞テスト
接続ステータス →成功
ユーザクレデンシャル →成功
あれ！？全部成功する。
■FortigateCLI操作
# diagnose test authserver ldap [ADサーバ名] [認証するユーザー名] [パスワード]
authenticate '認証するユーザー名' against 'ADサーバ名' failed!
あれっ！？CLIでやったら認証失敗する。
どうやらGUIとCLIで動作が違うようである。
ということでこれはパケットキャプチャですね。
Fortigate本体でもdiagnose sniffer packet等によるパケットキャプチャは
取得可能ですが、NP(Network Processor)などのASICでオフロードされている
トラフィックについては、CPUを経由しないためキャプチャ対象外となります。
今回は対象トラフィックを確実に取得するため、スイッチ側でSPAN(ミラーポート)を
設定し、該当インターフェースのトラフィックをミラーリングしてWiresharkで
パケットキャプチャを実施します。
■WireShark調査結果
ADサーバのIPアドレス：10.1.1.101
[GUIからLDAP]
認証が成功するパターンですね。
こちらは想定しているポートから通信がちゃんとでていました。
10.1.1.1 → 10.1.1.101 Protocol 389(LDAP)
[CLIからLDAP]
認証が失敗するパターン。
なんということでしょうこちらは想定しているポートから通信が出ていません。
192.168.1.1 → 10.1.1.101 Protocol 389(LDAP)
192.168.1.0セグメントはmgmtセグメントでルーティングなども
していません。こりゃ通信はできないわけですね。
ルーティングテーブルを確認すると以下のようになっています。
# get router info routing-table all
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 8.8.10.10, port1, [1/0]
C 10.1.1.0/24 is directly connected, port6
C 192.168.1.0/24 is directly connected, port24
サーバセグメントはport1、マネジメントポートはport24でそれぞれ
directly connectedですがなぜかLDAP認証はマネジメントから通信
しようとしているようです。
■管理通信を管理インタフェース利用設定
今回はHAを組む際にset ha-direct enableを設定をしていたため
管理通信が管理インタフェースから出ていました。
[ha-direct設定]
# show system ha
config system ha
set ha-mgmt-status enable →管理用インタフェースを登録
config ha-mgmt-interfaces
edit 1
set interface "mgmt"
set gateway 192.168.1.1
next
end
set ha-direct enable →管理通信を管理インタフェース利用設定
end
■ha-directとは
ha-directとは、HA構成において特定の通信を専用の
管理インターフェース（mgmt interface）経由で行う機能となる。
通常、FortiGateのHA構成では装置自身が発生させる
通信(LDAP、DNS、Syslog、FortiGuardなど)は、データプレーン側の
インターフェースを経由して送信されます。しかし、ha-directを有効化
することで、以下のような通信をHAの管理インターフェースから
直接送信することが可能となる。
1.認証関連通信（LDAP / RADIUS など）
2.DNS問い合わせ
3.FortiGuardアクセス
4.Syslog送信
5.SNMP通信
6.その他、FortiGate自身が発生させる管理プレーン通信
以下参照サイト
*FORTINET製品サポートサイト
HA構成時に管理用インタフェースからSyslog, SNMP Trapを送信できますか
*Knowledge Stare
FortiGateの冗長化構成(HA構成)におけるha-direct設定について
■接続試験
ha-directを削除してしまうと影響範囲がわからないので
一旦はLDAP認証する際のIPアドレスを指定することにした。
[LDAP設定]
# show user ldap
config user ldap
edit "ADSERVERNAME"
set server "10.1.1.101"
set source-ip "10.1.1.1" →ldap認証を行うソースIPアドレスを指定
set cnid "sAMAccountName"
set dn "DC=test,DC=co,DC=jp"
set type regular
set username "fortiadmin@test.co.jp"
set password ENC password
このあとFortiClientから接続試験を行ったところ
正常にIP-SEC通信ができました。
続きを読む
TOP OF THE NETWORK×NETWORKFortiClientを利用し、証明書認証とLDAPによる
ユーザー認証を組み合わせた二要素認証方式にて
IPsec VPN接続を構成しているのだがうまくVPNが張れない。
だから心も晴れない。
まず事前情報としてわかっていた設定をFortiClient側で実施。
最終的にこの設定は必須ということがわかりました。
■FortiClient設定変更
How to enable EAP-TTLS for IPSec IKEv2 tunnels in
VPN-only (unlicensed) FortiClient
[FortiClient設定変更手順]
1.FortiClientの設定ファイル（configファイル）をバックアップする
2.configファイルを編集し、＜ike_settings＞ 配下に ＜eap_method＞2＜/eap_method＞ を追加する
3.編集後のconfigファイルをリストア（復元）する
この設定は、リストア後は＜authentication_method＞2＜/authentication_method＞に
自動変換され＜eap_method＞2＜/eap_method＞の行はなくなる。
※＜＞は半角に直してください
そしてFortigate側のCLIでdebugしながらFortiClientで接続してみることに。
■デバッグ
[デバッグコマンド]
# diagnose debug reset →デバッグの条件リセット
# diagnose debug application ike -1 →IKE/IPsec VPNなどの情報
# diagnose debug application fnbamd -1 →LDAPサーバへの接続情報
# diagnose debug enable →デバッグ開始
デバッグは機器への負荷が高くなるので必ず止めましょう。
[デバッグ終了コマンド]
# diagnose debug reset
# diagnose debug disable
以下取得したログ
------------------------------------------------------
TEST-FW001# diagnose debug reset
TEST-FW001# diagnose debug application fnbamd -1
Debug messages will be on for 30 minutes.
TEST-FW001# diagnose debug enable
TEST-FW001# [1] handle_req-Rcvd auth_cert req id=7777777, len=2380, opt=8
[2] __cert_auth_ctx_init-req_id=7777777, opt=8
[3] __cert_auth_ctx_init-OCSP resp is found.
[4] __cert_chg_st- 'Init'
[5] fnbamd_cert_load_certs_from_req-3 cert(s) in req.
[6] __cert_init-req_id=7777777
[7] __cert_build_chain-req_id=7777777
[8] fnbamd_chain_build-Chain discovery, opt 0x19, cur total 1
[9] fnbamd_chain_build-Following depth 0
[10] fnbamd_chain_build-Extend chain by builtin CA cache. (good)
[11] fnbamd_chain_build-Following depth 1
[12] fnbamd_chain_build-Extend chain by builtin CA cache. (good)
[13] fnbamd_chain_build-Following depth 2
[14] fnbamd_chain_build-Self-sign detected.
[15] __cert_chg_st- 'Init' -> 'Validation'
[16] __cert_verify-req_id=7777777
[17] __cert_verify-Chain is complete.
[18] fnbamd_builtin_cert_check-Following cert chain depth 0
[19] fnbamd_builtin_cert_check-Following cert chain depth 1
[20] fnbamd_builtin_cert_check-Builtin CRL found: 24b5494
[21] fnbamd_builtin_cert_check-Following cert chain depth 2
[22] fnbamd_builtin_cert_check-Certificate status is unchecked.
[23] __cert_verify_do_next-req_id=7777777
[24] __cert_chg_st- 'Validation' -> 'OCSP-Checking'
[25] __cert_ocsp_check-req_id=7777777
[26] fnbamd_verify_ocsp_response-Cert status: GOOD.
[27] __cert_ocsp_resp_verify-verify_ocsp_response returns 0 -1
[28] __cert_chg_st- 'OCSP-Checking' -> 'Done'
[29] __cert_done-req_id=7777777
[30] fnbamd_auth_session_done-Session done, id=7777777
[31] __fnbamd_cert_auth_run-Exit, req_id=7777777
[32] create_auth_cert_session-fnbamd_cert_auth_init returns 0, id=7777777
[33] auth_cert_success-id=7777777
[34] fnbamd_cert_auth_copy_cert_status-req_id=7777777
[35] fnbamd_cert_auth_copy_cert_status-Cert st 210, req_id=7777777
[36] fnbamd_comm_send_result-Sending result 0 (nid 0) for req 7777777, len=1592
[37] destroy_auth_cert_session-id=7777777
[38] fnbamd_cert_auth_uninit-req_id=7777777
[39] fnbamd_ldaps_destroy-
[40] fnbamd_rads_destroy-
------------------------------------------------------
証明書の認証はうまくいってそうだがldapで失敗していそうである。
ldapsは[39]行目だけでそれ以外のログが見当たらない。
認証にすら確認していないのかもしれない。
ちなみにdestroy自体は破壊や失敗という意味ではなくセッションや
接続の終了という意味です。
[39] fnbamd_ldaps_destroy-
ldap(AD)サーバとしてはPCのドメイン参加やユーザーのログインは
正常に行えることは確認している。そこで今度はFortigateから
ldap接続の確認を行うことにした。
■FortigateGUI操作
ユーザ＆認証＞LDAPサーバ＞[設定しているADサーバ]選択＞LDAPサーバの編集画面
各項目を設定した上でバインドタイプ レギュラー
ユーザー名/パスワードを入力して＞接続をテスト
接続ステータス →成功
ユーザクレデンシャルテスト＞ユーザクレデンシャルをテストの編集画面
ユーザ名/パスワードを入力して＞テスト
接続ステータス →成功
ユーザクレデンシャル →成功
あれ！？全部成功する。
■FortigateCLI操作
# diagnose test authserver ldap [ADサーバ名] [認証するユーザー名] [パスワード]
authenticate '認証するユーザー名' against 'ADサーバ名' failed!
あれっ！？CLIでやったら認証失敗する。
どうやらGUIとCLIで動作が違うようである。
ということでこれはパケットキャプチャですね。
Fortigate本体でもdiagnose sniffer packet等によるパケットキャプチャは
取得可能ですが、NP(Network Processor)などのASICでオフロードされている
トラフィックについては、CPUを経由しないためキャプチャ対象外となります。
今回は対象トラフィックを確実に取得するため、スイッチ側でSPAN(ミラーポート)を
設定し、該当インターフェースのトラフィックをミラーリングしてWiresharkで
パケットキャプチャを実施します。
■WireShark調査結果
ADサーバのIPアドレス：10.1.1.101
[GUIからLDAP]
認証が成功するパターンですね。
こちらは想定しているポートから通信がちゃんとでていました。
10.1.1.1 → 10.1.1.101 Protocol 389(LDAP)
[CLIからLDAP]
認証が失敗するパターン。
なんということでしょうこちらは想定しているポートから通信が出ていません。
192.168.1.1 → 10.1.1.101 Protocol 389(LDAP)
192.168.1.0セグメントはmgmtセグメントでルーティングなども
していません。こりゃ通信はできないわけですね。
ルーティングテーブルを確認すると以下のようになっています。
# get router info routing-table all
Routing table for VRF=0
S* 0.0.0.0/0 [10/0] via 8.8.10.10, port1, [1/0]
C 10.1.1.0/24 is directly connected, port6
C 192.168.1.0/24 is directly connected, port24
サーバセグメントはport1、マネジメントポートはport24でそれぞれ
directly connectedですがなぜかLDAP認証はマネジメントから通信
しようとしているようです。
■管理通信を管理インタフェース利用設定
今回はHAを組む際にset ha-direct enableを設定をしていたため
管理通信が管理インタフェースから出ていました。
[ha-direct設定]
# show system ha
config system ha
set ha-mgmt-status enable →管理用インタフェースを登録
config ha-mgmt-interfaces
edit 1
set interface "mgmt"
set gateway 192.168.1.1
next
end
set ha-direct enable →管理通信を管理インタフェース利用設定
end
■ha-directとは
ha-directとは、HA構成において特定の通信を専用の
管理インターフェース（mgmt interface）経由で行う機能となる。
通常、FortiGateのHA構成では装置自身が発生させる
通信(LDAP、DNS、Syslog、FortiGuardなど)は、データプレーン側の
インターフェースを経由して送信されます。しかし、ha-directを有効化
することで、以下のような通信をHAの管理インターフェースから
直接送信することが可能となる。
1.認証関連通信（LDAP / RADIUS など）
2.DNS問い合わせ
3.FortiGuardアクセス
4.Syslog送信
5.SNMP通信
6.その他、FortiGate自身が発生させる管理プレーン通信
以下参照サイト
*FORTINET製品サポートサイト
HA構成時に管理用インタフェースからSyslog, SNMP Trapを送信できますか
*Knowledge Stare
FortiGateの冗長化構成(HA構成)におけるha-direct設定について
■接続試験
ha-directを削除してしまうと影響範囲がわからないので
一旦はLDAP認証する際のIPアドレスを指定することにした。
[LDAP設定]
# show user ldap
config user ldap
edit "ADSERVERNAME"
set server "10.1.1.101"
set source-ip "10.1.1.1" →ldap認証を行うソースIPアドレスを指定
set cnid "sAMAccountName"
set dn "DC=test,DC=co,DC=jp"
set type regular
set username "fortiadmin@test.co.jp"
set password ENC password
このあとFortiClientから接続試験を行ったところ
正常にIP-SEC通信ができました。
続きを読む
NETWORK×NETWORK
V字モデル ウォーターフォール インフラ構築にも当てはまるのか？
よくウォーターフォール開発で各フェーズに対応する
テスト工程をV字モデルで表している図をみかけます。
これはインフラ構築にもあてはまるのでしょうか？
あてはまるというよりもV字モデル・ウォーター
フォールは主流だと言えます。なぜならば、インフラ
プロジェクトは要件（必要なサーバ台数、ネットワーク帯域、
セキュリティ方針など）が事前に明確になりやすく、
稼働後の変更が難しいため、V字モデルが最も
適している手法の一つと言えます。(クラウドは変更が
容易なため当てはまらないかもしれませんが・・・)
ではインフラ構築において各フェーズごとに何を
行えばいいか確認していきます。
＜提案フェーズ＞
◆顧客の課題を解決するための方針・構成・概算費用を
提示する工程
・現状課題の整理、解決方法の提示、
全体のシステム構成案、導入スケジュール、概算費用など
◆成果物例
・提案書、構成イメージ図、概算見積もりなど
・案件受注
＜要件定義フェーズ＞
◆システムに求められる機能・性能・制約を明確にする工程
・機能要件整理(システム構成/ソフトウェア/通信要件など)
・非機能要件整理(可用性/性能・拡張性/移行性/
セキュリティ/運用・保守など)
◆成果物例
・要件定義書、要件一覧、業務フローなど
＜基本設計フェーズ＞
◆要件を満たすシステムの全体構造を設計する工程
・要件定義で確定した内容を基に設計を行う
・システム構成、ネットワーク構成、主要機能設計、
インターフェース設計、OS設計、環境設計など
◆成果物例
・基本設計書、システム構成図、ネットワーク構成図など
・導入製品の決定(提案段階で確定してもらうのが理想だが
要件定義や基本設計後に確定する場合が多い)
＜詳細設計フェーズ＞
◆基本設計をもとに、実装レベルまで具体化する工程
・基本設計で確定した内容を元にハードウェアや
ソフトウェアの設定項目や値の確定
◆成果物例
・詳細設計書(パラメーターシート)
＜単体試験フェーズ＞
◆各機器ごとの設定および動作確認する工程
・詳細設計書(パラメーターシート)通り
各機器が設定されているか試験を実施
・サーバの起動、NW機器の疎通確認などそれぞれの動作確認
◆成果物例
・単体試験仕様書、単体試験確認書など
＜結合試験フェーズ＞
◆複数の機能やシステムを連携させて動作確認する工程
・基本設計通り環境が構築できているか試験を実施
・システム間の連携が正しく動作するか確認する
◆成果物例
・結合試験仕様書、結合試験確認書
・障害試験仕様書
・接続試験仕様書
＜総合(受入)試験フェーズ＞
◆実際の運用に近い状態でシステム全体の動作を確認する試験
・システム全体が要件通り動くか確認
・本番環境で動作することを考慮した試験を実施
◆成果物例
・総合試験仕様書、総合試験確認書など
最後の総合(受入)試験についてはこのように書き方を
まとめていますが一般的には総合試験は開発ベンダーが実施して
受入試験は発注者(ユーザー)が実施するものだと思います。
インフラだと機能要件にかかわるところが多くないのでインフラ
(開発)ベンダー側と発注者で実施する試験をまとめています。
要はベンダーを信用してくださいということですね♪
TOP OF THE NETWORK×NETWORKテスト工程をV字モデルで表している図をみかけます。
これはインフラ構築にもあてはまるのでしょうか？
あてはまるというよりもV字モデル・ウォーター
フォールは主流だと言えます。なぜならば、インフラ
プロジェクトは要件（必要なサーバ台数、ネットワーク帯域、
セキュリティ方針など）が事前に明確になりやすく、
稼働後の変更が難しいため、V字モデルが最も
適している手法の一つと言えます。(クラウドは変更が
容易なため当てはまらないかもしれませんが・・・)
ではインフラ構築において各フェーズごとに何を
行えばいいか確認していきます。
＜提案フェーズ＞
◆顧客の課題を解決するための方針・構成・概算費用を
提示する工程
・現状課題の整理、解決方法の提示、
全体のシステム構成案、導入スケジュール、概算費用など
◆成果物例
・提案書、構成イメージ図、概算見積もりなど
・案件受注
＜要件定義フェーズ＞
◆システムに求められる機能・性能・制約を明確にする工程
・機能要件整理(システム構成/ソフトウェア/通信要件など)
・非機能要件整理(可用性/性能・拡張性/移行性/
セキュリティ/運用・保守など)
◆成果物例
・要件定義書、要件一覧、業務フローなど
＜基本設計フェーズ＞
◆要件を満たすシステムの全体構造を設計する工程
・要件定義で確定した内容を基に設計を行う
・システム構成、ネットワーク構成、主要機能設計、
インターフェース設計、OS設計、環境設計など
◆成果物例
・基本設計書、システム構成図、ネットワーク構成図など
・導入製品の決定(提案段階で確定してもらうのが理想だが
要件定義や基本設計後に確定する場合が多い)
＜詳細設計フェーズ＞
◆基本設計をもとに、実装レベルまで具体化する工程
・基本設計で確定した内容を元にハードウェアや
ソフトウェアの設定項目や値の確定
◆成果物例
・詳細設計書(パラメーターシート)
＜単体試験フェーズ＞
◆各機器ごとの設定および動作確認する工程
・詳細設計書(パラメーターシート)通り
各機器が設定されているか試験を実施
・サーバの起動、NW機器の疎通確認などそれぞれの動作確認
◆成果物例
・単体試験仕様書、単体試験確認書など
＜結合試験フェーズ＞
◆複数の機能やシステムを連携させて動作確認する工程
・基本設計通り環境が構築できているか試験を実施
・システム間の連携が正しく動作するか確認する
◆成果物例
・結合試験仕様書、結合試験確認書
・障害試験仕様書
・接続試験仕様書
＜総合(受入)試験フェーズ＞
◆実際の運用に近い状態でシステム全体の動作を確認する試験
・システム全体が要件通り動くか確認
・本番環境で動作することを考慮した試験を実施
◆成果物例
・総合試験仕様書、総合試験確認書など
最後の総合(受入)試験についてはこのように書き方を
まとめていますが一般的には総合試験は開発ベンダーが実施して
受入試験は発注者(ユーザー)が実施するものだと思います。
インフラだと機能要件にかかわるところが多くないのでインフラ
(開発)ベンダー側と発注者で実施する試験をまとめています。
要はベンダーを信用してくださいということですね♪
NETWORK×NETWORK
ランサムウェアとは
ランサムウェアとは
ランサムウェアはRansom（身代金）とSoftware（ソフトウェア）を
組み合わせた造語です。ソフトウェアを利用してファイルの暗号化を
行い（ファイルを閲覧不可状態）復元方法を提示する代わりに
身代金を請求する。
最近ではランサムウェアを簡単に作成できるRaaS(Ransomware as a Service)
など攻撃するためのツールを販売及びレンタルするような仕組みまで
普及してしまっている。
あとはノーウェアランサムもかなり普及している。
こちらは暗号化もせずにデータを盗んで公開すると脅す手法。
単純明快だが効果は抜群である。バックアップからデータを戻しても
盗られたデータは相手の手に落ちたままなので脅迫は続きます。
また暗号化を実施しないのでデータを保存しているサーバーの
負荷があがらず検知がしづらいという攻撃側のメリットなども大きい。
よくここまでいろんな方法が思いつくものですね。
攻める側も守る側もいたちごっこは続きそうです。
・マルウェア ランサムウェア 違い
・ネットワーク機器 ランサムウェア対策
TOP OF THE NETWORK×NETWORKランサムウェアはRansom（身代金）とSoftware（ソフトウェア）を
組み合わせた造語です。ソフトウェアを利用してファイルの暗号化を
行い（ファイルを閲覧不可状態）復元方法を提示する代わりに
身代金を請求する。
最近ではランサムウェアを簡単に作成できるRaaS(Ransomware as a Service)
など攻撃するためのツールを販売及びレンタルするような仕組みまで
普及してしまっている。
あとはノーウェアランサムもかなり普及している。
こちらは暗号化もせずにデータを盗んで公開すると脅す手法。
単純明快だが効果は抜群である。バックアップからデータを戻しても
盗られたデータは相手の手に落ちたままなので脅迫は続きます。
また暗号化を実施しないのでデータを保存しているサーバーの
負荷があがらず検知がしづらいという攻撃側のメリットなども大きい。
よくここまでいろんな方法が思いつくものですね。
攻める側も守る側もいたちごっこは続きそうです。
・マルウェア ランサムウェア 違い
・ネットワーク機器 ランサムウェア対策
NETWORK×NETWORK
SMTP AUTH 廃止
SMTP AUTH 廃止
マイクロソフト社がセキュリティリスクの懸念から
Exchange OnlineにおけるSMTP AUTH（基本認証/Basic認証）の
廃止を決定しました。
そもそもSMTP AUTH認証とは何なのでしょうか。
どちらかというとBasic(ベーシック認証)と言ったほうが
馴染みがある人が多いかもしれません。
ベーシック認証は一般的にはユーザー名とパスワードで認証する
仕組みです。これは盗まれてしまうと簡単に使えてしまい最近では
この認証方式だけでは非常にリスクがあると言われています。
SMTP AUTHはメール送信時(SMTP利用時)にユーザー名とパスワードで
認証する仕組みです。
以下構成例では、FortiGateが自身のアラートメールをFortiAnalyzer
に送信します。その後、FortiAnalyzerが発報するアラートメールを
Exchange Online に転送し、メール送信を行います。
今回導入している Forti 製品には、単体で外部へ直接メール送信を
完結させる仕組みがないためこのような構成になっています。
◆構成例
Fortigate→FortiAnalyzer→Exchange Online→アラートメールの発砲
(指定したメールあてに送信)
◆FortiAnalyzerの設定情報(Exchange Onlineの認証情報)
SMTPサーバ名：SMTP-AUTH
メールサーバ：smtp.office365.com
SMTPサーバポート：587
認証を有効化：有効
Eメールアカウント：メール発砲する宛先(test@co.jp)
パスワード：Password
セキュアオプション：STARTTLS(SMTPを暗号化するオプション)
ここで記載のあるsmtp.office356.comにベーシック認証できなくなる
わけですね。めんどくさいけどセキュリティレベルを上げるためには
仕方がないことです。
◆対応策
ではどのような対応策があるのか見ていきます。
・OAuth 2.0
・SMTP Relay
・Forti社のメールサーバ利用
[OAuth 2.0]
OAuth 2.0は、ベーシック認証の代わりに推奨されている認証技術です。
従来のように ID やパスワードを相手側へ直接渡すのではなく、
有効期限付きの「トークン」を発行してアクセスさせる仕組みです。
このトークンには有効期限があり、アクセス可能な範囲を限定できます。
また、必要に応じて失効させることも可能なため、セキュリティレベルが
高いのが特徴です。さらに、二要素認証（MFA）にも対応しており、
より安全な認証方式として推奨されています。
[SMTP Relay]
SMTPリレーサーバを利用する。
この場合ベーシック認証ではなくIPアドレスなどでの制限となるため
Exchange OnlineのSMTP AUTHには引っかからない。
自社オンプレで構築する場合は結構な費用が発生するためクラウドの
サービスを利用するのがいい。
[Forti社メールサーバ利用]
Forti社がクラウド上に準備しているメールサーバとなります。
一番簡単だがドメインがfortinet社のものから変更できない。
サーバ名：notification.fortinet.net
用途：アラートメール／ログ通知送信
SMTPポート：通常 465 または 587
認証：不要（SMTP-AUTH 不要）
TLS：有効（暗号化通信）
上記3つのうちだとFortigateやFortiAnalyzerはOAuthに対応していない
ためSMTP RelayやForti社のメールサーバを利用することを
検討しなければならない。
◆対応期限
そこで問題はいつまでにこの対応が必要なのかということ。
2026年1月27日にマイクロソフト社から発表があったのですが、かなり
緩和されたロードマップとなっていました。
もともとは2026年春(3月か4月くらい)に完全終了だったのですが
2026年12月末までは利用できそうです。設定変更を実施することで
2027年後半までは普通に使えそうですね。
Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline
Exchange Team Blog
Microsoft Exchange Team Blog内容参照
TOP OF THE NETWORK×NETWORKマイクロソフト社がセキュリティリスクの懸念から
Exchange OnlineにおけるSMTP AUTH（基本認証/Basic認証）の
廃止を決定しました。
そもそもSMTP AUTH認証とは何なのでしょうか。
どちらかというとBasic(ベーシック認証)と言ったほうが
馴染みがある人が多いかもしれません。
ベーシック認証は一般的にはユーザー名とパスワードで認証する
仕組みです。これは盗まれてしまうと簡単に使えてしまい最近では
この認証方式だけでは非常にリスクがあると言われています。
SMTP AUTHはメール送信時(SMTP利用時)にユーザー名とパスワードで
認証する仕組みです。
以下構成例では、FortiGateが自身のアラートメールをFortiAnalyzer
に送信します。その後、FortiAnalyzerが発報するアラートメールを
Exchange Online に転送し、メール送信を行います。
今回導入している Forti 製品には、単体で外部へ直接メール送信を
完結させる仕組みがないためこのような構成になっています。
◆構成例
Fortigate→FortiAnalyzer→Exchange Online→アラートメールの発砲
(指定したメールあてに送信)
◆FortiAnalyzerの設定情報(Exchange Onlineの認証情報)
SMTPサーバ名：SMTP-AUTH
メールサーバ：smtp.office365.com
SMTPサーバポート：587
認証を有効化：有効
Eメールアカウント：メール発砲する宛先(test@co.jp)
パスワード：Password
セキュアオプション：STARTTLS(SMTPを暗号化するオプション)
ここで記載のあるsmtp.office356.comにベーシック認証できなくなる
わけですね。めんどくさいけどセキュリティレベルを上げるためには
仕方がないことです。
◆対応策
ではどのような対応策があるのか見ていきます。
・OAuth 2.0
・SMTP Relay
・Forti社のメールサーバ利用
[OAuth 2.0]
OAuth 2.0は、ベーシック認証の代わりに推奨されている認証技術です。
従来のように ID やパスワードを相手側へ直接渡すのではなく、
有効期限付きの「トークン」を発行してアクセスさせる仕組みです。
このトークンには有効期限があり、アクセス可能な範囲を限定できます。
また、必要に応じて失効させることも可能なため、セキュリティレベルが
高いのが特徴です。さらに、二要素認証（MFA）にも対応しており、
より安全な認証方式として推奨されています。
[SMTP Relay]
SMTPリレーサーバを利用する。
この場合ベーシック認証ではなくIPアドレスなどでの制限となるため
Exchange OnlineのSMTP AUTHには引っかからない。
自社オンプレで構築する場合は結構な費用が発生するためクラウドの
サービスを利用するのがいい。
[Forti社メールサーバ利用]
Forti社がクラウド上に準備しているメールサーバとなります。
一番簡単だがドメインがfortinet社のものから変更できない。
サーバ名：notification.fortinet.net
用途：アラートメール／ログ通知送信
SMTPポート：通常 465 または 587
認証：不要（SMTP-AUTH 不要）
TLS：有効（暗号化通信）
上記3つのうちだとFortigateやFortiAnalyzerはOAuthに対応していない
ためSMTP RelayやForti社のメールサーバを利用することを
検討しなければならない。
◆対応期限
そこで問題はいつまでにこの対応が必要なのかということ。
2026年1月27日にマイクロソフト社から発表があったのですが、かなり
緩和されたロードマップとなっていました。
もともとは2026年春(3月か4月くらい)に完全終了だったのですが
2026年12月末までは利用できそうです。設定変更を実施することで
2027年後半までは普通に使えそうですね。
Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline
Exchange Team Blog
Microsoft Exchange Team Blog内容参照
NETWORK×NETWORK
ネットワーク機器 ランサムウェア対策
ネットワーク機器 ランサムウェア対策
最近巷を騒がせているマルウェアの一種にランサムウェアが
あります。平たく言うと侵入した後、管理者権限を奪って
重要ファイルなどを暗号化したのちに身代金を要求する手口です。
単純ですが効果は抜群ですよね。
今一番多い侵入経路としてはメールやVPNなどでしょうか。
最近Fortinet社のFortiOS7.4系では一部OSからSSL-VPNが利用不可となり
FortiOS7.6系からは完全に廃止となっています。IPSEC VPNは
引き続き使えます。
IPSEC VPNがまだ多くのネットワーク機器で実装されていることを考えると
VPN自体は技術としてはまだまだ使えるのでしっかりと運用で
カバーしていくべきなのです。ただパッチを定期的に当てるのが面倒だったり
侵入されてから横移動しやすいというウィークポイントを持っているのも
事実です。ゼロトラストネットワークだと横移動しずらいのでセキュリティは
強固になるのですが導入費が跳ね上がります。
それでは既存の環境でどのような対策がとれるのか以下の観点から
考えていきたいと思います。
① ファームウェアの更新
② 不要な接続の遮断
③ 認証の強化
④ アクセス制御（横展開防止）
⑤ 資産管理の徹底
① ファームウェアの更新
[目的]
既知の脆弱性を利用されないようにする(特にVPNまわり)
[対策]
・ベンダーセキュリティサイトの確認やメールの登録
・利用しているネットワーク機器に該当するパッチが出た場合は必然的に更新する
・重大度の高いパッチは優先して更新する
→CriticalやHigh
・サポート切れ機器は利用しない
・SSL-VPNは利用しない
[ポイント]
・作業前にバックアップ取得
・本番環境でパッチを当てるまえに検証環境で実施して、通信試験
・作業手順書、運用手順書などを作成して1回の作業で終わらせない
② 不要な接続の遮断
[目的]
攻撃される対象を極力少なくする
[対策]
・当たり前だが通信は必要なものに絞る
(以外となぜこのポートが空いてるの？って設定が入っている場合が多い)
・WAN側ポートはPING/TELNET/HTTPS接続など遮断しておく
・管理ポートに接続できる人を限定
[ポイント]
・設定、通信の定期的な棚卸しを運用で実施する
→必要がなくなったルールなどから侵入される
・SSL-VPN装置の撤去、使っていないVPN環境の撤去
→テレワーク時に導入したがオフィス回帰でもう利用していないなど
③ 認証の強化
[目的]
管理権限を守る、奪われない(これを奪われると大体終わり)
[対策]
・デフォルト設定の排除
→admin/admin、administrator/password、cisco/ciscoなど安易なものにしない
・管理ポートの変更
・アカウントの管理
・MFA(二要素認証)の導入
[ポイント]
・接続できる管理者や方法などを限定的にする
・利用していないアカウントの削除
→退職者などのアカウントは残さない
→ユーザーやパスワードを定期的に変更する
・セキュリティ対策をしっかりする
→証明書などを導入することで簡単には接続させない
④ アクセス制御
[目的]
侵入されても被害を広げない(横展開は絶対にブロック)
[対策]
・デフォルト設定は常にブロック
→FWなどは基本的に暗黙のDeny設定がはいるが通信は必要なもののみ許可する
・セグメント分離
→利用する環境ごとにセグメントは必ずわける。
・内部から外部の通信も極力しぼる
→C2攻撃などは侵入したあと外との通信を発生させるため
[ポイント]
・必要ないものは極力ネットワークにつながない
・ランサムウェアはバックアップデータを狙ったりするので
コールドバックアップなどで絶対に手の届かない場所で管理
→昔ワンビシって会社を利用していたことがあり決まった時間に
テープバックアップを遠隔地に運んで保管してくれるサービスがあった。
今思えばランサムにはかなり有効だよな。ちなみに今このワンビシは
株式会社NXワンビシアーカイブズという名前で日本通運ホールディングスの
完全子会社になっています
⑤ 資産管理の徹底
[目的]
管理側が知らない機械を作らない
[対策]
・資産管理ツールの導入
→資産管理台帳を自動で作成(Excelなどで人が作成していると限界がくる)
・定期的な棚卸し
・ログの集中管理
[ポイント]
・資産管理ツールを導入して自動化ももちろん必須ですがなんだかんだ
人がみて確認するということも大事。知らない機械やルールが勝手に
部署ごとにあってそこから情報が洩れるということもありうる。
正直侵入や攻撃を100%防ぐのは無理です。これは断言できます。
ポイントは侵入されたあとどのような対策・対応ができるかに
かかっています。これは攻撃されてからでは遅いので普段から準備して
万全の対策を取っておく必要があります。
健康な時はわからないのですが病気になってからはじめて健康の大切が
わかります。企業だと一度情報漏洩すると信用を回復するのは並大抵の
ことではありません。高い、普段使わないならもったいないではなく
セキュリティ対策はお金を使ってでも事前にやっておくことをお勧めします。
TOP OF THE NETWORK×NETWORK最近巷を騒がせているマルウェアの一種にランサムウェアが
あります。平たく言うと侵入した後、管理者権限を奪って
重要ファイルなどを暗号化したのちに身代金を要求する手口です。
単純ですが効果は抜群ですよね。
今一番多い侵入経路としてはメールやVPNなどでしょうか。
最近Fortinet社のFortiOS7.4系では一部OSからSSL-VPNが利用不可となり
FortiOS7.6系からは完全に廃止となっています。IPSEC VPNは
引き続き使えます。
IPSEC VPNがまだ多くのネットワーク機器で実装されていることを考えると
VPN自体は技術としてはまだまだ使えるのでしっかりと運用で
カバーしていくべきなのです。ただパッチを定期的に当てるのが面倒だったり
侵入されてから横移動しやすいというウィークポイントを持っているのも
事実です。ゼロトラストネットワークだと横移動しずらいのでセキュリティは
強固になるのですが導入費が跳ね上がります。
それでは既存の環境でどのような対策がとれるのか以下の観点から
考えていきたいと思います。
① ファームウェアの更新
② 不要な接続の遮断
③ 認証の強化
④ アクセス制御（横展開防止）
⑤ 資産管理の徹底
① ファームウェアの更新
[目的]
既知の脆弱性を利用されないようにする(特にVPNまわり)
[対策]
・ベンダーセキュリティサイトの確認やメールの登録
・利用しているネットワーク機器に該当するパッチが出た場合は必然的に更新する
・重大度の高いパッチは優先して更新する
→CriticalやHigh
・サポート切れ機器は利用しない
・SSL-VPNは利用しない
[ポイント]
・作業前にバックアップ取得
・本番環境でパッチを当てるまえに検証環境で実施して、通信試験
・作業手順書、運用手順書などを作成して1回の作業で終わらせない
② 不要な接続の遮断
[目的]
攻撃される対象を極力少なくする
[対策]
・当たり前だが通信は必要なものに絞る
(以外となぜこのポートが空いてるの？って設定が入っている場合が多い)
・WAN側ポートはPING/TELNET/HTTPS接続など遮断しておく
・管理ポートに接続できる人を限定
[ポイント]
・設定、通信の定期的な棚卸しを運用で実施する
→必要がなくなったルールなどから侵入される
・SSL-VPN装置の撤去、使っていないVPN環境の撤去
→テレワーク時に導入したがオフィス回帰でもう利用していないなど
③ 認証の強化
[目的]
管理権限を守る、奪われない(これを奪われると大体終わり)
[対策]
・デフォルト設定の排除
→admin/admin、administrator/password、cisco/ciscoなど安易なものにしない
・管理ポートの変更
・アカウントの管理
・MFA(二要素認証)の導入
[ポイント]
・接続できる管理者や方法などを限定的にする
・利用していないアカウントの削除
→退職者などのアカウントは残さない
→ユーザーやパスワードを定期的に変更する
・セキュリティ対策をしっかりする
→証明書などを導入することで簡単には接続させない
④ アクセス制御
[目的]
侵入されても被害を広げない(横展開は絶対にブロック)
[対策]
・デフォルト設定は常にブロック
→FWなどは基本的に暗黙のDeny設定がはいるが通信は必要なもののみ許可する
・セグメント分離
→利用する環境ごとにセグメントは必ずわける。
・内部から外部の通信も極力しぼる
→C2攻撃などは侵入したあと外との通信を発生させるため
[ポイント]
・必要ないものは極力ネットワークにつながない
・ランサムウェアはバックアップデータを狙ったりするので
コールドバックアップなどで絶対に手の届かない場所で管理
→昔ワンビシって会社を利用していたことがあり決まった時間に
テープバックアップを遠隔地に運んで保管してくれるサービスがあった。
今思えばランサムにはかなり有効だよな。ちなみに今このワンビシは
株式会社NXワンビシアーカイブズという名前で日本通運ホールディングスの
完全子会社になっています
⑤ 資産管理の徹底
[目的]
管理側が知らない機械を作らない
[対策]
・資産管理ツールの導入
→資産管理台帳を自動で作成(Excelなどで人が作成していると限界がくる)
・定期的な棚卸し
・ログの集中管理
[ポイント]
・資産管理ツールを導入して自動化ももちろん必須ですがなんだかんだ
人がみて確認するということも大事。知らない機械やルールが勝手に
部署ごとにあってそこから情報が洩れるということもありうる。
正直侵入や攻撃を100%防ぐのは無理です。これは断言できます。
ポイントは侵入されたあとどのような対策・対応ができるかに
かかっています。これは攻撃されてからでは遅いので普段から準備して
万全の対策を取っておく必要があります。
健康な時はわからないのですが病気になってからはじめて健康の大切が
わかります。企業だと一度情報漏洩すると信用を回復するのは並大抵の
ことではありません。高い、普段使わないならもったいないではなく
セキュリティ対策はお金を使ってでも事前にやっておくことをお勧めします。
NETWORK×NETWORK
Public DNS 一覧
ネットワークがめちゃくちゃ遅くなったりするときの
原因として名前解決が考えられます。
名前解決とは人間がわかりやすい名前をコンピュータが
わかりやすいIPアドレスに変換する仕組みです。
◆DNSサーバ
PC：以下のサイトを見たいので、名前のIPアドレスを教えてください！
www.google.co.jp
DNSサーバー：あいよ！
www.google.co.jp → IPアドレス：142.250.199.3
PC：142.250.199.3へ接続、うまくgoogleのサイトが見えた！
動作的にはこのようなにPCがわかるIPアドレスへの
変換をおこなっているのがDNSサーバとなります。
通信が遅くなる原因としては色々考えられるのですが、
DNSの名前解決は最初に疑ってもいい要因です。
会社のネットワークだとプロキシサーバやプロバイダが
提供しているDNSサーバを利用していることが多いのですが
世の中にはパブリックDNSといわれる無料で利用できる
DNSサーバもあったりします。
とりあえずネットワーク遅延などが起きるときは
無料DNSサーバを利用して障害の切り分けを実施しましょう。
◆無料DNSサーバ一覧
[Google Public DNS]
IPv4:8.8.8.8 IPv6:2001:4860:4860::8888
IPv4:8.8.4.4 IPv6:2001:4860:4860::8844
[Cloudflare]
IPv4:1.1.1.1 IPv6:2606:4700:4700::1111
IPv4:1.0.0.1 IPv6:2606:4700:4700::1001
[Quad9]
IPv4:9.9.9.9 IPv6:2620:fe::fe
[Cisco]
IPv4:208.67.222.222 IPv6:2620:119:35::35
こちらの無料DNSサーバは一時的に利用する分には
いいのですが以下について考慮する必要があります。
・情報が無料DNSサーバ運営事業者に見える
→会社としてどのような外部サイトに接続しているか見えてしまう
→会社のポリシーに引っかからないか
とはいえ結局ISP事業者の外部DNSサーバを利用している時点で
情報は回線事業者には見えています。あまり変わらない気もします。
インターネットに出るときの構成として以下のような経路をよく見ます。
経路：PC→AD(DNS)サーバ→プロキシサーバ→FW→インターネット
この場合内部の名前解決はAD(DNS)サーバが行い、ログなどは
プロキシサーバに保存されます。よって外部DNSは正直安定していて
早いPublicDNSで全然問題ないと思います。
TOP OF THE NETWORK×NETWORK原因として名前解決が考えられます。
名前解決とは人間がわかりやすい名前をコンピュータが
わかりやすいIPアドレスに変換する仕組みです。
◆DNSサーバ
PC：以下のサイトを見たいので、名前のIPアドレスを教えてください！
www.google.co.jp
DNSサーバー：あいよ！
www.google.co.jp → IPアドレス：142.250.199.3
PC：142.250.199.3へ接続、うまくgoogleのサイトが見えた！
動作的にはこのようなにPCがわかるIPアドレスへの
変換をおこなっているのがDNSサーバとなります。
通信が遅くなる原因としては色々考えられるのですが、
DNSの名前解決は最初に疑ってもいい要因です。
会社のネットワークだとプロキシサーバやプロバイダが
提供しているDNSサーバを利用していることが多いのですが
世の中にはパブリックDNSといわれる無料で利用できる
DNSサーバもあったりします。
とりあえずネットワーク遅延などが起きるときは
無料DNSサーバを利用して障害の切り分けを実施しましょう。
◆無料DNSサーバ一覧
[Google Public DNS]
IPv4:8.8.8.8 IPv6:2001:4860:4860::8888
IPv4:8.8.4.4 IPv6:2001:4860:4860::8844
[Cloudflare]
IPv4:1.1.1.1 IPv6:2606:4700:4700::1111
IPv4:1.0.0.1 IPv6:2606:4700:4700::1001
[Quad9]
IPv4:9.9.9.9 IPv6:2620:fe::fe
[Cisco]
IPv4:208.67.222.222 IPv6:2620:119:35::35
こちらの無料DNSサーバは一時的に利用する分には
いいのですが以下について考慮する必要があります。
・情報が無料DNSサーバ運営事業者に見える
→会社としてどのような外部サイトに接続しているか見えてしまう
→会社のポリシーに引っかからないか
とはいえ結局ISP事業者の外部DNSサーバを利用している時点で
情報は回線事業者には見えています。あまり変わらない気もします。
インターネットに出るときの構成として以下のような経路をよく見ます。
経路：PC→AD(DNS)サーバ→プロキシサーバ→FW→インターネット
この場合内部の名前解決はAD(DNS)サーバが行い、ログなどは
プロキシサーバに保存されます。よって外部DNSは正直安定していて
早いPublicDNSで全然問題ないと思います。
NETWORK×NETWORK
マルウェア ランサムウェア 違い
最近よく耳にするマルウェアやランサムウェア。
大企業が攻撃されたときニュースではこの言葉が躍っていますね。
ではマルウェアやランサムウェアとは何なのでしょうか。
◇マルウェアとは
悪意があるソフトウェアの総称
・ウィルス、ランサムウェア、トロイの木馬、ワーム、スパイウェアなど
◇ランサムウェアとは
マルウェアの一種で重要なデータを暗号化して身代金を要求する
(最近では暗号化せずに重要なデータを盗んで身代金を要求する
という現実世界の誘拐みたいな手口も多いとか)
ランサムウェアだけというよりもマルウェアといわれるような
悪意のあるソフトウェアと組み合わせて攻撃し、最終的には
ランサムウェアでとどめを刺すようなイメージですね。
では対策としてどのようなことを考えないといけないのでしょうか。
◇マルウェア(ランサムウェア)対策
１．入口対策
２．侵入されても影響範囲を広げない
３．侵入後の怪しい動きを検知
４．感染しても復旧できる仕組み
＊．普段からの教育
① 入口対策（最重要対策）
インターネットと社内の境目(入口)で感染を防ぐ
[メール対策（最大の侵入経路）]
・添付ファイルのサンドボックス実行
・マクロ付Officeファイルはブロック
・実行ファイルの遮断（.exe .js .isoなど）
・URLリライト・リアルタイム評価及び再評価
→なぜ再評価が必要か：メール受信時は無害なサイトのURLでも
数時間後、数日後にマルウェア配布サイトへのリンクに変わっている
・なりすまし対策（SPF/DKIM/DMARC）
→SPF：送信元IPの明言、DKIM：送信途中で改竄されていないか、
DMARC：SPF/DKIMが失敗したときの挙動を決めておく
[Web / インターネット対策]
・URLフィルタリング
→アクセス先のURLを見て判断する仕組み
・カテゴリブロック
→ジャンルごとまとめてブロック(アダルト、ギャンブル、マルウェアなど)
・不正ダウロード検知
→ハッシュ値の確認、拡張子偽装など
・新規ドメインや評価未確定サイトの遮断
[VPN・リモートアクセス]
・MFA認証(多要素認証)の導入
・クライアント証明書のインストール
・接続後の通信制御（VPN接続後の利用できる範囲をなるべく絞る）
・VPN装置のOS最新バージョンアップ
→VPNの技術が問題なのではなく機器の脆弱性が問題。セキュリティパッチ
などは必ず更新するようにする
② 侵入されても影響範囲を広げない
侵入された後の横展開を防ぐ(ネットワーク分離や権限制御など)
[ネットワーク分離]
クライアント / サーバ / 管理 / バックアップセグメントを分けて構築
内部の通信制御(east-west制御)
→社内の通信だから安全ではなく必要な通信のみ許可するようにする。
→基本的にはゼロトラストの考えで、何も信用しない
権限管理・管理者権限の常用禁止
→ランサムは「管理者権限を取れたら勝ち」 のゲーム
PAMの導入
→特権IDの管理(ドメイン管理者、サーバ管理者（root / Administrator）、
NW機器管理ID、クラウド管理者、バックアップ管理者など)
③ 侵入後の怪しい動きを検知
入口対策でも100%防げないので、侵入後の被害を最小化する方法を考慮
[エンドポイント]
・EDR(Endpoint Detection and Response)
→PCやサーバなど実際に人が利用する端末
→端末内の動きを常に監視し、怪しければ検知・対応する仕組み
・挙動検知
→短時間で複数ファイルの暗号化を実施、権限昇格などを繰り返している
などの怪しい動きをしている
・C2通信検知(Command & Control)
→感染した端末が外のサーバと通信を実施して情報を送ったりファイルの
暗号化したりする
[ネットワーク]
・IDS / IPS
・DNSフィルタ
→名前解決する際に危険なサイトへの接続は許可しない
・NDR(Network Detection and Response)
→全体の通信を常時監視して怪しい動きを検知・対応する仕組み
[ログ統合]
・SIEM(Security Information and Event Management)
→ログを一か所に集めて一元管理・分析などを実施
・管理ログ・VPNログ・通信ログ取得
→感染はゼロにできないを前提として考慮する
→感染しても調査できる仕組み
④ 感染しても復旧できる仕組み
[バックアップについて]
・バックアップ戦略
→何を(重要度)、どこに、どれくらいの頻度で、どれくらい保持するか、
誰が復旧できるか
→3-2-1ルール(バックアップデータ×3、媒体数×2、1つは別の場所)
・オフライン / WORM
→バックアップ媒体を必要なとき以外NWに接続しない
→データを消せない、上書きできない仕組み
・バックアップNW分離
→セグメントを分けて通信制御
・マルウェア感染しても身代金を払わない
→犯人が調子にのる
[その他の仕組み]
・DLP（情報流出対策）
→個人情報、企業情報、顧客情報、機密情報などの漏洩
・大量転送検知
・クラウド共有監視
→社外共有を作成したり外部の人にリンクを公開
→大量のファイルを共有
＊ 普段からの教育
・教育
・インシデント対応訓練
・感染時の初動
・連絡フロー
などなど昨今巷を騒がせているランサムウェア対策は何か一つをやるでは
不十分でいろいろ組み合わせて対策が必要になってきます。
実際にデータを暗号化されたり、盗まれて身代金を要求されてからでは
時すでに遅しとなります。セキュリティ対策は正しくやれば無駄になることは
ないのでお財布と相談した上でできることをキッチリとやっていきましょう！
TOP OF THE NETWORK×NETWORK大企業が攻撃されたときニュースではこの言葉が躍っていますね。
ではマルウェアやランサムウェアとは何なのでしょうか。
◇マルウェアとは
悪意があるソフトウェアの総称
・ウィルス、ランサムウェア、トロイの木馬、ワーム、スパイウェアなど
◇ランサムウェアとは
マルウェアの一種で重要なデータを暗号化して身代金を要求する
(最近では暗号化せずに重要なデータを盗んで身代金を要求する
という現実世界の誘拐みたいな手口も多いとか)
ランサムウェアだけというよりもマルウェアといわれるような
悪意のあるソフトウェアと組み合わせて攻撃し、最終的には
ランサムウェアでとどめを刺すようなイメージですね。
では対策としてどのようなことを考えないといけないのでしょうか。
◇マルウェア(ランサムウェア)対策
１．入口対策
２．侵入されても影響範囲を広げない
３．侵入後の怪しい動きを検知
４．感染しても復旧できる仕組み
＊．普段からの教育
① 入口対策（最重要対策）
インターネットと社内の境目(入口)で感染を防ぐ
[メール対策（最大の侵入経路）]
・添付ファイルのサンドボックス実行
・マクロ付Officeファイルはブロック
・実行ファイルの遮断（.exe .js .isoなど）
・URLリライト・リアルタイム評価及び再評価
→なぜ再評価が必要か：メール受信時は無害なサイトのURLでも
数時間後、数日後にマルウェア配布サイトへのリンクに変わっている
・なりすまし対策（SPF/DKIM/DMARC）
→SPF：送信元IPの明言、DKIM：送信途中で改竄されていないか、
DMARC：SPF/DKIMが失敗したときの挙動を決めておく
[Web / インターネット対策]
・URLフィルタリング
→アクセス先のURLを見て判断する仕組み
・カテゴリブロック
→ジャンルごとまとめてブロック(アダルト、ギャンブル、マルウェアなど)
・不正ダウロード検知
→ハッシュ値の確認、拡張子偽装など
・新規ドメインや評価未確定サイトの遮断
[VPN・リモートアクセス]
・MFA認証(多要素認証)の導入
・クライアント証明書のインストール
・接続後の通信制御（VPN接続後の利用できる範囲をなるべく絞る）
・VPN装置のOS最新バージョンアップ
→VPNの技術が問題なのではなく機器の脆弱性が問題。セキュリティパッチ
などは必ず更新するようにする
② 侵入されても影響範囲を広げない
侵入された後の横展開を防ぐ(ネットワーク分離や権限制御など)
[ネットワーク分離]
クライアント / サーバ / 管理 / バックアップセグメントを分けて構築
内部の通信制御(east-west制御)
→社内の通信だから安全ではなく必要な通信のみ許可するようにする。
→基本的にはゼロトラストの考えで、何も信用しない
権限管理・管理者権限の常用禁止
→ランサムは「管理者権限を取れたら勝ち」 のゲーム
PAMの導入
→特権IDの管理(ドメイン管理者、サーバ管理者（root / Administrator）、
NW機器管理ID、クラウド管理者、バックアップ管理者など)
③ 侵入後の怪しい動きを検知
入口対策でも100%防げないので、侵入後の被害を最小化する方法を考慮
[エンドポイント]
・EDR(Endpoint Detection and Response)
→PCやサーバなど実際に人が利用する端末
→端末内の動きを常に監視し、怪しければ検知・対応する仕組み
・挙動検知
→短時間で複数ファイルの暗号化を実施、権限昇格などを繰り返している
などの怪しい動きをしている
・C2通信検知(Command & Control)
→感染した端末が外のサーバと通信を実施して情報を送ったりファイルの
暗号化したりする
[ネットワーク]
・IDS / IPS
・DNSフィルタ
→名前解決する際に危険なサイトへの接続は許可しない
・NDR(Network Detection and Response)
→全体の通信を常時監視して怪しい動きを検知・対応する仕組み
[ログ統合]
・SIEM(Security Information and Event Management)
→ログを一か所に集めて一元管理・分析などを実施
・管理ログ・VPNログ・通信ログ取得
→感染はゼロにできないを前提として考慮する
→感染しても調査できる仕組み
④ 感染しても復旧できる仕組み
[バックアップについて]
・バックアップ戦略
→何を(重要度)、どこに、どれくらいの頻度で、どれくらい保持するか、
誰が復旧できるか
→3-2-1ルール(バックアップデータ×3、媒体数×2、1つは別の場所)
・オフライン / WORM
→バックアップ媒体を必要なとき以外NWに接続しない
→データを消せない、上書きできない仕組み
・バックアップNW分離
→セグメントを分けて通信制御
・マルウェア感染しても身代金を払わない
→犯人が調子にのる
[その他の仕組み]
・DLP（情報流出対策）
→個人情報、企業情報、顧客情報、機密情報などの漏洩
・大量転送検知
・クラウド共有監視
→社外共有を作成したり外部の人にリンクを公開
→大量のファイルを共有
＊ 普段からの教育
・教育
・インシデント対応訓練
・感染時の初動
・連絡フロー
などなど昨今巷を騒がせているランサムウェア対策は何か一つをやるでは
不十分でいろいろ組み合わせて対策が必要になってきます。
実際にデータを暗号化されたり、盗まれて身代金を要求されてからでは
時すでに遅しとなります。セキュリティ対策は正しくやれば無駄になることは
ないのでお財布と相談した上でできることをキッチリとやっていきましょう！
NETWORK×NETWORK
Windows11 セットアップ ネットワーク スキップ
Windows11になってからPCセットアップ時にMicrosoftアカウントの
入力を求められいらついたことはありませんか？
本当にむかつく仕様ですよね。何様のつもりなんでしょうか？
マイクロソフト様ですね。
MicrosoftアカウントはWindows11の22H2から必須になりました。
持っていない人やネットワークに接続できないひとのことを全く
考えていませんね。というわけでアカウントを持っていなくても
設定できる方法を検証していきます。
１．start ms-cxh:localonly
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞start ms-cxh:localonly
すると[このPCのユーザーを作成します]とポップアップが表示されます。
ユーザー名、パスワード、パスワードの秘密の回答などを入力して[次へ]
を押すとPC再起動後に作成したローカルユーザーでログインできました。
２．oobe\BypassNRO.cmd
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞cd oobe
C:\Windows\System32\oobe＞BypassNRO.cmd
こちらの方法でコマンドを入力したあとPCが再起動して
結局Microsfotアカウントを要求されました。
３．コマンドでローカルユーザー作成
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞net user "ユーザー名" "パスワード" /add
C:\Windows\System32>net loaclgroup "Administrators" "ユーザー名" /add
C:\Windows\System32>cd oobe
C:\Windows\System32\oobe>msoobe && shutdown -r
PC再起動後に作成したローカルユーザーでログイン。
手段はまだ残されているのですがすべて[Shift+F10]だより。
これ管理権限でコマンドプロンプト制限されたら終わりそうだな。
そこは頼みますよマイクロソフトさん。
TOP OF THE NETWORK×NETWORK入力を求められいらついたことはありませんか？
本当にむかつく仕様ですよね。何様のつもりなんでしょうか？
マイクロソフト様ですね。
MicrosoftアカウントはWindows11の22H2から必須になりました。
持っていない人やネットワークに接続できないひとのことを全く
考えていませんね。というわけでアカウントを持っていなくても
設定できる方法を検証していきます。
１．start ms-cxh:localonly
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞start ms-cxh:localonly
すると[このPCのユーザーを作成します]とポップアップが表示されます。
ユーザー名、パスワード、パスワードの秘密の回答などを入力して[次へ]
を押すとPC再起動後に作成したローカルユーザーでログインできました。
２．oobe\BypassNRO.cmd
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞cd oobe
C:\Windows\System32\oobe＞BypassNRO.cmd
こちらの方法でコマンドを入力したあとPCが再起動して
結局Microsfotアカウントを要求されました。
３．コマンドでローカルユーザー作成
設定画面で[Shift+F10]を押してコマンドプロンプト起動
起動後、以下コマンド入力
C:\Windows\System32＞net user "ユーザー名" "パスワード" /add
C:\Windows\System32>net loaclgroup "Administrators" "ユーザー名" /add
C:\Windows\System32>cd oobe
C:\Windows\System32\oobe>msoobe && shutdown -r
PC再起動後に作成したローカルユーザーでログイン。
手段はまだ残されているのですがすべて[Shift+F10]だより。
これ管理権限でコマンドプロンプト制限されたら終わりそうだな。
そこは頼みますよマイクロソフトさん。
NETWORK×NETWORK
CISCO AP 自立型 設定
Ciscoの古いAP(Cisco Aironet1100シリーズ)を設定してみた。
EOLはとっくに来ているみたいでOSのバージョンアップ
とかはできない。
Cisco Aironet 1100 シリーズ - 終了のお知らせ
電源はもっていないし売っていないのでPoEスイッチを
秋葉原で買ってきた。5portで5千円と結構するものである。
ポートはCONSOLEとETHERNETの2ポートついている。
IPが設定されているかもわからないので一旦コンソール
ケーブルにて接続。
Username：cisco
Password：Cisco
ap>enable
Password：Cisco
Cisco Aironetシリーズのデフォルトユーザーパスワードで
ログインすることができた。ホスト名もapがデフォルト。
まずはETHERNETに管理IPの設定。
LANにIPを振るとWebUIでも接続して設定変更できるので便利です。
ap#conf t
ap(config)#interface gigabitEthernet 0
ap(config-if)#ip addresss 192.168.1.254 255.255.255.0
ap(config-if)#no shut
今日はそのままCLIで設定を継続。
SSID、暗号化方式、パスワードなどを設定していきます。
ap(config)#dot11 ssid Ciscotest-SSID(SSID名を入力)
ap(config-ssid)#authentication open
ap(config-ssid)#authentication key-management wpa version 2
ap(config-ssid)#wpa-psk ascii 0 *********(パスワードを入力)
ap(config-ssid)#guest-mode →SSIDを表示させる(ステルスモードの場合は設定しない)
ap(config-ssid)#exit
ap(config)#int dot11Radio 1 →2.4GHz(Radio 0)と5GHz(Radio 1)どちらで設定するか決定
ap(config-if)#encryption mode ciphers aes
ap(config-if)#ssid Ciscotest-SSID
ap(config-if)#station-role root →rootだと親機、repeaterだと中継器
ap(config-if)#no shutdown
ap(config-if)#exit
設定した帯域がupしていることを確認
ap#show int dot11Radio 1
Dot11Radio1 is up, line protocol is up
続く・・・
IPアドレスなどが正常に設定できていることを確認
ap#show ip interface brief
ここまで設定すればクライアントPCから接続して
インターネットを閲覧することができました。
CiscoAPの接続先としてFortigateがいるのですが
DHCPやセグメントの設定はやっています。
設定は管理IPを振ったあとWebUIでするのが楽かも。。。
APの管理画面へ接続
ブラウザにhttp://192.168.1.254 →gigabitEthernet 0に設定したIP
ユーザー/パスワードは変更していない限りはデフォルト
TOP OF THE NETWORK×NETWORKEOLはとっくに来ているみたいでOSのバージョンアップ
とかはできない。
Cisco Aironet 1100 シリーズ - 終了のお知らせ
電源はもっていないし売っていないのでPoEスイッチを
秋葉原で買ってきた。5portで5千円と結構するものである。
ポートはCONSOLEとETHERNETの2ポートついている。
IPが設定されているかもわからないので一旦コンソール
ケーブルにて接続。
Username：cisco
Password：Cisco
ap>enable
Password：Cisco
Cisco Aironetシリーズのデフォルトユーザーパスワードで
ログインすることができた。ホスト名もapがデフォルト。
まずはETHERNETに管理IPの設定。
LANにIPを振るとWebUIでも接続して設定変更できるので便利です。
ap#conf t
ap(config)#interface gigabitEthernet 0
ap(config-if)#ip addresss 192.168.1.254 255.255.255.0
ap(config-if)#no shut
今日はそのままCLIで設定を継続。
SSID、暗号化方式、パスワードなどを設定していきます。
ap(config)#dot11 ssid Ciscotest-SSID(SSID名を入力)
ap(config-ssid)#authentication open
ap(config-ssid)#authentication key-management wpa version 2
ap(config-ssid)#wpa-psk ascii 0 *********(パスワードを入力)
ap(config-ssid)#guest-mode →SSIDを表示させる(ステルスモードの場合は設定しない)
ap(config-ssid)#exit
ap(config)#int dot11Radio 1 →2.4GHz(Radio 0)と5GHz(Radio 1)どちらで設定するか決定
ap(config-if)#encryption mode ciphers aes
ap(config-if)#ssid Ciscotest-SSID
ap(config-if)#station-role root →rootだと親機、repeaterだと中継器
ap(config-if)#no shutdown
ap(config-if)#exit
設定した帯域がupしていることを確認
ap#show int dot11Radio 1
Dot11Radio1 is up, line protocol is up
続く・・・
IPアドレスなどが正常に設定できていることを確認
ap#show ip interface brief
ここまで設定すればクライアントPCから接続して
インターネットを閲覧することができました。
CiscoAPの接続先としてFortigateがいるのですが
DHCPやセグメントの設定はやっています。
設定は管理IPを振ったあとWebUIでするのが楽かも。。。
APの管理画面へ接続
ブラウザにhttp://192.168.1.254 →gigabitEthernet 0に設定したIP
ユーザー/パスワードは変更していない限りはデフォルト
NETWORK×NETWORK
