CISSP合格ノート・CBK#04 アプリケーションおよびシステムの開発(Applications & Systems Development Security)・リモートワーク

CBK#04 アプリケーションおよびシステムの開発(Applications & Systems Development Security)

go to menu page

CBK#04 アプリケーションおよびシステムの開発(Applications & Systems Development Security)

4.1. セキュリティ原則

機密性 (Confidentiality)

├ 直接的な損失（バックドア、ウィルスなど）
└ 間接的な損失（機密情報の無許可の開示による間接的な損害など）

完全性 (Integrity)

├ プログラム、システム、データ
└ 信頼関係（公式、非公式なサイト等との信頼関係）

可用性 (Availability)

└ プログラム、データ、処理、リソース

4.2. マルウェア（悪意のあるソフトウェア）とウィルスの定義 (Malware and Virus Definition)

悪意のあるソフトウェア (Malware):

├ システムへの不正侵入、セキュリティポリシーの侵害、不正コードや破壊的コードの送り付けを目的として設計された、ソフトウェアまたはプログラム。
└ バックドア、改竄、ＤＤｏＳ(Distributed Denial of Service:分散型サービス不能攻撃)、デマ情報、論理爆弾、プランク（嫌がらせ）、ＲＡＴ、トロイの木馬、ウィルス、ワーム、ゾンビなど。

4.3. データベースシステムとデータベース管理 (Database systems and database management)

データベースのタイプ (Types of databases):

├ 階層型(Hierarchical)
├ メッシュ(Mesh)
├ オブジェクト指向(Object oriented)
└ リレーショナル(Relational)

データベース管理システム (ＤＢＭＳ: Database Management System)

├ 様々なタイプのユーザがアドホッククエリを使って、大きな構造的なデータセットを管理するためのプログラム群。
├ 構造化された大量のデータセットを管理
├ 複数のユーザにデータアクセスを提供
└ データの完全性を実現

ＤＢＭＳの条件

├ トランザクションの持続
├ フォルトトレーランス（対障害性）と復元
├ 複数ユーザによよる共有
└ セキュリティ管理

セキュリティに関する問題点

├ データの管理が可能
├ デッドロックの回避（２つ以上のプロセスが、それぞれ相手が何かするのを待機し、前に進めない膠着状態。）＜完全性＞
└ アクセス制御により認証されたユーザだけが許可された行動をとる事ができる許可された活動。（最小特権を実現するための機能）　＜機密性＞

データベース (Database):

└ 意味のある方法で保存されたデータの集合で、必要に応じて複数のユーザやアプリケーションがアクセスし閲覧し、データの更新を行うことが出来る。

4.3.1. データベース用語 (Database terms)/jargon

レコード (Record):

 └ 関連するデータアイテムの集合

ファイル (File): 

 └ 同じタイプのレコードの集合

データベース (Database):

 └ 相互に参照されるファイルの集合

ＤＢＭＳ (Data Base Management System):

 └ データベースを管理しコントロールする

ベースリレーション (Base relation):

 └ データベースに保存されたテーブル

タプル／レコード (Tuples/Record):

 └ データベース内の行

属性(Attribute):

 └ データベース内の列

主キー(Primary key):

 └ 行を一意に決める列

ビュー(View):

 └ データベース内に定義された仮想的な関係で、サブジェクトが閲覧できるデータをコントロールする。

外部キー(Foreign key):

 └ あるテーブルのある属性が他のテーブルの主キーになっている。

セル(Cell):

 └ 行と列の交差。

スキーマ(Schema):

 └ データベースを表すデータ。

データディクショナリ(Data dictionary):

└ データエレメントとその関係の中央のリポジトリ。

濃度(Cardinality):

└ リレーション内の行数。

度(Degree): 

 └ リレーション内の列数。

ドメイン(Domain): 

 └ ある属性が取りうる値の集合。

4.3.2. データベースモデル (Database models)

リレーショナルデータモデル(Relational data model) :

├ 属性(列)とタプル(行)を使用し情報を格納・整理する。
└ 主キーがレコード内の全てのデータを対応する値に対応づけるフィールドである。

