ネスぺに昨年のリベンジ(第一回)

・前提

前回のネスぺに挑戦したのですが、エンジニア一年目の合格は無謀すぎたのか午後Ⅱ試験で8点足らず敗北…

前回の敗北…

前回は以下の書籍を2周ずつ行いました

DSC_0008

しかし、詰め込みの知識と動的ルーティングプロトコルに苦手意識を持っていたこと、解答の記述について基本から応用に

結びつけることが出来ぬまま臨んでしまったことが敗北の原因だと分析しております

今年は実務を通して各種プロトコルへの解像度・ネスぺを解くにあたり必要な実務上の視点が身についたと考えているため

上記の書籍の復習+今年のネスぺR6+定期購読している日経NWの記事で対策していきたい

・ネスぺ教科書

今回の記事では上記画像の中から以下の書籍の自信がないところを復習としてまとめます

Amazon.co.jp: 左門至峰の出るとこネスペ教科書 最短距離で合格できるネットワークスペシャリスト (Usable Textbook) : 左門 至峰: Japanese Books

・2章

  • 一般のPCには通常MACアドレスが二つある(イーサネットと無線)
  • 1Gbpsはカテゴリ5e,6のLANケーブルで10Gbpsはカテゴリ6Aや7
  • マルチギガイーサネット…伝送速度は2.5or5Gbpsで規格はIEEE802.3bz
  • ARPスプーフィングは通信制御装置が使用することもある→ARPには認証機能がないので、不正なPCからのARP要求に制御装置のMACを入れて応答
  • LAN設計において冗長化するためあえてループを作り普段はSTPで防ぐ構成をとることもままある
  • STPにおけるブロッキング、リスニング、ラーニングの時間(忘れがちだが20,15,15秒)
  • LAGの設定方法のメリデメ→静的はネゴシエーションに余分なトラフィックが流れない、LACPは対向機器の状態が分かる

・第三章

  • 複数のAPを集中管理するWLCの主要機能(APの設定と構成を管理,APのステータス管理,AP同士の電波干渉を検知,APの負荷分散制御,PMKの保持などによるハンドオーバ機能,利用者認証・VLAN認証などのセキュリティ設定)
  • WLCの動作モード(制御用通信だけがWLCを通過してデータ用通信は端末間で直接行われる、データ通信もWLCを通過)
  • 5GHzは無線LANとレーダの専用帯域でチャネルはW52,53,56
  • W52,53は屋外で使用できない
  • 無線LANのAPはレーダを検知すると即座に他チャネルへ切り替える→DFS
  • APのセルを重ねて配置する意味→APの負荷分散、ハンドオーバをスムーズに行うため
  • PoE:802.3af,PoE+:802.3at,PoE++:802.3bt
  • 無線LANのアクセス制御方式→SSID,[c:any]接続拒否,SSID隠蔽,MACフィルタリング,IEEE802.1x認証
  • 他にもSSIDのステルス機能でビーコンを表示しない方法もある
  • APの認証方式としてパーソナルモード(APとPCでPSKで認証)とエンタープライズモード(認証サーバでユーザIDとPW)がある
  • WPA2のパーソナルモードはPSKを基にPMKを生成していたが3ではSAEを基にPMKを生成するのでよりセキュアに

・第四章

  • ICMPリダイレクトは現行の経路情報を基にした通信よりもよい通信経路(ルータ)があったときにそれを伝えるメッセージ
  • CGN→通信キャリアレベルの規模で使用するNAT
  • マルチキャスト通信はソースとレシーバでやり取りする
  • マルチキャスト通信ではL3機器間のPIMとレシーバ間でのIGMPv2で通信を実現
  • PCがあるマルチキャストグループに参加するときはIGMPjoinメッセージを、離脱するときはIGMPleaveメッセージを送信
  • L2SWはIGMPスヌーピングによって不要なPCにはマルチキャストを送信しないこともできる
  • マルチキャストルーティングプロトコルにはPIM-SMとPIM-DMがあり、ユニキャストルーティングと併用
  • IPv6通信はトランスレータという機器によって、IPv4/IPv6トランスレーションを実現
  • IPからMAC解決するプロトコルがARPでなくv6ではIGMP
  • v6はv4と異なり、DHCPがなくとも自動でIPが割り当てられ、標準ヘッダ以外に拡張ヘッダが導入されIPsecが標準実装

