Linux × Security設定の適正化編 ~ユーザ/運用管理~

はじめに

クラウドインテグレーション部の渡邊です。

本記事のシリーズでは、サーバの構築・運用に最低限必要なセキュリティの体系的知識習得を目的としています。

本シリーズの全体像と今回執筆の内容の位置づけは以下の通りです。

• 設定の適正化
  • ソフトウェア管理
  • ユーザ管理 ←今回はここについて説明
  • 運用管理 ←今回はここについて説明
• パケットフィルタリング
• 権限の制御
• 暗号化
• 検知

本内容はLinuxセキュリティ標準教科書に準拠しており、設定の適正化の観点でセキュリティチェック項目表に沿って内容を紹介していきます。

※灰色にマスクされている内容は別の記事で関連する内容を紹介するため割愛しております。

引用元：「Linuxセキュリティ標準教科書」 特定非営利活動法人エルピーアイジャパン p.13

環境

Amazon Linux 2

ユーザ管理

1.1 不要なユーザは、ログインできなくするか、削除する

1つ目は不要なユーザをログイン不可にするか削除することです。

これは不要なユーザによるセキュリティインシデントを防ぐために行います。 不要なユーザが多いほど情報漏洩のリスクが高まるため、ログイン不可にするか削除する対策を推奨します。

ユーザの基礎知識

ユーザの一覧は/etc/passwdで確認ができます。

$ cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
-略-

出力結果に:で区切られているものが出力されています。

各項目についての説明は以下の通りです。

また、新規ユーザ作成時には予約uidgidに注意します。 AmazonLinux2の場合は予約uidgidを以下の通り確認できました。

$ cat /usr/share/doc/setup*/uidgid

NAME UID GID HOME SHELL PACKAGES
root 0 0 /root /bin/bash setup
bin 1 1 /bin /sbin/nologin setup
daemon 2 2 /sbin /sbin/nologin setup
sys - 3 - - setup
adm 3 4 /var/adm /bin/bash setup
tty - 5 - - setup
disk - 6 - - setup
lp 4 7 /var/spool/lpd /sbin/nologin setup
mem - 8 - - setup
kmem - 9 - - setup
wheel - 10 - - setup
cdrom - 11 - - setup
sync 5 (0) /sbin /bin/sync setup
shutdown 6 (0) /sbin /sbin/shutdown setup
halt 7 (0) /sbin /sbin/halt setup
mail 8 12 /var/spool/mail /sbin/nologin setup
news 9 13 /var/spool/news /sbin/nologin setup
uucp 10 14 /var/spool/uucp /sbin/nologin uucp
operator 11 (0) /root /sbin/nologin setup
games 12 (100) /usr/games /sbin/nologin setup
gopher 13 30 /var/gopher /sbin/nologin -(not created by default)
ftp 14 50 /var/ftp /sbin/nologin setup
man - 15 - - setup
-略-

RedHatの資料の章Reserved User and Group IDsを参考にすると、新規ユーザを作成する際は予約済みのID 1000以下の数字を避け、予約範囲の拡大を加味して5000からUIDを割り当てることが望ましいようなのでその点に留意して新規ユーザを作成するとよいと思います。

実際に予約IDのUIDで新規ユーザ作成を試みました、ポイントは以下の通りです。

• 予約IDで新規ユーザを作成することに成功する。しかし、システムユーザを作成する際にUID重複エラーが発生するので予約IDで新規ユーザを作成しないほうがいい。例えば、test-userを予約ID 17（厳密には/etc/login.defsに設定のUIDの範囲外）で作成できるが警告が出る。

$ sudo useradd -m test-user -u 17
useradd warning: test-user's uid 17 outside of the UID_MIN 1000 and UID_MAX 60000 range.

• 予約IDであるかに関わらず重複するUIDを割り当てることは基本的にできない（--non-unique オプションをつければ作成可能）。例えば、既に作成されているUID 14を新規ユーザtest-userに割り当てるとエラーが発生して作成できない。

$ sudo useradd -m test-user -u 14
useradd: UID 14 is not unique

ユーザアカウントのロックと削除をやってみる

