Mam pięć CentOS 6 systemów Linux w pracy, i napotkał dość dziwny problem, który tylko wydaje się stało z moim identyfikatora we wszystkich systemach linux mam ... To jest przykład problemu z wpisami I wyłączonych z lastpolecenia .. .

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)

Możesz zobaczyć dwa moje wpisy logowania powyżej, które nie mają przypisanego źródłowego adresu IP. Moje maszyny CentOS mają aż sześciu innych użytkowników, którzy współużytkują systemy. Około 10% moich loginów widzi ten problem, ale żadne inne nazwy użytkowników nie wykazują tego zachowania . Brak wpisów /var/log/securedla wpisów bez źródłowego adresu IP.

pytania

Biorąc pod uwagę rodzaj skryptów, które trzymam w tych systemach (które kontrolują znaczną część naszej infrastruktury sieciowej), jestem trochę przestraszony i chciałbym zrozumieć, co powoduje, że moje loginy czasami tracą adresy źródłowe.

• Dlaczego last -iwyświetla się 0.0.0.0dla pozycji wiersza pts (zobacz także tę odpowiedź )
• Czy jest coś (oprócz złośliwego działania), które uzasadniałoby zachowanie?
• Czy poza śledzeniem czasu historii bashu są inne rzeczy, które mogę zrobić, aby wyśledzić problem?

Informacyjny

Od tego zaczęło się dziać, mam włączone bashhistorii znakowania czasem (czyli HISTTIMEFORMAT="%y-%m-%d %T "w .bash_profile), a także dodano kilka innych hacków historii bash ; nie daje to jednak wskazówek co do tego, co wydarzyło się podczas poprzednich wydarzeń.

Wszystkie systemy działają w 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 ~]$

EDYTOWAĆ

Jeśli używam last -i mpenning, widzę takie wpisy ...

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)

Uwaga dla tych, którzy próbują odpowiedzieć: Nie zalogowałem się za pomocą screenpolecenia ani graficznego interfejsu użytkownika . Wszystkie moje dane logowania pochodzą z SSH; aby otrzymać nagrodę główną, musisz przytoczyć wiarygodne referencje, aby wyjaśnić last -i 0.0.0.0wpisy pochodzące wyłącznie z SSH.

EDYCJA 2 (na pytania ewwhite)

/etc/resolv.conf(zwróć uwagę, że użyłem .localadresów w lastpowyższych wynikach, aby ukryć informacje o mojej firmie)

[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 informacje (zwróć uwagę, że ten dostosowany plik hosts istnieje tylko na jednym komputerze, na którym występują te problemy)

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

sftpWyjście z /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)

OSTATECZNA ROZDZIELCZOŚĆ

Zobacz moją odpowiedź poniżej

script różnice w zachowaniu między RedHat a Debianem

Połączone biblioteki

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

Bazując na źródłowym kodzie źródłowym , scriptz obu wersji otwierają nowe pty. Poniżej znajduje się test.

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 scriptotworzył nowe pts (2). Po prostu się nie zaktualizował /var/log/wtmp.

CentOS 6

Pomijam test, ponieważ już wiemy, że scriptotwierają pty i rejestrują się w wtmp.

libutemper

• Projekt: http://freecode.com/projects/libutempter
• Opis: libutempter zapewnia interfejs biblioteki dla emulatorów terminali, takich jak screen i xterm, do rejestrowania sesji użytkownika w plikach utmp i wtmp.

Główną różnicą wydaje się być dodatkowa biblioteka (libutempter.so.0 ) CentOS scriptpołączona z.

Przetestuj z Ubuntu 12.04

Kompilowanie scriptz 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)

Testowanie

Przed uruchomieniem 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

W ciągu 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

Po scriptzakończeniu

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

Główna przyczyna pustej nazwy hosta

I tak, script.cutwórz wtmpwpis z pustą nazwą hosta. Spójrz na następujący blok kodu w util-linux-2.20.1/term-utils/script.cwierszu: 245–247

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

Oprzeć na libutempter-1.1.5/utempter.h

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

Tak więc script.cprzekazuje pustą nazwę hosta doutempter_add_record .

RedHat Backport

