Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
コンテンツコンテンツ
セキュリティ強化ガイド
  1. 前書き
  2. 1 セキュリティと機密保持
  3. 2 コモンクライテリア (Common Criteria)
  4. I 認証
    1. 3 PAM を利用した認証
    2. 4 NIS の使用
    3. 5 YaST を利用した認証クライアントの設定
    4. 6 389 LDAP ディレクトリサービス
    5. 7 Kerberos を利用したネットワーク認証
    6. 8 Active Directory サポート
    7. 9 FreeRADIUS サーバの構築
  5. II ローカルセキュリティ
    1. 10 物理的なセキュリティ
    2. 11 seccheck を利用した自動的なセキュリティチェック
    3. 12 ソフトウエア管理
    4. 13 ファイルの管理
    5. 14 パーティションやファイルの暗号化
    6. 15 cryptctl を利用したアプリケーション向けのストレージ暗号化
    7. 16 ユーザ管理
    8. 17 Spectre/Meltdown チェッカー
    9. 18 YaST を利用したセキュリティの設定
    10. 19 PolKit による認可制御
    11. 20 Linux でのアクセス制御リスト
    12. 21 証明書ストア
    13. 22 AIDE を利用した侵入検知
  6. III ネットワークセキュリティ
    1. 23 X Window System と X 認証
    2. 24 SSH: 機密を保持するネットワーク操作
    3. 25 マスカレードとファイアウオール
    4. 26 VPN サーバの設定
    5. 27 X Window System で動作する PKI マネージャ XCA による管理
  7. IV AppArmor による権限の制限
    1. 28 AppArmor の紹介
    2. 29 入門
    3. 30 プログラムに対する予防接種
    4. 31 プロファイルのコンポーネントと文法
    5. 32 AppArmor のプロファイルリポジトリ
    6. 33 YaST を利用したプロファイルの構築と管理
    7. 34 コマンドラインからのプロファイル構築
    8. 35 チェンジハット機能による Web アプリケーションのプロファイル作成
    9. 36 pam_apparmor によるユーザの制限
    10. 37 プロファイルを作成したアプリケーションの管理
    11. 38 サポート
    12. 39 AppArmor 用語集
  8. V SELinux
    1. 40 SELinux の設定
  9. VI Linux 監査フレームワーク
    1. 41 Linux 監査システムの概要
    2. 42 Linux 監査フレームワークの設定
    3. 43 監査ルールセットの紹介
    4. 44 その他の情報源
  10. A GNU ライセンス
ナビゲーション
適用先 openSUSE Leap 15.2

16 ユーザ管理

16.1 様々なアカウントのチェック

16.1.1 ロック (施錠) されていないアカウント

ログインに使用していないシステムアカウントやベンダーのアカウントについては、ロック (施錠) を行っておくのが重要です。 /etc/shadow ファイル内のパスワード欄が !* で始まって いない ものが、ロックされていないアカウントになります。また passwd -l コマンドでアカウントをロックすると、同ファイルのパスワード欄の冒頭に !! が追加されますので、これによって簡単にロックを行うことができます。また、 usermod -L でロックを行った場合は、パスワード欄の冒頭に ! が追加されます。多くのシステムや共有アカウントの場合、パスワード欄に *!! が追加されることで、暗号化されたパスワードとしては使用できない文字列となることから、これによってログインを防止しています。このような事情から、ロックされていないアカウントを一覧表示するには、下記のようなコマンドを入力して実行します (egrep で正規表現を使用しています):

root # egrep -v ':\*|:\!' /etc/shadow | awk -F: '{print $1}'

また、 /etc/passwd ファイルのパスワード欄に x が設定されていることも確認しておいてください。下記のコマンドは、パスワード欄に x が書かれていないアカウントの一覧を表示します:

root # grep -v ':x:' /etc/passwd

パスワード欄に x が書かれているアカウントは、そのパスワードが shadow で暗号化されていることを表わします。この場合、実際のパスワードは /etc/shadow 内に暗号化されて記録されます。また、 /etc/passwd ファイルのパスワード欄が空である場合は、 shadow ファイルの参照は行われず、ログイン時のパスワード入力も行われない意味になります。

16.1.2 使用されていないアカウント

ユーザやアプリケーション、システムやデーモンが使用していないシステムアカウントやベンダーアカウントについては、システムから削除しておくべきです。下記のコマンドを使用することで、それぞれのアカウントがどのファイルを所有しているのかを調べることができます:

root # find / -path /proc -prune -o -user アカウント -ls