まずはユーザアカウントのロックを実際にやってみると正しいパスワードを入力しても認証に失敗しました。 ロックしたユーザはアンロックすることで通常通り使えるようになるので必要なら戻しましょう。

また、不要であればuserdelコマンドでユーザを削除してください、その際にホームディレクトリも同時に削除する-rオプションを指定することをおすすめします。

#通常は切り替えられることを確認
[ec2-user@ip-172-31-9-27 ~]$ su - test-user
Password:
[test-user@ip-172-31-9-27 ~]$ exit
logout

#ユーザアカウントをロックしてパスワード認証によるユーザ切り替えの失敗を確認
[ec2-user@ip-172-31-9-27 ~]$ sudo passwd -l test-user
Locking password for user test-user.
passwd: Success
[ec2-user@ip-172-31-9-27 ~]$ su - test-user
Password:
su: Authentication failure

#ロックしたユーザアカウントをアンロックすることで再び切り替えられることを確認
[ec2-user@ip-172-31-9-27 ~]$ sudo passwd -u test-user
Unlocking password for user test-user.
passwd: Success
[ec2-user@ip-172-31-9-27 ~]$ su - test-user
Password:
Last login: Wed Jul 12 02:48:49 UTC 2023 on pts/2
Last failed login: Wed Jul 12 02:49:22 UTC 2023 on pts/2
There was 1 failed login attempt since the last successful login.

#不要なユーザであるためホームディレクトリごと削除
[ec2-user@ip-172-31-9-27 ~]$ sudo userdel -r test-user

1.2 必要に応じてユーザのパスワードに有効期限をつける

2つ目はパスワード漏洩リスクの軽減です。パスワードの長さと変更頻度に関して考慮する必要があるでしょう。

• パスワードの長さ
  • パスワードが短いと、パスワード総当たり攻撃や辞書を使ったキーワードによる攻撃を受けてしまう可能性が高いです。 仮にパスワード変更しても同様に攻撃が成功してしまう確率は依然高いため、長いパスワードにするべきです。
• パスワードの変更頻度
  • パスワードを長い期間変えないと攻撃が成功してしまう恐れがあります。一方で、有効期限が短いとユーザはログインを簡単にできるように短いパスワードにしたりメモを取ることによる流出などデメリットが有るため適切な頻度を設定する必要があります。 IPAはパスワードポリシーを定めているのでそちらもぜひ参考にしてください。抜粋すると以下の内容が挙げられていました。

最低でも10文字以上の文字数で構成されている。 パスワードの中に数字や、「@」、「%」、「"」などの記号も混ぜている。 パスワード内のアルファベットに大文字と小文字の両方を入れている。 サービスごとに違うパスワードを設定している。

※SSH接続の場合、システム突破のリスクを下げるために鍵によるユーザ管理が主流のためユーザにパスワードを設定する機会はあまりないです。

ユーザのパスワード設定を確認してみると、このようにいくつかの項目が表示されます。

$ sudo chage -l ec2-user

Last password change : Jun 06, 2023
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

各項目についての説明は以下の通りです。これらの設定項目を把握した上で、顧客と相談して更新頻度を検討するとよいと思います。

1.3 su / sudo を使えるユーザを制限する

3つ目は、suコマンドやsudoコマンドの制御です。 suによって、他のユーザに切り替えることができます。このコマンドで特権ユーザにログインすることができます。 sudoによって、特権ユーザとして指定したコマンドを実行することができます。 ユーザアカウントが不正利用された際にシステムが乗っ取られる危険を軽減するため、これらのコマンドは制限する必要があります。

suおよびsudoコマンドの制限に関連する代表的な設定ファイルを以下に示します。

/etc/pam.d/配下のファイルでsuコマンドやsudoコマンドをPAM（特権アクセス管理）で制限します。 /etc/sudoersでsudoコマンドの使える範囲を制限します。

また、/etc/sudoersは非常に重要なファイルのため、viコマンドではなく、visudoコマンドを推奨します。visudoコマンドを使用することで、複数の同時編集に対してsudoersファイルをロックし、基本的な構文チェックをしてくれます。

