Abstract navy and gray geometric header background for article on low-risk legacy DNS migration
コンテンツハブ

OSIモデルとは何ですか?また、DNSとIPアドレスは、その7つのレイヤーのどこに位置づけられますか?

DDI、OSIモデル Updated

OSIモデルはネットワークを7つの層に分割しており、中核となるネットワーク機能はそれぞれ異なる層で動作します。具体的には、DNSはレイヤー7、IPアドレスはレイヤー3、MACアドレスはレイヤー2に位置します。BlueCat Integrityは、MACレコードとIPレコードを単一の信頼できる情報源として連携させます。

· 01 — OSIモデルとは何か、そしてその7つの層がどのように役割を分担しているか

OSIモデルとは何ですか?

OSIモデルは、国際標準化機構(ISO)によって作成された概念的なフレームワークであり、ネットワーク通信を7つの階層に分類しています。 各レイヤーは独自の機能を果たし、その直上のレイヤーおよび直下のレイヤーと通信を行います。

上から順に、レイヤーはアプリケーション(レイヤー 7)、プレゼンテーション(6)、セッション(5)、トランスポート(4)、ネットワーク(3)、データリンク(2)、物理(1)です。 このモデルは、インターネットプロトコルに基づいて構築された4層のTCP/IPモデルとは異なり、特定のプロトコルに依存せず、エンジニアにトラブルシューティングのための共通言語を提供します。

DNSは、レイヤー7のアプリケーション層プロトコルです。レイヤー4ではUDP(場合によってはTCP)を介して、レイヤー3ではIPを介して伝送されます。このため混乱を招くこともありますが、これらのレイヤーを使用しているからといって、DNSがレイヤー4やレイヤー3のプロトコルになるわけではありません。

7 抽象化レイヤー

このモデルは、レイヤー1の電気信号、無線信号、光信号から、レイヤー7のアプリケーションプロトコルに至るまで、7つのレイヤーを積み重ねたものです。

Network server racks Read article
さらに詳しく読む

What is the OSI model? It standardizes how computer networks communicate

The OSI model is a conceptual model that provides a universal standard for how computing devices communicate across networks, with seven abstract layers.

1 min Page
続きを読む

· 02 — OSIモデルが「参照モデル」であり、「ネットワークモデル」ではない理由

OSIモデルについて、人々はどのような誤解を抱いているのでしょうか?

最もよくある間違いは、OSIモデルを「何かが接続できるネットワーク」として扱うことです。 これはネットワークのための7層モデルであり、データリンク層はその第2層であり、ネットワークが接続する対象ではありません。

レイヤーに関する混乱は、まったく異なる役割を果たすプロトコルを混同させる原因にもなります。ARPはIPアドレスをMACアドレスに解決するデータリンク層のプロトコルであるのに対し、DNSはドメイン名をIPアドレスに変換する階層的な命名システムです。この2つは別物ですが、IPネットワークでは、DNSが機能するためにはARPが正常に動作している必要があります。

テレビの犯罪コメディ『ブルックリン・ナイン・ナイン』のあるエピソード(S6E14)では、これらの用語が支離滅裂に組み合わされ、OSIはネットワークではないという指摘を含め、台詞一つひとつが事実確認の対象となりました。 このエピソードが伝えるより広範な教訓はソーシャルエンジニアリングに関するもので、チームに攻撃者を疑うための技術的知識が欠けていたため、攻撃者はほぼ成功しかけていた。

B99 Read article
さらに詳しく読む

How Brooklyn Nine-Nine S6E14 got cybersecurity all wrong

Brooklyn Nine-Nine's writers have a great cybersecurity vocabulary, but not a great understanding of how cybersecurity works. BlueCat breaks it down.

8 min Blog
続きを読む

· 03 — DNSの暗号化は、それを監視するチームにとってどのような変化をもたらすか

クエリが HTTPS 経由で暗号化されると、DNS の可視性はどうなるのでしょうか?

DNS に対する企業の可視性はゼロになります。 DNS over HTTPS は、通常の DNS クエリと応答を HTTPS 暗号化の内部で伝送するため、経路を監視している者(企業のセキュリティツールを含む)は、どの名前が解決されているかを判別できなくなります。

