web-dev-qa-db-ja.com

Linuxをパーティション分割する最も安全な方法は?

私は最近ネットブックを入手しましたが、ネットワークセキュリティとエクスプロイト開発について学ぶことができるようにKali Linuxをインストールしたいと思っています。これを使用して、セキュリティについてできるだけ多くのことを学びたいと思います。

セキュリティリスクに対して最も抵抗力を持つようにLinuxボックスを分割する最良の方法は何ですか? Linuxのすべてのフォルダを含む単一のパーティションは本当に悪いのですか?

可能性のある脅威の詳細に進むことができる場合は、追加のポイント。出来るだけ学びたいです。

33
DCIndieDev

情報セキュリティの聖三位一体:C(機密性)、I(完全性)、およびA(可用性)に留意してください。したがって、構成の強化について話すときは、使用しているテクノロジ、保護されている情報、組織内での情報の使用方法、および脅威を考慮する必要があります。これらの回答、および場合によっては他の回答に基づいて、どのテナントが最も重要で何に焦点を当てるかを決定し始めることができます。

ファイルシステムレベルでは、通常、整合性と可用性に最も関心があります。情報の機密性はおそらく別のレイヤーで処理する必要がありますが、ファイルシステムの配置方法と使用方法は、情報が信頼できるものであり、必要なときにいつでも利用できることを確認する必要があります。

パーティションをレイアウトする際に留意する必要があるのは、障害モードです。通常、その質問の形式は次のとおりです。「パーティションxがいっぱいになるとどうなりますか?」

OSを格納しているパーティションがいっぱいになるとどうなりますか?_/_がいっぱいになると、奇妙なことが時々起こります。時々システムがハングします。新しいログインセッションが発生しない場合があります。システムが起動を拒否することがあります。

すべての障害モードの中で、OS、カーネルのバージョン、構成などに基づいて症状が変化する可能性が最も高いため、これを厳密に特徴付けるのは最も困難です。一部のファイルシステム、特にext行は、ファイルシステムが創造された。この回収されたスペースは、rootユーザーのみが使用でき、システム管理者が引き続きスペースを操作およびクリーンアップできるようにすることを目的としています。

ログを保存するパーティションがいっぱいになるとどうなりますか?監査/レポートデータを失い、攻撃者がそのデータを非表示にするために使用されることがありますアクティビティ。ログインイベントを記録できない場合、システムが新しいユーザーを認証しない場合があります。

_/var_がいっぱいになるとRPMベースのシステムで何が起こりますか?パッケージマネージャーはパッケージをインストールまたは更新しません構成によっては、警告なしに失敗する場合があります。

特にユーザーがパーティションに書き込むことができる場合は、パーティションをいっぱいにするのは簡単です。面白くするために、このコマンドを実行して、かなり大きなファイル_cat /dev/zero > zerofile_をすばやく作成できることを確認してください。

パーティションをいっぱいにするだけでなく、別のマウントポイントに場所を配置するときに、マウントオプションをカスタマイズすることもできます。

_/dev/_がnoexecでマウントされていない場合はどうなりますか?以来_/dev_通常、OSによって維持されると想定されており、悪意のあるプログラムを隠すために頻繁に(そして時にはまだ)使用されるデバイスのみが含まれています。 noexecをオフにすると、そこに格納されているバイナリを起動できます。

これらすべての理由、およびさらに多くの強化ガイドでは、実行する最初のステップの1つとしてパーティション分割について説明します。実際、新しいサーバーを構築している場合、ディスクをパーティション分割する方法は、ほぼ正確に最初に最初に決定することです。上で、後で変更するのが最も難しいことがよくあります。 Center for Internet Security と呼ばれるグループが存在し、読みやすい構成ガイドのゴブが作成されます。あなたはおそらくあなたの特定の オペレーティングシステム のガイドを見つけ、彼らが言うかもしれない詳細を見ることができます。

RedHat Enterprise Linux 6を見ると、推奨されるパーティションスキームは次のとおりです。

_# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec
_

これらすべての変更の背後にある原則は、それらが相互に影響を与えないようにすること、および/または特定のパーティションで実行できることを制限することです。たとえば、_/tmp_のオプションを見てみましょう。つまり、そこにデバイスノードを作成したり、そこからプログラムを実行したり、set-uidビットを設定したりすることはできません。その性質上、_/tmp_はほぼ常に書き込み可能な世界であり、多くの場合、メモリにのみ存在する特殊なタイプのファイルシステムです。これは、攻撃者が悪意のあるコードをドロップして実行する簡単なステージングポイントとしてそれを使用し、システムをクラッシュ(または単に再起動)してすべての証拠を消去する可能性があることを意味します。 _/tmp_の機能はその機能を必要としないため、機能を簡単に無効にして、そのような状況を防ぐことができます。

