Skip to content

DNET_SecurityVulnerabilities

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

SC：脆弱性

概要

用語

基礎

  • 基礎の該当節を参照。

リスク (risk)

  • 目的に対する不確かさの影響で、好機と脅威がある。
  • SCでは、好機ではなく、脆弱性に起因する脅威

※ PMP：リスク・マネジメント（PMP：共通の該当節を参照）

脆弱性 (vulnerability)

SCでの脆弱性は、脆弱性の詳細を参照。

  • 安全性上の弱点

  • 英語では、

    • Vulnerability
    • 俗に、Security Hole

  • ISO 27000では、
    一つ以上の脅威によって付け込まれる
    可能性のある情報資産または管理策(control)の弱点

  • 区分

    • 設備
    • 技術
    • 管理

脅威 (threat)

  • 脅威

  • 情報資産や組織に損害を与える可能性がある、
    脆弱性に起因する望ましくないインシデントの潜在的な原因

  • 区分

    • 災害
    • 障害
    • 人的

管理策(control)

  • リスク (risk)（脅威）を修正する対策のこと
  • しかし、同様に脆弱性を持っている可能性がある。
  • コレを導き出すのがリスク・アセスメント

インシデント (incident)

具現化した脅威、若しくは、その確率。

  • 望まない単独若しくは一連の情報セキュリティ事象

  • 又は予期しない単独若しくは一連の情報セキュリティ事象であって、
    事業運営を危うくする確率及び情報セキュリティを脅かす確率が高いもの。

情報資産

  • 脅威に晒される主な対象。
  • 脆弱性を持っている可能性がある。

脆弱性の詳細

種類と具体例

# 種類 具体例
# 設備面 ・構造上の欠陥
・メンテナンス不備
・入退館設備の不備
# 技術面 ・ネットワーク構成上の欠陥
・ソフトウェアのバグ
・アクセス制御システムの不備
・設定ミス、安易なパスワード
・ウィルス対策の不備
# 管理面 ・方針、既定の不備
・機器、外部記憶媒体の不備
・教育、マニュアルの不備
・インシデント対応計画の不備
・監視体制、監査の不備

識別 / 評価

リスク (risk)的に捉え...。

  • 脅威の該当節を参照。

情報資産、脅威との関係

情報資産の脆弱性に起因するリスク (risk)（脅威）の
顕在化 / 具現化がインシデント (incident) / 損失

詳細（技術的）

ネットワーク

脆弱性（ネットワーク）

「機密性、完全性」、「可用性」に分かれる。

  • 機密性、完全性の侵害

    • ネットワーク、サブネット

      • が分割されていない。
      • 間のアクセス制御が無い。

    • 接続口の問題

      • リピータハブの利用（盗聴可能）
      • 必要以上に多いアクセス・ポイント
      • 誰でも接続可能なスイッチの放置

  • 可用性の低下

    • 処理性能

      • 機器の処理能力、負荷分散
      • ネットワーク帯域幅、負荷分散

    • 冗長化

      • 機器
      • ネットワーク

    • 制限

      • インターネット接続口の帯域制御
      • ネットワーク、サブネット分割
        （ブロードキャスト制限）

対策（ネットワーク）

マップが難しいが、

  • ネットワーク、サブネット分割

    • アクセス制御（機密性、完全性）
    • ブロードキャスト制限（可用性）

  • 接続口（機密性、完全性）

    • 無線LAN廃止

    • セキュリティ対策強化

    • ハブの

      • スイッチ化（機密性、完全性、可用性）
      • 物理ポートのロック（機密性、完全性）

    • インターネット接続口の集約

      • フィルタ（機密性、完全性）
      • 帯域制御等（可用性）

  • 各種可用性の向上（可用性）

    • 冗長化
    • 負荷分散
    • 帯域制限
    • 帯域確保
    • キャパシティ・プランニング

UDP, TCP

  • UDP, TCP（基礎の該当節を参照）

脆弱性（UDP, TCP）

  • 仕様が公開されている（RFC）。

  • IPスプーフィング（脅威の該当節を参照）が可能

  • 暗号化機能が標準で実装されていない（IPv4）。

  • セッション層の仕様

    • DoS系に対する脆弱性がある。
    • ポイズニング系（脅威の該当節を参照）に対する脆弱性がある（特にUDP）。

対策（UDP, TCP）

  • IPスプーフィング（脅威の該当節を参照）対策として、逆引き＋遮断

  • SSH / TLS (SSL) / IPsecなどの導入
    による暗号化（何れもVPNで利用される）

  • 他の脆弱性については、UDP, TCP（基礎の該当節を参照）の
    セッション層の仕様の問題なので、
    上位プロトコル側での対応が必要になる。