階層型データモデル(Hierarchical data model) :

├ レコードとフィールドを論理木構造で関係づける。
├ 子は1つでもよく、複数でもなくてもよい。
└ 一対多の関係をマッピングする際に有用。

分散型データモデル (Distributed data model) :

├ 複数のデータベースにデータが保存されているが、論理的にはつながっている。
└ それぞれのデータベースは別々の管理者が管理できるが、全体の論理的データベースは1人もしくは1つのグループが管理しなければならない。

4.3.3. リレーショナルデータベースのコンポーネント:

データ定義言語(ＤＤＬ: Data Definition Language):

└ データベースの構造とスキーマを定義する。

構造(Structure):

└ テーブルサイズ、キープレースメント、ビュー、データエレメントリレーションシップ。

スキーマ(Schema):

└ 保存され操作されるデータのタイプとプロパティ。

データ操作言語(ＤＭＬ: Data Manipulation Language):

└ ユーザがデータベースを閲覧、操作、使用することができるコマンド全て。

クエリ言語(ＱＬ: Query Language):

└ ユーザがデータベースにリクエストをすることができる。

レポートジェネレータ(Report Generator):

└ ユーザが定義した形式でデータの印刷を行える。

4.3.4. データディクショナリ (Data dictionary)

データエレメントとそのリレーションシップの中央のリポジトリ。
└ データエレメント、スキーマオブジェクト、参照キーの集合。
スキーマオブジェクト(Schema objects)：
└ テーブル、ビュー、インデックス、プロシージャー 関数、トリガを含む。

4.3.5. キー (Keys)

主キー(Primary key):

├ テーブル内でユニークに識別し、テーブル内の個々のタプルもしくは行を明らかに指し示す。
└ テーブル内の候補キーのサブセットである。

外部キー(Foreign key):

└ 他のリレーション内の主キーに相当する、あるリレーション内の属性(行)。

4.3.6. 完全性 (Integrity)

同時性問題(Concurrency problems):

└ 異なるサブジェクトが最新の情報を得られるようにする。

意味整合性(Semantic integrity):

├ 構造的・意味的なルールが守られるようにする。 
└ これらのルールはデータ型、論理値、一意性制約、オペレーションに関係し、データベース構造に悪影響を及ぼす。

参照整合性(Referential integrity):

└ 存在しないレコードやNULL 値の主キーへの参照をしているレコードを持たないようにするメカニズム。

エンティティー整合性(Entity integrity):

└ 属性がNULL の場合。

ロールバック(Rollback):

└ 現在のトランザクションを終了させ、データベースに対する更新を全てキャンセルする文。

コミット(Commit):

└ トランザクションを終了させ、そのユーザが行った全ての更新を実行する。

チェックポイント(Checkpoint):

└ システムの不具合が生じたときやエラーが検知されたときに、ユーザがいつでもシステム障害前の時点に戻ることができる。

4.3.5 データベースセキュリティ問題(Database security issues)

集約(Aggregation):

└ 特定の情報にアクセスするクリアランスや許可がユーザにないが、この情報の構成要素へのアクセスが許可されている場合、このユーザは残りの見当をつけることができ制限された情報を得る

推論(Inference):

├ サブジェクトがアクセスを制限されている情報を、アクセスできるデータから推定するときに起きる。
└ 低いセキュリティレベルのデータが、高いセキュリティレベルのデータを間接的に表すときに見られる。

内容依存アクセス制御(Content-dependents access control):

└ アクセス制御を決めるときにファイルの内容を見る。 このタイプのアクセス制御は処理のオーバーヘッドが高いがより細かいコントロールができる。

セル隠蔽Cell suppression):

└ 推論攻撃に使用されうる情報を含んだ特定のセルを隠したり見せなかったりすること。

パーティショニング(Partitioning):

└ データベースをいくつかの部分に分け、許可されていない者がデータを集めて推論したり発見したりすることを難しくする。

ノイズと混乱(Noise and perturbation):

└ 攻撃者を誤った方向へ誘導したり混乱させたりして実際の攻撃を意味のないものにするために、偽の情報を挿入する技術。

