「セキュリティ」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
 
(14人の利用者による、間の77版が非表示)
3行目: 3行目:
 
[[Category:ネットワーク]]
  
[[Category:ネットワーク]]
 
[[en:Security]]
  
[[en:Security]]
  +
[[fa:امنیت]]
 
[[ru:Security]]
  
[[ru:Security]]
  +
[[zh-hans:Security]]
−
{{Related articles start (日本語)}}
  
  +
{{Related articles start}}
  +
{{Related|PAM}}
  +
{{Related|ケイパビリティ}}
 
{{Related|アプリケーション一覧/セキュリティ}}
  
{{Related|アプリケーション一覧/セキュリティ}}
 
{{Related|:カテゴリ:セキュリティ}}
  
{{Related|:カテゴリ:セキュリティ}}
 
{{Related articles end}}
  
{{Related articles end}}
−
この記事では Arch Linux システムを防御するための推奨事項とベストプラクティスを並べています。
 +
この記事には、Arch Linux システムを[[Wikipedia:ja:ハードニング|ハードニング]]するための推奨事項とベストプラクティスを並べています。
   
−
==概念==
 +
== 概念 ==
  +
−
*セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
  
  +
* システムのセキュリティを厳重にしすぎると、使い物にならなくなることもある。セキュリティと利便性のバランスを取ることが重要だ。重要なのは、安全で ''かつ'' 使いやすいシステムを作ること。
−
*セキュリティを高めるために出来ることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
  
  +
* 最大の脅威は常にユーザー自身である。
−
*少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
  
