Saya memiliki lima sistem linux CentOS 6 di tempat kerja, dan mengalami masalah yang agak aneh yang sepertinya hanya terjadi dengan userid saya di semua sistem linux yang saya miliki ... Ini adalah contoh masalah dari entri yang saya pengecualian dari lastperintah .. .

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)

Anda dapat melihat dua entri login Poin saya di atas yang tidak memiliki alamat IP sumber yang terkait dengannya. Mesin CentOS saya memiliki sebanyak enam pengguna lain yang berbagi sistem. Sekitar 10% dari login saya melihat masalah ini, tetapi tidak ada nama pengguna lain yang menunjukkan perilaku ini . Tidak ada entri /var/log/secureuntuk entri tanpa alamat IP sumber.

Pertanyaan

Mengingat jenis skrip yang saya simpan pada sistem ini (yang mengendalikan sebagian besar infrastruktur jaringan kami), saya agak takut dengan ini dan ingin memahami apa yang menyebabkan login saya kadang-kadang kehilangan alamat sumber.

• Mengapa last -iditampilkan 0.0.0.0untuk entri baris Poin (lihat juga jawaban ini )
• Adakah sesuatu (selain aktivitas jahat) yang dapat menjelaskan perilaku tersebut secara wajar?
• Selain cap waktu bash history, apakah ada hal lain yang dapat saya lakukan untuk melacak masalah ini?

Informasi

Sejak ini mulai terjadi, saya mengaktifkan bashcap waktu sejarah (yaitu HISTTIMEFORMAT="%y-%m-%d %T "di .bash_profile) dan juga menambahkan beberapa hack sejarah bash ; Namun, itu tidak memberikan petunjuk tentang apa yang terjadi selama kejadian sebelumnya.

Semua sistem menjalankan 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 ~]$

EDIT

Jika saya menggunakan last -i mpenning, saya melihat entri seperti ini ...

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)

Catatan untuk mereka yang mencoba menjawab: Saya belum masuk dengan screenperintah atau GUI . Semua login saya berasal dari SSH; untuk menerima hadiah karunia, Anda harus mengutip referensi otoritatif untuk menjelaskan last -i 0.0.0.0entri yang bersumber hanya melalui SSH.

EDIT 2 (untuk pertanyaan ewwhite)

/etc/resolv.conf(perhatikan bahwa saya menggunakan .localadd-on dalam lastoutput di atas untuk menyembunyikan info perusahaan saya)

[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/hosts info (perhatikan bahwa file host khusus ini hanya ada di salah satu mesin yang memiliki masalah ini)

[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]$

sftpOutput dari /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)

RESOLUSI AKHIR

Lihat jawaban saya di bawah ini

script perbedaan perilaku antara RedHat dan Debian

Perpustakaan Tertaut

CentOS 6.3 - skrip (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 - skrip (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

Berdasarkan kode sumber hulu , scriptdari kedua versi membuka pty baru. Berikut ini adalah tes.

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 scriptmemang membuka Poin baru (2). Itu hanya tidak memperbarui /var/log/wtmp.

CentOS 6

Saya melewatkan tes karena kita sudah tahu yang scriptmembuka pty dan mendaftar dengan wtmp.

libutemper

• Proyek: http://freecode.com/projects/libutempter
• Deskripsi: libutempter menyediakan antarmuka pustaka untuk emulator terminal seperti layar dan xterm untuk merekam sesi pengguna ke file utmp dan wtmp.

Jadi perbedaan utama tampaknya adalah library tambahan ( libutempter.so.0) yang scriptterhubung dengan CentOS .

Uji dengan Ubuntu 12.04

Kompilasi scriptdengan 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)

Pengujian

Sebelum berlari 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

Dalam 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

Setelah scriptakhir

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

Akar penyebab nama host emtpy

Dan ya, script.cbuat wtmpentri dengan nama host kosong. Lihatlah blok kode berikut di util-linux-2.20.1/term-utils/script.cBaris: 245-247

#ifdef HAVE_LIBUTEMPTER
    utempter_add_record(master, NULL);
#endif

Berdasarkan libutempter-1.1.5/utempter.h

extern int utempter_add_record (int master_fd, const char *hostname);

Jadi script.csebenarnya memberikan nama host kosong ke dalamnya utempter_add_record.

RedHat Backport

Yang menarik, hulu util-linux-ng-2.17.2sebenarnya tidak mendukung libutempter. Tampaknya Redhat memutuskan untuk menambahkan dukungan itu kembali.

john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp

Perintah di atas mengembalikan hasil kosong.

Kesimpulan

Jadi perbedaan perilaku antara kedua distro bukanlah bug, tetapi pilihan. RedHat memutuskan untuk mendukung fitur itu, sementara Debian melewatkannya.

Ini terlihat sangat membingungkan bagi saya. Entah itu harus menggunakan nama DNS atau alamat IP. Saya memeriksa last.cfile juga tetapi saya masih tidak dapat menemukan mengapa tidak menunjukkan apa-apa. Mungkin diberi waktu, saya bisa mengetahui bagian tentang 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 }

