Raisons pour lesquelles il manque des informations IP dans la sortie `last` lors des connexions pts?


18

J'ai cinq systèmes Linux CentOS 6 au travail et j'ai rencontré un problème assez étrange qui ne semble se produire qu'avec mon ID utilisateur sur tous les systèmes Linux que j'ai ... Ceci est un exemple du problème des entrées que j'ai excepté de la lastcommande .. .

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)

Vous pouvez voir deux de mes entrées de connexion pts ci-dessus qui ne sont pas associées à une adresse IP source. Mes machines CentOS ont jusqu'à six autres utilisateurs qui partagent les systèmes. Environ 10% de mes connexions voient ce problème, mais aucun autre nom d'utilisateur ne présente ce comportement . Il n'y a pas d'entrée /var/log/securepour les entrées sans adresse IP source.

Des questions

Compte tenu du type de scripts que je garde sur ces systèmes (qui contrôlent une grande partie de notre infrastructure réseau), je suis un peu effrayé par cela et j'aimerais comprendre ce qui pourrait amener mes connexions à manquer occasionnellement des adresses source.

  • Pourquoi last -is'affiche 0.0.0.0pour les entrées de ligne pts (voir également cette réponse )
  • Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?
  • Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?

Informatif

Depuis que cela a commencé, j'ai activé l' bashhorodatage de l'historique (c'est- HISTTIMEFORMAT="%y-%m-%d %T "à- dire dans .bash_profile) et j'ai également ajouté quelques autres hacks d'historique bash ; cependant, cela ne donne pas d'indices sur ce qui s'est passé lors des événements précédents.

Tous les systèmes exécutent 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 ~]$

ÉDITER

Si j'utilise last -i mpenning, je vois des entrées comme celle-ci ...

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)

Remarque pour ceux qui tentent de répondre: je ne me suis pas connecté avec la screencommande ou l'interface graphique . Toutes mes connexions proviennent de SSH; pour recevoir le prix, vous devez citer des références faisant autorité pour expliquer les last -i 0.0.0.0entrées provenant uniquement via SSH.