−
*[[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。
 +
* [[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部分は、必要最小限の権限のみを持つべきであり、それ以上のアクセスは許可されるべきではない。
  +
* 多層防御 (Defense in Depth): セキュリティは独立した複数の層で成り立つべきである。一つの層が突破されても、次の層が攻撃を食い止める仕組みが必要です。
  +
* 少しだけ疑い深くなること。常に警戒すること。うますぎる話には注意すべきだ。それが本当である可能性は低いと思うこと。
  +
* システムを100%安全にする方法はただ一つ。それはネットワークから切り離し、電源を切り、金庫に入れ、コンクリートで固め、二度と使用しないこと。
  +
* 失敗を想定せよ。セキュリティが破られたときに備え、あらかじめ対応策を準備しておくこと。
   
 
==パスワード==
  
==パスワード==
−
パスワードは安全な linux システムのかぎです。パスワードは[[Users and Groups (日本語)|ユーザーアカウント]], [[Disk encryption (日本語)|暗号化されたファイルシステム]], [[SSH keys|SSH]]/[[GPG (日本語)|GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。
 +
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。
   
  +
=== 安全なパスワードの選び方 ===
−
パスワードは簡単に[[Wikipedia:ja:パスワードクラック|割り出されたり]]または個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードは出来るだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。
  
   
  +
パスワードは、個人情報などから簡単に推測されないよう十分に複雑であり、また、ソーシャルエンジニアリングやブルートフォース攻撃などの手法で[[Wikipedia:Password cracking|クラック]]されないようにする必要があります。強力なパスワードの基本原則は、''長さ''と''ランダム性''に基づいています。暗号学では、パスワードの品質はその[[Wikipedia:Password strength#Entropy as a measure of password strength|エントロピー]]によって測られます。
−
{{Pkg|pwgen}} や {{Pkg|apg}} などのツールは安全なパスワードを生成するのに役立ちます。
  
   
  +
安全でないパスワードには、以下のようなものが含まれます。また、以下のようなものを元に変更や置き換えを行った場合も同様に危険です。
−
また、ある文章の各単語の一番最初を取ってパスワードを作ることもできます。
  
−
例えば “the girl is walking down the rainy street” なら “t6!WdtR5” とパスワードにすることができます。この方法はパスワードを覚えるのをずっと簡単にしてくれます。さらに、入力するのが面倒くさくなりますがパスワードを “The girl is walking down the rainy street" にすることも可能です。
  
   
  +
* 個人を特定できる情報(例:ペットの名前、生年月日、市外局番、好きなビデオゲームなど)
−
===パスワードの管理===
  
  +
* 単純な文字の置き換えを行った単語(例:{{ic|k1araj0hns0n}})最新の辞書攻撃ではこれらも簡単に解析可能
−
強固なパスワードを選び出したら、それを安全に保管してください。[[Wikipedia:ja:ソーシャル・エンジニアリング|心理操作]]や[[Wikipedia:Shoulder surfing (computer security)|ショルダーサーフィン]]に注意したり、セキュアでないサーバーから必要以上に情報が流出するのをふせぐためにパスワードを再利用しないようにしてください。{{Pkg|pass}}, {{Pkg|keepassx}}, {{Pkg|gnome-keyring}} などのツールは大量の複雑なパスワードを管理するのに役立ちます。[[Wikipedia:ja:LastPass|Lastpass]] はデバイス間で同期するためにオンラインで暗号化されたパスワードを保存するサービスですが、クローズドソースのコードと外部の企業の両方を信頼する必要があります。
  
  +
* 既存の "単語" や一般的な文字列の前後に数字・記号・文字を追加したもの(例:{{ic|DG091101%}})
  +
* 一般的なフレーズや辞書にある単語を短く組み合わせたもの(例:{{ic|photocopyhauntbranchexpose}})文字の置き換えを行っても(例:{{ic|Ph0toc0pyh4uN7br@nch3xp*se}})、安全とは限らない(ただし、後述の "Diceware" を利用した場合は例外あり)
  +
* [[Wikipedia:List of the most common passwords|最も一般的なパスワード]]のいずれか
   
  +
最も安全なパスワードは、十分に長く(長いほど良い)ランダムなソースから生成されたものです。長いパスワードを使用することが重要です。[https://www.theregister.com/2019/02/14/password_length 弱いハッシュアルゴリズムを使用すると、8文字のパスワードハッシュはわずか数時間で解読可能] です。
−
概して、安全なパスワードは覚えにくいからといって安全でないパスワードを使ってはいけません。パスワードはバランスを取る必要があります。弱いパスワードをたくさん作るよりは、安全なパスワードの暗号化されたデータベースを作り、一つの強いマスターパスワードで守るほうが良いでしょう。パスワードを紙に書くのも、物理的なセキュリティを必要としますがソフトウェアの脆弱性を防ぐ点では同じくらい有効です [https://www.schneier.com/blog/archives/2005/06/write_down_your.html]。
  
   
  +
{{Pkg|pwgen}} や {{AUR|apg}} のようなツールを使用すると、ランダムなパスワードを生成できます。しかし、これらのパスワードは覚えにくいことがあります。覚えやすくするための1つの方法は、長いパスワードを生成し、最初は最低限の安全な文字数だけを暗記し、完全な文字列を一時的に書き留めることです。時間をかけて入力する文字数を増やしていけば、最終的にはパスワードが筋肉の記憶として定着し、完全に覚える必要がなくなります。この方法は難易度が高いものの、辞書攻撃や "知的" ブルートフォース攻撃(単語の組み合わせや文字の置き換えを考慮する攻撃)に対して非常に強力です。
−
===パスワードのハッシュ===
  
−
{{Warning|SHA512 は高速なハッシュ関数として設計されており、パスワードのハッシュ用には作られていません。bcrypt や scrypt などに比べて SHA512 によってハッシュ化されたパスワードには攻撃者は''はるかに''高速にブルートフォース攻撃をすることができます。}}
  
   
  +
パスワード管理とは別に、{{Pkg|keepassxc}} はパスワード/パスフレーズの生成機能を提供します。GUI でカスタマイズ可能なパスワード生成機能があり、辞書ベースのパスフレーズもサポートされています。
−
デフォルトの Arch のハッシュ [[SHA_password_hashes|sha512]] はとても強固で変更する必要はありません。デフォルトでは、{{ic|/etc/shadow}} にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、{{ic|/etc/passwd}} にはユーザー識別子だけが保存されます。従って、[[#root の制限|root ユーザーが安全]]である限り、ファイルが外部システムにコピーされたり解読されることはありえません。
  
   
  +
パスワードを覚えるための1つの方法として、**記憶術(ニーモニック)**を利用することが挙げられます。
−
==パーティション==
  
  +
例えば、"the girl is walking down the rainy street" というフレーズは、以下のようなパスワードに変換できます。簡単な例:{{ic|t6!WdtR5}} より複雑な例:{{ic|t&6!RrlW@dtR,57}}
  +
この方法は、パスワードを覚えやすくすることができますが、英単語の最初の文字には偏りがあることに注意が必要です([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]] を参照)
  +
  +
また、ランダムに生成したパスワードを紙に書いて安全な場所に保管するという方法も有効です。例えば、財布、カバン、金庫などに保管するのがよいでしょう。ほとんどの人は、デジタルセキュリティよりも物理的な貴重品の保護に関しては理解しやすいため、この方法は現実的です。
  +
  +
さらに、記憶術とランダム生成を組み合わせる方法も効果的です。例えば、長くランダムに生成したパスワードを[[パスワードマネージャ]]に保存し、それをマスターパスワードで管理する方法です。マスターパスワードは記憶し、絶対に保存しないようにします。この方法では、パスワードマネージャーがインストールされているシステムでのみパスワードにアクセスできるようになり、状況によっては不便にもなりますが、セキュリティ強化の側面もあります。一部のパスワードマネージャーにはスマートフォンアプリもあり、手入力が必要な場合にパスワードを表示することができます(この場合、完全にランダムなものではなく、タイピングしやすいが安全なパスワードを使うことも検討できます)ただし、マスターパスワードを忘れるとすべてのパスワードにアクセスできなくなるため、単一障害点になり得ることに注意が必要です。
  +
また、一部のパスワードマネージャーは、保存するパスワードを暗号化するのではなく、マスターパスワードとサービス名から計算する方式を採用しており、新しいシステムでもデータ同期なしで使用できます。
  +
  +
覚えやすく、それでいて強力なパスワードの作成方法として、無関係な単語を複数組み合わせたパスフレーズを使うという方法もあります。この方法では、十分に長いフレーズを使用することで、辞書単語を使うことによるエントロピーの損失を補うことができます。この手法のエントロピーのトレードオフについては、[https://xkcd.com/936/ xkcdのコミック] に示されています。この方法の安全性は、選択可能な単語の集合が大きい(数千語以上)ことと、5〜7語以上のランダムな単語を選択することによって保証されます。攻撃者が選択可能な単語の集合と、使用する単語数を知っていたとしても、(選択可能な単語数) の (選択する単語数) 乗の通りのパスフレーズが生成可能であり、安全性が確保されます。詳細については [https://www.rempe.us/diceware/ Diceware] を参照してください。
  +
  +
さらに詳しい情報については、[https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] や [[Wikipedia:Password strength]] も参考になります。
  +
  +
=== パスワードの管理 ===
  +
  +
強力なパスワードを選んだら、それを安全に保管することが重要です。[[Wikipedia:Keylogger|キーロガー]] (ソフトウェアおよびハードウェア)、スクリーンロガー、[[Wikipedia:Social engineering (security)|ソーシャルエンジニアリング]]、[[Wikipedia:Shoulder surfing (computer security)|ショルダースーフィング]]に注意し、パスワードの使い回しを避けて、セキュリティの低いサーバーから不要な情報が漏れないようにしましょう。[[アプリケーション一覧/セキュリティ#パスワードマネージャ|パスワードマネージャ]]を使用すると、大量の複雑なパスワードを管理できます。パスワードマネージャーからアプリケーションに保存されたパスワードをコピー&ペーストして使用する場合は、毎回コピーした内容をクリアし、ログに保存されないようにしてください(例:プレーンテキストのターミナルコマンドにペーストしないようにし、{{ic|.bash_history}} などのファイルに保存されないようにします)ブラウザ拡張として実装されたパスワードマネージャは、[https://www.spookjs.com サイドチャネル攻撃]に脆弱である可能性があります。これを回避するためには、別のアプリケーションとして実行されるパスワードマネージャーを使用することが推奨されます。
  +
  +
原則として、強力なパスワードを覚えにくいからといって、セキュリティが低いパスワードを選んではいけません。パスワードはバランスを取る必要があります。強力なマスターパスワードと鍵で守られた暗号化された安全なパスワードデータベースを持つ方が、多くの似たような弱いパスワードを使うよりも優れています。パスワードを紙に書いて保管することも、[https://www.schneier.com/blog/archives/2005/06/write_down_your.html] で示されているように、ソフトウェアの脆弱性を避けつつ物理的なセキュリティを確保できるため、非常に効果的です。
  +
  +
パスフレーズの強度のもう一つの側面は、それが他の場所から簡単に回復できないことです。
  +
  +
ディスク暗号化のパスフレーズをログインパスワードと同じに使用する場合(例えば、ログイン時に暗号化されたパーティションやフォルダを自動マウントする場合)、{{ic|/etc/shadow}} が暗号化されたパーティションに保存されるか、または強力な鍵導出関数 (i.e. yescrypt/argon2 や sha512 を PBKDF2 で使用、md5 や低回数の PBKDF2 は避ける) を使用して保存されたパスワードハッシュを使うようにしてください (詳細については [[SHA hashes#SHA パスワードハッシュ|SHA パスワードハッシュ]] を参照してください)
  +
  +
{{Tip|Arch Linux は [https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのハッシュアルゴリズム]を yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、{{ic|passwd}} を実行してパスワード変更を行うなどして下さい。}}
  +
  +
パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。
  +
  +
データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。
  +
  +
=== パスワードのハッシュ ===
  +
  +
ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例:MD5、SHA)
  +
  +
パスワードハッシュ関数は、ユーザー入力 (パスワード) を計算せずに解読することが不可能になるように設計されています(例:bcrypt)[[Wikipedia:Key derivation function|鍵導出関数]] (KDF; 例:yescrypt、scrypt、PBKDF2) は、入力 (マスターキーやパスワード) から秘密鍵 (例:AESキー、パスワードハッシュ) を導出するために設計された暗号アルゴリズムです。したがって、KDF はパスワードハッシュ関数としても使用できる複数の用途に対応します。
  +
  +
デフォルトでは、Arch Linux はユーザーパスワードをルート専用の読み取り可能な {{ic|/etc/shadow}} ファイルにハッシュ化して保存します。これは、他のユーザーのパラメータが保存される世界に読み取り可能な {{ic|/etc/passwd}} ファイルから分離されています。詳細は [[ユーザーとグループ#ユーザーデータベース]] を参照してください。また、[[#root の制限]] も参照してください。
  +
  +
パスワードは '''passwd''' コマンドを使用して設定され、このコマンドはシステムの暗号化関数でパスワードを[[Wikipedia:Key stretching|ストレッチ]]し、その後 {{ic|/etc/shadow}} に保存されます。パスワードは[[Wikipedia:Salt (cryptography)|ソルト]]も施され、[[Wikipedia:Rainbow table|レインボーテーブル]]攻撃に対して防御されます。詳細は[https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils Linux でパスワードがどのように保存されているか(Shadow ユーティリティを使ったハッシュの理解)]を参照してください。
  +
  +
パスワードハッシュは定義されたフォーマットに従って保存されるため、新たな ''passwd'' コマンドの実行に対してメソッドとパラメータを設定することができます。したがって、{{ic|/etc/shadow}} ファイルに保存された個々のハッシュは、システムでサポートされているハッシュ関数の異種混合になる可能性があります。
  +
  +
フォーマット、ハッシュメソッド、およびパラメータに関する詳細は、{{man|5|crypt}} を参照してください。
  +
  +
{{ic|/etc/login.defs}} ファイルでは、[https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ デフォルトのパスワードハッシュメソッド]{{ic|ENCRYPT_METHOD YESCRYPT}} とそのパラメータ {{ic|YESCRYPT_COST_FACTOR}} が設定されます。
  +
  +
例えば、デフォルトの {{ic|YESCRYPT_COST_FACTOR}} パラメータを増加させると、パスワードからハッシュを導き出すために必要な計算時間が対数的に増加します。これは、システムがユーザーのログインを認証する際や、第三者がパスワードの秘密を取得しようとする場合にも適用されます。
  +
  +
これに対して、SHA-512 ハッシュ関数の計算時間は、パラメータにより線形的に影響されます。以前の Arch のデフォルトについては [[SHA パスワードハッシュ]] を参照してください。yescrypt アルゴリズムは内部で SHA-256、HMAC、およびPBKDF2 を使用してパスワードハッシュを計算することに注意してください。主な理由は、これらの広く使用され、テストされた関数の良い特性を組み合わせ、攻撃への耐性を強化することです。例えば、SHA の多用途性が原因で、この関数のハードウェアサポートが提供され、SHA ハッシュの計算性能が著しく向上したため、パスワードハッシュ関数としての使用が次第に時代遅れになりつつあります。
  +
  +
=== pam_cracklib を用いた強力なパスワードの強制 ===
  +
  +
''pam_pwquality'' は、[[Wikipedia:Dictionary attack|辞書攻撃]]に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは ''pam_cracklib'' をベースにしており、そのオプションとの後方互換性があります。
  +
  +
{{Pkg|libpwquality}} パッケージを[[インストール]]してください。
  +
  +
{{Warning|デフォルトでは、''root'' アカウントはこのポリシーの影響を受けません。}}
  +
  +
{{Note|
  +
* ''root'' アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
  +
* 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。
  +
}}
  +
  +
例えば、以下のポリシーを強制したい場合:
  +
  +
* エラーが発生した場合にパスワードを2回入力する (retry オプション)
  +
* 最小長10文字 (minlen オプション)
  +
* 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
  +
* 最低1桁の数字 (dcredit オプション)
  +
* 最低1つの大文字 (ucredit オプション)
  +
* 最低1つの小文字 (lcredit オプション)
  +
* 最低1つのその他の文字 (ocredit オプション)
  +
* "myservice" および "mydomain" という単語を含めない
  +
* root にもこのポリシーを強制する
  +
  +
{{ic|/etc/pam.d/passwd}}ファイルを以下のように編集します:
  +
  +
{{bc|1=
  +
#%PAM-1.0
  +
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
  +
password required pam_unix.so use_authtok sha512 shadow
  +
}}
  +
  +
{{ic|password required pam_unix.so use_authtok}} は、''pam_unix'' モジュールに対してパスワードの入力を促さず、代わりに ''pam_pwquality'' で提供されたものを使用するように指示します。
  +
  +
詳細については、{{man|8|pam_pwquality}} および {{man|8|pam_unix}} のマニュアルページを参照してください。
  +
  +
== CPU ==
  +
  +
=== マイクロコード ===
  +
  +
CPU のマイクロコードに対する重要なセキュリティ更新プログラムをインストールする方法については、[[マイクロコード]] を参照してください。
  +
  +
=== ハードウェアの脆弱性 ===
  +
  +
CPU の中には、ハードウェアの脆弱性を含んでいるものがあります。これらの脆弱性の一覧と、特定の使用シナリオに合わせてこれらの脆弱性を緩和するためにカーネルをカスタマイズするのに役立つ緩和策の選択ガイドについては、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] を参照してください。
  +
  +
既知の脆弱性の影響を受けているかどうかを確認するには、以下を実行してください。
  +
  +
$ grep -r . /sys/devices/system/cpu/vulnerabilities/
  +
  +
ほとんどの場合、カーネルとマイクロコードを更新することで、脆弱性を軽減することができます。
  +
  +
==== 同時マルチスレッディング (ハイパースレッディング) ====
  +
  +
[https://ja.wikipedia.org/wiki/%E5%90%8C%E6%99%82%E3%83%9E%E3%83%AB%E3%83%81%E3%82%B9%E3%83%AC%E3%83%83%E3%83%87%E3%82%A3%E3%83%B3%E3%82%B0 同時マルチスレッディング]] (SMT) は、インテル CPU のハイパースレッディングとも呼ばれ、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] および [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] 脆弱性の原因となる可能性のあるハードウェア機能です。Linux カーネルとマイクロコードのアップデートには、既知の脆弱性に対する緩和策が含まれていますが、[https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests 信頼できない仮想化ゲストが存在する場合、特定の CPU で SMT を無効にしたほうが良い場合があります。]
  +
  +
SMT は、システムのファームウェアで無効にできることがよくあります。詳細については、マザーボードまたはシステムのドキュメントを参照してください。また、以下の [[カーネルパラメータ]] を追加することで、カーネルで SMT を無効にすることができます。
  +
  +
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force
  +
  +
== メモリ ==
  +
  +
===ハード化された malloc ===
  +
  +
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) は [https://ja.wikipedia.org/wiki/GNU_C%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA glibc] の malloc() をハード化した代替品です。元々は Android の [[Wikipedia:Bionic (software)|Bionic]] と [https://ja.wikipedia.org/wiki/Musl musl] に組み込むために開発されましたが、 x86_64 アーキテクチャの標準 Linux ディストリビューションのサポートにも組み込みました。
  +
  +
hardened_malloc はまだ glibc に統合されていませんが(支援とプルリクエストは歓迎します)、LD_PRELOAD と一緒に簡単に使用することができます。これまでのテストでは、 {{ic|/etc/ld.so.preload}} でグローバルに有効にすると、 一握りのアプリケーションにしか問題を起こしません。例えば、{{ic|getrandom}} が標準のホワイトリストにないため、{{ic|seccomp}} 環境フラグが無効でないと {{ic|man}} は正常に動作しませんが、これはシステムコールを追加して再構築すれば簡単に修正可能です。hardened_malloc は性能上のコストがあるので、どの実装を使うかは攻撃対象領域と性能上の必要性に基づいてケースバイケースで決めるとよいでしょう。
  +
  +
スタンドアロンで試すには、hardened-malloc-preload ラッパー スクリプトを使用するか、適切なプリロード値でアプリケーションを手動で開始します。
  +
  +
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox
  +
  +
[[Firejail]] の正しい使い方は、その wiki ページにあります。また、hardened_malloc の設定可能なビルドオプションは、githubレポで見つけることができます。
  +
  +
== ストレージ ==
  +
  +
===ディスク暗号化===
  +
  +
[[ディスク暗号化]]、特に [[#パスワード|強力なパスフレーズ]] を使用したフルディスク暗号化は、物理的な回復からデータを守る唯一の方法です。これにより、コンピュータの電源がオフになっている場合や、対象のディスクがアンマウントされている場合にデータの機密性が保たれます。
  +
  +
ただし、コンピュータの電源が入っており、ドライブがマウントされている場合、そのデータは暗号化されていないドライブと同様に脆弱です。そのため、データパーティションがもう必要なくなったら、できるだけ早くアンマウントすることが最良の実践です。
  +
  +
また、[[Trusted Platform Module#LUKS による保存データの暗号化|TPMにキーを保存してドライブを暗号化]] することもできますが、過去に [https://tpm.fail 脆弱性] があり、キーは [https://pulsesecurity.co.nz/articles/TPM-sniffing TPMバススニッフィング攻撃] によって抽出される可能性があります。
  +
  +
[[dm-crypt]] のような特定のプログラムは、ユーザーが仮想ボリュームとしてループファイルを暗号化できるようにします。これは、システムの特定の部分だけを安全に保護する必要がある場合、フルディスク暗号化の合理的な代替手段です。
  +
  +
[[ディスク暗号化]] の記事で比較されているブロックデバイスやファイルシステムベースの暗号化方法は、物理メディア上のデータ保護には有効ですが、リモートシステム(例えば [[保存データ暗号化#クラウドストレージの最適化|クラウドストレージ]])に保存されたデータを保護するためには使用できません。そのため、個々のファイル暗号化が役立つ場合もあります。
  +
  +
ファイルを暗号化するためのいくつかの方法は次の通りです:
  +
  +
* 一部の [[アーカイブと圧縮|アーカイブおよび圧縮]] ツールは基本的な暗号化も提供します。例としては、[[7-Zip]] ({{ic|-p}} フラグ)、{{Pkg|zip}} ({{ic|-e}}フラグ) があります。これらのツールはクロスプラットフォームの互換性のためにカスタムアルゴリズムを使用している場合があるため、特別な注意を払って使用するべきです。[https://math.ucr.edu/~mike/zipattacks.pdf]
  +
* [[GnuPG]] を使用してファイルを [[GnuPG#Encrypt and decrypt|暗号化]] できます。
  +
* {{Pkg|age}} は、シンプルで使いやすいファイル暗号化ツールです。複数の受信者をサポートしており、SSH キーを使用した暗号化もサポートしているため、安全なファイル共有に役立ちます。
  +
  +
=== ファイルシステム ===
   
 
現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。
  
現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。
42行目: 195行目:
 
それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。
  
それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。
   
−
===マウントオプション===
 +
====マウントオプション====
   
−
最小権限の原則に従って、パーティションは (機能性を失わない限りで) 最も制限的なマウントオプションを使ってマウントすると良いでしょう。
 +
最小特権の原則に従い、ファイルシステムは可能な限り制限の厳しいマウントオプションを使用してマウントするべきです(機能を失わない範囲で)
   
−
====関連するマウントオプション====
 +
関連するマウントオプションは以下の通りです:
   
−
*{{ic|nodev}}: ファイルシステム上のキャラクタ・ブロック特殊デバイスを解釈しない。
 +
* {{ic|nodev}}: ファイルシステム上のキャラクタデバイスやブロックデバイスを解釈しない。
−
*{{ic|nosuid}}: set-user-identifier や set-group-identifier ビットの効果を許可しない。
 +
* {{ic|nosuid}}: set-user-identifier や set-group-identifier ビットを無効にする。
−
*{{ic|noexec}}: マウントされたファイルシステム上の全てのバイナリの直接実行を許可しない。
 +
* {{ic|noexec}}: マウントされたファイルシステム上のバイナリを直接実行できないようにする。
  +
** {{ic|/home}} に {{ic|noexec}} を設定すると、実行可能なスクリプトが禁止され、[[Wine]]、[[Steam]]、PyCharm、[[.NET]] などが動作しなくなります。
  +
*** Wine は Windows バイナリの実行に {{ic|exec}} フラグを必要としません。ただし、Wine 自体を {{ic|/home}} にインストールする場合は必要です。
  +
*** [[Steam]] を動作させるには、{{ic|/home/user/.local/share/Steam}} を [[fstab]] で {{ic|exec}} としてマウントできます。以下の設定を追加してください: {{bc|/home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0}}
  +
** 一部のパッケージ(例:{{Pkg|nvidia-dkms}} のビルド)では、{{ic|/var}} に {{ic|exec}} が必要な場合があります。
   
  +
データ用のファイルシステムは、常に {{ic|nodev}}、{{ic|nosuid}}、{{ic|noexec}} を指定してマウントするべきです。
−
====使用例====
  
   
  +
マウントを検討すべきファイルシステム:
−
{{Note|データパーティションはいつでも {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}} でマウントするべきです。}}
  
   
  +
* {{ic|/var}}
−
{| class="wikitable"
  
  +
* {{ic|/home}}
−
| align="center" |'''パーティション'''
  
−
| align="center" |{{ic|nodev}}
 +
* {{ic|/dev/shm}}
−
| align="center" |{{ic|nosuid}}
 +
* {{ic|/tmp}}
−
| align="center" |{{ic|noexec}}
 +
* {{ic|/boot}}
−
|-
  
−
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup>
  
−
|-
  
−
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam
  
−
|-
  
−
| {{ic|/dev/shm}}||yes||yes||yes
  
−
|-
  
−
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things
  
−
|-
  
−
| {{ic|/boot}}||yes||yes||yes
  
−
|-
  
−
|}
  
   
  +
{{Tip|[[systemd#GPT パーティションの自動マウント|GPT パーティションの自動マウント]] を使用する場合、ESP および XBOOTLDR パーティションは [https://github.com/systemd/systemd-stable/commit/49804cfb71d3a79f433096e4cfb5616980171336 常に {{ic|noexec,nosuid,nodev}} で強化] されます。}}
−
<sup>[1]</sup> パッケージによっては (例えば {{AUR|nvidia-dkms}} のビルド) {{ic|/var}} で {{ic|exec}} を必要とすることがあるので注意してください。
  
   
−
==ファイルシステムのパーミッション==
 +
==== スナップショット ====
−
デフォルトのファイルシステムのパーティションはほぼ全ての読み取りアクセスが許可されているため、パーティションを変更することで http や nobody ユーザーなど root 以外のアカウントへのアクセスを手に入れた攻撃者から重要な情報を隠すことができます。
  
   
  +
ファイルシステムのスナップショットを利用する場合(例えば [[Btrfs]]、[[LVM]]、[[ZFS]] など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、[[Snapper]] のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。
−
例えば:
  
   
  +
以下は、{{ic|/home/}} 内の機密情報がスナップショットに残存する例です:
−
# chmod 700 /boot /etc/{iptables,arptables}
  
   
  +
* 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、{{ic|.local/share/Trash/}}、{{ic|.history}} などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
−
デフォルトの [[Umask]] を変更することで新しく作成したファイルのセキュリティを向上させることができます。[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] はセキュリティを最大化させるために {{ic|077}} の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、[[Umask#Setting_the_umask]] を参照してください。
  
  +
* 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル({{ic|.cache/thumbnails}})や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴({{ic|.mozilla/}}、{{ic|.config/chromium/}} など)も、削除される前にスナップショットに記録されている場合があります。
   
  +
対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、[[Btrfs]] を使用している場合、{{ic|.cache/}}、{{ic|.config/}}、{{ic|.local/}}、{{ic|.var/}} など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。
−
==ディスク暗号化==
  
   
  +
{{Note|{{ic|.local/share/Trash}} を別のサブボリュームに移動すると、場合によっては [[GNOME/Files]] などでゴミ箱の機能が正常に動作しなくなる可能性があります。}}
−
[[Disk encryption (日本語)|ディスク暗号化]]、特に[[#パスワード|強固なパスフレーズ]]による完全ディスク暗号化は、物理的なリカバリからデータを守る唯一の方法です。コンピュータの電源がオフになっていて問題のディスクがアンマウントされている時は完璧なセキュリティを提供します。
  
   
  +
===ファイルシステムのパーミッション===
−
しかしながら、コンピュータの電源が入れられてドライブがマウントされると、そのデータは暗号化されていないドライブと同じように無防備になります。そのためデータが必要なくなったときはすぐにデータのパーティションをアンマウントするのが最善です。
  
   
  +
デフォルトの [[パーミッション]] では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、{{ic|http}} ユーザーや {{ic|nobody}} ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。[[chmod]] を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。
−
[[Dm-crypt (日本語)|Dm-crypt]] など特定のプログラムでは、ループファイルを物理ボリュームとして暗号化することができます。これはシステムの特定部分だけを守りたいときに完全なディスク暗号化の代わりの選択肢となりえます。
  
   
  +
# chmod go-r ''path_to_hide''
−
==ユーザー設定==
  
−
インストールした後は日常の使用のために通常ユーザーを作成してください。root ユーザーを常用してはいけません。
  
   
  +
{{Warning|この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、{{ic|g}} をコマンドから削除するか、既に実行してしまった場合は {{ic|chmod g+r path}} で再度許可を追加する必要があるかもしれません。}}
−
===3回ログインを失敗したユーザーをロックアウトする===
  
  +
−
セキュリティをさらに高めるために、指定した回数ログインを失敗したユーザーをログインできなくすることが可能です。root ユーザーがロックを解除するまでそのユーザーアカウントにロックをかけるか、または設定した時間が経つと自動でロックが解除されるように設定できます。
  
  +
考慮すべきパスの例:
−
3回ログインを失敗したユーザーを10分間ログインできないようにするには {{ic|/etc/pam.d/system-login}} を変更する必要があります:
  
  +
  +
* {{ic|/boot}}: [[パーティショニング#/boot|ブートディレクトリ]]、[[vmlinuz]] や [[initramfs]] image、または [[ユニファイドカーネルイメージ]] が含まれる場合があります。なお、[[systemd# GPT パーティションの自動マウント]] を使用する場合、デフォルトで安全なパーミッションが適用されます。
  +
* {{ic|/etc/nftables.conf}}: [[nftables]] の設定ファイル({{Pkg|nftables}} および {{Pkg|iptables-nft}} に適用)
  +
* {{ic|/etc/iptables}}: レガシーな [[iptables]] の設定ファイル({{Pkg|iptables}} に適用)
  +
  +
また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの [[umask]] 値 {{ic|0022}} を変更することも可能です。[https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] では最大限のセキュリティを確保するために、{{ic|0077}} を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については [[Umask#マスクの値を設定]] を参照してください。
  +
  +
さらに、[[sudo]] を使用する場合、[[Sudo#Permissive umask|デフォルトの root umask]] を適用するよう設定することを検討してください。
  +
  +
=== SUID ファイルと SGID ファイル ===
  +
  +
[[Wikipedia:ja:Setuid|Setuid]] ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。
  +
  +
* [[PAM|unix_chkpwd]]
  +
* chage expiry gpasswd groupmems [[passwd]] sg ({{Pkg|shadow}} パッケージ)
  +
* [[FUSE|fusermount3]]
  +
* pkexec polkit-agent-helper-1[https://github.com/polkit-org/polkit/pull/501] ([[polkit]] パッケージ)
  +
* [[OpenSSH|ssh-keysign]]
  +
* chfn chsh mount newgrp umount wall write ({{Pkg|util-linux}} パッケージ)
  +
* [[sudo]] [[doas]] [[su]] [[Kerberos|ksu]]
  +
* [[firejail]]
  +
* [[Dbus|dbus-daemon-launch-helper]]
  +
* [[Chromium|chromium-sandbox]]
  +
  +
このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば [[Wikipedia:Setuid#Security impact]] を参照してください。[https://www.cvedetails.com/vulnerability-list/vendor_id-16224/product_id-36412/Calibre-ebook-Calibre.html][https://www.cvedetails.com/product/32625/Sudo-Project-Sudo.html?vendor_id=15714][https://www.cvedetails.com/vulnerability-list/vendor_id-16191/Firejail-Project.html]
  +
  +
SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、''典型的には''潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりに[[ケイパビリティ]]を割り当てることによって、Setuid や Setgid の使用を回避することが可能です。
  +
  +
{{Tip|SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。}}
  +
  +
SUID ビットか SGID ビットを持つファイルを {{ic|/usr/bin}} から探すには:
  +
  +
$ find /usr/bin -perm "/u=s,g=s"
  +
  +
== ユーザー設定 ==
  +
  +
=== root アカウントを日常的に使用しない ===
  +
  +
最小特権の原則に従い、root ユーザーを日常的に使用しないようにしてください。システムを使用する各人に非特権ユーザーアカウントを作成するか。一時的な特権アクセスには、必要に応じて [[sudo]] を使用する。
  +
  +
=== ログイン失敗後の遅延時間の設定 ===
  +
  +
以下の行を {{ic|/etc/pam.d/system-login}} に追加し、ログインに失敗した際に最低4秒の遅延を追加します。
   
−
{{hc|/etc/pam.d/system-login|
 +
{{hc|/etc/pam.d/system-login|2=
  +
auth optional pam_faildelay.so delay=4000000
−
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
  
−
#auth required pam_tally.so onerr=succeed file=/var/log/faillog
  
 
}}
  
}}
   
  +
{{ic|4000000}} は遅延させる時間をマイクロ秒単位で指定します。
−
2行目のコメントを消すとログインの失敗ごとに2度カウントされるようになります。これだけです。冒険心を味わいたければ、ログインを3回失敗してみてください。それで何が起こるか分かるはずです。手動でユーザーのロックを解除するには次を実行してください:
  
   
  +
===3回ログインを失敗したユーザーをロックアウトする===
−
# pam_tally --user --reset
  
   
  +
{{Pkg|pambase}} 20200721.1-2 の時点では 、デフォルトで {{ic|pam_faillock.so}} が有効になっており、15分間に3回ログインに失敗すると10分間ユーザをロックアウトします ({{Bug|67644}} を参照してください) このロックアウトはパスワード認証 (例:ログインと ''sudo'') にのみ適用され、SSH 経由の公開鍵認証はそのまま利用可能です。 完全なサービス拒否を防ぐために、このロックアウトは root では無効になっています。
−
3回ログインが失敗したユーザーを永遠にログインできないようにしたい場合 {{ic|unlock_time}} の部分を削除してください。こうすると root がアカウントをアンロックするまでログインできなくなります。
  
  +
  +
ユーザーをロック解除するには、次のようにします。
  +
  +
$ faillock --reset --user ''username''
  +
  +
デフォルトでは、ロック機構は {{ic|/run/faillock/}} にあるユーザーごとのファイルです。ディレクトリの所有者は root ですが、ファイルの所有者はユーザーなので、 {{ic|faillock}} コマンドはファイルを空にするだけで、root は必要ありません。
  +
  +
モジュール {{ic|pam_faillock.so}} は、ファイル {{ic|1=/etc/security/faillock.conf}} で設定することが可能です。ロックアウトのパラメータです。
  +
  +
* {{ic|unlock_time}} - ロックアウト時間 (秒単位、デフォルトは10分)
  +
* {{ic|fail_interval}} - ロックアウトに失敗するとロックアウトされる時間 (秒単位、デフォルトは15分)
  +
* {{ic|deny}} - ロックアウトするまでに何回ログインに失敗するか (デフォルトは 3)
  +
  +
{{Note|{{ic|1=deny = 0}} はロックアウトを無効化します}}
  +
  +
デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、{{ic|1=/etc/security/faillock.conf}} の {{ic|dir}} パラメータを {{ic|/var/lib/faillock}} に変更する必要があります。
  +
  +
変更を反映させるために再起動する必要はありません。root アカウントのロックアウトを有効にする、集中ログイン (LDAP など) を無効にするなど、さらなる設定オプションについては {{man|5|faillock.conf}} を参照してください。
  +
  +
=== プロセスの数を制限する ===
  +
  +
信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。
  +
  +
* soft nproc 100
  +
* hard nproc 200
  +
  +
=== Wayland を使用する ===
  +
  +
[[Xorg]] よりも [[Wayland]] を使用することをお勧めします。Xorg の設計は現代のセキュリティ慣行より古く、多くの人が [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 は安全でないと考えています] 例えば、Xorg のアプリケーションは非アクティブな状態でもキーストロークを記録することがあります。
  +
  +
もし Xorg を実行しなければならないなら、[[Xorg#Rootless_Xorg|root での実行を避ける]]ことが推奨されます。Wayland 内では、XWayland 互換レイヤーは自動的に root レス Xorg を使用します。
   
 
== root の制限 ==
  
== root の制限 ==
 
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
  
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
   
−
===su の代わりに sudo を使う===
 +
=== su の代わりに sudo を使う ===
−
[[Su (日本語)#セキュリティ|色々な理由]]から特権アクセスには [[Su (日本語)|su]] よりも [[sudo (日本語)|sudo]] を使うほうが好ましいとされます。
 +
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。
   
 
* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
  
* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
141行目: 358行目:
 
}}
  
}}
   
−
====sudo を使ってファイルを編集する====
 +
==== sudo を使ってファイルを編集する ====
 
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
  
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
   
−
EXPORT SUDO_EDITOR=rvim
 +
export SUDO_EDITOR=rvim
   
 
ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
  
ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
   
−
===root ログインの制限===
 +
=== root ログインの制限 ===
−
[[Sudo (日本語)|sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。
 +
[[sudo]] を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。[[sudo]] を使える状態のまま root を無効化したい場合、{{ic|passwd -l root}} を使用します。
   
−
====特定のユーザーだけに許可を与える====
 +
==== 特定のユーザーだけに許可を与える ====
−
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} を編集して次の行をアンコメントしてください:
 +
[[Wikipedia:Pluggable authentication module|PAM]] の {{ic|pam_wheel.so}} は {{ic|wheel}} グループに入っているユーザーだけに {{ic|su}} を使用したログインを許可します。{{ic|/etc/pam.d/su}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
 
{{bc|<nowiki>
  
{{bc|<nowiki>
 
# Uncomment the following line to require a user to be in the "wheel" group.
  
# Uncomment the following line to require a user to be in the "wheel" group.
159行目: 376行目:
 
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
  
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
   
−
====ssh ログインを拒否する====
 +
==== ssh ログインを拒否する ====
−
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH (日本語)#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
 +
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
  +
  +
==== access.conf で許容されるログインの組み合わせを指定する ====
  +
  +
誰かが [[PAM]] でログインしようとすると、 {{ic|/etc/security/access.conf}} がそのログインプロパティに一致する最初の組み合わせをチェックします。そして、その組み合わせのルールに基づいて、試行が失敗するか成功するかが決まります。
  +
  +
+:root:LOCAL
  +
-:root:ALL
  +
  +
特定のグループやユーザーに対してルールを設定することができます。この例では、ユーザー archie は、wheel および adm グループに属するすべてのユーザーと同様に、ローカルでのログインを許可されています。それ以外のログインは拒否されます。
  +
  +
+:archie:LOCAL
  +
+:(wheel):LOCAL
  +
+:(adm):LOCAL
  +
-:ALL:ALL
  +
  +
詳しくは {{man|5|access.conf}} で確認してください。
   
 
==強制アクセス制御==
  
==強制アクセス制御==
170行目: 403行目:
   
 
*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
  
*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
−
*[[TOMOYO Linux (日本語)|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。
 +
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。
−  
−
===ロールベースアクセス制御===
  
−
grsecurity がサポートしている MAC 実装はロールベースアクセス制御と呼ばれています。RBAC はユーザーごとにロールを割り当てます。それぞれのロールには特定のオブジェクトで実行できる操作を定義します。上手く記述されたロールと操作を使うことでユーザーに指定した作業しかできないように制限をかけることができます。デフォルトの "deny-all" では管理者が想定していない行動をユーザーは出来ません。
  
−  
−
*[[Grsecurity (日本語)#RBAC|Grsecurity RBAC]] には設定を楽にするため AppArmor のような学習モードが備わっています。
  
−
*[[Grsecurity (日本語)#RBAC|Grsecurity RBAC]] は SELinux のように付加的なメタデータを使いません。RBAC は SELinux よりもずっと高速です。
  
   
 
===ラベル MAC===
  
===ラベル MAC===
 
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。
  
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。
   
−
*[[SELinux (日本語)|SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。
 +
*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。
   
 
=== アクセス制御リスト ===
  
=== アクセス制御リスト ===
−
[[Wikipedia:ja:アクセス制御リスト|アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。
 +
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。
   
  +
== カーネルの堅牢化 ==
−
*[[grsecurity (日本語)|grsecurity]] はセキュリティを向上させるための完全なカーネルパッチセットだけでなく、ACL アクセス制御も実装しています。メモリ割り当てのコントロールを拡張し、chroot 制限を改良、特定のネットワーク挙動に関係するルールを定めます。
  
   
−
==カーネルの防御==
 +
=== カーネルの自己防衛機能/脆弱性攻撃対策 ===
   
  +
{{pkg|linux-hardened}} パッケージは、[https://github.com/anthraxx/linux-hardened 基本的なカーネル堅牢化パッチセット]と、{{pkg|linux}} パッケージよりもセキュリティに重点を置いたコンパイル時設定オプションを使用します。カスタムビルドでは、セキュリティ寄りのデフォルトとは異なる、セキュリティと性能の妥協点を選択することができます。
−
===カーネルログへのアクセスを制限する===
  
   
  +
しかし、このカーネルを使うといくつかのパッケージが動かなくなることに注意する必要があります。例えば
−
カーネルログにはカーネルの脆弱性を突こうとしている攻撃者にとって有益な情報、保護が必要なメモリーアドレスなどが含まれています。{{ic|kernel.dmesg_restrict}} フラグは (デフォルトで root として実行しているプロセスしか持たない) {{ic|CAP_SYS_ADMIN}} ケイパビリティのないログへのアクセスを禁止します。
  
   
  +
* {{AUR|skypeforlinux-preview-bin}}
−
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}
  
  +
* {{AUR|skypeforlinux-stable-bin}}
  +
* {{pkg|throttled}}
   
  +
[[NVIDIA]] などのアウトオブツリードライバを使用している場合、その [[DKMS]] パッケージに切り替える必要があるかもしれません。
−
===proc ファイルシステムのカーネルポインタへのアクセスを制限する===
  
   
  +
==== ユーザー空間 ASLR の比較 ====
−
{{ic|kernel.kptr_restrict}} を有効にすると {{ic|CAP_SYSLOG}} のない通常ユーザーから {{ic|/proc/kallsyms}} のカーネルシンボルのアドレスが秘匿され、動的にアドレス・シンボルを解決するカーネル exploit が難しくなります。これは事前にコンパイルされた Arch Linux カーネルではあまり意味がありません、周到な攻撃者はカーネルパッケージをダウンロードしてそこから手動でシンボルを取得することができるからです。しかしながら自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし root 以外のユーザーで使用する場合いくつかの {{Pkg|perf}} コマンドが破壊されます (メインの {{Pkg|perf}} 機能には結局 root アクセスが必要になりますが)。詳しくは {{Bug|34323}} を見て下さい。
  
   
  +
{{pkg|linux-hardened}} パッケージは、アドレス空間配置ランダム化の改善された実装をユーザ空間のプロセスに対して提供します。{{pkg|paxtest}} コマンドを使うことで、提供されるエントロピーの推定値を得ることができます:
−
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}
  
   
  +
===== 64 ビットプロセス =====
−
===BPF JIT コンパイラを無効にする===
  
   
  +
{{hc|linux-hardened 5.4.21.a-1-hardened|
−
Linux カーネルにはパフォーマンス最適化のために BPF/Seccomp ルールセットをネイティブコードにコンパイルする機能が含まれています。最高レベルのセキュリティのために {{ic|net.core.bpf_jit_enable}} フラグは0にしておくべきです。
  
  +
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)
  +
}}
   
  +
{{hc|linux 5.5.5-arch1-1|
−
コンパイラは特定の領域では有用ですが、通常は役に立ちません。JIT コンパイラは攻撃者がヒープスプレー攻撃を行う機会を与え、カーネルのヒープが悪意のあるコードで満たされるかもしれません。このコードは不正な関数へのポインタの間接参照など、他の脆弱性攻撃によって実行される危険性があります。
  
  +
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)
  +
}}
   
  +
{{hc|linux-lts 4.19.101-1-lts|
−
{{note|[[grsecurity (日本語)|grsecurity]] には BPF JIT コンパイラの JIT ハードニングが含まれており、攻撃のリスクを大幅に減らします。}}
  
  +
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 カーネル上) =====
−
===ptrace スコープ===
  
   
  +
{{hc|linux-hardened|
−
{{ic|kernel.yama.ptrace_scope}} フラグによって、Arch は Yama LSM をデフォルトで有効にしています。このフラグはプロセスが {{ic|CAP_SYS_PTRACE}} のないスコープの外で他のプロセスに {{ic|ptrace}} コールを実行するのを止めます。多くのデバッグツールがいくつかの機能を使うためにこれを必要としますが、セキュリティの面では飛躍的な改善になります。この機能がないと、名前空間のような外部レイヤーを適用しないかぎり同一ユーザーで動作するプロセスの分割は基本的に行われません。デバッガを既存プロセスにアタッチできることはこの欠点のデモンストレーションです。
  
  +
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)
  +
}}
   
  +
{{hc|linux|
−
{{note|[[grsecurity (日本語)|grsecurity]] では、この防護は {{ic|kernel.grsecurity.harden_ptrace}} フラグによって切り替えます。}}
  
  +
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 ファイルシステム内のカーネルポインタへのアクセスを制限する ===
−
====破壊される機能の例====
  
   
  +
{{ic|kernel.kptr_restrict}} を 1 に設定すると、{{ic|CAP_SYSLOG}} を持たない通常ユーザから {{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが秘匿され、カーネルのエクスプロイトで動的にアドレス/シンボルを解決することが困難になります。これは、事前にコンパイルされた Arch Linux カーネルではあまり意味がありません。周到な攻撃者はカーネルパッケージをダウンロードして、そこから手動でシンボルを取得することができるからです。しかしながら、自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし、一部の {{Pkg|perf}} コマンドの機能が、root 以外のユーザによって使用されば場合に破壊されます (しかし、いずれにせよ多くの {{Pkg|perf}} コマンドは root アクセスを必要とします)。詳細は {{Bug|34323}} を参照してください。
−
{{Note|{{ic|sudo}} を使って特定のユーザーに、パスワード有り無しで許可を与えたりすることで、root で以下のコマンドを実行することは可能です。}}
  
   
  +
{{ic|kernel.kptr_restrict}} を 2 に設定すると、{{ic|/proc/kallsyms}} 内のカーネルシンボルのアドレスが権限に依らず隠されます。
−
* {{ic|gdb -p $PID}}
  
−
* {{ic|strace -p $PID}}
  
−
* {{ic|perf trace -p $PID}}
  
−
* {{ic|reptyr $PID}}
  
   
  +
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=
−
=== リンクの [[Wikipedia:TOCTOU|TOCTOU]] 攻撃を防止する ===
  
  +
kernel.kptr_restrict = 1
  +
}}
   
  +
{{Note|{{pkg|linux-hardened}} はデフォルトで {{ic|0}} ではなく {{ic|1=kptr_restrict=2}} を設定します。}}
−
この機能が追加された日時や根拠についてはこの [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit メッセージ]を見て下さい。
  
   
  +
=== BPF の堅牢化 ===
−
fs.protected_hardlinks = 1
  
−
fs.protected_symlinks = 1
  
   
  +
BPF は、実行時にカーネル内のバイトコードを動的にロードして実行するために使用されるシステムです。ネットワーク (XDP, tc など)、トレース (kprobes, uprobes, tracepoints など)、セキュリティ (seccomp など) など、多くの Linux カーネルサブシステムで使用されています。また、高度なネットワークセキュリティ、パフォーマンスプロファイリング、ダイナミックトレースにも有効です。
−
{{Note|現在は {{ic|/usr/lib/sysctl.d/50-default.conf}} によってデフォルトで有効にされています。}}
  
   
  +
BPF はもともと [[Wikipedia:ja:Berkeley Packet Filter|Berkeley Packet Filter]] の頭文字をとったもので、オリジナルの古典的な BPF は BSD 用のパケットキャプチャツールに使われていたためです。これは最終的に拡張 BPF (eBPF) に発展し、その後まもなくただの BPF (頭字語ではありません) に改名されました。BPFはパケットフィルタリングツールの実装に使われることがありますが、 iptables や netfilter のようなパケットフィルタリングツールと混同しないでください。
−
===hidepid===
  
   
  +
BPF のコードは解釈されるか、[[Wikipedia:ja:実行時コンパイラ|Just-In-Time (JIT) コンパイラ]]を使ってコンパイルされるかのどちらかです。Arch のカーネルは {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} でビルドされており、BPF インタープリタを無効にして全ての BPF を JIT コンパイラでコンパイルするよう強制しています。これにより、攻撃者が BPF を使って SPECTRE 型の脆弱性を悪用した特権昇格攻撃をすることが難しくなります。詳しくは、[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb CONFIG_BPF_JIT_ALWAYS_ON を導入したカーネルパッチ]を参照してください。
−
カーネルには権限がないユーザーから他のユーザーのプロセスを秘匿させる機能が存在し、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=1}} または {{ic|1=hidepid=2}} でマウントすることで有効になります。ただし、[http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html この機能は現在 systemd を破壊します]。カーネルによるコンテナの cgroups ファイルシステムの仮想化サポートが欠けているために、その対応策が必要だからです。
  
   
  +
カーネルは JIT コンパイルされた BPF に対して、パフォーマンスと多くの BPF プログラムをトレース・デバッグする能力を犠牲にして、ある種の JIT スプレー攻撃を軽減するための堅牢化機能を備えています。この機能は、{{ic|net.core.bpf_jit_harden}} を {{ic|1}} (非特権コードの堅牢化を有効化する) か {{ic|2}} (全てのコードの堅牢化を有効化する) に設定することで有効化できます。
−
===grsecurity===
  
   
  +
詳しくは、[https://docs.kernel.org/admin-guide/sysctl/net.html カーネルドキュメント] の {{ic|net.core.bpf_*}} 設定を参照してください。
−
標準の Linux カーネルは機密情報へのアクセスを必要以上に許可しておりメモリーの脆弱性攻撃への保護は最低限しか提供していません。[https://grsecurity.net/ Grsecurity] はこれを修正することを目指しています。Grsecurity には PaX のメモリーパッチがバンドルされています。PaX は ALSR を発明しており、強力な保護を提供します。Grsecurity はファイルシステムを防護し、高度なロールベースアクセス制御を提供して、せっかくの PaX のメモリー保護を無駄にするような情報漏洩を防ぎます。
  
  +
  +
{{Tip|
  +
* {{Pkg|linux-hardened}} では、デフォルトで {{ic|1=net.core.bpf_jit_harden=2}} が設定されており、{{ic|0}} ではありません。
  +
* デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには {{ic|1=kernel.unprivileged_bpf_disabled=1}} を設定してください [https://access.redhat.com/security/cve/cve-2021-33624]。
  +
}}
  +
  +
=== ptrace スコープ ===
  +
  +
{{man|2|ptrace}} システムコールは、あるプロセス ("tracer") が他のプロセス ("tracee") の実行を監視、制御し、tracee のメモリとレジスタを検査、変更するための手段を提供します。通常、{{ic|ptrace}} は ''gdb'' や ''strace''、''perf''、''reptyr'' などのデバッグツールによって使用されます。しかし、他のプロセスからデータを読んだり、他のプロセスの制御を奪ったりする手段を悪意のあるプロセスにも提供してしまいます。
  +
  +
Arch では、{{ic|kernel.yama.ptrace_scope}} [[カーネルパラメータ]]を提供する [https://docs.kernel.org/admin-guide/LSM/Yama.html Yama LSM] がデフォルトで有効化されています。このパラメータはデフォルトで {{ic|1}} (制限) に設定されており、{{ic|CAP_SYS_PTRACE}} [[ケイパビリティ]]も特権も持たない tracer が制限されたスコープ外で {{ic|ptrace}} コールを実行できないようにしています。これは、古典的なパーミッションと比べてセキュリティ上大きな改善です。このモジュールが無いと、同じユーザとして実行されているプロセスを隔てるものがなくなってしまいます ({{man|7|pid_namespaces}} などの他のセキュリティレイヤーがない場合)。
  +
  +
{{Note|デフォルトでは、[[sudo]] を使うなどして、{{ic|ptrace}} を必要とするツールを特権プロセスとして実行することができます。}}
  +
  +
デバッグツールを使う必要がない場合は、システムを堅牢化するために {{ic|kernel.yama.ptrace_scope}} を {{ic|2}} (管理者限定) や {{ic|3}} ({{ic|ptrace}} を禁止) に設定することを検討してください。
  +
  +
=== hidepid ===
  +
  +
{{Warning|
  +
* これは、サンドボックスと [[Xorg]] 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
  +
* {{Pkg|systemd}} > 237.64-1 を使用している場合、これは [[D-Bus]]、[[Polkit]]、[[PulseAudio]]、そして [[bluetooth]] で問題を発生させます。
  +
}}
  +
  +
カーネルには、{{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} オプションと {{ic|1=gid=}} オプションを使ってマウントすることで、他のユーザのプロセス (通常、{{ic|/proc}} でアクセス可能) を非特権ユーザから秘匿する機能があります。これらのマウントオプションは https://docs.kernel.org/filesystems/proc.html でドキュメント化されています。
  +
  +
これにより、侵入者が動作中のプロセスの情報 (特権で動作しているデーモンがあるか、他のユーザが機密情報を扱うプログラムを実行しているか、他のユーザがプログラムを実行しているか) を得る作業を複雑化し、ユーザが特定のプログラムを実行しているかどうかを知るのを不可能にし (ただし、そのプログラムがそれ自体の挙動で存在を他者に知られることがないとする)、さらに、貧弱に書かれたプログラムが機密情報をプログラム引数を介して渡したとしてもローカルの盗聴者から守られます。
  +
  +
{{ic|proc}} [[ユーザーとグループ#システムグループ#グループ]] ({{Pkg|filesystem}} パッケージによって提供されています) は、他のユーザのプロセス情報を得ることのできるユーザのホワイトリストとして機能します。ユーザやサービスが自身以外の {{ic|/proc/<pid>}} ディレクトリにアクセスする必要がある場合、そのユーザまたはサービスを[[ユーザーとグループ#グループ管理|proc グループに追加してください]]。
  +
  +
例えば、プロセスの情報を {{ic|proc}} グループに属さない他のユーザから隠すには:
  +
  +
{{hc|/etc/fstab|2=
  +
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
  +
}}
  +
  +
ユーザのセッションを正しく動作させるために、''systemd-logind'' を例外として追加する必要があります:
  +
  +
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
  +
[Service]
  +
SupplementaryGroups=proc
  +
}}
  +
  +
=== モジュールのロードを制限する ===
  +
  +
デフォルトの Arch カーネルは {{ic|CONFIG_MODULE_SIG_ALL}} が有効で、{{Pkg|linux}} パッケージの一部としてビルドされた全てのカーネルモジュールに署名します。これにより、カーネルは有効なキーで署名されたモジュールだけをロードするように制限できます。実際、これはローカルでコンパイルされた、もしくは {{Pkg|virtualbox-host-modules-arch}} などのパッケージによって提供された、ツリー外のモジュールは全てロードできないことを意味します。
  +
  +
カーネルモジュールの読み込みは {{ic|1=module.sig_enforce=1}} [[カーネルパラメータ]]を設定することで制限することができます。詳細は[https://docs.kernel.org/admin-guide/module-signing.html カーネルドキュメント]で見られます。
  +
  +
=== kexec を無効にする ===
  +
  +
Kexec は、現在実行中のカーネルを置き換えることを可能にします。
  +
  +
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=
  +
kernel.kexec_load_disabled = 1
  +
}}
  +
  +
{{Tip|kexec は {{pkg|linux-hardened}} でデフォルトで無効になっています。}}
  +
  +
=== カーネルロックダウンモード ===
  +
  +
Linux 5.4 から、オプションの[https://mjg59.dreamwidth.org/55105.html ロックダウン機能]がカーネルに[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d 追加されました]。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。
  +
  +
ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。
  +
  +
[[カーネル#公式サポートカーネル|公式にサポートされているカーネル]]は全て LSM を初期化しますが、ロックダウンモードを強制しません。
  +
  +
{{Tip|有効化されている LSM は {{ic|cat /sys/kernel/security/lsm}} を実行することで確認することができます。}}
  +
  +
ロックダウンには2つの動作モードがあります:
  +
  +
* {{ic|integrity}}: ユーザーランドが実行中のカーネルを変更できるカーネル機能 (kexec、bpf) は無効化されます。
  +
* {{ic|confidentiality}}: ユーザーランドがカーネルから機密情報を抽出するためのカーネルの機能も無効化されます。
  +
  +
特定の脅威モデルで指示がない限り、{{ic|integrity}} を使用することが推奨されます。
  +
  +
実行時にカーネルのロックダウンを有効にするには、以下を実行してください:
  +
  +
# echo ''mode'' > /sys/kernel/security/lockdown
  +
  +
起動時にカーネルのロックダウンを有効にするには、{{ic|1=lockdown=''mode''}} [[カーネルパラメータ]]を使用してください:
  +
  +
{{Note|
  +
* カーネルロックダウンを実行時に無効化することはできません。
  +
* カーネルロックダウンは、[[ハイバネート]]を無効化します。
  +
}}
  +
  +
{{man|7|kernel_lockdown}} も参照してください。
  +
  +
=== Linux Kernel Runtime Guard (LKRG) ===
  +
  +
[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) は、カーネルの整合性チェックとエクスプロイト行為の検出を行うカーネルモジュールです。
  +
  +
== アプリケーションのサンドボックス化 ==
  +
  +
こちらも参照 [[Wikipedia:ja:サンドボックス (セキュリティ)]]
  +
  +
{{Note|ユーザー名前空間の設定項目 {{ic|CONFIG_USER_NS}} は、現在 {{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}}、および {{Pkg|linux-hardened}} で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。}}
  +
  +
{{Warning|非特権ユーザー名前空間の使用 ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) は、{{Pkg|linux}}、{{Pkg|linux-lts}}、{{Pkg|linux-zen}} でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します([https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction AppArmorのWiki] および {{Bug|36969}} を参照。}}
  +
  +
これを軽減するためには、次のいずれかを行ってください:
  +
  +
* 安全なデフォルトを持つ {{Pkg|linux-hardened}} カーネルを使用する、または
  +
* {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] を {{ic|0}} に設定する。
  +
  +
これにより、[[Zoom Meetings|Zoom]] や {{pkg|nsjail}} などのアプリケーションが動作しなくなる場合があることに注意してください。また、システムに {{pkg|bubblewrap}} がインストールされている場合は、{{pkg|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]]、または [https://www.qubes-os.org/ Qubes OS](Xen ベース)などの完全仮想化オプションを使用することで、リスクの高いアプリケーションを実行したり、危険なウェブサイトを閲覧したりする場合に、隔離とセキュリティを強化することができます。
   
 
==ネットワークとファイアウォール==
  
==ネットワークとファイアウォール==
   
 
===ファイアウォール===
  
===ファイアウォール===
−
標準の Arch カーネルは [[Wikipedia:ja:iptables|Netfilter]] の [[iptables (日本語)|iptables]] を使用する能力がありますが、デフォルトでは有効になっていません。[[公式リポジトリ]]から {{Pkg|iptables}} をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。
  
   
  +
標準の Arch カーネルは [[Wikipedia:Netfilter|Netfilter]] の [[iptables]] および [[nftables]] を使用できますが、これらのサービスはデフォルトで [[有効化]] されていません。システム上で実行されているサービスを保護するために、何らかの形のファイアウォールを設定することを強く推奨します。多くのリソース(ArchWiki など)では、どのサービスを保護するべきかが明示的に記載されていないため、ファイアウォールを有効にすることは良い予防措置となります。
−
*全般的な情報は [[iptables (日本語)|iptables]] を見て下さい。
  
  +
−
*iptables ファイアウォールを設定するガイドは [[Simple stateful firewall]] を見て下さい。
  
  +
* 一般的な情報については [[iptables]] および [[nftables]] を参照してください。
−
*netfilter を設定する他の方法は[[ファイアウォール]]を見て下さい。
  
  +
* iptables ファイアウォールの設定方法については [[シンプルなステートフルファイアウォール]] を参照してください。
  +
* netfilter の設定方法については [[ファイアウォール]] を参照してください。
  +
* Bluetack などの IP アドレスリストをブロックするには [[Ipset]] を参照してください。
  +
* {{Pkg|opensnitch}} は、アプリケーション、ポート、ホストなどによる設定可能なルールをサポートする、構成可能なインバウンドおよびアウトバウンドファイアウォールです。
  +
  +
==== ポートを開く ====
  +
  +
一部のサービスは、開かれたネットワークポートでインバウンドトラフィックを待ち受けます。これらのサービスは、必要最低限のアドレスとインターフェースにのみバインドすることが重要です。リモート攻撃者が [https://samy.pl/slipstream/ ネットワークプロトコルの欠陥を悪用して公開されたサービスにアクセスする] 可能性があります。これは、[https://nvd.nist.gov/vuln/detail/CVE-2019-13450 localhost にバインドされたプロセス] にも発生することがあります。
  +
  +
一般的に、サービスがローカルシステムのみでアクセス可能であれば、非ループバックアドレス(例えば {{ic|0.0.0.0/0}})ではなく、Unix ドメインソケット({{man|7|unix}})や {{ic|localhost}} のようなループバックアドレスにバインドするべきです。
  +
  +
サービスがネットワーク越しに他のシステムからアクセス可能である必要がある場合、厳格な [[ファイアウォール]] ルールでアクセスを制御し、可能な限り認証、認可、暗号化を構成することが重要です。
  +
  +
現在のすべてのオープンポートをリストするには、{{ic|ss -l}} を使用できます。すべてのリスニング中のプロセスとその数値的な TCP および UDP ポート番号を表示するには:
  +
  +
# ss -lpntu
  +
  +
その他のオプションについては、{{man|8|ss}}を参照してください。
   
 
===カーネルパラメータ===
  
===カーネルパラメータ===
−
ネットワークに影響を与えるカーネルパラメータは [[Sysctl (日本語)|Sysctl]] を使って設定できます。設定方法は [[Sysctl (日本語)#TCP/IP スタックの防御]] を見て下さい。
 +
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。
   
 
===SSH===
  
===SSH===
−
[[SSH keys#Disabling password logins|SSH 鍵を必要]]としない [[Secure Shell (日本語)|Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban (日本語)|Fail2ban]] や [[Sshguard (日本語)|Sshguard]] はログを監視して [[Iptables (日本語)|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
 +
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
   
  +
二段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する二段階認証方式を提供します。
−
[[Secure Shell (日本語)#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
  
  +
  +
[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
   
 
===DNS===
  
===DNS===
263行目: 717行目:
 
[[DNSSEC]] や [[DNSCrypt]] を見て下さい。
  
[[DNSSEC]] や [[DNSCrypt]] を見て下さい。
   
  +
=== プロキシ ===
−
==パッケージの認証==
  
  +
−
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key (日本語)|Pacman-key]] を見て下さい。
  
  +
プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。
  +
  +
例えば {{Pkg|glibc}} の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。[[dnsmasq]] などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]。
  +
  +
=== SSL 証明書の管理 ===
  +
  +
サーバーサイドの SSL 証明書の管理については [[OpenSSL]] や [[Network Security Services]] (NSS) を参照してください。また、関連する [[Let’s Encrypt]] プロジェクトも見てください。
  +
  +
デフォルトのインターネット SSL 証明書のトラストチェーンは {{Pkg|ca-certificates}} パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{AUR|ca-certificates-cacert}}, {{Pkg|ca-certificates-mozilla}}) に依存しています。
  +
  +
デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、[http://www.theregister.co.uk/2016/05/27/blue_coat_ca_certs/ ニュース] を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
  +
# {{ic|.crt}} 形式の証明書を入手してください (例: [https://crt.sh/?id=19538258 view], [https://crt.sh/?d=19538258 download]; 既存のルート認証局の場合、システム内にあるはずです)。
  +
# {{ic|/etc/ca-certificates/trust-source/blacklist/}} にコピーしてください。
  +
# root で ''update-ca-trust'' を実行してください。
  +
  +
お好きなブラウザを開いて'''信頼できない'''サイトとして表示されれば、ブラックリストが上手く機能しています。
  +
  +
== 物理セキュリティ ==
   
−
==物理セキュリティ==
  
 
{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}
  
{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}
   
 
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。
  
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで''実用的で''高いレベルのセキュリティを得ることができます。
   
−
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐために出来ることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
 +
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [http://www.breaknenter.org/projects/inception/]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
   
 
[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
  
[[#ディスク暗号化|ディスク暗号化]]はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
277行目: 748行目:
 
===BIOS をロックダウンする===
  
===BIOS をロックダウンする===
   
−
BIOS にパスワードを追加することによってリムーバルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
 +
BIOS にパスワードを追加することによってリムーバブルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
   
−
===ブートローダー===
 +
=== ブートローダー ===
   
−
ブートローダーの保護はとても重要です。{{ic|1=init=/bin/sh}} というたった一つのカーネルパラメータで、全てのユーザー・ログイン制限が全くの無に帰します。
 +
[[Arch ブートプロセス#ブートローダー|ブートローダー]] を保護することは非常に重要です。保護されていないブートローダは、例えば {{ic|1=init=/bin/sh}} を設定することでログインの制限を回避することができます。[[カーネルパラメータ]] でシェルに直接ブートするようにします。
   
−
====Syslinux====
 +
==== Syslinux ====
   
−
Syslinux は[[Syslinux (日本語)#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
 +
Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
   
−
====GRUB====
 +
==== GRUB ====
   
−
[[GRUB (日本語)|GRUB]] も同じくブートローダーのパスワードをサポートしています。詳しくは [[GRUB (日本語)#GRUB メニューのパスワード保護|GRUB#GRUB メニューのパスワード保護]] を見て下さい。
 +
[[GRUB]] はブートローダのパスワードもサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護|GRUB メニューのパスワード保護]] を参照してください。[[GRUB/ヒントとテクニック# GRUB メニューのパスワード保護|暗号化 /boot]] もサポートしていますが、これはブートローダコードの一部だけを暗号化しないままにしています。GRUB の設定、[[カーネル]]、[[initramfs]] は暗号化されています。
   
  +
==== systemd-boot ====
−
===root でのコンソールログインを拒む===
  
−
コンソールからの root ログインを拒否するよう設定を変更すれば侵入者がシステムへのアクセスを取得するのを難しくすることができます。侵入者はシステムに存在するユーザーの名前とそのユーザーのパスワードを考えなくてはならなくなります。コンソールによって root がログインできるようになっている場合、侵入者が解き当てるのはパスワードだけで十分になります。
  
−
コンソールの root ログインのブロックは {{ic|/etc/securetty}} の tty 行をコメントアウトすることで行います。
  
−
{{hc|/etc/securetty|
  
−
#tty1
  
−
}}
  
   
  +
[[systemd-boot]] は [[#セキュアブート]] が有効な場合、カーネルパラメータの編集を無効にします。代わりの方法として、[[systemd-boot#パスワードで保護されたカーネルパラメータエディタ]] を参照して下さい、より伝統的なパスワードベースのオプションを使用できます。
−
ブロックしたい tty 全てで同じようにコメントアウトしてください。
  
  +
−
変更の効果を確認するには、一つの行だけをコメントアウトしてから特定のコンソールに移って root でのログインを試行してみてください。{{ic|Login incorrect}} というメッセージが表示されるはずです。ブロックされたことを確認したら、戻ってから残りの tty 行をコメントアウトしてください。
  
  +
=== セキュアブート ===
−
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}
  
  +
  +
[[セキュアブート]] は [[UEFI]] の機能で、コンピュータが起動するファイルの認証を可能にするものです。これは、起動パーティション内のファイルを置き換えるような、いくつかの [https://ja.wikipedia.org/wiki/%E6%82%AA%E6%84%8F%E3%81%82%E3%82%8B%E3%83%A1%E3%82%A4%E3%83%89%E6%94%BB%E6%92%83 悪意あるメイド攻撃] を防止するのに役立つ。通常、コンピュータにはベンダー (OEM) によって登録されたキーが付属しています。しかし、これを取り外して、コンピュータを「セットアップモード」にし、ユーザーが自分のキーを登録・管理できるようにすることができます。
  +
  +
セキュアブートのページでは、[https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Implementing_Secure_Boot using your own keys] によってセキュアブートを設定する方法を案内しています。
  +
  +
=== トラステッドプラットフォームモジュール(TPM) ===
  +
  +
[[Trusted Platform Module|TPM]] は、暗号鍵が埋め込まれたハードウェア・マイクロプロセッサです。これは、最近のほとんどのコンピュータの基本的な信頼性の根源を形成し、ブートチェーンのエンドツーエンドの検証を可能にします。内部スマートカードとして使用したり、コンピュータ上で動作するファームウェアを証明したり、改ざん防止とブルートフォース耐性のあるストアにユーザーがシークレットに挿入することができます。
  +
  +
=== リムーバブル フラッシュ ドライブ上のブートパーティション ===
  +
  +
ブートパーティションをフラッシュドライブに置き、それがないとシステムが起動しないようにする、というのはよくあるアイデアです。このアイデアの支持者はしばしば [[セキュリティ#ディスク暗号化|ディスク暗号化]] を併用し、ブートパーティションに置かれた [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USBdetached encryption headers] を使っている人もいます。
  +
  +
この方法は [https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB encrypting /boot] と統合することも可能です。
   
 
=== 自動ログアウト ===
  
=== 自動ログアウト ===
−
[[Bash (日本語)|Bash]] または [[Zsh (日本語)|Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。
 +
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。
   
 
例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):
  
例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):
320行目: 800行目:
   
 
シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。
  
シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。
  +
  +
=== 不正なUSBデバイスから保護する ===
  +
  +
[[Usbguard]] は、デバイスの属性に基づく基本的なホワイトリストおよびブラックリスト機能を実装することで、不正な USB デバイス (別名 [https://ja.wikipedia.org/wiki/BadUSB BadUSB], [https://github.com/samyk/poisontap PoisonTap] または [https://lanturtle.com/ LanTurtle]) からコンピューターを保護できるソフトウェアフレームワークです。
  +
  +
=== 揮発性データの収集 ===
  +
  +
電源が入っているコンピュータは、[https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection] に対して脆弱である可能性があります。コンピュータの電源を入れる必要がない時や、コンピュータの物理的な安全性が一時的に損なわれる場合(例:セキュリティチェックポイントを通過する時)には、コンピュータの電源を完全に切ることがベストプラクティスです。
  +
  +
== パッケージ ==
  +
  +
=== パッケージの認証 ===
  +
パッケージの署名が適正に使われていないと [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview パッケージマネージャへの攻撃] が考えられ、さらに [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html 適切な署名システム] を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは [[Pacman-key]] を見て下さい。
  +
  +
=== アップグレード ===
  +
  +
定期的に [[システムメンテナンス#システムのアップグレード|システムのアップグレード]] を行うことが重要です。
  +
  +
=== 脆弱性アラートの確認 ===
  +
  +
National Vulnerability Database が提供する Common Vulnerabilities and Exposure (CVE) Security Alert の更新を購読し、[https://nvd.nist.gov/download.cfm NVD Download webpage] で見つけてください。[https://security.archlinux.org/ Arch Linux Security Tracker] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットを表形式でまとめた、特に有用なリソースです。ツール {{Pkg|arch-audit}} は実行中のシステムに影響を与える脆弱性をチェックするために使われます。グラフィカルなシステムトレイである {{Pkg|arch-audit-gtk}} も使うことができます。[https://wiki.archlinux.org/title/Arch_Security_Team Arch Security Team]も参照してください。
  +
  +
特にメインレポジトリや AUR 以外の手段でソフトウェアをインストールしている場合は、あなたが使っているソフトウェアのリリース通知を購読することも検討すべきです。いくつかのソフトウェアには、セキュリティに関する通知を受け取るために購読できるメーリングリストがあります。ソースコードホスティングサイトはしばしば新しいリリースの RSS フィードを提供しています。
  +
  +
=== パッケージの再ビルド ===
  +
  +
攻撃対象領域を減らす手段として、パッケージをリビルドし、不要な関数や機能を削除することができます。例えば、{{Pkg|bzip2}} は [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] を回避するために {{ic|bzip2recover}} を使わずにリビルドすることが可能です。カスタムハードニングフラグは、手動またはラッパーを介して適用することもできます。
  +
  +
{| class="wikitable"
  +
! フラグ !! 目的
  +
|-
  +
| -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 || 移設後の読み出し専用セグメント
  +
|}
  +
  +
* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info ソース]
   
 
== 参照 ==
  
== 参照 ==
   
  +
* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
−
* [[DeveloperWiki:Security]]
  
−
* ArchWiki のセキュリティアプリケーションのリスト: [[List_of_Applications/Security (日本語)|Lists of Applications: Security]]
 +
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
  +
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
−
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]
  
−
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]
 +
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
−
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]
 +
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]
  +
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux ワークステーションのセキュリティチェックリスト]
−
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]
  
  +
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
−
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]
  
  +
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
−
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
  
−
* [http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Hardening Debian (pdf)]
 +
* [https://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Debian 安全化マニュアル (PDF)]
 
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
  
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
  +
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

2025年4月10日 (木) 00:33時点における最新版

関連記事

この記事には、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 パスワードハッシュ を参照してください)

ヒント: Arch Linux は デフォルトのハッシュアルゴリズムを yescrypt に変更しました。もしデフォルトをカスタマイズしていない場合は、passwd を実行してパスワード変更を行うなどして下さい。

パスワードデータベースをバックアップする場合、そのコピーが他のパスフレーズで保護されていないことを確認してください。例えば、暗号化されたドライブや認証されたリモートストレージサービスなどです。もしそのような保護が施されている場合、必要なときにアクセスできなくなります。役立つ方法としては、データベースがバックアップされているドライブやアカウントをマスターパスワードの簡単な暗号学的ハッシュで保護することです。バックアップ場所のリストを保持してください。もしもマスターパスワードが漏洩したと疑われる場合、その場所すべてでパスワードを即座に変更し、マスターパスワードから導出された鍵で保護されたすべてのバックアップと場所も変更する必要があります。

データベースをセキュアにバージョン管理するのは非常に複雑な場合があります。もしその方法を選択するなら、すべてのデータベースバージョンでマスターパスワードを更新する手段を持っている必要があります。マスターパスワードが漏洩したときにそれを即座に知るのは難しいことがあります。他の人がパスワードを発見するリスクを減らすために、定期的にパスワードを変更することを選ぶかもしれません。もしデータベースのコピーの管理が失われたと感じた場合、そのコピーがブルートフォース攻撃によってマスターパスワードを解読される前に、そのデータベース内のすべてのパスワードを変更する必要があります。

パスワードのハッシュ

ハッシュは一方向の関数です。つまり、入力を計算せずにそのハッシュを解読することは不可能になるように設計されています (例: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_pwquality は、辞書攻撃に対する保護を提供し、システム全体で強制できるパスワードポリシーを設定するのに役立ちます。これは pam_cracklib をベースにしており、そのオプションとの後方互換性があります。

libpwquality パッケージをインストールしてください。

警告: デフォルトでは、root アカウントはこのポリシーの影響を受けません。
ノート:
  • root アカウントを使用すると、設定したパスワードポリシーをバイパスするユーザーパスワードを設定できます。これは一時的なパスワードを設定する際に便利です。
  • 現在のパスワードに関するセキュリティガイドライン(例:NISTなど)では、特別な文字を強制することは推奨されていません。なぜなら、それらはしばしば予測可能な変更を引き起こすだけだからです。

例えば、以下のポリシーを強制したい場合:

  • エラーが発生した場合にパスワードを2回入力する (retry オプション)
  • 最小長10文字 (minlen オプション)
  • 新しいパスワードを入力する際、古いパスワードとは少なくとも6文字異なること (difok オプション)
  • 最低1桁の数字 (dcredit オプション)
  • 最低1つの大文字 (ucredit オプション)
  • 最低1つの小文字 (lcredit オプション)
  • 最低1つのその他の文字 (ocredit オプション)
  • "myservice" および "mydomain" という単語を含めない
  • root にもこのポリシーを強制する

/etc/pam.d/passwdファイルを以下のように編集します: 

#%PAM-1.0
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root
password required pam_unix.so use_authtok sha512 shadow

password required pam_unix.so use_authtok は、pam_unix モジュールに対してパスワードの入力を促さず、代わりに pam_pwquality で提供されたものを使用するように指示します。

詳細については、pam_pwquality(8) および pam_unix(8) のマニュアルページを参照してください。

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 などが動作しなくなります。
      • Wine は Windows バイナリの実行に exec フラグを必要としません。ただし、Wine 自体を /home にインストールする場合は必要です。
      • Steam を動作させるには、/home/user/.local/share/Steam を fstab で exec としてマウントできます。以下の設定を追加してください: 
        /home/user/.local/share/Steam /home/user/.local/share/Steam none defaults,bind,user,exec,nofail 0 0
    • 一部のパッケージ(例:nvidia-dkms のビルド)では、/var に exec が必要な場合があります。

データ用のファイルシステムは、常に nodev、nosuid、noexec を指定してマウントするべきです。

マウントを検討すべきファイルシステム:

  • /var
  • /home
  • /dev/shm
  • /tmp
  • /boot
ヒント: GPT パーティションの自動マウント を使用する場合、ESP および XBOOTLDR パーティションは 常に noexec,nosuid,nodev で強化 されます。

スナップショット

ファイルシステムのスナップショットを利用する場合(例えば Btrfs、LVM、ZFS など)、スナップショットがユーザーが削除したと期待している機密情報を保持する可能性があることを理解することが重要です。特に、Snapper のような自動スナップショットツールを設定している場合、定期的またはシステムイベントに応じてスナップショットが作成されるため、この問題が発生しやすくなります。

以下は、/home/ 内の機密情報がスナップショットに残存する例です:

  • 削除されたファイルやディレクトリ: ファイルシステム上から削除されたとしても、古いスナップショット内には残存している可能性があります。これは通常想定される動作ですが、.local/share/Trash/、.history などのファイルやディレクトリを保持する必要があるかどうかを検討すべきです。
  • 一時ファイルやキャッシュ: アプリケーションによって生成された一時ファイルやキャッシュデータもスナップショットに含まれる可能性があります。例えば、暗号化されたディレクトリ内のファイルを開くと、サムネイル(.cache/thumbnails)や作業用のコピーが作成され、それらがスナップショットに含まれる可能性があります。同様に、ブラウザの履歴(.mozilla/、.config/chromium/ など)も、削除される前にスナップショットに記録されている場合があります。

対応可能であれば、これらのディレクトリをスナップショットの対象から完全に除外することを検討してください。例えば、Btrfs を使用している場合、.cache/、.config/、.local/、.var/ など、用途に応じたディレクトリをサブボリュームとして作成することで、スナップショットの影響を受けにくくできます。

ノート: .local/share/Trash を別のサブボリュームに移動すると、場合によっては GNOME/Files などでゴミ箱の機能が正常に動作しなくなる可能性があります。

ファイルシステムのパーミッション

デフォルトの パーミッション では、ほとんどのファイルが読み取り可能になっていますが、これを変更することで、http ユーザーや nobody ユーザーなどの非 root アカウントに侵入した攻撃者から貴重な情報を隠すことができます。chmod を使用して、グループやその他のユーザーからすべてのアクセス権を削除できます。 

# chmod go-r path_to_hide
警告: この設定を広範囲に適用しないでください。1つの設定ファイルごとに適用し、非表示にする価値があるか、プログラムの動作に影響しないかを確認してください。グループが必要な場合は、g をコマンドから削除するか、既に実行してしまった場合は chmod g+r path で再度許可を追加する必要があるかもしれません。

考慮すべきパスの例:

また、新しく作成されるファイルのセキュリティを向上させるために、デフォルトの umask 値 0022 を変更することも可能です。NSA RHEL5 Security Guide では最大限のセキュリティを確保するために、0077 を推奨しており、これにより所有者以外のユーザーが新しいファイルを読み取れなくなります。変更方法については Umask#マスクの値を設定 を参照してください。

さらに、sudo を使用する場合、デフォルトの root umask を適用するよう設定することを検討してください。

SUID ファイルと SGID ファイル

Setuid ビットや Setgid ビットが設定されたファイルには注意しましょう。このようなファイルの例としては、以下があります。

このような実行ファイルの主なリスクとして、特権昇格の脆弱性があります。例えば Wikipedia:Setuid#Security impact を参照してください。[4][5][6]

SUID ビットが設定されているが root によって所有されていないファイル、または SGID ビットが設定されているファイルは、典型的には潜在的なリスクがより小さいですが、理論上、そのようなファイルに脆弱性が存在している場合は、依然として損害を与える可能性があります。通常、代わりにケイパビリティを割り当てることによって、Setuid や Setgid の使用を回避することが可能です。

ヒント: SUID/SGID 実行ファイルを含むパッケージを最新に保って、脆弱性からシステムを守ることが肝心です。

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)
ノート: deny = 0 はロックアウトを無効化します

デフォルトでは、すべてのユーザーロックは再起動後に失われます。攻撃者がマシンをリブートできるのであれば、ロックは持続させた方が安全です。ロックを持続させるには、/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 コマンドを実行できるようになります。

ヒント: visudo で vi の代わりに nano を使うには: 
/etc/sudoers
Defaults editor=/usr/bin/rnano

# EDITOR=nano visudo のエクスポートは何にでも EDITOR として使うことができるためにセキュリティリスクとされています。

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
ノート: linux-hardened はデフォルトで 0 ではなく kptr_restrict=2 を設定します。

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_* 設定を参照してください。

ヒント:
  • linux-hardened では、デフォルトで net.core.bpf_jit_harden=2 が設定されており、0 ではありません。
  • デフォルトでは、BPF プログラムは非特権ユーザでも実行可能です。この挙動を変更するには kernel.unprivileged_bpf_disabled=1 を設定してください [7]。

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) などの他のセキュリティレイヤーがない場合)。

ノート: デフォルトでは、sudo を使うなどして、ptrace を必要とするツールを特権プロセスとして実行することができます。

デバッグツールを使う必要がない場合は、システムを堅牢化するために kernel.yama.ptrace_scope を 2 (管理者限定) や 3 (ptrace を禁止) に設定することを検討してください。

hidepid

警告:
  • これは、サンドボックスと Xorg 内で実行するアプリケーションなど、特定のアプリケーションで問題を発生させる場合があります (回避策を見てください)。
  • systemd > 237.64-1 を使用している場合、これは D-Bus、Polkit、PulseAudio、そして bluetooth で問題を発生させます。

カーネルには、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
ヒント: kexec は linux-hardened でデフォルトで無効になっています。

カーネルロックダウンモード

Linux 5.4 から、オプションのロックダウン機能がカーネルに追加されました。これは、UID 0 (root) とカーネルの間の境界を強化することを目的としています。この機能を有効にすると、ハードウェアやカーネルへの低レベルなアクセスに依存している一部のアプリケーションは動作しなくなる可能性があります。

ロックダウンを使用するには、LSM が初期化され、ロックダウンモードが設定されている必要があります。

公式にサポートされているカーネルは全て LSM を初期化しますが、ロックダウンモードを強制しません。

ヒント: 有効化されている LSM は cat /sys/kernel/security/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:サンドボックス (セキュリティ)

ノート: ユーザー名前空間の設定項目 CONFIG_USER_NS は、現在 linux、linux-lts、linux-zen、および linux-hardened で有効になっています。これが無効だと、一部のアプリケーションで特定のサンドボックス機能が利用できなくなる可能性があります。
警告: 非特権ユーザー名前空間の使用 (CONFIG_USER_NS_UNPRIVILEGED) は、linux、linux-lts、linux-zen でデフォルトで有効になっています。これにより、ローカル特権昇格の攻撃対象が大幅に拡大します(AppArmorのWiki および FS#36969 を参照。

これを軽減するためには、次のいずれかを行ってください:

  • 安全なデフォルトを持つ linux-hardened カーネルを使用する、または
  • kernel.unprivileged_userns_clone sysctl を 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

DNSSEC や DNSCrypt を見て下さい。

プロキシ

プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。

例えば glibc の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。dnsmasq などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [8]。

SSL 証明書の管理

サーバーサイドの SSL 証明書の管理については OpenSSL や Network Security Services (NSS) を参照してください。また、関連する Let’s Encrypt プロジェクトも見てください。

デフォルトのインターネット SSL 証明書のトラストチェーンは ca-certificates パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: ca-certificates-cacertAUR, ca-certificates-mozilla) に依存しています。

デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、ニュース を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:

  1. .crt 形式の証明書を入手してください (例: view, download; 既存のルート認証局の場合、システム内にあるはずです)。
  2. /etc/ca-certificates/trust-source/blacklist/ にコピーしてください。
  3. root で update-ca-trust を実行してください。

お好きなブラウザを開いて信頼できないサイトとして表示されれば、ブラックリストが上手く機能しています。

物理セキュリティ

ノート: リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。

十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで実用的で高いレベルのセキュリティを得ることができます。

攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [9]。これを防ぐためにできることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。

ディスク暗号化はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。

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 移設後の読み出し専用セグメント

参照

「https://wiki.archlinux.jp/index.php?title=セキュリティ&oldid=40159」から取得