ぎじゅつめも

とある工学系学生が学んだことをメモするだけのブログです。

マルウェア解析等に役立つ評価サイト

某社の方々に役立つサイトを教えていただいたので、まとめておきたいと思います。

 

疑わしいファイルをハッシュで検索したり、実際のファイルをアップロードすることでそのスキャン結果を表示してくれます。スキャンに用いられるのは既存の40種類以上ものウイルス対策製品で、主要なNortonやMaCafeeなども含まれています。また、URL、ドメインIPアドレスに対するスキャンも行ってくれます。

www.virustotal.com

 

  • Threatcrowd

ドメインIPアドレスマルウェアハッシュ値などから、関連するドメインマルウェアをグラフで可視化してくれます。

Threat Crowd | Threatcrowd.org Open Source Threat Intelligence

 

  • IBM X-Force Exchange

IBM X-Forceというセキュリティ調査チームによりサポートされたプラットフォーム。メインページにはトレンドであるbotnetの分布情報やIBM X-Forceからの勧告なども表示されるので、様々な脅威に関する知見が得られます。

IPアドレス、URL、ドメイン、疑わしいプログラムのハッシュ値などで検索をするとその評価情報を表示してくれます。IPアドレスからはwhois情報も表示してくれます。また、面白い機能として最近よく検索されているトレンドも表示されます。

exchange.xforce.ibmcloud.com

5G技術についてのメモ【無線技術/コアネットワーク技術】

5G(第五世代移動通信システム)ではどんな技術が採用される予定なのか、先日某研究開発センタを訪問させていただいた折に教えていただきました。そこでお聞きした内容は全て公開情報だそうなので、ここで簡単にメモしておきたいと思います。

 

今後のICT社会に予期されること

IoTの普及・ユビキタス社会の推進により、全てのモノが無線でつながるようになると考えられます。また、情報端末数の増大により通信ネットワークが取り扱う情報量も大幅に増大することが考えられます。

 

無線アクセス技術

目標性能

今後のICT社会に予期されることを踏まえて、5Gで無線アクセス技術の目標は“大容量化(システム容量1000倍)”、“高速通信(体感100倍)”、“同時接続数の増強(現在の100倍を目指すそうです)”、“低遅延化(無線区間の遅延が現状5ms~10msなので1ms以下へ)”、”低コスト化/省電力化”なのだそうです。

技術コンセプト

比較的低い周波数(UHF)帯は飽和状態にあります。なので、今後は高周波数帯を使うことになります。しかし、高周波数になればなるほど、回折能力(障害物を回り込んで伝搬する能力)が低下して損失率が大きくなる欠点があります。

これを解決する技術が5Gには求められました。

Massive MIMO

これまでの基地局のアンテナ数は、例えばFDD(周波数分割多重)なLTEで2本、TDD(時分割多重)なLTEでも4本or8本程度であり、電波は上空から見て円状に吹かしていました。しかし、5Gでは前述の課題を克服するため、Massive MIMOという概念を導入しました。これはアンテナ数が最大128個にも及ぶ超多素子アンテナです。これにより、電波を言わばビーム状に引き延ばし、指向性を持たせ、情報端末を操作するユーザに直接電波を吹かします。このデジタルビームフォーミング(以下DBF)により損失を減らす試みが行われています。すなわち、今までは基地局を中心にセルを構成していましたが、今後はユーザを考慮した動的なセル(ダイナミック仮想セル)の構築を行うことで快適な通信環境を作り出そうとしているようです。

コアネットワーク技術

技術コンセプト

今まで全てのサービスを同一のアーキテクチャで実現していましたが、サービスごとに要求される品質などは様々です。しかし、サービスごとに通信基盤をいくつも用意するようでは膨大なコストがかかってしまいます。そこで、1つの通信基盤上で複数の要件を同時に満たす技術が求められました。

ネットワークスライス

ネットワークスライスという概念は、1つのネットワークに複数の論理的なネットワークを収容する仮想化技術により実現されるもので、論理的なネットワークをスライスと呼んでいます。仮想化を行う中継器ではスライスごとに異なるプログラムを走らせることができます。

ネットワークスライスにより、例えば低遅延のサービスを利用したいユーザがアクセスしてきた場合、低遅延のスライスにユーザを移動させることで要件を満たすことが出来ます。

インシデント解析のためのログ収集システム【SIEM/Cybereason】