上記では -prune オプションを設定していますが、これは /proc ファイルシステム以下を読み飛ばす設定です。上記を実行した結果、アカウントを削除しても問題がないと判断できれば、下記のコマンドを実行してアカウントを削除してかまいません:

root # userdel -r アカウント

userdel コマンドに -r オプションを指定しないと、ユーザのホームディレクトリやメールスプールファイル ( /var/spool/mail/アカウント ) が削除されなくなります。なお、多くのシステムアカウントに対しては、ホームディレクトリの設定はありません。

16.2 パスワードの有効期限の設定

パスワードに対して有効期限を設定することは、一般に推奨されるセキュリティ設定です。ただし、システムアカウントや共有アカウント (例: Oracle など) については、このルールから除外しておかないと、パスワードの期限が切れたタイミングで、そのアカウントを使用するアプリケーションが動作しなくなってしまうからです。

一般に企業内のポリシーでは、システムアカウントや共有アカウントのパスワード変更に関する条項を作成しておくべきです。それ以外の一般ユーザのアカウントについては、自動的に期限が切れるように設定しておくとよいでしょう。下記の例では、ユーザアカウントごとにパスワードの有効期限を設定するための方法を示しています。

下記の表には、 useradd コマンドで新しいアカウントを作成する際に使用できる、各種のファイルとパラメータが示されています。これらの設定は、アカウントの作成時に /etc/shadow ファイル内に書き込みが行われます。新しいユーザを作成する際に YaST のツール ( ユーザとグループの管理 ) を使用すると、ユーザごとに設定を行うことができます。また、設定内容によってはシステム全体に適用されるものもあります (たとえば /etc/login.defs ファイルや /etc/default/useradd ファイルの変更がそれにあたります):

/etc/login.defs

PASS_MAX_DAYS

パスワードの最長有効期間 (日) を指定します。

/etc/login.defs

PASS_MIN_DAYS

パスワードの最短有効期間 (日) を指定します。これより短い間隔では、パスワードの変更ができなくなります。

/etc/login.defs

PASS_WARN_AGE

パスワードの変更通知を行う日数を指定します。

/etc/default/useradd

INACTIVE

パスワードの有効期限が切れてから、アカウントが無効化されるまでの日数を指定します。

/etc/default/useradd

EXPIRE

アカウントそのものの有効期限を YYYY-MM-DD の形式で指定します。

注記
注記

上記のファイルは、いずれもアカウントの作成時に適用されるもので、ファイルの変更前に作成されたアカウントについては効果がありません。

上記の /etc/login.defs ファイルや /etc/default/useradd ファイルを変更したことを確認したら、あとは実際にユーザを作成して、 /etc/shadow ファイルにどのような設定が行われるのかを確認します。

新しいユーザを作成するには、下記のようなコマンドを入力して実行します:

root # useradd -c "テストユーザ" -g グループ ユーザ名

-g オプションは、追加するアカウントのプライマリグループを指定するためのオプションです:

root # id ユーザ名
uid=509(test) gid=100(users) groups=100(users)

/etc/login.defs/etc/default/useradd に設定した内容が、新しく作成した test ユーザに対してどのように反映されたのかを確認します。 /etc/shadow ファイル内を下記のようにして表示します:

root # grep ユーザ名 /etc/shadow
test:!!:12742:7:60:7:14::

パスワードの有効期限については、 chage コマンドを使用することでいつでも変更できます。システムアカウントや共有アカウントに対してパスワードの有効期限を無効化したい場合は、 chage コマンドで下記のように入力して実行します:

root # chage -M -1 システムアカウント名

パスワードの有効期限に関する情報を表示するには、下記のように入力して実行します:

root # chage -l システムアカウント名

たとえば下記のようになります:

root # chage -l TEST
Minimum: 7
Maximum: 60
Warning: 7
Inactive: 14
Last Change: Jan 11, 2015
Password Expires: Mar 12, 2015
Password Inactive: Mar 26, 2015
Account Expires: Never

16.3 複雑なパスワードの強制

セキュリティの実践の一環として、ユーザに対し単純なパスワードを禁止するような措置を取っておくことが重要です。パスワードが安全に保管されている限り、複雑なパスワードを設定すれば、容易には侵入できなくなるからです。また、複雑なパスワードを設定しておくことで辞書攻撃からアカウントを保護することができますし、ロックアウト (施錠) と併用すれば、さらに侵入を困難にすることができます。しかしながら、必ずしもこの方式が適切とは限りません。ロックアウトを併用すれば誰もアプリケーションやシステムに入れなくなってしまうことになりますので、サービス拒否攻撃 (DoS) というもう 1 つの問題を引き起こしてしまいます。