Dua variabel global yang digunakan dalam konteks adalah ini.

int usedns = 0;     /* Use DNS to lookup the hostname. */
72 int useip = 0;       /* Print IP address in number format */

Jadi, secara teori, harus menggunakan dns atau IP.

Saya akan melihat apakah saya bisa menggali lebih jauh. Tapi apa yang diminta oleh orang kulit putih adalah pertanyaan yang valid.

Jadi saya menjalankan terakhir di debugger yang diharapkan akan memberi Anda setidaknya beberapa jawaban untuk pertanyaan Anda. Perasaan saya adalah penyebab utama lebih dalam.

Mengapa -i terakhir menunjukkan 0,0.0.0 untuk entri baris Poin

Cara terbaik untuk menjelaskan ini adalah apa yang terjadi ketika Anda tidak melakukannya lulus -i.

Alasannya ada di bagian kode ini 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);
}

Keduanya usednsdan useip(menggunakan opsi default) tidak ditandai. Ini menyebabkan logika untuk menyalin keluar dari struct p->ut_hostyang menurut man utmpberisi nama login jarak jauh seperti yang dicatat oleh apa pun yang ditulis ke dalam utmp.

char ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                              kernel version for run-level
                              messages */

Dalam kasus Anda, nilai di sini adalah nol. Inilah sebabnya saat Anda berlarilast tidak ada yang muncul untuk Anda.

Dalam kasus last -imaka dns_lookup dipanggil. Ini akan melewati entri (p-> ut_addr_v6) untuk diselesaikan melalui DNS. Dalam kasus Anda, nilai ini juga mengandung nol.

Sebagian besar dns_lookupadalah rias jendela dan heusteric. Pada dasarnya yang penting adalah fungsinya getnameinfo. Ini adalah panggilan perpustakaan yang dalam hal ini akan mencoba yang terbaik untuk menyelesaikan nilai biner yang disimpan di ut_addr_v6. Ketika entri ini berisi nol (seperti dalam kasus Anda), Anda sebenarnya menyelesaikan ini 0.0.0.0seperti apa yang terjadi dengan Andalast -i output .

Adakah sesuatu (selain aktivitas jahat) yang dapat menjelaskan perilaku tersebut secara wajar?

Yah, itu mungkin bug atau kekhilafan. Its tidak mungkin berbahaya karena tampaknya bodoh untuk meninggalkan setiap jejak sebagai penyerang daripada menghilangkan alamat sumber.

Fokus jawaban sejauh ini mencari di tempat yang salah. lasthanya membaca utmpatau wtmp. Namun lastmelakukan yang terbaik dengan data yang dimilikinya.

Penyebab utama Anda terletak di suatu tempat dengan cara yang utmpsedang ditulis !

Sementara beberapa aplikasi langsung menulis ke utmpsaya kira sumber masalah Anda terletak pada cara sshdmenangani manajemen sesi.

Selain cap waktu bash history, apakah ada hal lain yang dapat saya lakukan untuk melacak masalah ini?

utmpbiasanya tidak dapat ditulisi dan tidak dimaksudkan untuk menjadi. utmpditulis oleh aplikasi yang dirancang untuk login Anda dan mengatur sesi Anda. Dalam kasus Anda itusshd .

Mengapa sshd tidak menangani pengguna Anda dengan benar sangat aneh karena harus menyalin dengan benar pada nama host tempat Anda berasal. Di sinilah upaya debugging mungkin harus difokuskan. Mulailah dengan menambahkan hasil debug sshd ke log Anda dan lihat apakah ada sesuatu yang aneh muncul.

