Ho cinque sistemi Linux CentOS 6 al lavoro e ho riscontrato un problema piuttosto strano che sembra accadere solo con il mio userid su tutti i sistemi Linux che ho ... Questo è un esempio del problema dalle voci che ho escluso dal lastcomando .. .

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)

Puoi vedere due delle mie voci di accesso pts sopra a cui non è associato un indirizzo IP di origine. Le mie macchine CentOS hanno ben altri sei utenti che condividono i sistemi. Circa il 10% dei miei accessi rileva questo problema, ma nessun altro nome utente presenta questo comportamento . Non è presente alcuna voce /var/log/secureper le voci senza un indirizzo IP di origine.

Domande

Dato il tipo di script che mantengo su questi sistemi (che controllano gran parte della nostra infrastruttura di rete), ne sono un po 'spaventato e vorrei capire cosa causerebbe occasionalmente ai miei accessi la mancanza di indirizzi di origine.

• Perché last -imostra 0.0.0.0per le voci di riga pts (vedi anche questa risposta )
• C'è qualcosa (diverso dall'attività dannosa) che spiegherebbe ragionevolmente il comportamento?
• Oltre al timestamp della cronologia bash, ci sono altre cose che posso fare per rintracciare il problema?

Informativo

Da quando è iniziato questo, ho abilitato il timestamp della bashcronologia (cioè HISTTIMEFORMAT="%y-%m-%d %T "in .bash_profile) e ho anche aggiunto alcuni altri hack di cronologia bash ; tuttavia, ciò non fornisce indizi su ciò che è accaduto durante le occorrenze precedenti.

Tutti i sistemi funzionano con 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 ~]$

MODIFICARE

Se uso last -i mpenning, vedo voci come questa ...

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)

Nota per coloro che cercano di rispondere: non ho effettuato l'accesso con il screencomando o la GUI . Tutti i miei accessi provengono da SSH; per ricevere il premio Bounty, è necessario citare riferimenti autorevoli per spiegare le last -i 0.0.0.0voci provenienti solo tramite SSH.

EDIT 2 (per domande di ewwhite)

/etc/resolv.conf(nota che ho usato .localaddrs lastnell'output sopra per nascondere le informazioni della mia azienda)

[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 (nota che questo file hosts personalizzato esiste solo su una delle macchine che presenta questi problemi)

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

sftpUscita da /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)

RISOLUZIONE FINALE

Vedi la mia risposta qui sotto

script differenze di comportamento tra RedHat e Debian

Librerie collegate

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

Basata sul codice sorgente upstream , scriptda entrambe le versioni si aprono nuovi pty. Di seguito è riportato il 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 scriptha aperto un nuovo punto (2). Non si è aggiornato /var/log/wtmp.

CentOS 6

Sto saltando il test perché sappiamo già che scriptapro pty e mi registro con wtmp.

libutemper

• Progetto: http://freecode.com/projects/libutempter
• Descrizione: libutempter fornisce un'interfaccia di libreria per emulatori di terminale come screen e xterm per registrare sessioni utente in file utmp e wtmp.

Quindi la differenza principale sembra essere la libreria extra ( libutempter.so.0) a cui CentOS è scriptcollegato.

Prova con Ubuntu 12.04

Compilando scriptcon 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)

analisi

Prima di correre 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

Entro 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

Dopo la scriptfine

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

La causa principale del nome host emtpy

E sì, script.ccrea la wtmpvoce con un nome host vuoto. Guarda il seguente blocco di codice nella util-linux-2.20.1/term-utils/script.criga: 245-247

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

Base su libutempter-1.1.5/utempter.h

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

Quindi in script.crealtà sta passando un nome host vuoto in utempter_add_record.

RedHat Backport

La cosa interessante è che l'upstream in util-linux-ng-2.17.2realtà non supporta libutempter. Sembra che Redhat abbia deciso di aggiungere nuovamente quel supporto.

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

Il comando sopra restituisce un risultato vuoto.

Conclusione

Quindi la differenza di comportamento tra le due distro non è un bug, ma una scelta. RedHat ha deciso di supportare quella funzionalità, mentre Debian l'ha saltata.

Questo mi sembra assolutamente sconcertante. O dovrebbe usare un nome DNS o un indirizzo IP. Ho controllato anche il last.cfile ma non riesco ancora a trovare il motivo per cui non mostra nulla. Probabilmente dato un po 'di tempo, posso capire la parte su 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 }

Le due variabili globali utilizzate nel contesto sono queste.

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

Quindi, in teoria, dovrebbe usare dns o IP.

Vedrò se riesco a scavare qualcosa di più. Ma ciò che l'ewwhite ha fatto sono domande valide.