このような事情から、まずはパスワードの管理をより現実的かつ効率的に行うことが重要です。多くの企業ではパスワードに対して、 1 文字以上の数字と小文字、大文字を必要とするようにしています。ポリシーは企業によって異なりますが、パスワードの複雑さの強制と効率性の両立は、いくぶん難しいものになります。

16.4 PAM を利用したパスワードとログインの管理

Linux-PAM (Pluggable Authentication Modules for Linux) は共有ライブラリから成るパッケージスイートで、ローカルのシステム管理者に対してアプリケーションからのユーザ認証方法を設定する機能を提供します。

PAM が提供する機能のほか、この仕組みによって提供される環境ごとの最適な構成方式については、よく知っておくことをお勧めします。この設定作業は一度だけ実施すればよく、全てのシステムに対して同じ設定を行っておく (設定の標準化) こともできますし、そこからさらにホスト固有の設定を追加する (特定のホストやサービス、アプリケーションに対するセキュリティ強化) こともできます。これはつまり、この仕組みが非常に柔軟な構造であることを理解することにもなります。

PAM のアーキテクチャを詳しく知りたい場合は、 /usr/share/doc/packages/pam ディレクトリ内にある PAM のドキュメンテーション (英語) をお読みになることをお勧めします。ここには様々な形式が用意されています。

下記の説明では、特にパスワードの強度ポリシーに関する設定など、既定の PAM 設定の変更方法の例を示しています。これにはたとえばパスワードそのものの複雑性のほか、パスワードの再利用やアカウントのロックアウト (一時的な無効化) も含まれます。これらは機能全体のうちのごく一部ではありますが、 PAM の構造や柔軟性を理解するには最適な例です。

重要
重要: pam-config の制限について

pam-config ツールは PAM の設定ファイルのうち、 common-{account,auth,password,session} の各設定ファイルを変更するために使用します。これらのファイルにはグローバルオプションのほか、下記のようなコメントが書かれています:

# This file is autogenerated by pam-config. All changes
# will be overwritten.
# (このファイルは pam-config で自動生成されたものです。直接ここで編集を
# 行っても、上書きされてしまう可能性があります)

それ以外の個別のサービスファイル、たとえば login, password, sshd , su などのファイルについては、手作業で編集しなければなりません。もちろん pam-config を全く使用せず、全てのファイルを手作業で編集してもかまいません。ですが pam-config には古い設定の変換や現在の設定の更新、そして正当性のチェックなど、様々な機能が用意されています。詳しくは man 8 pam-config で表示されるマニュアルページをお読みください。

16.4.1 パスワードの強度

openSUSE Leap ではパスワードの強度を調べるための pam_cracklib ライブラリが提供されています。このライブラリは、パスワードが弱すぎるような場合、より強いパスワードの使用を提案する機能も備えています。下記では、このライブラリが提供する、パスワードポリシーの設定や監査目的で使用する各種のパラメータについて説明しています。

PAM ライブラリは指定された順序で処理を行います。完璧に期待通りの動作になるよう、要件とポリシーをフローチャートの形にまとめてから設定することをお勧めします。

表 16.1: パスワードの強度に関するルール例

pam_cracklib.so

minlen=8

パスワードの文字数の最小値を指定します。ここでは 8 文字を指定しています

pam_cracklib.so

lcredit=-1

パスワードのうち、小文字の文字数の最小値を指定します。ここでは 1 文字を指定しています

pam_cracklib.so

ucredit=-1

パスワードのうち、大文字の文字数の最小値を指定します。ここでは 1 文字を指定しています

pam_cracklib.so

dcredit=-1

パスワードのうち、数字の文字数の最小値を指定します。ここでは 1 文字を指定しています

pam_cracklib.so

ocredit=-1

パスワードのうち、その他の文字数の最小値を指定します。ここでは 1 文字を指定しています

これらのパスワード制限を設定するにあたっては、 pam-config ツールを利用することができます。たとえばパスワードの長さの最小値を設定したい場合は、下記のように入力して実行します:

tux > sudo pam-config -a --cracklib-minlen=8 --cracklib-retry=3 \
--cracklib-lcredit=-1 --cracklib-ucredit=-1 --cracklib-dcredit=-1 \
--cracklib-ocredit=-1 --cracklib

これで新しいパスワードに対する強度チェックが行われるようになります。あとは root 以外のアカウントでログインしなおし、 passwd コマンドでパスワードを設定して試してみるとよいでしょう。なお上記の要件は、 root で passwd コマンドを実行した場合には適用されないことに注意してください。