古典的なマルウェア感染等のインシデントの検知/解析は、エンドポイントや中継器といったそれぞれのノード単一での情報に基づいて行ってきました。しかし、DDoSや情報窃取などのマルウェアの振る舞いは、ネットワークを通じて複数のノードにまたがって行われますので、監視したいネットワークにおけるあらゆるノードのログを収集して、総合的に分析(相関分析)する方が好ましいです。これを実現する製品、サービスについて学んだので、後学のためにメモしておこうと思います。

 

ログ収集に基づく異常検知システムの目的

導入の目的は主に以下の2点です。

これらを実現するためには、ログ収集し分析する製品が必要となります。 

 

実際の製品/サービス

ログの収集を行い、分析に応用することができる実際の製品/サービスを紹介していこうと思います。ここで紹介するのはあくまで分析用のものであり、マルウェアを駆除する機能は別途確保する必要があります。

 

Cybereason

各エンドポイントのログデータを収集し、AIを用いた分析を行うことで、サイバー攻撃に加担するプロセスの兆候・現状などをリアルタイムで検出するサービスです。また、ログ収集のために各エンドポイントにはCybereasonセンサを導入する必要があります。

Cybereasonで可視化される情報を具体的に挙げると、マルウェアと疑われるプロセスのファイルのハッシュ値、ファイルへの署名の有無、プロセスの通信ログ、通信先及びファイルの信頼性評価(Reputation)等があります。

Cybereasonソリューションはクラウドベースで展開されており、ログやファイルの評価情報・分析結果などの詳細はブラウザを通してGUIベースで確認できます。

SIEMと違った利点として特に挙げられるのは、プロセスに焦点を置いた振る舞いの詳細を見ることができる点です。欠点としては、エンドポイントのログしか収集できないことが挙げられます。

▼参考リンク

www.softbank.jp

 

 

SIEM

SIEMはSecurity Information and Event Managementの略称です。

SIEM自体は特定のサービスやソフトウェアを指す用語では無く、サーバ、ネットワーク機器、セキュリティ機器、アプリケーション等から得られるログを収集し、異常があった際に管理者に通知する仕組み、機能を指します。実際にSIEMを実装している製品としてはMcAfee SIEMがあり、以後これについて解説します。

様々な製品のログから必要な情報を、統一フォーマットで抜き出して可視化します。主要なネットワーク製品のログ用パーサーはベンダが用意してくれていますが、マイナーな製品のログは運用側でパーサーを作成してログの切り分けを自前で行う必要があります。また、MaCafee SIEMの場合、ソフトウェアとハードウェア一式での提供となっていました。インシデントはその重要度ごとにランク付けされ、必要に応じて管理者にアラートを流すことができます。アラートを出すルールを管理者が設定することも出来る。

利点はネットワークのエンドポイントだけでなく中継ノードからも情報を収集できることです。これによって、インシデントの及ぼしている影響をネットワークの全体像を踏まえて観測できます。具体的にいうと、FW、IDS/IPS、Webプロキシなどの情報も相関的な分析に含めることができるので、攻撃者の偵察から攻撃までのプロセスを可視化できます。例で言うと、FWで空いていないポート群へのアクセス(ポートスキャン)を検知した後に、同様の送信IPアドレスからIDSでディレクトリトラバーサルを検知していれば、それぞれの通信の関連性が見えてきます。

▼参考リンク

www.mcafee.com

 

※補足:単一ノードのログ可視化サービス

CybereasonやSIEMなどは複数ノードのログを総合的に可視化しましたが、単一ノードのログ可視化サービスもあり、Mackerelなどが挙げられます。CPUやメモリの使用率などを時系列で可視化しパラメータが閾値を越えたら通知するアラート機能もあります。

mackerel.io

 

ログ収集システムの併用について

ここで紹介したSIEMとCybereasonのようなものは互いの欠点に補うように併用することもできます。

SIEMで怪しい通信の全体像を把握した後、対象ノード上の詳細なプロセスの振る舞いをCybereasonで観測するといった使い分けができます。

これらのログ収集システムが動的に連携を取る仕組みについては現在のところ把握していませんが、そのうち登場するかもしれません。

 

ログ収集の課題