データベースビュー(Database views):

└ 1つのグループや特定のユーザに特定の情報を閲覧することを許可し、他のグループには全く許可しない。

ポリインスタンス (Poly instantiation):

└ リレーションにおいて同じ主キーのタプルを含むことができ、それぞれのインスタンスはセキュリティレベルで識別される。

ＯＬＴＰ／オンライントランザクション処理(On Line Transaction Processing):

└ 問題を監視し、起きたときに適切に対応するメカニズムを提供する。

２相コミットサービス(Two-phase commit service):

└ 全てのデータベースが受け入れて更新をするまでトランザクションが完了しない

データウェアハウジング(Data warehousing):

├ 複数のデータベースから得たデータを組み合わせて大きなデータベースにし、完全な情報取得とデータ分析を行う。
├ レポーテイングおよび分析の為に最適化される。
└ データの相関関係を見えるようにする。データマイニングにより意思決定をサポート。
└ データの相互関係を定義しメタデータを生成する。

データマイニング(Data mining):

└ データウェアハウス内のデータをより有用な情報にする処理。

メタデータ(Metadata):

├ データマイニングツールによって作成されたデータで、関連性、相関を見つけるためのもの。
├ リソースの体系的な管理が可能なので、情報検索が向上する。
└ 利点
├ データ間の目に見えない関連性を明確にする。
└ 無関係に見えるデータを関連づける事ができる。

オブジェクト指向データベース(ＯＯＤＢ: Object-Oriented Data Bases):

├ コードと分析の再使用が簡単で、保守の手間が省けると言う特徴がある。 
├ 問題の分析からデザインや実現への移行が容易である。
└ 主要な短所としては、ラーニングカーブが急であること、開発と運用のためのハードウェア・ソフトウェアのオーバーヘッドが高いことが挙げられる。

オブジェクトリレーショナルデータベース(Object Relational Databases):

└ オブジェクト指向とリレーショナル技術の特徴を組み合わせる。

4.4. システムライフサイクルのフェーズ / ソフトウェアライフサイクル
(System life cycle phases / Software life cycle)

4.4.1. 開発プロセス (software life cycle development process)

プロジェクト開始(Project initiation):

├ プロジェクト定義の構想
└ 提案

機能デザイン分析と計画　(Functional design analysis and planning)

├ 要件を明らかにし、定義する。
└ システム環境の仕様の決定。

システムデザイン仕様(System design specifications)

├ 機能デザインレビュー
├ 機能分析
├ 詳細計画の導入
└ コードデザイン

ソフトウェア開発 (Software development)

└ ソフトウェアの開発とプログラミング

インストール (Installation)／実装 (implementation)

├ 製品のインストール
└ テストと監査

運用 (Operational)／保守 (maintenance)

└ 製品の変更、修正、マイナーな変更

廃棄 (Disposal)／更新と入れ替え (Revision and replacement)

└ 更新や全ての入れ替えによって製品を変更

4.4.2. ウォーターフォールモデル (The Waterfall Model)

├ システム要件 (System requirements)
├ ソフトウェア要件 (Software requirements)
├ 分析 (Analysis)
├ プログラムデザイン (Program design)
├ コーディング (Coding)
├ テスト (Testing)
└ 運用と保守 (Operations & Maintenance)

4.4.3. Ｖ＆Ｖを組み入れた修正版ウォーターフォールモデル
(Modified Waterfall Model incorporating V&V)

├ システム実現可能性 (System feasibility)     ⇒　妥当性確認 (validation)
├ ソフトウェアプランと要件 (Software plans & requirements)     
    ⇒　妥当性確認 (validation)
├ 製品デザイン (Product design)     ⇒　検証 (verification)
├ 詳細デザイン (Detailed design)     ⇒　検証 (verification)
├ コーディング (Coding)     ⇒　単体テスト (unit test)
├ 製品のインテグレーション (Integration Product)     
    ⇒　検証(verification)
├ 実装(Implementation)     ⇒　システムテスト(system test)
└ 運用と保守(Operations & Maintenance)     ⇒　妥当性再確認(revalidation)

