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

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

    目次

      はじめに

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

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

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

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

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

      2023-08-04-14-07-42

      引用元:「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
      -略-

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

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

      項目 rootユーザの例 説明
      ユーザ名 root ユーザのログイン名
      パスワード x 以前はパスワードが記述されていた項目
      ※現在は /etc/shadow に暗号化されたパスワードが記載されているため、この部分は固定文字列 X と表示されています
      ユーザID(UID) 0 ユーザ固有の数字による識別子(UID)
      グループID(GID) 0 ユーザのプライマリーグループの数値識別子(GID)
      ユーザ情報 root ユーザのフルネームや役職など、ユーザに関する追加情報
      ホームディレクトリ /root ユーザのホームディレクトリへの絶対パス
      シェル(Shell) /bin/bash ユーザのデフォルトシェルへの絶対パス

      また、新規ユーザ作成時には予約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

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

      項目 値の例 説明
      Last password change Jun 06, 2023 ユーザのパスワードが最後に変更された日
      Password expires never ユーザのパスワードが失効する日付
      ※例の場合、「never」なので、パスワードは失効しない。
      Password inactive never パスワードが無効になった日からユーザIDが無効になるまでの日数
      Account expires never ユーザアカウントの有効期限が切れる日
      Minimum number of days between password change 0 ユーザが再びパスワードを変更できるようになるまでの最短日数
      ※例の場合、「0」なのでいつでも変更できる
      Maximum number of days between password change 99999 ユーザのパスワード失効までの最大日数
      ※例の場合、「99999」なので期限切れにならない。また、この設定値はPassword expiresに反映される
      Number of days of warning before password expires 7 パスワードの有効期限が切れるまでの警告の日数

       

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

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

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

      コマンド/グループ ファイル 説明
      suコマンド /etc/pam.d/su suコマンドに関連するPAMの設定を格納するファイル。認証プロセスを制御する。
      sudoコマンド /etc/pam.d/sudo sudoコマンドの実行時に使用されるPAMの設定を含むファイル。認証ルールやポリシーを指定する。
        /etc/sudoers sudoコマンドの設定ファイル。特権ユーザのアクセス制御ルールや許可されるコマンドを定義する。
        /etc/sudoers.d sudoコマンドの設定を追加またはオーバーライドするためのディレクトリ。個別の設定ルールを格納する。
      wheelグループ /etc/group グループの情報を格納するファイル。sudoコマンドの実行に必要な特権グループとしてwheelグループがある

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

      また、/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/groupwheel: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-usersudoコマンドを使用するとエラーが発生します。

      $ sudo ls

      test-user is not in the sudoers file.

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

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

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

      項目 説明
      root ルールが適用されるユーザです。
      ALL ルールが適用されるホストです。
      (ALL) コマンドを実行するユーザまたはグループです。
      ALL ユーザが実行することを許可されたコマンドです。

      運用管理

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

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

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

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

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

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

      Systemd補足

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

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

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

      ランレベル ターゲットユニット 説明
      0 runlevel0.target,poweroff.target システムをシャットダウンして、電源を切断
      1 runlevel1.target,rescue.target レスキューシェルを設定
      2 runlevel2.target,multi-user.target 非グラフィカルなマルチユーザシステムを設定
      3 runlevel3.target,multi-user.target 非グラフィカルなマルチユーザシステムを設定
      4 runlevel4.target,multi-user.target 非グラフィカルなマルチユーザシステムを設定
      5 runlevel5.target,graphical.target グラフィカルなマルチユーザシステムを設定
      6 runlevel6.target,reboot.target システムをシャットダウンして再起動

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

       

      2.2 ログを正確に残す

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

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

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

      まとめ

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

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

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

      【参考】

      System Users

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

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

       

      アジアクエスト株式会社では一緒に働いていただける方を募集しています。
      興味のある方は以下のURLを御覧ください。