セキュリティ

関連記事

• アプリケーション一覧/セキュリティ
• カテゴリ:セキュリティ

この記事では 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]。

パスワードのハッシュ

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

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

How are passwords stored in Linux (Understanding hashing with shadow utils) も参照してください。

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

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

警告: root アカウントはこのポリシーの影響を受けません。

ノート: root アカウントを 望ましい/設定された ポリシーを迂回したユーザーにパスワードを設定するために利用できます。 これは一時的なパスワードを設定するときに便利です。

例えば以下のようなポリシーを強制させたい場合:

• エラー時に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

The password required pam_unix.so use_authtok instructs the pam_unix module to not prompt for a password but rather to use the one provided by pam_cracklib.

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

パーティション

現在カーネルは 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 でマウントするべきです。

パーティション	nodev	nosuid	noexec
/var	yes	yes	yes [1]
/home	yes	yes	yes, if you do not code, use wine or steam
/dev/shm	yes	yes	yes
/tmp	yes	yes	maybe, breaks compiling packages and various other things
/boot	yes	yes	yes

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

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

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

例えば:

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

デフォルトの Umask を変更することで新しく作成したファイルのセキュリティを向上させることができます。NSA RHEL5 Security Guide はセキュリティを最大化させるために 077 の umask を提案しています、これは新しいファイルの所有者以外のユーザーによる読み取りを出来なくします。umask を変更するには、Umask#マスクの値を設定 を参照してください。

ディスク暗号化

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

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

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

ユーザー設定

インストールした後は日常の使用のために通常ユーザーを作成してください。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個までに制限されます。ulimit コマンドを使って一時的に上げられる最大数も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 コマンドを実行できるようになります。

ヒント: 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 アクセスを大分制限することが可能です。

特定のユーザーだけに許可を与える

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

ロールベースアクセス制御

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

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

ラベル MAC

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

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

アクセス制御リスト

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

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

カーネルの防御

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

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

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

ptrace スコープ

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

ノート: grsecurity では、この防護は kernel.grsecurity.harden_ptrace フラグによって切り替えます。

破壊される機能の例

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

• gdb -p $PID
• strace -p $PID
• perf trace -p $PID
• reptyr $PID

リンクの TOCTOU 攻撃を防止する

この機能が追加された日時や根拠についてはこの commit メッセージを見て下さい。

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

ノート: 現在は /usr/lib/sysctl.d/50-default.conf によってデフォルトで有効にされています。

hidepid

カーネルには権限がないユーザーから他のユーザーのプロセスを秘匿させる機能が存在し、proc ファイルシステムを hidepid=1 または hidepid=2 でマウントすることで有効になります。ただし、この機能は現在 systemd を破壊します。カーネルによるコンテナの cgroups ファイルシステムの仮想化サポートが欠けているために、その対応策が必要だからです。

grsecurity

標準の Linux カーネルは機密情報へのアクセスを必要以上に許可しておりメモリーの脆弱性攻撃への保護は最低限しか提供していません。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 カーネルは Netfilter の iptables を使用する能力がありますが、デフォルトでは有効になっていません。公式リポジトリから iptables をインストールして、有効にし、ファイアウォールを設定することが強く推奨されます。

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

カーネルパラメータ

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

SSH

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

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

DNS

DNSSEC や DNSCrypt を見て下さい。

パッケージの認証

パッケージの署名が適正に使われていないと パッケージマネージャへの攻撃 が考えられ、さらに 適切な署名システム を使っているパッケージマネージャにも影響を与える可能性があります。Arch はデフォルトでパッケージの署名を使用しており5つの信頼されたマスターキーによる web of trust を使っています。詳しくは Pacman-key を見て下さい。

物理セキュリティ

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

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

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

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

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 行をコメントアウトしてください。

ノート: If you see ttyS0 this is for a serial console. Similarly, on Xen virtualized systems hvc0 is for the administrator.

自動ログアウト

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 を使っているような場合は、とても有用です。

参照

• ArchWiki のセキュリティアプリケーションのリスト: アプリケーション一覧/セキュリティ
• Securing and Hardening Red Hat Linux Production Systems
• Hardening the linux desktop
• Hardening the linux server
• Securing and Optimizing Linux
• UNIX and Linux Security Checklist v3.0
• CentOS Wiki: OS Protection
• Hardening Debian (pdf)
• The paranoid #! Security Guide
• Linux Foundation's Linux workstation security checklist
• privacytools.io