Это выглядит абсолютно загадочным для меня. Либо он должен использовать DNS-имя или IP-адрес. Я проверил last.c файл также, но я до сих пор не могу найти, почему он ничего не показывает. Вероятно, по прошествии некоторого времени я смогу разобраться в части о 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 }

Вот две глобальные переменные, используемые в контексте:

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

Таким образом, теоретически, он должен использовать DNS или IP.

Я посмотрю, смогу ли я копать что-нибудь дальше. Но то, что спросили, это правильные вопросы.

(1) База на ОП last выход

После входа в систему через ssh можно войти в ssh на локальный хост и получить 0.0.0.0 в last -i на потом.

База на первых четырех строках журнала ОП

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/19 вход был в пределах pts/17 период входа.

pts/17 вход был в пределах pts/1 период входа.

Для этого конкретного случая логично предположить, что OP ssh из 192.0.2.91 (pty/1), затем в этом сеансе SSH, войдите в систему локально (ssh localhost снова на сервер (pts/17), и опять(pts/19).

Пожалуйста, проверьте, не происходит ли это совпадение с другим случаем.

Следующее может помочь определить причину

• Вы используете SSH-ключ? Если да, то на сервере вы настроили ssh-key для локального входа?
• Проверьте или отправьте /var/log/secure того же периода времени. Это может дать намек.
• Проверьте скрипты, которые вы используете
• Проверьте псевдонимы оболочки, которые вы используете
• Проверьте историю команд

(2) Дополнительный Secnario

Сценарий 1 - судо и терминал

1. UserA логин X Window
2. Откройте терминал windows, сделайте xhost + localhost
3. su - UserB или же sudo su - UserB затем откройте новый терминал (xterm, gnome-терминал и т. д.)
4. UserB будет отображаться как 0.0.0.0 в last -i

su - UserB не будет регистрироваться как UserB войдите в систему последним, но открытие терминала будет.

Сценарий 2 - вход

1. SSH на сервер
2. тип sudo login
3. войдите под своим именем
4. проверять last а также last -i

last не показывать имя хоста или IP для login session, last -i будет IP 0.0.0.0 для 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 уже показывает блок кода last.c, Причина last отображать пустое имя хоста /IP потому что ut_host для этих записей на самом деле пусто. Для полной структуры wtmp, сделайте man wtmp в любой системе Linux.

2 сценария показывают, что даже стандартные пакеты в определенных ситуациях создают их как таковые.

(3) Взломать историю Bash

Это будет работать только при использовании сеанса bash как интерактивная оболочка.

.bashrc а также .bash_profile используются только bash,

Они не будут получены автоматически, если сессия использует какую-либо другую оболочку (sh, csh и т. Д.) Или выполнит программу напрямую, и истории bash также не будет.

(4) Процесс учета

С ОП ничего не говорится о secure файл, я буду считать, что это тупик, и он на самом деле предоставить сейчас подсказку.

Если следующее предположение верно

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

auth.log(debian)/secure(CentOS) не поможет. Поскольку в нем записано только действие, связанное с аутентификацией.

wtmp / utmp, с ограничением в их структуре данных, также является тупиком. Нет информации о том, что их создало.

Это оставляет нас с одним вариантом, процесс учета. Это большой пистолет, и его следует использовать с осторожностью.

1. Может быть, против политики компании
2. Другие пользователи в общей системе могут быть недовольны / неудобны, если она включена
3. Файл журнала может занимать много места на диске. Следите за скоростью роста размера файла.

Версия пакета psacct должна быть 6.3.2-56 или выше, согласно этому посту.

Если это будет использоваться, и /var/log имеет ограниченное пространство, измените файл журнала acct на каталог (доступ только root) в /home, который обычно имеет гораздо больше места.

Это действительно большой пистолет. При ОП 10% частота должна быть в течение недели. Если в течение этого периода пустая запись появится в last но ничего из журнала действий, это стало загадочной ситуацией и потребовало бы каких-то решительных действий.

Ниже приведен пример вывода 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

Вы также можете использовать "dump-acct", чтобы показать больше информации.

PS1: я пытался открыть несколько терминалов и ссх сессии. Непонятно (или не просто указать точку), что открывают новые очки. Тем не менее, он показывает все, что выполнялось в этом сеансе.

PS2: сообщение в блоге об использовании acct Майком.

Так что я побежал последним в отладчике, который, надеюсь, даст вам хотя бы несколько ответов на ваш вопрос. Мое чувство коренная причина, хотя глубже.

Почему последний -i показывает 0.0.0.0 для записей строки pts

Лучший способ объяснить это то, что происходит, когда вы не передаете -i.

Причина этого в этом разделе кода 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);
}

