セキュリティ
この記事では Arch Linux システムを防御するための推奨事項とベストプラクティスを並べています。
目次
概念
- セキュリティを厳しくするあまりシステムが使い物にならなくなってしまう可能性があります。うまいやり方は度を越さない程度にセキュリティを強化します。
- セキュリティを高めるために出来ることは数多く存在しますが、一番の脅威はいつだってユーザー自身です。セキュリティを考える時は、多層防御を考える必要があります。ある層が突破されたとしても、他の層が攻撃を防御しなくてはなりません。ただし全てのネットワークからマシンを切断して、金庫にしまって決して使わないかぎり、システムを100%セキュアにすることは不可能です。
- 少しだけ病的なまでの心配性 (パラノイド) になりましょう。それは役に立ちます。そして疑り深くなってください。話がうますぎるように聞こえたら、おそらくその通りです。
- 最小権限の原則: システムの各部位は使用に必要なことにだけしかアクセスできないようにするべきで、それ以上は必要ありません。
パスワード
パスワードは安全な linux システムのかぎです。パスワードはユーザーアカウント, 暗号化されたファイルシステム, SSH/GPG 鍵などを守ります。コンピュータを使用する人を信頼するのに使う主要な手段なので、安全なパスワードを選んでそれを保護するというのがセキュリティの大部分と言っても過言ではありません。
強力なパスワードの選び方
パスワードは簡単に割り出されたりまたは個人情報から類推されないようにすることが重要です。そういうわけで、辞書に載っている単語やあなたの飼っている犬の名前などは使わないようにしましょう。パスワードは出来るだけ8文字以上で、小文字と大文字を混ぜてください。さらに数字や特殊文字も1文字以上含めると良いでしょう。当たり前ですが、長くて複雑なパスワードが基本的に良いパスワードとされます。
pwgen や apg などのツールは安全なパスワードを生成するのに役立ちます。
また、ある文章の各単語の一番最初を取ってパスワードを作ることもできます。 例えば “the girl is walking down the rainy street” なら “t6!WdtR5” とパスワードにすることができます。この方法はパスワードを覚えるのをずっと簡単にしてくれます。さらに、入力するのが面倒くさくなりますがパスワードを “The girl is walking down the rainy street" にすることも可能です。
パスワードの管理
強固なパスワードを選び出したら、それを安全に保管してください。心理操作やショルダーサーフィンに注意したり、セキュアでないサーバーから必要以上に情報が流出するのをふせぐためにパスワードを再利用しないようにしてください。pass, keepassx, gnome-keyring などのツールは大量の複雑なパスワードを管理するのに役立ちます。Lastpass はデバイス間で同期するためにオンラインで暗号化されたパスワードを保存するサービスですが、クローズドソースのコードと外部の企業の両方を信頼する必要があります。
概して、安全なパスワードは覚えにくいからといって安全でないパスワードを使ってはいけません。パスワードはバランスを取る必要があります。弱いパスワードをたくさん作るよりは、安全なパスワードの暗号化されたデータベースを作り、一つの強いマスターパスワードで守るほうが良いでしょう。パスワードを紙に書くのも、物理的なセキュリティを必要としますがソフトウェアの脆弱性を防ぐ点では同じくらい有効です [1]。
パスワードのハッシュ
デフォルトの Arch のハッシュ sha512 はとても強固で変更する必要はありません。デフォルトでは、/etc/shadow
にパスワードがハッシュ化されて保存され、root にだけ読み取り許可を与え、/etc/passwd
にはユーザー識別子だけが保存されます。従って、root ユーザーが安全である限り、ファイルが外部システムにコピーされたり解読されることはありえません。
How are passwords stored in Linux (Understanding hashing with shadow utils) も参照してください。
pam_cracklib を用いた強力なパスワードの強制
pam_cracklib は辞書攻撃からの防御を提供し、システム全体で強制するパスワードポリシーの設定を補助します。
例えば以下のようなポリシーを強制させたい場合:
- エラー時に2回パスワードプロンプト
- 最小で10文字の長さ (minlen オプション)
- 新しくパスワードを設定する場合、少なくとも6文字は古いパスワードと異なる (difok オプション)
- 少なくとも1文字数字を含む (dcredit オプション)
- 少なくとも1文字は大文字を含む (ucredit オプション)
- 少なくとも1文字は異なる文字を含む (ocredit オプション)
- 少なくとも1文字は小文字を含む (lcredit オプション)
/etc/pam.d/passwd
ファイルを以下のように書き換えます:
#%PAM-1.0 password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 password required pam_unix.so use_authtok sha512 shadow
password required pam_unix.so use_authtok
でパスワードのプロンプトを表示するときに pam_unix モジュールではなく pam_cracklib によるプロンプトを使うようになります。
詳細な情報については pam_cracklib(8) と pam_unix(8) の man ページを参照してください。
ストレージ
ディスク暗号化
ディスク暗号化、特に強固なパスフレーズによる完全ディスク暗号化は、物理的なリカバリからデータを守る唯一の方法です。コンピュータの電源がオフになっていて問題のディスクがアンマウントされている時は完璧なセキュリティを提供します。
しかしながら、コンピュータの電源が入れられてドライブがマウントされると、そのデータは暗号化されていないドライブと同じように無防備になります。そのためデータが必要なくなったときはすぐにデータのパーティションをアンマウントするのが最善です。
Dm-crypt など特定のプログラムでは、ループファイルを物理ボリュームとして暗号化することができます。これはシステムの特定部分だけを守りたいときに完全なディスク暗号化の代わりの選択肢となりえます。
ファイルシステム
現在カーネルは fs.protected_hardlinks
や fs.protected_symlinks
sysctl スイッチが有効になっていればハードリンクやシンボリックリンクに関するセキュリティの問題を解決するので、world-writable なディレクトリを分離させるセキュリティ的な利点はもはや存在しません。
それでもディスク容量が消耗したときのダメージを低減させる荒っぽい方法として world-writable なディレクトリを含むパーティションが分割されることがあります。しかしながら、サービスを落とすには /var
や /tmp
などのパーティションを一杯にするだけで十分です。この問題の対処についてはもっと柔軟性のある方法が存在します (クォータなど)、またファイルシステムによっては関連する機能を持っていることがあります (btrfs はサブボリュームにクォータを設定できます)。
マウントオプション
最小権限の原則に従って、パーティションは (機能性を失わない限りで) 最も制限的なマウントオプションを使ってマウントすると良いでしょう。
nodev
: ファイルシステム上のキャラクタ・ブロック特殊デバイスを解釈しない。nosuid
: set-user-identifier や set-group-identifier ビットの効果を許可しない。noexec
: マウントされたファイルシステム上の全てのバイナリの直接実行を許可しない。
パーティション | nodev
|
nosuid
|
noexec
|
/var |
yes | yes | yes [1] [2] |
/home |
yes | yes | yes (wine や steam を使用しない場合 [2]) |
/dev/shm |
yes | yes | yes |
/tmp |
yes | yes | no (パッケージをコンパイルできなくなる可能性があります) |
/boot |
yes | yes | yes |
[1] パッケージによっては (例えば nvidia-dkms) /var
で exec
を必要とすることがあるので注意してください。
[2] noexec
がパーティションに設定されている場合、Qt 5.8 以上では QML を使用するアプリケーションがクラッシュしたり機能しなくなることがあります。解決方法は Qt#Qt 5.8 で QML を使用するアプリケーションがクラッシュあるいは動作しないを参照。
ファイルシステムのパーミッション
デフォルトのファイルシステムのパーミッションはほぼ全ての読み取りアクセスが許可されているため、パーミッションを変更することで http
や nobody
ユーザーなど root 以外のアカウントへのアクセスを手に入れた攻撃者から重要な情報を隠すことができます。
例えば:
# chmod 700 /boot /etc/{iptables,arptables}
デフォルトの Umask を変更することで新しく作成したファイルのセキュリティを向上させることができます。NSA RHEL5 Security Guide はセキュリティを最大化させるために 077
の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、Umask#マスクの値を設定を参照してください。
ユーザー設定
インストールした後は日常の使用のために通常ユーザーを作成してください。root ユーザーを常用してはいけません。
3回ログインを失敗したユーザーをロックアウトする
セキュリティをさらに高めるために、指定した回数ログインを失敗したユーザーをログインできなくすることが可能です。root ユーザーがロックを解除するまでそのユーザーアカウントにロックをかけるか、または設定した時間が経つと自動でロックが解除されるように設定できます。
3回ログインを失敗したユーザーを10分間ログインできないようにするには /etc/pam.d/system-login
を変更する必要があります:
/etc/pam.d/system-login
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回ログインが失敗したユーザーを永遠にログインできないようにしたい場合 unlock_time
の部分を削除してください。こうすると root がアカウントをアンロックするまでログインできなくなります。
プロセスの数を制限する
信頼できないユーザーが大量に存在するシステムでは、一度に実行できるプロセスの数を制限して、フォーク爆弾などのサービス拒否攻撃を予防することが重要です。ユーザーやグループごとに実行できるプロセスの数は /etc/security/limits.conf
で定義することができ、デフォルトでは空になっています。以下の値をファイルに追加すると、実行できるプロセスが100個までに制限されます。prlimit
コマンドを使って一時的に上げられる最大数も200個までに制限します。ユーザーが普段実行するプロセスの数や、管理するハードウェアにあわせて適切な値に変更してください。
* soft nproc 100 * hard nproc 200
root の制限
root ユーザーは、定義上、システムで最も強力なユーザーです。このため、root ユーザーの権限を維持しながら害を及ぼす力を制限する、もしくは root ユーザーの行動をもっと追跡できるようにする方法が多数存在します。
su の代わりに sudo を使う
色々な理由から特権アクセスには su よりも sudo を使うほうが好ましいとされます。
- 通常の権限しか持たないユーザーが実行した特権コマンドのログを保持します。
- root アクセスを必要とする各ユーザーに root ユーザーのパスワードを与える必要がありません。
- 完全な root ターミナルは作成されないため、
sudo
は root アクセスが必要ないコマンドを偶発的に root で実行してしまうことを防止します。これは最小権限の原則と合っています。 - 一つのコマンドを実行するためだけに完全な root アクセスを与える代わりに、ユーザーごとに個々のプログラムを有効にすることができます。例えば、ユーザー alice に特定のプログラムへのアクセス権限を与えるには:
# visudo
/etc/sudoers
alice ALL = NOPASSWD: /path/to/program
また、全てのユーザーに個別のコマンドを許可することも可能です。通常ユーザーでサーバーから Samba 共有をマウントするには:
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs
これによって users グループのメンバーである全てのユーザーが全てのマシン (ALL) から /sbin/mount.cifs
や /sbin/umount.cifs
コマンドを実行できるようになります。
sudo を使ってファイルを編集する
root で vim
などのテキストエディタを使用するのはセキュリティ上の脆弱性になりえます。ユーザーは任意のシェルコマンドを実行でき、コマンドを実行したユーザーのログが残らないからです。これを解決するには、以下をシェルの設定ファイルに追加してください:
export SUDO_EDITOR=rvim
ファイルの編集には sudoedit filename
または sudo -e filename
を使って下さい。自動的に rvim
によって filename
が編集されるようになり、テキストエディタからのシェルコマンドが無効になります。
root ログインの制限
sudo を適切に設定することで、ユーザビリティをあまり下げることなく完全な root アクセスを大分制限することが可能です。sudo を使える状態のまま root を無効化したい場合、passwd -l root
を使用します。
特定のユーザーだけに許可を与える
PAM の pam_wheel.so
は wheel
グループに入っているユーザーだけに su
を使用したログインを許可します。/etc/pam.d/su
と /etc/pam.d/su-l
の両方を編集して次の行をアンコメントしてください:
# Uncomment the following line to require a user to be in the "wheel" group. auth required pam_wheel.so use_uid
特権コマンドを実行できる既存のユーザーだけが root でログインできるようになります。
ssh ログインを拒否する
ローカルユーザーの root ログインを拒否したくない場合でも、SSH による root ログインを拒否するのがグッドプラクティスです。この目的は、ユーザーがリモートでシステムを完全に手にかける前にセキュリティ層を追加することにあります。
強制アクセス制御
強制アクセス制御 (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 パッケージよりもセキュリティを高めるコンパイルオプションを有効にしています。また、カスタムビルドすることでセキュリティ指向のデフォルト設定から、セキュリティとパフォーマンスを両立するように設定を変更することができます。詳しくは Gentoo wiki の記事 を参照してください。現時点では前に存在した linux-grsec
パッケージ (grsecurity パッチは非公開となり有料になりました) と比較して強化ポイントが少なくなっていますが、上流の Kernel Self Protection Project と共同歩調をとって拡張が行われる予定です。出来る限り上流にマージしつつ、政治的な理由で変更が拒否されたり変更が来るのを待つことなくパッチを利用することができます。
カーネルログへのアクセスを制限する
カーネルログにはカーネルの脆弱性を突こうとしている攻撃者にとって有益な情報、保護が必要なメモリーアドレスなどが含まれています。kernel.dmesg_restrict
フラグは (デフォルトで root として実行しているプロセスしか持たない) CAP_SYS_ADMIN
ケイパビリティのないログへのアクセスを禁止します。
/etc/sysctl.d/50-dmesg-restrict.conf
kernel.dmesg_restrict = 1
proc ファイルシステムのカーネルポインタへのアクセスを制限する
kernel.kptr_restrict
を有効にすると CAP_SYSLOG
のない通常ユーザーから /proc/kallsyms
のカーネルシンボルのアドレスが秘匿され、動的にアドレス・シンボルを解決するカーネル exploit が難しくなります。これは事前にコンパイルされた Arch Linux カーネルではあまり意味がありません、周到な攻撃者はカーネルパッケージをダウンロードしてそこから手動でシンボルを取得することができるからです。しかしながら自分でカーネルをコンパイルする場合は、ローカルの root 攻撃を減らす効果があります。ただし root 以外のユーザーで使用する場合いくつかの perf コマンドが破壊されます (メインの perf 機能には結局 root アクセスが必要になりますが)。詳しくは FS#34323 を見て下さい。
/etc/sysctl.d/50-kptr-restrict.conf
kernel.kptr_restrict = 1
BPF JIT コンパイラを無効にする
Linux カーネルにはパフォーマンス最適化のために BPF/Seccomp ルールセットをネイティブコードにコンパイルする機能が含まれています。最高レベルのセキュリティのために net.core.bpf_jit_enable
フラグは0にしておくべきです。
コンパイラは特定の領域では有用ですが、通常は役に立ちません。JIT コンパイラは攻撃者がヒープスプレー攻撃を行う機会を与え、カーネルのヒープが悪意のあるコードで満たされるかもしれません。このコードは不正な関数へのポインタの間接参照など、他の脆弱性攻撃によって実行される危険性があります。
ptrace スコープ
kernel.yama.ptrace_scope
フラグによって、Arch は Yama LSM をデフォルトで有効にしています。このフラグはプロセスが CAP_SYS_PTRACE
のないスコープの外で他のプロセスに ptrace
コールを実行するのを止めます。多くのデバッグツールがいくつかの機能を使うためにこれを必要としますが、セキュリティの面では飛躍的な改善になります。この機能がないと、名前空間のような外部レイヤーを適用しないかぎり同一ユーザーで動作するプロセスの分割は基本的に行われません。デバッガを既存プロセスにアタッチできることはこの欠点のデモンストレーションです。
破壊される機能の例
gdb -p $PID
strace -p $PID
perf trace -p $PID
reptyr $PID
リンクの TOCTOU 攻撃を防止する
この機能が追加された日時や根拠についてはこの commit メッセージを見て下さい。
fs.protected_hardlinks = 1 fs.protected_symlinks = 1
hidepid
通常は /proc
から他のユーザーのプロセスを確認することができますが、カーネルにはプロセスを秘匿する機能が存在し proc
ファイルシステムを hidepid=
と gid=
オプションを使ってマウントすることで有効になります。詳しいドキュメントは こちら に存在します。
プロセスを隠すことで侵入者は動作中のプロセスに関する情報を得るのが難しくなります (どのデーモンが特権権限で動作しているか、プログラムの実行に使われているユーザーはどれか、など)。さらに、引数で機密情報を渡すような問題のあるプログラムから情報が漏れてしまうことを防ぎます。
filesystem パッケージに含まれている proc
グループはホワイトリストとして機能し、グループに含まれているユーザーは他のユーザーのプロセス情報を閲覧することが可能です。/proc/<pid>
ディレクトリから他のユーザーの情報を得る必要があるユーザーやサービスがある場合、グループにユーザーを追加してください。
proc
グループに含まれていないユーザーに他のユーザーのプロセス情報を表示しない設定は以下の通りです:
/etc/fstab
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0
Xorg を動作させるために systemd-logind の例外を追加する必要があります:
/etc/systemd/system/systemd-logind.service.d/hidepid.conf
[Service] SupplementaryGroups=proc
アプリケーションのサンドボックス化
Firejail
Firejail はアプリケーションやサーバーをサンドボックス化するためのシンプルで使いやすいツールです。Firejail はサーバーだけでなくブラウザなどのインターネットに接続するアプリケーションでも使うことができます。
bubblewrap
bubblewrap は Flatpak から開発された setuid サンドボックスアプリケーションです。Firejail よりもリソースの消費力が少なく抑えられています。ファイルパスのホワイトリストなどの機能を欠いていますが、バインドマウントやユーザー/IPC/PID/ネットワーク/cgroup 名前空間の作成ができ、簡単なサンドボックスから 複雑なサンドボックス まで自在に使うことが可能です。
chroot
手動で chroot 監獄を構築する方法もあります。
Linux Containers
他の手段 (KVM や Virtualbox) よりも強力な分離が必要なときは Linux Containers を選択するのもよいでしょう。LXC は仮想ハードウェアを使って擬似的な chroot で既存のカーネル上で動作します。
他の仮想化手段
VirtualBox, KVM, Xen などの完全な仮想化マシンを使うことでもセキュリティを向上させることができます。危険なアプリケーションを実行したり危険なウェブサイトを開いたりするときに役に立つでしょう。
ネットワークとファイアウォール
ファイアウォール
標準の Arch カーネルは Netfilter の iptables を使用する能力がありますが、デフォルトでは有効になっていません。公式リポジトリから iptables をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。
- 全般的な情報は iptables を見て下さい。
- iptables ファイアウォールを設定するガイドはシンプルなステートフルファイアウォールを見て下さい。
- netfilter を設定する他の方法はファイアウォールを見て下さい。
- Bluetack などの IP アドレスのリストをブロックする方法は Ipset を見て下さい。
カーネルパラメータ
ネットワークに影響を与えるカーネルパラメータは sysctl を使って設定できます。設定方法は sysctl#TCP/IP スタックの防御 を見て下さい。
SSH
SSH 鍵を必要としない Secure Shell を使うのは避けましょう。これは総当たり攻撃を防ぎます。また、Fail2ban や Sshguard はログを監視して iptables ルールを書き込む方式の保護を提供しますが、攻撃者がアドレスを識別して管理者からのパケットのように偽装することができるため、サービスの妨害が行われる危険性があります。
2段階認証によって認証を強化することができます。Google Authenticator はワンタイムパスコード (OTP) を使用する2段階認証方式を提供します。
root ログインを拒否するのは、侵入追跡と root アクセス前のセキュリティレイヤを追加するという両方の面でグッドプラクティスです。
DNS
プロキシ
プロキシはアプリケーションとネットワークの間に挟まる追加レイヤーとして使われ、信頼できないソースからのデータをサニタイズします。少ない権限でプロキシを動作させることで、エンドユーザー権限で複雑なアプリケーションを実行するよりも攻撃対象を小さくすることができます。
例えば glibc の中に実装されている DNS リゾルバを考えてみてください。(root で実行することもある) アプリケーションにリンクされている DNS リゾルバにバグが存在した場合、リモートコード実行につながる危険があります。dnsmasq などの DNS キャッシュサーバーをインストールしてプロキシとして使うことで問題を防ぐことが可能です [2]。
SSL 証明書の管理
サーバーサイドの SSL 証明書の管理については OpenSSL や Network Security Services (NSS) を参照してください。また、関連する Let’s Encrypt プロジェクトも見てください。
デフォルトのインターネット SSL 証明書のトラストチェーンは ca-certificates パッケージによって提供されています。Arch はデフォルトで信頼しても問題ないとされる証明書を提供しているソース (例: ca-certificates-cacert, ca-certificates-mozilla) に依存しています。
デフォルトの証明書を変えたいと思うことがあるかもしれません。例えば、ニュース を読んで証明書を信頼しないようにしたい場合 (ソースのプロバイダーによって無効になるのを待てない場合)、Arch のインフラを使うことで簡単に設定できます:
.crt
形式の証明書を入手してください (例: view, download; 既存のルート認証局の場合、システム内にあるはずです)。/etc/ca-certificates/trust-source/blacklist/
にコピーしてください。- root で update-ca-trust を実行してください。
お好きなブラウザを開いて信頼できないサイトとして表示されれば、ブラックリストが上手く機能しています。
パッケージの認証
パッケージの署名が適正に使われていないと パッケージマネージャへの攻撃 が考えられ、さらに 適切な署名システム を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは Pacman-key を見て下さい。
NVD/CVE アラートを購読する
National Vulnerability Database による Common Vulnerabilities and Exposure (CVE) を講読する (NVD のダウンロードページ)。また、Arch Linux セキュリティトラッカー は Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG), CVE データセットをまとめた情報を提供しています。Arch CVE モニタリングチームも見てください。
物理セキュリティ
十分な時間とリソースさえあればコンピュータへの物理的なアクセスは root アクセスになります。しかしながら、十分な防御策を張ることで実用的で高いレベルのセキュリティを得ることができます。
攻撃者は悪意のある IEEE 1394 (FireWire), Thunderbolt, PCI Express デバイスを取り付けることでメモリーへの完全なアクセスを手に入れることができ、次に起動した時には簡単にコンピュータの完全なコントロールを手中に収めることができます [3]。これを防ぐために出来ることは限られており、悪意のあるファームウェアをドライブに書き込むなどハードウェア自体の改変に対処することは不可能です。ただし、攻撃者の大部分にはこうした知識がなく実行されることはほとんどありません。
ディスク暗号化はコンピュータが盗まれた場合にデータへのアクセスを防止しますが、あなたが次にログインしたときにデータを取得するために悪意のあるファームウェアが能力のある攻撃者によってインストールされる可能性があります。
BIOS をロックダウンする
BIOS にパスワードを追加することによってリムーバルメディアから誰かが起動する (これはコンピュータへの root アクセスと基本的に同義です) のを予防します。使用しているドライブがブートの順番で一番最初に来ることを確認して、可能であれば他のドライブのブートを無効にしてください。
ブートローダー
ブートローダーの保護はとても重要です。init=/bin/sh
というたった一つのカーネルパラメータで、全てのユーザー・ログイン制限が全くの無に帰します。
Syslinux
Syslinux はブートローダーのパスワード保護をサポートしています。メニューのアイテムごとにパスワードを設定したり、ブートローダー全体にパスワードの保護を設定することが可能です。
GRUB
GRUB も同じくブートローダーのパスワードをサポートしています。詳しくは GRUB/Tips and tricks#GRUB メニューのパスワード保護 を見て下さい。
root でのコンソールログインを拒む
コンソールからの root ログインを拒否するよう設定を変更すれば侵入者がシステムへのアクセスを取得するのを難しくすることができます。侵入者はシステムに存在するユーザーの名前とそのユーザーのパスワードを考えなくてはならなくなります。コンソールによって root がログインできるようになっている場合、侵入者が解き当てるのはパスワードだけで十分になります。
コンソールの root ログインのブロックは /etc/securetty
の tty 行をコメントアウトすることで行います。
/etc/securetty
#tty1
ブロックしたい tty 全てで同じようにコメントアウトしてください。
変更の効果を確認するには、一つの行だけをコメントアウトしてから特定のコンソールに移って root でのログインを試行してみてください。Login incorrect
というメッセージが表示されるはずです。ブロックされたことを確認したら、戻ってから残りの tty 行をコメントアウトしてください。
自動ログアウト
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 を使っているような場合は、とても有用です。
X からの TTY アクセスをブロック
Xorg#TTY のアクセスをブロックを見てください。
パッケージの再ビルド
パッケージを再ビルドして無駄な機能を省くことで攻撃対象を減らすことができます。例えば bzip2 から bzip2recover
を外してビルドすることで CVE-2016-3189 に対処できます。ハードニングフラグは手動で設定したり hardening-wrapper で適用できます。
カスタムハードニングフラグ
以下のビルドフラグを /etc/makepkg.conf
で有効にできます。将来的に Arch のデフォルトフラグ となることが予定されています:
- LDFLAGS:
z,now
- CFLAGS:
-fno-plt -fstack-check
hardening-checkAUR を使って標準の 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!
hardening-checkAUR を使って堅牢化した 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
checksec を使って標準の 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
checksec を使って堅牢化した 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
参照
- DeveloperWiki:Security
- Arch Linux セキュリティトラッカー
- ArchWiki のセキュリティアプリケーションのリスト: アプリケーション一覧/セキュリティ
- CentOS Wiki: OS Protection
- Hardening the Linux desktop
- Hardening the Linux server
- Linux Foundation: Linux ワークステーションのセキュリティチェックリスト
- privacytools.io Privacy Resources
- Red Hat Enterprise Linux 7 セキュリティガイド
- Debian 安全化マニュアル (PDF)
- The paranoid #! Security Guide
- UNIX and Linux Security Checklist v3.0