Tengo cinco sistemas Linux CentOS 6 en el trabajo, y encontré un problema bastante extraño que solo parece ocurrir con mi ID de usuario en todos los sistemas Linux que tengo ... Este es un ejemplo del problema de las entradas que exceptué del 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)

Puede ver dos de mis entradas de inicio de sesión de pts que no tienen una dirección IP de origen asociada a ellas. Mis máquinas CentOS tienen hasta otros seis usuarios que comparten los sistemas. Aproximadamente el 10% de mis inicios de sesión ven este problema, pero ningún otro nombre de usuario exhibe este comportamiento . No hay entrada /var/log/securepara las entradas sin una dirección IP de origen.

Preguntas

Dado el tipo de scripts que mantengo en estos sistemas (que controlan gran parte de nuestra infraestructura de red), estoy un poco asustado por esto y me gustaría entender qué ocasionaría que mis inicios de sesión ocasionalmente pierdan las direcciones de origen.

• ¿Por qué se last -imuestra 0.0.0.0para las entradas de línea de pts (también vea esta respuesta )
• ¿Hay algo (que no sea actividad maliciosa) que explique razonablemente el comportamiento?
• Además de la marca de tiempo del historial de bash, ¿hay otras cosas que pueda hacer para rastrear el problema?

Informativo

Desde que esto comenzó a suceder, habilité la bashmarca de tiempo del historial (es decir, HISTTIMEFORMAT="%y-%m-%d %T "en .bash_profile) y también agregué algunos otros trucos del historial de bash ; sin embargo, eso no da pistas sobre lo que sucedió durante los sucesos anteriores.

Todos los sistemas ejecutan 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 ~]$

EDITAR

Si lo uso last -i mpenning, veo entradas como esta ...

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 para aquellos que intentan responder: no he iniciado sesión con el screencomando o la GUI . Todos mis inicios de sesión son de SSH; Para recibir el premio de recompensa, debe citar referencias autorizadas para explicar las last -i 0.0.0.0entradas obtenidas solo a través de SSH.

EDITAR 2 (para las preguntas de ewwhite)

/etc/resolv.conf(tenga en cuenta que utilicé .localaddrs en la lastsalida anterior para ocultar la información de mi empresa)

[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 información (tenga en cuenta que este archivo de hosts personalizado solo existe en una de las máquinas que tiene estos problemas)

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

sftpSalida desde /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)

RESOLUCION FINAL

Mira mi respuesta a continuación

script diferencias de comportamiento entre RedHat y Debian

Bibliotecas vinculadas

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

Base en código fuente ascendente , scriptde ambas versiones abren nueva pty. Siguiente es prueba.

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 scriptabrió un nuevo pts (2). Simplemente no se actualizó /var/log/wtmp.

CentOS 6

Me estoy saltando la prueba porque ya sabemos que scriptabrir pty y registrarse con wtmp

libutemper

• Proyecto: http://freecode.com/projects/libutempter
• Descripción: libutempter proporciona una interfaz de biblioteca para emuladores de terminal como screen y xterm para grabar sesiones de usuario en archivos utmp y wtmp.

Entonces, la principal diferencia parece ser la biblioteca adicional ( libutempter.so.0) centrada scriptcon CentOS .

Prueba 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)

Pruebas

Antes de correr 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

Dentro 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

Despues del scriptfinal

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 raíz del nombre de host emtpy

Y sí, script.ccree la wtmpentrada con el nombre de host vacío. Mire el siguiente bloque de código en la util-linux-2.20.1/term-utils/script.clínea: 245-247

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

Basado en libutempter-1.1.5/utempter.h

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

Entonces, en script.crealidad está pasando un nombre de host vacío utempter_add_record.

RedHat Backport

Lo interesante es que upstream en util-linux-ng-2.17.2realidad no es compatible libutempter. Parece que Redhat decidió agregar ese respaldo nuevamente.

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

El comando anterior devuelve un resultado vacío.

Conclusión

Entonces, la diferencia de comportamiento entre las dos distribuciones no es un error, sino una elección. RedHat decidió admitir esa característica, mientras que Debian la omitió.

Esto me parece absolutamente desconcertante. O bien, debe usar algún nombre DNS o dirección IP. También revisé el last.carchivo pero todavía no puedo encontrar por qué no muestra nada. Probablemente con algo de tiempo, puedo calcular la parte sobre 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 }

Las dos variables globales utilizadas en el contexto son estas.

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

Entonces, en teoría, debería usar dns o IP.

Veré si puedo cavar algo más. Pero lo que ewwhite hizo son preguntas válidas.