И то и другое usedns а также useip (с использованием параметров по умолчанию) не помечены. Это заставляет логику копировать из структуры p->ut_host который согласно man utmp содержит имя для удаленного входа в систему, записанное тем, кто записал utmp,

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

В вашем случае значение здесь равно нулю. Вот почему, когда вы бежите last ничего не появляется для вас.

В случае last -i тогда вызывается dns_lookup. Это передаст запись (p->ut_addr_v6) для разрешения через DNS. В вашем случае это значение также содержит нули.

Большинство dns_lookup это оформление витрин и шутка. В основном важна функция getnameinfo, Это библиотечный вызов, который в этом случае будет стараться разрешить двоичное значение, хранящееся в ut_addr_v6, Когда эта запись содержит нули (например, в вашем случае), вы фактически решаете это как 0.0.0.0 как это происходит с вашим last -i выход.

Есть ли что-нибудь (кроме злонамеренной деятельности), которое разумно объясняет поведение?

Ну, это, наверное, ошибка или недосмотр. Маловероятно, что это будет злонамеренно, поскольку кажется глупым оставлять какой-либо след в качестве злоумышленника, а не опускать адрес источника

До сих пор в центре внимания находились не в том месте. last просто читает utmp или же wtmp, тем не мение last делает все возможное с данными, которые у него есть.

Ваша коренная причина лежит где-то в манере, к которой utmp пишется!

Хотя несколько приложений напрямую пишут в utmp Я думаю, источник ваших проблем лежит на пути sshd обрабатывает управление сеансом.

Кроме метки времени в истории bash, есть ли другие способы, которые я могу сделать, чтобы отследить проблему?

utmp обычно не доступен для записи и не предназначен для этого. utmp написано приложениями, предназначенными для входа в систему и настройки сеанса. В вашем случае это sshd,

Почему sshd не обрабатывает вашего пользователя должным образом, очень странно, так как он должен правильно копировать имя хоста, с которого вы пришли. Вот где усилия по отладке, вероятно, должны быть сосредоточены. Начните с добавления отладочных выходных данных sshd в ваши журналы и посмотрите, не возникнет ли что-то аномальное.

Если вы хотите обойти проблему (или, возможно, даже узнать больше о проблеме), вы можете использовать pam_lastlog управлять utmp добавив его в запись сеанса в /etc/pam.d/sshd.

На самом деле это не помешает проверить, если он уже там - потому что pam_lastlog содержит nohost вариант, который определенно объяснит ваше поведение, которое вы испытываете.

Наконец, вы не могли использовать последний вообще. aulast выполняет ту же работу через подсистему аудита.

Возможно, стоит попробовать проверить, удалось ли хотя бы написать правильный адрес. Если это не так, то ваша проблема должна быть с sshd, так как sshd передает DNS-имена различным подсистемам, таким как utmp или аудит.

Когда вы входите в систему, это может быть несколько записей в последней команде.

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)    

Первая запись с tty* появляется, когда вы входите через терминал или консоль, нажимая CTRL+ALT+F1-6. Это довольно ясно из терминала, который он использует.

Вторая запись обычно появляется, когда вы входите в систему и открываете окно терминала в графическом интерфейсе. Также будет запись, даже если вы откроете новую вкладку в том же окне терминала.

Третий тип ввода происходит, когда вы открываете сеанс экрана после входа в систему через SSH. Это также создаст запись там и без какого-либо IP-адреса.

Четвертая запись вполне нормальна, и все это понимают.

Если вы делаете last -i со следующими записями вы увидите что-то вроде этого:

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)    

Я почти уверен, что ваш случай подходит к любому из двух случаев: один с окном терминала в GUI, а другой с сеансом экрана.

Надеюсь, что это помогло.

Я проверил 12 многопользовательских серверов приложений CentOS и RHEL 6.3. Никто не демонстрировал это поведение. Там не было пропущенных записей в last Выход вернется на 4-5 недель.

Я думаю, что было бы важно увидеть ваши /etc/hosts запись файла, чтобы убедиться, что он соответствует этому формату.

Кроме того, что вы делаете для разрешения DNS? Вы можете опубликовать свой /etc/resolv.conf?

