こんにちは！インフラやセキュリティの世界へようこそ。新人IT担当者や、これから開発を本格的に始める方にとって、「セキュリティの要塞化（ハーデニング）」って、なんだか要塞という言葉だけでも身構えてしまいますよね。
でも、安心してください。難しく考える必要はありません。サーバーのセキュリティ対策も、私たちが普段暮らしている「お家の防犯対策」とまったく同じなんです。
今回は、Linuxサーバーのログインを守るための強力な門番である PAM（Pluggable Authentication Modules） を使って、弱いパスワードをシャットアウトし、悪意ある侵入者のブルートフォース攻撃（総当たり攻撃）を防ぐ方法を、一緒に優しく紐解いていきましょう！
—
1. 家の鍵で例える「パスワードポリシー」と「ブルートフォース攻撃」
想像してみてください。あなたが新しく引っ越したお家の鍵を、自分で選べることになりました。
ここで、もしあなたが鍵の暗証番号を 1234 や password のような、誰でも簡単に思いつくものに設定してしまったらどうなるでしょうか？ 空き巣（攻撃者）がやってきて、片っ端から簡単な番号を試していけば、ものの数秒で扉が開いてしまいますよね。これがネットの世界における ブルートフォース攻撃（総当たり攻撃） です。
さらに厄介なことに、泥棒は何百万回もの「ガチャガチャ」という鍵の試行を、人間の手ではなく自動化されたボット（プログラム）を使って一瞬で行います。
この泥棒の侵入を防ぐために、管理人がマンションの入り口（サーバー）で次のようなルールを定めておく必要があります。
1. 簡単な鍵（パスワード）を作らせないルール（文字数や複雑さの強制）
2. 何回も鍵をガチャガチャ試したら、一定時間インターホンを鳴らせなくするルール（アカウントロックアウト）
Linuxサーバーでこの「厳しい管理人さん」の役割を果たしてくれるのが、PAM という仕組みなんです。
—
2. pam_pwquality で「甘いパスワード」を絶対に許さない
まずは、ユーザーが「簡単すぎるパスワード」を設定できないようにする仕組みから見ていきましょう。Linuxでは、pam_pwquality というモジュールを使ってこれを強制します。
例えば、ユーザーが 123456 や自分の名前をパスワードにしようとしたとき、「おいおい、そのパスワードはセキュリティ的に危なすぎるから、もっと頑丈なものにしなさい！」と突っ込みを入れてくれる仕組みです。
実際に設定ファイルを見てみよう
設定ファイルは通常 /etc/security/pwquality.conf にあります。実際のファイルの中身と、それぞれの設定値の意味を分かりやすく日本語のコメント付きで見てみましょう。
# /etc/security/pwquality.conf の設定例
# パスワードの最低文字数を「12文字以上」に強制します（短い鍵は簡単に破られます！）
minlen = 12
# 最低でも「大文字」「小文字」「数字」「記号」のうち、何種類を混ぜる必要があるかを指定します
# 4種類すべてを含める場合は -4 に設定します
minclass = 4
# 同じ文字が連続して使える最大数です（例: aaa は禁止、など）
maxrepeat = 2
# 辞書に載っているような単語（password や admin など）が含まれていないかをチェックします
gecoscheck = 1このように設定しておけば、開発者やユーザーがうっかり「甘いパスワード」を設定しようとしても、システム側が「ダメです！」と跳ね返してくれます。これで第一の防壁はバッチリです。
—
3. pam_faillock で悪意ある「鍵ガチャ」を阻止する
次に、どれだけ複雑なパスワードにしていても、攻撃者が何億回もパスワードを総当たりで当ててくる「ブルートフォース攻撃」への対策です。
実世界のマンションであれば、オートロックの前で怪しい男が1分間に100回も鍵穴に違う鍵を差し込んでいたら、管理人さんが飛んできて警察に通報するか、インターホンを一時的にロックしますよね。
Linuxサーバーでも同じように、「何回連続でログインに失敗したら、一定時間そのアカウントをロックする」 という設定を pam_faillock というモジュールで行います。
設定の手順とポイント
現代の多くのLinuxディストリビューション（RHEL/CentOSやUbuntuなど）では、/etc/pam.d/common-auth や /etc/pam.d/system-auth といったファイルにPAMの設定が記述されています。
ここに、以下のような設定を組み込みます。
# ログイン失敗の記録とロックアウトを制御する設定例
# 認証失敗時の試行回数やロック時間を管理するモジュールを組み込む
auth required pam_faillock.so preauth audit silent deny=5 unlock_time=900
auth [success=1 default=ignore] pam_unix.so
auth [default=die] pam_faillock.so authfail audit deny=5 unlock_time=900ここで使われているパラメーターの意味を、一つずつ優しく噛み砕いて説明しますね。
deny=5- 「パスワード入力を 5回連続で間違えたら アウト（ロックする）」という意味です。うっかりミスを許容しつつ、ボットによる無限アタックを防ぎます。
unlock_time=900- 「ロックされたアカウントを 900秒（＝15分間） そのまま凍結する」という意味です。攻撃者は15分間足止めを食らうため、攻撃のスピードが劇的に落ち、実質的に総当たり攻撃が無力化されます。
もし万が一、正当なユーザーがパスワードを忘れすぎてロックされてしまっても、15分待てば自動的に解除されますし、管理者であればコマンド一つで即座にロックを解除してあげることも可能です。
—
4. 現場のプロがこっそり教える、設定時の「泥臭い」注意点
教科書やマニュアルには「これを設定すれば安全です」とサラッと書いてありますが、現場のインフラエンジニアやホワイトハッカーが実際にこの設定を入れるときは、いくつかの「泥臭い罠」に気をつけています。
ここで、実務で絶対にやってはいけない失敗談をシェアしておきますね。
1. リモート接続（SSH）で自分を締め出さない
- 設定ファイルを編集したあと、必ず「別のターミナルウィンドウ（タブ）を開いたまま」で、正常にログインできるかテストしてください。もし設定をミスしていると、今開いているセッションを切った瞬間に「自分自身すら二度とログインできない孤島のサーバー」が完成してしまいます。これはインフラエンジニアあるあるの冷や汗ポイントです！
2. サービスアカウントへの配慮
- 人間ではなく、バッチ処理や外部システムが自動連携で使うような「システム用のアカウント」に対して、厳しすぎるパスワードポリシーやアカウントロックを適用してしまうと、システム連携が突然止まって大障害に繋がることがあります。人間が使うアカウント（対話型シェルを持つアカウントなど）と、システム用のアカウントはしっかりと切り分けて設定しましょう。
—
まとめ：一歩ずつ、確実にサーバーを強固にしていこう
今回は、PAMを用いたパスワードの複雑性強制（pam_pwquality）と、ブルートフォース攻撃対策（pam_faillock）についてお話ししました。
セキュリティ対策というと、なんだか難解な暗号や、見たこともない黒い画面の呪文をたくさん打つイメージがあるかもしれません。ですが、本質はいつもシンプルです。
- 「破られにくい鍵（パスワード）をルール化する」
- 「怪しい動きを検知したら、一時的に扉を閉ざす（ロックアウト）」
この2つをサーバーの門番（PAM）にしっかりと覚え込ませるだけで、あなたのサーバーの安全性は劇的に跳ね上がります。
焦る必要はありません。まずは手元の検証環境やテスト用のサーバーから、一歩ずつ設定を試してみてくださいね。あなたのエンジニアライフとサーバーの安全を、心から応援しています！
コメント