Tôi có năm hệ thống linux CentOS 6 đang hoạt động và gặp phải một vấn đề khá kỳ lạ chỉ xảy ra với userid của tôi trên tất cả các hệ thống linux mà tôi có ... Đây là một ví dụ về sự cố từ các mục tôi ngoại trừ từ lastlệnh .. .

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)

Bạn có thể thấy hai trong số các mục đăng nhập pts của tôi ở trên không có địa chỉ IP nguồn được liên kết với chúng. Các máy CentOS của tôi có tới sáu người dùng khác chia sẻ hệ thống. Khoảng 10% thông tin đăng nhập của tôi thấy vấn đề này, nhưng không có tên người dùng nào khác thể hiện hành vi này . Không có mục nhập /var/log/securecho các mục mà không có địa chỉ IP nguồn.

Câu hỏi

Với loại tập lệnh mà tôi giữ trên các hệ thống này (điều khiển phần lớn cơ sở hạ tầng mạng của chúng tôi), tôi hơi bị bối rối bởi điều này và muốn hiểu điều gì sẽ khiến thông tin đăng nhập của tôi thỉnh thoảng bỏ lỡ địa chỉ nguồn.

• Tại sao không last -ihiển thị 0.0.0.0cho các mục dòng pts (cũng xem câu trả lời này )
• Có bất cứ điều gì (ngoài hoạt động độc hại) sẽ giải thích hợp lý hành vi đó không?
• Khác với dấu thời gian lịch sử bash, có những điều khác tôi có thể làm để theo dõi vấn đề không?

Thông tin

Vì điều này bắt đầu xảy ra, tôi đã kích hoạt tính bashnăng dập thời gian lịch sử (tức là HISTTIMEFORMAT="%y-%m-%d %T "trong .bash_profile) và cũng thêm một vài hack lịch sử bash khác ; tuy nhiên, điều đó không đưa ra manh mối cho những gì đã xảy ra trong những lần xuất hiện trước đó.

Tất cả các hệ thống chạy 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 ~]$

CHỈNH SỬA

Nếu tôi sử dụng last -i mpenning, tôi thấy các mục như thế này ...

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)

Lưu ý cho những người đang cố gắng trả lời: Tôi chưa đăng nhập bằng screenlệnh hoặc GUI . Tất cả thông tin đăng nhập của tôi là từ SSH; để nhận giải thưởng tiền thưởng, bạn phải trích dẫn các tài liệu tham khảo có thẩm quyền để giải thích các last -i 0.0.0.0mục có nguồn gốc chỉ thông qua SSH.

EDIT 2 (cho câu hỏi của ewwhite)

/etc/resolv.conf(lưu ý rằng tôi đã sử dụng .localaddrs ở lastđầu ra ở trên để ẩn thông tin của công ty tôi)