ログ収集システムは、各所で得られたログを一元化することでその恩恵を得ます。そのため、あまりにもログの量が膨大だと、一元化する先のマシンの性能次第では処理が追い付かなくなってしまいます。そのため、運用者側でのログの取捨選択などが必要となってきます。このジレンマにより、企業によっては、取りたくても取れないログが出てきているようです。

 

ログの外部吐き出しの恩恵

クラッカーは潜入したエンドポイントの情報改ざんを行った場合、 その痕跡を消すべくログの改ざんも試みる場合があります。しかし、適切なタイミングでログを外部へ吐きだしていれば、エンドポイントの改ざん後のログと外部へ吐きだされた正規のログを見合わせることで、改ざんの痕跡発見につながることもあります。

ログ分析に基づくマルウェア解析の過程

ログ収集システムを用いたマルウェア解析を実際に体験して学んだことをメモしておこうと思います。

解析環境はWindowsです。

 

セキュリティオペレーションの流れ

まず、マルウェア解析を含むセキュリティオペレーションの一連の流れを示します。

順序概要 
 1  アラートシステム(Cybereason,SIEM等)が異常検知
 2  異常と検知されたプロセス/ファイルの解析(Cybereason,SIEM等の示すログ情報と異常根拠を元に解析。必要に応じて感染ノードを回収して実ファイルの調査とユーザへの聴取。)
 3  分析後に対象がマルウェアか過検知かの判定
 4  マルウェアの場合、被害状況・現状の確認
 5  対応(マルウェア削除、システムのスキャン、再発防止の仕組み構築、注意勧告、上長や関係部署への通達)

 ここでは、上記の内の2~3に該当するマルウェア解析について述べて行きたいと思います。また、コードの解析はアラートシステムに任せ、ログ情報を元にした解析に焦点を当てます。

 

マルウェア解析

今回はアラートシステムにCybereasonを用いた場合の解析について述べます。

注視するべき要点 

ネットワークフォレンジックの観点から注視すべき要点は以下のものです。

単語概要
場所 IPアドレスと、それが存在する地域についての情報。攻撃の温床となるアドレスは偏っているので、怪しさの指標になる。C&CサーバやbotnetのIPアドレスはスキャンサービスのVirustotal等で調べられる。
時刻  攻撃・異常の発生時刻など。どのタイミングでどのような振る舞いをしているかは分析に重要。
期間 疑わしいプロセスが振る舞う期間。潜伏期間や攻撃期間などはマルウェアの動向を考察する上で参考になる。
方向性 通信が内向きか外向きかという方向性。外部通信であればC&C通信である可能性があり、内向きであれば横への展開(感染拡大)である可能性があるという推測ができる。
ポート トランスポート層でのポート番号。どのようなサービスにアクセスしようとしたか等を知る事が出来る。例えばポートスキャン実行時には複数の宛先ポートが検出される。
 データ量 通信量とも。不自然に大きなデータがやり取りされていれば、情報窃取やマルウェア注入などのインシデントを想起できる。 
頻度 振る舞いの頻度。通信頻度が正規ユーザが行う頻度とかけはなれていた場合、悪意のあるプロセスがバックグラウンドでC&C通信を行っている可能性などが考えられる。 また、不審な振る舞いの頻度が高ければマルウェアであるとの判断につながる。
評価 Reputation。マルウェアハッシュ値IPアドレスドメイン名、URLなどに対する評価。様々なマルウェアスキャン製品・サービスによって裏付けられた評価であり、分析対象がマルウェアか否かを判断する指標となる。 これを行うサービスとしてはVirustotalIBM X-Forceなどがある。
履歴  ログ情報。 プロセスが如何なる振る舞いをしているか、ある端末で起きている事象が他の端末でも起きていないか等の調査に役立てる。
プロセス プロセスの正当性の確認。異常なプロセスが親や子にいないか。プロセスの実行源となったファイルに署名はついているかなどを確認する。
状態

疑わしいプロセスが現段階でどのような状態にあるか。既にマルウェアとしての活動を停止しているのか、現在もまだ動作しているのかなど。 

 

怪しいプロセスの具体的な情報例

上記に記された要点に沿って、実際のマルウェアで観測されがちな特徴を記述します。

ファイルのハッシュが既知のマルウェアと一致

