セキュリティ

2017-12-24T13:44:55Z

Ngkz: /* 3回ログインを失敗したユーザーをロックアウトする */ 英語版から節をインポート

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[fa:امنیت]]
[[ru:Security]]
{{Related articles start}}
{{Related|PAM}}
{{Related|ケイパビリティ}}
{{Related|アプリケーション一覧/セキュリティ}}
{{Related|:カテゴリ:セキュリティ}}
{{Related articles end}}
この記事では Arch Linux システムを防御するための推奨事項とベストプラクティスを並べています。

==概念==
*セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
*セキュリティを高めるために出来ることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
*少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
*[[Wikipedia:ja:最小権限の原則|最小権限の原則]]: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。

==パスワード==
パスワードは安全な linux システムのかぎです。パスワードは[[ユーザーとグループ|ユーザーアカウント]], [[ディスク暗号化|暗号化されたファイルシステム]], [[SSH 鍵|SSH]]/[[GPG]] 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。

===強力なパスワードの選び方===

パスワードは簡単に[[Wikipedia:ja:パスワードクラック|割り出されたり]]または個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードは出来るだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。

{{Pkg|pwgen}} や {{Pkg|apg}} などのツールは安全なパスワードを生成するのに役立ちます。

また、ある文章の各単語の一番最初を取ってパスワードを作ることもできます。
例えば “the girl is walking down the rainy street” なら “t6!WdtR5” とパスワードにすることができます。この方法はパスワードを覚えるのをずっと簡単にしてくれます。さらに、入力するのが面倒くさくなりますがパスワードを “The girl is walking down the rainy street" にすることも可能です。

===パスワードの管理===
強固なパスワードを選び出したら、それを安全に保管してください。[[Wikipedia:ja:ソーシャル・エンジニアリング|心理操作]]や[[Wikipedia:Shoulder surfing (computer security)|ショルダーサーフィン]]に注意したり、セキュアでないサーバーから必要以上に情報が流出するのをふせぐためにパスワードを再利用しないようにしてください。{{Pkg|pass}}, {{Pkg|keepassx}}, {{Pkg|gnome-keyring}} などのツールは大量の複雑なパスワードを管理するのに役立ちます。[[Wikipedia:ja:LastPass|Lastpass]] はデバイス間で同期するためにオンラインで暗号化されたパスワードを保存するサービスですが、クローズドソースのコードと外部の企業の両方を信頼する必要があります。