Así que corrí por última vez en un depurador que con suerte le dará al menos algunas respuestas a su pregunta. Sin embargo, mi sentimiento es que la causa raíz es más profunda.

¿Por qué last -i muestra 0.0.0.0 para entradas de línea pts

La mejor manera de explicar esto es lo que sucede cuando no pasa -i.

La razón de esto está en esta sección de código de 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);
}

Ambos usednsy useip(usando las opciones predeterminadas) no están marcados. Esto hace que la lógica se copie fuera de la estructura p->ut_hostque, según man utmpcontiene, el nombre de inicio de sesión remoto según lo registrado por lo que haya escrito en el utmp.

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

En su caso, el valor aquí es ceros. Es por eso que cuando ejecutas lastnada aparece para ti.

En el caso de last -ientonces se invoca dns_lookup. Esto pasará la entrada (p-> ut_addr_v6) que se resolverá a través de DNS. En su caso, este valor también contiene ceros.

La mayor parte dns_lookupes escaparatismo y heusteric. Básicamente lo que importa es la función getnameinfo. Esta es una llamada a la biblioteca que en este caso hará todo lo posible para resolver el valor binario almacenado en ut_addr_v6. Cuando esta entrada contiene ceros (como en su caso), en realidad está resolviendo esto 0.0.0.0como es lo que sucede con su last -isalida.

¿Hay algo (que no sea actividad maliciosa) que explique razonablemente el comportamiento?

Bueno, probablemente sea un error o descuido. Su poco probable que sea dañino, ya que parece estúpida dejar ningún rastro como atacante en lugar de omitir una dirección de origen.

El foco de las respuestas hasta ahora ha sido buscar el lugar equivocado. lastsolo lee utmpo wtmp. Sin embargo, lastestá haciendo todo lo posible con los datos que tiene.

¡Su causa raíz se encuentra en algún lugar de la manera en que utmpse está escribiendo !

Si bien algunas aplicaciones escriben directamente utmp, supongo que la fuente de sus problemas radica en el sshdmanejo de la administración de la sesión.

Además de la marca de tiempo del historial de bash, ¿hay otras cosas que pueda hacer para rastrear el problema?

utmpnormalmente no se puede escribir y no está destinado a serlo. utmpestá escrito por aplicaciones diseñadas para iniciar sesión y configurar su sesión. En tu caso eso es sshd.

Por qué sshd no maneja a su usuario correctamente es muy extraño, ya que debería estar copiando correctamente el nombre de host del que vino. Aquí es donde los esfuerzos de depuración probablemente deberían centrarse. Comience agregando la salida de depuración de sshd a sus registros y vea si surge algo anómalo.

Si desea solucionar el problema (o tal vez incluso descubrir más sobre el problema) puede usarlo pam_lastlogpara administrar utmpagregándolo a la entrada de la sesión en /etc/pam.d/sshd.

De hecho, no está de más comprobar si ya está allí, porque pam_lastlogcontiene una nohostopción que definitivamente explicaría su comportamiento.

Finalmente, no podrías usar el último en absoluto. aulasthace el mismo trabajo a través del subsistema de auditoría.

Puede valer la pena intentar ver si eso ha logrado al menos escribir la dirección correcta. Si no es así, su problema debe ser sshd, ya que sshd está pasando los nombres DNS a diferentes subsistemas como utmp o audit.

(1) Base en lastsalida OP

Después de iniciar sesión a través de ssh, se puede enviar ssh a localhost y obtener 0.0.0.0 last -ipara más adelante.

Base en las primeras cuatro líneas del registro de 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/19iniciar sesión fue dentro del pts/17período de inicio de sesión.

pts/17iniciar sesión fue dentro del pts/1 período de inicio de sesión.

Para esta ocurrencia específica, es lógico adivinar que OP ssh desde 192.0.2.91 ( pty/1), luego dentro de esa sesión ssh, inicie sesión localmente ( ssh localhost) en el servidor nuevamente ( pts/17) y nuevamente ( pts/19).

Verifique si esta superposición ocurre con otra ocurrencia.

Lo siguiente puede ayudar a señalar la causa

• ¿Usas ssh-key? Si es así, en el servidor, ¿configuró ssh-key para iniciar sesión localmente?
• Verifique o publique / var / log / secure del mismo período de tiempo. Puede proporcionar alguna pista.
• Verifica los scripts que usas
• Verifique los alias de shell que usa
• Revisa tu historial de comandos

(2) Secnario adicional

Escenario 1 - sudo y terminal