Jika Anda ingin mengatasi masalah (atau, bahkan mungkin menemukan lebih banyak tentang masalah ini) yang dapat Anda gunakan pam_lastloguntuk mengelola utmpdengan menambahkannya ke sesi entri ke /etc/pam.d/sshd.

Sebenarnya tidak ada salahnya untuk memeriksa apakah sudah ada - karena pam_lastlogberisi nohostopsi yang pasti akan menjelaskan perilaku Anda yang Anda alami.

Akhirnya, Anda tidak dapat menggunakan yang terakhir sama sekali. aulastmelakukan pekerjaan yang sama melalui subsistem audit.

Mungkin patut dicoba untuk melihat apakah itu telah berhasil setidaknya menulis alamat yang benar. Jika belum maka masalah Anda harus dengan sshd karena sshd meneruskan nama-nama DNS di sekitar subsistem yang berbeda seperti utmp atau audit.

(1) Mendasarkan pada lastoutput OP

Setelah masuk melalui ssh, seseorang dapat ssh ke localhost dan mendapatkan 0,0.0.0 masuk last -i untuk nanti.

Berdasarkan empat baris pertama log OP

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/19login adalah dalam pts/17periode login.

pts/17 masuk ada di dalam pts/1 periode login.

Untuk kejadian khusus ini, masuk akal untuk menebak bahwa OP ssh dari 192.0.2.91 ( pty/1), kemudian dalam sesi ssh itu, masuk secara lokal ( ssh localhost) ke server lagi ( pts/17), dan lagi (pts/19 ).

Silakan periksa apakah tumpang tindih ini terjadi dengan kejadian lain.

Berikut ini dapat membantu menunjukkan penyebabnya

• Apakah Anda menggunakan ssh-key? Jika demikian, di server, apakah Anda mengatur ssh-key untuk masuk secara lokal?
• Periksa atau pos / var / log / aman dari kerangka waktu yang sama. Ini mungkin memberikan beberapa petunjuk.
• Periksa skrip yang Anda gunakan
• Periksa alias shell yang Anda gunakan
• Periksa riwayat perintah Anda

(2) Secnario Tambahan

Skenario 1 - sudo dan terminal

1. UserA login X Window
2. Buka jendela terminal, lakukan xhost + localhost
3. su - UserBatau sudo su - UserBkemudian buka terminal baru (xterm, terminal gnome, dll)
4. UserB akan ditampilkan sebagai 0.0.0.0 in last -i

su - UserBtidak akan mendaftar sebagai UserBlogin terakhir, tetapi membuka terminal akan.

Skenario 2 - masuk

1. ssh ke server
2. Tipe sudo login
3. masuk sebagai dirimu sendiri
4. periksa lastdanlast -i

lasttidak menunjukkan nama host atau IP untuk login session. last -iakan IP 0.0.0.0 untuk login session.

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

Jawaban Mife sudah menunjukkan blok kode last.c. Alasan lastmenampilkan nama host kosong / IP adalah karena ut_hostuntuk catatan itu sebenarnya kosong. Untuk struktur wtmp lengkap, lakukan man wtmppada sistem linux apa pun.

2 skenario di sini menunjukkan bahwa bahkan paket standar, dalam situasi tertentu, membuatnya seperti itu.

(3) Hack Sejarah Bash

Ini hanya akan berfungsi jika sesi digunakan bashsebagai shell interaktif.

.bashrcdan .bash_profilehanya digunakan oleh bash.

Mereka tidak akan bersumber secara otomatis jika sesi menggunakan shell lain (sh, csh, dll) atau menjalankan program secara langsung, dan tidak akan ada bash history juga.

(4) Proses Akuntansi

Karena OP tidak menyebutkan tentang secure file, saya akan berasumsi bahwa itu adalah jalan buntu dan itu sebenarnya memberikan petunjuk sekarang.

Jika asumsi berikut ini benar

`last` 0.0.0.0 entries are actually created with in OP own session

auth.log (debian) / secure (CentOS) tidak akan membantu. Karena hanya tindakan terkait otentikasi yang dicatat di dalamnya.

wtmp / utmp, dengan keterbatasan dalam struktur datanya, juga merupakan jalan buntu. Tidak ada informasi tentang apa yang membuatnya.