4.4.4. セキュリティ問題

├ システム開発のそれぞれのフェーズでセキュリティが考慮されなければならない。
├ セキュリティは開発の最後で取り扱ってはならない。なぜならコスト、時間、手間がかかり機能が欠けるからである。
├ 職務分離が、ロール、環境、製品開発に関する機能において実践されなければならない。
├ プログラマーは作成されているコードに直接アクセスできないようにする。
├ システム内のセキュリティメカニズムのテストと評価に関する証明。
├ システムとそのセキュリティレベルに関するマネジメントの正式な認定。
└ 変更に関しては承認を得、テストし、記録しなければならない。 そしてその変更はシステムのセキュリティレベルやセキュリティポリシーの実施能力に影響を与えてはならない。

4.4.5. 変更管理のサブフェーズ (Change control sub-phases)

├ リクエスト管理 (Request control)
├ 変更管理 (Change control)
└ リリース管理 (Release control)

4.4.6. 変更管理のプロセス(Change control process)

├ 変更の正式なリクエストをする。
├ リクエストを分析する。
├ 実行計画を立てる。
├ 実行のコストを計算する。
├ セキュリティに対する影響をレビューする。
├ 変更リクエストを記録する。
├ 承認を得るために変更リクエストを提出する。
├ 変更の開発。
├ 製品のコーディングを行い、機能の追加や削除を行う。
├ これらのコードの変更を正式な変更リクエストにリンクさせる。
├ テストと品質承認のためにソフトウェアを提出する。
├ 品質が適切な物になるまで繰り返す。
└  バージョンの変更を行う。

4.4.7. コンフィギュレーション管理 (Configuration management)

├ コンフィギュレーションの特定 (Configuration identification)
├ コンフィギュレーション管理 (Configuration control)
├ コンフィギュレーション状況説明 (Configuration status accounting)
└  コンフィギュレーション監査(Configuration audit)

4.4.8. ＣＭＭ／ソフトウェアプロセス成熟度モデル (Software Capability Maturity Model)

Level 1: 初期レベル(Initiating)

└ 有能な人々と英雄; プロセスは正式でなく場当たり的

Level 2: 反復できるレベル(Repeatable)

└ プロジェクト管理プロセス; プロジェクト管理の実践が制度化されている。

Level 3: 定義されたレベル(Defined)

└ エンジニアリングプロセスと組織のサポート; 技術的な実践がマネジメントの実践と統合され制度化されている。

Level 4: 管理されたレベル(Managed)

└ 製品とプロセスの改善; 製品とプロセスが量的にコントロールされている。

Level 5: 最適化されたレベル(Optimized)

└ プロセスの改善の継続; プロセス改善が制度化されている。

4.5. アプリケーション開発方法論 (Application Development Methodology)

4.5.1. 言語のタイプ (Types of languages)

マシン語(Machine language):

└ コンピュータやプロセッサが直接理解して処理できる。

アセンブリ言語(Assembly language):

└ システムは直接理解できないので処理されてマシン語に変換される。

高級言語(High-level language):

└ システムは直接理解できないので処理されてマシン語に変換される。

4.5.2. プログラム (Programs)

インタープリタ型プログラム(Interpreted programs):

└ プログラムによって命令が1つずつ読まれ解釈される。

コンパイルされたプログラム(Compiled programs):

└ 高級言語で書かれコンパイラと呼ばれるプログラムによってマシンが読める形式に変換される。

4.5.3. オブジェクト指向プログラミング (ＯＯＰ: Object-Oriented Programming)

├ クラスおよびクラス内のオブジェクトを使用する。
├ クラスが定義されると、作成されたクラスのメンバーやインスタンスのために属性が再利用される。
├ オブジェクトは属性値をカプセル化する。
├ 情報は1つの名前の元にパッケージ化されて他のオブジェクトによって1つのエンティティーとして再利用される。
├ オブジェクトには共通部分が存在する。
├ 他のコンポーネントと相互作用するインターフェイスオブジェクトにはプライベートな部分が存在する。
└　実際にどのように動くか、リクエストされたオペレーションをどのように実行するかインターフェイスから入力されたメッセージが、リクエストされて実行されるオペレーションやメソッドを特定する。