[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 thông tin (lưu ý rằng tệp máy chủ tùy chỉnh này chỉ tồn tại trên một trong các máy có những vấn đề này)

[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Đầu ra từ /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)

GIẢI QUYẾT CUỐI CÙNG

Xem câu trả lời của tôi dưới đây

script khác biệt về hành vi giữa RedHat và Debian

Thư viện liên kết

CentOS 6.3 - tập lệnh (produc-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 - tập lệnh (produc-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

Dựa trên mã nguồn ngược dòng , scripttừ cả hai phiên bản đều mở pty mới. Sau đây là thử nghiệm.

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đã mở một pts mới (2). Nó chỉ không cập nhật/var/log/wtmp .

CentOS 6

Tôi đang bỏ qua bài kiểm tra vì chúng tôi đã biết rằng scriptmở pty và đăng ký với wtmp.

libutemper

• Dự án: http://freecode.com/projects/libutempter
• Mô tả: libutempter cung cấp giao diện thư viện cho các trình giả lập đầu cuối như màn hình và xterm để ghi lại các phiên của người dùng vào các tệp utmp và wtmp.

Vì vậy, sự khác biệt chính dường như là thư viện phụ ( libutempter.so.0) CentOS scriptđược liên kết với.

Kiểm tra với Ubuntu 12.04

Biên dịch scriptvới 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)

Kiểm tra

Trước khi chạy 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

Trong 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

Sau khi scriptkết thúc

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

Nguyên nhân gốc của tên máy chủ emtpy

Và có, script.chãy tạo wtmpmục với tên máy chủ trống. Nhìn vào khối mã sau đây trong util-linux-2.20.1/term-utils/script.cDòng: 245-247

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

Dựa vào libutempter-1.1.5/utempter.h

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

Vì vậy, script.cthực sự là chuyển tên máy chủ trống vào utempter_add_record.

Redport Backport

Điều thú vị là, thượng nguồn util-linux-ng-2.17.2thực sự không hỗ trợ libutempter. Có vẻ Redhat quyết định thêm hỗ trợ đó trở lại.

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

Lệnh trên trả về kết quả trống.

Phần kết luận

Vì vậy, sự khác biệt trong hành vi giữa hai bản phát hành không phải là một lỗi, mà là một sự lựa chọn. RedHat quyết định hỗ trợ tính năng đó, trong khi Debian bỏ qua nó.

Điều này có vẻ hoàn toàn khó hiểu với tôi. Nó nên sử dụng một số tên DNS hoặc địa chỉ IP. Tôi cũng đã kiểm tra last.ctệp nhưng tôi vẫn không thể tìm thấy lý do tại sao nó không hiển thị gì. Có lẽ được đưa ra một thời gian, tôi có thể tìm ra phần về 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 }

Hai biến toàn cầu được sử dụng trong bối cảnh là những.

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

Vì vậy, về lý thuyết, nó nên sử dụng dns hoặc IP.

Tôi sẽ xem nếu tôi có thể đào thêm bất cứ điều gì. Nhưng những gì ewwhite hỏi là những câu hỏi hợp lệ.

Vì vậy, tôi đã chạy lần cuối trong trình gỡ lỗi, hy vọng sẽ cung cấp cho bạn ít nhất một số câu trả lời cho câu hỏi của bạn. Cảm giác của tôi là nguyên nhân gốc rễ sâu hơn mặc dù.

Tại sao cuối cùng -i hiển thị 0.0.0.0 cho các mục nhập pts

Cách tốt nhất để giải thích điều này là những gì xảy ra khi bạn không vượt qua -i.

Lý do cho điều này là trong phần mã này của 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);
}

Cả hai usednsvà useip(sử dụng các tùy chọn mặc định) không được gắn cờ. Điều này làm cho logic sao chép ra khỏi cấu trúc p->ut_hostmà theo đó man utmpcó chứa tên đăng nhập từ xa như được ghi lại bởi bất cứ điều gì được ghi vào utmp.

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

Trong trường hợp của bạn, giá trị ở đây là số không. Đây là lý do tại sao khi bạn chạy lastkhông có gì xuất hiện cho bạn.

Trong trường hợp last -isau đó dns_lookup được gọi. Điều này sẽ vượt qua mục (p-> ut_addr_v6) để được giải quyết thông qua DNS. Trong trường hợp của bạn, giá trị này cũng chứa số không.

Hầu hết dns_lookuplà mặc quần áo cửa sổ và bá đạo. Về cơ bản những gì quan trọng là chức năng getnameinfo. Đây là một cuộc gọi thư viện mà trong trường hợp này sẽ cố gắng hết sức để giải quyết giá trị nhị phân được lưu trữ trong ut_addr_v6. Khi mục này chứa số không (chẳng hạn như trong trường hợp của bạn), bạn thực sự đang giải quyết vấn đề này 0.0.0.0như những gì xảy ra với last -iđầu ra của bạn .

Có bất cứ điều gì (ngoài hoạt động độc hại) sẽ giải thích hợp lý hành vi đó không?