ファイル名は自由に決めることができるため、マルウェア配布者は、マルウェアに無害そうな名前をつけることがあります。しかし、そのファイルの内容までを悪意のないものに偽装するのは難しいことです。そこで、マルウェア解析者は、ファイルの内容を識別するためにハッシュを用います(※本筋から逸れるのでハッシュや衝突に関する説明は省略します)。既知のマルウェアのハッシュと、検知した疑わしいファイルのハッシュが一致すれば、ファイル名が異なっても中身が同じでマルウェアの可能性が高いと判断できます。ハッシュとしてはSHA1MD5がよく用いられるようです。

既知のマルウェアとハッシュが一致するものがあるか検索する際にはVirustotalなどを利用します。

ファイルパスが怪しい

例えば実行ファイルがユーザローカル領域のtempフォルダ配下から実行されている場合などは、ユーザの意図に関わらずマルウェアから実行されている場合があります。

例)Emdiviなど

また、おおよそ正規の実行ファイルはProgramFilesに置かれます。マルウェアの場合、すぐに発見されないようにフォルダの深い階層に設置するような場合があります。

アイコンや名前・拡張子がおかしい

拡張子が.pdf.exeのように2重になされている場合、2重拡張子といい、ユーザに実行ファイルではない偽装を行う意図が考えられます。2重拡張子には、.exeを表示領域から見切れさせるために、.pdf____________.exeと冗長な命名をするようなものもあります。また、実行ファイルにも関わらずドキュメントファイルのアイコンなどを装う場合もマルウェアの可能性があります。

実行ファイルが実行ファイルを作成している

ドロッパー(Dropper)と呼ばれるマルウェア等にありがちな挙動です。ドロッパーは、それ自体にC&C通信などの諜報機能を持ちませんが、実行されると、悪意のある挙動を行うマルウェアダウンローダー等)を作成して子プロセスとして実行します。

目立った諜報活動を行う子プロセスのマルウェアが削除されても、そのマルウェアを作成・実行するドロッパーが生きていればまたマルウェアが作成されるので、ドロッパーも特定して削除する必要があります。

ヒューリスティック分析(振る舞い検知)を行っているCybereason等では、実行ファイルを作成するような動作もマルウェアとして検知してくれるようです。また、仮にマルウェアが検知された場合、解析過程でその親プロセスを辿ることができればドロッパーに行きつくことがあるのでプロセスの親子関係も大事な要素です。

信頼できそうな製作者や製品名だが電子署名がない

ファイルにはその製作者や製品名を記述できますが、その他にも作成元を証明するための電子署名をつけることができます。

マルウェアの作成者は、この製作者や製品名を、偽装したアイコンやファイル名、ダウンロード時の状態に合わせてもっともらしいものに設定します。例えば、Flash Playerの脆弱性につけこんでダウンロードさせたマルウェアの場合、製作者をadobe systems incorporated、製品名をadobe flash player utilityなどとすることがあり、この情報だけだと一見安全そうに見えます。ただし、電子署名までは偽装できないので、この電子署名が無いという情報だけで一転してとても信頼性のないファイルとなります。

現状の把握

サイバー攻撃、特に標的型攻撃を、その手順ごとに段階化した考えをサイバー・キル・チェーンといいます。以下の表にその概要を示します。

名称概要 
偵察 あらゆる偵察行動を指します。企業のサイトや公開情報から、攻撃対象の情報を得る。また、攻撃の踏み台に出来そうな脆弱性のあるノードを探すなど。脆弱性の調査にはポートスキャンなどが行われる。
武器化 脆弱性のあるサイトに悪意のあるコードを埋め込んだり、攻撃ツール(rootkit,dropper)やマルウェアを作成する。
配送 なりすましメールなどにマルウェアを添付して攻撃対象に送り込んだり、悪意のあるコードを埋め込んだサイトに攻撃対象を誘導して、ドライブバイダウンロード(ユーザに気づかれないようにDL)させる。
エクスプロイト/攻撃 メールの添付ファイルを開かせたり、ダウンロードさせた実行ファイルを実行させる。
インストール エクスプロイトの結果としてマルウェアが設置される。
遠隔操作 C&Cサーバに接続させることにより、感染端末を遠隔操作する。
侵入拡大 通称、横への展開とも呼ばれ、ネットワーク内で脆弱性を探して侵入先を拡大する。
目的実行 目的の情報を窃取する。

現状を把握する場合、このサイバー・キル・チェーンがどの段階かを把握すると良いかもしれません。また、攻撃対策時には、このサイバー・キル・チェーンをどこで切れるかを考慮します。

過検知について