・第五章

  • TCPでACKを待たずに送信できるデータ量のことをウィンドウサイズという
  • TCPプロトコルは3ウェイハンドシェイクによって送信元IPを詐称できない

・第六章

  • HTTPにはGETやPOSTなど様々なメソッドがあるがHTTPSを使用するときはCONNECTメソッドがある
  • プロキシサーバを通過するとき暗号化されているパケットを通信するとき困らないようCONNECTメソッドを使用
  • XFFヘッダはクライアントのIPをヘッダに追記できる→プロキシを経由すると通信がプロキシで一旦終端し、送信元IPが全てプロキシのIPに変換されてしまうため、PCのIPをFWのログなどに残したいときに使用
  • HTTPの基本的な処理→3ウェイハンドシェイク・複数のTCPコネクションでWebサイトに接続
  • HTTP/1.1の問題点→HTTPヘッダが圧縮されない・一つのTCPコネクションで1ファイルのみ取得→通信が遅い
  • HTTP/2→ストリームによる通信の多重化・ヘッダ圧縮
  • プロキシサーバのメリット→ユーザ認証・キャッシュの保存
  • windowsでもプロキシサーバのIP(またはFQDN)とポート番号(一般に8080とか3128が多い)を指定画面はおなじみ
  • 上記方法以外にプロキシサーバをPACファイルで設定する方法もある
  • CONNECTメソッドはプロキシサーバまでしか送られないことに注意(HTTPS通信であることを知らせるためのものなので)
  • プロキシサーバで一旦通信を終端して暗号化を復号するためにはサーバ証明書(オレオレ証明書)が必要
  • 上記についてPC側にエラーが表示されないようにするにはプロキシサーバのルート証明書をPCに入れないといけない
  • リバースプロキシのメリットは代理応答してくれるからセキュア・負荷分散・キャッシュによる応答速度向上がある
  • L2SWのDHCPスヌーピング機能はDHCPのパケットの内容を確認し、PCが固定で設定したIPの時、不正なDHCPサーバが勝手にPCにIPを割り当てることを防ぐ
  • DNSサーバに名前解決を依頼する機能を持つPCのソフトをリゾルバという
  • 国際化ドメイン名はURLに英語以外も使用できるようにする技術
  • DNSサーバは可用性向上のため二台以上置く必要があるが、いずれもactiveでゾーン情報のマスタを保有しているのがマスタDNSサーバでその複製を持っているのがスレーブDNSサーバでスレーブからマスタへゾーン転送を要求するので注意
  • ゾーン転送の感覚はrefreshに格納されている値に従っていたがラグが発生するのでマスタは情報が更新されるとNOTIFYメッセージを送信するのでスレーブがそれを受信したことをきっかけにする
  • リゾルバは名前解決するソフトなのでLinuxのdig,nslookup,DNSサーバもリゾルバ
  • フルリゾルバは自分で最後まで名前解決できるキャッシュDNSサーバなどが一礼
  • 名前解決はリゾルバ→キャッシュ(フルリゾルバ)DNSサーバ→権威(コンテンツ)DNSサーバ(windowsのNW設定で設定するDNSサーバ)
  • DNSに関するキャッシュポイズニングやリフレクタ攻撃について、その原因が外部からの再帰問い合わせを受け付けてしまうことにあるので権威DNSサーバのフルリゾルバ機能は無効にするべきだが、PC(リゾルバ)→権威DNSサーバだと名前解決できないから社内にキャッシュDNSサーバを設置して社内PCの名前解決を受け入れるPC→キャッシュ→権威の構成にする
  • リゾルバ⇔キャッシュ間の問い合わせを再帰問い合わせ、キャッシュ⇔コンテンツ間の問い合わせを反復問い合わせという
  • キャッシュDNSサーバが他のDNSサーバに名前解決を転送する機能やその相手先DNSサーバをフォワーダといい、例として社内のキャッシュDNSがフォワーダとしてプロバイダのDNSサーバを指定するなど
  • DNSの設定はDNSサーバのゾーンファイルに記載
  • DNSキャッシュポイズニングの攻撃を実現するステップ→キャッシュDNSサーバがコンテンツDNSサーバから正規の問い合わせを受信する前に偽のIPをキャッシュさせる→攻撃者はDNSの問い合わせIDを変えながら大量に数を打つ
  • DNSキャッシュポイズニングの対策→送信元ポートのランダム化orDNSSECorDNSサーバの構成変更
  • メールサーバはセキュリティ上の理由からDMZに配置する外部メールサーバ(中継メールサーバ)と内部セグメントに設置する内部メールサーバがある
  • メールの送信プロトコル→SMTP,POP before SMTP(25),SMTP AUTH(587で主流),SMTP over TLS(465)
  • 受信プロトコル→POP3(110),IMAP4(143),POP3S(995)
  • SMTPコマンドによるメール送信の流れ→まずEHLOでSMTPのセッションの開始を通知してMAIL FROMで送信元のメアドを通知しRCPT TOで宛先のメアドを通知し(この二つはエンベロープ情報)でその後メールヘッダとメール本文が通知
  • 自社のメールサーバが踏み台メールサーバとして利用されてしまうことがある→オープンリレーを無効にしていないと…
  • 踏み台対策として自社宛のメール以外中継処理しないようにする
  • VoIP→音声データをパケット化してIP上で通信することで構成としては固定電話→アナログ電話線→VoIPGW→LANケーブル→ルータ→WAN
  • 電話通信は音声データ以外に相手を呼び出したり切断する呼制御というデータがある
  • 呼制御は従来のアナログ電話であればPBXが担当するがVoIPではSIPというプロトコルで実現しSIPサーバが担当し音声データはRTPプロトコルが担当
  • 認証サーバの用途について、ADサーバはwindowの管理用でRADIUSはリモートアクセス用が主でLDAPはディレクトリサービス(主にLinux)で使用