Vâng, nó có thể là một lỗi hoặc giám sát. Nó không có khả năng độc hại vì có vẻ ngu ngốc khi để lại bất kỳ dấu vết nào với tư cách là kẻ tấn công thay vì bỏ qua địa chỉ nguồn.

Trọng tâm của câu trả lời cho đến nay đã được nhìn vào chỗ sai. lastchỉ cần đọc utmphoặc wtmp. Tuy nhiên lastđang làm tốt nhất với dữ liệu nó có.

Nguyên nhân sâu xa của bạn nằm ở đâu đó theo cách utmpviết !

Trong khi một vài ứng dụng viết trực tiếp vào utmptôi đoán nguồn gốc của các vấn đề của bạn nằm ở cách sshdxử lý việc quản lý phiên.

Khác với dấu thời gian lịch sử bash, có những điều khác tôi có thể làm để theo dõi vấn đề không?

utmpthường không thể ghi và không có nghĩa là. utmpđược viết bởi các ứng dụng được thiết kế để đăng nhập bạn và thiết lập phiên của bạn. Trong trường hợp của bạn đó là sshd.

Tại sao sshd không xử lý người dùng của bạn đúng cách là rất lạ vì nó phải được sao chép chính xác trong tên máy chủ mà bạn đến. Đây là nơi mà các nỗ lực gỡ lỗi có lẽ nên được tập trung. Bắt đầu với việc thêm đầu ra gỡ lỗi của sshd vào nhật ký của bạn và xem liệu có bất cứ điều gì bất thường xuất hiện không.

Nếu bạn muốn giải quyết vấn đề (hoặc thậm chí có thể khám phá thêm về vấn đề này), bạn có thể sử dụng pam_lastlogđể quản lý utmpbằng cách thêm nó vào mục nhập phiên vào /etc/pam.d/sshd.

Như một vấn đề thực tế, sẽ không đau để kiểm tra nếu nó đã ở đó - bởi vì pam_lastlogcó một nohosttùy chọn chắc chắn sẽ giải thích hành vi của bạn mà bạn đang gặp phải.

Cuối cùng, bạn không thể sử dụng cuối cùng. aulastthực hiện cùng một công việc thông qua hệ thống con kiểm toán.

Có thể đáng để thử xem nếu điều đó đã quản lý ít nhất là viết đúng địa chỉ. Nếu không có thì vấn đề của bạn phải là với sshd vì sshd đang chuyển các tên DNS xung quanh các hệ thống con khác nhau như utmp hoặc kiểm toán.

(1) Dựa trên lastđầu ra OP

Sau khi đăng nhập qua ssh, người ta có thể ssh vào localhost và nhận 0,0.0.0 last -isau.

Dựa trên bốn dòng nhật ký đầu tiên của 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/19đăng nhập là trong pts/17thời gian đăng nhập.

pts/17đăng nhập là trong pts/1 thời gian đăng nhập.

Đối với sự xuất hiện cụ thể này, thật hợp lý khi đoán rằng OP ssh từ 192.0.2.91 ( pty/1), sau đó trong phiên ssh đó, đăng nhập cục bộ ( ssh localhost) vào máy chủ một lần nữa ( pts/17) và một lần nữa ( pts/19).

Vui lòng kiểm tra nếu sự chồng chéo này xảy ra với sự xuất hiện khác.

Sau đây có thể giúp xác định nguyên nhân

• Bạn có sử dụng ssh-key không? Nếu vậy, trên máy chủ, bạn đã thiết lập ssh-key để đăng nhập cục bộ chưa?
• Kiểm tra hoặc đăng / var / log / an toàn của cùng khung thời gian. Nó có thể cung cấp một số gợi ý.
• Kiểm tra tập lệnh bạn sử dụng
• Kiểm tra bí danh shell bạn sử dụng
• Kiểm tra lịch sử lệnh của bạn

(2) Secnario bổ sung

Kịch bản 1 - sudo và thiết bị đầu cuối