情報隠蔽(Information hiding)：

└ 他のコンポーネントは、それぞれのオブジェクトが内部でどのように動くかについて知っている必要はない。

抽象化(Abstraction)：

└ 不必要な詳細を隠し、重要な継承プロパティが吟味・レビューされるようにする機能。

4.5.4. オブジェクト指向のフェーズ (Phases of object orientation)

オブジェクト指向要件分析 (ＯＯＲＡ: Object-Oriented Requirements Analysis)：

└ オブジェクトのクラスとその相互作用を定義する。

オブジェクト指向分析(ＯＯＡ: Object-Oriented Analysis)：

└ オブジェクト指向の概念においては、問題ドメイン内の特定の問題を理解しモデリングする。

ドメイン分析(ＤＡ: Domain Analysis)：

└ 与えられたドメイン内の全てのアプリケーションに共通するクラスとオブジェクトを特定する。

オブジェクト指向デザイン(ＯＯＤ: Object-Oriented Design)：

└ オブジェクトはモジュールの基本単位; オブジェクトはクラスのインスタンス。

オブジェクト指向プログラミング(ＯＯＰ: Object-Oriented Programming)：

└ 他のプログラミングアプローチのようなタイプや変換ではなくオブジェクトやメソッドの採用を強調する。

4.5.5. オブジェクト指向プログラミング（ＯＯＰ）の特長

カプセル化(Encapsulation):

└ 内部データとオペレーションを隠す。

相性(Polymorphism):

└ オブジェクトのコピーを作成し、これらのコピーに変更を加える。

Poly instantiation:

└ ブジェクト内のデータ間の違いにより、低いセキュリティレベルのサブジェクトが高いセキュリティレベルの情報を知ることのないようにする。

継承 (Inheritance):

└ プロパティと属性を共有する。

重継承 (Multiple inheritance):

└ あるクラスが複数の親クラスから動作特性を継承する状態。

委譲 (Delegation): 
└ ブジェクトからのリクエストを他のオブジェクトに転送もしくは委譲すること。この転送は、リクエストを受け取ったオブジェクトがリクエストにサービスするためのメソッドを持ってない場合に必然となる。

4.5.6. データモデリング (Data Modeling)

構造化分析アプローチ (Structured analysis approach):

└ アプリケーション内の全てのオブジェクトとサブジェクトを見て、関係、コミュニケーションパス、継承プロパティーをマッピングする。

データモデリング (Data modeling):

└ データが処理される方法やコンポーネントとは独立してデータを考える。

4.5.7. データ構造 (Data Structures)

データ構造(Data Structure):

└ データエレメント間の論理的関係の表現。

凝集性(Cohesive):

└ 凝集性のあるモジュールは、他のモジュールの助けをほとんどもしくは全くなくてもあるタスクを実行できる。

低凝集性(Low Cohesion): 
└ 分散していて複数のタスクを実行する。

高凝集性(High Cohesion): 

├ 1つのタスクに集中する。
└ 最適なプログラミングではできる限り凝集性の高いモジュールを使用するが、異なるモジュールはデータをやり取りしコミュニケートしなければならないため、通常は完全に凝集的にはならない。

結合(Coupling):

└ アプリケーション内モジュール間の相互結合の尺度。

Low Coupling:

└ 独立したモジュール。

High Coupling:

├ 他のモジュールに依存する結合度が低いほど、よりよいソフトウェアデザインである。なぜならモジュールが独立だからである。
└ コンポーネントが独立であるほどアプリケーションが簡潔で、変更やトラブルシューティングが容易である。

4.5.8. オブジェクト管理アーキテクチャー (ＯＭＡ: Object Management Architecture)

オブジェクトリクエストブローカ(ORB: Object Request Brokers):

└ コンポーネント間の全てのコミュニケーションを管理し、異質で分散した環境において相互に作用しあうことを可能にする。