EDIT 2 (pour les questions d'ewwhite)

/etc/resolv.conf(notez que j'ai utilisé des .localaddrs dans la lastsortie ci-dessus pour masquer les informations de mon entreprise)

[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 (notez que ce fichier d'hôtes personnalisé n'existe que sur l'une des machines qui a ces problèmes)

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

sftpSortie de /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)

RÉSOLUTION FINALE

Voir ma réponse ci-dessous


Se connectent-ils tous via ssh? J'ai plusieurs grands systèmes multi-utilisateurs CentOS 6.x. Je vais voir si je peux voir la même chose là-bas.
ewwhite

@ewwhite, merci ... toutes les connexions doivent être ssh (et parfois via la console GUI, mais je ne me connecte qu'à partir de l'interface graphique lorsque je remets la boîte en place). Aucun autre protocole de connexion à distance n'est activé.
Mike Pennington

La sortie de last -i mpenningmontre-t-elle les blancs?
JeffG

Oh, c'est vrai .. J'ai besoin de répliquer cela sur un serveur EL6.3 ...
ewwhite

Pouvez-vous fournir la sortie de connexion à partir de / var / log / secure et / var / log / messages? Je crois que la valeur IP est un paramètre transmis via PAM. PAM affiche-t-il l'IP correctement?
Matthew Ife

Réponses:


4

script différences de comportement entre RedHat et Debian

Bibliothèques liées

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 sur le code source en amont , scriptdes deux versions ouvrent un nouveau pty. Voici le 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 scripta ouvert un nouveau pts (2). Il n'a tout simplement pas été mis à jour /var/log/wtmp.

CentOS 6

Je saute le test car nous savons déjà qu'il scriptfaut ouvrir pty et s'enregistrer avec wtmp.

libutemper

  • Projet: http://freecode.com/projects/libutempter
  • Description: libutempter fournit une interface de bibliothèque pour les émulateurs de terminaux tels que screen et xterm pour enregistrer des sessions utilisateur dans des fichiers utmp et wtmp.

La principale différence semble donc être la bibliothèque supplémentaire ( libutempter.so.0) avec laquelle CentOS est scriptlié.

Testez avec Ubuntu 12.04

Compiler scriptavec 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)

Essai

Avant de courir 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

Dans 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

Après la scriptfin

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 cause première du nom d'hôte emtpy

Et oui, script.ccréez l' wtmpentrée avec un nom d'hôte vide. Regardez le bloc de code suivant dans la util-linux-2.20.1/term-utils/script.cligne: 245-247

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

Baser sur libutempter-1.1.5/utempter.h

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

Il en script.cest de même en passant un nom d'hôte vide dans utempter_add_record.

RedHat Backport

La chose intéressante est que l'amont util-linux-ng-2.17.2ne prend pas en charge libutempter. Il semble que Redhat ait décidé de rajouter ce soutien.

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

La commande ci-dessus renvoie un résultat vide.

Conclusion

La différence de comportement entre les deux distributions n'est donc pas un bug, mais un choix. RedHat a décidé de prendre en charge cette fonctionnalité, tandis que Debian l'a ignorée.


Qu'en est-il de CentOS 5?
ewwhite

@ewwhite Pouvez-vous me donner la coreutilsversion rpm utilisée par CentOS 5? Je dois vérifier le code source.
John Siu

Ce n'est pas nécessaire. libutemptern'est pas lié dans EL4 (via ldd), mais il est lié dans les scriptcommandes EL5 et EL6 . Cette modification de fonctionnalité a probablement été mise en place pour les systèmes de type Red Hat depuis l'introduction en 2007 de RHEL 5. coreutilssur EL4 est la version 5.2.1. Sur EL5, c'est la version 5.97.
ewwhite

Je vois. BTW, scriptest dans util-linux.
John Siu

1
@JohnSiu: Oui, c'est la raison de la différence, il me semble qu'ils ont corrigé le bogue signalé et (involontairement) en ont créé un nouveau.
user9517 pris en chargeGoFundMonica

12

Cela me semble absolument déroutant. Soit il doit utiliser un nom DNS ou une adresse IP. J'ai également vérifié le last.cfichier, mais je ne trouve toujours pas pourquoi il ne montre rien. Compte tenu probablement d'un certain temps, je peux comprendre la partie sur 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 }

Les deux variables globales utilisées dans le contexte sont les suivantes.

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

Donc, en théorie, il devrait utiliser le DNS ou IP.

Je vais voir si je peux creuser plus loin. Mais ce que ewwhite a demandé sont des questions valables.


1
+1 pour creuser dans le code source réel de la commande en question.
Chris Smith

Excellente information, c'est le genre de source faisant autorité que je recherche. Merci d'avoir fait le travail acharné pour trouver le code.
Mike Pennington

8

J'ai donc couru en dernier dans un débogueur qui, espérons-le, vous donnera au moins quelques réponses à votre question. Mon sentiment est que la cause profonde est plus profonde.

Pourquoi last -i affiche 0.0.0.0 pour les entrées de ligne pts

La meilleure façon d'expliquer cela est ce qui se passe lorsque vous ne réussissez pas -i.

La raison en est dans cette section de code 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);
}

Les deux usednset useip(en utilisant les options par défaut) ne sont pas marqués. Cela provoque la logique à copier hors de la structure p->ut_hostqui, selon, man utmpcontient le nom de connexion à distance tel qu'enregistré par tout ce qui a été écrit dans le utmp.

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

Dans votre cas, la valeur ici est des zéros. C'est pourquoi, lorsque vous exécutez, lastrien ne s'affiche pour vous.

Dans ce cas, last -idns_lookup est invoqué. Cela passera l'entrée (p-> ut_addr_v6) à résoudre via DNS. Dans votre cas, cette valeur contient également des zéros.