16.4.2 過去に使用したことのあるパスワードの制限

pam_pwhistory モジュールを使用することで、過去に使用したことのあるパスワードを禁止するように設定することもできます。下記の例では、少なくとも過去 6 ヶ月間は、以前のパスワードを使用できないようにシステムを設定します:

tux > sudo pam-config -a --pwhistory --pwhistory-remember=26

16.2項 「パスワードの有効期限の設定」 では PASS_MIN_DAYS7 を設定しています。これはパスワードを変更する際の最小間隔を指定する項目です。上記のように pam_unix26 を設定すると、過去 26 回分 (つまり、最低でも 26*7 日分 = 約 6 ヶ月分) のパスワードを記憶して、使用できないようにすることができます。

ここまでの pam-config の設定で生成された PAM の設定ファイル ( /etc/pam.d/common-auth ) の内容は、下記のようになります:

auth      required   pam_env.so
auth      required   pam_unix.so     try_first_pass
account   required   pam_unix.so     try_first_pass
password  requisit   pam_cracklib.so
password  required   pam_pwhistory.so        remember=26
password  optional   pam_gnome_keyring.so    use_authtok
password  required   pam_unix.so     use_authtok nullok shadow try_first_pass
session   required   pam_limits.so
session   required   pam_unix.so     try_first_pass
session   optional   pam_umask.so

16.4.3 ログイン失敗時のユーザアカウントのロックアウト

ssh, login, su, sudo などで一定回数以上のログイン失敗が繰り返された場合、対象のアカウントをロックアウトする措置は、一般的なセキュリティ対策として実施されるものです。しかしながら、これを実施してしまうとアプリケーションや管理者、 root ユーザでのログインができなくなってしまいますから、悪意のある攻撃者がサービス拒否攻撃として使用できてしまうものでもあります。幸いなことに、 PAM での制御は非常に直感的です。

既定では PAM は全ての root ログインを許可します。 pam_tally2 モジュールを使用することで、その他のユーザ (一般ユーザおよびシステムユーザ) に対するロックアウトを設定することができます。 /etc/pam.d/login 内の冒頭に下記の内容を記述することで、 root を除く全ユーザに対し、 6 回のログイン失敗時に 10 分間のロックアウトを設定することができます:

auth required pam_tally2.so deny=6 unlock_time=600

下記は /etc/pam.d/login ファイルに設定した場合の例です:

#%PAM-1.0
auth     requisite      pam_nologin.so
auth     include        common-auth
auth     required       pam_tally2.so deny=6 unlock_time=600
account  include        common-account
account  required       pam_tally2.so
password include        common-password
session  required       pam_loginuid.so
session  include        common-session
#session  optional       pam_lastlog.so nowtmp showfailed
session  optional       pam_mail.so standard

root ユーザに対してもロックアウトを設定することができますが、注意してお使いください:

auth required pam_tally2.so deny=6 even_deny_root unlock_time=600

root に対して異なるロックアウトを設定することもできます:

auth required pam_tally2.so deny=6 root_unlock_time=120  unlock_time=600

ロックアウトの解除を自動では行わず、管理者の操作を必要としたい場合は、 unlock_time オプションを削除してください。下記の 2 つのコマンド例では、ログイン失敗回数を表示して、ロックアウト解除を行う例を示しています:

root # pam_tally2 -u username
Login           Failures Latest failure     From
username            6    12/17/19 13:49:43  pts/1

root # pam_tally2 -r -u username

ログインを試した記録は、既定で /var/log/tallylog 内に保存されます。

ロックアウト時間の経過後や管理者によるロックアウト解除を実施すると、上記のカウンタは 0 にリセットされます。

その他のログインサービスで pam_tally2 を使用するには、 /etc/pam.d/ 内にあるそれぞれの設定ファイル (sshd, su, sudo, sudo-i, su-l) に設定を追加してください。

16.5 root ログインの制限

既定では root にはパスワードを設定するため、さまざまな方法でログインができることになります。たとえばローカルの端末やグラフィカルなセッション、 SSH 経由でのログインなどがあります。これらはセキュリティ上の理由から、できる限り制限しておくことが望ましいものです。もちろん root アカウントを共有して使用するようなことも避けるべきです。このようなことから管理者は、 susudo (詳しくは man 1 su コマンドもしくは man 8 sudo コマンドで表示されるマニュアルページをお読みください) などのツールを使用して特権を得るべきです。これにより、管理者でのログインを特定のユーザに結びつけることができるようになります。この方式では root のパスワードに加え、もう 1 つの安全性も提供します。それは root の特権を得るには root のパスワード だけでなく 、管理者 (一般ユーザ) のパスワード認証も突破しなければならないようにできる、という点です。本章では、システムのさまざまなレベルにおいて、直接的な root ログインを制限するための方法を説明しています。