・第七章

  • OSコマンドインジェクション→URLにOSのコマンドを操作するものを混ぜ不正利用
  • SQLインジェクション→URLにDBを操作するコマンドを混ぜ不正利用
  • DNSamp攻撃→DNSは問い合わせパケットより応答パケットのサイズの方が大きく、UDPであることを利用した攻撃
  • NTPを使ったDDoS対策としてNTPサーバのmonlistを無効にする方法がある
  • FWをアクトスタン構成で組むときはフェイルオーバーリンクという専用の線で結線することでセッション情報を同期する
  • 上の作業によりアクトが故障してもPC⇔インターネット通信が維持→ステートフルフェイルオーバー機能
  • チャレンジレスポンス方式→サーバから送信される一度きりのデータをクライアント側で演算した物を返して認証する
  • メッセージ認証→メッセージにMACを付与して送信することで改ざんを検知
  • RADIUSはサプリカントとオーセンティケータと認証サーバで機能する
  • RADIUSについて、PEAPはID/PWでクライアント認証し、サーバ証明書でサーバ認証
  • EAP-TLSはクライアント証明書でクライアント認証し、サーバ証明書でサーバ認証
  • サプリカントからオーセンティケータに通信の始めにEAPOLを送信
  • 検疫NW→外出先で使用したPCに問題がないかを調べ検査結果に応じてサーバやPCへの接続を制限したりパターンファイルやパッチの強制的な適用を行い、これらを実現するためにPCを認証する認証LANと組み合わせるなどのやりかたがある
  • ディジタル署名の目的は改ざん防止・なりすまし防止
  • 公開鍵が正規のものであることを証明するディジタル証明書にはクライアント証明書・サーバ証明書・ルート証明書がある
  • サーバ証明書はURL横の鍵マークで確認でき、サブジェクト内のコモンネームが格納されていて、サイトのFQDN単位で発行されるのでFQDNが複数あると証明書も複数必要
  • CRLよりもOCSPプロトコルを使ったほうがディジタル証明書の失効の確認は早いが事前準備が大変
  • TLS通信の流れについて、クライアントからclient hello→server hello→サーバ証明書→クライアント証明書→暗号化通信
  • TLSの鍵交換方式はDHEとECDHEがありDHが秘密・公開鍵が毎回固定されているがDHEは毎回変わるのでセキュア
  • TLS1.3からAEAD暗号利用モードが必須になった→AEADはメッセージを認証するので改ざんを検知できる
  • OP25B→動的IPから25番ポートを使用して外部NWへの通信を許可しないこと→SMTPに認証機能がないので
  • 仮にPCが外部NWへ通信したいときはサブミッションポート(ポート番号587)を使ってSMTP-AUTHで送信する
  • SPFは送信メールサーバのドメインが詐称されていないかを受信メールサーバ側で検証すること→送信メールサーバ側でTXTレコードをゾーンファイルに設定して送信メールサーバのIPを指定
  • 迷惑メール対策としてその他にDKIM(送信元メールサーバでディジタル署名を付与してメールサーバの正当性を検証するのでSPFと併用可能)とDMARC(SPFやDKIMの検証に失敗した際のアクションを設定可能)がある
  • IDSやIPSはアノマリ型(挙動監視)かシグネチャ型(パターンマッチング)で監視
  • IDSで防御する方法→IDSで検知した攻撃者の送信元IPをFWと連携して防御したり不正なTCPコネクションを検知した際、送信元・宛先IP両方にRSTのフラグをONにして送信・UDPの際は攻撃者に対しport unreachbleを設定したエラーを伝えるパケットを送信
  • フォールスポジティブは誤検知でフォールスネガティブは見逃し
  • WAFはIDSやIPSでも防げない高度なWebサーバへの攻撃を防げる
  • WAFの代表的な機能は以下のもの→SSLアクセラレーション、負荷分散、シグネチャによる通信検知