1. Usuario X ventana de inicio de sesión
2. Abra una ventana de terminal, haga xhost + localhost
3. su - UserBo sudo su - UserBluego abra una nueva terminal (xterm, gnome-terminal, etc.)
4. UserB se mostrará como 0.0.0.0 en last -i

su - UserBno se registrará como UserBinicio de sesión en último lugar, pero abrir un terminal lo hará.

Escenario 2 - inicio de sesión

1. ssh en el servidor
2. tipo sudo login
3. inicie sesión como usted mismo
4. comprobar lastylast -i

lastno mostrar nombre de host o IP para el login session. last -iIP 0.0.0.0 para el 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 respuesta de Mife ya muestra el bloque de código de last.c. La razón para lastmostrar el nombre de host / IP vacío es porque ut_hostesos registros están realmente vacíos. Para una estructura wtmp completa, hazlo man wtmpen cualquier sistema Linux.

Los 2 escenarios aquí muestran que incluso los paquetes estándar, bajo cierta situación, los crean como tales.

(3) Bash History Hack

Solo funcionará si la sesión se usa bashcomo shell interactivo.

.bashrcy .bash_profilesolo son utilizados por bash.

No se obtendrán automáticamente si la sesión usa cualquier otro shell (sh, csh, etc.) o ejecuta el programa directamente, y tampoco habrá historial de bash.

(4) Contabilidad de procesos

Dado que OP no menciona nada sobre el securearchivo, asumiré que es un callejón sin salida y que en realidad proporciona una pista.

Si la siguiente suposición es correcta

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

auth.log (debian) / secure (CentOS) no ayudará. Como solo se registra en él la acción relacionada con la autenticación.

wtmp / utmp, con la limitación en su estructura de datos, también es un callejón sin salida. No hay información sobre lo que los creó.

Eso nos deja con una opción, la contabilidad de procesos . Esta es una gran arma y debe usarse con precaución.

1. Quizás en contra de la política de la compañía
2. Otros usuarios en un sistema compartido pueden estar descontentos / incómodos con él habilitado
3. El archivo de registro puede usar mucho espacio en disco. Esté atento a la tasa de crecimiento del tamaño del archivo.

La versión del paquete psacct debe ser 6.3.2-56 o superior, de acuerdo con esta publicación .

Si se va a utilizar esto y /var/logtiene un espacio limitado, cambie el archivo de registro de acct a un directorio (acceso solo raíz) debajo /home, que generalmente tiene mucho más espacio.

Esta es realmente la gran arma. Con una tasa de incidencia de OP del 10%, debería haber un resultado dentro de una semana. Si durante ese período, la entrada vacía aparece lastpero nada en el registro de cuentas, se convierte en una situación misteriosa y requeriría una acción drástica .

A continuación se muestra una salida de muestra de 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

También puede usar 'dump-acct' para mostrar más información.

PS1: intenté abrir algunas sesiones de terminal y ssh. No está claro (o no es fácil de señalar) qué abrirá un nuevo pts. Sin embargo, muestra todo lo que se ejecutó dentro de esa sesión / pts.

PS2: Una publicación de blog sobre el uso de la actuación de un Mike.

Cuando inicia sesión en una máquina, estas podrían ser pocas entradas en el último 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 primera entrada con tty * aparece cuando inicia sesión a través del terminal o la consola presionando CTRL + ALT + F1-6. Está bastante claro desde el terminal que está usando.

La segunda entrada normalmente aparece en la imagen cuando inicia sesión en una máquina y abre una ventana de terminal en la GUI. También habrá una entrada incluso si abre una nueva pestaña en la misma ventana de terminal.

El tercer tipo de entrada se produce cuando abre una sesión de pantalla después de iniciar sesión a través de SSH. Eso también creará una entrada allí y sin ninguna dirección IP.

La cuarta entrada es bastante normal, que todos entienden.

Si lo hace last -icon las siguientes entradas, verá algo como esto:

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)    

Estoy bastante seguro de que su caso entra en cualquiera de los 2 casos, uno con la ventana de terminal en la GUI y el otro con la sesión de pantalla.

Espero que esto ayude.

No creo que lleguemos lejos con esto sin depurar last.c, pero eso no debería ser demasiado difícil ya que se compila fácilmente ...

Sin embargo, una posibilidad es volcar el archivo / var / log / wtmp usando el comando utmpdump y echar un vistazo a los registros en bruto, esto puede arrojar algo de luz para usted. Si no es así, publique alguna salida relevante de

utmpdump /var/log/wtmp 

para que podamos recrear copias locales de su wtmp para depurar con

utmpdump -r <dumpfile >wtmp