ＣＯＲＢＡ: Common Object Request Broker Architecture:

├ 異なるソフトウェア、プラットフォーム、ハードウェア環境における相互運用性を提供する。
├ 場所や開発者に関わらず、アプリケーションが相互にコミュニケートできるようにする。
└ この互換性を実現するために、ユーザは小さな初期コードとインターフェイス定義言語(IDL: Interface Definition　Language)を開発する。

共通オブジェクトモデル (COM: Common Object Model):

└ プログラム間でのオブジェクトの交換をサポートする。

分散型共通オブジェクトモデル (DCOM: Distributed Common Object Model):

├ ネットワーク環境でオブジェクトを共有するための標準を定義する。
└ 環境内のユーザ、リソース、コンポーネントを一意に識別するために、グローバルでユニークな識別子であるGUID を使用する。

オープンデータベース接続 (ODBC: Open Database Connectivity):

└ 様々なタイプのリレーショナルデータベースへの接続に使われる標準SQLを提供する。

動的データ交換 (DDE: Dynamic Data Exchange):

├ IPC を提供することにより異なるアプリケーションでデータを共有する。
└ ２つのアプリケーション間での直接対話を可能にするコミュニケーションメカニズム。

分散コンピューティング環境 (DCE: Distributed Computing Environment):

├ RPC を元にした、コミュニケーションレイヤを持つ管理サービスの集合。
├ ネットワーク層の上にあるソフトウェアのレイヤで、その上のアプリケーションにサービスを提供する。
├ ユニバーサル一意識別子(UUID)を使用し、環境内のユーザ、リソース、コンポーネントをユニークに識別する。
├  RPC 関数はプログラムを送りネットワーク越しに送信するために準備することによって、引数とコマンドを収集する。
└ DFS(Distributed File Services、分散ファイルサービス) が、全てのDCE ユーザが共有するために使用する単一の統合されたファイルシステムを提供する。

4.5.9. エキスパートシステム /知識ベースシステム(Expert systems/knowledge based systems)

├ 人工知能を使用し人間の知識をエミュレートして問題解決する。
├ 知識ベースとアルゴリズムセットとルールを持ち、知識と入ってきたデータから新しい事実を推論するために使用されるコンピュータプログラム。
├ ルールベースプログラミング(Rule├based programming): 
└ エキスパートシステムの一般的な開発手法である。
├ パターンマッチング(Pattern matching): 
└ if-then ロジックユニットに基づく。
└ 推論エンジン(Inference engine): 
└ 自動的に事実をパターンにマッチングさせ、どのルールが当てはまるかを決定するメカニズム。

4.5.10. 人工神経ネットワーク (Artificial Neural Networks)

├ 脳のニューラル構造に基づいた電子モデル。
└ ニューロンとその回路の基本的な機能を模倣して新しい方法で問題を解決しようとしている。

4.5.11. Java

├ プロセッサに依存しない中間コードであるバイトコードを生成するのでプラットフォームに依存しない。
├ Java 仮想マシンはバイトコードをマシン語に変換する。
└ Java アプレットは、アプレットのアクセスをユーザシステムの特定の領域にのみ制限したサンドボックスを採用したセキュリティスキームを使用しているので、不正やアプレットの不具合から守られる。

4.5.12. ActiveX

├ マイクロソフトの技術で、インターネットユーザがダウンロードして機能やインターネット体験を強化するためのコントロールを書くために使用される。
├ プログラムがどこから来たかをユーザに知らせることによりセキュリティを守っている。
└ 電子証明と信頼された認証局に依存したコード署名技術を使用している。

4.5.13. 不正なコード (Malicious Code)

ウイルス、ワーム、トロイの木馬、論理爆弾等、以下によって検知される:

├ ファイルサイズの増加
├ 予期しない多くのディスクアクセス
└  更新・変更日時の変更

4.5.14. ウイルス (Virus)

他のプログラムを探して自らのコピーを埋め込んで感染するプログラム。
感染したプログラムが実行されると埋め込まれたウイルスが実行され感染が広がる。

ブートセクターウイルス(Boot sector virus):

