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 -imuestra0.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)
last -i mpenningmuestra los espacios en blanco?Respuestas:
scriptdiferencias de comportamiento entre RedHat y DebianBibliotecas vinculadas
CentOS 6.3 - script (util-linux-ng 2.17.2)
Ubuntu 12.04 - script (util-linux 2.20.1)
PTY
Base en código fuente ascendente ,
scriptde ambas versiones abren nueva pty. Siguiente es prueba.Ubuntu 12.04
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 wtmplibutemper
Entonces, la principal diferencia parece ser la biblioteca adicional (
libutempter.so.0) centradascriptcon CentOS .Prueba con Ubuntu 12.04
Compilando
scriptcon libutempterPruebas
Antes de correr
scriptDentro
scriptDespues del
scriptfinalLa causa raíz del nombre de host emtpy
Y sí,
script.ccree lawtmpentrada con el nombre de host vacío. Mire el siguiente bloque de código en lautil-linux-2.20.1/term-utils/script.clínea: 245-247Basado en
libutempter-1.1.5/utempter.hEntonces, en
script.crealidad está pasando un nombre de host vacíoutempter_add_record.RedHat Backport
Lo interesante es que upstream en
util-linux-ng-2.17.2realidad no es compatiblelibutempter. Parece que Redhat decidió agregar ese respaldo nuevamente.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ó.
fuente
coreutilsversión rpm que usa CentOS 5? Tengo que verificar el código fuente.libutempterno está vinculado en EL4 (víaldd), pero está vinculado en elscriptcomando EL5 y EL6 . Es probable que este cambio de características haya sido implementado para sistemas similares a Red Hat desde la introducción en 2007 de RHEL 5.coreutilsen EL4 es la versión 5.2.1. En EL5 es la versión 5.97.scriptestá en util-linux.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.Las dos variables globales utilizadas en el contexto son estas.
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.
fuente
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.cAmbos
usednsyuseip(usando las opciones predeterminadas) no están marcados. Esto hace que la lógica se copie fuera de la estructurap->ut_hostque, segúnman utmpcontiene, el nombre de inicio de sesión remoto según lo registrado por lo que haya escrito en elutmp.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óngetnameinfo. Esta es una llamada a la biblioteca que en este caso hará todo lo posible para resolver el valor binario almacenado enut_addr_v6. Cuando esta entrada contiene ceros (como en su caso), en realidad está resolviendo esto0.0.0.0como es lo que sucede con sulast -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 leeutmpowtmp. 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 elsshdmanejo 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 essshd.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 administrarutmpagregá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 unanohostopció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.
fuente
pam_lastlogcomo se mencionó anteriormente?(1) Base en
lastsalida OPDespué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
pts/19iniciar sesión fue dentro delpts/17período de inicio de sesión.pts/17iniciar sesión fue dentro delpts/1perí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
(2) Secnario adicional
Escenario 1 - sudo y terminal
xhost + localhostsu - UserBosudo su - UserBluego abra una nueva terminal (xterm, gnome-terminal, etc.)UserBse mostrará como 0.0.0.0 enlast -isu - UserBno se registrará comoUserBinicio de sesión en último lugar, pero abrir un terminal lo hará.Escenario 2 - inicio de sesión
sudo loginlastylast -ilastno mostrar nombre de host o IP para ellogin session.last -iIP 0.0.0.0 para ellogin session.La respuesta de Mife ya muestra el bloque de código de
last.c. La razón paralastmostrar el nombre de host / IP vacío es porqueut_hostesos registros están realmente vacíos. Para una estructura wtmp completa, hazloman 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 porbash.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
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.
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
lastcommTambié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.
fuente
ssh localhosty verifiquelast -i.login locally, me refiero a hacerssh localhostdentro de esa sesión ssh. Modifiqué esa oración, espero que ahora sea menos confusa.Cuando inicia sesión en una máquina, estas podrían ser pocas entradas en el último comando.
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: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.
fuente
screenninguna de las0.0.0.0entradas. Solo uso la GUI cuando instalé las máquinas (alrededor de agosto / septiembre). Veo muchas0.0.0.0entradas de pts después de ese tiempo.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
para que podamos recrear copias locales de su wtmp para depurar con
fuente
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: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.
fuente
/etc/hosts) deberían afectar a todos ... no solo yolast -ifambos archivos y ver si ves los mismos resultados con el tiempo?/var/log/secure... las entradas que0.0.0.0muestran no muestran nada en/var/log/secureRESOLUCION 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 unaptsentrada cuando usa elscriptcomando ... Demostraré el resultado delast -iantes y después de ejecutarscript...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 otraptsentrada 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, miwtmpdebería tener una0.0.0.0entrada después de cada uno de mis inicios de sesión ssh ...Por supuesto, ese no fue el caso ...
fuente
scriptcomando en su pregunta inicial.scriptprograma hace un mecanografiado de todo lo impreso en su terminal. Es un detalle pertinente..bashrco.bash_profileno; Ejecutoscript foo.logcuando hago cambios importantes para poder tener un registro de cambios ... es decir, por eso solo afecta al ~ 10% de mis inicios de sesión 2) Si su acusación es correcta (y no lo es), nunca tendría un inicio de sesión ssh que no tenía otra0.0.0.0entrada justo después 3)scriptsolo lo hace en CentOS ... Lo he usado durante más de una década y nunca vi este comportamiento en otra distribución ... en este punto, estoy argumentando que es probable que sea un CentOS errorscriptsolo bifurcaré un shell. En base a lo que está mostrando aquí, la versión CentOS / Redhat descriptrealmente bifurca primero. Aunque un poco decepcionado (: P) de que no es algo más genérico / a través de la distribución, al menos el misterio ha desaparecido de mi mente. PD: Me sorprende que tengas a Gentoo en producción @. @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.
fuente
¿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í.
fuente
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.
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.
fuente
# last -i |grep 0.0.0.0 \ reboot system boot 0.0.0.0 Wed Dec 5 20:09 - 17:18 (15+21:08) # last |grep reboot \ reboot system boot 2.6.32-10-pve Wed Dec 5 20:09 - 17:18 (15+21:08)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/
fuente
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 ...
Sharon
fuente
netstat -nae | grep 23No es una forma útil de encontrar conexiones telnet. Este comando da 92 resultados en mi sistema, ninguno de ellos es telnet.