16.5.1 ローカルのテキストコンソールへのログイン制限

TTY デバイスはコンソール経由でのテキストモードアクセスを提供するデバイスです。デスクトップシステムの場合は直接接続されたキーボード経由で、サーバシステムの場合は KVM スイッチやリモートマネージメントカード (ILO, DRAC など) 経由でも使用することができます。既定では、 Linux は 6 つの異なるコンソールを提供します。これらは AltF1 から AltF6 までを押すことで切り替えることができます。グラフィカル環境が動作している場合は、それぞれ CtrlAltF1 から CtrlAltF6 までを押してください。それぞれの端末は tty1 から tty6 に対応します。

下記の手順では、最初の TTY のみを使用できるよう root アクセスを制限しています。この方式は緊急時の管理者アクセスを残しておくためのもので、通常は TTY を使用すべきではありません。

注記
注記

また、ここで示している手順は一般的な PC アーキテクチャ (x86 および AMD64/Intel 64) 向けの設定手順となります。 POWER 等のアーキテクチャの場合は、 tty1 ではないデバイス名になります。また、端末デバイス名は誤って指定することのないように注意してください。現在使用している端末デバイス名を知りたい場合は、 tty コマンドをお使いください。また、 SSH 経由でのログインやグラフィカルなセッションを使用している場合 (表示されるデバイス名が /dev/pts/N のようになります) は設定しないでください。実際のログイン端末 (AltFN でアクセスできるもの) にのみ設定してください。

手順 16.1: ローカル TTY への root ログインの制限
  1. まずは PAM スタックの設定ファイル /etc/pam.d/login 内の auth ブロックに、 pam_securetty モジュールを設定します:

    auth     requisite      pam_nologin.so
     auth     [user_unknown=ignore success=ok ignore=ignore auth_err=die default=bad] pam_securetty.so noconsole
     auth     include        common-auth

    これにより、ローカルコンソールでの認証時に、 pam_securetty モジュールが使用されるようになります。このモジュールは root に対し、ログイン可能な TTY デバイスを制限する機能を提供します。ログイン可能な TTY デバイスの一覧は、 /etc/securetty ファイルで設定します。

  2. /etc/securetty ファイルの内容を編集して、 1 つだけ残すようにします。これにより、 root ユーザが使用できる TTY デバイスを制限できることになります。

    #
    # This file contains the device names of tty lines (one per line,
    # without leading /dev/) on which root is allowed to login.
    #
    tty1
  3. 設定を行ったら、実際に root でログインを試してみて、指定した TTY 以外からログインできなくなっていることを確認します。上記の例ではたとえば tty2 などがそれにあたります。この場合、パスワードを尋ねられることなく即時に拒否されるはずですので、こちらもご確認ください。また、指定した TTY (tty1) からログインできることも確認しておいてください。これにより、ロックアウトされているのではなく、端末の制限でログインできなくなっていることが確定できるためです。

重要
重要

/etc/pam.d/common-auth に対しては pam_securetty を設定してはなりません。設定してしまうと susudo のコマンドにも影響が及ぶことになり、これらのコマンドでも TTY が制限されることになるためです。

重要
重要

上記のように設定変更を行うと、シリアルコンソール (例: /dev/ttyS0) からのログインも制限対象となり、ログインができなくなります。シリアルコンソールからのログインを許可したい場合は、 /etc/securetty ファイル内にシリアルのデバイス名を追加してください。

16.5.2 グラフィカルセッションへのログインの制限

サーバのセキュリティをより高めたい場合は、グラフィカル環境そのものの使用を避けることをお勧めします。グラフィカル環境のプログラムはいずれも root での使用を想定しておらず、コンソールプログラムよりもセキュリティ上の問題となりうる可能性があるためです。どうしてもグラフィカルログインが必要な場合は root 以外でログインするものとし、 root ではグラフィカルログインができないように設定してください。

root に対してグラフィカル環境へのログインを禁止したい場合も、 16.5.1項 「ローカルのテキストコンソールへのログイン制限」 と同じ手順を使用することができます。ディスプレイマネージャに属する PAM スタックの設定ファイル (たとえば GDM であれば /etc/pam.d/gdm) に、 pam_securetty モジュールを追加してください。また、グラフィカルなセッションは TTY デバイス (既定では tty7) で動作していますので、 root のログインを tty1 だけに制限すれば、 root はグラフィカル環境も使用できないようになります。