ログの保存場所である_/var/log_および_/var/log/audit_は、リソースの枯渇からバッファリングするために分割されています。さらに、ログストレージがいっぱいになり始めると、auditdはいくつかの特別な処理(通常はより高いセキュリティ環境)を実行できます。パーティションに配置することで、このリソース検出のパフォーマンスが向上します。

より冗長にして、mount(8)を引用すると、これはまさに上記で使用したオプションと同じです。

noexecマウントされたファイルシステム上のバイナリの直接実行を許可しません。 (最近まで、とにかく/lib/ld*.so/mnt/binaryのようなコマンドを使用してバイナリを実行することが可能でした。このトリックはLinux 2.4.25/2.6.0以降失敗します。)

nodevファイルシステム上の文字を解釈したり、特殊デバイスをブロックしたりしません。

nosuidset-user-identifierまたはset-group-identifierビットを有効にしないでください。 (これは安全に見えますが、実際にはsuidperl(1)がインストールされている場合はかなり安全ではありません。)

セキュリティの観点から、これらはファイルシステム自体に保護をかけることができるので、知っておくと非常に良いオプションです。安全性の高い環境では、noexecオプションを_/home_に追加することもできます。ログファイルの分析など、データを処理するためのシェルスクリプトを標準ユーザーが作成するのが難しくなりますが、特権を昇格させるバイナリを実行することもできなくなります。

また、rootユーザーのデフォルトのホームディレクトリは_/root_であることに注意してください。つまり、これは_/_ファイルシステムにあり、_/home_ではnotです。

各パーティションに与える正確な量は、システムのワークロードに応じて大きく異なります。私が管理した典型的なサーバーは、人との対話をほとんど必要としないため、_/home_パーティションはそれほど大きくする必要はありません。同じことが_/var_にも当てはまります。これは、頻繁に作成および削除される一時的なデータを格納する傾向があるためです。ただし、Webサーバーは通常、その遊び場として_/var/www_を使用します。つまり、別のパーティションにも配置する必要があるか、または_/var/_を大きくする必要があります。

過去に、以下をベースラインとして推奨しました。

_# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250
_

これらは、システムの目的と環境の動作に応じて確認および調整する必要があります。また、LVMを使用し、ディスク全体を割り当てることはお勧めしません。これにより、必要に応じてパーティションを簡単に拡張または追加できます。

38
Scott Pack

1つまたは複数のパーティションに分割することは、securityの問題ではなく、reliabilityの問題です。アイデアの1つは、パーティションの1つがクラッシュした場合、thatパーティションの内容を失うことですが、他のパーティションは問題ありません。また、そのパーティションをいっぱいにしても、他のパーティションは影響を受けません。各パーティションは独自のファイルシステムを持つことができ、さまざまなコンテキストでのパフォーマンスに関してすべてのタイプのファイルシステムが同等であるとは限りません(ほとんどのファイルシステムは、ほとんどのコンテキストでほとんど同じです)。一部のPCでは、このアーキテクチャの歴史的な特殊性のため、ブートプロセスがディスクの最初の数ギガバイトよりも遠くにアクセスできない場合があります。したがって、/bootは、限られたサイズの個別のパーティションとして設定する方がよく、ディスクの最初に配置されます。

パーティションレベルの暗号化を適用する場合、暗号化が多すぎると問題が発生する可能性があります。つまり、復号化を行うコードを、外側に配置する必要がありますパーティション。これは実際の暗号化製品に大きく依存します(一部はブートローダーに復号化コードを埋め込むことができます)。

