Ich habe fünf CentOS 6-Linux-Systeme im Einsatz und ein ziemlich seltsames Problem ist bei meiner Benutzer-ID auf allen Linux-Systemen aufgetreten ... Dies ist ein Beispiel für das Problem bei Einträgen, die ich mit Ausnahme des lastBefehls ausgeführt habe. .

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)

Oben sehen Sie zwei meiner PTS-Anmeldeeinträge, denen keine Quell-IP-Adresse zugeordnet ist. Meine CentOS-Maschinen haben bis zu sechs andere Benutzer, die sich die Systeme teilen. Ungefähr 10% meiner Anmeldungen sehen dieses Problem, aber keine anderen Benutzernamen zeigen dieses Verhalten . Es ist kein Eintrag /var/log/securefür die Einträge ohne Quell-IP-Adresse vorhanden.

Fragen

Angesichts der Art von Skripten, die ich auf diesen Systemen verwende (die einen Großteil unserer Netzwerkinfrastruktur steuern), habe ich ein wenig Angst davor und würde gerne verstehen, was dazu führen würde, dass meine Anmeldungen gelegentlich Quelladressen verpassen.

• Warum funktioniert last -iShow 0.0.0.0für pts Zeileneinträge (siehe auch diese Antwort )
• Gibt es irgendetwas (außer böswilligen Aktivitäten), das das Verhalten angemessen erklärt?
• Gibt es außer der Zeitstempelung der Bash-Historie noch andere Möglichkeiten, um das Problem aufzuspüren?

Information

Seit dies passiert ist, habe ich die bashVerlaufszeitstempelung (dh HISTTIMEFORMAT="%y-%m-%d %T "in .bash_profile) aktiviert und auch einige andere Bash-Verlaufs-Hacks hinzugefügt . Dies gibt jedoch keinen Hinweis darauf, was während der vorherigen Vorkommnisse geschehen ist.

Alle Systeme laufen unter 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 ~]$

BEARBEITEN

Wenn ich benutze last -i mpenning, sehe ich Einträge wie diesen ...

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)

Hinweis für diejenigen, die versuchen zu antworten: Ich habe mich nicht mit dem screenBefehl oder der GUI angemeldet . Alle meine Logins stammen von SSH; die Prämie Auszeichnung zu erhalten, müssen Sie zitieren maßgebliche Referenzen , die erklären last -i 0.0.0.0Einträge nur über SSH bezogen.

EDIT 2 (für ewwhite's Fragen)

/etc/resolv.conf(Beachten Sie, dass ich .localoben in der lastAusgabe addrs verwendet habe , um die Informationen meines Unternehmens auszublenden.)

[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 (Beachten Sie, dass diese angepasste Hosts-Datei nur auf einem der Computer vorhanden ist, auf denen diese Probleme auftreten.)

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

sftpAusgabe von /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)

ENDGÜLTIGE ENTSCHLIESSUNG

Siehe meine Antwort unten

script Verhaltensunterschiede zwischen RedHat und Debian

Verknüpfte Bibliotheken

CentOS 6.3 - Skript (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 - Skript (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 auf Upstream - Quellcode , scriptvon beiden Versionen nicht öffnen neuen pty. Es folgt ein 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 scripthat ein neues Pkt eröffnet (2). Es wurde einfach nicht aktualisiert /var/log/wtmp.

CentOS 6

Ich überspringe den Test, da wir bereits wissen, dass scriptSie pty öffnen und sich bei wtmp registrieren.

libutemper

• Projekt: http://freecode.com/projects/libutempter
• Beschreibung: libutempter bietet eine Bibliotheksschnittstelle für Terminalemulatoren wie screen und xterm, um Benutzersitzungen in utmp- und wtmp-Dateien aufzuzeichnen.

Der Hauptunterschied scheint also die zusätzliche Bibliothek ( libutempter.so.0) zu sein, mit der CentOS scriptverbunden ist.

Test mit Ubuntu 12.04

Kompilieren scriptmit 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)

Testen

Vor dem Laufen 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

Innerhalb 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

Nach dem scriptEnde

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

Die Hauptursache für den leeren Hostnamen

Und ja, script.cerstelle den wtmpEintrag mit leerem Hostnamen. Betrachten Sie den folgenden Codeblock in util-linux-2.20.1/term-utils/script.cZeile: 245-247

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

Basis auf libutempter-1.1.5/utempter.h

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

Also script.cwird tatsächlich ein leerer Hostname übergeben utempter_add_record.

RedHat Backport

Das Interessante ist, Upstream unterstützt util-linux-ng-2.17.2eigentlich nicht libutempter. Anscheinend hat Redhat beschlossen, diese Unterstützung wieder hinzuzufügen.

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

Der obige Befehl gibt ein leeres Ergebnis zurück.

Fazit

Der Unterschied im Verhalten zwischen den beiden Distributionen ist also kein Fehler, sondern eine Wahl. RedHat entschied sich, dieses Feature zu unterstützen, während Debian es übersprang.

Das sieht für mich absolut rätselhaft aus. Entweder sollte ein DNS-Name oder eine IP-Adresse verwendet werden. Ich habe die last.cDatei ebenfalls überprüft, kann aber immer noch nicht feststellen, warum sie nichts anzeigt. Vermutlich kann ich nach einiger Zeit den Teil über 0.0.0.0 herausfinden.

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 }

Die beiden im Kontext verwendeten globalen Variablen sind diese.

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

Theoretisch sollte also entweder DNS oder IP verwendet werden.

Ich werde sehen, ob ich weiter graben kann. Aber was ewwhite gestellt hat, sind berechtigte Fragen.

Also habe ich zuletzt einen Debugger gestartet, der Ihnen hoffentlich zumindest einige Antworten auf Ihre Frage gibt. Mein Gefühl ist, dass die Grundursache tiefer liegt.

Warum zeigt last -i 0.0.0.0 für Pkt-Zeileneinträge an?

Der beste Weg , dies zu erklären ist , was passiert , wenn Sie dont -i übergeben.

Der Grund dafür ist in diesem Codeabschnitt von 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);
}

