Cela me semble absolument déconcertant. Soit cela devrait utiliser un nom DNS ou une adresse IP. J'ai également vérifié le fichier last.c mais je ne trouve toujours pas pourquoi il ne montre rien. Probablement en donnant un peu de temps, je pourrai comprendre la partie concernant 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 ce contexte sont les suivantes.

int usedns = 0;     /* Utiliser DNS pour rechercher le nom d'hôte. */
72 int useip = 0;       /* Imprimer l'adresse IP au format numérique */

Donc, en théorie, cela devrait utiliser soit le dns ou IP.

Je verrai si je peux trouver quelque chose de plus profond. Mais ce que ewwhite a demandé sont des questions valides.

(1) Base on OP dernier résultat

Après s'être connecté via ssh, on peut ssh vers localhost et obtenir 0.0.0.0 dans dernier -i pour la suite.

Base sur les quatre premières lignes du journal de l'OP

mpenning pts/19                        ven nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        ven nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   ven nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       ven nov 16 10:17 - 10:49 (12+00:31)

pts/19 connexion été faite pendant la période de connexion de pts/17.

La connexion de pts/17 été faite pendant la période de connexion de pts/1.

Pour cette occurrence spécifique, il est logique de supposer que l'OP a ssh à partir de 192.0.2.91 (pty/1), puis à l'intérieur cette session ssh, s'est connecté localement (ssh localhost) au serveur à nouveau (pts/17), et à nouveau (pts/19).

Veuillez vérifier si ce chevauchement se produit avec d'autres occurrences.

Les éléments suivants peuvent aider à trouver la cause

• Utilisez-vous une clé ssh? Si oui, sur le serveur, avez-vous configuré la clé ssh pour vous connecter localement?
• Vérifiez ou postez /var/log/secure de la même période. Cela pourrait fournir quelques indications.
• Vérifiez les scripts que vous utilisez
• Vérifiez les alias de shell que vous utilisez
• Vérifiez votre historique de commandes

(2) Scénario supplémentaire

Scénario 1 - sudo et terminal

1. UtilisateurA se connecte à WindowX
2. Ouvrez une fenêtre de terminal, faites xhost + localhost
3. su - UtilisateurB ou sudo su - UtilisateurB puis ouvrez un nouveau terminal (xterm, gnome-terminal, etc)
4. UtilisateurB apparaîtra comme 0.0.0.0 dans dernier -i

su - UtilisateurB ne sera pas enregistré en tant que connexion UtilisateurB dans dernier, mais l'ouverture d'un terminal le sera.

Scénario 2 - connexion

1. ssh dans le serveur
2. tapez sudo login
3. connectez-vous en tant que vous-même
4. vérifiez dernier et dernier -i

dernier ne montre pas de nom d'hôte ou d'IP pour la session de connexion. dernier -i affichera IP 0.0.0.0 pour la session de connexion.

john@U64D211:~$ dernier -5
john     pts/0                         dim déc 23 20:50   toujours connecté   
john     pts/0                         dim déc 23 20:50 - 20:50  (00:00)    
john     pts/0        :0               dim déc 23 20:50 - 20:50  (00:00)    
reboot   démarrage système  3.2.0-35-générique dim déc 23 20:49 - 20:50  (00:01)    
john     pts/2        js.example.com   dim déc 23 17:14 - crash  (03:34)    

wtmp commence sam déc  1 06:30:46 2012
john@U64D211:~$ dernier -5i
john     pts/0        0.0.0.0          dim déc 23 20:50   toujours connecté   
john     pts/0        0.0.0.0          dim déc 23 20:50 - 20:50  (00:00)    
john     pts/0        0.0.0.0          dim déc 23 20:50 - 20:50  (00:00)    
reboot   démarrage système  0.0.0.0          dim déc 23 20:49 - 20:50  (00:01)    
john     pts/2        192.168.1.90     dim déc 23 17:14 - crash  (03:34)    

wtmp commence sam déc  1 06:30:46 2012

