Geum.ru

Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материалаРеферат

Содержание


Чтение файлов журналов
Файлы utmp, wtmp и last log
User tty from login@ idle jcpu pcpu what
Подобный материал:
1   ...   89   90   91   92   93   94   95   96   ...   101

Чтение файлов журналов


Просмотр содержимого большинства файлов журналов (по крайней мере тех, которые записываются демоном syslogd) не представляет труда. Типичная запись в файле журнала syslog выглядит следующим образом:

Oct 3 10:56:18 volcan sshd[5915]: log: Generating 768 bit RSA key.

Формат всегда один и тот же. В первой колонке указывается дата и время внесения в журнал записи. Время является локальным временем сервера. Во второй колонке указывается имя сервера, который сделал эту запись. Часто в этой колонке указываются полные доменные имена внешних по отношению к протоколирующему серверу сетевых узлов, однако формат указываемых здесь имен можно изменить при помощи ключа командной строки (см. предыдущую главу). В рассматриваемом случае во второй колонке указано имя локальной системы — volcan. Следующая колонка содержит имя и идентификатор PID демона, создавшего эту запись. Идентификатор процесса PID (Process ID) указывается не всегда. В нашем случае создателем записи является демон sshd с идентификатором PID, равным 5915. Далее идет собственно сама запись, то есть текст сообщения, переданного демоном. В нашем случае запись показывает, что демон защищенной командной оболочки sshd (Secure Shell Daemon) с идентификатором PID 5915 сгенерировал ключ шифрования длиной 768 бит для обеспечения соединения через сеть.

Таким образом, пользователь root может свободно читать любой журнал, созданный демоном syslogd. Для этого не требуется никаких специальных программ. Однако некоторые программы, предназначенные для чтения сообщений, все же существуют. Первая такая программа называется dmesg. На самом деле программа dmesg не читает содержимое файла журнала. Вместо этого данная утилита читает кольцевой буфер ядра. Кольцевой буфер — это обычный буфер, который спроектирован таким образом, что сразу же после его заполнения новые данные начинают записываться в его начало и далее, затирая при этом информацию, которая располагалась в начале буфера до этого. Таким образом, добавление новых данных в буфер происходит по кольцу, переходя из конца в начало буфера.

Утилита dmesg возвращает последние 8192 байт из кольцевого буфера ядра (в документации указывается число 8196, однако на самом деле это не так). Это соответствует размеру кольцевого буфера в старых ядрах версий 2.0.x. Начиная с версии 2.2.13 размер кольцевого буфера увеличился и стал равным 16384 байтам. Чтобы увидеть все содержимое буфера целиком, можно воспользоваться ключом -s за которым указывается количество отображаемых байт кольцевого буфера. Например, вы можете воспользоваться командой:

dmesg -s16284


По этой команде на экран будет выведено полное содержимое кольцевого буфера. Если вы полагаете, что вам требуется более емкий буфер, вы можете модифицировать значение параметра LOG_BUF_LEN в файле /usr/src/linux/kernel/printk.c. Увеличивая размер буфера, вы должны сделать его кратным значению 8192.


СОВЕТ

Утилита dmesg читает содержимое кольцевого буфера ядра, а не содержимое файла /var/log/ messages, поэтому даже если система загружается с использованием строки init=/bin/sh, вы все равно сможете ознакомиться с диагностическими сообщениями, хранящимися в кольцевом буфере.

Совместно с утилитой dmesg можно использовать еще один из двух ключей (нельзя использовать эти два ключа одновременно). Любой из них можно использовать совместно с ключом -s. Во-первых, вы можете использовать ключ -с, который очищает кольцевой буфер. Во-вторых, вы можете использовать ключ -n<#>, при помощи которого вы можете сообщить утилите dmesg наименьший допустимый приоритет сообщений, выводимых на консоль. Например, если вы хотите отобразить только сообщения уровня приоритета emergency, вы можете указать -n 1. По мере увеличения этого числа разрешенный уровень приоритета понижается, и соответственно, все большее количество сообщений будет выводиться на экран. Пример вывода утилиты dmesg показан в листинге 23.4.


Листинг 23.4. Фрагмент вывода утилиты dmesg

ррр: channel pppO closing.

ррр0 released

ppp0: сcр closed

hdb: ATAPI 24Х CD-ROM drive, 120kB Cache