ディスクをパーティションに分割するほど、全体の柔軟性が低下することに注意してください。パーティションがいっぱいになると、他のパーティションに空き領域があっても、いっぱいになり、そのまま残ります( [〜#〜] lvm [〜#〜] は、それに対処するのに役立ちますので、 OSインストーラがLVMを使用するかどうかを尋ねるときに「yes」と言います)。作成するパーティションが多いほど、この問題は起こりやすく、困難になります。

簡単で安全な方法は、OSインストーラに最適と思われるパーティションを選択させることです。これが何を必要とするかについての正確な知識と経験が得られるまで、パーティションサイズを変更しないでください。定期的なバックアップを作成することを忘れないでください。数か月後には、OSを再インストールして「正しく実行する」ことが予想されますが、これは必ずしも悪い考えではないので、気にしないでください。これは学習ツールであり、本番環境に移行するサーバーではありません。

12
Tom Leek

これを他のレスポンダーとは異なる方法で見てみましょう。多数のエクスプロイトを見る場合、すべての脅威が可能であり、それを可能な限りシステムでサンドボックス化することは、有用な予防策のようです。 Xenはそのための1つの簡単な方法です。別のファイルシステムでディスクイメージを使用できますが、使用することがわかっている場合は、個別のディスクパーティションを残しておくことをお勧めします(Dom0で自動マウントされないことを確認してください)。

KaliがXen Dom0としてどのように機能するかはわかりません。 Ubuntuには少なくとも問題があるようです。 XenServer または別の特殊なXen Dom0ビルドのために部屋を空けることを検討してください。 [編集:最近のネットブックがどのようなものかはわかりませんが、XenServerが実際には対象にしていないと思います... Dom0としてXenでうまく機能する他の単純なディストリビューションもあるかもしれません。エクスプロイトの調査があまり一般的でない場合は、スタンドアロンまたはDomUとして実行されるKaliインストールをセットアップできる場合があります。]

BSDシステムでは、可能な限り読み取り専用でマウントし、不変のフラグを使用するようにパーティション分割することを含む強化方法について聞いたことがあります。同様のセットアップが可能なLinuxシステムが少なくともいくつかあると思いますが、KaliはDebianベースであるように見え、Debianでは実際にはそれを実行できないと思います[編集:書き込み可能ファイルをマウントしない限りFSそれ以上、これは時間をかけて維持するのはまだ厄介です。いずれにせよ、私はこれを汎用マシンに推奨することはせず、パーティショニングが使用される可能性のあるすべての方法にもっと一般的に関心がある場合にのみ取り上げます。目的に応じて、削除して簡単に再作成できるシステムに脅威を配置します。

2
joveian

これらの応答の一部には多くの優れた情報がありますが、それらが実際に特定の要件に対処しているとは思えません。あなたが述べた目的は学ぶことであり、このシステムを実験に使用してKali Linuxで遊んで、セキュリティ関連の問題の理解を深めることを計画している場合、強化されたシステムではなく、迅速かつ簡単に再インストールできるシステムを目指しますまたは安全。システムの知識と経験を習得したら、はるかに優れた立場で、どの構成がニーズに最適であり、作業スタイルなどに最適であるかを判断できます。

注意すべきいくつかのことは他の人には言及されていません。

  • パーティショニングに関するアドバイスの多くは部分的に古く、プリリンクやプリロード、キャッシングなど、ブートプロセスを高速化するために使用されるいくつかの最新のテクニックと競合する可能性があります。

  • システムの使用方法とそのシステムの構成方法について本当によく理解するまでは、パーティションのサイズを正確にすることはほとんど不可能です。別のユーザーが指摘したように、たとえばKaliが/ optを使用する場合、optパーティションを作成するか、/ optが/に割り当てられたスペースを使用する必要があります。それが機能するかどうか、またはそれが何のために使用されるのかがわからない場合、パーティションを作成するための大きさを判断できません。

  • 学習の要件は、本番のペンテストやセキュリティ監査/調査システムの要件とは大きく異なります。学習する場合、頻繁に行う必要があるのは、システムを既知の良好な(工場出荷時のデフォルト)状態にすばやく簡単に戻すことです。このため、私は仮想イメージを使用することがよくありますが、ネットブックではこれは現実的ではありません。プロダクション、ペンテスト、セキュリティ監査などのシステムでは、かなり保護されたものが必要です。おそらく、専用の(そしてワイプ可能な)ストレージサポートを備えた読み取り専用メディアにKaliをセットアップします。これにより、システムが悪意のある環境で使用されても変更または変更されないという確信が高まり、システムを再起動すると必ず既知の構成に戻るなどの確信が高まります。

Kali Linuxを始めるのはかなり難しいと思います。カーリーを使って安全を学ぶつもりだと言うのは、戦闘機に飛び込んで飛ぶことを容赦なくしようと言うのと少し似ています。これがどれほど簡単に見つかるかは、Linuxの経験と、Debianベースのシステムの知識に依存します。私は、簡単にワイプして再インストールできる単一のパーティションだけの標準インストールを使用します。後で、見つけて実行することに応じて、より堅牢で安全なセットアップを検討できます。カーリーは実際には比較的新しいものであり、それでも独自の歯が生える問題があることに注意してください。デフォルトのインストールに固執することで、Kaliのセットアップでバグが発生する可能性を減らすことができます。これは、学習しているときに本当に混乱する可能性があります。結論として、最初はシンプルにしてください。

1
Tim X

他のすべての答えは良い出発点です。

昔(90年代前半)にはディスクが小さかったため、実際にはunixをインストールして/ usrを独自の物理ディスクに配置することができました。インストール後、物理ディスクに読み取り専用ジャンパーを設定できます。インターネット上のすべてが広く開かれた平文の時代に戻ったとき、それは根付かれるのが一般的でした。この設定のいいところは、一度ルート化されたとしても、/ usr内のファイルが変更されないように保護されていたことです。

Ro、execであるファイルシステムで/ bin、/ sbin、/ usrを作成し、他のすべてのファイルシステムをnoexecにすることで、同様のことを行うことができます。

0
jrwren