Interesujące jest to, że upstream util-linux-ng-2.17.2faktycznie nie obsługuje libutempter. Wygląda na to, że Redhat postanowił dodać to wsparcie z powrotem.

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

Powyższe polecenie zwraca pusty wynik.

Wniosek

Różnica w zachowaniu między dwoma dystrybucjami nie jest błędem, ale wyborem. RedHat postanowił wesprzeć tę funkcję, a Debian ją pominął.

To wydaje mi się całkowicie zagadkowe. Albo powinien użyć nazwy DNS lub adresu IP. Sprawdziłem last.crównież plik, ale nadal nie mogę znaleźć powodu, dla którego nic nie pokazuje. Prawdopodobnie mając trochę czasu, mogę dowiedzieć się o części 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 }

Dwie globalne zmienne użyte w kontekście to:

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

Teoretycznie powinien używać dns lub IP.

Zobaczę, czy mogę coś jeszcze wykopać. Ale to, co ewwhite zadał, to ważne pytania.

Uruchomiłem więc ostatnio debugger, który, mam nadzieję, da ci przynajmniej trochę odpowiedzi na twoje pytanie. Moje przeczucie jest jednak głębsze.

Dlaczego ostatnia -i pokazuje 0.0.0.0 dla pozycji wiersza pts

Najlepszym sposobem na wyjaśnienie tego jest to, co dzieje się, gdy tego nie robisz zdasz -i.

Powodem tego jest sekcja kodu 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);
}

Zarówno usednsi useip(przy użyciu opcji domyślnych) nie są oflagowane. Powoduje to, że logika kopiuje się ze struktury, p->ut_hostktóra zgodnie z tym man utmpzawiera zdalną nazwę logowania zapisaną przez cokolwiek, co zapisano w utmp.

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

W twoim przypadku wartość tutaj to zero. Dlatego kiedy biegnieszlast nic się nie pojawia.

W takim przypadku last -iwywoływana jest funkcja dns_lookup. Spowoduje to przekazanie wpisu (p-> ut_addr_v6) do rozwiązania przez DNS. W twoim przypadku również ta wartość zawiera zera.

Większość z nich dns_lookupto szaty okienne i krzepkie. Zasadniczo liczy się funkcja getnameinfo. Jest to wywołanie biblioteki, które w tym przypadku postara się rozwiązać wartość binarną przechowywaną w pliku ut_addr_v6. Kiedy ten wpis zawiera zera (jak w twoim przypadku), tak naprawdę rozwiązujesz to 0.0.0.0tak, jak dzieje się z twoimlast -i wyjściowymi.

Czy jest coś (oprócz złośliwego działania), które uzasadniałoby zachowanie?

Cóż, to prawdopodobnie błąd lub niedopatrzenie. Jego mało prawdopodobne, aby być złośliwy, ponieważ wydaje się głupi opuścić jakikolwiek śladu jako atakującego, a nie pominięcie adresu źródłowego.

Odpowiedzi do tej pory koncentrowały się na niewłaściwym miejscu. lastpo prostu czyta utmplub wtmp. jednaklast robi wszystko, co w jego mocy, aby mieć dane.

Twoja podstawowa przyczyna leży gdzieś w sposobie, do którego utmpjest napisana !

Podczas gdy kilka aplikacji bezpośrednio pisze do utmp, myślę, że źródłem problemów sshdjest sposób zarządzania sesją.

Czy poza śledzeniem czasu historii bashu są inne rzeczy, które mogę zrobić, aby wyśledzić problem?

utmpzazwyczaj nie jest zapisywalny i nie jest przeznaczony do tego. utmpjest napisany przez aplikacje zaprojektowane do zalogowania się i skonfigurowania sesji. W twoim przypadku tak jest sshd.

Dlaczego sshd nie obsługuje użytkownika poprawnie, jest bardzo dziwne, ponieważ powinno poprawnie kopiować nazwę hosta, z której przyszedłeś. W tym miejscu należy prawdopodobnie skupić się na debugowaniu. Rozpocznij od dodania do dzienników danych wyjściowych debugowania sshd i sprawdź, czy pojawi się coś nietypowego.