L'essentiel dns_lookupest l'habillage de fenêtre et heustérique. Ce qui compte, c'est la fonction getnameinfo. Il s'agit d'un appel de bibliothèque qui dans ce cas fera de son mieux pour résoudre la valeur binaire stockée dans le ut_addr_v6. Lorsque cette entrée contient des zéros (comme dans votre cas), vous résolvez 0.0.0.0en fait ce qui se passe avec votre last -isortie.

Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?

Eh bien, c'est probablement un bug ou une erreur. Il est peu probable qu'il soit malveillant, car il semble stupide de laisser une trace en tant qu'attaquant plutôt que d'omettre une adresse source.

Jusqu'à présent, les réponses se sont concentrées sur le mauvais endroit. lastlit simplement utmpou wtmp. Cependant lastfait de son mieux avec les données dont il dispose.

Votre cause profonde se situe quelque part dans la manière d' utmpécrire !

Bien que quelques applications écrivent directement, utmpje suppose que la source de vos problèmes réside dans la manière de sshdgérer la gestion des sessions.

Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?

utmpn'est généralement pas accessible en écriture et n'est pas censé l'être. utmpest écrit par des applications conçues pour vous connecter et configurer votre session. Dans votre cas, c'est le cas sshd.

Pourquoi sshd ne gère pas correctement votre utilisateur est très étrange car il devrait être copié correctement dans le nom d'hôte d'où vous venez. C'est là que les efforts de débogage devraient probablement être concentrés. Commencez par ajouter la sortie de débogage de sshd à vos journaux et voyez si quelque chose d'anormal se présente.

Si vous souhaitez contourner le problème (ou, peut-être même éventuellement en savoir plus sur le problème), vous pouvez l'utiliser pam_lastlogpour le gérer utmpen l'ajoutant à l' entrée de session dans /etc/pam.d/sshd.

En fait, cela ne fera pas de mal de vérifier s'il est déjà là - car pam_lastlogcontient une nohostoption qui expliquerait certainement votre comportement que vous rencontrez.

Enfin, vous ne pouviez pas utiliser du tout. aulastfait le même travail via le sous-système d'audit.

Cela pourrait valoir la peine d'essayer de voir si cela a réussi à au moins écrire la bonne adresse. Si ce n'est pas le cas, votre problème doit être avec sshd car sshd transmet les noms DNS autour de différents sous-systèmes comme utmp ou audit.


Pourriez-vous ajouter des instructions spécifiques sur la façon d'utiliser pam_lastlogcomme mentionné ci-dessus?
Mike Pennington

8

(1) Base sur la lastsortie OP

Après vous être connecté via ssh, on peut ssh vers localhost et obtenir 0.0.0.0 last -ipour la dernière.

Base sur les quatre premières lignes du journal 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/19la connexion était dans pts/17la période de connexion.

pts/17la connexion était dans pts/1 la période de connexion.

Pour cette occurrence spécifique, il est logique de deviner que OP ssh de 192.0.2.91 ( pty/1), puis dans cette session ssh, connectez-vous localement ( ssh localhost) au serveur à nouveau ( pts/17) et à nouveau ( pts/19).

Veuillez vérifier si ce chevauchement se produit avec une autre occurrence.

Ce qui suit peut aider à identifier la cause

  • Utilisez-vous ssh-key? Si oui, sur le serveur, avez-vous configuré ssh-key pour vous connecter localement?
  • Vérifiez ou affichez / var / log / secure du même laps de temps. Cela peut fournir un indice.
  • Vérifiez les scripts que vous utilisez
  • Vérifiez les alias de shell que vous utilisez
  • Vérifiez l'historique de vos commandes

(2) Secnario supplémentaire

Scénario 1 - Sudo et terminal

  1. UtilisateurA login X Window
  2. Ouvrez une fenêtre de terminal, faites xhost + localhost
  3. su - UserBou sudo su - UserBalors ouvrez un nouveau terminal (xterm, gnome-terminal, etc.)
  4. UserB apparaîtra comme 0.0.0.0 dans last -i