1. Cửa sổ đăng nhập người dùng X
2. Mở một cửa sổ đầu cuối, làm xhost + localhost
3. su - UserBhoặc sudo su - UserBsau đó mở một thiết bị đầu cuối mới (xterm, gnome-terminal, v.v.)
4. UserB sẽ hiển thị là 0.0.0.0 trong last -i

su - UserBsẽ không đăng ký như là một UserBđăng nhập cuối cùng, nhưng mở một thiết bị đầu cuối sẽ.

Kịch bản 2 - đăng nhập

1. ssh vào máy chủ
2. kiểu sudo login
3. đăng nhập như chính mình
4. kiểm tra lastvàlast -i

lasthiển thị không có tên máy chủ hoặc IP cho login session. last -isẽ IP 0.0.0.0 cho 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

Câu trả lời của Mife đã hiển thị khối mã của last.c. Lý do lasthiển thị tên máy chủ / IP trống là vì ut_hostcác bản ghi đó thực sự trống. Để cấu trúc wtmp hoàn chỉnh, hãy thực hiện man wtmptrên bất kỳ hệ thống linux nào.

Hai kịch bản ở đây cho thấy rằng ngay cả các gói tiêu chuẩn, trong tình huống nhất định, cũng tạo ra chúng như vậy.

(3) Hack lịch sử Bash

Nó sẽ chỉ hoạt động nếu phiên sử dụng bashnhư vỏ tương tác.

.bashrcvà .bash_profilechỉ được sử dụng bởi bash.

Chúng sẽ không có nguồn gốc tự động nếu phiên sử dụng bất kỳ shell nào khác (sh, csh, v.v.) hoặc thực hiện chương trình trực tiếp và cũng sẽ không có lịch sử bash.

(4) Kế toán quy trình

Vì OP không đề cập gì đến securetập tin, tôi sẽ cho rằng đó là một ngõ cụt và nó thực sự cung cấp gợi ý ngay bây giờ.

Nếu giả định sau đây là đúng

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

auth.log (debian) / safe (CentOS) sẽ không giúp ích. Như chỉ hành động xác thực liên quan được ghi lại trong đó.

wtmp / utmp, với giới hạn trong cấu trúc dữ liệu của họ, cũng là một ngõ cụt. Không có thông tin về những gì đã tạo ra chúng.

Điều đó để lại cho chúng tôi một lựa chọn, xử lý kế toán . Đây là một khẩu súng lớn và phải được sử dụng một cách thận trọng.

1. Có thể chống lại chính sách của công ty
2. Những người dùng khác trên một hệ thống được chia sẻ có thể không hài lòng / không thoải mái với nó được kích hoạt
3. Tệp nhật ký có thể sử dụng nhiều dung lượng đĩa. Theo dõi tốc độ tăng trưởng kích thước tập tin.

Phiên bản gói psacct phải là 6.3.2-56 trở lên, theo bài đăng này .

Nếu điều này được sử dụng và /var/logcó không gian hạn chế, hãy thay đổi tệp nhật ký acct thành một thư mục (quyền truy cập chỉ root) bên dưới /home, thường có nhiều không gian hơn.

Đây thực sự là khẩu súng lớn. Với tỷ lệ xuất hiện OP 10%, sẽ có kết quả trong vòng một tuần. Nếu trong khoảng thời gian đó, mục nhập trống xuất hiện lastnhưng không có gì từ nhật ký acct, nó trở thành một tình huống bí ẩn và sẽ yêu cầu một số hành động quyết liệt .

Sau đây là một đầu ra mẫu của 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

Bạn cũng có thể sử dụng 'dump-acct' để hiển thị thêm thông tin.

PS1: Tôi đã cố mở một vài thiết bị đầu cuối và ssh. Nó không rõ ràng (hoặc không dễ dàng để xác định điểm) những gì mở một pts mới. Tuy nhiên, nó hiển thị mọi thứ chạy trong pts / session đó.

PS2: Một bài đăng trên blog về việc sử dụng acct của Mike.

Khi bạn đăng nhập vào Máy, đây có thể là một vài mục trong lệnh cuối cùng.

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)    