16.5.3 SSH ログインの制限

既定では、 root ユーザは SSH ネットワークプロトコル経由でログインできるようになっています (SSH ポートがファイアウオールでブロックされていない限り) 。 root でのログインを禁止したい場合は、 OpenSSH の設定を変更することで実現することができます:

  1. /etc/ssh/sshd_config ファイルを編集して、下記のようなパラメータを設定します:

    PermitRootLogin no
  2. あとは sshd サービスを再起動して、設定を適用します:

    systemctl restart sshd.service
注記
注記

OpenSSH の場合、 pam_securetty モジュールでの設定は不適切です。これは SSH の仕様上の理由で、 PAM スタック経由でログインするとは限らない (たとえば SSH は公開鍵認証にも対応しており、この場合は PAM を経由しない) ためです。これに加えて SSH では、パスワードの入力が誤っている場合と、ポリシーによって制限されている場合とで応答が異なるため、悪意のある攻撃者であれば容易に識別されてしまう問題もあります。

16.6 対話型シェルセッションに対する無操作タイムアウトの設定

対話型のシェルに対しては、何も操作していない場合のタイムアウト時間を設定して、一定の時間が経過すると自動的に切断するように設定するとよいでしょう。この設定を行うことでセッションの盗用を未然に防ぐことができるほか、システムリソースの浪費を防ぐことにも繋がります。

既定ではシェルに対する無操作タイムアウトは設定されていません。シェルを開いて何も操作を行わなくても、何日も何年も開いたままになります。ほとんどのシェルには無操作タイムアウトの設定が存在し、一定時間の経過後自動的にセッションを終了させることができます。下記では、一般的に使用されるシェルを対象に、無操作タイムアウトの設定を示しています。

無操作タイムアウトはログインシェルにのみ適用するか、全ての対話型シェルに適用するかを選択することができます。全ての対話型シェルに設定した場合、タイムアウトはそれぞれのシェルで別々に動作し、タイムアウト値は累積して処理されます。言い換えると、サブシェルや子シェルを起動した場合、そのシェルに対しては新しいタイムアウト値が設定されるため、サブシェルもしくは子シェルが時間切れになっても親のシェルはそのタイミングでは終了せず、動作し続けることになります。

下記の表には、 openSUSE Leap に同梱されている各種のシェルと、設定方法に関する一覧が記述されています:

パッケージ使用できるシェルシェル変数時間単位読み込み専用にするための設定方法設定パス (ログインシェルの場合)設定パス (全てのシェルの場合)

bash

bash, sh

TMOUT

readonly TMOUT=

/etc/profile.local , /etc/profile.d/

/etc/bash.bashrc

mksh

ksh, lksh, mksh, pdksh

TMOUT

readonly TMOUT=

/etc/profile.local , /etc/profile.d/

/etc/ksh.kshrc.local

tcsh

csh, tcsh

autologout

set -r autologout=

/etc/csh.login.local

/etc/csh.cshrc.local

zsh

zsh

TMOUT

readonly TMOUT=

/etc/profile.local , /etc/profile.d/

/etc/zsh.zshrc.local

上記のシェルはいずれも内部タイムアウト値の設定が存在し、これに値を設定することで無操作タイムアウトを実現しています。ユーザ側でタイムアウト設定を上書きさせたくない場合は、シェル変数を読み込み専用にしてください。具体的な設定方法も上記で示しています。

注記
注記

この機能は、ユーザがセッションの存在を忘れてしまいがちな状況や、セキュリティに配慮していない使い方に対する対策として設定できる項目であり、悪意に対する対策にはならないことに注意してください。また、このタイムアウト値はシェルの待機状態に対してのみ働くもので、悪意を持ってすれば容易にタイムアウトを無効化できてしまいます。

無操作タイムアウトを設定するには、それぞれのシェルの設定ファイルに対して変数を設定します。ログインシェルのみに設定する場合と、全てのシェルに対して設定する場合とでファイルが異なることにも注意してください。下記の例は bashksh に対して働く設定で、ユーザ側からはタイムアウト値を書き換えることができないよう、読み込み専用の設定を行っています。下記の内容は /etc/profile.d/timeout.sh ファイルを作成して記述してください:

# /etc/profile.d/timeout.sh for SUSE Linux
#
# Timeout in seconds until the bash/ksh session is terminated
# in case of inactivity.
# 24h = 86400 sec
readonly TMOUT=86400
ヒント
ヒント