・第八章

  • LBはルータのように単純にパケット転送をするわけでなく、送信・受信側で2つのTCPコネクションを確立することで適切な振り分け先にパケットを転送できるのだが、振り分け先サーバからのパケットがルーティング処理によってPCに戻ってこない可能性があるので送信元IPをPCから自身のIPに変更する(ソースNAT)か振り分け先サーバのデフォゲをLBに設定することで対策する
  • LBは通信の途中で違うサーバに振り分けられては困るので、セッション維持機能がある(L3orL7)
  • VRRPはバックアップルータがVRRP広告を受信しなくなったら切り替わり、マスタに昇格したバックアップルータがGARPを送信しSWのMACテーブルを書き換える
  • トラッキング→VRRPは一ポート故障しただけではマスタを切り替えないが、負荷分散に関係するポートが1ポートでも故障した時自動で切り替わる
  • SNMPエージェントは各種管理情報をMIBに格納
  • SSL-VPNはTLS(HTTPS)でリモートアクセスする方式でSSL-VPN機器をリバースプロキシとして配置する必要がありVPNルータ・クライアントソフトがなくてもブラウザさえあればVPN環境を構築可能
  • SSL-VPN装置の方式→リバースプロキシ方式,ポートフォワーディング方式,L2フォワーディング方式がある
  • リバースプロキシ方式→リモートPCから会社のDMZにあるSSL-VPN機器のポート443番に通信し、ID/PWで認証して許可されると通信が可能になるが、この時ポート番号443で通信されるのはSSL-VPN機器までで、社内のWebサーバと通信するのであればそれ以降は80で通信
  • ポートフォワーディング方式→任意のポート番号が使用できるようにリモートPCにJavaアプレットというプログラムを入れて、リモートPCとSSL-VPN機器間でポート443の安全な通信路を確立したのち通信
  • L2フォワーディング方式→リモートPCに専用ソフトorブラウザのプラグインモジュールを入れてリモートPCとSSL-VPN機器間でTLS接続トンネルを形成しそのうえでレイヤ2の通信を行うこの方式の特徴としてリモートPCにL2フォワーディング用の専用IPを割り振ることが可能なので、一般的な構成としてリモートPCにプライベートIPを付与しリモートPCがまるで社内LANに直接接続されたPCのようにふるまうことが可能→IPアドレスプールはSSL-VPN機器の中にある
  • SDNはソフトを使ったNWの概念でそれを実現する代表的な技術はOpenflowであり、コントロールプレーンのOFCとデータプレーンのOFSがありOFCがOFSを管理している
  • OFSは起動するとOFCの間でTCPコネクションを確立してその後はOFCの指示によりフローテーブルの作成などを行うのでOFS導入時はOFSにOFCのIPと自身のIPを設定するだけでよいから楽
  • OFS⇔OFC間の通信メッセージはPacket In,Packet out,Flow Mod
  • 管理テーブルはOFSの内部にありどのような処理をするのかの命令が複数格納されており、その命令(エントリ)はパケット識別子(MF)によってIPやMACなどパケットを識別する条件が格納されているものと、Actionというどういう処理をするかが格納されている
  • RPOは障害復旧からどの時点までのデータを戻せるかの時間でRTOは障害発生時からシステムが回復するまでの時間