Mục đầu tiên với tty * xuất hiện khi bạn đăng nhập qua thiết bị đầu cuối hoặc bảng điều khiển bằng cách nhấn CTRL + ALT + F1-6. Nó khá rõ ràng từ thiết bị đầu cuối đang sử dụng.

Mục nhập thứ hai thường xuất hiện khi bạn đăng nhập vào Máy và mở cửa sổ đầu cuối trong GUI. Cũng sẽ có một mục ngay cả khi bạn mở một Tab mới trong cùng cửa sổ terminal.

Loại mục nhập thứ ba xuất hiện khi bạn mở một phiên màn hình sau khi đăng nhập thông qua SSH. Điều đó cũng sẽ tạo ra một mục ở đó và không có bất kỳ địa chỉ IP.

Mục thứ tư là khá bình thường mà mọi người đều hiểu.

Nếu bạn làm last -ivới các mục sau, bạn sẽ thấy một cái gì đó như thế này:

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)    

Tôi khá chắc chắn rằng trường hợp của bạn thuộc bất kỳ trường hợp nào trong số 2 trường hợp, một trường hợp có Cửa sổ đầu cuối trong GUI và trường hợp khác có phiên màn hình.

Hy vọng điều này đã giúp.

Tôi không nghĩ rằng chúng ta sẽ tiến xa với điều này mà không cần gỡ lỗi Last.c, nhưng điều đó không quá khó vì nó dễ dàng biên dịch ...

Mặc dù vậy, một khả năng là kết xuất tệp / var / log / wtmp bằng cách sử dụng lệnh utmpdump và xem xét các bản ghi thô, điều này có thể làm sáng tỏ bạn. Nếu không xin vui lòng gửi một số đầu ra có liên quan từ

utmpdump /var/log/wtmp 

để chúng tôi có thể tạo lại các bản sao cục bộ của wtmp để gỡ lỗi với

utmpdump -r <dumpfile >wtmp

Tôi đã kiểm tra trên 12 máy chủ ứng dụng dựa trên nhiều người dùng CentOS và RHEL 6.3. Không ai thể hiện hành vi này. Không có mục nào bị thiếu trong lastđầu ra trở lại 4-5 tuần.

Tôi nghĩ rằng điều quan trọng là phải xem /etc/hostsmục nhập tệp của bạn để đảm bảo rằng nó phù hợp với định dạng này .

Ngoài ra, bạn đang làm gì để phân giải DNS? Bạn có thể gửi bài của bạn /etc/resolv.conf?

Các phản hồi khác chỉ ra rằng 0.0.0.0kết nối địa phương là chính xác. Các ví dụ điển hình là khởi động lại và các sự kiện đăng nhập bảng điều khiển:

 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)    

Vì điều này dường như chỉ xảy ra với người dùng được đặt tên, nên có bất kỳ thay đổi nào có nguồn gốc thú vị được lấy hoặc chạy trong tập lệnh đăng nhập của họ không? Bạn đã thay đổi ~/.bashrchoặc ~/.bash_profiletừ mặc định? Có bất kỳ kịch bản đăng nhập đặc biệt khác trong môi trường?

--Chỉnh sửa--

Tôi vẫn không thể tái tạo điều này bằng bất kỳ cách nào. Tôi nhìn vào hai thành phần quan trọng, mặc dù. Các lastlệnh là ổn định và chưa được thay đổi trong một thời gian dài. Nhìn vào thay đổi cho các công cụ sysvinit , không có lỗi liên quan. Tương tự cho initscripts (wtmp).

Nếu bạn có thể buộc điều này xảy ra, hãy thử nó với một tài khoản người dùng khác từ cùng một máy nguồn. Nhưng tôi không thấy bất kỳ dấu hiệu nào cho thấy đây là sự cố hệ điều hành.

GIẢI QUYẾT CUỐI CÙNG

Tôi đã trao phần thưởng, vì vậy đây hoàn toàn dành cho những người làm việc trong tương lai với cùng một câu hỏi.

