セキュリティ
この記事には、Arch Linux システムをハードニングするための推奨事項とベストプラクティスを並べています。
目次
概念
- システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で かつ 使いやすいシステムを作ること。
- 最大の脅威は常にユーザー自身である。
- 最小権限の原則: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
- 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
- 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
- システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
- 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。
パスワード
パスワードは安全な linux システムのかぎです。パスワードはユーザーアカウント, 暗号化されたファイルシステム, SSH/GPG 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。
安全なパスワードの選び方
パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法でクラックされないようにする必要があります。強力なパスワードの基本原則は、長さとランダム性に基づいています。暗号学では、パスワードの品質はそのエントロピーによって測られます。
安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。
- 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
- 単純な文字の置き換えを行った単語(例:
k1araj0hns0n)最新の辞書攻撃ではこれらも簡単に解析可能 - 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:
DG091101%) - 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:
photocopyhauntbranchexpose)文字の置き換えを行っても(例:Ph0toc0pyh4uN7br@nch3xp*se)、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり) - 最も一般的なパスワードのいずれか
最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能 です。
pwgen や apgAUR のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。
パスワード管理とは別に、keepassxc はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。
パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:t6!WdtR5 より複雑な例:t&6!RrlW@dtR,57
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です(Wikipedia:Letter frequency を参照)
また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。
さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードをパスワードマネージャに保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。 また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。
覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、xkcdのコミック に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については Diceware を参照してください。
さらに詳しい情報については、The passphrase FAQ や Wikipedia:Password strength も参考になります。
パスワードの管理
強力なパスワードを選んだら、それを安全に保管することが重要です。キーロガー (ソフトウェアおよびハードウェア)、スクリーンロガー、ソーシャルエンジニアリング、ショルダースーフィングに注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。パスワードマネージャを使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、.bash_history などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、サイドチャネル攻撃に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。
原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[1] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。
パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。
ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、/etc/shadow が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については SHA パスワードハッシュ を参照してください)
パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。
データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。
パスワードのハッシュ
ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)
パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)鍵導出関数 (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。
デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な /etc/shadow ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な /etc/passwd ファイルから分離されています。詳細は ユーザーとグループ#ユーザーデータベース を参照してください。また、#root の制限 も参照してください。
パスワードは passwd コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードをストレッチし、その後 /etc/shadow に保存されます。パスワードはソルトも施され、レインボーテーブル攻撃に対して防御されます。詳細はLinux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)を参照してください。
パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな passwd コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、/etc/shadow ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。
フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、crypt(5) を参照してください。
/etc/login.defs ファイルでは、デフォルトのパスワードハッシュメソッドENCRYPT_METHOD YESCRYPT とそのパラメータ YESCRYPT_COST_FACTOR が設定されます。
例えば、デフォルトの YESCRYPT_COST_FACTOR パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。
これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては SHA パスワードハッシュ を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。
pam_cracklib を用いた強力なパスワードの強制
pam_cracklib は辞書攻撃からの防御を提供し、システム全体で強制するパスワードポリシーの設定を補助します。
例えば以下のようなポリシーを強制させたい場合:
- エラー時に2回パスワードプロンプト
- 最小で10文字の長さ (minlen オプション)
- 新しくパスワードを設定する場合、少なくとも6文字は古いパスワードと異なる (difok オプション)
- 少なくとも1文字数字を含む (dcredit オプション)
- 少なくとも1文字は大文字を含む (ucredit オプション)
- 少なくとも1文字は異なる文字を含む (ocredit オプション)
- 少なくとも1文字は小文字を含む (lcredit オプション)
/etc/pam.d/passwd ファイルを以下のように書き換えます:
#%PAM-1.0 password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 password required pam_unix.so use_authtok sha512 shadow
password required pam_unix.so use_authtok でパスワードのプロンプトを表示するときに pam_unix モジュールではなく pam_cracklib によるプロンプトを使うようになります。
詳細な情報については pam_cracklib(8) と pam_unix(8) の man ページを参照してください。
CPU
マイクロコード
CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、マイクロコード を参照してください。
ハードウェアの脆弱性
CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、kernel documentation on hardware vulnerabilities を参照してください。
既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。
$ grep -r . /sys/devices/system/cpu/vulnerabilities/
ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。
同時マルチスレッディング (ハイパースレッディング)
同時マルチスレッディング] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、L1 Terminal Fault および Microarchitectural Data Sampling 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。
SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の カーネルパラメータ を追加することで、カーネルで SMT を無効にすることができます。
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force
メモリ
ハード化された malloc
hardened_malloc (hardened_mallocAUR, hardened-malloc-gitAUR) は glibc の malloc() をハード化した代替品です。元々は Android の Bionic と musl に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。
hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 /etc/ld.so.preload でグローバルに有効にすると、 一握りのアプリケーションにしか問題を起こしません。例えば、getrandom が標準のホワイトリストにないため、seccomp 環境フラグが無効でないと man は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。
スタンドアロンで試すには、hardened-malloc-preload ラッパー スクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox
Firejail の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。
ストレージ
ディスク暗号化
ディスク暗号化、特に 強力なパスフレーズ を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。
ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。
また、TPMにキーを保存してドライブを暗号化 することもできますが、過去に 脆弱性 があり、キーは TPMバススニッフィング攻撃 によって抽出される可能性があります。
dm-crypt のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。
ディスク暗号化 の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば クラウドストレージ)に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。
ファイルを暗号化するためのいくつかの方法は次の通りです:
- 一部の アーカイブおよび圧縮 ツールは基本的な暗号化も提供します。例としては、7-Zip (
-pフラグ)、zip (-eフラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[2] - GnuPG を使用してファイルを 暗号化 できます。
- age は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。
ファイルシステム
現在カーネルは fs.protected_hardlinks や fs.protected_symlinks sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。
それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには /var や /tmp などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。
マウントオプション
最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)
関連するマウントオプションは以下の通りです:
nodev: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。nosuid: set-user-identifier や set-group-identifier ビットを無効にする。noexec: マウントされたファイルシステム上のバイナリを直接実行できないようにする。/homeにnoexecを設定すると、実行可能なスクリプトが禁止され、Wine、Steam、PyCharm、.NET などが動作しなくなります。- 一部のパッケージ(例:nvidia-dkms のビルド)では、
/varにexecが必要な場合があります。
データ用のファイルシステムは、常に nodev、nosuid、noexec を指定してマウントするべきです。
マウントを検討すべきファイルシステム:
/var/home/dev/shm/tmp/boot
スナップショット
ファイルシステムのスナップショットを利用する場合(例えば Btrfs、LVM、ZFS など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、Snapper のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。
以下は、/home/ 内の機密情報がスナップショットに残存する例です:
- 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、
.local/share/Trash/、.historyなどのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。 - 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル(
.cache/thumbnails)や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴(.mozilla/、.config/chromium/など)も、削除される前にスナップショットに記録されている場合があります。
対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、Btrfs を使用している場合、.cache/、.config/、.local/、.var/ など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。
ファイルシステムのパーミッション
デフォルトの パーミッション では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、http ユーザーや nobody ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。chmod を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。
# chmod go-r path_to_hide
考慮すべきパスの例:
/boot: ブートディレクトリ、vmlinuz や initramfs image、または ユニファイドカーネルイメージ が含まれる場合があります。なお、systemd# GPT パーティションの自動マウント を使用する場合、デフォルトで安全なパーミッションが適用されます。/etc/nftables.conf: nftables の設定ファイル(nftables および iptables-nft に適用)/etc/iptables: レガシーな iptables の設定ファイル(iptables に適用)
また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの umask 値 0022 を変更することも可能です。NSA RHEL5 Security Guide では最大限のセキュリティを確保するために、0077 を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については Umask#マスクの値を設定 を参照してください。
さらに、sudo を使用する場合、デフォルトの root umask を適用するよう設定することを検討してください。
SUID ファイルと SGID ファイル
Setuid ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。これらは /usr/bin 内にあり、SUID ビットが設定されていて、root によって所有されています:
このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば Wikipedia:Setuid#Security impact を参照してください。[3][4][5]
SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、典型的には潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりにケイパビリティを割り当てることによって、Setuid や Setgid の使用を回避することが可能です。
SUID ビットか SGID ビットを持つファイルを /usr/bin から探すには:
$ find /usr/bin -perm "/u=s,g=s"
ユーザー設定
root アカウントを日常的に使用しない
最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて sudo を使用する。
ログイン失敗後の遅延時間の設定
以下の行を /etc/pam.d/system-login に追加し、ログインに失敗した際に最低4秒の遅延を追加します。
/etc/pam.d/system-login
auth optional pam_faildelay.so delay=4000000
4000000 は遅延させる時間をマイクロ秒単位で指定します。
3回ログインを失敗したユーザーをロックアウトする
pambase 20200721.1-2 の時点では 、デフォルトで pam_faillock.so が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします (FS#67644 を参照してください) このロックアウトはパスワード認証 (例:ログインと sudo) にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。 完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。
ユーザーをロック解除するには、次のようにします。
$ faillock --reset --user username
デフォルトでは、ロック機構は /run/faillock/ にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 faillock コマンドはファイルを空にするだけで、root は必要ありません。
モジュール pam_faillock.so は、ファイル /etc/security/faillock.conf で設定することが可能です。ロックアウトのパラメータです。
unlock_time- ロックアウト時間 (秒単位、デフォルトは10分)fail_interval- ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)deny- ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)
デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、/etc/security/faillock.conf の dir パラメータを /var/lib/faillock に変更する必要があります。
変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては faillock.conf(5) を参照してください。
プロセスの数を制限する
信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、フォーク爆弾などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は /etc/security/limits.conf で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。prlimit コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。
* soft nproc 100 * hard nproc 200
Wayland を使用する
Xorg よりも Wayland を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が は安全でないと考えています 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。
もし Xorg を実行しなければならないなら、root での実行を避けることが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。
root の制限
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
su の代わりに sudo を使う
色々な理由から特権アクセスには su よりも sudo を使うほうが好ましいとされます。
- 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
- root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
- 完全な root ターミナルは作成されないため、
sudoは root アクセスが必要ないコマンドを偶発的に root で実行してしまうことを防止します。これは最小権限の原則と合っています。 - 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー alice に特定のプログラムへのアクセス権限を与えるには:
# visudo
/etc/sudoers
alice ALL = NOPASSWD: /path/to/program
また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs
これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から /sbin/mount.cifs や /sbin/umount.cifs コマンドを実行できるようになります。
sudo を使ってファイルを編集する
root で vim などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
export SUDO_EDITOR=rvim
ファイルの編集には sudoedit filename または sudo -e filename を使って下さい。自動的に rvim によって filename が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
root ログインの制限
sudo を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。sudo を使える状態のまま root を無効化したい場合、passwd -l root を使用します。
特定のユーザーだけに許可を与える
PAM の pam_wheel.so は wheel グループに入っているユーザーだけに su を使用したログインを許可します。/etc/pam.d/su と /etc/pam.d/su-l の両方を編集して次の行をアンコメントしてください:
# Uncomment the following line to require a user to be in the "wheel" group. auth required pam_wheel.so use_uid
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
ssh ログインを拒否する
ローカルユーザーの root ログインを拒否したくない場合でも、SSH による root ログインを拒否するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
access.conf で許容されるログインの組み合わせを指定する
誰かが PAM でログインしようとすると、 /etc/security/access.conf がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。
+:root:LOCAL -:root:ALL
特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。
+:archie:LOCAL +:(wheel):LOCAL +:(adm):LOCAL -:ALL:ALL
詳しくは access.conf(5) で確認してください。
強制アクセス制御
強制アクセス制御 (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている任意アクセス制御 (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。
パス名 MAC
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。
- AppArmor は Canonical によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
- Tomoyo はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。
ラベル MAC
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。
- SELinux は、Linux セキュリティを向上させる NSA プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。
アクセス制御リスト
アクセス制御リスト (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。
カーネルの堅牢化
カーネルの自己防衛機能/脆弱性攻撃対策
linux-hardened パッケージは、基本的なカーネル堅牢化パッチセットと、linux パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。
しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば
NVIDIA などのアウトオブツリードライバを使用している場合、その DKMS パッケージに切り替える必要があるかもしれません。
ユーザー空間 ASLR の比較
linux-hardened パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。paxtest コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:
64 ビットプロセス
linux-hardened 5.4.21.a-1-hardened
Anonymous mapping randomization test : 32 quality bits (guessed) Heap randomization test (ET_EXEC) : 40 quality bits (guessed) Heap randomization test (PIE) : 40 quality bits (guessed) Main executable randomization (ET_EXEC) : 32 quality bits (guessed) Main executable randomization (PIE) : 32 quality bits (guessed) Shared library randomization test : 32 quality bits (guessed) VDSO randomization test : 32 quality bits (guessed) Stack randomization test (SEGMEXEC) : 40 quality bits (guessed) Stack randomization test (PAGEEXEC) : 40 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed) Offset to library randomisation (ET_EXEC): 34 quality bits (guessed) Offset to library randomisation (ET_DYN) : 34 quality bits (guessed) Randomization under memory exhaustion @~0: 32 bits (guessed) Randomization under memory exhaustion @0 : 32 bits (guessed)
linux 5.5.5-arch1-1
Anonymous mapping randomization test : 28 quality bits (guessed) Heap randomization test (ET_EXEC) : 28 quality bits (guessed) Heap randomization test (PIE) : 28 quality bits (guessed) Main executable randomization (ET_EXEC) : 28 quality bits (guessed) Main executable randomization (PIE) : 28 quality bits (guessed) Shared library randomization test : 28 quality bits (guessed) VDSO randomization test : 20 quality bits (guessed) Stack randomization test (SEGMEXEC) : 30 quality bits (guessed) Stack randomization test (PAGEEXEC) : 30 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed) Offset to library randomisation (ET_EXEC): 28 quality bits (guessed) Offset to library randomisation (ET_DYN) : 28 quality bits (guessed) Randomization under memory exhaustion @~0: 29 bits (guessed) Randomization under memory exhaustion @0 : 29 bits (guessed)
linux-lts 4.19.101-1-lts
Anonymous mapping randomization test : 28 quality bits (guessed) Heap randomization test (ET_EXEC) : 28 quality bits (guessed) Heap randomization test (PIE) : 28 quality bits (guessed) Main executable randomization (ET_EXEC) : 28 quality bits (guessed) Main executable randomization (PIE) : 28 quality bits (guessed) Shared library randomization test : 28 quality bits (guessed) VDSO randomization test : 19 quality bits (guessed) Stack randomization test (SEGMEXEC) : 30 quality bits (guessed) Stack randomization test (PAGEEXEC) : 30 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed) Offset to library randomisation (ET_EXEC): 28 quality bits (guessed) Offset to library randomisation (ET_DYN) : 28 quality bits (guessed) Randomization under memory exhaustion @~0: 28 bits (guessed) Randomization under memory exhaustion @0 : 28 bits (guessed)
32 ビットプロセス (x86_64 カーネル上)
linux-hardened
Anonymous mapping randomization test : 16 quality bits (guessed) Heap randomization test (ET_EXEC) : 22 quality bits (guessed) Heap randomization test (PIE) : 27 quality bits (guessed) Main executable randomization (ET_EXEC) : No randomization Main executable randomization (PIE) : 18 quality bits (guessed) Shared library randomization test : 16 quality bits (guessed) VDSO randomization test : 16 quality bits (guessed) Stack randomization test (SEGMEXEC) : 24 quality bits (guessed) Stack randomization test (PAGEEXEC) : 24 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed) Offset to library randomisation (ET_EXEC): 18 quality bits (guessed) Offset to library randomisation (ET_DYN) : 16 quality bits (guessed) Randomization under memory exhaustion @~0: 18 bits (guessed) Randomization under memory exhaustion @0 : 18 bits (guessed)
linux
Anonymous mapping randomization test : 8 quality bits (guessed) Heap randomization test (ET_EXEC) : 13 quality bits (guessed) Heap randomization test (PIE) : 13 quality bits (guessed) Main executable randomization (ET_EXEC) : No randomization Main executable randomization (PIE) : 8 quality bits (guessed) Shared library randomization test : 8 quality bits (guessed) VDSO randomization test : 8 quality bits (guessed) Stack randomization test (SEGMEXEC) : 19 quality bits (guessed) Stack randomization test (PAGEEXEC) : 19 quality bits (guessed) Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed) Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed) Offset to library randomisation (ET_EXEC): 8 quality bits (guessed) Offset to library randomisation (ET_DYN) : 13 quality bits (guessed) Randomization under memory exhaustion @~0: No randomization Randomization under memory exhaustion @0 : No randomization
proc ファイルシステム内のカーネルポインタへのアクセスを制限する
kernel.kptr_restrict を 1 に設定すると、CAP_SYSLOG を持たない通常ユーザから /proc/kallsyms 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の perf コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの perf コマンドは root アクセスを必要とします)。詳細は FS#34323 を参照してください。
kernel.kptr_restrict を 2 に設定すると、/proc/kallsyms 内のカーネルシンボルのアドレスが権限に依らず隠されます。
/etc/sysctl.d/51-kptr-restrict.conf
kernel.kptr_restrict = 1
BPF の堅牢化
BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。
BPF はもともと Berkeley Packet Filter の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。
BPF のコードは解釈されるか、Just-In-Time (JIT) コンパイラを使ってコンパイルされるかのどちらかです。Arch のカーネルは CONFIG_BPF_JIT_ALWAYS_ON でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチを参照してください。
カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、net.core.bpf_jit_harden を 1 (非特権コードの堅牢化を有効化する) か 2 (全てのコードの堅牢化を有効化する) に設定することで有効化できます。
詳しくは、カーネルドキュメント の net.core.bpf_* 設定を参照してください。
ptrace スコープ
ptrace(2) システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、ptrace は gdb や strace、perf、reptyr などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。
Arch では、kernel.yama.ptrace_scope カーネルパラメータを提供する Yama LSM がデフォルトで有効化されています。このパラメータはデフォルトで 1 (制限) に設定されており、CAP_SYS_PTRACE ケイパビリティも特権も持たない tracer が制限されたスコープ外で ptrace コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます (pid_namespaces(7) などの他のセキュリティレイヤーがない場合)。
デバッグツールを使う必要がない場合は、システムを堅牢化するために kernel.yama.ptrace_scope を 2 (管理者限定) や 3 (ptrace を禁止) に設定することを検討してください。
hidepid
カーネルには、proc ファイルシステムを hidepid= オプションと gid= オプションを使ってマウントすることで、他のユーザのプロセス (通常、/proc でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。
これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。
proc ユーザーとグループ#システムグループ#グループ (filesystem パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の /proc/<pid> ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスをproc グループに追加してください。
例えば、プロセスの情報を proc グループに属さない他のユーザから隠すには:
/etc/fstab
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
ユーザのセッションを正しく動作させるために、systemd-logind を例外として追加する必要があります:
/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service] SupplementaryGroups=proc
モジュールのロードを制限する
デフォルトの Arch カーネルは CONFIG_MODULE_SIG_ALL が有効で、linux パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは virtualbox-host-modules-arch などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。
カーネルモジュールの読み込みは module.sig_enforce=1 カーネルパラメータを設定することで制限することができます。詳細はカーネルドキュメントで見られます。
kexec を無効にする
Kexec は、現在実行中のカーネルを置き換えることを可能にします。
/etc/sysctl.d/51-kexec-restrict.conf
kernel.kexec_load_disabled = 1
カーネルロックダウンモード
Linux 5.4 から、オプションのロックダウン機能がカーネルに追加されました。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。
ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。
公式にサポートされているカーネルは全て LSM を初期化しますが、ロックダウンモードを強制しません。
ロックダウンには2つの動作モードがあります:
integrity: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。confidentiality: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。
特定の脅威モデルで指示がない限り、integrity を使用することが推奨されます。
実行時にカーネルのロックダウンを有効にするには、以下を実行してください:
# echo mode > /sys/kernel/security/lockdown
起動時にカーネルのロックダウンを有効にするには、lockdown=mode カーネルパラメータを使用してください:
kernel_lockdown(7) も参照してください。
Linux Kernel Runtime Guard (LKRG)
LKRG (lkrg-dkmsAUR) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。
アプリケーションのサンドボックス化
こちらも参照 Wikipedia:ja:サンドボックス (セキュリティ)
これを軽減するためには、次のいずれかを行ってください:
- 安全なデフォルトを持つ linux-hardened カーネルを使用する、または
kernel.unprivileged_userns_clonesysctl を0に設定する。
これにより、Zoom や nsjail などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに bubblewrap がインストールされている場合は、bubblewrap-suid に置き換える必要があります。詳細は Bubblewrap#インストール を参照してください。
Firejail
Firejail は、アプリケーションやサーバーをサンドボックス化するための使いやすいツールです。元々はブラウザやインターネット向けアプリケーションのために作成されましたが、現在では多くのアプリケーションに対応しています。さまざまな機能を備えたサンドボックス環境を構築するために、suid バイナリとしてインストールされ、ブラックリストとホワイトリストに基づいてターゲットアプリケーションのサンドボックス化された実行環境を構築します。
bubblewrap
bubblewrap は、Flatpak などの非特権コンテナツール向けに開発されたサンドボックスアプリケーションで、Firejail よりもリソース消費と複雑さが大幅に小さいです。ファイルパスのホワイトリスト機能は欠けていますが、bubblewrap はバインドマウントのほか、ユーザー/IPC/PID/ ネットワーク /cgroup 名前空間の作成をサポートしており、シンプルなものから複雑なサンドボックスまで対応可能です。
Bubblejail サンドボックスは bubblewrap を基にしており、リソース指向の権限モデルと、権限を調整するためのグラフィカルインターフェースを提供します。
chroot
手動で chroot してサンドボックス化されたプロセス環境を作成できます。しかし、これは他のサンドボックス技術に比べて非常に制限されています。そのサンドボックス化の範囲はファイルパスの隔離に限られています。
Linux Containers
Linux Containers は、他のオプション(完全な仮想化オプション を除く) よりも多くの隔離が必要な場合に適した選択肢です。LXC は、既存のカーネルの上で擬似 chroot 内で実行され、独自の仮想ハードウェアを持っています。
完全な仮想化オプション
VirtualBox、KVM、Xen、または Qubes OS(Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。
ネットワークとファイアウォール
ファイアウォール
標準の Arch カーネルは Netfilter の iptables および nftables を使用できますが、これらのサービスはデフォルトで 有効化 されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。
- 一般的な情報については iptables および nftables を参照してください。
- iptables ファイアウォールの設定方法については シンプルなステートフルファイアウォール を参照してください。
- netfilter の設定方法については ファイアウォール を参照してください。
- Bluetack などの IP アドレスリストをブロックするには Ipset を参照してください。
- opensnitch は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。
ポートを開く
一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする 可能性があります。これは、localhost にバインドされたプロセス にも発生することがあります。
一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば 0.0.0.0/0)ではなく、Unix ドメインソケット(unix(7))や localhost のようなループバックアドレスにバインドするべきです。
サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な ファイアウォール ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。
現在のすべてのオープンポートをリストするには、ss -l を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:
# ss -lpntu
その他のオプションについては、ss(8)を参照してください。
カーネルパラメータ
ネットワークに影響を与えるカーネルパラメータは sysctl を使って設定できます。設定方法は sysctl#TCP/IP スタックの防御 を見て下さい。
SSH
SSH 鍵を必要としない Secure Shell を使うのは避けましょう。これは総当たり攻撃を防ぎます。また、Fail2ban や Sshguard はログを監視して iptables ルールを書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
二段階認証によって認証を強化することができます。Google Authenticator はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。
root ログインを拒否するのは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
DNS
プロキシ
プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。
例えば glibc の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。dnsmasq などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [7]。
SSL 証明書の管理
サーバーサイドの SSL 証明書の管理については OpenSSL や Network Security Services (NSS) を参照してください。また、関連する Let’s Encrypt プロジェクトも見てください。
デフォルトのインターネット SSL 証明書のトラストチェーンは ca-certificates パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: ca-certificates-cacertAUR, ca-certificates-mozilla) に依存しています。
デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、ニュース を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
.crt形式の証明書を入手してください (例: view, download; 既存のルート認証局の場合、システム内にあるはずです)。/etc/ca-certificates/trust-source/blacklist/にコピーしてください。- root で update-ca-trust を実行してください。
お好きなブラウザを開いて信頼できないサイトとして表示されれば、ブラックリストが上手く機能しています。
物理セキュリティ
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで実用的で高いレベルのセキュリティを得ることができます。
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [8]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
ディスク暗号化はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
BIOS をロックダウンする
BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
ブートローダー
ブートローダー を保護することは非常に重要です。保護されていないブートローダは、例えば init=/bin/sh を設定することでログインの制限を回避することができます。カーネルパラメータ でシェルに直接ブートするようにします。
Syslinux
Syslinux はブートローダーのパスワード保護をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
GRUB
GRUB はブートローダのパスワードもサポートしています。詳しくは GRUB メニューのパスワード保護 を参照してください。暗号化 /boot もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、カーネル、initramfs は暗号化されています。
systemd-boot
systemd-boot は #セキュアブート が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、systemd-boot#パスワードで保護されたカーネルパラメータエディタ を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。
セキュアブート
セキュアブート は UEFI の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの 悪意あるメイド攻撃 を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。
セキュアブートのページでは、using your own keys によってセキュアブートを設定する方法を案内しています。
トラステッドプラットフォームモジュール(TPM)
TPM は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。
リムーバブル フラッシュ ドライブ上のブートパーティション
ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば ディスク暗号化 を併用し、ブートパーティションに置かれた encryption headers を使っている人もいます。
この方法は encrypting /boot と統合することも可能です。
自動ログアウト
Bash または Zsh を使っている場合、TMOUT によってタイムアウトによるシェルからの自動ログアウトを設定できます。
例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):
/etc/profile.d/shell-timeout.sh
TMOUT="$(( 60*10 ))"; [ -z "$DISPLAY" ] && export TMOUT; case $( /usr/bin/tty ) in /dev/tty[0-9]*) export TMOUT;; esac
(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:
$ export TMOUT="$(( 60*10 ))";
シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや TMOUT をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。
不正なUSBデバイスから保護する
Usbguard は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 BadUSB, PoisonTap または LanTurtle) からコンピューターを保護できるソフトウェアフレームワークです。
揮発性データの収集
電源が入っているコンピュータは、volatile data collection に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。
パッケージ
パッケージの認証
パッケージの署名が適正に使われていないと パッケージマネージャへの攻撃 が考えられ、さらに 適切な署名システム を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは Pacman-key を見て下さい。
アップグレード
定期的に システムのアップグレード を行うことが重要です。
脆弱性アラートの確認
National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、NVD Download webpage で見つけてください。Arch Linux Security Tracker は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール arch-audit は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである arch-audit-gtk も使うことができます。Arch Security Teamも参照してください。
特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。
パッケージの再ビルド
攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、bzip2 は CVE-2016-3189 を回避するために bzip2recover を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。
| フラグ | 目的 |
|---|---|
| -D_FORTIFY_SOURCE=2 | ランタイムバッファオーバーフローの検出 |
| -D_GLIBCXX_ASSERTIONS | C++ の文字列とコンテナのランタイム境界チェック |
| -fasynchronous-unwind-tables | バックトレースの信頼性向上 |
| -fexceptions | テーブルベースのスレッドキャンセルを有効にする |
| -fpie -Wl,-pie | 実行可能ファイルに対する完全な ASLR |
| -fpic -shared | 共有ライブラリのテキスト再配置を行わない |
| -fplugin=annobin | ハードニング品質管理用データの作成 |
| -fstack-clash-protection | スタックオーバーフロー検出の信頼性向上 |
| -fstack-protector or -fstack-protector-all | スタックスマッシュプロテクター |
| -fstack-protector-strong | 同様に |
| -g | デバッグ情報を生成する |
| -grecord-gcc-switches | デバッグ情報にコンパイラのフラグを格納する |
| -mcet -fcf-protection | 制御フローの完全性保護 |
| -O2 | 推奨される最適化 |
| -pipe | 一時ファイルを回避し、ビルドを高速化します。 |
| -Wall | 推奨されるコンパイラの警告 |
| -Werror=format-security | 安全でない可能性のあるフォーマット文字列の引数を拒否する |
| -Werror=implicit-function-declaration | 関数プロトタイプの欠落を却下する |
| -Wl,-z,defs | アンダーリンクの検出と拒否 |
| -Wl,-z,now | 遅延バインディングを無効にする |
| -Wl,-z,relro | 移設後の読み出し専用セグメント |
参照
- Arch Linux セキュリティトラッカー
- ArchWiki のセキュリティアプリケーションのリスト: アプリケーション一覧/セキュリティ
- CentOS Wiki: OS Protection
- Hardening the Linux desktop
- Hardening the Linux server
- Linux Foundation: Linux ワークステーションのセキュリティチェックリスト
- privacytools.io Privacy Resources
- Red Hat Enterprise Linux 7 セキュリティガイド
- Debian 安全化マニュアル (PDF)
- The paranoid #! Security Guide
- UNIX and Linux Security Checklist v3.0