ログアウト後にもセッションを残しておきたい場合は、 screen ツールをお使いになることをお勧めします。 screen セッションはログアウト時にも終了させられることがなく、必要に応じて再接続できるためです。また、ログアウトせずにセッションをロック (施錠) することもできます (man screen で表示されるマニュアルページで、 Ctrlax ) に関する説明をお読みください) 。

16.7 不用意なサービス拒否攻撃の防止

Linux ではユーザやグループに対して、システムリソースの制限を設定することができます。これはプログラム内にバグ (たとえばメモリリーク) があったような場合に非常に有用な仕組みで、これによってシステムの動作が遅くなったり、場合によっては全く使えなくなってしまったりするようなことを防ぐことができます。また、この制限を設定することにより、プログラムがリソースを使用しすぎてしまい (たとえばプログラムが利用可能なファイルハンドル全てを占有してしまったりなど) 、新しい接続を受け付けられなくなってしまったり、ローカルログインができなくなってしまったりする問題を防ぐこともできます。その反面、リソースの制限はサービス拒否攻撃を容易にしてしまうことにも注意してください。一般的にはユーザやグループに対してリソース制限を設定すると、その用途にもよりますが、システムの保護に役立てることができます。

16.7.1 システムリソースの制限例

下記の例では Oracle というユーザアカウントに対してリソース制限を設定しています。リソース制限の設定項目については、 /etc/security/limits.conf ファイルを読むか、 man limits.conf で表示されるマニュアルページをお読みください。

bash などのようなほとんどのシェルでは、さまざまなリソース (最大ファイルディスクリプタ数や最大プロセス数など) の制限を行うことができます。これらはユーザ単位で設定することができます。現在のシェルでのリソース制限設定を表示するには、下記のようなコマンドを入力して実行します:

root # ulimit -a

bash シェルにおける ulimit の説明については、 bash のマニュアルページをお読みください。

重要
重要: SSH セッションに対する制限の設定について

SSH セッションに対しては、 "hard" や "soft" の制限が期待通りにならないことがあります。正しく動作させたい場合は、いったん root でログインしたのち、対象のユーザ (たとえば oracle) に su をして切り替えるようにしてください。またリソースの制限は、システムの起動時に開始されたアプリケーションに対しても作用させることができます。 SSH 経由でリソース制限が正しく動作していないように見える場合は、 /etc/ssh/sshd_config ファイル内の UsePrivilegeSeparation オプションを "no" に設定して、 SSH デーモンを再起動 ( systemctl restart sshd ) してください。ただし、このような設定は、別の意味でシステムのセキュリティを弱める結果になることに注意してください。

ヒント
ヒント: ssh でのパスワードログインの禁止について

SSH 経由でのログインに際しては、パスワードでのログインそのものを禁止することで、さらに安全性を高めることができます。なお、パスワードでのログインを禁止する場合は、あらかじめ公開鍵でのログインが正しく動作することを確認した後にしてください。パスワードでのログインを禁止するには、 /etc/ssh/sshd_config ファイルに下記のような行を追加します:

UseLogin no
UsePAM no
PasswordAuthentication no
PubkeyAuthentication yes

下記の例では oracle ユーザが開くことのできるファイルおよびファイルハンドルの数を変更しています。この変更は root/etc/security/limits.conf ファイルを編集することで行います:

oracle           soft    nofile          4096
oracle           hard    nofile          63536

上記の "soft" の行は oracle ユーザがログインしてからのファイルハンドル (開いているファイル) の数の上限を設定していて、この値を超過すると警告メッセージが表示されるようになります。絶対的な上限は "hard" の行で設定し、この例では 65536 個までを利用できることになります。コマンドで設定する場合は、下記のように入力して実行します:

root # ulimit -n 63536

上記の "soft", "hard" の値は必要に応じて調整してください。

注記
注記

ulimit を設定する場合は、よく注意して設定してください。 nofile に対して "hard" の上限をカーネルの規定する最大値 ( /proc/sys/fs/file-max ) に設定してしまうと、もしもそのユーザが全てのファイルハンドルを使用してしまった場合、 PAM モジュールにアクセスする際にもファイルハンドルを使用しますので、ログインさえもできなくなってしまうことになります。

リソース制限は pam_limits を使用して設定することもできます。全てのサービスで共通で設定する場合は /etc/pam.d/common-auth ファイルを、 SSH, su, login, telnet など、サービスごとに設定する場合は下記のファイルをそれぞれ編集してください:

/etc/pam.d/sshd (SSH の場合)
/etc/pam.d/su (su の場合)
/etc/pam.d/login (ローカルログインや telnet の場合)