su - UserBne s'enregistrera pas en tant que UserBlogin en dernier, mais l'ouverture d'un terminal le fera.

Scénario 2 - connexion

  1. ssh dans le serveur
  2. type sudo login
  3. connectez-vous en tant que vous
  4. vérifier lastetlast -i

lastn'afficher aucun nom d'hôte ou IP pour le login session. last -iIP 0.0.0.0 pour le 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 réponse de Mife montre déjà un bloc de code de last.c. La raison pour laquelle le lastnom d'hôte / IP vide est dû ut_hostau fait que ces enregistrements sont en fait vides. Pour une structure wtmp complète, faites man wtmpsur n'importe quel système Linux.

Les 2 scénarios ici montrent que même les packages standard, dans certaines situations, les créent en tant que tels.

(3) Bash History Hack

Cela ne fonctionnera que si la session est utilisée bashcomme shell interactif.

.bashrcet .bash_profilene sont utilisés que par bash.

Ils ne seront pas fournis automatiquement si la session utilise un autre shell (sh, csh, etc.) ou exécute directement un programme, et il n'y aura pas non plus d'historique bash.

(4) Comptabilité des processus

Étant donné que OP ne mentionne rien au sujet du securefichier, je suppose que c'est une impasse et qu'il fournit actuellement un indice.

Si l'hypothèse suivante est correcte

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

auth.log (debian) / secure (CentOS) n'aidera pas. Comme seule l'action liée à l'authentification y est enregistrée.

wtmp / utmp, avec la limitation de leur structure de données, est également une impasse. Il n'y a aucune information sur ce qui les a créés.

Cela nous laisse avec une option, la comptabilité des processus . C'est un gros pistolet et doit être utilisé avec prudence.

  1. Peut-être contre la politique de l'entreprise
  2. D'autres utilisateurs sur un système partagé peuvent être mécontents / mal à l'aise avec l'activation
  3. Le fichier journal peut utiliser beaucoup d'espace disque. Gardez un œil sur le taux de croissance de la taille des fichiers.

La version du package psacct devrait être 6.3.2-56 ou supérieure, selon cet article .

Si celui-ci doit être utilisé et /var/logdispose d'un espace limité, remplacez le fichier journal acct par un répertoire (accès root uniquement) sous /home, qui a généralement beaucoup plus d'espace.

C'est vraiment le gros canon. Avec un taux d'occurrence de 10% OP, il devrait y avoir un résultat dans la semaine. Si pendant cette période, une entrée vide apparaît lastmais rien dans le journal des comptes, cela devient une situation mystérieuse et nécessiterait une action drastique .

Voici un exemple de sortie 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

Vous pouvez également utiliser «dump-acct» pour afficher plus d'informations.

PS1: J'ai essayé d'ouvrir quelques terminaux et session ssh. Il n'est pas clair (ou difficile à cerner) ce qui ouvre un nouveau pts. Cependant, il montre tout ce qui s'est déroulé dans ce pts / session.

PS2: un article de blog sur l'utilisation de acct par un Mike.


Je ne sais pas comment vous avez conclu qu'une connexion localhost donne 0.0.0.0, elle apparaît toujours comme localhost pour moi. Je me connecte uniquement avec ssh, je ne sais pas ce que vous entendez par connexion locale
Mike Pennington

Veuillez faire ssh localhostet vérifier last -i.
John Siu

Concernant login locally, je veux dire faire ssh localhostdans cette session ssh. J'ai modifié cette phrase, j'espère qu'elle est moins déroutante maintenant.
John Siu

Scénario supplémentaire ajouté.
John Siu

5

Lorsque vous vous connectez à une machine, il peut s'agir de quelques entrées dans la dernière commande.

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 première entrée avec tty * apparaît lorsque vous vous connectez via le terminal ou la console en appuyant sur CTRL + ALT + F1-6. C'est assez clair depuis le terminal qu'il utilise.

La deuxième entrée apparaît normalement lorsque vous vous connectez à une machine et ouvrez une fenêtre de terminal dans l'interface graphique. Il y aura également une entrée même si vous ouvrez un nouvel onglet dans la même fenêtre de terminal.