正規の正常なソフトウェアが誤ってマルウェアと検知されてしまうことを過検知といいます。とりあえず疑わしきは罰するという路線では業務がままならず、必要である正常なソフトウェアは削除しないようにしなくてはならないため、過検知かどうかを正しく判断する技術が重要になってきます。

対応

対応は技術的対応と業務的対応に分けられると思います。

技術的対応としては例えば

・C&Cサーバのアドレスをブラックリストに登録して通信させないようにする

マルウェアやその生成源を特定して削除する

・感染の疑われるノードのスキャン

・感染の疑われる端末の押収と実端末上での捜査

などが挙げられます。

業務的な対応としては例えば

・感染先ネットワークの管理者や上長、セキュリティチームへの報告

・インシデント関係者への聴取と警告

などが挙げられます。

リンク

ここには参考になる書籍やサイトのURLについてメモしておきます。順次更新予定です。

 

参考書籍

帯域幅スループット測定からボトルネックの推定方法など

 

  • あきみち,空閑 洋平 著『インターネットのカタチ-もろさが織り成す粘り強い世界-』オーム社

公開BGP情報を基にしたネットワーク可視化プロジェクトの紹介など

 

参考サイト

  •  確認君+

    cgi.b4iine.net

    Webページへアクセスすることで相手側へ知られてしまう情報を確認できるサイトです。

tracerouteの仕様について

tracerouteは、指定したホストまでの経路(経由したノード)を表示するツールです。自社ネットワークで障害が起こった時に“どのノードまではパケットが正常に届いているのか”等を調べる時に使います。もしも使用者が攻撃者であれば“攻撃パケットが標的リンクを通るかどうか”等を調べるために使うこともできるでしょう。また、あるノードまでは応答が早く、あるノードを境に応答が遅くなる場合、このノード間がボトルネックリンクではないかという推測もできます。

このtracerouteですが、IPヘッダのTTL値を利用していることはよく知られています。しかしIP層以上の仕様/実装がWindowsUnix系OSLinux)では違います。この点について、大学の実験実習で学んだのでメモとして書き留めておこうと思います。

各OSでの仕様を知ることは、Firewallでtracerouteを通したい場合等に役に立ちます。また、AS等では当該パケットを観測することでtracerouteが行われたことを認知し、攻撃者による攻撃前の調査パケット(予兆)を得るといったことも可能になるかと思われます。

 

各OS共通の仕様

IPヘッダまでの仕様は各OSで共通です。IPヘッダにはTTLフィールドといものがあります。TTL値は経由できるホップ数を表しており、IPパケットは経由したノードごとにTTL値を1減らされ、0になるとそのノードにおいて破棄されます。tracerouteでは、調査パケットのIPヘッダのTTL値が1の場合,2の場合,3の場合...と試していき、最終的に対象ホストに到達するまでこれを繰り返すというものです。

つまり、tracerouteコマンドを打つと、まずはIPヘッダのTTLフィールド(パケットが経由できるノード数を表すフィールド)を1としたパケットが送りだされます。経由できるノード数は1なので、最初の中継器でパケットが受け取られてTTL値が1減らされ0になるので、パケットは最初の中継器で破棄されます。次のパケットはTTL値が2なので、2つ目の中継器で破棄されます。次のパケットはTTL値が3なので、3つ目の中継器で破棄され...という風に対象ホストに至るまでのそれぞれのノードで破棄されるパケットがでてくるのです。

traceroute実行ノードは、これらの破棄されたノードからの応答を受け取ることで、対象ホストまでの全ルートを得ます。

 

Windwosでの仕様

Windowsではtracerouteはtracertコマンドとして実装されています。Windowsでのtracerouteは簡単に言うとpingです。すなわち、IPの上層はICMPとなっています。traceroute実行ノードによる調査パケットは全てICMP type8 code0(echo request)として送られます。ただし、それぞれの中継ノードではTTL値が0になってパケットは破棄されるので、中継ノードからtraceroute実行ノードに対してICMP type11 code0(time exceeded)が返されます。唯一宛先ホストのみが、echo requestに対する応答として、ICMP type0 code0(echo reply)を返します。

traceroute実行ノードはecho replyが返ってきたら宛先ホストまでのtraceが完了したと解釈することができます。ちなみにそれぞれの応答(time exceededおよびecho reply)内には送信者の情報が記載されているので、traceroute実行ノードは中継ノードの情報を得られます。

 