Itu meninggalkan kita dengan satu opsi, proses akuntansi . Ini adalah senjata besar dan harus digunakan dengan hati-hati.

1. Mungkin bertentangan dengan kebijakan perusahaan
2. Pengguna lain pada sistem bersama mungkin tidak senang / tidak nyaman dengan itu diaktifkan
3. File log dapat menggunakan banyak ruang disk. Mengawasi laju pertumbuhan ukuran file.

Versi paket psacct harus 6.3.2-56 atau lebih tinggi, sesuai dengan posting ini .

Jika ini akan digunakan, dan /var/logmemiliki ruang terbatas, ubah file log acct ke direktori (akses hanya root) di bawah /home, yang biasanya memiliki lebih banyak ruang.

Ini benar-benar senjata besar. Dengan tingkat kejadian OP 10%, harus ada hasil dalam seminggu. Jika selama periode itu, entri kosong muncul lasttetapi tidak ada dari log acct, itu menjadi situasi misteri , dan akan memerlukan beberapa tindakan drastis .

Berikut ini adalah contoh output dari 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

Anda juga dapat menggunakan 'dump-acct' untuk menampilkan info lebih lanjut.

PS1: Saya mencoba membuka beberapa terminal dan sesi ssh. Tidak jelas (atau tidak mudah untuk menunjukkan poin) apa yang membuka Poin baru. Namun, itu menunjukkan semua yang berjalan dalam Poin / Sesi itu.

PS2: Posting blog tentang penggunaan acct oleh Mike.

Ketika Anda masuk ke suatu Mesin, ini bisa menjadi beberapa entri dalam perintah terakhir.

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)    

Entri pertama dengan tty * datang ketika Anda masuk melalui terminal atau konsol dengan menekan CTRL + ALT + F1-6. Cukup jelas dari terminal yang digunakannya.

Entri kedua biasanya muncul ketika Anda masuk ke Mesin dan membuka jendela terminal di GUI. Akan ada entri bahkan jika Anda membuka Tab baru di jendela terminal yang sama.

Jenis Entri Ketiga datang ketika Anda membuka sesi layar setelah masuk ke melalui SSH. Itu juga akan membuat entri di sana dan tanpa alamat IP.

Entri keempat cukup normal yang dipahami semua orang.

Jika Anda melakukannya last -idengan entri berikut, Anda akan melihat sesuatu seperti ini:

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)    

Saya cukup yakin bahwa kasing Anda berada di salah satu dari 2 kasing, satu dengan Jendela terminal di GUI dan yang lainnya dengan sesi layar.

Semoga ini bisa membantu.

Saya tidak berpikir kita akan berhasil dengan ini tanpa debugging last.c, tapi itu seharusnya tidak terlalu sulit karena mudah dikompilasi ...

Namun satu kemungkinan adalah untuk membuang file / var / log / wtmp menggunakan perintah utmpdump dan melihat pada catatan mentah ini mungkin memberi sedikit cahaya bagi Anda. Jika tidak, silakan kirim beberapa keluaran yang relevan dari

utmpdump /var/log/wtmp 

sehingga kami dapat membuat ulang salinan lokal dari wtmp Anda untuk di-debug

utmpdump -r <dumpfile >wtmp

Saya memeriksa 12 server aplikasi berbasis CentOS dan RHEL multi-pengguna. Tidak ada yang memperlihatkan perilaku ini. Tidak ada entri yang hilang dilast output akan kembali 4-5 minggu.

Saya pikir akan penting untuk melihat /etc/hostsentri file Anda untuk memastikan itu sesuai dengan format ini .

Juga, apa yang Anda lakukan untuk resolusi DNS? Bisakah Anda memposting/etc/resolv.conf ?

Respons lain yang mengindikasikan 0.0.0.0koneksi lokal benar. Contoh khasnya adalah acara reboot dan konsol login:

 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)    

Karena ini sepertinya hanya terjadi pada pengguna yang diberi nama, apakah ada perubahan ada sesuatu yang funky yang bersumber atau dijalankan dalam skrip login mereka? Apakah Anda sudah berubah ~/.bashrcatau~/.bash_profile dari default? Apakah ada skrip login khusus lainnya di lingkungan?

--Edit--