Quindi ho funzionato per ultimo in un debugger che si spera possa darti almeno alcune risposte alla tua domanda. Il mio sentimento è che la causa principale è più profonda però.

Perché last -i mostra 0.0.0.0 per le voci di riga pts

Il modo migliore per spiegarlo è cosa succede quando non si passa -i.

Il motivo è in questa sezione di codice di 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);
}

Entrambi usednse useip(utilizzando le opzioni predefinite) non sono contrassegnati. Questo fa sì che la logica si copi fuori dalla struttura p->ut_hostche secondo il man utmpcontiene il nome di accesso remoto come registrato da qualsiasi cosa scritta nel file utmp.

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

Nel tuo caso, il valore qui è zero. Questo è il motivo per cui quando corri lastnon appare nulla per te.

Nel caso di last -iallora viene invocato dns_lookup. Questo passerà la voce (p-> ut_addr_v6) da risolvere tramite DNS. Nel tuo caso questo valore contiene anche zero.

La maggior parte dns_lookupè vetrinistica ed heusteric. Fondamentalmente ciò che conta è la funzione getnameinfo. Questa è una chiamata in libreria che in questo caso farà del suo meglio per risolvere il valore binario memorizzato in ut_addr_v6. Quando questa voce contiene zero (come nel tuo caso), lo stai risolvendo esattamente 0.0.0.0come succede con l' last -ioutput.

C'è qualcosa (diverso dall'attività dannosa) che spiegherebbe ragionevolmente il comportamento?

Beh, probabilmente è un bug o una svista. È improbabile che sia dannoso poiché sembra stupido lasciare qualsiasi traccia come attaccante piuttosto che omettere un indirizzo di origine.

Finora il focus delle risposte è stato guardare nel posto sbagliato. lastlegge utmpo wtmp. Tuttavia laststa facendo del suo meglio con i dati che ha.

La tua causa principale sta da qualche parte nel modo in cui utmpviene scritta !

Mentre alcune applicazioni scrivono direttamente, utmpsuppongo che l'origine dei tuoi problemi risieda nel modo in cui sshdsi gestisce la gestione della sessione.

Oltre al timestamp della cronologia bash, ci sono altre cose che posso fare per rintracciare il problema?

utmpnon è tipicamente scrivibile e non è pensato per esserlo. utmpè scritto da applicazioni progettate per accedere e configurare la sessione. Nel tuo caso lo è sshd.

Perché sshd non sta gestendo correttamente l'utente è molto strano in quanto dovrebbe copiare correttamente il nome host da cui provieni. Questo è dove gli sforzi di debug dovrebbero probabilmente essere focalizzati. Inizia con l'aggiunta dell'output di debug di sshd ai tuoi log e vedi se compare qualcosa di anomalo.

Se vuoi aggirare il problema (o, forse, scoprire eventualmente altro sul problema) puoi usarlo pam_lastlogper gestirlo utmpaggiungendolo alla voce della sessione in /etc/pam.d/sshd.

È un dato di fatto, non farà male controllare se è già lì - perché pam_lastlogcontiene nohostun'opzione che spiegherebbe sicuramente il tuo comportamento che stai vivendo.

Infine, non è stato possibile utilizzare l'ultimo. aulastfa lo stesso lavoro tramite il sottosistema di controllo.

Potrebbe valere la pena provare se questo è riuscito a scrivere almeno l'indirizzo corretto. In caso contrario, il problema deve riguardare sshd poiché sshd sta passando i nomi DNS in diversi sottosistemi come utmp o audit.

(1) Base su lastuscita OP

Dopo aver effettuato l'accesso tramite ssh, si può ssh su localhost e ottenere 0.0.0.0 last -iper il successivo.

Base sulle prime quattro righe del registro di 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/19l'accesso era pts/17nel periodo di accesso.

pts/17l'accesso era pts/1 nel periodo di accesso.

Per questa specifica occorrenza, è logico indovinare che OP ssh da 192.0.2.91 ( pty/1), quindi all'interno di quella sessione ssh, accedere ssh localhostnuovamente localmente ( ) al server ( pts/17) e di nuovo ( pts/19).

Si prega di verificare se questa sovrapposizione si verifica con altre occorrenze.

Di seguito può aiutare a individuare la causa

• Usi ssh-key? In tal caso, sul server, hai impostato ssh-key per accedere localmente?
• Controlla o pubblica / var / log / secure dello stesso intervallo di tempo. Potrebbe fornire qualche suggerimento.
• Controlla gli script che usi
• Controlla gli alias di shell che usi
• Controlla la cronologia dei tuoi comandi

(2) Secnario aggiuntivo

Scenario 1: sudo e terminale