実際に、やってみます。

suコマンドの制御

/etc/pam.d/suの#auth required pam_wheel.so use_uidのコメントアウトを解除して以下のようにします。 これでwheelグループに属しているユーザのみ suコマンドが出来るように設定変更されました。

#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid
auth substack system-auth
auth include postlogin
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session include postlogin
session optional pam_xauth.so

この時点ではec2-userがwheelグループに属しているため、suコマンドを使って新規ユーザtest-userにログインできます。

[ec2-user@ip-172-31-9-27 ~]$ su - test-user
Password:
Last login: Wed Jul 12 04:56:19 UTC 2023 on pts/2
[test-user@ip-172-31-9-27 ~]$

/etc/groupのwheel:x:10:ec2-userのec2-userを消します。以下の通りになっていればOKです。

$ cat /etc/group | grep wheel
wheel:x:10:

ec2-userが作成したユーザに変更できないことを確認できました。 ec2-userがwheelグループに属していないためsuコマンドの実行に失敗しました。

$ su - test-user

Password:
su: Permission denied

sudoコマンドの制御 

新規ユーザtest-userでsudoコマンドを使用するとエラーが発生します。

$ sudo ls

test-user is not in the sudoers file.

/etc/sudoersのroot ALL=(ALL) ALLの下に test-user ALL=(ALL) ALLを追加することでエラーは出なくなります。

-略-
root ALL=(ALL) ALL
test-user ALL=(ALL) ALL
-略-

それぞれの項目の意味は以下の通りです。

運用管理

2.1 ランレベルを適切に設定し、不要なデーモンを起動させない

1つ目は不要なデーモンの起動を制御することです。 デーモンを起動させることで以下のデメリットがあります。

• 使わないはずのポートが開いていることによる攻撃リスク
• CPU などのリソースを無駄に消費

RHEL7以降やAmazon Linux2では、プロセスを管理する仕組みとしてinitdを廃止し起動ターゲット(systemd)を採用しました。 それぞれの以下の方式でプロセスをコントロールします。

• initd・・・ランレベルの設定でデーモンの自動起動をコントロール
• Systemd・・・各デーモンの自動起動をコントロール

よって、initdで使用したランレベルをsystemdでは使用しません。

Systemd補足

Systemdには以下の特徴があります。

• Linux の起動処理 (init) やユニットの管理を行うソフトウェア群
• ユニットのタイプとして、「target」「mount」「service」 などがある
• 各ユニットでプロセスの起動を制御できる
• 並列でユニットを起動するので素早い
• ターゲットはinitdのランレベルに対応している

ランレベル/ターゲットユニット対応表

※runlevelX.targetは右側のターゲットのシンボリックリンクです

2.2 ログを正確に残す

2つ目はログを正確に残すことです。障害などが発生したときに原因や起こったことを把握するためログを確認します。 ログを正確に残さないと原因の究明が困難になるため、正確に残すようにする必要があります。

ログの設定に関しては以下2点に注意してください。

• ディスク容量を圧迫しないようにログをローテーションすること
  • ログは一つ一つのデータは小さいですが数が膨大になるため、定期的にログを圧縮したり、外部サーバに送ったり、古いログを削除するなど容量を圧迫しないように工夫が必要です
• ログの時刻を正確にするためにサーバの時刻を正確にする
  • ログを参照する際に、時刻が正確でないと障害を特定するのが困難になるため、ntpサーバを正しく設定したり、タイムゾーンを想定のものに設定する必要があります

まとめ

今回はソフトウェア管理の設定の適正化で以下観点を説明しました。

• ユーザ管理
  • 不要なユーザは、ログインできなくするか、削除する
  • 必要に応じてユーザのパスワードに有効期限をつける
  • su / sudo を使えるユーザを制限する
• 運用管理
  • ランレベルを適切に設定し、不要なデーモンを起動させない
  • ログを正確に残す

次回の記事ではパケットフィルタリングについて執筆予定です。ぜひそちらも御覧ください！

【参考】

System Users

第16回　複数のユーザを効率良く管理する（有効期限の制御）

パスワードファイル /etc/passwd の構造