PTSログインの「最後の」出力でIP情報が欠落している理由は？
私は5つのCentOS 6 Linuxシステムを稼働させていますが、私が持っているすべてのLinuxシステムでmy useridでのみ発生するような奇妙な問題が発生しました...これは例ですlastコマンドから除外したエントリの問題の...
mpenning pts/19 Fri Nov 16 10:32 - 10:35 (00:03)
mpenning pts/17 Fri Nov 16 10:21 - 10:42 (00:21)
bill pts/15 sol-bill.local Fri Nov 16 10:19 - 10:36 (00:16)
mpenning pts/1 192.0.2.91 Fri Nov 16 10:17 - 10:49 (12+00:31)
kkim14 pts/14 192.0.2.225 Thu Nov 15 18:02 - 15:17 (4+21:15)
gduarte pts/10 192.0.2.135 Thu Nov 15 12:33 - 08:10 (11+19:36)
gduarte pts/9 192.0.2.135 Thu Nov 15 12:31 - 08:10 (11+19:38)
kkim14 pts/0 :0.0 Thu Nov 15 12:27 - 15:17 (5+02:49)
gduarte pts/6 192.0.2.135 Thu Nov 15 11:44 - 08:10 (11+20:25)
kkim14 pts/13 192.0.2.225 Thu Nov 15 09:56 - 15:17 (5+05:20)
kkim14 pts/12 192.0.2.225 Thu Nov 15 08:28 - 15:17 (5+06:49)
kkim14 pts/11 192.0.2.225 Thu Nov 15 08:26 - 15:17 (5+06:50)
dspencer pts/8 192.0.2.130 Wed Nov 14 18:24 still logged in
mpenning pts/18 alpha-console-1. Mon Nov 12 14:41 - 14:46 (00:04)
上記の私のptsログインエントリのうち、送信元IPアドレスが関連付けられていないものを2つ確認できます。私のCentOSマシンには、システムを共有する最大6人のユーザーがいます。ログインの約10％でこの問題が発生していますが、他のユーザー名がこの動作を示していません。送信元IPアドレスのないエントリの/var/log/secureにはエントリがありません。
ご質問
これらのシステム（ネットワークインフラストラクチャの大部分を制御します）で保持しているスクリプトの種類を考えると、これに少し驚かされて、ログインがソースアドレスを時々見逃す原因となるものを理解したいと思います。
- なぜ
last -iが0.0.0.0を表示するのかpts行エントリ（ this answer も参照） - 動作を合理的に説明できる何か（悪意のあるアクティビティ以外）はありますか？
- Bash履歴のタイムスタンプ以外に、問題を追跡するために他にできることはありますか？
情報提供
これが始まって以来、bash履歴タイムスタンプ（つまりHISTTIMEFORMAT="%y-%m-%d %T "の.bash_profile）を有効にし、 他のbash履歴ハック ;も追加しました。ただし、これは以前の発生中に何が起こったかの手掛かりを与えません。
すべてのシステムはCentOS 6.3を実行しています...
[mpenning@typo ~]$ uname -a
Linux typo.local 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[mpenning@typo ~]$
編集
last -i mpenningを使用すると、次のようなエントリが表示されます...
mpenning pts/19 0.0.0.0 Fri Nov 16 10:32 - 10:35 (00:03)
mpenning pts/17 0.0.0.0 Fri Nov 16 10:21 - 10:42 (00:21)
screenコマンドまたはGUIでログインしていません。ログインはすべてSSHからのものです。賞金を受け取るには、SSH経由でのみ提供されるlast -i0.0.0.0エントリを説明するauthoritative参照を引用する必要があります。
編集2（ewwhiteの質問用）
/etc/resolv.conf（会社の情報を非表示にするために、上記のlast出力で.local addrsを使用したことに注意してください）
[mpenning@sasmars network]$ cat /etc/resolv.conf
nameserver 192.0.2.40
nameserver 192.0.2.60
domain mycompany.com
search mycompany.com
[mpenning@sasmars network]$
/etc/hostsinfo（このカスタマイズされたホストファイルは、これらの問題が発生しているマシンの1つにのみ存在することに注意してください）
[mpenning@sasmars network]$ cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
192.0.2.44 sasmars.mycompany.com sasmars
::1 localhost6.localdomain6 localhost6
## Temporary kludge until I add reverse hostname mappings...
## Firewalls
192.0.2.254 a2-inet-fw1
192.0.2.253 a2-inet-fw2
192.0.2.254 a2-wan-fw1
192.0.2.253 a2-wan-fw2
192.0.2.201 a2-fab-fw1
192.0.2.202 a2-fab-fw2
192.0.2.203 t1-eds-fw1
192.0.2.42 sasvpn
192.0.2.246 sasasa1
192.0.2.10 sasoutfw1
## Wireless
192.0.2.6 saswcs1
192.0.2.2 l2wlc3
192.0.2.4 l2wlc4
192.0.2.12 f2wlc5
192.0.2.16 f2wlc6
192.0.2.14 f2wlc1
192.0.2.8 f2wlc2
[mpenning@sasmars network]$
sftp/var/log/secure *からの出力
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: called (pam_tacplus v1.3.7)
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: user [mpenning] obtained
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: called
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: obtained password
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: password obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: tty [ssh] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: rhost [192.0.2.91] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: trying srv 0
Dec 26 10:36:38 sasmars sshd[26016]: Accepted password for mpenning from 192.0.2.91 port 55118 ssh2
Dec 26 10:36:38 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26016]: pam_unix(sshd:session): session opened for user mpenning by (uid=0)
Dec 26 10:36:38 sasmars sshd[26018]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26018]: subsystem request for sftp
Dec 26 10:37:20 sasmars sshd[26016]: pam_unix(sshd:session): session closed for user mpenning
Dec 26 10:37:20 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
最終的な解決策
以下を参照 以下の私の答え
script RedHatとDebianの動作の違い
リンクされたライブラリ
CentOS 6.3-スクリプト（util-linux-ng 2.17.2）
#ldd /usr/bin/script
linux-vdso.so.1 => (0x00007fff077ff000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f309f5d1000)
libutempter.so.0 => /usr/lib64/libutempter.so.0 (0x00007f309f3cf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f309f03b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f309f7e1000)
Ubuntu 12.04-スクリプト（util-linux 2.20.1）
#ldd /usr/bin/script
linux-vdso.so.1 => (0x00007fff375ff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc0d7ab0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc0d76f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d7cdc000)
PTY
両方のバージョンの アップストリームソースコード 、scriptに基づいて、新しいptyを開きます。以下はテストです。
Ubuntu 12.04
john@U64D211:~/tmp$ ls /dev/pts
0 1 5 8 ptmx
john@U64D211:~/tmp$ script
Script started, file is TypeScript
john@U64D211:~/tmp$ ls /dev/pts
0 1 2 5 8 ptmx
john@U64D211:~/tmp$ last -i
john pts/0 0.0.0.0 Sat Jan 5 09:09 still logged in
reboot system boot 0.0.0.0 Sat Jan 5 09:08 - 09:52 (00:44)
john pts/0 0.0.0.0 Thu Jan 3 00:50 - 01:42 (00:52)
reboot system boot 0.0.0.0 Thu Jan 3 00:48 - 01:43 (00:54)
wtmp begins Tue Jan 1 20:48:28 2013
john@U64D211:~/tmp$ exit
exit
Script done, file is TypeScript
john@U64D211:~/tmp$ ls /dev/pts
0 1 5 8 ptmx
john@U64D211:~/tmp$
Ubuntu 12.04 scriptは新しいpts（2）をオープンしました。 /var/log/wtmpは更新されませんでした。
CentOS 6
scriptはptyを開いてwtmpに登録することをすでに知っているので、テストをスキップしています。
libutemper
- プロジェクト： http://freecode.com/projects/libutempter
- 説明：libutempterは、screenやxtermなどの端末エミュレーターにライブラリー・インターフェースを提供して、ユーザー・セッションをutmpおよびwtmpファイルに記録します。
したがって、主な違いは、リンクされた追加のライブラリ（libutempter.so.0）CentOS scriptのようです。
Ubuntu 12.04でテストします
_scriptをlibutempterでコンパイルする
john@U64D211:~/tmp/util-linux-2.20.1$ Sudo apt-get install libutempter-dev
john@U64D211:~/tmp/util-linux-2.20.1$ ./configure --with-utempter
john@U64D211:~/tmp/util-linux-2.20.1$ make
john@U64D211:~/tmp/util-linux-2.20.1$ cd term-utils/
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ldd ./script
linux-vdso.so.1 => (0x00007fff54dff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f289e635000)
libutempter.so.0 => /usr/lib/libutempter.so.0 (0x00007f289e432000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f289e072000)
/lib64/ld-linux-x86-64.so.2 (0x00007f289e861000)
テスト
実行する前にscript
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0 1 5 8 ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john pts/0 0.0.0.0 Sat Jan 5 09:09 still logged in
reboot system boot 0.0.0.0 Sat Jan 5 09:08 - 10:37 (01:28)
john pts/0 0.0.0.0 Thu Jan 3 00:50 - 01:42 (00:52)
reboot system boot 0.0.0.0 Thu Jan 3 00:48 - 01:43 (00:54)
wtmp begins Tue Jan 1 20:48:28 2013
script内
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ./script
Script started, file is TypeScript
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0 1 2 5 8 ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john pts/2 0.0.0.0 Sat Jan 5 10:37 still logged in
john pts/0 0.0.0.0 Sat Jan 5 09:09 still logged in
reboot system boot 0.0.0.0 Sat Jan 5 09:08 - 10:37 (01:29)
john pts/0 0.0.0.0 Thu Jan 3 00:50 - 01:42 (00:52)
reboot system boot 0.0.0.0 Thu Jan 3 00:48 - 01:43 (00:54)
wtmp begins Tue Jan 1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ exit
exit
Script done, file is TypeScript
script終了後
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0 1 5 8 ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john pts/2 0.0.0.0 Sat Jan 5 10:37 - 10:37 (00:00)
john pts/0 0.0.0.0 Sat Jan 5 09:09 still logged in
reboot system boot 0.0.0.0 Sat Jan 5 09:08 - 10:37 (01:29)
john pts/0 0.0.0.0 Thu Jan 3 00:50 - 01:42 (00:52)
reboot system boot 0.0.0.0 Thu Jan 3 00:48 - 01:43 (00:54)
wtmp begins Tue Jan 1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last
john pts/2 Sat Jan 5 10:37 - 10:37 (00:00)
john pts/0 :0 Sat Jan 5 09:09 still logged in
reboot system boot 3.2.0-35-generic Sat Jan 5 09:08 - 10:38 (01:30)
john pts/0 :0 Thu Jan 3 00:50 - 01:42 (00:52)
reboot system boot 3.2.0-35-generic Thu Jan 3 00:48 - 01:43 (00:54)
wtmp begins Tue Jan 1 20:48:28 2013
空のホスト名の根本的な原因
はい、script.cは空のホスト名でwtmpエントリを作成します。 util-linux-2.20.1/term-utils/script.c Line：245-247の次のコードブロックを見てください。
#ifdef HAVE_LIBUTEMPTER
utempter_add_record(master, NULL);
#endif
libutempter-1.1.5/utempter.hに基づく
extern int utempter_add_record (int master_fd, const char *hostname);
したがって、script.cは実際には空のホスト名をutempter_add_recordに渡します。
RedHatバックポート
興味深いのは、上流のutil-linux-ng-2.17.2が実際にlibutempterをサポートしていないことです。 Redhatはそのサポートを追加することに決めたようです。
john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp
上記のコマンドは空の結果を返します。
結論
したがって、2つのディストリビューションの動作の違いはバグではなく、選択です。 RedHatはその機能のサポートを決定しましたが、Debianはそれをスキップしました。
これは私には完全に不可解に見えます。 DNS名またはIPアドレスを使用する必要があります。 last.cファイルも表示されますが、何も表示されない理由はまだわかりません。おそらくしばらくすると、0.0.0.0程度の部分がわかります。
int dns_lookup(char *result, int size, int useip, int32_t *a)
307 {
308 struct sockaddr_in sin;
309 struct sockaddr_in6 sin6;
310 struct sockaddr *sa;
311 int salen, flags;
312 int mapped = 0;
313
314 flags = useip ? NI_NUMERICHOST : 0;
315
316 /*
317 * IPv4 or IPv6 ?
318 * 1. If last 3 4bytes are 0, must be IPv4
319 * 2. If IPv6 in IPv4, handle as IPv4
320 * 3. Anything else is IPv6
321 *
322 * Ugly.
323 */
324 if (a[0] == 0 && a[1] == 0 && a[2] == htonl (0xffff))
325 mapped = 1;
326
327 if (mapped || (a[1] == 0 && a[2] == 0 && a[3] == 0)) {
328 /* IPv4 */
329 sin.sin_family = AF_INET;
330 sin.sin_port = 0;
331 sin.sin_addr.s_addr = mapped ? a[3] : a[0];
332 sa = (struct sockaddr *)&sin;
333 salen = sizeof(sin);
334 } else {
335 /* IPv6 */
336 memset(&sin6, 0, sizeof(sin6));
337 sin6.sin6_family = AF_INET6;
338 sin6.sin6_port = 0;
339 memcpy(sin6.sin6_addr.s6_addr, a, 16);
340 sa = (struct sockaddr *)&sin6;
341 salen = sizeof(sin6);
342 }
343
344 return getnameinfo(sa, salen, result, size, NULL, 0, flags);
345 }
コンテキストで使用される2つのグローバル変数はこれらです。
int usedns = 0; /* Use DNS to lookup the hostname. */
72 int useip = 0; /* Print IP address in number format */
したがって、理論的には、DNSまたはIPを使用する必要があります。
さらに掘り下げることができるかどうかを確認します。しかし、ewwhiteが尋ねたのは有効な質問です。
（1）OP last出力に基づく
Ssh経由でログインした後、sshでlocalhostにアクセスし、last -iで0.0.0.0を取得できます。
OPのログの最初の4行に基づく
mpenning pts/19 Fri Nov 16 10:32 - 10:35 (00:03)
mpenning pts/17 Fri Nov 16 10:21 - 10:42 (00:21)
bill pts/15 sol-bill.local Fri Nov 16 10:19 - 10:36 (00:16)
mpenning pts/1 192.0.2.91 Fri Nov 16 10:17 - 10:49 (12+00:31)
pts/19ログインはpts/17ログイン期間内でした。
pts/17ログインはpts/1ログイン期間内でした。
この特定の発生については、OPが192.0.2.91（pty/1）からsshであると推測し、そのsshセッション内でサーバーにローカルにログイン（ssh localhost）することをお勧めします（pts/17）、そして再び（pts/19）。
この重複が他の状況で発生するかどうかを確認してください。
以下は、原因を特定するのに役立ちます
- Ssh-keyを使用していますか？その場合、サーバーでローカルにログインするようにssh-keyを設定しましたか？
- 同じ時間枠の/ var/log/secureを確認または投稿します。ヒントが表示される場合があります。
- 使用するスクリプトを確認する
- 使用するシェルエイリアスを確認する
- コマンド履歴を確認する
（2）追加Secnario
シナリオ1-Sudoとターミナル
- UserAログインXウィンドウ
- ターミナルウィンドウを開き、
xhost + localhostを実行します。 su - UserBまたはSudo su - UserB次に、新しいターミナル（xterm、gnome-terminalなど）を開きます。UserBはlast -iで0.0.0.0と表示されます
su - UserBは最後にUserBログインとして登録されませんが、ターミナルを開くと登録されます。
シナリオ2-ログイン
- サーバーにssh
- タイプ
Sudo login - 自分でログイン
lastとlast -iを確認してください
lastは、login sessionのホスト名またはIPを表示しません。 last -iは、login sessionのIP 0.0.0.0になります。
john@U64D211:~$ last -5
john pts/0 Sun Dec 23 20:50 still logged in
john pts/0 Sun Dec 23 20:50 - 20:50 (00:00)
john pts/0 :0 Sun Dec 23 20:50 - 20:50 (00:00)
reboot system boot 3.2.0-35-generic Sun Dec 23 20:49 - 20:50 (00:01)
john pts/2 js.example.com Sun Dec 23 17:14 - crash (03:34)
wtmp begins Sat Dec 1 06:30:46 2012
john@U64D211:~$ last -5i
john pts/0 0.0.0.0 Sun Dec 23 20:50 still logged in
john pts/0 0.0.0.0 Sun Dec 23 20:50 - 20:50 (00:00)
john pts/0 0.0.0.0 Sun Dec 23 20:50 - 20:50 (00:00)
reboot system boot 0.0.0.0 Sun Dec 23 20:49 - 20:50 (00:01)
john pts/2 192.168.1.90 Sun Dec 23 17:14 - crash (03:34)
wtmp begins Sat Dec 1 06:30:46 2012
Mifeの回答にはすでにlast.cのコードブロックが表示されています。 lastが空のホスト名/ IPを表示する理由は、それらのレコードのut_Hostが実際には空であるためです。完全なwtmp構造については、任意のLinuxシステムでman wtmpを実行してください。
ここでの2つのシナリオは、特定の状況下で、標準パッケージでさえ、そのように作成することを示しています。
（3）Bash History Hack
セッションがインタラクティブシェルとしてbashを使用する場合にのみ機能します。
.bashrcおよび.bash_profileはbashのみが使用します。
セッションが他のシェル（sh、cshなど）を使用する場合、またはプログラムを直接実行する場合、これらは自動的に供給されず、bash履歴もありません。
（4）プロセスアカウンティング
OPはsecureファイルについて何も言及していないので、これは行き止まりであり、実際にヒントを提供していると思います。
次の仮定が正しい場合
`last` 0.0.0.0 entries are actually created with in OP own session
auth.log（debian）/ secure（CentOS）は役に立ちません。認証関連のアクションのみが記録されるため。
データ構造に制限があるwtmp/utmpも行き止まりです。それらを作成したものについての情報はありません。
これにより、1つのオプション プロセスアカウンティング が残ります。これは大きな銃であり、注意して使用する必要があります。
- 多分会社の方針に反する
- 共有システムを使用している他のユーザーは、それを有効にすると不満/不快かもしれません
- ログファイルは、多くのディスク領域を使用する可能性があります。ファイルサイズの増加率に注意してください。
この post に従って、psacctパッケージのバージョンは6.3.2-56以上である必要があります。
これを使用する場合で、/var/logのスペースが限られている場合は、acctログファイルを/homeの下のディレクトリ（ルートのみのアクセス）に変更します。
これは本当に大きな銃です。 OP 10％の発生率では、1週間以内に結果が得られるはずです。その期間中に空のエントリがlastに表示されても、acctログから何も表示されない場合、それはmystery状況、そしていくつかの劇的なアクションが必要になります。
以下はlastcommの出力例です
lesspipe john pts/8 0.02 secs Mon Dec 24 17:10
lesspipe F john pts/8 0.00 secs Mon Dec 24 17:10
dirname john pts/8 0.00 secs Mon Dec 24 17:10
basename john pts/8 0.00 secs Mon Dec 24 17:10
kworker/1:2 F root __ 0.00 secs Mon Dec 24 16:54
tty john pts/6 0.01 secs Mon Dec 24 17:09
tty john pts/4 0.01 secs Mon Dec 24 17:09
cron F root __ 0.05 secs Mon Dec 24 17:09
sh S root __ 0.01 secs Mon Dec 24 17:09
find root __ 0.01 secs Mon Dec 24 17:09
maxlifetime root __ 0.00 secs Mon Dec 24 17:09
php5 root __ 0.23 secs Mon Dec 24 17:09
which root __ 0.00 secs Mon Dec 24 17:09
lastcomm root pts/0 0.01 secs Mon Dec 24 17:08
tty john pts/1 0.01 secs Mon Dec 24 17:08
dconf worker X john __ 5.46 secs Mon Dec 24 16:58
lastcomm root pts/7 0.04 secs Mon Dec 24 17:05
mesg S root pts/7 0.00 secs Mon Dec 24 17:05
bash F root pts/7 0.00 secs Mon Dec 24 17:05
dircolors root pts/7 0.00 secs Mon Dec 24 17:05
'dump-acct'を使用して詳細情報を表示することもできます。
PS1：私はいくつかのターミナルとsshセッションを開こうとしました。何が新しいポイントを開くかは明確ではありません（または特定するのは簡単ではありません）ただし、そのpts /セッション内で実行されたすべてが表示されます。
PS2：A blog マイクによるアカウントの使用についての投稿。
だから私はデバッガで最後に走りました、あなたの質問に少なくともいくつかの答えを与えることを願っています。根本的な原因はもっと深いと思いますが。
なぜ最後の-iはpts行エントリに対して0.0.0.0を表示するのですか
これを説明する最良の方法は、dont -iを渡すとどうなるかです。
この理由は、last.cのこのコードセクションにあります
if (usedns || useip)
r = dns_lookup(domain, sizeof(domain), useip, p->ut_addr_v6);
if (r < 0) {
len = UT_HOSTSIZE;
if (len >= sizeof(domain)) len = sizeof(domain) - 1;
domain[0] = 0;
strncat(domain, p->ut_Host, len);
}
usednsとuseipの両方（デフォルトのオプションを使用）にはフラグが付けられていません。これにより、ロジックがp->ut_Hostからコピーし、man utmpには、utmpに書き込まれた内容によって記録されたリモートログイン名が含まれます。
char ut_Host[UT_HOSTSIZE]; /* Hostname for remote login, or
kernel version for run-level
messages */
あなたの場合、ここの値はゼロです。このため、lastを実行しても何も表示されません。
last -iの場合、dns_lookupが呼び出されます。これにより、DNS経由で解決されるエントリ（p-> ut_addr_v6）が渡されます。あなたの場合、この値またにはゼロが含まれます。
dns_lookupの大部分は、窓のドレッシングとヒューステリックです。基本的に重要なのは関数getnameinfoです。これはライブラリ呼び出しであり、この場合、ut_addr_v6に格納されているバイナリ値を解決するために最善を尽くします。このエントリにゼロが含まれている場合（ケースの場合など）は、0.0.0.0の出力で発生するのと同じように、実際にこれをlast -iに解決しています。
動作を合理的に説明できる何か（悪意のあるアクティビティ以外）はありますか？
まあ、それはおそらくバグか見落としです。 anyトレースを送信元アドレスを省略するのではなく、攻撃者として残すのは愚かであるように思われるため、悪意のある可能性は低いです。
これまでの答えの焦点は、間違った場所を見ていました。 lastはutmpまたはwtmpを読み取ります。ただし、lastは、保有しているデータを最大限に活用しています。
根本的な原因は、utmpへの書き込み方法のどこかにあります！
いくつかのアプリケーションがutmpに直接書き込む場合、問題の原因はsshdがセッション管理を処理する方法にあると思います。
Bash履歴のタイムスタンプ以外に、問題を追跡するために他にできることはありますか？
utmpは通常、書き込み可能ではなく、書き込みを行うためのものではありません。 utmpは、ログインしてセッションをセットアップするように設計されたアプリケーションによって作成されます。あなたの場合、それはsshdです。
Sshdがユーザーを適切に処理していない理由は非常に奇妙です。これは、元のホスト名を適切にコピーする必要があるためです。これはおそらくデバッグ作業に焦点を当てるべきです。 sshdのデバッグ出力をログに追加することから始め、異常が発生していないか確認します。
問題を回避したい場合（または問題の詳細を発見する可能性がある場合）は、pam_lastlogを使用してutmpをに追加することで管理できます。 /etc/pam.d/sshdへのセッションエントリ。
実際、すでに存在しているかどうかを確認しても問題ありません。pam_lastlogには、発生している動作を明確に説明するnohostオプションが含まれているためです。
最後に、最後はまったく使えませんでした。 aulastは、監査サブシステムを介して同じジョブを実行します。
それが少なくとも正しいアドレスを書くことができたかどうかを確認するために試してみる価値があるかもしれません。そうでない場合は、sshdがutmpや監査などのさまざまなサブシステムの周りにDNS名を渡しているため、問題がsshdにある必要があります。
マシンにログインすると、これらは最後のコマンドのいくつかのエントリである可能性があります。
geekride tty2 Fri Dec 21 15:45 - 15:45 (00:00)
geekride pts/1 Fri Dec 21 13:45 still logged in
geekride pts/1 :pts/0:S.0 Thu Dec 6 12:49 - 00:40 (11:50)
geekride pts/1 10.31.33.47 Thu Dec 6 12:49 - 00:40 (11:50)
Tty *の最初のエントリは、CTRL + ALT + F1-6を押してターミナルまたはコンソールからログインしたときに表示されます。それが使用している端末からはほとんど明らかです。
2番目のエントリは通常、マシンにログインしてGUIでターミナルウィンドウを開くと表示されます。同じターミナルウィンドウで新しいタブを開いた場合でも、エントリがあります。
3番目のタイプのエントリは、SSH経由でログインした後にスクリーンセッションを開いたときに表示されます。また、IPアドレスなしでエントリが作成されます。
4番目のエントリは、誰もが理解しているかなり正常なものです。
もし、するなら last -i次のエントリを使用すると、次のようになります。
geekride tty2 0.0.0.0 Fri Dec 21 15:45 - 15:45 (00:00)
geekride pts/9 0.0.0.0 Fri Dec 21 13:45 still logged in
geekride pts/1 0.0.0.0 Thu Dec 6 12:49 - 00:40 (11:50)
私はあなたのケースが2つのケースのいずれかに該当すると確信しています。1つはGUIのターミナルウィンドウで、もう1つはスクリーンセッションです。
これがお役に立てば幸いです。
最終的な解決策
私はすでにボーナスを授与したので、これは純粋に同じ質問を持つ将来のグーグルのためのものです。
これが私のログインの〜10％にのみ表示される理由は、ルーターまたはスイッチに大きな変更を加えるときにscript foo.logを使用するため、変更の完全なターミナルログが得られます。まだ理解できない理由により、CentOSはptsコマンドを使用するとscriptエントリを作成します... scriptを実行する前後にlast -iの出力を示します...
[mpenning@sasmars net]$ last -i | head
kkim14 pts/13 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/12 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/10 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/9 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/5 192.0.2.225 Wed Jan 2 09:43 still logged in
mpenning pts/17 192.0.2.29 Mon Dec 31 16:45 - 16:49 (00:03)
gduarte pts/16 192.0.2.135 Thu Dec 27 10:54 still logged in
gduarte pts/14 192.0.2.135 Thu Dec 27 10:44 still logged in
dspencer pts/14 192.0.2.4 Thu Dec 27 09:56 - 09:57 (00:01)
mpenning pts/14 192.0.2.91 Thu Dec 27 08:31 - 08:32 (00:00)
[mpenning@sasmars net]$ script ~/something_random.log
Script started, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ date
Thu Jan 3 16:14:19 CST 2013 # <--------------------------------------------------
[mpenning@sasmars net]$ exit
exit
Script done, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ last -i | head
mpenning pts/15 0.0.0.0 Thu Jan 3 16:14 - 16:14 (00:00) # <------
kkim14 pts/13 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/12 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/10 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/9 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/5 192.0.2.225 Wed Jan 2 09:43 still logged in
mpenning pts/17 192.0.2.29 Mon Dec 31 16:45 - 16:49 (00:03)
gduarte pts/16 192.0.2.135 Thu Dec 27 10:54 still logged in
gduarte pts/14 192.0.2.135 Thu Dec 27 10:44 still logged in
dspencer pts/14 192.0.2.4 Thu Dec 27 09:56 - 09:57 (00:01)
[mpenning@sasmars net]$ cat /etc/redhat-release
CentOS release 6.3 (Final)
[mpenning@sasmars net]$
この動作はCentOS 6に固有のようです...ラボの一部のCentOS 4.7マシンでは、wtmpに空白のエントリを配置していません。Debian/ Gentooマシンもこの動作を示しません。私たちのlinux管理者は、ptsを実行したときにCentOSが別のscriptエントリを意図的に追加する理由を頭を悩ませています...これはRHELのバグだと思います。
[〜＃〜] edit [〜＃〜]：この問題を RHELバグID 892134
注意
~/.bashrcまたは~/.bash_profileにscriptを入れると誤解している人もいます。これは欠陥のある引数です...それが真実である場合、私のwtmpには、sshログインのたびに0.0.0.0エントリが必要です...
[mpenning@sasmars net]$ last -i | head
kkim14 pts/13 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/12 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/10 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/9 192.0.2.225 Wed Jan 2 09:43 still logged in
kkim14 pts/5 192.0.2.225 Wed Jan 2 09:43 still logged in
mpenning pts/18 0.0.0.0 Mon Dec 31 16:45 - 16:49 (00:03) # <-----
mpenning pts/17 192.0.2.29 Mon Dec 31 16:45 - 16:49 (00:03) # <-----
gduarte pts/16 192.0.2.135 Thu Dec 27 10:54 still logged in
gduarte pts/14 192.0.2.135 Thu Dec 27 10:44 still logged in
dspencer pts/14 192.0.2.4 Thu Dec 27 09:56 - 09:57 (00:01)
mpenning pts/15 0.0.0.0 Thu Dec 27 08:31 - 08:32 (00:00) # <-----
mpenning pts/14 192.0.2.91 Thu Dec 27 08:31 - 08:32 (00:00) # <-----
もちろん、そうではありませんでした...
Last.cをデバッグせずにこれでうまくいくとは思いませんが、簡単にコンパイルできるのでそれほど難しくありません...
ただし、1つの可能性は、 tmpdump コマンドを使用して/ var/log/wtmpファイルをダンプし、生のレコードを確認することです。そうでない場合は、いくつかの関連する出力を投稿してください
utmpdump /var/log/wtmp
デバッグするwtmpのローカルコピーを再作成できるように
utmpdump -r <dumpfile >wtmp
12のマルチユーザーCentOSとRHEL 6.3ベースのアプリケーションサーバーを確認しました。誰もこの行動を示しませんでした。 lastの出力には、4〜5週間前のエントリの欠落はありませんでした。
/etc/hostsファイルのエントリを確認して、それを確認することが重要だと思います この形式に準拠 。
また、DNS解決のために何をしていますか？ /etc/resolv.confを投稿できますか？
0.0.0.0がローカル接続を表すことを示す他の応答は正しいです。典型的な例は、リブートおよびコンソールログインイベントです。
reboot system boot 0.0.0.0 Sat Dec 8 06:12 - 05:57 (12+23:45)
reboot system boot 0.0.0.0 Sat Dec 8 05:25 - 06:09 (00:44)
reboot system boot 0.0.0.0 Fri Nov 30 14:28 - 05:22 (7+14:54)
root tty1 0.0.0.0 Fri Nov 30 13:52 - 13:55 (00:03)
reboot system boot 0.0.0.0 Fri Nov 30 13:51 - 14:25 (00:34)
これは指名ユーザーでのみ発生するように見えるので、ログインスクリプトでソース化または実行されているファンキーな変更はありますか？ ~/.bashrcまたは~/.bash_profileをデフォルトから変更しましたか？環境内に他の特別なログインスクリプトはありますか？
-編集-
私はまだこれをいかなる方法でも再現することができません。ただし、2つの重要なコンポーネントを見てみましょう。 lastコマンドは安定しており、長期間変更されていません。 sysvinit-tools の変更ログを見ると、関連するバグはありません。 initscripts （wtmp）も同様です。
これを強制的に実行できる場合は、同じソースマシンの別のユーザーアカウントで試してください。しかし、これがOSの問題であるという兆候は見られません。
疑似端末スレーブ（pts）接続は、システムへの間接接続を意味するSSHまたはtelnet接続です。これらの接続はすべて、コンピューターにコマンドを発行できるシェルに接続できます。したがって、システムの端末をGUIから開くと、ソースIP 0.0.0.0のPTSが開きます。あなたによって提供された情報から、それはこのサーバーで実行されている、またはスケジュールされたスクリプトが原因で発生しているようです。これはsshまたはtelnetサービスまたはローカルptsを使用してターミナルに出力をスローしています。
どのsshクライアントを使用していますか？一部のSSHクライアントは1つの接続で複数の端末を多重化でき、IPのないすべてのセッションが、ログに記録されたIPのある長いセッションに該当することに気付きました。
ここでsshを使用してこの動作を再現することはできません。
おそらく、IPアドレスがDNSサーバーの1つで空白の文字列に解決されます。10％の時間しか発生しない場合はおそらくセカンダリです（または、中央リポジトリから配信されている場合は、おそらくホストファイルです）。これは、欠落した（または空白の）エントリを説明し、Sohamのソースの読み取りと一致します。
ローカルシステムを使用していて、0.0.0.0はすべてのインターフェイスのIPアドレスを意味するために発生します。誰かがハッキングしたと思われる場合は、sshを介してコマンドを含むシェルの完全なロギングを設定してみてください http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/ =
「0.0.0.0」は、それがローカルユーザー（リモートログインではない）であることを意味し、おそらくcronjobなどのアプリケーションによって呼び出されます。