Saya masih tidak dapat mereproduksi ini dengan cara apa pun. Saya melihat dua komponen penting. The lastperintah stabil dan tidak berubah dalam waktu yang lama. Melihat changelog untuk sysvinit-tools , tidak ada bug yang relevan. Sama untuk skrip init (wtmp).

Jika Anda dapat memaksa ini terjadi, coba dengan akun pengguna yang berbeda dari mesin sumber yang sama. Tapi saya tidak melihat indikasi bahwa ini adalah masalah OS.

RESOLUSI AKHIR

Saya sudah memberikan bonus, jadi ini murni untuk googler masa depan dengan pertanyaan yang sama.

Alasan ini hanya muncul di ~ 10% dari login saya adalah karena ketika saya membuat perubahan besar pada router atau switch kami, saya menggunakan script foo.logjadi saya punya log terminal lengkap dari perubahan. Untuk alasan yang saya masih tidak mengerti, CentOS membuat ptsentri ketika Anda menggunakan scriptperintah ... Saya akan menunjukkan output last -isebelum dan setelah menjalankan script...

[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]$

Perilaku ini tampaknya unik untuk CentOS 6 ... kami memiliki beberapa mesin CentOS 4.7 di lab yang tidak memasukkan entri kosong di wtmp... Mesin Debian / Gentoo juga tidak menunjukkan perilaku ini. Admin-linux kami menggaruk-garuk kepala mereka mengapa CentOS akan dengan sengaja menambahkan ptsentri lain ketika Anda mengeksekusiscript ... Saya menduga ini adalah bug RHEL.

EDIT : Saya mengajukan masalah ini sebagai RHEL Bug id 892134

CATATAN

Beberapa orang telah keliru menganggap aku meletakkan scriptdi saya ~/.bashrcatau ~/.bash_profile. Ini adalah argumen yang cacat ... jika itu benar, saya wtmpharus memiliki 0.0.0.0entri setelah setiap login ssh saya ...

[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)  # <-----

Tentu saja, bukan itu masalahnya ...

Koneksi Pseudo Terminal Slave (pts) adalah koneksi SSH atau telnet yang berarti koneksi tidak langsung ke sistem. Semua koneksi ini dapat terhubung ke shell yang memungkinkan Anda untuk mengeluarkan perintah ke komputer. Jadi, ketika Anda membuka terminal di sistem Anda dari gui, itu membuka Poin dengan sumber ip 0.0.0.0. Dari informasi yang diberikan oleh Anda, tampaknya itu terjadi karena skrip berjalan di server ini atau dijadwalkan, yang menggunakan ssh atau layanan telnet atau Poin lokal untuk melempar output di terminal.

Klien ssh mana yang Anda gunakan? Beberapa klien ssh dapat mengalikan beberapa terminal melalui satu koneksi dan saya perhatikan semua sesi Anda tanpa IP termasuk dalam sesi yang lebih panjang yang memiliki IP yang dicatat.

Saya tidak dapat menduplikasi perilaku ini dengan ssh di sini.

Mungkin alamat IP Anda memutuskan menjadi string kosong pada salah satu server DNS Anda, mungkin yang sekunder jika itu terjadi hanya 10 persen dari waktu (atau mungkin saja file host jika ini didistribusikan dari repositori pusat). Itu akan menjelaskan entri yang hilang (atau ruang putih) dan konsisten dengan bacaan Soham tentang sumber.

"0.0.0.0" berarti itu adalah pengguna lokal (bukan login jarak jauh), mungkin dipanggil oleh aplikasi misalnya cronjob.

Itu terjadi karena Anda menggunakan sistem lokal dan 0.0.0.0 berarti alamat ip semua antarmuka. Jika Anda berpikir bahwa mungkin ada seseorang yang diretas, Anda mencoba mengatur log penuh shell termasuk perintah melalui ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Saya menyelesaikannya dengan menambahkan skrip ke ~ / .bashrc skrip menemukan alamat IP sumber koneksi telnet terakhir, Kemudian Anda dapat menambahkan IP ke file log atau melakukan apa pun yang Anda butuhkan ..

client_ip=$(echo $(netstat -nae | grep $(netstat -nae | grep 23 | awk  '{print $8}' | sort -n | tail -n1) | awk '{print $5}') | awk -F':' '{print $1}' )

echo "client_ip=$client_ip"

Sharon