Uniform CDROM driver Revision: 2.56

VFS: Disk change detected on device ide0(3.64)

ISO 9660 Extensions: Microsoft Joliet Level 3

ISOFS: changing to secondary root

Uniform CD-ROM driver unloaded

PPP: ppp line discipline successfully unregistered

CSLIP: code copyright 1989 Regents of the University of California

PPP: version 2.3.7 (demand dialling)

PPP line discipline registered.

registered device ppp0

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

Файлы utmp, wtmp и last log


Файлы журналов, создаваемые демоном syslogd, а также некоторыми другими демонами, использующими свои собственные журналы (например, uucp, httpd и т. п.), являются легко читаемыми файлами в формате ASCII. Однако существуют и другие файлы журналов, которые содержат в себе не просто ASCII-текст, а бинарные данные. К этой категории относятся три файла: lastlog, utmp и wtmp. В этих файлах содержится информация, связанная с подключением пользователей к системе.

Если вы не обнаружите в вашей системе файлов utmp или wtmp, не удивляйтесь. Дело в том, что если эти файлы перемещены или удалены из системы или просто никогда не были созданы, система просто не осуществляет добавление в них записей. Иными словами, при отсутствии этих файлов механизм протоколирования сведений в них отключается. Такая возможность специально предусмотрена для тех, кто не желает пользоваться протоколированием сведений в этих файлах. Если же вы хотите использовать эти файлы, но в вашей системе они отсутствуют, значит, вы должны самостоятельно создать их. Для этого достаточно воспользоваться простой командой touch имя_файла, отданной в корректном каталоге. Файлы, о которых идет речь, содержат в себе информацию о подключении пользователей к системе и используются несколькими программами. Корректным каталогом для файла wtntp является каталог с именем /var/log, а корректным каталогом для файла utmp является /var/run.


ПРИМЕЧАНИЕ

Если файлы utmp и wtmp не будут созданы, ничего страшного не произойдет, однако имейте в виду, что при этом протоколирование сведений в них (эти сведения имеют отношение к использованию пользовательских учетных записей) будет отключено. Такой режим можно использовать для небольшой системы, к которой пользователи, как правило, не подключаются.

Файл utmp содержит в себе сведения о текущих подключениях к системе. Файл wtmp содержит исторические сведения о подключениях к системе. В файле lastlog содержится информация о последнем успешном подключении пользователя к системе, когда это произошло и из какого места пользователь подключился. Все эти файлы используются утилитами last, Lastlog, uptime, utmpdump, w и who. Файлы utmp, wtmp и lastlog содержат в себе данные в бинарном формате, поэтому их нельзя просмотреть напрямую обычным текстовым редактором, однако для просмотра их содержимого можно использовать одну из вышеупомянутых утилит. Например, если вы не хотите, чтобы пользователи обладали возможностью использовать утилиту who, вы можете изменить режим доступа к файлу utmp таким образом, чтобы он перестал быть доступным для чтения всем пользователям.

Несмотря на то, что в файлах utmp и wtmp содержится информация о подключении пользователей к системе, далеко не все программы обращаются к этим файлам. Некоторые программы, такие как xdm (или kdm), не могут или не должны создавать записи в файле utmp, однако при этом они создают записи в файле wtmp. Это объясняется способом, при помощи которого пользователь подключается к системе с использованием xdm или kdm. Ни одна из программ диспетчера экрана не обладает контролирующим TTY, поэтому процесс login не может составить для них корректную запись для файла utmp. Это означает, что программы xdm и kdm функционируют подобно службе FTP, которая вносит записи только в файл wtmp.


ПРИМЕЧАНИЕ

Контролирующий терминал процесса — это терминал, с которого был запущен этот процесс. Именно на контролирующий терминал направляются все выводимые этим процессом сообщения (если только не было выполнено специальное перенаправление стандартного потока вывода и/или стандартного потока вывода ошибок).


Программы, использующие utmp и wtmp, выводят на экран информацию о подключениях, перезапусках и т. п. В листинге 23.5 показан сильно урезанный вывод утилиты last.


Листинг 23.5 Вывод команды last, урезанный для краткости

david pts/2 volcan.pananix.c Thu Oct 28 08:50 - 08:54 (00:03)

david pts/1 volcan.pananix.c Thu Oct 28 07:52 still logged in