1. Accesso utente X Finestra
2. Apri un terminale windows, fai xhost + localhost
3. su - UserBo sudo su - UserBquindi aprire un nuovo terminale (xterm, gnome-terminal, ecc.)
4. UserB verrà visualizzato come 0.0.0.0 in last -i

su - UserBnon si registrerà come UserBlogin in ultimo, ma aprendo un terminale sarà.

Scenario 2: accesso

1. ssh nel server
2. genere sudo login
3. accedi come te stesso
4. controllare lastelast -i

lastmostra nessun nome host o IP per il login session. last -isarà IP 0.0.0.0 per 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

La risposta di Mife mostra già il blocco di codice di last.c. Il motivo per lastvisualizzare il nome host / IP vuoto è perché ut_hostper quei record sono effettivamente vuoti. Per una struttura wtmp completa, esegui man wtmpsu qualsiasi sistema Linux.

I 2 scenari qui mostrano che anche i pacchetti standard, in determinate situazioni, li creano come tali.

(3) Bash History Hack

Funzionerà solo se la sessione utilizza bashcome shell interattiva.

.bashrce .bash_profilesono utilizzati solo da bash.

Non verranno generati automaticamente se la sessione utilizza qualsiasi altra shell (sh, csh, ecc.) O esegue direttamente il programma e non ci sarà neanche una cronologia di bash.

(4) Elaborazione contabilità

Dal momento che OP non menziona nulla sul securefile, suppongo che sia un vicolo cieco e in realtà fornisce un suggerimento.

Se il seguente presupposto è corretto

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

auth.log (debian) / secure (CentOS) non aiuterà. Poiché in essa è registrata solo l'azione relativa all'autenticazione.

Anche wtmp / utmp, con la limitazione nella loro struttura di dati, è un vicolo cieco. Non ci sono informazioni su ciò che li ha creati.

Questo ci lascia con un'opzione, elaborare la contabilità . Questa è una grande pistola e deve essere usata con cautela.

1. Forse contro la politica aziendale
2. Altri utenti su un sistema condiviso potrebbero essere infelici / a disagio con questo abilitato
3. Il file di registro può utilizzare molto spazio su disco. Tieni d'occhio il tasso di crescita delle dimensioni del file.

La versione del pacchetto psacct dovrebbe essere 6.3.2-56 o successiva, secondo questo post .

Se deve essere usato e /var/logha uno spazio limitato, cambia il file di registro acct in una directory (accesso solo root) in /home, che di solito ha molto più spazio.

Questa è davvero la grande pistola. Con un tasso di occorrenza del 10% OP, dovrebbe esserci un risultato entro una settimana. Se durante quel periodo, appare una voce vuota lastma nulla dal registro acct, diventa una situazione misteriosa e richiederebbe un'azione drastica .

Di seguito è riportato un esempio di output di 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

Puoi anche usare 'dump-acct' per mostrare più informazioni.

PS1: ho provato ad aprire qualche terminale e sessione ssh. Non è chiaro (o non facile da individuare) cosa aprire un nuovo punto. Tuttavia, mostra tutto ciò che è stato eseguito all'interno di quel punto / sessione.

PS2: un post sul blog sull'uso di acct da parte di Mike.

Quando si accede a una macchina, queste potrebbero essere alcune voci nell'ultimo comando.

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)    

La prima voce con tty * arriva quando si accede tramite il terminale o la console premendo CTRL + ALT + F1-6. È praticamente chiaro dal terminale che sta utilizzando.

La seconda voce viene normalmente visualizzata quando si accede a una macchina e si apre una finestra del terminale nella GUI. Ci sarà anche una voce anche se si apre una nuova scheda nella stessa finestra del terminale.

Il terzo tipo di voce viene visualizzato quando si apre una sessione dello schermo dopo aver effettuato l'accesso tramite SSH. Ciò creerà anche una voce lì e senza alcun indirizzo IP.

La quarta voce è abbastanza normale e tutti capiscono.

Se lo fai last -icon le seguenti voci, vedrai qualcosa del genere:

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)    

Sono praticamente sicuro che il tuo caso rientri in uno dei 2 casi, uno con il terminale Window nella GUI e l'altro con la sessione dello schermo.

Spero che questo abbia aiutato.

Non credo che andremo lontano con questo senza il debug di last.c, ma non dovrebbe essere troppo difficile in quanto si compila facilmente ...

Una possibilità però è di scaricare il file / var / log / wtmp usando il comando utmpdump e dare un'occhiata ai record grezzi che potrebbero farti luce. In caso contrario, si prega di inviare alcuni output pertinenti da

utmpdump /var/log/wtmp 