Le troisième type d'entrée survient lorsque vous ouvrez une session d'écran après vous être connecté via SSH. Cela créera également une entrée là-bas et sans aucune adresse IP.

La quatrième entrée est assez normale, ce que tout le monde comprend.

Si vous le faites last -iavec les entrées suivantes, vous verrez quelque chose comme ceci:

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)    

Je suis à peu près sûr que votre cas se présente dans l'un des 2 cas, l'un avec la fenêtre du terminal dans l'interface graphique et l'autre avec la session d'écran.

J'espère que cela a aidé.


2
Je n'ai pas utilisé l'interface graphique ou screenpour aucune des 0.0.0.0entrées. Je n'utilise l'interface graphique que lorsque j'ai installé les machines (vers août / septembre). Je vois de nombreuses 0.0.0.0entrées pts après cette heure.
Mike Pennington

1
cela a été vraiment utile et a dissipé quelques-uns des doutes vraiment anciens que j'avais
Rahul

3

Je ne pense pas que nous allons aller loin avec cela sans déboguer last.c, mais cela ne devrait pas être trop difficile car il se compile facilement ...

Une possibilité est cependant de vider le fichier / var / log / wtmp à l'aide de la commande utmpdump et de jeter un œil aux enregistrements bruts, cela peut vous éclairer. Sinon, veuillez publier une sortie pertinente de

utmpdump /var/log/wtmp 

afin que nous puissions recréer des copies locales de votre wtmp pour déboguer avec

utmpdump -r <dumpfile >wtmp

Cela peut sembler ne pas être une réponse, mais c'est vraiment le cas, nous avons dépassé le point où les gens le savent et ont vraiment besoin de déboguer.
user9517 pris en chargeGoFundMonica

C'est spécifique à l'environnement. J'exécute suffisamment de ces serveurs et je ne peux reproduire le comportement avec aucune combinaison d'activité normale.
ewwhite

@ewwhite: J'en ai aussi quelques-uns et je ne le trouve pas non plus.
user9517 pris en chargeGoFundMonica

@ewwhite J'ai essayé moi-même quelques machines CentOS et j'ai également demandé à certains collègues de maintenir environ 300 de ces boîtiers. Ils ne se souviennent pas non plus d'avoir vu cela auparavant.
Tonny

3

J'ai vérifié sur 12 serveurs d'applications multi-utilisateurs CentOS et RHEL 6.3. Aucun n'a montré ce comportement. Il n'y avait aucune entrée manquante dans la lastproduction remontant à 4-5 semaines.

Je pense qu'il serait important de voir votre /etc/hostsentrée de fichier pour vous assurer qu'elle est conforme à ce format .

Aussi, que faites-vous pour la résolution DNS? Pouvez-vous poster votre /etc/resolv.conf?

Les autres réponses indiquant que 0.0.0.0représente les connexions locales sont correctes. Les exemples typiques sont les événements de redémarrage et de connexion à la 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)    

Étant donné que cela ne semble se produire qu'avec les utilisateurs nommés, y a-t-il un changement, il y a quelque chose de génial à trouver ou à exécuter dans leurs scripts de connexion? Avez-vous changé ~/.bashrcou ~/.bash_profilepar défaut? Existe-t-il d'autres scripts de connexion spéciaux dans l'environnement?

--Éditer--

Je ne suis toujours pas en mesure de reproduire cela en aucune façon. Je regarde cependant deux composants critiques. La lastcommande est stable et n'a pas été modifiée depuis longtemps. En regardant le journal des modifications pour sysvinit-tools , il n'y a pas de bogues pertinents. Idem pour les scripts d' initiation (wtmp).

Si vous pouvez forcer cela à se produire, essayez-le avec un compte d'utilisateur différent des mêmes machines source. Mais je ne vois aucune indication qu'il s'agit d'un problème de système d'exploitation.