概して、安全なパスワードは覚えにくいからといって安全でないパスワードを使ってはいけません。パスワードはバランスを取る必要があります。弱いパスワードをたくさん作るよりは、安全なパスワードの暗号化されたデータベースを作り、一つの強いマスターパスワードで守るほうが良いでしょう。パスワードを紙に書くのも、物理的なセキュリティを必要としますがソフトウェアの脆弱性を防ぐ点では同じくらい有効です [https://www.schneier.com/blog/archives/2005/06/write_down_your.html]。

===パスワードのハッシュ===
{{Warning|SHA512 は高速なハッシュ関数として設計されており、パスワードのハッシュ用には作られていません。bcrypt や scrypt などに比べて SHA512 によってハッシュ化されたパスワードには攻撃者は''はるかに''高速にブルートフォース攻撃をすることができます。}}

デフォルトの Arch のハッシュ [[SHA パスワードハッシュ|sha512]] はとても強固で変更する必要はありません。デフォルトでは、{{ic|/etc/shadow}} にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、{{ic|/etc/passwd}} にはユーザー識別子だけが保存されます。従って、[[#root の制限|root ユーザーが安全]]である限り、ファイルが外部システムにコピーされたり解読されることはありえません。

[http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)] も参照してください。

=== pam_cracklib を用いた強力なパスワードの強制 ===

''pam_cracklib'' は[[Wikipedia:ja:辞書攻撃|辞書攻撃]]からの防御を提供し、システム全体で強制するパスワードポリシーの設定を補助します。

{{Warning|''root'' アカウントはこのポリシーの影響を受けません。}}
{{Note|''root'' アカウントを利用することで望ましい/設定されたポリシーを迂回したユーザーのパスワードを設定することができます。これは一時的なパスワードを設定するときに便利です。}}

例えば以下のようなポリシーを強制させたい場合:
* エラー時に2回パスワードプロンプト
* 最小で10文字の長さ (minlen オプション)
* 新しくパスワードを設定する場合、少なくとも6文字は古いパスワードと異なる (difok オプション)
* 少なくとも1文字数字を含む (dcredit オプション)
* 少なくとも1文字は大文字を含む (ucredit オプション)
* 少なくとも1文字は異なる文字を含む (ocredit オプション)
* 少なくとも1文字は小文字を含む (lcredit オプション)

{{ic|/etc/pam.d/passwd}} ファイルを以下のように書き換えます:
{{bc|1=
#%PAM-1.0
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow
}}

{{ic|password required pam_unix.so use_authtok}} でパスワードのプロンプトを表示するときに ''pam_unix'' モジュールではなく ''pam_cracklib'' によるプロンプトを使うようになります。

詳細な情報については pam_cracklib(8) と pam_unix(8) の man ページを参照してください。

== ストレージ ==

===ディスク暗号化===

[[ディスク暗号化]]、特に[[#パスワード|強固なパスフレーズ]]による完全ディスク暗号化は、物理的なリカバリからデータを守る唯一の方法です。コンピュータの電源がオフになっていて問題のディスクがアンマウントされている時は完璧なセキュリティを提供します。

しかしながら、コンピュータの電源が入れられてドライブがマウントされると、そのデータは暗号化されていないドライブと同じように無防備になります。そのためデータが必要なくなったときはすぐにデータのパーティションをアンマウントするのが最善です。

[[Dm-crypt]] など特定のプログラムでは、ループファイルを物理ボリュームとして暗号化することができます。これはシステムの特定部分だけを守りたいときに完全なディスク暗号化の代わりの選択肢となりえます。

=== ファイルシステム ===

現在カーネルは {{ic|fs.protected_hardlinks}} や {{ic|fs.protected_symlinks}} sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。

それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには {{ic|/var}} や {{ic|/tmp}} などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。

====マウントオプション====

最小権限の原則に従って、パーティションは (機能性を失わない限りで) 最も制限的なマウントオプションを使ってマウントすると良いでしょう。

*{{ic|nodev}}: ファイルシステム上のキャラクタ・ブロック特殊デバイスを解釈しない。
*{{ic|nosuid}}: set-user-identifier や set-group-identifier ビットの効果を許可しない。
*{{ic|noexec}}: マウントされたファイルシステム上の全てのバイナリの直接実行を許可しない。

{{Note|データパーティションはいつでも {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}} でマウントするべきです。}}

{| class="wikitable"
| align="center" |'''パーティション'''
| align="center" |{{ic|nodev}}
| align="center" |{{ic|nosuid}}
| align="center" |{{ic|noexec}}
|-
| {{ic|/var}}||yes||yes||yes [1] [2]
|-
| {{ic|/home}}||yes||yes||yes (wine や steam を使用しない場合 [2])
|-
| {{ic|/dev/shm}}||yes||yes||yes
|-
| {{ic|/tmp}}||yes||yes||no (パッケージをコンパイルできなくなる可能性があります)
|-
| {{ic|/boot}}||yes||yes||yes
|-
|}

[1] パッケージによっては (例えば {{Pkg|nvidia-dkms}}) {{ic|/var}} で {{ic|exec}} を必要とすることがあるので注意してください。

[2] {{ic|noexec}} がパーティションに設定されている場合、Qt 5.8 以上では QML を使用するアプリケーションがクラッシュしたり機能しなくなることがあります。解決方法は [[Qt#Qt 5.8 で QML を使用するアプリケーションがクラッシュあるいは動作しない]]を参照。

===ファイルシステムのパーミッション===
デフォルトのファイルシステムのパーミッションはほぼ全ての読み取りアクセスが許可されているため、[[パーミッション]]を変更することで {{ic|http}} や {{ic|nobody}} ユーザーなど root 以外のアカウントへのアクセスを手に入れた攻撃者から重要な情報を隠すことができます。

例えば:

# chmod 700 /boot /etc/{iptables,arptables}

デフォルトの [[Umask]] を変更することで新しく作成したファイルのセキュリティを向上させることができます。[http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] はセキュリティを最大化させるために {{ic|077}} の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、[[Umask#マスクの値を設定]]を参照してください。

==ユーザー設定==
インストールした後は日常の使用のために通常ユーザーを作成してください。root ユーザーを常用してはいけません。

===3回ログインを失敗したユーザーをロックアウトする===
セキュリティをさらに高めるために、指定した回数ログインを失敗したユーザーをログインできなくすることが可能です。root ユーザーがロックを解除するまでそのユーザーアカウントにロックをかけるか、または設定した時間が経つと自動でロックが解除されるように設定できます。
3回ログインを失敗したユーザーを10分間ログインできないようにするには {{ic|/etc/pam.d/system-login}} を変更する必要があります:

{{hc|/etc/pam.d/system-login|
2=auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed
#auth required pam_tally.so onerr=succeed file=/var/log/faillog
}}

2行目のコメントを消すとログインの失敗ごとに2度カウントされるようになります。これだけです。冒険心を味わいたければ、ログインを3回失敗してみてください。それで何が起こるか分かるはずです。手動でユーザーのロックを解除するには次を実行してください:

# pam_tally2 --user ''username'' --reset

3回ログインが失敗したユーザーを永遠にログインできないようにしたい場合 {{ic|unlock_time}} の部分を削除してください。こうすると root がアカウントをアンロックするまでログインできなくなります。

=== プロセスの数を制限する ===

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。{{ic|prlimit}} コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。

* soft nproc 100
* hard nproc 200

== root の制限 ==
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。

===su の代わりに sudo を使う===
[[Su#セキュリティ|色々な理由]]から特権アクセスには [[su]] よりも [[sudo]] を使うほうが好ましいとされます。

* 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
* root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
* 完全な root ターミナルは作成されないため、{{ic|sudo}} は root アクセスが必要ないコマンドを偶発的に ''root'' で実行してしまうことを防止します。これは[[Wikipedia:ja:最小権限の原則|最小権限の原則]]と合っています。
* 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー ''alice'' に特定のプログラムへのアクセス権限を与えるには:

# visudo

{{hc|/etc/sudoers|
alice ALL = NOPASSWD: /path/to/program}}

また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から {{ic|/sbin/mount.cifs}} や {{ic|/sbin/umount.cifs}} コマンドを実行できるようになります。

{{Tip|{{ic|visudo}} で {{ic|vi}} の代わりに {{ic|nano}} を使うには:

{{hc|/etc/sudoers|
2=Defaults editor=/usr/bin/rnano
}}
{{ic|1=# EDITOR=nano visudo}} のエクスポートは何にでも {{ic|EDITOR}} として使うことができるためにセキュリティリスクとされています。
}}

====sudo を使ってファイルを編集する====
root で {{ic|vim}} などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:

export SUDO_EDITOR=rvim

ファイルの編集には {{ic|sudoedit filename}} または {{ic|sudo -e filename}} を使って下さい。自動的に {{ic|rvim}} によって {{ic|filename}} が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。

===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}} と {{ic|/etc/pam.d/su-l}} の両方を編集して次の行をアンコメントしてください:
{{bc|<nowiki>
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
</nowiki>}}
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。

====ssh ログインを拒否する====
ローカルユーザーの root ログインを拒否したくない場合でも、[[SSH#root ログインを拒否する|SSH による root ログインを拒否]]するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。

==強制アクセス制御==

[[Wikipedia:ja:強制アクセス制御|強制アクセス制御]] (Mandatory Access Control, MAC) は Arch やほとんどの Linux ディストリビューションで使われている[[Wikipedia:ja:任意アクセス制御|任意アクセス制御]] (Discretionary Access Control, DAC) とは大きく異なるタイプのセキュリティポリシーです。原則的に MAC ではシステムに影響を与えるプログラムの行動は全てセキュリティルールセットによってチェックを受けます。このルールセットは、DAC とは対照的に、ユーザーが変更することは不可能です。実装方法は色々と異なるタイプが存在しますが、強制アクセス制御を使うことで実質的にコンピュータのセキュリティを著しく向上させることになります。

===パス名 MAC===
パス名ベースのアクセス制御は指定されたファイルのパスに基づいてパーミッションを与えるというシンプルな形式のアクセス制御です。この形式のアクセス制御の欠点としてはファイルが移動されてもパーミッションはファイルと一緒に付いていかないということが挙げられます。プラス面となるのは、パス名ベースの MAC はラベルベースの MAC と異なり、幅広いファイルシステムに実装できることです。

*[[AppArmor]] は [[Wikipedia:ja:カノニカル|Canonical]] によって開発されている MAC 実装で SELinux に比べて"簡単"になっています。
*[[TOMOYO Linux|Tomoyo]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ラベル MAC===
ラベルベースのアクセス制御ではファイルの拡張属性を使ってセキュリティパーミッションを管理します。このシステムはセキュリティの機能においてパス名ベースの MAC よりも間違いなく柔軟性が高い一方、拡張属性をサポートしているファイルシステムでしか動作しません。

*[[SELinux]] は、Linux セキュリティを向上させる [[Wikipedia:ja:アメリカ国家安全保障局|NSA]] プロジェクトに基づいており、システムユーザーやロールとは完全に独立して MAC を実装しています。成長してオリジナルの設定が変わっていくシステムのコントロールを簡単に維持できる、極めて強固なマルチレベル MAC ポリシー実装を提供します。

=== アクセス制御リスト ===
[[アクセス制御リスト]] (Access Control List, ACL) は何らかの方法で直接ファイルシステムにルールを付加する代わりとなる手段です。ACL はプログラムの行動を許可された挙動のリストでチェックすることによりアクセス制御を実装しています。

==カーネルの防御==

=== カーネルの自己防衛機能/脆弱性攻撃対策 ===

{{pkg|linux-hardened}} パッケージは [https://github.com/thestinger/linux-hardened 基本的なカーネル堅牢化パッチセット] を使用しており {{pkg|linux}} パッケージよりもセキュリティを高めるコンパイルオプションを有効にしています。また、カスタムビルドすることでセキュリティ指向のデフォルト設定から、セキュリティとパフォーマンスを両立するように設定を変更することができます。詳しくは [https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project Gentoo wiki の記事] を参照してください。現時点では前に存在した {{ic|linux-grsec}} パッケージ (grsecurity パッチは非公開となり有料になりました) と比較して強化ポイントが少なくなっていますが、上流の Kernel Self Protection Project と共同歩調をとって拡張が行われる予定です。出来る限り上流にマージしつつ、政治的な理由で変更が拒否されたり変更が来るのを待つことなくパッチを利用することができます。

===カーネルログへのアクセスを制限する===

{{Note|{{pkg|linux-hardened}} ではデフォルトで有効になっています。}}

カーネルログにはカーネルの脆弱性を突こうとしている攻撃者にとって有益な情報、保護が必要なメモリーアドレスなどが含まれています。{{ic|kernel.dmesg_restrict}} フラグは (デフォルトで root として実行しているプロセスしか持たない) {{ic|CAP_SYS_ADMIN}} ケイパビリティのないログへのアクセスを禁止します。

{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}

===proc ファイルシステムのカーネルポインタへのアクセスを制限する===

{{Note|{{pkg|linux-hardened}} ではデフォルトで {{ic|1=kptr_restrict=2}} と設定されています。}}

{{ic|kernel.kptr_restrict}} を有効にすると {{ic|CAP_SYSLOG}} のない通常ユーザーから {{ic|/proc/kallsyms}} のカーネルシンボルのアドレスが秘匿され、動的にアドレス・シンボルを解決するカーネル exploit が難しくなります。これは事前にコンパイルされた Arch Linux カーネルではあまり意味がありません、周到な攻撃者はカーネルパッケージをダウンロードしてそこから手動でシンボルを取得することができるからです。しかしながら自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし root 以外のユーザーで使用する場合いくつかの {{Pkg|perf}} コマンドが破壊されます (メインの {{Pkg|perf}} 機能には結局 root アクセスが必要になりますが)。詳しくは {{Bug|34323}} を見て下さい。

{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}

===BPF JIT コンパイラを無効にする===

Linux カーネルにはパフォーマンス最適化のために BPF/Seccomp ルールセットをネイティブコードにコンパイルする機能が含まれています。最高レベルのセキュリティのために {{ic|net.core.bpf_jit_enable}} フラグは0にしておくべきです。

コンパイラは特定の領域では有用ですが、通常は役に立ちません。JIT コンパイラは攻撃者がヒープスプレー攻撃を行う機会を与え、カーネルのヒープが悪意のあるコードで満たされるかもしれません。このコードは不正な関数へのポインタの間接参照など、他の脆弱性攻撃によって実行される危険性があります。

===ptrace スコープ===

{{ic|kernel.yama.ptrace_scope}} フラグによって、Arch は Yama LSM をデフォルトで有効にしています。このフラグはプロセスが {{ic|CAP_SYS_PTRACE}} のないスコープの外で他のプロセスに {{ic|ptrace}} コールを実行するのを止めます。多くのデバッグツールがいくつかの機能を使うためにこれを必要としますが、セキュリティの面では飛躍的な改善になります。この機能がないと、名前空間のような外部レイヤーを適用しないかぎり同一ユーザーで動作するプロセスの分割は基本的に行われません。デバッガを既存プロセスにアタッチできることはこの欠点のデモンストレーションです。

====破壊される機能の例====

{{Note|{{ic|sudo}} を使って特定のユーザーに、パスワード有り無しで許可を与えたりすることで、root で以下のコマンドを実行することは可能です。}}

* {{ic|gdb -p $PID}}
* {{ic|strace -p $PID}}
* {{ic|perf trace -p $PID}}
* {{ic|reptyr $PID}}

=== リンクの [[Wikipedia:TOCTOU|TOCTOU]] 攻撃を防止する ===

この機能が追加された日時や根拠についてはこの [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit メッセージ]を見て下さい。

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

{{Note|現在は {{ic|/usr/lib/sysctl.d/50-default.conf}} によってデフォルトで有効にされています。}}

===hidepid===

通常は {{ic|/proc}} から他のユーザーのプロセスを確認することができますが、カーネルにはプロセスを秘匿する機能が存在し {{ic|proc}} ファイルシステムを {{ic|1=hidepid=}} と {{ic|1=gid=}} オプションを使ってマウントすることで有効になります。詳しいドキュメントは [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/proc.txt#n1919 こちら] に存在します。

プロセスを隠すことで侵入者は動作中のプロセスに関する情報を得るのが難しくなります (どのデーモンが特権権限で動作しているか、プログラムの実行に使われているユーザーはどれか、など)。さらに、引数で機密情報を渡すような問題のあるプログラムから情報が漏れてしまうことを防ぎます。

{{Pkg|filesystem}} パッケージに含まれている {{ic|proc}} [[ユーザーとグループ#システムグループ|グループ]]はホワイトリストとして機能し、グループに含まれているユーザーは他のユーザーのプロセス情報を閲覧することが可能です。{{ic|/proc/<pid>}} ディレクトリから他のユーザーの情報を得る必要があるユーザーやサービスがある場合、[[ユーザーとグループ#グループ管理|グループにユーザーを追加]]してください。

{{ic|proc}} グループに含まれていないユーザーに他のユーザーのプロセス情報を表示しない設定は以下の通りです:
{{hc|/etc/fstab|2=
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
}}

[[Xorg]] を動作させるために systemd-logind の例外を追加する必要があります:
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=
[Service]
SupplementaryGroups=proc
}}

== アプリケーションのサンドボックス化 ==

{{Note|標準の Arch カーネルではユーザー名前空間の {{ic|CONFIG_USER_NS}} が設定されていないため、特定のサンドボックス機能がアプリケーションから使えない場合があります。{{pkg|linux-hardened}} パッケージでは有効になっていますが、非特権での使用はデフォルトで無効になっています。{{ic|kernel.unprivileged_userns_clone}} の [[sysctl]] を {{ic|1}} に設定することで使用できるようになりますが、ローカルの権限昇格を引き起こす可能性が高くなるので注意してください。}}

=== Firejail ===

[[Firejail]] はアプリケーションやサーバーをサンドボックス化するためのシンプルで使いやすいツールです。Firejail はサーバーだけでなくブラウザなどのインターネットに接続するアプリケーションでも使うことができます。

=== bubblewrap ===

[[bubblewrap]] は [[Flatpak]] から開発された setuid サンドボックスアプリケーションです。Firejail よりもリソースの消費力が少なく抑えられています。ファイルパスのホワイトリストなどの機能を欠いていますが、バインドマウントやユーザー/IPC/PID/ネットワーク/cgroup 名前空間の作成ができ、簡単なサンドボックスから [https://github.com/projectatomic/bubblewrap/blob/master/demos/bubblewrap-shell.sh 複雑なサンドボックス] まで自在に使うことが可能です。

=== chroot ===

手動で [[chroot]] 監獄を構築する方法もあります。

=== Linux Containers ===

他の手段 (KVM や Virtualbox) よりも強力な分離が必要なときは [[Linux Containers]] を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。

=== 他の仮想化手段 ===

[[VirtualBox]], [[KVM]], [[Xen]] などの完全な仮想化マシンを使うことでもセキュリティを向上させることができます。危険なアプリケーションを実行したり危険なウェブサイトを開いたりするときに役に立つでしょう。

==ネットワークとファイアウォール==

===ファイアウォール===
標準の Arch カーネルは [[Wikipedia:ja:iptables|Netfilter]] の [[iptables]] を使用する能力がありますが、デフォルトでは有効になっていません。[[公式リポジトリ]]から {{Pkg|iptables}} をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。

*全般的な情報は [[iptables]] を見て下さい。
*iptables ファイアウォールを設定するガイドは[[シンプルなステートフルファイアウォール]]を見て下さい。
*netfilter を設定する他の方法は[[ファイアウォール]]を見て下さい。
*Bluetack などの IP アドレスのリストをブロックする方法は [[Ipset]] を見て下さい。

===カーネルパラメータ===
ネットワークに影響を与えるカーネルパラメータは [[sysctl]] を使って設定できます。設定方法は [[sysctl#TCP/IP スタックの防御]] を見て下さい。

===SSH===
[[SSH 鍵#パスワードログインの無効化|SSH 鍵を必要]]としない [[Secure Shell]] を使うのは避けましょう。これは[[Wikipedia:ja:総当たり攻撃|総当たり攻撃]]を防ぎます。また、[[Fail2ban]] や [[Sshguard]] はログを監視して [[iptables|iptables ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

2段階認証によって認証を強化することができます。[[Google Authenticator]] はワンタイムパスコード (OTP) を使用する2段階認証方式を提供します。

[[Secure Shell#root ログインを拒否する|root ログインを拒否する]]のは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。

===DNS===

[[DNSSEC]] や [[DNSCrypt]] を見て下さい。

=== プロキシ ===

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

例えば {{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 はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: {{Pkg|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'' を実行してください。

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

==パッケージの認証==
パッケージの署名が適正に使われていないと [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]] を見て下さい。

== NVD/CVE アラートを購読する ==

National Vulnerability Database による Common Vulnerabilities and Exposure (CVE) を講読する ([http://nvd.nist.gov/download.cfm NVD のダウンロードページ])。また、[https://security.archlinux.org/ Arch Linux セキュリティトラッカー] は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットをまとめた情報を提供しています。[[en2:Arch CVE Monitoring Team|Arch CVE モニタリングチーム]]も見てください。

{{Warning|無理に部分アップデートをしないでください。Arch Linux によってサポートされている手段ではなく、問題が発生する可能性があります。ひとつのコンポーネントをアップグレードする時はシステム全体をアップグレードしてください。システムアップデートをほとんどやらないとアップデートプロセスが複雑になる可能性があります。}}

==物理セキュリティ==
{{Note|リモート攻撃からコンピュータを守りたいだけの場合はこのセクションは無視してかまいません。}}

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

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

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

===BIOS をロックダウンする===

BIOS にパスワードを追加することによってリムーバルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。

===ブートローダー===

ブートローダーの保護はとても重要です。{{ic|1=init=/bin/sh}} というたった一つのカーネルパラメータで、全てのユーザー・ログイン制限が全くの無に帰します。

====Syslinux====

Syslinux は[[Syslinux#セキュリティ|ブートローダーのパスワード保護]]をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。

====GRUB====

[[GRUB]] も同じくブートローダーのパスワードをサポートしています。詳しくは [[GRUB/ヒントとテクニック#GRUB メニューのパスワード保護]] を見て下さい。

===root でのコンソールログインを拒む===
コンソールからの root ログインを拒否するよう設定を変更すれば侵入者がシステムへのアクセスを取得するのを難しくすることができます。侵入者はシステムに存在するユーザーの名前とそのユーザーのパスワードを考えなくてはならなくなります。コンソールによって root がログインできるようになっている場合、侵入者が解き当てるのはパスワードだけで十分になります。
コンソールの root ログインのブロックは {{ic|/etc/securetty}} の tty 行をコメントアウトすることで行います。
{{hc|/etc/securetty|
#tty1
}}

ブロックしたい 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.}}

=== 自動ログアウト ===
[[Bash]] または [[Zsh]] を使っている場合、{{ic|TMOUT}} によってタイムアウトによるシェルからの自動ログアウトを設定できます。

例えば、以下は仮想コンソールから自動でログアウトします (X11 のターミナルエミュレータからはログアウトしません):

{{hc|/etc/profile.d/shell-timeout.sh|<nowiki>
TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
/dev/tty[0-9]*) export TMOUT;;
esac
</nowiki>}}

(X のコンソールも含めて) 全ての Bash/Zsh プロンプトでタイムアウトさせたい場合は、次を使って下さい:

$ export TMOUT="$(( 60*10 ))";

シェルで何かコマンドが動作している間はこのタイムアウトは動作しないので注意してください (例: SSH セッションや {{ic|TMOUT}} をサポートしていない他のシェル)。しかしながら固まった GDM/Xorg を root で再起動するのに VC を使っているような場合は、とても有用です。

=== X からの TTY アクセスをブロック ===

[[Xorg#TTY のアクセスをブロック]]を見てください。

== パッケージの再ビルド ==

パッケージを再ビルドして無駄な機能を省くことで攻撃対象を減らすことができます。例えば {{Pkg|bzip2}} から {{ic|bzip2recover}} を外してビルドすることで [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189] に対処できます。ハードニングフラグは手動で設定したり {{Pkg|hardening-wrapper}}{{Broken package link|パッケージが存在しません}} で適用できます。

=== カスタムハードニングフラグ ===

以下のビルドフラグを {{Ic|/etc/makepkg.conf}} で有効にできます。将来的に [https://lists.archlinux.org/pipermail/arch-dev-public/2016-October/028405.html Arch のデフォルトフラグ] となることが予定されています:

* LDFLAGS: {{Ic|z,now}}
* [[Wikipedia:CFLAGS|CFLAGS]]: {{Ic|-fno-plt -fstack-check}}

{{AUR|hardening-check}} を使って標準の {{Ic|bzip2}} バイナリの状態を確認:

$ hardening check -v /usr/bin/bzip2
/usr/bin/bzip2:
Position Independent Executable: no, normal executable!
Stack protected: yes
Fortify Source functions: no, only unprotected functions found!
unprotected: fread
unprotected: fprintf
unprotected: strcat
unprotected: strncpy
unprotected: strcpy
Read-only relocations: no, not found!
Immediate binding: no, not found!

{{AUR|hardening-check}} を使って堅牢化した {{Ic|bzip2}} バイナリの状態を確認:

$ hardening check -v /usr/bin/bzip2
/usr/bin/bzip2:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
unprotected: memcpy
unprotected: fread
unprotected: strncpy
protected: fprintf
protected: strcat
Read-only relocations: yes
Immediate binding: yes

{{Pkg|checksec}} を使って標準の {{Ic|bzip2}} バイナリの状態を確認:

$ checksec -f /usr/bin/bzip2
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
No RELRO Canary found NX enabled No PIE No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2

{{Pkg|checksec}} を使って堅牢化した {{Ic|bzip2}} バイナリの状態を確認:

$ checksec -f /usr/bin/bzip2
RELRO STACK CANARY NX PIE RPATH RUNPATH FORTIFY Fortified Fortifiable FILE
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH Yes 0 5 /usr/bin/bzip2

{{Note|PIE を有効にするとパッケージによっては問題が発生します。その場合は {{Ic|1=export HARDENING_PIE=0}} で無効にできます。}}

== 参照 ==

* [[en2:DeveloperWiki:Security|DeveloperWiki:Security]]
* [https://security.archlinux.org/ Arch Linux セキュリティトラッカー]
* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]
* [https://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the Linux desktop]
* [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 ワークステーションのセキュリティチェックリスト]
* [https://www.privacytools.io/ privacytools.io Privacy Resources]
* [https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/Security_Guide/index.html Red Hat Enterprise Linux 7 セキュリティガイド]
* [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]
* [https://www.auscert.org.au/resources/publications/guidelines/unix-linux/unix-and-linux-security-checklist-v3.0 UNIX and Linux Security Checklist v3.0]

ArchWiki - 利用者の投稿記録 [ja]

セキュリティ