1. WPA2 には中間者攻撃による脆弱性が存在した
2. ネットワーク層
2.1. ルーティング
2.1.1. スタティックルーティング
2.1.1.1. メリット
2.1.1.1.1. 設計者の意図通りの経路選択がされる
2.1.1.2. デメリット
2.1.1.2.1. 大規模の場合経路情報が大きくなる
2.1.1.2.2. 設定が複雑で間違いが起こりやすい
2.1.2. ダイナミックルーティング
2.1.2.1. メリット
2.1.2.1.1. 自動で最適なルート選択が可能
2.1.2.1.2. 障害時に自動で経路変更が可能
2.1.2.2. デメリット
2.1.2.2.1. ルーティング情報交換用にトラフィックがながれる
2.1.2.2.2. ルータに負担がかかり処理がおそくなることがある
2.1.2.3. RIP
2.1.2.3.1. デメリット
2.1.2.4. RIP2
2.1.2.4.1. RIPからの改良点
2.1.2.5. OSPF
2.1.2.5.1. RIPの欠点をおぎない広く使われている
2.1.2.5.2. リンクステート型アルゴリズム
2.1.2.5.3. コストが最小となる最適経路を決定する
2.1.2.5.4. エリアという概念
2.1.2.5.5. LSA
2.1.2.6. BGP
2.1.2.6.1. パス属性を用いたパスベクタ型
2.1.2.6.2. ASという概念
2.1.2.6.3. 経由するルータまで分かる
2.1.2.6.4. その他の用語
3. 試験対策
3.1. 回線を束ねる技術
4. 運用管理
4.1. 管理項目
4.1.1. 構成管理
4.1.2. セキュリティ管理
4.1.3. 資源管理
4.1.4. 性能管理
4.1.5. 障害管理
4.2. ITサービスマネジメント
4.2.1. プロアクティブな取り組みが推奨される
4.3. ITIL
4.3.1. ITサービスマネジメントのフレームワーク
4.3.2. ベストプラクティスがまとめられている
4.3.3. ITILを基にした規格がJIS Q 20000 (SIO/IEC 20000)
4.4. 運用管理のポイント
4.4.1. システム導入後の日々の運用で管理
4.4.2. ログのチェック
4.4.3. マニュアルを作成し、最新の状態を維持する
4.4.4. 役割、責務を分担し、窓口を一つにする
4.4.5. メールなどは必要十分な数に絞る
4.4.6. 障害時の対応がてきせつかどうか、訓練して確認する
4.4.7. 自動化やマニュアルで作業者の負担を軽減する
5. ストレージ
5.1. SAN
5.1.1. FC-SAN
5.1.1.1. TCP/IPは使用せず、FCPを使う
5.1.1.2. 構成
5.1.1.2.1. ストレージ
5.1.1.2.2. FCスイッチ
5.1.1.2.3. サーバ（HBAつき）
5.1.2. IP-SAN
5.1.2.1. iSCSI
5.1.2.1.1. TCP/IPを使ってSCSIデータを送る
5.1.2.1.2. SCSIコマンドを発行する「イニシエータ」と
5.1.2.1.3. ストレージ装置で稼働して処理を実行する「ターゲット」間でデータのやりとりをする
5.1.2.2. FCIP
5.1.2.2.1. FCプロトコルをIPでカプセル化
5.1.3. FCoE
5.1.3.1. データリンク層
5.1.3.2. IEEE802.1QのVLANタグを使用した拡張イーサネットを利用してFCフレームを転送する
5.1.3.3. ジャンボフレームを使う必要あり。
5.1.3.4. CNAインターフェースとFCoE対応スイッチが必要
5.1.3.5. FCはロスレスのため、ロスレスイーサネットが実現できる
5.1.3.6. サーバ上のスロットやケーブル消費をおさえ、ネットワークを統合、トポロジを単純にできる
5.1.3.7. CNAがボトルネックになり信頼性や性能問題となりうる
5.1.3.7.1. 対策は二重化、迂回
5.1.4. SANとNASどっちが速い？
5.1.4.1. SANはFTFSなどのファイルシステムを介さずストレージにアクセスできる（ローデバイス方式）
5.1.4.2. NASよりSANが速い
5.1.4.2.1. 企業ではSANネットワークが構築される
5.1.5. FC-SANとIP-SANどっちが速い？
5.1.5.1. TCP/IPは大量のデータトラフィックが発生するストレージアクセスには向かない
5.1.5.2. TCP/IPを使わない、FC-SANのほうが速い
5.1.6. 小規模ならiSCSIによるIP-SANがコスト○
5.2. SANとNASの違い
5.2.1. lbg[NXg[WƂ́i DAS / NAS / SAN j
5.2.2. NASƂ - NASSAN̈Ⴂ
6. ネットワーク関連技術
6.1. 負荷分散
6.2. VRRP
6.3. SNMP
6.3.1. VLAN IDは12bit (4094 ID)が利用可能 (4096-2)
6.3.2. MIB
6.3.3. コミュニティ
6.3.4. ポーリングとtrap
6.4. SDN
6.4.1. ソフトウェアでネットワークを制御
6.4.2. かんたん、迅速にネットワーク構成を大幅に変更可能
6.4.3. プロトコル Open Flow 誕生によって注目を浴びる
6.4.3.1. 昔のネットワーク機器は
6.4.3.2. ①各種プロトコル
6.4.3.3. ②OS(コントロールプレーン)/制御ソフトウェア
6.4.3.4. ③ハードウェア(データプレーン)/パケット転送処理
6.4.3.5. となっており、②③はベンダーの独自インターフェースで接続されていた
6.4.3.6. そこで...
6.4.3.6.1. コントロールプレーンとデータプレーンを分離し、標準インターフェース（OpenFlow）で接続
6.4.3.7. OpenFlowのメリット
6.4.3.7.1. 独自プロトコル利用可能
6.4.3.7.2. 複雑な操作もソフトで実行可能
6.4.3.7.3. ネットワーク機器もシンプルで安くなる
6.4.3.8. OpenFlowの処理が遅くなる時
6.4.3.8.1. OFS内にフローテーブルがない
6.4.3.8.2. マッチするフローエントリがない
6.4.3.8.3. 稀なマッチングルール
6.4.3.8.4. 過去に学習済みなのにOFCに聞く
6.4.3.9. OpenFlow 普及後の話
6.4.3.9.1. 当初はSDN=OpenFlowだった
6.4.3.9.2. OpenFlowでカバーできない部分が出てきた
6.4.3.9.3. OpenFlow ではレイヤ1-4までしか制御できなかった
6.4.3.9.4. ベンダーが独自プロトコルを公開するようになった
6.4.3.9.5. ソフトウェアでネットワークの課題を解決すること自体がSDNという意味合いに変化してきた
6.4.3.10. OpenFlowが適さない環境
6.4.3.10.1. データセンターなどは流れるトラフィックの見当をつけておくことができるが...
6.4.3.10.2. 多彩なパケットが飛ぶWAN側に設置すると学習にきりがなく、リソースが枯渇する
6.4.4. 構成
6.4.4.1. SDNコントローラー
6.4.4.1.1. ネットワーク制御の中心となるソフトウェア
6.4.4.2. スイッチ（物理・仮想）
6.4.4.2.1. データを転送する
6.4.4.2.2. SDNコントローラーからの制御を受け付ける仕組みが必要
6.4.4.3. オーケストレータ
6.4.4.3.1. システム全体を制御する
6.4.4.3.2. ストレージやサーバとの連携のために必要。管理者はオーケストレータにアクセスする
6.4.5. ノースバンドAPIとサウスバウンドAPI
6.4.5.1. ノースバンドAPI
6.4.5.1.1. OpenStackなど
6.4.5.2. サウスバウンドAPI
6.4.5.2.1. SDNコントローラーからスイッチ群を制御するインターフェース
6.4.5.2.2. OpenFlowやベンダ独自API
6.4.6. VLANの限界を超えたSDN
6.4.6.1. VLANは最大4094ではたりない
6.4.6.2. オーバレイ型
6.4.6.2.1. 両端の仮想スイッチに情報を書き込む
6.4.6.2.2. コントローラーがどの仮想スイッチをトンネルでつなぐのか計算する
6.4.6.2.3. L2overL3トンネルを作成して通信する
6.4.6.2.4. メリット
6.4.6.2.5. デメリット
6.4.6.3. ホップバイホップ
6.4.6.3.1. コントローラーがすべての物理スイッチ、仮想スイッチに指示する
6.4.6.3.2. フローテーブルを検索して適切なポートからパケットを流す
6.4.6.3.3. メリット
6.4.6.3.4. デメリット
6.5. 無線LAN
6.5.1. 規格
6.5.2. セキュリティ
6.5.3. MIMO,MU-MIMO
6.5.4. WPA３
6.5.4.1. SAEからPMKを作成
6.5.4.2. ４way handshake の前にSAEを使って情報交換
6.5.4.3. 4way ハンドシェークは２つの鍵交換を行う
6.5.4.3.1. PTK
6.5.4.3.2. GTK
7. セキュリティ
7.1. FW
7.1.1. DMZ
7.1.2. FWの分類
7.1.3. FWルール
7.1.4. UTM
7.1.5. FWの冗長化
7.2. IEEE802.1X認証
7.2.1. EAP
7.2.1.1. PPPを拡張したもの
7.2.1.2. EAPの代表的な認証方式
7.2.1.2.1. EAP-MD５
7.2.1.2.2. EAP-TLS
7.2.1.2.3. PEAP
7.2.2. IEEE802.1X認証に必要なもの
7.2.2.1. サプリカント
7.2.2.1.1. PCにインストールされるソフト
7.2.2.2. オーセンティケータ
7.2.2.2.1. 承認スイッチ、無線APなど
7.2.2.3. 認証サーバ
7.2.2.3.1. RADIUSサーバに代表される認証サーバ
7.2.3. 認証手続き
7.2.3.1. 参考書要チェック
7.2.3.2. 承認SW->認証サーバへの問い合わせの代表プロトコルは？
7.2.3.2.1. RADIUS
7.3. IDS/IPS
7.3.1. 勉強不要
7.4. IPsec
7.4.1. VPNを実現するときの技術
7.4.2. 暗号技術を用いてインターネットでデータを安全に受信するための企画
7.4.3. 暗号化だけでなく、認証、改ざん検知も可能
7.4.4. 利用者の利便性が高い
7.4.5. IPsecを構成するプロトコル
7.4.5.1. IKE
7.4.5.1.1. 暗号鍵の交換するプロトコル
7.4.5.1.2. DH鍵交換方式を改良した技術で鍵を交換する
7.4.5.2. AH
7.4.5.2.1. データのメッセージ認証
7.4.5.2.2. データの改ざんを検知できる
7.4.5.3. ESP
7.4.5.3.1. データのメッセージ認証＆暗号化可能
7.4.5.3.2. じゃAHいらなくない？
7.4.6. 運用モード
7.4.6.1. トンネルモード
7.4.6.1.1. 拠点間VPNで利用されることが多い
7.4.6.1.2. VPNルータ同士で暗号化する
7.4.6.1.3. IPパケット全体を保護する
7.4.6.2. トランスポートモード
7.4.6.2.1. リモートアクセスVPNで利用されることが多い
7.4.6.2.2. IPsecが実装された機器同士で暗号化する
7.4.6.2.3. TCP/UDPヘッダとペイロードを保護する
7.4.7. ESPの暗号化範囲
7.4.7.1. トンネルモードの場合
7.4.7.1.1. 元のIPヘッダからESPトレーラまで
7.4.7.1.2. ESPトレーラは暗号化の端数調整に使う
7.4.7.1.3. ESP認証データはハッシュ値などがあるだけで暗号化する必要がないので暗号化不要
7.4.8. 通信の様子
7.4.8.1. 参考書要チェック
7.5. PKIとディジタル署名
7.6. SSL
8. データリンク層
8.1. イーサネットのフレーム構造を書ける？
8.1.1. 宛先MACアドレス 6byte
8.1.2. 送信元MACアドレス 6byte
8.1.3. タイプ 2byte
8.1.4. データ 46 - 1500 byte
8.1.4.1. データ部分の最大サイズをMTUという。
8.1.5. FCS 4byte
8.2. VLANが付与されたらフレームはどうなる？
8.2.1. 送信元MACアドレスとタイプの間に4byteの802.1Qのヘッダが挿入される
9. アプリケーション層
9.1. DHCP
9.1.1. 前回午後問題出でたので出ないと予想
9.1.2. DHCPサーバ導入メリット
9.1.2.1. 設定簡素化
9.1.2.2. IPアドレス情報の一元管理
9.1.2.3. IPアドレスの有効活用
9.1.2.3.1. リース期間を設定してIPアドレスを再利用できる
9.1.3. DHCPサーバのデメリット
9.1.4. DHCPリレー
9.1.5. DHCPスヌーピング
9.2. DNS
9.2.1. 多数のDNSサーバで構成される分散型データベース
9.2.2. 負荷分散と可用性を考慮して13のルートDNSサーバが世界中に配置されている
9.2.3. 代表的なレコード
9.2.3.1. SOAレコード
9.2.3.1.1. 自身が管理するDNSのゾーンに関する情報を記載
9.2.3.2. Aレコード
9.2.3.3. MXレコード
9.2.3.3.1. メールサーバのFQDNを記載
9.2.3.4. NSレコード
9.2.3.4.1. ゾーン自身や下位ドメインのDNSサーバを記載
9.2.3.4.2. FQDNで記載する
9.2.3.5. PTRレコード
9.2.3.5.1. 逆引き
9.2.3.6. CNAME
9.2.3.6.1. 別名
9.2.4. bindの設定例
9.2.4.1. /etc/named.conf
9.2.4.2. /var/named/seeko.com
9.2.4.2.1. serial番号
9.2.4.2.2. refresh時間
9.2.4.2.3. retry時間
9.2.4.2.4. expire時間
9.2.4.2.5. negative cache時間
9.2.4.2.6. NSレコード
9.2.4.2.7. MXレコード
9.2.4.2.8. その他レコードもここに記載
9.2.5. DNS関連用語
9.2.5.1. リゾルバ
9.2.5.2. ２つの問い合わせ
9.2.5.2.1. 再帰問い合わせ
9.2.5.2.2. 反復問い合わせ
9.2.5.3. zone転送
9.2.5.3.1. プライマリ→セカンダリDNSサーバへの同期
9.2.5.3.2. セカンダリがリフレッシュ間隔でゾーン転送を要求
9.2.5.3.3. セカンダリが起動したときやプライマリからの更新通知（notify)がされたときもゾーン転送される
9.2.5.4. DNSキャッシュサーバ
9.2.5.4.1. ドメイン情報を管理しない
9.2.5.4.2. キャッシュ情報を保有してPCからの問い合わせに回答
9.2.5.4.3. 問い合わせ先DNSサーバをフォワーダとして設定するだけでOK
9.2.5.4.4. 対義語としてドメイン情報をもつ「コンテンツサーバ」
9.2.5.4.5. キャッシュサーバ導入のメリット
9.2.5.4.6. コンテンツサーバではなくキャッシュサーバが回答するメリット
9.2.5.5. ダイナミックDNS
9.2.5.5.1. PCのIPアドレスが変わってもそのPCにはホナ時ホスト名でアクセスできる
9.2.5.5.2. 一般的にLANで使われる
9.3. 電子メール
9.3.1. 送信用プロトコル
9.3.1.1. SMTP
9.3.1.1.1. 認証機能がないので...
9.3.2. 受信用プロトコル
9.3.2.1. POP3
9.3.2.1.1. PCがメールを受信したらメールデータはサーバから消える
9.3.2.1.2. 問題点
9.3.2.2. POP3S
9.3.2.2.1. POP通信そのものをSSL暗号化。995番ポート
9.3.2.3. IMAP４
9.3.2.3.1. POP3の問題に対処可能
9.3.2.3.2. メールをサーバ上で管理
9.3.2.3.3. どのPCからでも同一に見える
9.3.2.3.4. Webメールのようなイメージ
9.3.2.3.5. メールデータを以降する際に便利
9.3.3. メールシステムの構成
9.3.3.1. DMZに外部メールサーバ
9.3.3.2. 内部セグメントに内部メールサーバ
9.3.3.3. このようにする理由は？
9.3.3.3.1. セキュリティ確保
9.3.3.3.2. メールデータをDMZにおいておくのは危険
9.3.3.3.3. 内部メールサーバにメールデータは蓄積する
9.3.4. メールヘッダ
9.3.4.1. 下から上に配送ルートが記載される
9.3.4.1.1. 基本的にbyで示されたサーバを見る
9.3.5. MIME
9.3.5.1. メールで画像、動画、音声など様々な情報をおくる仕組み
9.3.6. セキュリティ対策
9.3.6.1. 送信元の認証
9.3.6.1.1. SPF
9.3.6.1.2. DKIM
9.3.7. SPAM対策
9.3.7.1. OP25B
9.3.7.1.1. ISP管理下のIPから管理外ネットワークのメールサーバへSMTPを禁止
9.3.7.1.2. 多くのプロバイダで導入
9.3.7.1.3. プロバイダのメールサーバに送る場合は２５番でOK
9.3.7.1.4. それ以外は587番でSMTP AUTHの認証が必要
9.3.8. オプトイン/オプトアウト
9.3.8.1. オプトイン
9.3.8.1.1. メルマガを配信希望と能動的に伝えたユーザーのみ送信
9.3.8.2. オプトアウト
9.3.8.2.1. 配信停止の申し出がない限りメルマガを送る
9.4. FTP
9.4.1. FTPのセキュリティ
9.4.1.1. FTPはデータが平文
9.4.1.1.1. SFTP
9.4.1.2. 認証データも平文
9.4.2. 転送モード
9.4.2.1. ACSIIモード
9.4.2.1.1. 改行を自動変換してくれるが、ファイルが壊れることも
9.4.2.2. バイナリモード（最近はこっち）
9.4.3. アクティブモードとパッシブモード
9.4.3.1. アクティブモード
9.4.3.2. パッシブモード
9.4.4. TFTP
9.4.4.1. 簡易型ファイル転送用プロトコル
9.4.4.2. ユーザ認証をしない
9.4.4.3. TCPではなくUDPを使う
9.5. Proxy
9.5.1. 導入目的
9.5.1.1. セキュリティ強化
9.5.1.2. キャッシュによる帯域効率化と高速化
9.5.2. 設定方法
9.5.2.1. IP直指定
9.5.2.2. 自動設定ファイル（PAC）
9.5.3. HTTPSの場合
9.5.3.1. PCはproxyに透過処理を依頼
9.5.3.2. CONNECTメソッドを使う
9.5.3.3. proxyによるセキュリティチェックができなくなる？
9.5.3.3.1. そのとおり
9.5.3.3.2. 最近の製品はHTTPS通信をproxyで一旦終端して通信を復号化する
9.5.3.3.3. そのあとproxyとWebサーバ間で再度HTTPS通信する
9.5.3.3.4. このときはproxyのサーバ証明書をPCにインストールする必要あり
9.6. VoIP
9.6.1. 参考書要チェック