FC2ブログ

[ネスペ]まとめ

ARP、Gratuitous ARP

ノードA(MAC=A、IP=①) <-------> ノードB(MAC=B、IP=②)









         動作コード 送信元MAC 送信元IP 宛先MAC 宛先IP コメント
通常MAC問合せ                           
ARP Request 1 A 000000000000 通常のARPは宛先MAC=0で問合せ
ARP Reply   2 B A
IPアドレス競合検知                           
ARP Request 1 A 0.0.0.0 000000000000 OSはIP更新の際、「IPを①に設定したよー」と周囲に問合せる
Gratuitous ARP 2 B B 「既にIP①は設定してるよー」と答える
周辺機器のテーブル更新                           
Gratuitous ARP 2 X FFFFFFFFFFFF ノードB機器を交換した時、「私MAC=Xに変わったよー」と通知する




ルーティングプロトコル






分類 プロトコル ルーティングアルゴリズム メトリック 更新間隔 更新に使用するマルチキャストアドレス
EGP(Exterior Gateway Protocol) BGP(Border Gateway Protocol) パスベクタ型 パス(経路)+方向(ベクタ)
IGP(Interiror Gateway ProtocolRIPv2 ディスタンスベクタ型 ホップ数 定期的 224.0.0.9
OSPF リンクステート型 コスト 変更があった時 224.0.0.5(All OSPFルータ)、224.0.0.6(All DRルータ)
EIGRP ディスタンスベクタ(ハイブリッド)型 帯域幅+遅延 変更があった時 224.0.0.10




OSPF

Helloパケット交換(マルチキャスト(224.0.0.5)で送信)
 > 隣接ルータとネイバー関係確立
 > ネイバーを認識するとネイバーテーブルに格納
 > ネイバー存在を確認するために定期的にHelloパケットを送信
 > 自身のLSA(Link State Advertisement、リンク情報)をネイバールータに送信
 > 受信したLSAはトポロジテーブル(LSDB = Link State Database )に格納
 > 同じエリア内の全てのルータで同じLSDBを保持
 > LSDBに格納されたLSAを組み合わせてネットワーク全体の地図(トポロジマップ)を作成
 > SPFアルゴリズム(ダイクストラ)を実行し階層ツリーのSPFツリーを作成


内部ルータ: 全I/Fが同エリアに接続されてるルータ。
バックボーンルータ: 1つ以上のI/Fがバックボーンエリアに接続しているルータ。
エリア境界ルータ(ABR = Area Border Router): 異なるエリアを接続しているルータ。
AS境界ルータ(ASBR = AS Boundary Router ) : 1つ以上のI/Fが外部ASのルータと接続しているルータ。


代表ルータ(DR =Designated Router): DRとBDRの間だけでLSAを交換する。
バックアップ代表ルータ(BDR =Backup DR): 
DROTHER : DR、BDRに選出されなかったOSPFルータ。

Helloパケット交換
 > 2Way Stateになった
 > 中に含まれるOSPFプライオリティ値を見る
 > 一番大きい値 = DRになる
 > 二番目に大きい値 = BDRになる
 > もしプライオリティ値が同じ場合は、ルータIDの大きい方からDR、BDRになる。

 ※ DRとBDRはセグメントごとに選出。OSPFプライオリティ値はI/F毎に設定。
   例えば、あるOSPFルータがセグメント1ではDR、セグメント2ではDROTHER、という場合もある。

LSAを交換するネイバー: ルータ間の関係 = Adjacency(アジャセンシ―) > ステータス=Full
ただのネイバー: ルータ間の関係 = Neighbor(ネイバー) > ステータス=2Way



STP

データリンク層(L2)の冗長化技術

STP有効のスイッチを接続
 > BPDUを交換して、ブリッジIDを比較

  <STPで使用されるBPDUバージョン0のフォーマット>
  プロトコル    2Byte : 0=STPを示す
  バージョン    1Byte : BPDUでは0
  タイプ      1Byte : 
  フラグ      1Byte : 
  ルートブリッジID 8Byte : 一番小さいIDがルートブリッジになる
  ルートパスコスト 4Byte : ルートブリッジからのパスコスト合計
  ブリッジID    8Byte : 自身のブリッジID (= ブリッジプライオリティ 2Byte + MAC 6Byte

 > 一番小さいブリッジプライオリティを持つスイッチがルートブリッジ、2番目はセカンダリルートブリッジ、になる。
 > もしブリッジプライオリティが同じ場合は、次にMACアドレスを比較して、一番小さいMACがルートブリッジへ。
    (注)実際には、ルートにさせるスイッチに、一番小さいブリッジIDを付けておく。

 > ルートブリッジからのパスコストが最も大きいポートが、ブロッキングポートになる。
   (言い換えると、指定ポート(セグメントで一番RBに近いポート)でも、ルートポート(ブリッジで一番RBに近いポート)でもないポートがブロッキングポートになる)

  <帯域幅によりパスコストが決まる>
  10Mbps  : 100
  100Mbps  :  19
  1000Mbps :  4
  10Gbps  :  2



具体的な流れ
 1.STP対応ブリッジがループを検出した。
 2.ブロッキング(フレームの転送停止)して、ループを抑える。
 3.リスニング(BPDU受信によるトポロジ把握)
 4.ラーニング(MACアドレスを学習)
 5.フォワーディング(指定ポートとルートポートの転送開始) ※ ブロッキングポートは転送停止。




VPN















方式変更点タイププロトコルコストセキュリティ 速度 可用性 利用ネットワーク暗号化トレンド
専用線専用回線ギャランティ型?なし?××(専用線) ◎◎ × 専用線(閉域網)を占有非常に高額で課題あり、VPN技術へ
IP-VPNギャランティ型MPLS×(L3ルータ) 専用線(閉域網)を複数企業で共有無し(MPLSでユーザ毎に分離)専用線に比べ、距離に依存しない料金体系が画期的。しかしIP通信のみ。L3 VPN。
広域イーサネットギャランティ型〇(L2SW) 専用線(閉域網)を複数企業で共有 IP-VPNの弱点「IP通信のみ」、を解決。L2でVPN構成し、マルチプロトコル実現。しかしIP通信のみでも問題なくなってきてる。
インターネットVPN◎◎ × ×(帯域保証なし) ×(専用線系に比べ可用性低い) インターネット網IP-SEC/SSLBB回線の改善により帯域・信頼性向上し、企業でも利用されるように。
LAN間接続VPN(インターネットVPN)
リモートアクセスVPN(インターネットVPN)
IPSec-VPN(インターネットVPN)全クライアントに専用ソフト/L2TP + IPSec 課題:全クライアントに専用ソフト、クライアントにセキュリティチェック機能無し、ユーザに応じたアクセス制御が困難。 SSL-VPNへ。
SSL-VPN(インターネットVPN)サーバ機器の対応/クライアントアプリのSSL対応
エントリーVPN ベストエフォート型 〇(BB回線利用しながら、インターネットに接続せず閉域網を構成) 閉域網(インターネット接続無し)インターネットVPNの不安の種「インターネット接続」を出来なくしたもの。



SSL-VPN
  1.リバースプロキシ方式
    動作フロー
      1.クライアント: https://www.hoge.com/aaaへアクセス
      2.SSLサーバ: アクセスしてきたクライアントの認証
      3.SSLサーバ: URL変換 > http://aaa.hoge.com
      4.クライアント: aaaサーバと通信可能になる
    課題
      ・Webブラウザで動作しないアプリは使用できない。

  2.ポートフォワーディング方式
    概要
      ・クライアントにJavaやActiveXモジュールを追加させてSSL-VPN通信する事でWebブラウザで動作しないアプリも使えるようにした。
    動作フロー
      1.クライアント: https://www.hoge.com/aaaへアクセス
      2.クライアント: Javaアプレットなどのモジュールを自動的にダウンロードして、PC上で動作させる。
      3.クライアント: JavaアプレットがSSL-VPN GWとSSLトンネルを確立
      4.クライアント: 起動したアプリが、PC上のSSL-VPNエージェント(Javaアプレット)と通信する。
                 VPN先とアクセスする場合は、Javaアプレットにデータが渡される。
      5.クライアント: Javaアプレットは、アプリに対応したTCP/UDPポート番号に対応したSSLコネクション確立。
      6.SSLサーバ: 事前に定義したイントラネット内のサーバ情報(IP/ポート)に基づき、該当サーバへデータを転送。
    課題
      ・

  3.L2フォワーディング方式
    動作フロー
      1.クライアント: https://www.hoge.com/aaaへアクセス
      2.クライアント: SSL-VPNクライアントソフトをダウンロードする。
      3.クライアント: SSL-VPNクライアントソフトがSSL-VPNゲートウェイとSSL通信を確立。
      4.クライアント: SSL-VPNクライアントソフトが、PC上に仮想NICを構築。その仮想NICにはSSL-VPN GWで事前に定義されたIPが割り当てられる。
      5.クライアント: VPN先のサーバが宛先の通信の場合、仮想NIC経由でSSL通信し、SSL-VPN GWに送信される。
      6.VPNサーバ: SSL-VPN GWは、そのデータをイントラネット内の該当サーバに転送。






デジタル署名
  データを送信した人が、間違いなく本人のものであるか証明するための技術。データの送信者を証明できる。

 <AからBへデータを送るケース>
  1.A: 公開鍵秘密鍵を生成。
  2.A: 「公開鍵」を受信者へ送付。 > ★この公開鍵は本物? > 後述の「デジタル証明書」で対策
  3.A: 送りたいデータを作成
  4.A: そのデータのハッシュ値を算出。(MD5/SHA-1)
  5.A: ハッシュ値を秘密鍵で暗号化する。
  6.A: (元のデータ + 暗号化ハッシュ値)を送る。暗号化ハッシュ値は署名の意味。
  7.B: 署名(暗号化ハッシュ値)を、Aの公開鍵で複合化し、ハッシュ値を得る。
  8.B: さらに、元のデータから、ハッシュ値を算出
  9.B: 7と8のハッシュ値が一致したら、Aが送ったデータが「改ざんされてない」事が証明される。



認証局 (Certification Authority)
   デジタル証明書の発行機関。

   「ルート認証局」 = 最上位の認証局。 最上位なので、他の承認を受ける事なく、正当性を証明してる。
   「中間認証局」  = ルート認証局以外。上位からデジタル証明書を発行してもらう事で、正当性を証明してる。



デジタル証明書
   デジタル署名の公開鍵が正しい事を証明するために使う。デジタル署名にデジタル証明書を付属させる。
   ITU-T勧告のX.509で標準仕様として規定。

  1.デジタル署名で「改ざんは防止可能」。 しかし、使った「公開鍵」は本物?
  2.「デジタル証明書」を、デジタル署名に付属させる。 > 公開鍵が本物である証明
    具体的には以下。

    2-1.Webサーバ: 秘密鍵と公開鍵を作る。
    2-2.Webサーバ: Webサーバ公開鍵と各種証明書を、CSR(証明書署名要求)として、認証局(CA)へ送る。
    2-3.CA     : 審査の結果OKなら、そのWebサーバ向けにデジタル証明書を発行。
                  CA秘密鍵で暗号化されたデジタル証明書。これがSSLサーバ証明書となる。
    2-4.クライアント: WebサーバへHTTPSアクセス。
    2-5.Webサーバ: 自身のデジタル証明書を送る。これが提示。
    2-6.クライアント: Webサーバのデジタル証明書を、ブラウザにインストールされている「ルート証明書」の中の公開鍵で複合化。
                  複合化して取り出した「Webサーバ公開鍵」と、同梱された公開鍵が一致すれば、
                  この「Webサーバ公開鍵」はCAが認証したものと証明される。



SSL (Secure Sockets Layer)
    改ざんや、なりすましを防げる暗号化通信技術。
    TLS1.0はSSL3.0を元にしてるが、互換性が無い。
    Google研究者が、2014年10月、SSL3.0の深刻な脆弱性を発見した。この欠点をつく攻撃手法は「POODLE」と名付けられた。

   1.クライアント: WebサーバへHTTPSアクセス。
   2.Webサーバ: サーバの文字色デジタル証明書を提示。
   3.クライアント: そのWebサーバデジタル証明書に署名したCAのルート証明書を検索
               Webブラウザにインストールされている「信頼できるルート証明書」から検索
   4.クライアント: ルート証明書の中の公開鍵で、Webサーバのデジタル証明書を復号して、Webサーバの公開鍵を取り出す。
               複合したデジタル証明書の中の公開鍵(Webサーバ)と、平文で送られた公開鍵を比較。
               一致したら、そのWebサーバの公開鍵は正当なものと証明される。
   5.クライアント: 共通鍵を生成。 (正確には、共通鍵の基になる、プリマスターシークレット情報、だそうだ)
   6.クライアント: 共通鍵を、Webサーバ公開鍵で暗号化して、Webサーバへ送る。
   7.Webサーバ: 送られてきた暗号化共通鍵を、自身の秘密鍵で復号して取り出す。
   8.両方    : この共通鍵でデータを暗号化して、SSL通信を行う。



DNSSEC
    DNS応答の送り元と完全性を検証できる。

   1.ゾーン管理者     : 秘密鍵と公開鍵を作成。
   2.ゾーン管理者     : ゾーン内のリソースレコードを、秘密鍵で暗号化し、電子署名を作成。また、公開鍵を公開。
   3.DNSキャッシュサーバ: 権威ネームサーバへ問合せ。
   4.ゾーン管理者     : 電子署名付きの応答を返す。
   5.DNSキャッシュサーバ: 電子署名を、ゾーン管理者の公開鍵で復号し、平文のDNS応答と比較。
                     一致すれば、正当なゾーン管理者が作成したもので、かつ改ざんも無い事が証明される。



SAML (Security Assertion Markup Language)
    SSO(シングルサインオン)を実現するために必要な、異なるドメイン間でユーザ認証を行うための認証情報の規格。

    IdP (Identity Provider) = 認証情報を提供する側
    SP (Service Provider) = 認証情報を利用する側

   1.ユーザ: クラウドサービスにアクセス
   2.SP  : クラウドサービス(SP)は、ユーザを確認し、SAML認証要求を生成。IdPへリダイレクト。
   3.IdP  : SAML認証を解析し、認証
   4.ユーザ: ユーザ認証
   5.IdP  : SAML認証応答を作成
   6.ユーザ: SAML認証応答と共に、クラウドサービスへリダイレクト
   7.SP  : SAML応答を検証し、ユーザログインを許可
   8.ユーザ: クラウドサービスへログイン



IP-VPN

<説明1>
   IPSecは、暗号化通信を実現する複数プロトコルの集合体。主要なプロトコルは以下3つ。

    1.鍵交換   : IKE (Internet Key Exchange) ・・・ IPSec通信前なので、IKE自身で暗号化通信をサポート。

    2.データ転送: ESP (Encapsulating Security Payload) ・・・ IPヘッダ+ESP、で通信。
       (1)トランスポートモード: IPヘッダ + <データ>(暗号化対象)
       (2)トンネルモード   : 新IPヘッダ + <元IPヘッダ + データ>(暗号化対象) ・・・ 真の受信先の隠蔽可能

    3.完全性と認証: AH (Authentication Header) ・・・ IPヘッダの直後に、「SPI」「シーケンス番号」「認証データ」を挿入。

<説明2>
   フェーズ1: 認証 + フェーズ2の暗号鍵生成
            ◆実行モード
              1.メインモード    : 認証に対向拠点のIPを使用する  > 対向拠点は固定IPにする。
              2.アグレッシブモード:     同上       使用しない > 対抗拠点のIPが変わってもOK。
            ◆暗号化アルゴリズム (フェーズ2で使用する暗号鍵を交換する際に使用)
              DES < 3DES < AES(より安全)

   フェーズ2: データ通信用トンネルの暗号鍵生成 + 制御用IKEトンネル生成
            ◆セキュリティプロトコル (IPsecトンネルで使用)
              1.AH : ○ 認証機能、 × 暗号化
              2.ESP: ○ 認証機能、 ○ 暗号化 > 暗号化も出来るESPが主流。

            ◆暗号化アルゴリズム (IPsecで使用)
              DES < 3DES < AES(より安全)

            ◆動作モード
              1.トンネルモード     : 新しいIPヘッダでパケットをカプセル化。
                新IPヘッダ + ESPヘッダ + <IPヘッダ + TCP/UDPヘッダ + Data + ESPトレーラ> + ESP認証データ
              2.トランスポートモード : 新しいIPヘッダでカプセル化。
                IPヘッダ + ESPヘッダ + <TCP/UDPヘッダ + Data + ESPトレーラ> + ESP認証データ

   その後  : データ通信用IPsecトンネル生成(上り、下り、の2つ)
スポンサーサイト

コメントの投稿

非公開コメント

カレンダー
11 | 2018/12 | 01
- - - - - - 1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31 - - - - -
累積訪問者
現在の訪問者
現在の閲覧者数:
最新記事
最新トラックバック
最新コメント
月別アーカイブ
カテゴリ
プロフィール

bobgosso

Author:bobgosso
FPGAのブログへようこそ!

検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QRコード