La réponse de Mife montre déjà un bloc de code de dernier.c. La raison pour laquelle dernier affiche un nom d'hôte/IP vide est que ut_host pour ces enregistrements est en fait vide. Pour obtenir la structure complète de wtmp, faites man wtmp sur n'importe quel système linux.

Les 2 scénarios ici montrent que, même avec des paquets standards, dans certaines situations, ils sont créés de cette façon.

(3) Piratage de l'historique de bash

Cela ne fonctionnera que si la session utilise bash comme shell interactif.

.bashrc et .bash_profile sont uniquement utilisés par bash.

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

(4) Décompte des processus

Puisque l'OP n'a mentionné rien concernant le fichier sécurisé, je vais supposer que c'est une impasse et qu'il ne fournit en réalité aucune indication.

Si l'hypothèse suivante est correcte

les entrées 0.0.0.0 de `dernier` sont effectivement créées dans la propre session de l'OP

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

wtmp/utmp, avec les limitations 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 seule option, le décompte des processus. C'est un gros calibre et doit être utilisé avec prudence.

1. Peut-être contraire à la politique de l'entreprise
2. D'autres utilisateurs sur un système partagé pourraient être mécontents/mal à l'aise s'il est activé
3. Le fichier journal peut utiliser beaucoup d'espace disque. Surveillez le taux de croissance de la taille du fichier.

La version du paquet psacct doit être 6.3.2-56 ou supérieure, selon ce post.

Si cela doit être utilisé, et que /var/log a un espace limité, changez le fichier journal de comptabilité vers un répertoire (à accès uniquement par root) sous /home, qui a généralement beaucoup plus d'espace.

C'est vraiment le gros calibre. Avec un taux d'occurrence de 10% pour l'OP, il devrait y avoir des résultats dans une semaine. Si, pendant cette période, des entrées vides apparaissent dans dernier mais rien provenant du journal de comptabilité, cela devient une situation mystère, et nécessiterait des actions drastiques.

Voici un exemple de sortie de derniercomm

lesspipe               john     pts/8      0.02 secs lun déc 24 17:10
lesspipe          F    john     pts/8      0.00 secs lun déc 24 17:10
dirname                john     pts/8      0.00 secs lun déc 24 17:10
basename               john     pts/8      0.00 secs lun déc 24 17:10
kworker/1:2       F    root     __         0.00 secs lun déc 24 16:54
tty                    john     pts/6      0.01 secs lun déc 24 17:09
tty                    john     pts/4      0.01 secs lun déc 24 17:09
cron              F    root     __         0.05 secs lun déc 24 17:09
sh               S     root     __         0.01 secs lun déc 24 17:09
find                   root     __         0.01 secs lun déc 24 17:09
maxlifetime            root     __         0.00 secs lun déc 24 17:09
php5                   root     __         0.23 secs lun déc 24 17:09
which                  root     __         0.00 secs lun déc 24 17:09
lastcomm               root     pts/0      0.01 secs lun déc 24 17:08
tty                    john     pts/1      0.01 secs lun déc 24 17:08
dconf worker         X john     __         5.46 secs lun déc 24 16:58
lastcomm               root     pts/7      0.04 secs lun déc 24 17:05
mesg             S     root     pts/7      0.00 secs lun déc 24 17:05
bash              F    root     pts/7      0.00 secs lun déc 24 17:05
dircolors              root     pts/7      0.00 secs lun déc 24 17:05

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

PS1: J'ai essayé d'ouvrir quelques terminaux et sessions ssh. Il n'est pas clair (ou pas facile à déterminer) ce qui a ouvert un nouveau pts. Cependant, cela montre tout ce qui s'est exécuté dans ce pts/session.

PS2: Un article de blog sur l'utilisation de la comptabilité par un certain Mike.

Alors j'ai exécuté en dernier recours dans un débogueur qui, je l'espère, vous donnera au moins quelques réponses à votre question. J'ai le sentiment que la cause initiale est plus profonde.

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

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

La raison de cela se trouve dans cette section du 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 usedns et useip (en utilisant les options par défaut) ne sont pas activées. Cela provoque la logique de copier à partir de la struct p->ut_host qui, selon man utmp, contient le nom de connexion distant tel qu'enregistré par ce qui a écrit dans le utmp.