全てのログインに対して適用したくない場合は、 /etc/security/limits.conf ファイルを読み込む PAM モジュールがあります。 PAM の設定ディレクティブは下記のようになります:

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

なお、上記で変更を行っても即時には反映されず、次回のログインから適用されることに注意してください:

root # su - oracle
tux > ulimit -n
4096

また、ここでの説明はいずれも bash シェルを使用した場合の例であり、それ以外のシェルを使用する場合は ulimit オプションが異なることに注意してください。たとえば oracle ユーザに対する制限が 4096 であった場合、これを 63536 まで増やすには、下記のように入力して実行します:

root # su - oracle
tux > ulimit -n
4096
tux > ulimit -n 63536
tux > ulimit -n
63536

ulimit -n 63536 のような設定 (この例では bash) を恒久的に保存したい場合は、 openSUSE Leap が提供する bash シェル向けのスタートアップファイル ( ~/.bashrc ファイルもしくは ~/.profile ファイル) にそれを記述します (使用しているシェルを確認したい場合は、 echo $SHELL を実行してください) 。下記のようなコマンドを実行することで、 bash シェルのリソース制限を設定することができます (設定対象の Linux マシンでお読みの場合は、このままコピー&ペーストしてもかまいません):

root # su - oracle
tux > cat >> ~oracle/.bash_profile << EOF
ulimit -n 63536
EOF

16.8 ログインバナーの表示

ポリシーや監査の理由から、もしくはユーザに対してセキュリティ手順を示しておく理由から、ログイン時にバナーを表示させることができます。

SSH やローカルコンソールなどからユーザがログインした にログインバナーを表示させたい場合は、 /etc/motd (motd = message of the day の略) ファイルにそれを記述します。このファイルは openSUSE Leap の既定で提供されていますが、特に何も書かれていません。表示したい内容をそのまま記述してください。

注記
注記: バナーの長さについて

バナーとして表示するメッセージは、長くても端末 1 ページ以内に収まるようにしてください。端末によってはスクロールして戻ることができない場合があるため、長すぎると読めなくなってしまうことがあるためです。

ログインバナーはテキストベースの端末であれば、ログイン に表示することもできます。ローカルコンソールへのログイン前に表示したい場合は /etc/issue ファイルに内容を記述してください。これはログインプロンプトよりも前に表示されます。 SSH 経由でのログインの場合は、 /etc/ssh/sshd_config ファイルの Banner パラメータを設定してください。こちらも SSH のログインプロンプトよりも前に表示されます。

GDM 経由でのグラフィカルログインの場合は、 GNOME 管理者ガイド (英語) にある手順でログインバナーを設定することができます。これに加えて、 はいいいえ を選択するようなバナーを表示することもできます。これを行うには、 /etc/gdm/Xsession ファイルを編集して、スクリプトの 最初のほう に下記のような内容を記述します:

if ! /usr/bin/gdialog --yesno '
This system is classified...
' 10 10; then
    /usr/bin/gdialog --infobox 'Aborting login'
    exit 1;
fi

上記の This system is classified... の部分に、表示したいバナーテキストを指定します。なお、このダイアログはログイン処理そのものを防ぐ仕組みではありません。 GDM のスクリプト処理について、詳しくは GDM 管理者マニュアル (英語) をお読みください。

16.9 各種のアカウント関連ユーティリティ

下記はユーザログインに関するデータを取得できるコマンドの一覧です:

who: 現時点でログインしているユーザを一覧表示します。

w: 誰がログインしているのかと、何をしているのかを表示します。

last: 直近のユーザログインを一覧で表示します。ログイン日時のほかログアウト日時、 IP アドレスなどの情報が含まれます。

lastb: last と同じ出力を行いますが、こちらはログインの失敗を記録する /var/log/btmp の内容を出力します。

lastlog: このコマンドは、各ユーザの最終ログイン日時を記録する /var/log/lastlog 内のデータを出力します。

ac: acct パッケージをインストールすると利用できるようになるコマンドです。このコマンドは、ユーザ単位もしくは日単位の接続時間を表示します。このコマンドは /var/log/wtmp を読み込んで処理します。

dump-utmp: /var/run/utmp もしくは /var/log/wtmp の内容を読み込んで、これをテキストとして処理可能な形式に変換します。

そのほかにも /var/log/messagesjournalctl コマンドの出力を確認してもかまいません。前者は何らかのログ記録 (syslog) アプリケーションが動作している場合、後者は動作していない場合に使用します。 journalctl で使用する systemd のジャーナル機能については、 第11章 「journalctl : systemd ジャーナルへの問い合わせコマンド をお読みください。