Другие ответы, указывающие, что 0.0.0.0 Представляет, что локальные соединения верны. Типичными примерами являются события перезагрузки и входа в консоль:

 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)    

Так как это происходит только с именованными пользователями, есть ли какое-то изменение, что происходит что-то необычное или запускается в их сценариях входа? Ты изменился ~/.bashrc или же ~/.bash_profile по умолчанию? Существуют ли другие специальные сценарии входа в среду?

--Редактировать--

Я все еще не могу воспроизвести это каким-либо образом. Я смотрю на два критических компонента, хотя. last Команда стабильна и не менялась долгое время. Если посмотреть на журнал изменений для sysvinit-tools, то здесь нет соответствующих ошибок. То же самое для начальных букв (wtmp).

Если вы можете заставить это произойти, попробуйте это с другой учетной записью пользователя из тех же исходных компьютеров. Но я не вижу никаких признаков того, что это проблема ОС.

ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ

Я уже присудил бонус, так что это чисто для будущих гуглеров с таким же вопросом.

Причина, по которой это появляется только в ~10% моих входов в систему, заключается в том, что когда я делаю серьезные изменения в наших маршрутизаторах или коммутаторах, я использую script foo.log поэтому у меня есть полный журнал регистрации изменений. По причинам, которые я до сих пор не понимаю, CentOS создает pts запись при использовании script команда... я продемонстрирую вывод last -i до и после бега 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]$

Такое поведение кажется уникальным для CentOS 6... у нас в лаборатории есть машины CentOS 4.7, которые не помещают пустую запись в wtmp... Машины Debian / Gentoo такого поведения также не демонстрируют. Наши администраторы linux ломают голову, почему CentOS намеренно добавил еще pts запись при исполнении script... Я подозреваю, что это ошибка RHEL.

РЕДАКТИРОВАТЬ: я подал эту проблему как идентификатор ошибки RHEL 892134

НОТА

Некоторые люди ошибочно предположили, что я положил script в моем ~/.bashrc или же ~/.bash_profile, Это неверный аргумент... если бы это было правдой, мой wtmp должен иметь 0.0.0.0 запись после каждого из моих логинов 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)  # <-----

Конечно, это был не тот случай...

Я не думаю, что мы доберемся до этого без отладки last.c, но это не должно быть слишком сложно, так как он легко компилируется...

Одна из возможностей, однако, - выгрузить файл /var/log/wtmp с помощью команды utmpdump и взглянуть на необработанные записи, которые могут пролить свет на вас. Если нет, пожалуйста, опубликуйте соответствующий вывод

utmpdump /var/log/wtmp 

так что мы можем воссоздать локальные копии вашего wtmp для отладки с

utmpdump -r <dumpfile >wtmp

Соединения псевдотерминала Slave (pts) - это соединения SSH или telnet, что означает косвенные соединения с системой. Все эти соединения могут подключаться к оболочке, которая позволит вам подавать команды на компьютер. Поэтому, когда вы открываете терминал в вашей системе из графического интерфейса, он открывает pts с исходным IP-адресом 0.0.0.0. Из предоставленной вами информации кажется, что это происходит из-за запуска сценария на этом сервере или по расписанию, который использует службу ssh или telnet или локальные точки для выдачи вывода в терминал.

Какой SSH-клиент вы используете? Некоторые клиенты ssh могут мультиплексировать несколько терминалов по одному соединению, и я замечаю, что все ваши сеансы без IP попадают в более длинные сеансы, которые имеют зарегистрированный IP.

Я не могу продублировать это поведение с помощью ssh.

Возможно, ваш IP-адрес преобразуется в пустую строку на одном из ваших DNS-серверов, возможно, вторичную, если это происходит только в 10% случаев (или, возможно, просто в файл hosts, если они распространяются из центрального хранилища). Это объясняет отсутствующую (или пробел) запись и согласуется с прочтением Сохемом источника.

Это происходит потому, что вы используете локальную систему, а 0.0.0.0 означает IP-адрес всех интерфейсов. Если вы думаете, что, возможно, кто-то взломал, вы попытаетесь настроить полную регистрацию оболочки, включая команды через ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

"0.0.0.0" означает, что это локальный пользователь (не удаленный вход в систему), вероятно, вызванный приложением, например, cronjob.

Я решил это, добавив скрипт в ~/.bashrc, скрипт находит последний IP-адрес источника соединения telnet, затем вы можете добавить IP в файл журнала или сделать все, что вам нужно..

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