Beide usednsund useip(unter Verwendung der Standardoptionen) sind nicht markiert. Dies bewirkt , dass die Logik der Struktur kopieren aus , p->ut_hostdie nach man utmpdem Remote - Login - Namen enthält als aufgezeichnet von was auch immer in der schrieb utmp.

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

In Ihrem Fall ist der Wert hier Nullen. Aus diesem Grund wird Ihnen beim Ausführen lastnichts angezeigt.

In diesem Fall last -iwird dns_lookup aufgerufen. Dadurch wird der Eintrag (p-> ut_addr_v6) übergeben, der über DNS aufgelöst werden soll. In Ihrem Fall enthält dieser Wert auch Nullen.

Das meiste dns_lookupist Schaufensterdekoration und heusterisch. Grundsätzlich kommt es auf die Funktion an getnameinfo. Dies ist ein Bibliotheksaufruf, der in diesem Fall sein Bestes versucht, den in der gespeicherten Binärwert aufzulösen ut_addr_v6. Wenn dieser Eintrag Nullen enthält (wie in Ihrem Fall), lösen Sie dies 0.0.0.0wie bei Ihrer last -iAusgabe auf.

Gibt es irgendetwas (außer böswilligen Aktivitäten), das das Verhalten angemessen erklärt?

Nun, es ist wahrscheinlich ein Fehler oder ein Versehen. Sein unwahrscheinlich bösartig zu sein , da es dumm scheint zu verlassen jede eher Spur als Angreifer als eine Quelladresse weggelassen wird .

Bisher lag der Fokus der Antworten auf der falschen Stelle. lastliest gerade utmpoder wtmp. Es lasttut jedoch sein Bestes mit den Daten, die es hat.

Ihre Hauptursache liegt irgendwo in der Art und Weise, auf die utmpgeschrieben wird !

Während einige Anwendungen direkt in das Programm schreiben, liegt utmpdie Ursache Ihrer Probleme vermutlich in der Art und Weise, sshdwie Sie mit der Sitzungsverwaltung umgehen.

Gibt es außer der Zeitstempelung der Bash-Historie noch andere Möglichkeiten, um das Problem aufzuspüren?

utmpist normalerweise nicht beschreibbar und soll es auch nicht sein. utmpwird von Anwendungen geschrieben, mit denen Sie sich anmelden und Ihre Sitzung einrichten können. In deinem Fall ist das so sshd.

Warum sshd Ihren Benutzer nicht richtig behandelt, ist sehr seltsam, da es in den Hostnamen, von dem Sie gekommen sind, richtig kopiert werden sollte. Hier sollten wahrscheinlich die Debugging-Bemühungen konzentriert werden. Beginnen Sie mit dem Hinzufügen der Debug-Ausgabe von sshd zu Ihren Protokollen und prüfen Sie, ob Anomalien auftreten.

Wenn Sie das Problem umgehen möchten (oder vielleicht sogar mehr über das Problem erfahren möchten ), können Sie pam_lastloges verwalten, utmpindem Sie es dem Sitzungseintrag unter /etc/pam.d/sshd hinzufügen.