Jeśli chcesz obejść problem (lub być może nawet dowiedzieć się więcej o nim), możesz użyć go pam_lastlogdo zarządzania utmp, dodając go do sesji wpisu na /etc/pam.d/sshd.

W rzeczywistości nie zaszkodzi sprawdzić, czy już tam jest - ponieważ pam_lastlogzawiera nohostopcję, która zdecydowanie wyjaśni twoje zachowanie, którego doświadczasz.

Wreszcie, nie można w ogóle użyć. aulastwykonuje to samo zadanie za pośrednictwem podsystemu kontroli.

Może warto spróbować sprawdzić, czy udało się przynajmniej zapisać poprawny adres. Jeśli tak nie jest, problem musi dotyczyć sshd, ponieważ sshd przekazuje nazwy DNS do różnych podsystemów, takich jak utmp lub audit.

(1) W oparciu o lastwyjście OP

Po zalogowaniu przez ssh można ssh do localhost i uzyskać 0.0.0.0 last -ina później.

Oprzyj na pierwszych czterech liniach dziennika PO

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/19logowanie było pts/17w okresie logowania.

pts/17logowanie było pts/1 w okresie logowania.

W przypadku tego konkretnego zdarzenia logiczne jest odgadnięcie, że OP ssh z 192.0.2.91 ( pty/1), a następnie w ramach tej sesji ssh ponownie zalogować się lokalnie ( ssh localhost) na serwer ( pts/17) i ponownie (pts/19 ).

Sprawdź, czy to nakładanie się dzieje się z innym wystąpieniem.

Następujące mogą pomóc w ustaleniu przyczyny

• Czy używasz klucza ssh? Jeśli tak, to czy na serwerze skonfigurowałeś klucz ssh do logowania lokalnego?
• Sprawdź lub opublikuj / var / log / secure w tym samym przedziale czasowym. Może to dostarczyć wskazówek.
• Sprawdź skrypty, których używasz
• Sprawdź używane aliasy powłoki
• Sprawdź swoją historię poleceń

(2) Dodatkowy Secnario

Scenariusz 1 - sudo i terminal

1. Użytkownik Login X Window
2. Otwórz okna terminala, zrób xhost + localhost
3. su - UserBlub sudo su - UserBnastępnie otwórz nowy terminal (xterm, terminal gnome itp.)
4. UserB pojawi się jako 0.0.0.0 w last -i

su - UserBnie zarejestruje się jako UserBostatni login, ale otworzy terminal.

Scenariusz 2 - logowanie

1. ssh na serwer
2. rodzaj sudo login
3. zaloguj się jako ty
4. sprawdź lastilast -i

lastnie pokazuje nazwy hosta ani adresu IP dla login session. last -ibędzie IP 0.0.0.0 dla 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

Odpowiedź Mife już pokazuje blok kodu last.c. Powodem lastwyświetlenia pustej nazwy hosta / adresu IP jest to, że ut_hostdla tych rekordów są faktycznie puste. Aby uzyskać pełną strukturę wtmp, wykonaj man wtmpna dowolnym systemie Linux.

Dwa scenariusze tutaj pokazują, że nawet standardowe pakiety, w pewnych sytuacjach, tworzą je jako takie.

(3) Hack History Bash

Będzie działać tylko wtedy, gdy sesja będzie używana bashjako interaktywna powłoka.

.bashrci .bash_profilesą używane tylko przez bash.

Nie będą one pozyskiwane automatycznie, jeśli sesja użyje innej powłoki (sh, csh itp.) Lub uruchomi program bezpośrednio i nie będzie też historii bash.

(4) Rachunkowość procesów

Ponieważ OP nie wspomina nic o securepliku, założę, że jest to ślepy zaułek i faktycznie zapewnia teraz wskazówkę.

Jeśli poniższe założenie jest prawidłowe

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

auth.log (debian) / secure (CentOS) nie pomoże. Ponieważ rejestrowane są w nim tylko działania związane z uwierzytelnianiem.

wtmp / utmp, z ograniczeniem w strukturze danych, jest również ślepym zaułkiem. Brak informacji o tym, co je utworzyło.

Pozostaje nam jedna opcja - rozliczanie procesów . To duża broń, z której należy korzystać ostrożnie.