david pts/1 volcan.pananix.c Wed Oct 27 22:38 - 22:55 (00:17)

david pts/2 Wed Oct 27 20:49 - 08:50 (12:00)

root tty2 Wed Oct 27 20:48 - 21:12 (00:23)

david ftp volcan.pananix.c Wed Oct 27 19:15 - 19:16 (00:01)

reboot system boot 2.2.13 Sun Oct 24 08:46 (4+00:18)

root tty1 Sun Oct 24 08:31 - crash (00:14)

Информация для этого листинга извлекается из файла wtmp. В каждой записи слева направо перечисляются: имя пользователя, контролирующий терминал (или ftp или system boot — загрузка системы), узел (если узел не является локальным, или версия ядра в случае, если указано system boot), дата и время подключения и отключения (или смещение GMT если указано system boot). Обратите внимание: в последней записи в завершающей колонке содержится метка crash (сбой). Это отнюдь не указывает на то, что система зависла. На самом деле это признак того, что было выполнено контролируемое завершение работы системы (shutdown). Однако сеанс подключения был прерван, так как изменился уровень запуска (runlevel), поэтому считается, что произошел ненормальный выход из сеанса.

Вывод (в сокращенной форме) утилиты lastlog показан в листинге 23.6. Здесь отображена информация, извлеченная из файла /var/log/lastlog, которая сопоставлена с информацией из файла /etc/passwd.


Листинг 23.6 Сокращенный вывод команды lastlog

Username Port From Latest

root tty2 Wed Oct 27 20:48:59 1999

bin **Never logged in**

daemon **Never logged in**

majordom **Never logged in**

postgres **Never logged in**

mysql **Never logged in**

Silvia ttyl Sat Aug 7 22:55:54 1999

david pts/2 volcan.pananix.c Thu Oct 28 08:50:18 1999

dns **Never logged in**

Утилита uptime использует информацию из файла utmp для формирования данных о подключениях, кроме того, она обращается к /рrос для получения информации о процессах. Вывод утилиты uptime выглядит следующим образом:

10:11am up 2 days, 19:29, 1 user, load average: 0.00, 0.01, 0.00

Единственным полем, для формирования которого используется файл utmp, является поле, в котором указывается количество пользователей, в данном случае 1.

Программа utmpdump может обрабатывать любой файл, имя которого указано в командной строке, однако эта программа в состоянии интерпретировать только файлы /var/run/utmp и /var/log/wtmp, так как эти файлы обладают сходным форматом. Сокращенная интерпретация файла utmp показана в листинге 23.7, а сокращенная интерпретация файла wtmp — в листинге 23.8.


Листинг 23.7 Содержимое utmp

Utmp dump of /var/run/utmp

[8] [00651] [bw ][][][] [0.0.0.0 ] [Sun Oct 24 08:46:17 1999 EST]

[1] [20021] [~~ ] [runlevel] [- ] [ ] [0.0.0.0 ] [Sun Oct 24 08:46:17 1999 EST]

[8] [00899] [15 ][][][] [0.0.0.0 ] [Sun Oct 24 08:46:40 1999 EST]

[8] [09264] [P001] [ ] [pts/1 ] [ ] [0.0.0.0 ] [Wed Oct 27 22:55:41 1999 EST]

[7] [13696] [P001] [david ] [pts/1 ] [volcan.pananix.com] [0.0.0.0 ] [Thu Oct 28 07:52:07 1999 EST]

Файл utmp содержит информацию только о текущих сеансах. Можно заметить, что в листинге присутствуют записи об очень старых сеансах. Если сравнить содержимое wtmp и utmp, можно обнаружить, что в utmp присутствуют некоторые устаревшие записи. Они сохранились потому, что соответствующие сеансы были завершены некорректно. Если просматривать каждую запись слева направо, в первой колонке можно увидеть численный идентификатор. Это одноразрядное число, которое не имеет большого значения. Вторая колонка содержит PID процесса. Если вы произведете поиск в системе перечисленных здесь идентификаторов PID, вы обнаружите, что активным является только самый последний, 13696. В третьей колонке может содержатся одно из следующих значений: ~~, bw, число или буква и число. Эти метки обозначают соответственно: изменение уровня запуска или перезагрузку, процесс bootwait и либо номер TTY, либо комбинацию буквы и числа для РТY. Четвертая колонка может быть либо пустой, либо содержать имя пользователя, reboot (перезагрузка) или runlevel (уровень запуска) в зависимости от доступной информации. В пятой колонке указывается контролирующий TTY или РТY, если эти данные известны. В пятой колонке указывается имя удаленного узла. Если подключение осуществляется с локального узла, в этом поле ничего не указывается. В седьмой колонке указывается IP-адрес удаленной системы. В последней колонке содержится дата и время записи. Обе таблицы — utmp и wtmp — содержат одни и те же сведения.