Verifiqué en 12 servidores de aplicaciones multiusuario CentOS y RHEL 6.3. Ninguno exhibió este comportamiento. No hubo entradas faltantes en la lastproducción que se remontan a las 4-5 semanas.

Creo que sería importante ver su /etc/hostsentrada de archivo para asegurarse de que se ajusta a este formato .

Además, ¿qué estás haciendo para la resolución DNS? ¿Puedes publicar tu /etc/resolv.conf?

Las otras respuestas que indican que 0.0.0.0representa conexiones locales son correctas. Los ejemplos típicos son los eventos de reinicio y de inicio de sesión de la consola:

 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)    

Dado que esto solo parece ocurrir con usuarios nombrados, ¿hay algún cambio? ¿Hay algo funky que se obtiene o ejecuta en sus scripts de inicio de sesión? ¿Has cambiado ~/.bashrco ~/.bash_profilepor defecto? ¿Hay otros scripts de inicio de sesión especiales en el entorno?

--Editar--

Todavía no puedo reproducir esto de ninguna manera. Sin embargo, miro dos componentes críticos. El lastcomando es estable y no se ha cambiado en mucho tiempo. Mirando el registro de cambios de sysvinit-tools , no hay errores relevantes. Lo mismo para initscripts (wtmp).

Si puede forzar que esto suceda, pruébelo con una cuenta de usuario diferente de las mismas máquinas de origen. Pero no veo ninguna indicación de que este sea un problema del sistema operativo.

RESOLUCION FINAL

Ya otorgué el bono, así que esto es solo para futuros googlers con la misma pregunta.

La razón por la que esto solo aparece en ~ 10% de mis inicios de sesión es porque cuando hago cambios importantes en nuestros enrutadores o conmutadores, lo uso script foo.logpara tener un registro completo del cambio del terminal. Por razones que todavía no entiendo, CentOS crea una ptsentrada cuando usa el scriptcomando ... Demostraré el resultado de last -iantes y después de ejecutar 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]$

Este comportamiento parece ser exclusivo de CentOS 6 ... tenemos algunas máquinas CentOS 4.7 en el laboratorio que no ponen una entrada en blanco en wtmp... Las máquinas Debian / Gentoo tampoco exhiben este comportamiento. Nuestros administradores de Linux se están rascando la cabeza por qué CentOS agregaría intencionalmente otra ptsentrada cuando ejecutasscript ... Sospecho que este es un error RHEL.

EDITAR : presenté este problema como ID de error RHEL 892134

NOTA

Algunas personas han asumido erróneamente que puse scriptmi ~/.bashrco ~/.bash_profile. Este es un argumento defectuoso ... si eso fuera cierto, mi wtmpdebería tener una 0.0.0.0entrada después de cada uno de mis inicios de sesión 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)  # <-----

Por supuesto, ese no fue el caso ...

Las conexiones Pseudo Terminal Slave (pts) son conexiones SSH o telnet que significan conexiones indirectas al sistema. Todas estas conexiones pueden conectarse a un shell que le permitirá emitir comandos a la computadora. Entonces, cuando abre un terminal en su sistema desde la interfaz gráfica de usuario, se abre un pts con source ip 0.0.0.0. Según la información proporcionada por usted, parece que sucede debido a la secuencia de comandos que se ejecuta en este servidor o está programada, que utiliza el servicio ssh o telnet o los puntos locales para lanzar la salida en la terminal.

¿Qué cliente ssh usas? Algunos clientes ssh pueden multiplexar múltiples terminales a través de una conexión y noto que todas sus sesiones sin IP caen dentro de sesiones más largas que tienen una IP registrada.

No puedo duplicar este comportamiento con ssh aquí.

Tal vez su dirección IP se resuelva en una cadena en blanco en uno de sus servidores DNS, probablemente la secundaria si ocurre solo el 10% del tiempo (o simplemente un archivo de host si se distribuye desde un repositorio central). Eso explicaría la entrada faltante (o espacio en blanco) y sería coherente con la lectura de Soham de la fuente.

"0.0.0.0" significa que es un usuario local (no un inicio de sesión remoto), probablemente invocado por la aplicación, por ejemplo, cronjob.

Ocurre porque usa el sistema local y 0.0.0.0 significa la dirección IP de todas las interfaces. Si cree que tal vez alguien hackeado, intente configurar el registro completo del shell, incluidos los comandos a través de ssh: http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Lo resolví agregando un script a ~ / .bashrc, el script encuentra la última dirección IP de origen de la conexión Telnet, luego puede agregar el IP a un archivo de registro o hacer lo que necesite ...

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