The Road to Genecialist!

RHEL4からREHL5にバージョンアップを考えているので設定を確認しています。

ログインに三回失敗するとアカウントロックされる設定で少し悩みました。というのは、RHEL4のpamモジュールとRHEL5のモジュールでバージョンが異なり、使い方が変更されているのです。

ログインの失敗回数を数えるにはpam_tally.soモジュールを使用します。

RHEL4では失敗の許容回数を指定する"deny="オプションをaccountで指定していたのですが、RHEL5になってからはauthで指定するように変更になっています（"deny="だけでなく、ほとんどがauthに移動されています）。

また、今まであまり気にしなかった各行の順番でも動作が変わるのです（ここは勉強しないといけないですね。モジュール間で値をやりとりしているのでしょう）。

何気なくpam_tally.soの行をauthの最後に付け加えていたのですが、ここでは何度ログインに失敗しようとも、正しいパスワードを入力すればログインできてしまいます(失敗カウントは増えていきます)。
正しくはpam_unix.soの前に記述する必要があります。

"
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth       required pam_env.so
auth       required pam_tally.so onerr=fail deny=3
auth       sufficient pam_unix.so nullok try_first_pass
auth       requisite pam_succeed_if.so uid >= 500 quiet
auth       required pam_deny.so

account    required pam_unix.so
account    sufficient pam_succeed_if.so uid < 500 quiet
account    required pam_permit.so

password  requisite pam_cracklib.so try_first_pass retry=3
password  sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password  required pam_deny.so

session   optional pam_keyinit.so revoke
session   required pam_limits.so
session   [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session   required pam_unix.so
"

RHEL5で確認

ちなみにRHEL3/4での設定では下記の通りになります。"deby="オプションの行はpam_unix.soの前に記述されていなくても有効になります（こっちではaccountで設定）。

とはいえ、RHEL5ではpam_unix.soの前でしか有効にならなかったし、Securing and Hardening Red Hat Linux Production Systemsというドキュメント内のLocking User Accounts After Too Many Login Failuresセクションで示されている例でもpam_unix.soの前に記述されているのでそのように設定しています。

RHEL3(LDAPが入っているのでちょっと異なる)
"
]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_tally.so deny=2 no_magic_root reset

password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so
"

RHEL4
"
]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/$ISA/pam_env.so
auth        required      /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so
account     required      /lib/security/$ISA/pam_tally.so deny=3 no_magic_root reset
password    required      /lib/security/$ISA/pam_cracklib.so retry=3 type= difok=3 minlen=8 dcredit=-1 lcredit=-1
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=12
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
"

RHEL3/4/5で確認

P.S.
複数スペースが入る場合の書き方が難しいです。スペースが複数個あるとNucleusが自動的に一つに集約してくれてしまいます・・・

XDMCP接続でLinuxサーバーに接続してるのですが、スクリーンセーバーが実行された後、パスワード解除が出来ないという問題が発生しました。

パスワードロックがかかりました。


パスワードを入力します。


認証に失敗し、パスワード入力欄に"Sorry!"と表示されます。


デフォルトでの設定は、アイドル時間が10分あるとスクリーンセーバーが起動し、解除するにはパスワードを入力する必要があります。
スクリーンセーバーの設定については/usr/X11R6/lib/X11/app-defaultsにあるXScreenSaverに記述されています。

スクリーンセーバー起動時間は
*timeout:00:10:00

パスワードロックがかかる設定については
*lock:True

この現象が発生したとき、

messagesには

Oct 13 11:23:31 hostname pam_tally[30076]: Error opening /var/log/faillog for update
Oct 13 11:23:33 hostname pam_tally[30076]: Error opening /var/log/faillog for update
Oct 13 11:23:33 hostname xscreensaver(pam_unix)[30076]: authentication failure; logname= uid=500 euid=500 tty=:0.0 ruser= rhost= user=root
Oct 13 11:23:33 hostname xscreensaver[30076]: pam_ldap: error trying to bind as user "uid=root,ou=Users,dc=test-domain,dc=com" (Invalid credentials)

secureには

Oct 13 11:23:35 hostname xscreensaver[30076]: FAILED LOGIN 2 ON DISPLAY "123.456.789.123:0.0", FOR "adminuser"

と書かれますので/var/log/faillog(ログイン失敗回数を記録するファイル)へのアクセスに失敗していると思われます。
secureの"FAILED LOGIN 2 ON"のカウントは失敗するごとに増えていきますが、pam_tallyのカウントとは違うようです。

いろいろ調べてみるとsystem-authのauthに書いているpam_tally.soの中で、"onerr=fail"を消すと動くというので試してみるとパスワード解除が出来るようになりました。
この"onerr=fail"はパスワードファイル等へのアクセスに失敗した場合には認証失敗とする意味ですので、今回の事象ではまさにドンぴしゃり！

ただ、これをはずしておくと通常のログイン時に認証が弱くなってしまいそうなのでつけておきたいオプション。