電子メール

SMTP脆弱性

オリジナルのSMTPが脆弱（メールの該当節を参照）

  • 非常に簡素な仕組み。

    • 実際にはMSAの機能は無く、
    • MTAは、MUA・MTAを区別しない。
    • すべて、25番ポートで処理する。

  • 平文であり

    • 改ざんが可能
    • 情報漏洩の可能性

  • MTAに脆弱性がある可能性

    • アカウント漏洩（VRFY、EXPNコマンドの脆弱性）
    • バッファ・オーバーフロー（脅威の該当節を参照）の脆弱性

  • 認証の機構を持たないため、
    第三者中継（オープン・リレー）が可能で、
    スパマーの踏み台として機能し得る。

    • 様々なスパム・メール（SC：脅威 - DoS攻撃の該当節を参照）を送信する。
    • 結果として、ブラックリストに登録されてしまう。

POP3脆弱性

  • メールが平文
  • 認証のクレデンシャルが平文

対策（電子メール）

主に、スパムメール対策

  • 送信時

    • OP25B (Outbound Port 25 Blocking)

      • ISPメールサーバを経由していないアウトバウンドTCP 25番ポートの通信を遮断する。

      • 第三者中継（オープン・リレー）対策後の、ボットなどによる直接送信を防止する。

      • ただし、以下の送信はOP25Bの影響を受けない。
        ・固定IPからの送信
        ・SMTP-AUTHで認証済ノードからの送信

    • MUA

      • Sender IDアカウントをSMTP AUTHで認証
        （何れもメールの該当節を参照）

  • 受信時

    • MTA
      各種、中継処理に対する制限（ホワイトリストやブラックリストを利用）

      • ブラックリストに含まれるMTAからの通信を遮断

      • ホワイトリストに含まれないMTAからの通信を遮断

      • 逆引きが出来ないMTAからの通信を遮断

      • 第三者中継（オープン・リレー）を許可しているMTAからの通信を遮断

      • Sender ID、SPF、DKIM、DMARCなどの送信元ドメイン認証（メールの該当節を参照）を
        使用して検証されないMTA（ドメイン）からの通信を遮断

      • 経路の暗号化も可能
        STARTTLS (25 → 587)
        SMTP over SSL/TLS (25 → 465)

    • MUA

      • スパムメールと思われる通信を遮断
        シグネチャが該当する通信を遮断（シグネチャ・マッチング）
        学習した特徴に該当する通信を遮断（ベイジアン・フィルタリング）

      • クレデンシャルと経路の暗号化
        POP3 → APOP (クレデンシャル)
        POP3 → STARTTLS (110 → 110) (経路)
        POP3 → POP3 over SSL/TLS (110 → 995) (経路)
        SSHポート・フォワーディング (110 → 22) (クレデンシャルと経路)

  • 送受信時

    • MUA
      • S/MIMEによる署名と暗号化（メールの該当節を参照）
      • PGPによる署名と暗号化（メールの該当節を参照）

  • 構成

    • MTAの脆弱性対策

      • 最新バージョン、パッチ適用
      • VRFY、EXPNコマンドの無効化
      • ウィルス対策ソフトの導入

    • MTAの構成

      • 社内向けはイントラネット上に配置
      • 社外向けはDMZ上に配置

    • 経路

      • 送信：社内向けMTA → 社外向けMTA → ISPのMTA
      • 受信：ISPのMTA → 社外向けMTA →★→ 社内向けMTA
        ★に「メール検査型サンドボックス（脅威の該当節を参照）」を配置する。

参考（電子メール）

  • メール - マイクロソフト系技術情報 Wiki > 認証関連
    メール

DNS

脅威にも書いたけど。

脆弱性（DNS）

  • ゾーン転送によって情報が抜かれる。

    • 管理情報 (サーバ名や IP アドレス等)が漏洩、悪用される。
    • コレらが外部に流出することで、組織のサーバやネットワーク構成を推測され、
      セキュリティに対する、潜在的な脅威の増加につながる可能性がある。

  • セッション層の仕様

    • DoS系に対する脆弱性がある。
    • DNSポイズニング（脅威の該当節を参照）に対する脆弱性がある（特にUDP）。

  • オープン リゾルバによる

    • 踏み台利用
    • 不正なリクエストによるダウン