Concernant vos questions sur l'environnement local ... Veuillez consulter les dernières modifications apportées à ma question ... gardez à l'esprit qu'aucun autre utilisateur n'a ce problème à part moi ... donc les configurations globales (comme /etc/hosts) devraient affecter tout le monde ... pas juste moi
Mike Pennington

Il serait utile de savoir sur quelle période cela s'est produit. Votre extrait de journal date d'un mois. Est-ce reproductible? Cela se produit-il sur tous les serveurs? Peut-être que si le fichier wtmp a été tourné, vous pouvez avoir un wtmp et wtmp1. Pouvez-vous exécuter last -ifsur ces deux fichiers et voir si vous voyez les mêmes résultats au fil du temps?
ewwhite

De plus, exécutez-vous des commandes; (p) sftp (p) scp? Je vous le demande car vos sessions sans IP se produisent dans le délai d'une session plus longue. Dans votre exemple, étiez-vous en train d'ouvrir plusieurs connexions à partir de 192.0.2.91?
ewwhite

bonnes questions ... Je dois me préparer pour les invités qui arrivent aujourd'hui mais je m'efforcerai de répondre avec ces détails ce week
Mike Pennington

J'utilise parfois scp et sftp via le client WinSCP gratuit; cependant, ces entrées produisent des entrées valides /var/log/secure... les entrées qui 0.0.0.0montrent ne montrent rien/var/log/secure
Mike Pennington

3

RÉSOLUTION FINALE

J'ai déjà attribué le bonus, c'est donc uniquement pour les futurs googleurs avec la même question.

La raison pour laquelle cela n'apparaît que dans environ 10% de mes connexions est que lorsque j'apporte des modifications majeures à nos routeurs ou commutateurs, j'utilise script foo.logdonc j'ai un journal de terminal complet de la modification. Pour des raisons que je ne comprends toujours pas, CentOS crée une ptsentrée lorsque vous utilisez la scriptcommande ... Je vais montrer la sortie last -iavant et après l'exécution 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]$

Ce comportement semble être unique à CentOS 6 ... nous avons quelques machines CentOS 4.7 dans le laboratoire qui ne mettent pas d'entrée vide dans wtmp... Les machines Debian / Gentoo ne présentent pas ce comportement non plus. Nos administrateurs linux se grattent la tête pourquoi CentOS ajouterait intentionnellement une autre ptsentrée lorsque vous exécutez script... Je soupçonne que c'est un bogue RHEL.

EDIT : J'ai classé ce problème sous le numéro d'identification de bogue RHEL 892134

REMARQUE

Certaines personnes ont supposé à tort que je mettais scriptmon ~/.bashrcou ~/.bash_profile. C'est un argument erroné ... si c'était vrai, mon wtmpdevrait avoir une 0.0.0.0entrée après chacune de mes connexions 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)  # <-----

Bien sûr, ce n'était pas le cas ...


3
Vous n'avez pas mentionné que vous utilisiez la scriptcommande dans votre question initiale.
ewwhite

2
J'ai demandé Avez-vous modifié ~ / .bashrc ou ~ / .bash_profile par défaut? Existe-t-il d'autres scripts de connexion spéciaux dans l'environnement? . Le scriptprogramme fait une dactylographie de tout imprimé sur votre terminal. C'est un détail pertinent.
ewwhite

2
@ewwhite il est temps pour vous d'arrêter d'attaquer et de commencer à penser de manière critique ... 1) Vous supposez que le script était dans mon .bashrcou .bash_profileil ne l'était pas; J'exécute script foo.loglorsque j'apporte des modifications majeures pour pouvoir avoir un journal des modifications ... c'est-à-dire que cela n'affecte que ~ 10% de mes connexions 2) Si votre accusation est correcte (et ce n'est pas le cas), je n'aurais jamais de connexion ssh qui n'a pas eu une autre 0.0.0.0entrée juste après 3) scriptne fait que cela dans CentOS ... Je l'ai utilisé pendant plus d'une décennie et je n'ai jamais vu ce comportement dans une autre distribution ... à ce stade, je soutiens que c'est probablement un CentOS bug
Mike Pennington