In der Tat tut es nicht weh, zu überprüfen, ob es bereits vorhanden ist - denn es pam_lastlogenthält eine nohostOption, die Ihr Verhalten definitiv erklären würde.

Letztendlich konnte man das überhaupt nicht nutzen. aulastübernimmt die gleiche Aufgabe über das Audit-Subsystem.

Könnte einen Versuch wert sein, um zu sehen, ob das geschafft hat, die korrekte Adresse mindestens zu schreiben. Wenn dies nicht der Fall ist, muss Ihr Problem bei sshd liegen, da sshd die DNS-Namen an verschiedene Subsysteme wie utmp oder audit weitergibt.

(1) Basis auf OP- lastAusgang

Nachdem Sie sich über ssh angemeldet haben, können Sie ssh an localhost senden und 0.0.0.0 last -ifür den späteren Zeitpunkt abrufen .

Basieren Sie auf den ersten vier Zeilen des OP-Protokolls

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/19Login war innerhalb des pts/17Login-Zeitraums.

pts/17Login war innerhalb des pts/1 Login-Zeitraums.

Für dieses spezielle Vorkommen ist es logisch zu erraten, dass sich OP ssh von 192.0.2.91 ( pty/1) aus und dann innerhalb dieser ssh-Sitzung lokal ( ssh localhost) erneut ( pts/17) und erneut ( pts/19) beim Server anmeldet .

Bitte überprüfen Sie, ob diese Überlappung mit einem anderen Vorkommen auftritt.

Folgendes kann helfen, die Ursache zu lokalisieren

• Benutzt du ssh-key? Wenn ja, haben Sie auf dem Server ssh-key eingerichtet, um sich lokal anzumelden?
• Überprüfe oder poste / var / log / secure im selben Zeitrahmen. Es kann einen Hinweis geben.
• Überprüfen Sie die von Ihnen verwendeten Skripte
• Überprüfen Sie die verwendeten Shell-Aliase
• Überprüfen Sie Ihren Befehlsverlauf

(2) Zusätzliches Secnario

Szenario 1 - Sudo und Terminal

1. UserA Login X-Fenster
2. Öffnen Sie ein Terminalfenster xhost + localhost
3. su - UserBoder sudo su - UserBdann öffne ein neues Terminal (xterm, gnome-terminal, etc)
4. UserB wird als 0.0.0.0 in angezeigt last -i

su - UserBwird sich nicht zuletzt als UserBLogin registrieren , sondern ein Terminal öffnen.

Szenario 2 - Anmeldung

1. SSH in Server
2. Art sudo login
3. Melden Sie sich als Sie selbst an
4. überprüfen lastundlast -i

lastzeigen keine Hostnamen oder IP für die login session. last -iwird IP 0.0.0.0 für die 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

Mife 's Antwort zeigt bereits den Codeblock von last.c. Der Grund für die lastAnzeige von leerem Hostnamen / IP ist, dass ut_hostdiese Datensätze tatsächlich leer sind. Für eine vollständige wtmp-Struktur verwenden Sie man wtmpein beliebiges Linux-System.

Die beiden hier gezeigten Szenarien zeigen, dass sogar Standardpakete sie unter bestimmten Umständen als solche erstellen.

(3) Bash History Hack

Dies funktioniert nur, wenn die Sitzung bashals interaktive Shell verwendet wird.

.bashrcund .bash_profilewerden nur von verwendet bash.

Sie werden nicht automatisch bezogen, wenn die Sitzung eine andere Shell (sh, csh usw.) verwendet oder ein Programm direkt ausführt, und es gibt auch keinen Bash-Verlauf.

(4) Prozessabrechnung

Da OP nichts über secureDatei erwähnt, gehe ich davon aus, dass das eine Sackgasse ist und es nun tatsächlich einen Hinweis gibt.

Wenn die folgende Annahme richtig ist

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

auth.log (debian) / secure (CentOS) wird nicht helfen. Da nur authentifizierungsbezogene Aktionen darin aufgezeichnet werden.

Auch wtmp / utmp ist mit seiner eingeschränkten Datenstruktur eine Sackgasse. Es gibt keine Informationen darüber, was sie geschaffen hat.

Damit haben wir eine Option: die Rechnungslegung . Dies ist eine große Waffe und muss mit Vorsicht eingesetzt werden.

1. Vielleicht gegen die Firmenpolitik
2. Andere Benutzer auf einem gemeinsam genutzten System sind möglicherweise mit der Aktivierung unzufrieden
3. Die Protokolldatei kann viel Speicherplatz belegen. Behalten Sie die Wachstumsrate der Dateigröße im Auge.

