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

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

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

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

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

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

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

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

utmpdump /var/log/wtmp 

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

utmpdump -r <dumpfile >wtmp

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

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

Причина, по которой это появляется только в ~ 10% моих входов в систему, состоит в том, что когда я вношу серьезные изменения в наши маршрутизаторы или коммутаторы, я использую скрипт foo.log , поэтому у меня есть полный журнал изменений в терминале. По причинам, которые я до сих пор не понимаю, CentOS создает запись pts , когда вы используете команду script ... Я продемонстрирую вывод last -i до и после запуска скрипта ...

[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 , когда вы выполняете скрипт ... Я подозреваю, что это ошибка RHEL.

EDIT : Я зарегистрировал эту проблему как идентификатор ошибки RHEL 892134

ПРИМЕЧАНИЕ

Некоторые люди ошибочно предположили, что я поместил скрипт в свой ~ / .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)  # <-----

Конечно, это было не так ...

ПРИМЕЧАНИЕ

Некоторые люди ошибочно предположили, что я поместил скрипт в свой ~ / .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)  # <-----

Конечно, это было не так ...

ПРИМЕЧАНИЕ

Некоторые люди ошибочно предположили, что я поместил скрипт в свой ~ / .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)  # <-----

Конечно, это было не так ...

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

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 со следующими записями, вы увидите что-то нравится:

(1) На основе OP последний вывод

После входа в систему через ssh можно использовать ssh на localhost и получить 0.0.0.0 в last -i для более позднего.

На основании первых четырех строк журнала 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 / 19 вход был в пределах pts / 17 периода входа.

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

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

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

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

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

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

Сценарий 1 - sudo и терминал

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

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

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

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

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

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

.bashrc и .bash_profile используются только bash ].

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

(4) Учет процессов

Поскольку OP ничего не упоминает о защищенном файле, я предполагаю, что это тупик, и он фактически дает подсказку.

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

`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 , в котором обычно гораздо больше места.

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

Ниже приводится пример вывода 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: Я попытался открыть несколько сеансов терминала и ssh. Непонятно (или непросто указать) что открыть новый оч.

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

Почему последний -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 или audit.

Мне это кажется совершенно загадочным. Либо он должен использовать какое-то 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.

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

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

 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)