通常の解決プロセスでは、デバイスが再帰的リゾルバーにアドレスを問い合わせ、リゾルバーは応答が得られるまで一連のネームサーバーにクエリを送信します。ネットワークチームは、ネットワークの状態を監視し、解決パスを最適化するためにこれらのクエリを分析しており、多くの組織では、DNSセキュリティ戦略の一環としてこれらを検査しています。

このトラフィックを暗号化することで、ネットワーク経路上での盗聴からユーザーを保護できますが、企業ネットワーク上では、サイバーセキュリティソリューションによるDNSクエリの検査が妨げられ、クエリの内容に基づくルーティングがはるかに困難になる可能性があります。また、解決処理が少数のパブリックリゾルバーに集中するため、1つの障害が発生しただけで、はるかに多くの人々に影響が及ぶ可能性があります。

two birds on birdhouse Read article
さらに詳しく読む

DNS over HTTPS: what, why, and who cares

Encrypting DNS queries and responses over HTTPS has long sparked robust debate, with interest from numerous stakeholders. Learn more with BlueCat.

8 min Blog
続きを読む

· 04 — 攻撃者がオープンDNSをサービス拒否(DoS)アンプとして悪用する方法

DDoS攻撃は、どのようにDNSを武器として利用するのですか?

攻撃者がDNSを利用する理由は、その設計上オープンであり、クエリの生成にコストがかからず、偽装も容易であるためです。 オープンなリゾルバを経由して送信されるなりすましクエリは、DNS サーバーを増幅器に変え、被害者に、それを引き起こしたリクエストよりもはるかに大規模な応答を大量に送りつけます。

DDoS 攻撃には 3 つの形態があります。サーバー、ファイアウォール、またはロードバランサーのリソースを枯渇させるプロトコル攻撃、一見正当に見えるリクエストを送信して Web サーバーをクラッシュさせるアプリケーション層攻撃、そして偽装されたパケットの洪水攻撃です。侵害されたコンピュータや IoT デバイスからなるボットネットが攻撃のボリュームを供給しており、その数は数十万ホスト以上に及ぶこともあります。

DNSは、常に開放された状態を維持する必要があり、リゾルバーがその役割を果たすためにすべてのリクエストを処理しなければならないため、攻撃者にとって魅力的な標的となっています。また、ほとんどのセキュリティチームはこのプロトコルを当然のこととして捉え、監視を行っていないため、まさにその隙を攻撃者は狙っているのです。

70:1 増幅率

攻撃者が送信する約80バイトごとに、DNSは約5.6キロバイトの攻撃トラフィックを生成する可能性があります。

Presenter at whiteboard explaining “DNS as weapon” with DDoS attack diagram and distributed denial of service notes Read article
さらに詳しく読む

How DDoS attacks use DNS as a weapon

Bad actors know that DoS and DDoS attacks can use DNS as a weapon to cause spectacular web crashes that bring critical business services to their knees.

7 min Blog
続きを読む

当社は、DNS、DHCP、IPAMをBlueCat Integrityに統合する企業チームと連携しています。30分間の電話相談で、お客様のネットワークのニーズを評価するお手伝いをいたします。


· 05 — エンタープライズ全体で DNS を可視化するためにプラットフォームに必要なもの

DNSの可視化とトラブルシューティングのためのプラットフォームにおいて、チームはどのような点を重視すべきでしょうか?

中核となる要件は、すべてのサーバーからの DNS データを 1 つの検索可能な場所に集約し、クライアント、ネットワーク、サーバー間の経路に沿ってクエリを追跡できることです。 この2つが揃わなければ、感染や設定ミスを明らかにするパターンは、個々のログの中に埋もれたままになってしまいます。

あるエンドポイントからの持続的な NXDOMAIN 応答は、マルウェアによるビーコン送信や、偵察および横方向の移動を示唆している可能性があります。一方、同期がずれたゾーンでは、一部のユーザーには NXDOMAIN が返され、他のユーザーには正しい応答が返されます。適切なログがあれば、こうした失敗した応答は貴重な情報源となります。

同期がずれてしまったゾーンについては、イースト-ウエストトラフィックを可視化できなければ、トラブルシューティングが困難です。

Four pastel speech bubbles with question marks, symbolizing unanswered DNS queries and NXDOMAIN responses Read article
さらに詳しく読む

What you can learn from an NXDOMAIN response

At a basic level, an NXDOMAIN response means “that site does not exist.” But it can also provide critical clues about your network’s security.

5 min Blog
続きを読む