・第九章

  • RIPはメトリックがホップ数でネクストホップとメトリックで管理するがホップ数の上限は15
  • RIPは実務にて使われることはないがその理由は定期更新が30秒であり、パスの選択に回線の帯域を考慮しないから
  • RIP2でも上記課題は特に解決していないが次の変更がある→経路交換に使用していたブロードキャストをマルチキャストにしてサブネットマスクに対応して認証機能も追加
  • RIPng→v6対応のRIPルーティングプロトコル
  • OSPFのメトリックはコストで帯域も考慮している
  • OSPFは負荷軽減のためエリア単位で管理しておりエリア番号が0のエリアはバックボーンエリア、二エリアの境界に位置するルータがABR
  • DR,BDRはエリアでなくセグメントごとに一つでDR・BDRはプライオリティ値で決定
  • ECMPは動的ルーティングプロトコルについて最適経路が複数あったとき負荷分散して送ってくれる
  • ECMPはパケットモードとフローモードが存在
  • IGPはUDPを使うがEGP(BGP)はTCPの179を使用
  • 再配布するときはループに気を付ける(具体的にはBGPから再配布された経路をBGPに再配布しないよう制限する)
  • IP-VPNではMPLSというラベル(ラベルには利用者を識別するVPN識別ラベルとIP-VPN網内の経路情報のための転送ラベルがある)を使用したプロトコルで高速化を実現
  • IP-VPNのラベルはCEでなくPEで付加される
  • マルチホーミングはインターネット回線の冗長化で複数のプロバイダを使って通信を負荷分散する
  • マルチホーミング時の通信フローについて、内部PCからインターネットはLBで振り分け、外部PCから内部への通信はDNSサーバでラウンドロビン
  • WAS(WAN高速化機器)が高速化を実現する方法→キャッシュ蓄積・データ圧縮・代理応答
  • WASはWANの通信経路の途中に配置されているので故障したらWAN通信が出来なくなるので故障時通信を継続するためにバイパス機能やフェールオープン機能が必要
  • SD-WANでいうとコントロールプレーンがSD-WANコントローラでデータプレーンがSD-WANルータ
  • PPPはPAPやCHAPなどの簡単なパスワード認証しかできなかったが認証機能を拡大したEAPが登場
  • PPPoEはLANに認証機能を実現するプロトコル
  • インターネットVPNはIPsecによって実現される
  • IPsec通信ではVPN機器間にNATを行う機器があると通信が失敗することがある→ESPはポート番号を持たないため機器を通過できない→NATトラバーサルという技術によってESPパケットにUDPヘッダを付与してNAT超えを実現
  • カプセル化について、IPsecで紹介したESP・AHとL2のL2TP・PPTPとL3のGRE
  • VPNは各拠点のLAN同士で通信した時にインターネットを経由したとしてもプライベートIPを使用できる
  • マルチキャスト通信をする(例えば動的ルーティング)VPN通信時はGRE over IPsecする必要がある
  • MTUはルータで調整するがMSSはPCで調整する

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です