└ データをブートセクターに移動するか、新しい情報で上書きする。

ステルスウイルス(Stealth virus): 

└ ファイルやブートレコードに施した変更を隠す。

ポリモーフィック型ウイルス(Polymorphic virus): 

└ 自らと異なるが動作するコピーを作成する。

└ ハードディスクのブートセクターおよび実行ファイルに感染する。

セルフガーブリングウイルスSelf-garbling virus:

├ 自らのコードを変造してアンチウイルスソフトウェアから隠そうとする。
└ ウイルスが広まるにつれてコードのエンコード方法が変化する。

4.5.15. ワーム (Worm)

ホストアプリケーションがなくとも自分自身で再生成される自己完結型プログラム。

4.5.16. 論理爆弾 (Logic bomb)

あるイベントが発生したときにプログラムやコードストリングを実行する。

4.5.17. トロイの木馬 (Trojan horse)

他のプログラムとして偽装されたプログラム。

4.6 攻撃(Attacks)

4.6.1. サービス拒否攻撃 (ＤｏＳ: Denial of Service):

攻撃者は被害者の帯域やリソースを消費しシステムのクラッシュを引き起こしたり他のパケットの処理を妨害したりする。

4.6.2. Smurf

３者必要である:

├ 攻撃者、被害者、増幅用ネットワーク攻撃者はパケットヘッダの送信元IP アドレスをスプーフもしくは変更し、ICMP ECHO パケットが被害者のシステムから送信されたように偽装する。
├ このICMP ECHO メッセージは増幅用ネットワークにブロードキャストされ、返答が返される。
└ これにより被害者のシステム・ネットワークは使用できなくなる。
Pingツールが実行されると、応答IPアドレスを含んだICMP(Internet Control Message Protocol)エコー要求パケットが目標のマシンに送信されます。目標のマシンがTCPパケットを受信した場合、Ping要求に認証の応答を返します。
Smurf DoS攻撃の場合は、Pingのパケット応答IPアドレスを、標的となるマシンのIPに偽装させます。このPingはIPブロードキャストアドレス全体に発信されます。その結果、全てのマシンが偽のPingパケットに反応して標的のマシンに応答するため、標的のマシンに過重負荷がかかってしまいます。

この攻撃は、SmurfというDoSツールを使用することから、Smurf攻撃と呼ばれています。
このような攻撃に遭う危険性を抑える手段の一つとして、使用頻度が低かったり必要のないIP-ダイレクトのブロードキャストを無効にしておくという方法があります。OSによっては、マシンがICMPパケットに応答しないよう設定することも可能です。
Smurf アタックの主なターゲットとなるは IRC サーバです。

4.6.3. Fraggle

├ UDP を武器として選択する。
└ 攻撃者はスプーフされたUDP パケットを増幅用ネットワークにブロードキャストし、その返答は被害者のシステムに返される。

sumurf の変種として fraggle があります。 これは ICMP の代わりに UDP を使用します。 この場合、echo、chargen、daytime、qotd の各ポートが応答のトリガとして利用されます。 これらのポートは pingpong アタックでも狙われやすいので、 オフにしておく必要があります。

4.6.4. SYN Flood

├ スプーフされたパケットでSYN メッセージを継続的に送信する。
└ 被害者はこのコミュニケーションソケットに必要なリソースを割り当て、SYN/ACK メッセージを返し、ACK メッセージを待つ。

4.6.5. ティアドロップ攻撃 (Teardrop Attack):

├ 攻撃者は、システムがフリーズもしくはリブートするような非常に小さいパケットを送信する。
└　いくつかのシステムではパケットが大きすぎないかについてはチェックしないが、小さすぎないかについてはチェックしないために起きる。

