У меня работает пять Linux-систем CentOS 6, и я столкнулся с довольно странной проблемой, которая, кажется, возникает только с моим идентификатором пользователя во всех системах 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
для pts строки записей (см. Также этот ответ ) - Есть ли что-нибудь (кроме злонамеренной деятельности), которое разумно объясняет поведение?
- Кроме метки времени в истории bash, есть ли другие способы, которые я могу сделать, чтобы отследить проблему?
информационный
С тех пор, как это начало происходить, я включил bash
отметку времени в истории (то есть HISTTIMEFORMAT="%y-%m-%d %T "
в .bash_profile
), а также добавил несколько других взломов истории bash ; однако, это не дает подсказки к тому, что произошло во время предыдущих случаев.
Все системы работают под управлением 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 ~]$
РЕДАКТИРОВАТЬ
Если я использую 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.
РЕДАКТИРОВАТЬ 2 (для вопросов Ewwhite)
/etc/resolv.conf
(обратите внимание, что я использовал .local
addrs в 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
info (обратите внимание, что этот настроенный файл 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)
ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ
Смотрите мой ответ ниже
last -i mpenning
показ пробелов?Ответы:
script
различия в поведении между RedHat и DebianСвязанные библиотеки
CentOS 6.3 - скрипт (util-linux-ng 2.17.2)
Ubuntu 12.04 - скрипт (util-linux 2.20.1)
PTY
Основываясь на исходном исходном коде ,
script
из обеих версий откройте новый pty. Следующее - тест.Ubuntu 12.04
Ubuntu 12.04
script
открыла новый pts (2). Это просто не обновлялось/var/log/wtmp
.CentOS 6
Я пропускаю тест, поскольку мы уже знаем, что
script
открываем pty и регистрируемся в wtmp.libutemper
Таким образом, основным отличием является дополнительная библиотека (
libutempter.so.0
),script
с которой связан CentOS .Тест с Ubuntu 12.04
Компиляция
script
с помощью libutempterтестирование
Перед запуском
script
В
script
После
script
окончанияОсновная причина имени хоста emtpy
И да,
script.c
создайтеwtmp
запись с пустым именем хоста. Посмотрите на следующий блок кода вutil-linux-2.20.1/term-utils/script.c
строке: 245-247Основывается на
libutempter-1.1.5/utempter.h
Так
script.c
что фактически передает пустое имя хоста вutempter_add_record
.RedHat Backport
Интересно то, что upstream на
util-linux-ng-2.17.2
самом деле не поддерживаетlibutempter
. Кажется, Redhat решил добавить эту поддержку обратно.Приведенная выше команда возвращает пустой результат.
Вывод
Таким образом, разница в поведении между двумя дистрибутивами - это не ошибка, а выбор. RedHat решил поддержать эту функцию, в то время как Debian ее пропустил.
источник
coreutils
версию rpm, которую использует CentOS 5? Я должен проверить исходный код.libutempter
не связан в EL4 (черезldd
), но это связано в EL5 и EL6script
команды. Это изменение функции, вероятно, имело место в системах, похожих на Red Hat, с тех пор, как в 2007 году была представленаcoreutils
версия RHEL 5. для EL4 версии 5.2.1. На EL5 это версия 5.97.script
есть в util-linux.Это выглядит абсолютно загадочным для меня. Либо он должен использовать DNS-имя или IP-адрес. Я также проверил
last.c
файл, но до сих пор не могу найти, почему он ничего не показывает. Вероятно, по прошествии некоторого времени я смогу разобраться в части о 0.0.0.0.Вот две глобальные переменные, используемые в контексте:
Таким образом, теоретически, он должен использовать DNS или IP.
Я посмотрю, смогу ли я копать что-нибудь дальше. Но то, что спросили, это правильные вопросы.
источник
Так что я побежал последним в отладчике, который, надеюсь, даст вам хотя бы немного ответов на ваш вопрос. Мое чувство коренная причина, хотя глубже.
Почему последний -i показывает 0.0.0.0 для записей строки pts
Лучший способ объяснить это то, что происходит, когда вы не передаете -i.
Причина этого в этом разделе кода
last.c
Оба
usedns
иuseip
(с использованием параметров по умолчанию) не помечены. Это заставляет логику копировать из структуры,p->ut_host
которая в соответствии сman utmp
именем удаленного входа в систему записывается тем, что записано вutmp
.В вашем случае значение здесь равно нулю. Вот почему, когда вы бежите,
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 или аудит.
источник
pam_lastlog
как указано выше?(1) База на
last
выходе ОППосле входа в систему через ssh можно войти в ssh на локальный хост и получить 0.0.0.0
last -i
для последующего использования.База на первых четырех строках журнала ОП
pts/19
вход был в течениеpts/17
периода входа.pts/17
вход был в течениеpts/1
периода входа.Для этого конкретного случая логично предположить, что OP ssh из 192.0.2.91 (
pty/1
), затем в этом сеансе ssh,ssh localhost
снова локально ( ) войти на сервер (pts/17
) и снова (pts/19
).Пожалуйста, проверьте, не происходит ли это совпадение с другим случаем.
Следующее может помочь определить причину
(2) Дополнительный Secnario
Сценарий 1 - судо и терминал
xhost + localhost
su - UserB
илиsudo su - UserB
затем откройте новый терминал (xterm, gnome-терминал и т. д.)UserB
будет отображаться как 0.0.0.0 вlast -i
su - UserB
не будет зарегистрирован какUserB
логин в последнем, но открытие терминала будет.Сценарий 2 - вход
sudo login
last
иlast -i
last
не показывать имя хоста или IP дляlogin session
.last -i
будет IP 0.0.0.0 дляlogin session
.В ответе Mife уже указан блок кода
last.c
. Причинаlast
отображения пустого имени хоста / IP заключается в том, чтоut_host
эти записи фактически пусты. Для полной структуры wtmp, сделайтеman wtmp
на любой системе Linux.2 сценария показывают, что даже стандартные пакеты в определенных ситуациях создают их как таковые.
(3) Взломать историю Bash
Это будет работать только в том случае, если сеанс используется в
bash
качестве интерактивной оболочки..bashrc
и.bash_profile
используются толькоbash
.Они не будут получены автоматически, если сессия использует какую-либо другую оболочку (sh, csh и т. Д.) Или выполнит программу напрямую, и истории bash также не будет.
(4) Процесс учета
Поскольку OP ничего не упоминает о
secure
файле, я предполагаю, что это тупик, и теперь он фактически дает подсказку.Если следующее предположение верно
auth.log (debian) / secure (CentOS) не поможет. Поскольку в нем записано только действие, связанное с аутентификацией.
wtmp / utmp, с ограничением в их структуре данных, также является тупиком. Нет информации о том, что их создало.
Это оставляет нас с одним вариантом, процесс учета . Это большой пистолет, и его следует использовать с осторожностью.
Версия пакета psacct должна быть 6.3.2-56 или выше, согласно этому посту .
Если он должен использоваться и
/var/log
имеет ограниченное пространство, измените файл журнала acct на каталог (доступ только для пользователя root)/home
, в котором обычно гораздо больше места.Это действительно большой пистолет. При ОП 10% частота должна быть в течение недели. Если в течение этого периода пустая запись появится в
last
журнале действий, но ничего не появится, это станет загадочной ситуацией и потребует каких-то решительных действий .Ниже приведен пример вывода
lastcomm
Вы также можете использовать «dump-acct», чтобы показать больше информации.
PS1: я пытался открыть несколько терминалов и ссх сессии. Непонятно (или не просто указать точку), что открывают новые очки. Тем не менее, он показывает все, что выполнялось в этом сеансе.
PS2: сообщение в блоге об использовании acct Майком.
источник
ssh localhost
и проверьтеlast -i
.login locally
, я имеюssh localhost
в виду делать в этой сессии SSH. Я изменил это предложение, надеюсь, теперь оно не так запутанно.Когда вы входите в систему, это может быть несколько записей в последней команде.
Первая запись с tty * появляется, когда вы входите через терминал или консоль, нажимая CTRL + ALT + F1-6. Это довольно ясно из терминала, который он использует.
Вторая запись обычно появляется, когда вы входите в систему и открываете окно терминала в графическом интерфейсе. Также будет запись, даже если вы откроете новую вкладку в том же окне терминала.
Третий тип ввода происходит, когда вы открываете сеанс экрана после входа в систему через SSH. Это также создаст запись там и без какого-либо IP-адреса.
Четвертая запись вполне нормальна, и все это понимают.
Если вы сделаете
last -i
со следующими записями, вы увидите что-то вроде этого:Я почти уверен, что ваш случай подходит к любому из двух случаев: один с окном терминала в GUI, а другой с сеансом экрана.
Надеюсь, что это помогло.
источник
screen
для какой-либо из0.0.0.0
записей. Я использую GUI только когда я установил машины (около августа / сентября). Я вижу много0.0.0.0
записей оч после этого времени.Я не думаю, что мы доберемся до этого без отладки last.c, но это не должно быть слишком сложно, так как он легко компилируется ...
Одна из возможностей, однако, - выгрузить файл / var / log / wtmp с помощью команды utmpdump и взглянуть на необработанные записи, которые могут пролить свет на вас. Если нет, пожалуйста, опубликуйте соответствующий вывод
так что мы можем воссоздать локальные копии вашего wtmp для отладки с
источник
Я проверил 12 многопользовательских серверов приложений CentOS и RHEL 6.3. Никто не проявлял такого поведения. В
last
выходных не было пропущенных записей, начиная с 4-5 недель.Я думаю, что было бы важно увидеть
/etc/hosts
запись вашего файла, чтобы убедиться, что она соответствует этому формату .Кроме того, что вы делаете для разрешения DNS? Вы можете опубликовать свой
/etc/resolv.conf
?Другие ответы, указывающие, что
0.0.0.0
представляют локальные соединения, являются правильными. Типичными примерами являются события перезагрузки и входа в консоль:Так как это происходит только с именованными пользователями, есть ли какое-то изменение, что происходит что-то необычное или запускается в их сценариях входа? Вы изменили
~/.bashrc
или~/.bash_profile
по умолчанию? Существуют ли другие специальные сценарии входа в среду?--Редактировать--
Я все еще не могу воспроизвести это каким-либо образом. Я смотрю на два критических компонента, хотя. Команда
last
стабильна и не менялась долгое время. Если посмотреть на журнал изменений для sysvinit-tools , то здесь нет соответствующих ошибок. То же самое для начальных букв (wtmp).Если вы можете заставить это произойти, попробуйте это с другой учетной записью пользователя из тех же исходных компьютеров. Но я не вижу никаких признаков того, что это проблема ОС.
источник
/etc/hosts
) должны затрагивать всех ... не только яlast -if
оба этих файла и посмотреть, видите ли вы одинаковые результаты с течением времени?/var/log/secure
записи ... записи, которые0.0.0.0
показывают, ничего не показывают в/var/log/secure
ЗАКЛЮЧИТЕЛЬНОЕ РЕШЕНИЕ
Я уже присудил бонус, так что это чисто для будущих гуглеров с таким же вопросом.
Причина, по которой это появляется только в ~ 10% моих входов в систему, заключается в том, что когда я делаю серьезные изменения в наших маршрутизаторах или коммутаторах, я использую их,
script foo.log
поэтому у меня есть полный журнал изменений терминала. По причинам, которые я до сих пор не понимаю, CentOS создаетpts
запись, когда вы используетеscript
команду ... Я продемонстрирую выводlast -i
до и после запускаscript
...Такое поведение кажется уникальным для CentOS 6 ... у нас в лаборатории есть машины CentOS 4.7, которые не помещают пустую запись в
wtmp
... Машины Debian / Gentoo также не демонстрируют такое поведение. Наши администраторы linux ломают голову над тем, почему CentOS намеренно добавляет другуюpts
запись при запускеscript
... Я подозреваю, что это ошибка RHEL.РЕДАКТИРОВАТЬ : я подал эту проблему как идентификатор ошибки RHEL 892134
НОТА
Некоторые люди ошибочно предположили, что я положил
script
в свой~/.bashrc
или~/.bash_profile
. Это некорректный аргумент ... если бы это было правдой, mywtmp
должен иметь0.0.0.0
запись после каждого из моих логинов ssh ...Конечно, это был не тот случай ...
источник
script
команду в своем первоначальном вопросе.script
Программа делает машинопись всего напечатанные на вашем терминале. Это уместная деталь..bashrc
или.bash_profile
не был; Я выполняю,script foo.log
когда я делаю серьезные изменения, чтобы я мог иметь журнал изменений ... т.е. именно поэтому он затрагивает только ~ 10% моих входов в систему. 2) Если ваше обвинение верно (и это не так), у меня никогда не будет логина ssh. у которого не было другой0.0.0.0
записи сразу после нее 3)script
делает это только в CentOS ... Я использовал ее более десяти лет и никогда не видел такого поведения в другом дистрибутиве ... на данный момент я утверждаю, что это скорее всего CentOS ошибкаscript
будет только раскошелиться на оболочку. Основываясь на том, что вы здесь показываете, CentOS / Redhat-версия наscript
самом деле в первую очередь форк pty. Хотя немного разочарован (: P), что это не что-то более общее / через дистрибутив, по крайней мере, загадка ушла из моего разума. PS: Я удивлен, что у вас есть Gentoo в производстве @. @Соединения псевдотерминала 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» означает, что это локальный пользователь (не удаленный вход в систему), вероятно, вызванный приложением, например, cronjob.
источник
# last -i |grep 0.0.0.0 \ reboot system boot 0.0.0.0 Wed Dec 5 20:09 - 17:18 (15+21:08) # last |grep reboot \ reboot system boot 2.6.32-10-pve Wed Dec 5 20:09 - 17:18 (15+21:08)
Это происходит потому, что вы используете локальную систему, а 0.0.0.0 означает IP-адрес всех интерфейсов. Если вы думаете, что, возможно, кто-то взломал, вы попытаетесь настроить полную регистрацию оболочки, включая команды через ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/
источник
Я решил это, добавив скрипт в ~ / .bashrc, скрипт находит последний IP-адрес источника соединения telnet, затем вы можете добавить IP в файл журнала или сделать все, что вам нужно ..
Sharon
источник
netstat -nae | grep 23
это не полезный способ найти соединения Telnet. Эта команда выдает 92 результата в моей системе, и ни один из них не является telnet.