※補足

ちなみに、tracerouteでは実行ノードとそれぞれの中継器間の情報(RTT等)しかわかりませんが、現行のWindowsでは中継器間の情報もわかるpathpingなるものがあったりするそうで…

 

Unix系OSLinux)での仕様

Linux等では、IPパケットの中身はICMPではなくUDPになっています(ただし指定すればICMPでも可能)。UDPヘッダの宛先ポート番号を、絶対に使われていないであろうポート番号に設定して送ります。TTL値が0になる中継ノードからは、実行ノードに対して、Windowsのtracertと同じようにICMP type11 code0(time exceeded)が返されます。しかし、宛先ホストには待ちうけていないポート宛ての要求が来たのでパケットを破棄し、実行ノードに対してICMP type3 code3(port unreachable)を返します。

実行ノードはport unreachableを得れば宛先ノードまでのtraceが完了したと判断します。以下はtraceroute後の宛先からのport unreachableをwiresharkで実際にキャプチャした際の画像です。

f:id:white-hawk:20170210034547p:plain

 

※補足

ちなみに、実際に使われるであろう宛先ポートを指定すると、運用されているサービスから応答が来てしまう可能性があるので、使われていないポートを指定します。また、メジャーなサービスの宛先ポート番号はウェルノウンポートとなるので、多くの実装では33434からインクリメントしてパケットを送信しますので、Firewallでもしtracerouteを通す場合これを意識するといいと思います。また念のため1度に2つ(資料によっては3つ)調査パケットを送るようです。(つまり1つのTTLに対して異なる宛先ポート番号を指定した2つ又は3つのパケットを送ります。)

 

結論

IP層より上層で使うプロトコルと、それに伴った宛先ホストまで到達したかどうかの判断方法が異なります。

 

今後のtraceroute関連の記事について

tracerouteの高速化については前から興味がありましたので、tracerouteのコードなんかを見ながら記事がかければなーと思います。あとtracerouteを応用した研究等(既存のものでいうと某大学様のASパス推測など)についても言及できればと思います。

Linux(CentOS)のディレクトリ構造

サーバをいじりはじめて最初に感じたのが、各ディレクトリの意味をちゃんと理解できていないなーということでした。

サーバを管理する上では吐かれたログを見たり、システムの設定をいじったりしないといけないので、ディレクトリ構造については知っておくべきだと思い、現行のディレクトリ構造の標準などについて調べてみました。

※間違いがあったら指摘して戴けると嬉しいです。

 

目次

 

 

FHS(Filesystem Hierarchy Standard)について

FHSはLinuxディストリビューションの多くが従っているファイルシステム階層に関する標準だそうです。自分が利用しているCentOSもこれに則っているようです。

2017年1月現在での現行標準はv3.0のようです。

 

ファイルシステムとは、記憶装置に格納されたデータ(ファイル)を、ユーザが操作できるようにするためにOSが提供している機能です。複数の関連するファイル(及びディレクトリ)を束ねるのがディレクトリになります。

Windows系OSではデバイスごとにツリー構造を持ちますが、UNIX系OSでは、すべてのデバイス上のファイルをひとつの階層構造(木構造)のいずれかのディレクトリ内に配置する仮想ファイルシステムになっており、この木構造の根にあたるのがルートディレクトリになります。

 

ディレクトリ構造

 Linuxファイルシステム最上位はルートディレクトリ("/")です。※ルートディレクトリは厳密には/直前の空白らしいのですが/と表すのが慣例となっています。

その直下のディレクトリは下記のようになっています。

 

名前格納される内容
/bin

最低限必要な基本コマンドの実行ファイル(binaries)が格納されている。 例えば、chmod、sh、ls、cp、pwd、chown、psなど。

※/usr/binと違いシングルユーザモードで使う最低限のもの置いている点。/binにないものを/usr/binに置いている。