Lý do điều này chỉ xuất hiện trong ~ 10% số lần đăng nhập của tôi là vì khi tôi thực hiện các thay đổi lớn đối với bộ định tuyến hoặc bộ chuyển mạch của chúng tôi, tôi sử dụng script foo.logđể tôi có một bản ghi thiết bị đầu cuối hoàn chỉnh của thay đổi. Vì những lý do tôi vẫn không hiểu, CentOS tạo một ptsmục khi bạn sử dụng scriptlệnh ... Tôi sẽ chứng minh đầu ra của last -itrước và sau khi chạy 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]$

Hành vi này dường như là duy nhất đối với CentOS 6 ... chúng tôi có một số máy CentOS 4.7 trong phòng thí nghiệm không đặt một mục trống trong wtmp... Máy Debian / Gentoo cũng không thể hiện hành vi này. Quản trị viên linux của chúng tôi đang gãi đầu tại sao CentOS lại cố tình thêm một ptsmục khác khi bạn thực thi script... Tôi nghi ngờ đây là lỗi của RHEL.

EDIT : Tôi đã gửi vấn đề này dưới dạng RHEL Bug id 892134

CHÚ THÍCH

Một số người đã giả định sai tôi đưa scriptvào ~/.bashrchoặc ~/.bash_profile. Đây là một lập luận thiếu sót ... nếu đó là sự thật, tôi wtmpnên có một 0.0.0.0mục sau mỗi lần đăng nhập ssh của tô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/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)  # <-----

Tất nhiên, đó không phải là trường hợp ...

Các kết nối Pseudo Terminal Slave (pts) là các kết nối SSH hoặc telnet có nghĩa là các kết nối gián tiếp đến hệ thống. Tất cả các kết nối này có thể kết nối với hệ vỏ cho phép bạn đưa ra lệnh cho máy tính. Vì vậy, khi bạn mở một thiết bị đầu cuối trên hệ thống của bạn từ gui, nó sẽ mở ra một pts với nguồn ip 0.0.0.0. Từ thông tin do bạn cung cấp, có vẻ như điều đó xảy ra do tập lệnh chạy trên máy chủ này hoặc theo lịch trình, đang sử dụng dịch vụ ssh hoặc telnet hoặc pts cục bộ để ném đầu ra trong thiết bị đầu cuối.

Bạn sử dụng máy khách ssh nào? Một số khách hàng ssh có thể ghép nhiều thiết bị đầu cuối qua một kết nối và tôi nhận thấy tất cả các phiên của bạn không có IP nằm trong các phiên dài hơn có IP được ghi lại.

Tôi không thể sao chép hành vi này với ssh ở đây.

Có lẽ địa chỉ IP của bạn phân giải thành một chuỗi trống trên một trong các máy chủ DNS của bạn, có thể là thứ cấp nếu nó chỉ xảy ra 10% thời gian (hoặc chỉ có thể là tệp lưu trữ nếu chúng được phân phối từ kho lưu trữ trung tâm). Điều đó sẽ giải thích cho mục nhập bị thiếu (hoặc khoảng trắng) và phù hợp với cách đọc nguồn của Soham.

"0.0.0.0" có nghĩa là người dùng cục bộ (không phải đăng nhập từ xa), có thể được gọi bởi ứng dụng, ví dụ như cronjob.

Nó xảy ra bởi vì bạn sử dụng hệ thống cục bộ và 0.0.0.0 có nghĩa là địa chỉ IP của tất cả các giao diện. Nếu bạn nghĩ rằng có thể ai đó đã hack, bạn hãy thử thiết lập ghi nhật ký shell đầy đủ bao gồm các lệnh thông qua ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Tôi đã giải quyết nó bằng cách thêm tập lệnh vào ~ / .bashrc tập lệnh tìm địa chỉ IP nguồn kết nối telnet cuối cùng, sau đó bạn có thể thêm IP vào tệp nhật ký hoặc làm bất cứ điều gì bạn cần ..

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