· 06 — 1つのレコードがレイヤー2ハードウェアとレイヤー3アドレスをどのように結びつけるか

企業チームは、スプレッドシートを使わずに、レイヤー2およびレイヤー3にわたってデバイスを追跡するにはどうすればよいですか?

彼らは、MAC アドレスや IP アドレスをスプレッドシートではなく、単一の記録システムに保管しています。 MAC アドレスはレイヤ 2 でのハードウェアを識別し、IP アドレスはレイヤ 3 でのネットワーク接続を識別するため、この 2 つを関連付けることで、チームはデバイスレベルでトラブルシューティングを行うことができます。

LAN では、ARP がIPv4 アドレスを MAC アドレスにマッピングすることで2 つのレイヤーを橋渡ししており、IPv6 ではネイバーディスカバリが同様の役割を果たしています。大企業では数百万もの MAC アドレスや IP アドレスを管理する必要がありますが、依然としてスプレッドシートで IP アドレスを追跡し、MAC アドレスを見落としているケースがあり、これが重大な運用リスクを生み出しています。

BlueCat Integrityは、DNS、DHCP、IPAMを統合し、デバイス、ユーザー、IPアドレスの関係に関する唯一の信頼できる情報源を提供します。そのAddress Managerを使用すると、管理者はMACアドレスを記録し、それらをMACプールにグループ化し、ネットワーク全体で各MACアドレスをIPアドレスに関連付けることができるため、デバイス単位でのトラブルシューティングが可能になります。

Network device Ethernet ports with connected cables and status LEDs, illustrating IP and MAC addressing in a physical network Read article
さらに詳しく読む

MAC address vs IP address: What’s the difference?

MAC address vs IP address: One is a unique hardware identifier, while the other identifies a device's network connection. Learn more with BlueCat.

6 min Blog
続きを読む
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button Read article
統合DDI

Integrity

Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.

9 min Page
完全性を確認

· 07 — 転送パス

コアネットワークサービスのトラブルシューティングをレイヤーごとに容易にするには、どのアプローチが適切でしょうか?

適切な出発点は、問題がどのレイヤーで発生しているかについての混乱、DNSトラフィックの可視性の欠如、手作業によるアドレスの追跡など、チームが現在直面している課題によって異なります。以下の各アプローチは、これらの課題のいずれかに対処するものです。

PATH 01
各チームは、同じサービス停止を異なる表現で説明している

インシデント発生前に各レイヤーについて合意しておく

7つのレイヤーをトリアージの共通言語として使用し、障害が発生したレイヤーによって特定されるようにします。ランブックではARPとDNSを区別し、ARPが機能しなくなるとDNSも動作しなくなることを覚えておいてください。
References: · 01, · 02
PATH 02
ユーザーやブラウザは、すでに HTTPS 経由でホスト名を解決している可能性があります

暗号化されたDNSの処理方法を決定する

暗号化されたDNSは、後から判明するデフォルトの設定ではなく、ポリシー上の選択として扱うべきです。可視性がより重要な場合は、レスポンスポリシーゾーンを使用して既知のDNS over HTTPSリゾルバーをブロックし、クエリがチームが監視可能なリゾルバー上で処理されるようにしてください。
References: · 03
PATH 03
DNSログは存在しますが、誰もそれを確認していません

攻撃対象領域としてのDNSに注意を払う

DNSログを監視してネットワークが他者への攻撃に悪用されないようにし、どのリクエストの解決を許可するかを制御し、データを一元化してNXDOMAINのパターンを文脈に沿って分析できるようにします。帯域幅を追加したり、悪意のあるクエリを迂回させたりできるインフラストラクチャがあれば、攻撃が発生した際の被害を最小限に抑えることができます。
References: · 04, · 05
PATH 04
IPアドレスはスプレッドシートに記録されており、MACアドレスは追跡されていません

すべてのアドレスを対応するハードウェアに紐付ける

両方を単一のシステム・オブ・レコードに統合し、各MACアドレスがネットワーク全体で関連するIPアドレスに紐付けられるようにします。そうすることで、症状ではなくデバイス自体からトラブルシューティングを開始できるようになります。
References: · 06

よくある質問

OSIモデルおよびその上で動作するサービスについて、エンジニアから最も頻繁に寄せられる質問に対する簡潔な回答です。

本分析で引用されたすべての情報源