対策（DNS）

  • 乗っ取り対策

    • 最新バージョン＋パッチ適用
    • バナーの非表示化

  • ゾーン転送先のサーバを制限する。

    • 外部DNSと内部DNSに分割し、外部DNSには内部のゾーン情報を登録しない。
    • インターネットからのゾーン転送要求をフィルタリングする。
    • セカンダリDNSからのゾーン転送要求のみ許可するように設定する。

  • DNSポイズニング（脅威の該当節を参照）のリスク低減

    • DNSキャッシュ時間を短くする。

    • 組織内

      • コンテンツ、キャッシュ・サーバを分割。
      • キャッシュ・サーバ利用を組織内に限定する。

    • 組織外

      • 再帰問合せ（DNSサーバの該当節を参照）の無効化
      • 送信元ポートのランダム化、TxIDの推測を困難にする。
      • DNSSEC（DNS Security Extensions）を導入する。

  • オープンにしない（オープン リゾルバ）

    • キャッシュサーバをインターネットからアクセスさせない。
      DNS amp攻撃（脅威の該当節を参照）と言うDoS攻撃の踏み台にならないようにする。

    • コンテンツ サーバとキャッシュ サーバを分割し、

      • 外部キャッシュ サーバは内部コンテンツ サーバのクエリにのみ対応。
      • 若しくは、クライアントと、問い合わせ数を制限する。

  • その他

    • DNSSEC (DNS Security Extensions)
      ゾーン情報改ざん、DNSポイズニング（脅威の該当節を参照）の防止

      • ゾーン内のリソースレコードを、秘密鍵で署名し、電子署名を作成。
      • また、コンテンツ サーバは電子署名付きの応答を返す。

    • ゾーン・レコードの改ざん防止

      • SOAレコードのシリアル番号はDNS設定内の更新を識別できる。
      • RFC2845: DNSにおける秘密鍵のトランザクション認証(TSIG)
        動的ゾーンを更新できる人を制限するために使用できる。
        ・更新要求が許可されているエンドポイントの特定と認証。
        ・共有秘密鍵と一方向ハッシュ関数を使用する。

    • EDNS0対応
      昨今、IPv6、DNSSEC、SPF、DKIMなどの普及によりDNSデータは拡大傾向で、
      512以上のデータ送信を、TCPフォールバックでなく、UDPパケット拡張で対応。

HTTP、Webアプリ

HTTP、Sessionの脆弱性、対策

  • セッション・ハイジャック系（脅威の該当節を参照）
  • 認証関連
    • 基本認証、Forms認証は、HTTPSで経路の暗号化が必要
    • , etc.

サーバ設定・実装の脆弱性、対策

各種、技術的な脅威（SC：脅威 の該当節を参照）への対応。

  • 乗っ取り対策

    • 最新バージョン＋パッチ適用
    • バナーの非表示化（HTTPヘッダ）
    • アクセス許可の設定

  • 不要な機能、コマンドの無効化

    • デフォルト・ページの配置とディレクトリ参照禁止
    • HTTPメソッド（PUT、TRACE）
    • エラーメッセージ送信機能の抑止

  • 最後はIPSの導入

アプリ仕様・実装上の脆弱性、対策

各種、アプリケーション脆弱性（脅威の該当節を参照）への対応

  • インジェクション系
  • 最後はWAFの導入

移行メモ

  • 「オープン リゾルバによる踏み台利」は書き掛けと判断し「踏み台利用」とした。
  • 「外部DNSには内部のソーン情報を登録しない。」→「ゾーン情報」に正した。
  • 元 Wiki の見出し「脆弱性の」は書き掛けであり、 配下が脆弱性そのものの説明であるため「脆弱性の詳細」とした。
  • 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所 （「基礎」「脆弱性 (vulnerability)」「脅威 (threat)」「識別 / 評価」 「UDP, TCP」など）は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
  • 同名の見出しが複数あり GitHub Wiki でアンカが衝突するため、括弧で文脈を補って一意にした （「脆弱性（ネットワーク）」「対策（ネットワーク）」「脆弱性（UDP, TCP）」 「対策（UDP, TCP）」「対策（電子メール）」「参考（電子メール）」 「脆弱性（DNS）」「対策（DNS）」）。
  • マイクロソフト系技術情報 Wiki（techinfoofmicrosofttech.osscons.jp）への URL リンクは、移行済みの VPN / メール / DNSサーバ / 認証基盤 に張り替えた。
  • PukiWiki のページ内アンカ（#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名 の該当節を参照）」の形に置き換えた。
  • 未移行のページはファイル名を予約し、TODO.md に記録した。

Tags: 移行, 資格, SC, 脆弱性, リスク, 脅威, インシデント, 情報資産, ネットワーク, SMTP, POP3, DNS, DNSSEC, WAF

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally