У мене є п’ять систем Linux Linux CentOS 6 на роботі, і я стикався з досить дивною проблемою, яка, здається, трапляється лише з моїм користувачем Userid у всіх системах Linux, які у мене є ... Це приклад проблеми із записів, які я виключив з lastкоманди. .

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)

Ви можете побачити дві мої записи входу в pts, які не мають пов’язаної з ними вихідної IP-адреси. Мої машини CentOS мають аж шість інших користувачів, які діляться системами. Приблизно 10% моїх логінів бачать цю проблему, але жодна інша ім’я користувача не демонструє такої поведінки . Немає даних /var/log/secureдля записів без вихідної IP-адреси.

Запитання

З огляду на тип сценаріїв, які я зберігаю в цих системах (які контролюють велику частину нашої мережевої інфраструктури), я трохи збентежений цим і хотів би зрозуміти, що може призвести до того, що мої входи час від часу пропускають адреси джерел.

• Чому last -iвідображається запис 0.0.0.0у рядку балів (також див. Цю відповідь )
• Чи є щось (окрім шкідливої ​​діяльності), що б розумно пояснювало поведінку?
• Окрім часової позначки історії басу, чи є інші речі, які я можу зробити, щоб відстежити проблему?

Інформаційні

Оскільки це почалося, я ввімкнув bashхроніку часу (тобто HISTTIMEFORMAT="%y-%m-%d %T "в .bash_profile), а також додав кілька інших хакерських історій ; однак це не дає підказки до того, що сталося під час попередніх подій.

У всіх системах працює 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 ~]$

EDIT

Якщо я використовую last -i mpenning, я бачу такі записи, як ця ...

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)

Примітка для тих, хто намагається відповісти: Я не ввійшов у систему за допомогою screenкоманди чи GUI . Усі мої реєстрації від SSH; щоб отримати нагороду за нагороду, ви повинні навести авторитетні посилання, щоб пояснити last -i 0.0.0.0записи, отримані лише через SSH.

EDIT 2 (для запитань ewwhite)

/etc/resolv.conf(зауважте, що я використовував .localдобавки у lastвихідному даних вище, щоб приховати інформацію про свою компанію)

[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 інформація (зауважте, що цей налаштований файл хостів існує лише на одній із машин, у яких є ці проблеми)

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

sftpВихід від /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)

Заключне рішення

Дивіться мою відповідь нижче

script відмінності в поведінці між RedHat та Debian

Пов'язані бібліотеки

CentOS 6.3 - скрипт (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 - скрипт (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

Базуючись на вихідному вихідному коді , scriptз обох версій відкриваються нові pty. Далі йде тест.

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 scriptвідкрив новий pts (2). Він просто не оновлювався/var/log/wtmp .

CentOS 6

Я пропускаю тест, оскільки ми вже знаємо, що scriptроблять open pty та реєструються з wtmp.

лібутемпер

• Проект: http://freecode.com/projects/libutempter
• Опис: libutempter надає бібліотечний інтерфейс для емуляторів терміналів, таких як екран та xterm для запису сеансів користувача для utmp та wtmp файлів.

Отже, головна відмінність - це додаткова бібліотека ( libutempter.so.0), з якою scriptпов'язаний CentOS .

Тест з Ubuntu 12.04

Складання за scriptдопомогою лібутемпера

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)

Тестування

Перед бігом 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

У межах 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

Після 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/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

Першопричина порожнього імені хоста

І так, script.cстворіть wtmpзапис із порожнім ім'ям хоста. Подивіться наступний код коду в util-linux-2.20.1/term-utils/script.cрядку: 245-247

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

Базуватися на libutempter-1.1.5/utempter.h

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

Так script.cце фактично передавання порожнього імені хоста вutempter_add_record .

RedHat Backport

Цікаво, що вгору за течією util-linux-ng-2.17.2насправді не підтримують libutempter. Здається, Редхат вирішив повернути цю підтримку.

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

Наведена вище команда повертає порожній результат.

Висновок

Тож різниця в поведінці між двома дистрибутивами - це не помилка, а вибір. RedHat вирішив підтримати цю функцію, а Debian пропустив її.

Це виглядає для мене абсолютно спантелично. Або він повинен використовувати якесь 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.

Я побачу, чи зможу я щось далі копати. Але те, що задали ewwhite, є вагомими питаннями.

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

Чому останній -i показує 0,0.0,0 для записів рядків балів

Найкращий спосіб пояснити це те, що відбувається, коли ви не проходите -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це управління сеансом.

Окрім часової позначки історії басу, чи є інші речі, які я можу зробити, щоб відстежити проблему?

utmpзазвичай не піддається запису і не призначений для цього. utmpнаписано програмами, призначеними для входу в систему та налаштування сеансу. У вашому випадку це так sshd.

Чому sshd не поводиться з користувачем належним чином, дуже дивно, оскільки воно повинно бути належним чином копіювати ім'я хоста, з якого ви прийшли. Саме тут, мабуть, слід зосередити зусилля налагодження. Почніть з додавання налагодження вихідного файлу sshd до своїх журналів і подивіться, чи з’явиться щось аномальне.

Якщо ви хочете вирішити проблему (або, можливо, навіть дізнатися більше про проблему), ви можете використовувати pam_lastlogдля управління utmp, додавши її до сеансу до /etc/pam.d/sshd.

Власне кажучи, не хочеться перевіряти, чи він уже є - тому що він pam_lastlogмістить nohostваріант, який би точно пояснював вашу поведінку.

Нарешті, ти не міг користуватися останнім часом. aulastвиконує ту саму роботу через підсистему аудиту.

Можливо, варто спробувати перевірити, чи вдалося принаймні написати правильну адресу. Якщо це не так, ваша проблема повинна бути з sshd, оскільки sshd передає імена DNS навколо різних підсистем, таких як utmp або аудит.

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

Після входу через ssh, ви можете отримати ssh до localhost та отримати 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-ключ для локального входу?
• Перевірте або опублікуйте / var / log / secure одного і того ж часового періоду. Це може надати певний натяк.
• Перевірте використовувані сценарії
• Перевірте використовувані вами псевдоніми оболонки
• Перевірте історію команд

(2) Додатковий синаріо

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

1. КористувачВхід у вікно X
2. Відкрийте вікна терміналу, зробіть xhost + localhost
3. su - UserBабо sudo su - UserBпотім відкрити новий термінал (xterm, gnome-terminal тощо)
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

Відповідь Майфа вже показує блок коду last.c. Причина lastвідображення порожнього імені хоста / IP в тому, що ut_hostдля цих записів фактично порожні. Для повної структури wtmp виконайте це man wtmpв будь-якій системі Linux.

Два сценарії показують, що навіть стандартні пакети, за певної ситуації, створюють їх як такі.

(3) Історія хаків

Він працюватиме лише в тому випадку, якщо сеанс використовуватиме bashяк інтерактивну оболонку.

.bashrcі .bash_profileвикористовуються лише користувачем bash.

Вони не отримуватимуться автоматично, якщо сеанс використовує будь-яку іншу оболонку (sh, csh тощо) або виконує програму безпосередньо, і історія башів також не буде.

(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 на каталог (доступ лише для кореневих файлів) /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: Я намагався відкрити декілька сеансів терміналу та ssh. Незрозуміло (або не просто визначити), що відкриває нові очки. Однак він показує все, що працювало в рамках цього бала / сеансу.

PS2: публікація в блозі про використання дії Mike.

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

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)    

Я майже впевнений, що ваша справа потрапляє в будь-який із двох випадків: один із термінальним вікном у графічному інтерфейсі, а інший із екрановим сеансом.

Сподіваюся, що це допомогло.

Я не думаю, що нам вдасться далеко досягти цього без налагодження last.c, але це не повинно бути надто важким, оскільки воно збирається легко ...

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

utmpdump /var/log/wtmp 

щоб ми могли відтворити локальні копії вашого wtmp для налагодження

utmpdump -r <dumpfile >wtmp

Я перевірив на 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за замовчуванням? Чи є в середовищі інші спеціальні сценарії входу?

--Edit--

Я досі ніяк не можу це відтворити. Я дивлюся на два найважливіші компоненти. 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 Bug id 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)  # <-----

Звичайно, це було не так ...

Підключення псевдотермінальних підлеглих (pts) - це з'єднання SSH або telnet, що означає непрямі підключення до системи. Усі ці з’єднання можуть підключитися до оболонки, що дозволить видавати команди на комп'ютер. Отже, коли ви відкриваєте термінал у вашій системі з gui, він відкриває бали з джерелом ip 0.0.0.0. З наданої вами інформації, здається, що це відбувається через запущений скрипт на цьому сервері або запланований, який використовує службу ssh або telnet або локальні точки, щоб перекинути вихід у термінал.

Який ssh-клієнт ви використовуєте? Деякі клієнти ssh можуть мультиплексувати декілька терміналів через одне з'єднання, і я помічаю, що всі ваші сеанси без IP потрапляють під час більш тривалих сеансів, які мають зареєстрований IP.

Я не можу дублювати цю поведінку зі ssh тут.

Можливо, ваша IP-адреса вирізняється порожнім рядком на одному з ваших серверів DNS, можливо, другорядним, якщо це трапляється лише 10 відсотків часу (або просто, можливо, файлом хостів, якщо вони поширюються з центрального сховища). Це пояснювало б відсутність (або пробіл) запису і відповідало б прочитанню Соамом джерела.

"0.0.0.0" означає, що це локальний користувач (не віддалений логін), імовірно, викликається програмою, наприклад, cronjob.

Це відбувається тому, що ви використовуєте локальну систему, а 0.0.0.0 означає ip-адресу всіх інтерфейсів. Якщо ви думаєте, що, можливо, хтось зламав, ви спробуйте налаштувати повний журнал оболонки, включаючи команди через ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Я вирішив це, додавши скрипт до ~ / .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"

Шарон