　断片化されたIPパケットをつなぎ合わせる際の、TCP/IPの実装上の問題を突いた攻撃方法。ネットワーク上にデータを転送するとき、ネットワークによって決められている最大伝送単位（MTU）を超えるようなIPパケットは、複数の小さなIPパケットに分割されます。分割されたそれぞれのIPパケットには、分割される前のパケットのどの部分であるかを示すオフセット情報が含まれています。分割されたIPパケットを受け取った側は、このオフセット情報を元にしてIPパケットを組み立て、元のパケットを復元しようとします。
　Teardrop攻撃では、このオフセット情報を偽造することにより、オフセットが重複するような不正なIPパケットの断片を作成し、ターゲットとなるコンピュータに送信します。受信した側のコンピュータが、重複したIPパケットの断片をうまく処理できないというTCP/IPの実装上の問題を持っていた場合、システムはクラッシュしてしまうことがあります。この攻撃を防ぐためにはTCP/IPの実装上の問題を修正したパッチを当てる必要があります。

4.6.6. 分散サービス拒否攻撃 (ＤＤｏＳ: Distributed Denial of Service):

├ ＤｏＳ攻撃の論理的な拡張。
└ 攻撃者はスレーブ/ゾンビマシンをコントロールするマスターコントローラーを構築する。

4.6.7. DNS DoS 攻撃 (DNS DoS Attacks)

├ 偽のIP アドレスを指す新しいレコードでDNS サーバのレコードを入れ替える。
└ キャッシュ汚染(Cache poisoning)：
└ 実際のレコードを入れ替えるのではなくサーバのキャッシュにデータを挿入する.

＜参考＞

ウイルスの種類

ファイル感染型    マルチパータイト型    ブートセクタ感染
システム感染型    電子メールウイルス    ポリモーフィック型
マクロウイルス    スクリプトウイルス    デマ情報

マルウェアの種類

ウイルス        感染し破壊や改竄を行う。
ワーム        感染し破壊や改竄を行う。自己増殖する。
デマ情報        デマのウイルス情報などのチェーンメール。
トロイの木馬    表面上は有益なソフトウェア、システムの遠隔操作など。
改竄        データやシステムファイルの変更など
バックドア    メンテナンスフックなど。（ソフトウェア等の裏口）
ＲＡＴ        Remote Admin Trojan（バックドア型トロイの木馬）
ＤＤｏＳ        分散型ＤｏＳ攻撃
プランク        嫌がらせ、イースタンエッグ、だファイル材サイズの増加

実行可能モバイルコード
Ｗｅｂアプレット        自動的にロードされ実行される。
ダイナミック電子メール    電子メールメッセージに含まれる、アクティブなスクリプトメッセージ。

モバイルコードからの保護手段
コードの実行場所を検証する。（サンドボックスを使用する。）

Ｗｅｂアプリケーション環境の懸念要素（検知にはＩＤＳが必要）

    • ハッキングの大多数は、アプリケーションレベル
    • HOST、NW、Userに欠陥を生じさせるもっとも簡単な方法
    • 広くアクセス可能
    • ログの無い場合が多い
    • 最低限の侵入検知
    • ファイヤーウォールで防御できない
    • トランスポート層での暗号化かが約にたたない。

ソフトウェア保護手段

    • 既存のシグネチャスキャン
        ◦ 既知のオブジェクト
        ◦ シグネチャの更新
        ◦ 誤検知が多い場合は要注意
・活動の監視
        ◦ 監査
        ◦ 処理、ディスク、通信に関する活動発見的チェック
        ◦ 誤検知
    • 変更検出
        ◦ プログラムやファイルやプロセスに対する変更
        ◦ 新しい実行ファイルの追加（整合性チェックと混同される場合がある。）
        ◦ （誤解）システムの完全性は最初のベースラインが確立される前に既にうしなわれている可能性がある。
        ◦ 誤検知が多い場合は要注意。

ＤＢＭＳの保護手段（ロック機能ＡＣＩＤシステム）

原始性（Atomicity）

└ 全ての変更が有効になるか、またはどの変更も有効にならないこと。

一貫性（Consistency）

└ オーナまたはシステムによって定義された整合性制約を満たしている場合のみ、トランザクションを実行する事ができる。

独立性（Isolation）

└ トランザクション完了しない限りその結果は明らかにならない。
永続性（Durability）
└ 完了したトランザクションの結果は永久に保証される。

ここまで

go to menu page

narto.hatenablog.com