1. Może wbrew polityce firmy
2. Inni użytkownicy w systemie współdzielonym mogą być niezadowoleni / niewygodni z włączonym systemem
3. Plik dziennika może zajmować dużo miejsca na dysku. Miej oko na tempo wzrostu wielkości pliku.

Psacct wersja pakietu powinna być 6.3.2-56 lub powyżej, zgodnie z tym poście .

Jeśli ma być użyty i /var/logma ograniczoną przestrzeń, zmień plik dziennika acct na katalog (dostęp tylko dla roota) pod /home, który zwykle ma znacznie więcej miejsca.

To naprawdę wielka broń. Przy 10% częstości występowania PO, wynik powinien pojawić się w ciągu tygodnia. Jeśli w tym okresie pojawi się pusty wpis, lastale nic z dziennika acct, stanie się tajemniczą sytuacją i będzie wymagał drastycznych działań .

Poniżej przedstawiono przykładowe dane wyjściowe 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

Możesz także użyć polecenia „zrzut-acct”, aby wyświetlić więcej informacji.

PS1: Próbowałem otworzyć kilka sesji terminalu i ssh. Nie jest jasne (ani trudne do ustalenia), co otwiera nowe punkty. Pokazuje jednak wszystko, co działało w ramach tej sesji / sesji.

PS2: post na blogu o używaniu acct przez Mike'a.

Po zalogowaniu się do komputera może to być kilka wpisów w ostatnim poleceniu.

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)    

Pierwszy wpis z tty * pojawia się, gdy logujesz się przez terminal lub konsolę, naciskając CTRL + ALT + F1-6. Z terminalu, z którego korzysta, jest prawie wszystko jasne.

Drugi wpis zwykle pojawia się w obrazie, gdy zalogujesz się na maszynie i otworzysz okno terminala w GUI. Pojawi się również wpis, nawet jeśli otworzysz nową kartę w tym samym oknie terminala.

Trzeci typ wpisu pojawia się po otwarciu sesji ekranowej po zalogowaniu do SSH. Spowoduje to również utworzenie wpisu bez adresu IP.

Czwarty wpis jest całkiem normalny, co wszyscy rozumieją.

Jeśli zrobisz last -inastępujące wpisy, zobaczysz coś takiego:

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)    

Jestem prawie pewien, że twoja sprawa jest rozpatrywana w jednym z dwóch przypadków, jeden z oknem terminalu w GUI, a drugi z sesją screen.

Mam nadzieję, że to pomogło.

Nie sądzę, żebyśmy zaszli za daleko bez debugowania last.c, ale nie powinno to być zbyt trudne, ponieważ łatwo się kompiluje ...

Jedną z możliwości jest jednak zrzucenie pliku / var / log / wtmp za pomocą komendy utmpdump i przejrzenie nieprzetworzonych rekordów, które mogą rzucić nieco światła na Ciebie. Jeśli nie, proszę zamieścić odpowiednie dane wyjściowe z

utmpdump /var/log/wtmp 

abyśmy mogli odtworzyć lokalne kopie twojego wtmp do debugowania

utmpdump -r <dumpfile >wtmp

Sprawdziłem na 12 serwerach aplikacji CentOS i RHEL 6.3 dla wielu użytkowników. Żaden nie wykazywał tego zachowania. Nie było brakujących wpisów wlast danych wyjściowych z 4-5 tygodni.

Myślę, że ważne jest, aby zobaczyć /etc/hostswpis pliku, aby upewnić się, że jest zgodny z tym formatem .

Co robisz dla rozwiązania DNS? Czy możesz opublikować swój/etc/resolv.conf ?

Pozostałe odpowiedzi wskazujące, że 0.0.0.0reprezentują połączenia lokalne są poprawne. Typowymi przykładami są zdarzenia restartu i logowania do konsoli:

 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)    

Ponieważ wydaje się, że zdarza się to tylko w przypadku nazwanych użytkowników, czy jest jakaś zmiana, że ​​coś funky jest pozyskiwane lub uruchamiane w skryptach logowania? Czy zmieniłeś ~/.bashrclub~/.bash_profile domyślnie? Czy w środowisku są jakieś specjalne skrypty logowania?