/boot 起動(ブート)に必要なファイル。カーネルの他にもinitrd等が含まれる。
/dev 接続されたデバイスを制御する際に用いるデバイス・ファイル(スペシャル・ファイル)が置かれる。データ入出力を1文字(バイト)単位で行うマウス・キーボードのようなものをキャラクタデバイス、ある一定の大きさ(ブロック)単位で行うHDD・メモリ・FDのようなものをブロックデバイスと呼ぶ。 デバイスファイルに対し、open()などのシステムコールを用いると、カーネルドライバがファイルではなくデバイスへアクセスする仕組みになっている。 主なデバイスファイル名とその詳細については以下のようになる。
hda IDE接続されたデバイスを表す(HDDである必要はない)。接続されるデバイスごとにhda,hdb,hdc...と命名される。また、HDDにパーティションがある場合パーティションごとのファイルも生成される。(例えば、sdaに3つのパーティションがある場合hda1,hda2,hda3)
sda SCSI接続されたデバイスを表す。命名規則は同上。
null nullデバイスを表す。nullデバイスは実体がない仮想的なデバイスの一つで、書き込んでも捨てられ読み出しても何も得られないデバイス。出力を捨てる際に用いる。
zero zeroデバイスを表す。zeroデバイスは実体がない仮想的なデバイスの一つで、書き込んでも捨てられ読み出すと0を得つづけることができるデバイス。
random 乱数生成器を表す。
stdin 標準入力(デフォルトではキーボード入力)を表す。
stdout 標準出力(デフォルトではコンソール画面)を表す。
stderr 標準エラー出力(デフォルトではコンソール画面)を表す。
tty 標準入出力となっている端末を表すデバイスファイル。teletypewriterの略称。
pts sshtelnetで接続する仮想端末のデバイスファイル。
/etc

固有の設定ファイルが置かれる。設定ファイルの拡張子と定義されているわけでないものの、confとつくものが割とある。例えばWebサーバの設定はhttpd.conf(httpd/conf)などとして置かれる。

/home ユーザのホームディレクトリ。
/lib /bin配下や/sbin配下にある実行ファイルに必要なライブラリ。
/media リムーバブルなデバイスのマウントポイント。
/mnt ファイルシステムの一時的なマウントポイントで、通常は空である。
/opt アプリケーションのパッケージのインストール用。
/proc

procfs(process filesystem)というプロセスの情報をファイルシステムに見せかけたものをマウントするディレクトリ。ここではプロセスや場合によってはカーネルの情報が置かれる。

/root rootユーザのホームディレクトリ。
/sbin システム管理関係のコマンド実行ファイルが置かれる。
/tmp 一時的に利用するファイル置き場。システムを再起動したときには消去されている。
/usr マルチユーザで共有可能なリソース、アプリケーションが置かれるディレクトリ。
/usr//bin /binに置かれなかったコマンドが置かれる。すなわちシングルユーザモードでは必要ないようなもの。
/usr/local ユーザがインストールしたソフトウェア等が置かれるディレクトリ。
/var 内容が変化する可変データが置かれるディレクトリ。ログファイルやアプリケーションキャッシュなど。

 

この他にもディストリビューションやOSごとに固有のディレクトリだったり、インストールしたサブシステムによって追加されるディレクトリがあるようです。自分のCentOSではselinuxという強制アクセス制御のためのディレクトリ等もありました。


 

補足

■initrdとはなんぞや

聞いたことがあってもよくわかっていなかったものの一つです。Wikipediaさん曰く次の通りらしいです。

初期RAMディスク(initial ramdisk)はLinuxカーネルブート時に一時的なルートファイルシステムをメモリに読み込むための方式。

initrd - Wikipedia

カーネルのbootにはファイルシステムを参照しないといけないが、ファイルシステム構築にはカーネルが必要という矛盾があり、これを打開するため、カーネルブート時には一時的なファイルシステムをメモリ上に展開するということでしょうか…?

うーん確信が持てない…ということでさらに調べていくとめちゃくちゃわかりやすく解説されていらっしゃるサイト様がありましたので、リンクを張っておきます。

Linuxのinitrdファイルの作成

つまりポイントは以下

  • 現状のLinuxでは、カーネルはモジュール化により各種ドライバを内包していない。なぜなら、ドライバをすべてカーネルに内包させると容量が肥大化するため。現在は必要に応じてモジュールをカーネルに組み込む形を取っている。
  • つまりブート時にカーネル単体をメモリ上に展開しても、ドライバがないのでHDDを認識できない問題が起こる。
  • initrdはブートする際に必要なHDDドライバなどのモジュールを、カーネルと一緒にメモリに展開するために記述されるファイル

モノリシックカーネルとドライバのモジュール化についても勉強になりましたので、ブートの仕組みやこれらについても後で改めて別記事にまとめようと思います。