Die psacct-Paketversion sollte laut diesem Beitrag 6.3.2-56 oder höher sein .

Wenn dies verwendet werden soll und /var/logder Speicherplatz begrenzt ist, ändern Sie die ACCT-Protokolldatei in ein Verzeichnis (nur Root-Zugriff) /home, in dem normalerweise viel mehr Speicherplatz vorhanden ist.

Das ist wirklich die große Waffe. Bei einer OP-Häufigkeit von 10% sollte das Ergebnis innerhalb einer Woche vorliegen. Wenn während dieser Zeit zeigen leeren Eintrag nach oben in lastaber nichts von ACCT log, es werden Rätsel Situation , und würde einige erfordern drastische Maßnahmen .

Es folgt eine Beispielausgabe von 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

Sie können auch 'dump-acct' verwenden, um weitere Informationen anzuzeigen.

PS1: Ich habe versucht, ein paar Terminal- und SSH-Sitzungen zu eröffnen. Es ist nicht klar (oder nicht leicht zu sagen), was ein neues Pkt eröffnet. Es wird jedoch alles angezeigt, was in dieser Pkt / Sitzung ausgeführt wurde.

PS2: Ein Blogbeitrag über die Verwendung von acct von einem Mike.

Wenn Sie sich bei einem Computer anmelden, sind dies möglicherweise nur wenige Einträge im letzten Befehl.

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)    

Der erste Eintrag mit tty * kommt, wenn Sie sich über das Terminal oder die Konsole anmelden, indem Sie STRG + ALT + F1-6 drücken. Es ist ziemlich klar von dem Terminal, das es benutzt.

Der zweite Eintrag wird normalerweise angezeigt, wenn Sie sich bei einem Computer anmelden und ein Terminalfenster in der GUI öffnen. Es wird auch dann ein Eintrag angezeigt, wenn Sie im selben Terminalfenster einen neuen Tab öffnen.

Der dritte Eintragstyp tritt ein, wenn Sie eine Bildschirmsitzung öffnen, nachdem Sie sich über SSH angemeldet haben. Dadurch wird dort auch ein Eintrag ohne IP-Adresse erstellt.

Der vierte Eintrag ist ziemlich normal, was jeder versteht.

Wenn Sie last -imit den folgenden Einträgen arbeiten, sehen Sie so etwas:

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)    

Ich bin mir ziemlich sicher, dass Ihr Fall in einem der beiden Fälle untergeht, einer mit dem Terminalfenster in der GUI und der andere mit der Bildschirmsitzung.

Hoffe das hat geholfen.

Ich glaube nicht, dass wir damit weiterkommen werden, ohne last.c zu debuggen, aber das sollte nicht allzu schwer sein, da es sich leicht kompilieren lässt ...

Eine Möglichkeit besteht jedoch darin, die Datei / var / log / wtmp mit dem Befehl utmpdump zu sichern und sich die Rohdatensätze anzusehen, die Ihnen möglicherweise Aufschluss geben . Wenn nicht, posten Sie bitte eine relevante Ausgabe von

utmpdump /var/log/wtmp 

Damit können wir lokale Kopien Ihres wtmp zum Debuggen wiederherstellen

utmpdump -r <dumpfile >wtmp

Ich habe 12 auf CentOS und RHEL 6.3 basierende Anwendungsserver für mehrere Benutzer überprüft. Keiner zeigte dieses Verhalten. Es gab keine fehlenden Einträge in der lastAusgabe, die 4-5 Wochen zurückgingen.

Ich denke, es wäre wichtig, Ihren /etc/hostsDateieintrag zu sehen, um sicherzustellen, dass er diesem Format entspricht .

Was tun Sie auch für die DNS-Auflösung? Kannst du deine posten /etc/resolv.conf?

Die anderen Antworten, die angeben, dass 0.0.0.0lokale Verbindungen dargestellt werden, sind korrekt. Die typischen Beispiele sind Neustart- und Konsolenanmeldungsereignisse:

 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)    

Da dies nur bei namentlich genannten Benutzern auftritt, gibt es eine Änderung, bei der etwas Ungewöhnliches in ihren Anmeldeskripten gefunden oder ausgeführt wird? Haben Sie geändert ~/.bashrcoder ~/.bash_profilevon der Standardeinstellung? Gibt es andere spezielle Anmeldeskripte in der Umgebung?

--Bearbeiten--