--Edytować--

Nadal nie jestem w stanie odtworzyć tego w żaden sposób. Patrzę jednak na dwa krytyczne elementy. lastKomenda jest stabilny i nie został zmieniony w długim czasie. Patrząc na dziennik zmian sysvinit-tools , nie ma żadnych istotnych błędów. To samo dotyczy skryptów startowych (wtmp).

Jeśli możesz to wymusić, wypróbuj je z innym kontem użytkownika z tych samych komputerów źródłowych. Ale nie widzę żadnych oznak, że jest to problem z systemem operacyjnym.

OSTATECZNA ROZDZIELCZOŚĆ

Już przyznałem bonus, więc jest on przeznaczony wyłącznie dla przyszłych pracowników Google z tym samym pytaniem.

Powodem jest to, że pojawia się to tylko w ~ 10% moich danych logowania, ponieważ kiedy wprowadzam poważne zmiany w naszych routerach lub przełącznikach, używam ich, script foo.logwięc mam pełny dziennik zmian tej zmiany. Z powodów, których wciąż nie rozumiem, CentOS tworzy ptswpis, gdy użyjesz scriptpolecenia ... Pokażę dane wyjściowe last -iprzed i po uruchomieniu 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]$

To zachowanie wydaje się być unikalne dla CentOS 6 ... w laboratorium mamy kilka maszyn CentOS 4.7, które nie wpisują pustego wpisu w wtmp... Maszyny Debian / Gentoo też nie wykazują takiego zachowania. Nasi administratorzy linuxa drapią się po głowie, dlaczego CentOS celowo dodałby kolejny ptswpis podczas wykonywania script... Podejrzewam, że to błąd RHEL.

EDYCJA : Złożyłem ten problem jako RHEL Bug id 892134

UWAGA

Niektórzy ludzie błędnie założyli, że wstawiłem scriptmoje ~/.bashrclub ~/.bash_profile. To jest błędny argument ... jeśli to prawda, wtmppowinienem mieć 0.0.0.0wpis po każdym logowaniu ssh ...

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

Oczywiście tak nie było ...

Połączenia Pseudo Terminal Slave (pts) to połączenia SSH lub telnet, co oznacza pośrednie połączenia z systemem. Wszystkie te połączenia mogą łączyć się z powłoką, która pozwala wydawać polecenia na komputer. Więc kiedy otworzysz terminal w twoim systemie z GUI, otworzy to pts ze źródłem ip 0.0.0.0. Z dostarczonych przez ciebie informacji wynika, że ​​dzieje się tak z powodu skryptu uruchomionego na tym serwerze lub zaplanowanego, który używa usługi ssh lub telnet lub lokalnych punktów do wysyłania danych wyjściowych do terminala.

Z którego klienta ssh korzystasz? Niektórzy klienci ssh mogą multipleksować wiele terminali przez jedno połączenie i zauważam, że wszystkie twoje sesje bez adresu IP mieszczą się w dłuższych sesjach, które mają zarejestrowany adres IP.

Nie mogę powielić tego zachowania za pomocą ssh tutaj.

Być może twój adres IP przekształca się w pusty ciąg na jednym z twoich serwerów DNS, prawdopodobnie wtórny, jeśli zdarza się to tylko 10 procent czasu (lub po prostu plik hosta, jeśli są one dystrybuowane z centralnego repozytorium). To tłumaczy brakujący (lub biały znak) wpis i jest spójny z odczytaniem źródła przez Soham.

„0.0.0.0” oznacza, że ​​jest to użytkownik lokalny (nie zdalny login), prawdopodobnie wywołany przez aplikację np. Cronjob.

Dzieje się tak, ponieważ korzystasz z systemu lokalnego, a 0.0.0.0 oznacza adres IP wszystkich interfejsów. Jeśli uważasz, że może ktoś się włamał, spróbuj ustawić pełne rejestrowanie powłoki, w tym polecenia za pośrednictwem ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Rozwiązałem go, dodając skrypt do ~ / .bashrc. Skrypt znajduje ostatni adres IP źródłowego połączenia telnet, następnie możesz dodać adres IP do pliku dziennika lub zrobić wszystko, czego potrzebujesz.

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