1
Merci beaucoup pour la mise à jour. J'ai testé sur Ubuntu 12.04, scriptne bifurquerai qu'un shell. Sur la base de ce que vous montrez ici, la version CentOS / Redhat de scriptfork en fait d'abord un pty. Bien qu'un peu déçu (: P) que ce ne soit pas quelque chose de plus générique / à travers la distribution, au moins le mystère a disparu de mon esprit. PS: Je suis surpris que vous ayez Gentoo en production @. @
John Siu

1
@MikePennington: Il est également présent dans Fedora BTW, Michael Hampton vérifie pour moi.
user9517 pris en chargeGoFundMonica

2

Les connexions Pseudo Terminal Slave (pts) sont des connexions SSH ou telnet qui signifient des connexions indirectes au système. Toutes ces connexions peuvent se connecter à un shell qui vous permettra d'envoyer des commandes à l'ordinateur. Ainsi, lorsque vous ouvrez un terminal sur votre système à partir de l'interface graphique, cela ouvre un point avec l'ip source 0.0.0.0. D'après les informations fournies par vous, il semble que cela se produise en raison du script exécuté sur ce serveur ou planifié, qui utilise le service ssh ou telnet ou des points locaux pour lancer la sortie dans le terminal.


Je n'utilise jamais l'interface graphique
Mike Pennington

2

Quel client ssh utilisez-vous? Certains clients ssh peuvent multiplexer plusieurs terminaux sur une seule connexion et je remarque que toutes vos sessions sans IP se trouvent dans des sessions plus longues qui ont une IP enregistrée.

Je ne peux pas reproduire ce comportement avec ssh ici.


J'utilise habituellement superputty , actuellement sur la version 1.4.0.1 ... mais j'ai également vu ce problème avec du mastic uni
Mike Pennington

1

Peut-être que votre adresse IP se résout en une chaîne vide sur l'un de vos serveurs DNS, probablement le secondaire si cela ne se produit que 10% du temps (ou tout simplement un fichier d'hôtes si ceux-ci sont distribués à partir d'un référentiel central). Cela expliquerait l'entrée manquante (ou espace blanc) et serait cohérent avec la lecture de la source par Soham.


0

"0.0.0.0" signifie qu'il s'agit d'un utilisateur local (pas une connexion à distance), probablement invoqué par l'application, par exemple cronjob.


Cette réponse semble fausse ... toutes les entrées 0.0.0.0 dans mes journaux sont sur une ligne pts
Mike Pennington

C'est une bonne réponse, exemple de mon système:# 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)
alterpub

@alterpub, encore une fois, je ne me connecte qu'avec ssh; 0.0.0.0 n'est pas une entrée ssh pty valide à moins que quelqu'un ne puisse me montrer la documentation officielle autrement.
Mike Pennington

0

Cela se produit parce que vous utilisez le système local et que 0.0.0.0 signifie l'adresse IP de toutes les interfaces. Si vous pensez que quelqu'un a piraté, essayez de configurer la journalisation complète du shell, y compris les commandes via ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/


Que voulez-vous dire "vous utilisez le système local" ... veuillez lire ma question attentivement ... Je ne me connecte qu'avec ssh. Suggérez-vous que 0.0.0.0 est une entrée valide pour une connexion ssh à un pty?
Mike Pennington

-1

Je l'ai résolu en ajoutant un script à ~ / .bashrc, le script trouve la dernière adresse IP source de la connexion Telnet, puis vous pouvez ajouter l'IP à un fichier journal ou faire tout ce dont vous avez besoin ..

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


1
Cette réponse n'a pas beaucoup de sens pour moi. La discussion ne porte pas sur telnet. netstat -nae | grep 23n'est pas un moyen utile pour trouver des connexions Telnet. Cette commande donne 92 résultats sur mon système, aucun d'entre eux n'étant telnet.
Hauke ​​Laging
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.