今回は対処療法的に、スクリーンセーバーの設定でパスワードロックがかからないようにします。前述ファイルの*lockをFalseにすればスクリーンセーバーが起動してもロックはされなくなります。
また、Linux側でスクリーンセーバーがかからないように*timeoutの時間も24:00:00にすることにしました。Linux側ではなく、XDMCPで接続している元のWindowsでスクリーンセーバーとパスワードロックがかかれば良いという話でまとまりましたので。
今回思い切ってスクリーンセーバーをアンインストールしようとも考えたのですが、依存関係が多くてちょっと怖いのでやめました。本番システムだし。


ちなみに、今回の事象については下記に記載がありました。

Securing and Hardening Red Hat Linux Production Systemsというドキュメント内のLocking User Accounts After Too Many Login FailuresセクションのNOTEです。以下引用

Since the /var/log/faillog is owned by root and only root can write to the /var/log/faillog file, xscreensaver and vlock won't work correctly. Each time xscreensaver or vlock is executed as a non-root user, you won't be able to do an unlock since these programs can't write to /var/log/faillog. I don't have a good solution for that. I can only think of setting the SUID bits on these programs.


訳：
/var/log/faillogはroot所有でrootのみが書き込み可能なファイルですので、xscreensaverもしくはvlockは正常に動作しません。xscreensaverもしくはvlockがnon-rootユーザーで実行された場合、ロック解除をすることが出来ません。これらのプログラムが/var/log/faillogを変更することが出来ない為です。これについて解決策はありません。xscreensaverもしくはvlockにSUIDビットを設定すれば良いのではないかと考えています。

今回の事象はRHEL3/4で発生します。

先日、pam_tally.soの記述が二ファイル(loginとsystem-auth)に書かれていることで、ログイン失敗について厳しかったことが発覚した。

本番サーバーではsystem-authに記述していることもあり、開発の各サーバーでもログイン失敗のカウントはloginファイルではなく、system-authファイルに記述することに決めた。

作業は別に何をするわけでもなく、ただ、loginファイルに書かれている

"
auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so per_user deny=3 no_magic_root reset
"

をsystem-authに書き写すだけ。

作業終了後、念のため動作確認をしてみた。telnetで接続し、わざと3回間違えてアカウントがロックされるかどうかを確認する。

RHEL3とRHEL4とで動作が違うことに気がついた。

RHEL3では、"deny=3"と設定すると「3回の間違いまでは許します」という動きに対し、
RHEL4では、"deny=3"と設定すると「3回失敗するとロックします」という動きだった。

当環境の詳細なバージョンは下記の通り
RHEL3(2.4.21-20)
pam(0.75)

RHEL4(2.6.9-43)
pam(0.77)

でも、"/usr/share/doc/pam-<version>/txts/README.pam_tally"に違いはないんだよなぁ・・・

今朝、隣に座っている開発リーダーから質問があった。

「ねぇねぇ、この開発サーバーだけ、ログインに失敗するとfaillogに2カウントされるんだけど」

「？ん？どういう事？」と実演を見てみた。

"pam_tally.so"を設定していると"/var/log/faillog"というファイルが作成され、ログイン情報が記録される。
通常、ログインに失敗すると、失敗カウントが1ずつ増えていく。そして、設定した限界値に達するとその後のログインが出来なくなるわけです。
問題のサーバーでは通常1ずつ増えていく失敗カウントが2ずつ増えていくのです。

何か設定間違いをしてしまったのかと思い、"/etc/pam.d"にあるsystem-authファイルをチェックする。

"
auth required /lib/security/$ISA/pam_tally.so onerr=fail no_magic_root
account required /lib/security/$ISA/pam_tally.so per_user deny=3 no_magic_root reset
"
上記2エントリが追加されているだけで、怪しい箇所は見受けられない。一回のカウント数を決める箇所もないし・・・

少しググってみると、system-authに書く派とloginに書く派があることがわかったので、うちのサーバーのloginを見てみると・・・書いてありました。

サーバーの設定を変更する要件があって、僕はsystem-authに追加していたのですが、前任管理者はloginに追加していたのです。知らなかった・・・

デフォルトのloginにはpam_tally.soの記述など無く、設定は全てsystem-authを参照してねという
"
pam_stack.so service=system-auth
"
が全てのエントリについて記述されている。

通常は全ての動作はsystem-authを見てそれに従う設定になっています。

今回の事象ではまず、loginを読み込んでfaillogに1追加し、次にsystem-authを読み込んでfaillogに1追加するので、全体としては2追加されることになっていたのです。

loginからpam_tally.soのエントリを削除して解決です。

もう一つ罠が仕掛けられていました。"deny=2"と設定されていたのです。一回間違えると失敗カウントが2になり、限界値2に達し、その後はログイン出来なくなってしまいます・・・あぁつかいずらいサーバーだったこと