in modo che possiamo ricreare copie locali del tuo wtmp con cui eseguire il debug

utmpdump -r <dumpfile >wtmp

Ho controllato su 12 server applicativi multiutente CentOS e RHEL 6.3. Nessuno ha mostrato questo comportamento. Non c'erano voci mancanti lastnell'output risalenti a 4-5 settimane.

Penso che sarebbe importante vedere la /etc/hostsvoce del file per assicurarsi che sia conforme a questo formato .

Inoltre, cosa stai facendo per la risoluzione DNS? Puoi pubblicare il tuo /etc/resolv.conf?

Le altre risposte che indicano che 0.0.0.0rappresenta le connessioni locali sono corrette. Gli esempi tipici sono il riavvio e gli eventi di accesso alla console:

 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)    

Dal momento che questo sembra accadere solo con utenti nominati, c'è qualche cambiamento c'è qualcosa di funky che viene fornito o eseguito nei loro script di accesso? Hai cambiato ~/.bashrco ~/.bash_profiledi default? Ci sono altri script di accesso speciali nell'ambiente?

--Modificare--

Non riesco ancora a riprodurlo in alcun modo. Guardo due componenti critici, però. Il lastcomando è stabile e non è stato modificato da molto tempo. Guardando il log delle modifiche per gli strumenti di sysvinit , non ci sono bug rilevanti. Lo stesso vale per initscripts (wtmp).

Se riesci a forzare questo, provalo con un altro account utente dalle stesse macchine di origine. Ma non vedo alcuna indicazione che si tratti di un problema con il sistema operativo.

RISOLUZIONE FINALE

Ho già assegnato il bonus, quindi questo è puramente per i futuri googler con la stessa domanda.

Il motivo per cui questo appare solo nel ~ 10% dei miei accessi è perché quando apporto importanti modifiche ai nostri router o switch, lo uso in script foo.logmodo da disporre di un registro terminale completo della modifica. Per motivi che ancora non capisco, CentOS crea una ptsvoce quando si utilizza il scriptcomando ... Dimostrerò l'output di last -iprima e dopo l'esecuzione 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]$

Questo comportamento sembra essere unico per CentOS 6 ... abbiamo alcune macchine CentOS 4.7 in laboratorio che non mettono una voce vuota in wtmp... Le macchine Debian / Gentoo non mostrano questo comportamento. I nostri amministratori di Linux si grattano la testa perché CentOS aggiunga intenzionalmente un'altra ptsvoce quando esegui script... Sospetto che si tratti di un bug RHEL.

EDIT : ho presentato questo problema come ID bug RHEL 892134

NOTA

Alcune persone hanno erroneamente supposto che io inserissi il scriptmio ~/.bashrco ~/.bash_profile. Questo è un argomento imperfetto ... se fosse vero, wtmpdovrei avere una 0.0.0.0voce dopo ognuno dei miei accessi 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)  # <-----

Certo, non era così ...

Le connessioni Pseudo Terminal Slave (pts) sono connessioni SSH o telnet che indicano connessioni indirette al sistema. Tutte queste connessioni possono connettersi a una shell che ti permetterà di inviare comandi al computer. Quindi quando si apre un terminale sul proprio sistema dalla GUI, si apre un pts con IP ip 0.0.0.0 di origine. Dalle informazioni fornite da te, sembra che stia accadendo a causa dello script in esecuzione su questo server o pianificato, che utilizza il servizio ssh o telnet o punti locali per lanciare l'output nel terminale.

Quale client ssh usi? Alcuni client SSH possono multiplexare più terminali su una connessione e noto che tutte le sessioni senza IP rientrano in sessioni più lunghe che hanno un IP registrato.

Non posso duplicare questo comportamento con ssh qui.

Forse il tuo indirizzo IP si risolve in una stringa vuota su uno dei tuoi server DNS, probabilmente il secondario se accade solo il 10% delle volte (o forse solo un file host se questi sono distribuiti da un repository centrale). Ciò spiegherebbe la voce mancante (o spazio bianco) e sarebbe coerente con la lettura di Soham della fonte.

"0.0.0.0" significa che è un utente locale (non un accesso remoto), probabilmente invocato dall'applicazione, ad esempio cronjob.

Succede perché usi il sistema locale e 0.0.0.0 indica l'indirizzo IP di tutte le interfacce. Se pensi che forse qualcuno abbia violato, prova a configurare la registrazione completa della shell compresi i comandi tramite ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Ho risolto aggiungendo uno script a ~ / .bashrc lo script trova l'ultimo indirizzo IP di origine della connessione telnet, quindi è possibile aggiungere l'IP a un file di registro o fare tutto ciò di cui si ha bisogno.

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