Ich kann das immer noch nicht reproduzieren. Ich betrachte jedoch zwei kritische Komponenten. Der lastBefehl ist stabil und wurde seit langem nicht mehr geändert. Im Changelog für Sysvinit-Tools gibt es keine relevanten Fehler. Gleiches gilt für Initscripts (wtmp).

Wenn Sie dies erzwingen können, versuchen Sie es mit einem anderen Benutzerkonto auf denselben Quellcomputern. Aber ich sehe keinen Hinweis darauf, dass dies ein Betriebssystemproblem ist.

ENDGÜLTIGE ENTSCHLIESSUNG

Ich habe den Bonus bereits vergeben, das ist also nur für zukünftige Googler mit der gleichen Frage.

Der Grund, warum dies nur in ~ 10% meiner Anmeldungen vorkommt, ist, dass ich bei größeren Änderungen an unseren Routern oder Switches script foo.logein vollständiges Terminalprotokoll der Änderung verwende. Aus Gründen, die ich immer noch nicht verstehe, erstellt CentOS einen ptsEintrag, wenn Sie den scriptBefehl verwenden ... Ich werde die Ausgabe von last -ivor und nach dem Ausführen demonstrieren 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]$

Dieses Verhalten scheint für CentOS 6 einzigartig zu sein ... wir haben einige CentOS 4.7-Maschinen im Labor, die keinen leeren Eintrag in wtmp... setzen. Debian / Gentoo-Maschinen zeigen dieses Verhalten ebenfalls nicht. Unsere Linux-Administratoren kratzen sich am Kopf, warum CentOS ptsbei der Ausführung absichtlich einen weiteren Eintrag hinzufügt script... Ich vermute, dies ist ein RHEL-Fehler.

BEARBEITEN : Ich reichte dieses Problem als RHEL Bug-ID 892134 ein

HINWEIS

Einige Leute haben fälschlicherweise angenommen, dass ich scriptmein ~/.bashrcoder einfüge ~/.bash_profile. Dies ist ein fehlerhaftes Argument ... wenn das wahr ist, wtmpsollte ich 0.0.0.0nach jedem meiner SSH-Logins einen Eintrag haben ...

[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)  # <-----

Das war natürlich nicht der Fall ...

Pseudo Terminal Slave (pts) -Verbindungen sind SSH- oder Telnet-Verbindungen, dh indirekte Verbindungen zum System. Alle diese Verbindungen können mit einer Shell verbunden werden, über die Sie Befehle an den Computer senden können. Wenn Sie also ein Terminal auf Ihrem System von GUI aus öffnen, öffnet es ein PTS mit der Quell-IP-Adresse 0.0.0.0. Aus den von Ihnen bereitgestellten Informationen geht hervor, dass dies auf ein auf diesem Server ausgeführtes oder geplantes Skript zurückzuführen ist, das den ssh- oder Telnet-Dienst oder lokale Punkte verwendet, um die Ausgabe in das Terminal zu werfen.

Welchen ssh client benutzt du? Einige ssh-Clients können mehrere Terminals über eine Verbindung multiplexen, und ich stelle fest, dass alle Ihre Sitzungen ohne IP-Adresse in längere Sitzungen fallen, in denen eine IP-Adresse protokolliert ist.

Ich kann dieses Verhalten mit ssh hier nicht duplizieren.

Möglicherweise wird Ihre IP-Adresse in eine leere Zeichenfolge auf einem Ihrer DNS-Server aufgelöst, wahrscheinlich die sekundäre, wenn sie nur zu 10 Prozent der Zeit auftritt (oder möglicherweise eine Hostdatei, wenn diese von einem zentralen Repository verteilt wird). Das würde den fehlenden (oder Leerzeichen-) Eintrag erklären und mit Sohams Lesart der Quelle übereinstimmen.

"0.0.0.0" bedeutet, dass es sich um einen lokalen Benutzer handelt (kein Remote-Login), der wahrscheinlich von einer Anwendung, z. B. Cronjob, aufgerufen wird.

Dies liegt daran, dass Sie ein lokales System verwenden und 0.0.0.0 die IP-Adresse aller Schnittstellen bedeutet. Wenn Sie glauben, dass jemand etwas gehackt hat, versuchen Sie, die vollständige Protokollierung der Shell einschließlich der Befehle über ssh einzurichten - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Ich habe es gelöst, indem ich ein Skript zu ~ / .bashrc hinzugefügt habe. Das Skript findet die letzte IP-Adresse der Telnet-Verbindungsquelle. Dann können Sie die IP zu einer Protokolldatei hinzufügen oder tun, was immer Sie benötigen.

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