Листинг 28.8. Сокращенный вывод wtmp Utmp dump of /var/log/wtmp

[2] [00000] [~~ ] [reboot ] [- ] [2.2.12 ] [0.0.0.0 ] [Fri Aug 27 20:40:16 1999 EST]

[8] [00631] [bw ][][][] [0.0.0.0 ] [Fri Aug 27 20:40:16 1999 EST]

[1] [20021] [~~ ] [runlevel] [~ ] [ ] [0.0.0.0 ] [Fri Aug 27 20:40:16 1999 EST]

[5] [00879] [15 ][][][] [0.0.0.0 ] [Fri Aug 27 20:40:16 1999 EST]

[7] [02976] [/3 ] [Silvia ] [pts/3 ] [ ] [0.0.0.0 ] [Fri Aug 27 23:35:42 1999 EST]

[8] [02753] [1 ] [ ] [tty1 ] [ ] [0.0.0.0 ] [Fri Aug 27 23:40:10 1999 EST]

[7] [13368] [ ] [david ] [ftpd13368 ] [volcan.pananix.com] [0.0.0.0 ] [Thu Oct 07 08:09:30 1999 EST]

В листинге 23.7 записи таблицы utmp расположены в хронологическом порядке. В листинге 23.8 записи таблицы wtmp также расположены в хронологическом порядке, однако этот порядок противоположен, то есть самые старые записи располагаются в конце таблицы.

Последний листинг этой главы — листинг 23.9 — показывает вывод команд w и who. Эти утилиты также используют для отображения информации сведения из файла utmp и системы /рrос.

Листинг 23.9. Вывод команд w и who

[root@chiriqui]# w

10:35am up 2 days, 19:52, 1 user, load average: 0.00, 0.00, 0.00

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

david pts/1 volcan.pananix.c 7:52am O.OOs 0.25s 0.02s w

[root@chiriqui]# who

david pts/1 Oct 28 07:52 (vo1can.pananix.com)

Команда w выводит несколько больший объем информации о системе и о пользователе, чем команда who. Однако данные, выводимые командой who, удобнее использовать в рамках сценариев. Обе команды показывают, что пользователь david подключен к псевдотерминалу 1 с 7 часов 52 минут утра 28 октября с удаленного узла с именем volcan. Команда w выводит сведения о том, какую нагрузку создает данный пользователь на локальную систему. Если этот пользователь ранее открывал другие сеансы, которые на текущий момент являются закрытыми, расход ресурсов для тех сеансов показан не будет. Команда w также показывает командный процесс, запущенный пользователем david, а также в первой строке сведения о времени, в течение которого система продолжала работу.

В предыдущих листингах показан основной режим работы каждой из утилит. Следует учитывать, что каждая из рассмотренных утилит обладает множеством ключей, при помощи которых можно изменить ее поведение. В зависимости от того, какие сведения протоколируются в журналах, из этих журналов вы можете почерпнуть большой объем информации о состоянии системы. Однако при этом ни в коем случае не следует забывать об одном очень важном обстоятельстве: нельзя полностью доверять журналам.


ВНИМАНИЕ

Любой, кто без вашего спроса получил доступ к системе на уровне привилегий root, может и, скорее всего, попытается отредактировать журналы так, чтобы скрыть свое присутствие и свои действия. Журналам можно доверять только в случае, если они выводятся напрямую на принтер или на любой другой не стираемый носитель информации.

Я хотел бы еще раз подчеркнуть это. Файлы журналов нельзя считать исчерпывающими и в полной мере аккуратными и точными. Содержимое этих файлов можно модифицировать, в них можно по своему усмотрению добавлять новые записи, кроме того, существующие в них записи можно стирать. Содержащаяся в журналах информация зависит от того, какие демоны работают в системе, записывают ли они информацию в свои собственные журналы или передают ее демону syslog.


СОВЕТ

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