char ut_host[UT_HOSTSIZE]; /* Nom d'hôte pour la connexion distante, ou
                              la version du noyau pour les messages de niveau d'exécution
                              */

Dans votre cas, la valeur ici est de zéros. C'est pourquoi lorsque vous exécutez last, rien n'apparaît pour vous.

Dans le cas de last -i, la fonction dns_lookup est alors invoquée. Cela va transmettre l'entrée (p->ut_addr_v6) à résoudre via DNS. Dans votre cas, cette valeur contient également des zéros.

La plupart de dns_lookup n'est que du vernis et de l'heuristique. Fondamentalement, ce qui importe est la fonction getnameinfo. Il s'agit d'un appel de bibliothèque qui, dans ce cas, va faire 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 en fait cela en 0.0.0.0 comme c'est le cas avec votre sortie last -i.

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

Eh bien, il s'agit probablement d'un bug ou d'un oubli. Il est peu probable que ce soit malveillant car il semble stupide de laisser toute 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. last lit simplement utmp ou wtmp. Cependant, last fait de son mieux avec les données qu'il a.

Votre cause première se situe quelque part dans la manière dont utmp est écrit!

Alors que quelques applications écrivent directement dans utmp, je suppose que la source de vos problèmes réside dans la façon dont sshd gère la gestion de session.

À part l'historique des commandes bash, y a-t-il d'autres choses que je peux faire pour suivre le problème?

utmp n'est généralement pas inscriptible et ce n'est pas son but. utmp est écrit par des applications conçues pour vous connecter et configurer votre session. Dans votre cas, c'est sshd.

Pourquoi sshd ne gère pas correctement votre utilisateur est très étrange car il devrait copier correctement le nom d'hôte à partir duquel vous êtes venu. C'est là que les efforts de débogage devraient probablement être concentrés. Commencez par ajouter une sortie de débogage de sshd dans vos journaux et voyez s'il y a quelque chose d'anormal qui remonte.

Si vous voulez contourner le problème (ou, peut-être même éventuellement découvrir plus sur le problème), vous pouvez utiliser pam_lastlog pour gérer utmp en l'ajoutant à l'entrée session de /etc/pam.d/sshd.

En fait, il ne serait pas inutile de vérifier s'il est déjà là — car pam_lastlog contient une option nohost qui expliquerait sûrement le comportement que vous rencontrez.

Enfin, vous pourriez ne pas utiliser last du tout. aulast fait le même travail via le sous-système d'audit.

Il pourrait être utile d'essayer pour voir si cela a réussi à écrire l'adresse correcte. Si ce n'est pas le cas, votre problème doit se situer au niveau de sshd car sshd transmet les noms DNS autour de différents sous-systèmes comme utmp ou audit.

Lorsque vous vous connectez à une machine, voici quelques entrées possibles dans la dernière commande.

geekride   tty2                        ven 21 déc 15:45 - 15:45  (00:00)    
geekride   pts/1                       ven 21 déc 13:45   encore connecté   
geekride   pts/1        :pts/0:S.0     jeu  6 déc 12:49 - 00:40  (11:50)    
geekride   pts/1        10.31.33.47    jeu  6 déc 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. Cela est assez clair en utilisant le terminal.

La deuxième entrée apparaît normalement lorsque vous vous connectez à une machine et ouvrez une fenêtre de terminal en GUI. 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 apparaît lorsque vous ouvrez une session d'écran après vous être connecté via SSH. Cela crée également une entrée sans adresse IP.

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

Si vous effectuez last -i avec les entrées suivantes, vous verrez quelque chose comme ceci :

geekride   tty2         0.0.0.0        ven 21 déc 15:45 - 15:45  (00:00)    
geekride   pts/9        0.0.0.0        ven 21 déc 13:45   encore connecté   
geekride   pts/1        0.0.0.0        jeu  6 déc 12:49 - 00:40  (11:50)    

Je suis assez sûr que votre cas correspond à l'un des 2 cas, soit avec la fenêtre de terminal en GUI, soit avec la session d'écran.

J'espère que cela vous a aidé.