セキュリティ

2016-03-04T16:40:18Z

Tyage: パーティションではなくパーミッション

[[Category:セキュリティ]]
[[Category:ファイルシステム]]
[[Category:ネットワーク]]
[[en:Security]]
[[ru:Security]]
{{Related articles start}}
{{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 のハッシュ [[en2:SHA password hashes|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)] も参照してください。

==パーティション==

現在カーネルは {{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 <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
|-
|}

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

==ファイルシステムのパーミッション==
デフォルトのファイルシステムのパーミッションはほぼ全ての読み取りアクセスが許可されているため、パーミッションを変更することで http や 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#マスクの値を設定]] を参照してください。

==ディスク暗号化==

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

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

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

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

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

{{hc|/etc/pam.d/system-login|
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
}}

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

# pam_tally --user ''username'' --reset

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

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

信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、[[Wikipedia:ja:Fork爆弾|フォーク爆弾]]などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は {{ic|/etc/security/limits.conf}} で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。ulimit コマンドを使って一時的に上げられる最大数も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 アクセスを大分制限することが可能です。

====特定のユーザーだけに許可を与える====
[[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]] はもうひとつのシンプルで、使いやすい強制アクセス制御を提供するシステムです。利用と実装の両面でシンプルになるように設計されており、依存するライブラリがとても少なくなっています。

===ロールベースアクセス制御===
grsecurity がサポートしている MAC 実装はロールベースアクセス制御と呼ばれています。RBAC はユーザーごとにロールを割り当てます。それぞれのロールには特定のオブジェクトで実行できる操作を定義します。上手く記述されたロールと操作を使うことでユーザーに指定した作業しかできないように制限をかけることができます。デフォルトの "deny-all" では管理者が想定していない行動をユーザーは出来ません。

*[[Grsecurity#RBAC|Grsecurity RBAC]] には設定を楽にするため AppArmor のような学習モードが備わっています。
*[[Grsecurity#RBAC|Grsecurity RBAC]] は SELinux のように付加的なメタデータを使いません。RBAC は SELinux よりもずっと高速です。

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

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

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

*[[grsecurity]] はセキュリティを向上させるための完全なカーネルパッチセットだけでなく、ACL アクセス制御も実装しています。メモリ割り当てのコントロールを拡張し、chroot 制限を改良、特定のネットワーク挙動に関係するルールを定めます。

==カーネルの防御==

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

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

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

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

{{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 コンパイラは攻撃者がヒープスプレー攻撃を行う機会を与え、カーネルのヒープが悪意のあるコードで満たされるかもしれません。このコードは不正な関数へのポインタの間接参照など、他の脆弱性攻撃によって実行される危険性があります。

{{note|[[grsecurity]] には BPF JIT コンパイラの JIT ハードニングが含まれており、攻撃のリスクを大幅に減らします。}}

===ptrace スコープ===

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

{{note|[[grsecurity]] では、この防護は {{ic|kernel.grsecurity.harden_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|1=hidepid=1}} または {{ic|1=hidepid=2}} でマウントすることで有効になります。ただし、[http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html この機能は現在 systemd を破壊します]。カーネルによるコンテナの cgroups ファイルシステムの仮想化サポートが欠けているために、その対応策が必要だからです。

===grsecurity===

標準の Linux カーネルは機密情報へのアクセスを必要以上に許可しておりメモリーの脆弱性攻撃への保護は最低限しか提供していません。[https://grsecurity.net/ Grsecurity] はこれを修正することを目指しています。Grsecurity には PaX のメモリーパッチがバンドルされています。PaX は ALSR を発明しており、強力な保護を提供します。Grsecurity はファイルシステムを防護し、高度なロールベースアクセス制御を提供して、せっかくの PaX のメモリー保護を無駄にするような情報漏洩を防ぎます。

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

=== Firejail ===

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

=== 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 ルール]]を書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。

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

===DNS===

[[en2:DNSSEC|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]] を見て下さい。

==物理セキュリティ==
{{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/Tips and tricks#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 を使っているような場合は、とても有用です。

== 参照 ==

* ArchWiki のセキュリティアプリケーションのリスト: [[アプリケーション一覧/セキュリティ]]
* [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]
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]
* [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)]
* [http://crunchbang.org/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation's Linux workstation security checklist]
* [https://www.privacytools.io/ privacytools.io]

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

セキュリティ