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



Pdf просмотр
страница38/42
Дата15.02.2017
Размер6.16 Mb.
Просмотров2891
Скачиваний0
ТипАнализ
1   ...   34   35   36   37   38   39   40   41   42
Листинг 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.
СОВЕТ
Протоколирование на системах повышенной важности (таких как брандмауэр) надежнее организовать таким
образом, чтобы протоколируемые сообщения выводились напрямую на принтер. В этом случае злоумышленник не
сможет модифицировать содержимое журналов, и вы получите возможность своевременно обнаружить его
присутствие.
Заключение
В данной главе я рассказал о содержимом некоторых стандартных файлов журналов, существующих в вашей системе. Эту информацию нельзя считать точной и исчерпывающей, однако благодаря ей вы можете получить множество полезных сведений о функционировании системы. Теперь вы должны лучше понимать, как работает система протоколирования и как используются связанные с ней программы. Я также рассказал о некоторых недостатках системы протоколирования syslog.

24
Использование средств наблюдения за
защитой сети
В данной главе рассматриваются следующие вопросы:
- защита вашей системы;
- начальная установка системы;
- повторяющиеся задачи.
Одной из наиболее сложных и обременительных задач, встающих перед администраторами- новичками (в особенности теми из них, кто никогда ранее не имел дела с какими-либо разновидностями
Unix), является задача обслуживания системы и поддержки должного уровня безопасности. Зачастую манера, в которой они обеспечивают должную защиту системы, напоминает рассказ нескольких слепых о слоне. Некоторые из администраторов знают о том, что очень важно ежедневно проверять системные журналы, другие знают, что надо постоянно следить за целостностью системных файлов, третьи осведомлены, что следует периодически проверять, какие из программ связывают порты на уровне привилегий root. Однако многие забывают, что самое важное — это объединить все эти операции.
Некоторые из задач следует выполнять чаще других. На небольшой однопользовательской системе, подключающейся к Интернету время от времени, правила фильтрации пакетов которой настроены на блокирование всех привилегированных портов, многие операции могут выполняться раз в неделю или даже раз в месяц. Если точно такая же система соединена с Интернетом 24 часа в сутки семь дней в неделю, если к ней ежедневно подключается большое количество пользователей, те же самые операции по обслуживанию системы и обеспечению безопасности следует выполнять ежедневно.
Подытоживая эти рассуждения, следует отметить, что все зависит от многих факторов. Решения о том, насколько часто следует выполнять те или иные процедуры, принимает администратор системы. Эти решения должны быть продуманными и аргументированными.

Когда система загружена
Лучше всего начать обслуживание еще до того, как система будет подключена к сети. В этот период времени, то есть уже после того как система установлена и загружена, но еще до того как вы подключитесь к сети и позволите другим пользователям входить в систему (либо через сеть, либо при помощи консоли), вы можете быть в определенной степени уверены в том, что система работоспособна и не содержит в себе
«троянских коней» и т. п.
Подразумевается, что вы доверяете используемому вами комплекту Linux. Такие компании, как
Caldera и Red Hat, прикладывают массу усилий для того, чтобы установить и настроить систему наиболее безопасным образом. Например, если вы устанавливаете RPM-пакет netkit-telnet, сервер (демон telnet) и клиент устанавливаются с использованием наиболее безопасной конфигурации. При этом сервер активизирован, то есть способен отвечать на поступающие запросы.
Если вы нуждаетесь в использовании клиента telnet, но при этом вам не нужен сервер telnet, вы должны отключить сервер telnet. Однако будьте уверены, что разрешения на доступ к файлам и права на владения настроены должным образом.
Прежде всего следует провести инвентаризацию системы. В пакет dailyscript (название переводится как «ежедневный сценарий») входит программа с именем check-package (название переводится как

«проверка пакетов»), которая в процессе установки dailyscript устанавливается в /etc/cron.d/lib таким образом, чтобы запускаться ежедневно. Если вы установите и запустите этот пакет, в результате первого запуска на экране появится сообщение об ошибке. Это происходит потому, что база данных для выполнения сравнения еще не сформирована. При повторном запуске вы не обнаружите никаких изменений, однако сообщение об ошибке на экран выводиться не будет. Теперь каждый раз при запуске этого сценария на экран будет выводиться информация об обнаруженных изменениях. В полностью установленной системе Caldera для завершения работы сценария требуется около 15 минут. Если вы не желаете устанавливать dailyscript, вы можете выполнить проверку пакетов самостоятельно. Для этого достаточно воспользоваться двумя командами: rpm -qa и rpm -Va. Результат выполнения каждой из этих команд следует записать в отдельный файл. В результате вы получите два файла. Если вы захотите сравнить текущее состояние вашей системы с изначальным ее состоянием, вы должны снова выполнить две упомянутые команды, после чего результат выполнения каждой из команд следует сравнить с содержимым двух файлов, которые вы сгенерировали, когда система была только что установлена. Если все в порядке
(обнаруженные отличия не вызывают у вас подозрений), вы можете сохранить два новых полученных файла для последующих проверок. Именно такую процедуру сравнения выполняет сценарий check- packages. Этот сценарий записывает полученные файлы на жесткий диск. Возможно, для большей надежности будет лучше сохранить эти файлы на гибком диске и защитить этот диск от записи.
Также рекомендуется сохранить в отдельный файл вывод команды:
find / -perm +600 -print
Благодаря этому вы получите список всех файлов SUID/SGID (каталоги и исполняемые файлы). Если вы будете периодически выполнять эту команду и сравнивать результат ее выполнения с изначальным файлом, вы сможете обнаружить, какие новые файлы SUID/SGID появились в вашей системе.
Помимо этого рекомендуется проверять файл /etc/passwd на наличие пользователей с идентификаторами UID или GID, равными нулю:
grep ":0:" /etc/passwd
Идентификаторами UID и GID, равными нулю, должны обладать только пользователь root и несколько системных учетных записей.
Кроме того, вы должны проверить, что в системе не существует ни одной учетной записи с пустым паролем:
awk -F: ' { print $2 ":" $1 } ' /etc/shadow | grep "V - | sed "s/://g" -
Просмотрите содержимое файла/etc/inetd.conf и закомментируйте все ненужные службы, а затем перезапустите (или сделайте SIGH UP) демон inetd. После этого можно приступить к «укреплению» вашей системы. Если в процессе просмотра /etc/ inetd.conf вы обнаруживаете службу, смысла которой вы не понимаете, закомментируйте ее. Если после завершения такой чистки в файле/etc/inetd.conf осталось что- либо помимо ftp, рорЗ и swat, значит, возможно, вы оставили там нечто лишнее.
Наконец, следует отредактировать файл /etc/aliases. Убедитесь в том, что запись ближе к концу файла изменена таким образом, что почта, адресованная пользователю root, перенаправляется какому-либо обычному пользователю. Не забудьте запустить newaliases.
Перекомпоновка ядра
Следующий шаг — перекомпоновка ядра. Для выполнения этой задачи лучше всего подключиться к
Интернету, загрузить последнюю версию «чистого» исходного кода ядра и откомпилировать его. Скорее всего, в том, что вы используете ядро Caldera, нет ничего ужасного, однако, возможно, в комплект
OpenLinux входит не самая свежая версия ядра, кроме того, в исходный код этого комплекта внесены модификации и исправления, поэтому подчас такое ядро сложно компоновать. Если ранее вы не имели опыта компоновки ядра Linux, будет лучше, если вы будете использовать для этой цели именно «чистые» исходные файлы. При этом вы за короткое время получите в свое распоряжение новое ядро, которое будет оптимизировано под интересующие вас задачи, и поэтому оно будет более эффективным и более быстрым.
Кроме того, благодаря использованию «чистых» исходных кодов вы подготовите свою систему к установке пакета FreeS/WAN (если, конечно, вы нуждаетесь в использовании этого пакета), как об этом рассказывается в главе 21. К сожалению, очень многие имеющиеся на рынке комплекты Linux используют в своем составе модифицированное ядро и модифицированные исходные файлы. Это относится не только к
Caldera, но и к Red Hat, Mandrake, SuSE и многим другим комплектам. Компании, занимающиеся распространением Linux, намеренно хотят предложить вам за ваши деньги более широкие возможности, однако пакет ядра является наиболее важной частью системы и к нему следует относиться с особенным вниманием. Если вы хотите быть уверенными в том, что ядро откомпилировано должным образом, используйте «чистые» исходники.
После того как вы скомпонуете ядро и загрузите его (в идеале — с поддержкой ipchains), вы можете
приступить к блокированию портов, которые, возможно, используются локальным узлом localhost, но которые вы не собираетесь делать доступными для внешних пользователей. На этом же этапе вы можете сделать некоторые из служб доступными для узлов вашей внутренней сети, и эти службы не обязательно должны быть внешними службами.
Установка и настройка ipchains
Если вы не установили ipchains, самое время сделать это. Настройку ipchains следует начать с блокирования портов с номерами ниже 1024. Лучше всего заблокировать все или по крайней мере большую часть этих портов. Затем, если в этом есть необходимость, вы можете приступить к открыванию портов.
Открывать их следует по одному — по мере того как они становятся необходимыми. Все открываемые вами порты следует использовать для обеспечения работы относительно безопасных демонов. Имейте в виду, что наибольшее количество проблем возникает при использовании демонов telnet и imap. Если вы не чувствуете в себе уверенности в том, что вы сможете обнаружить злоумышленника, пытающегося проникнуть в систему через эти порты, лучше не открывать их для внешнего мира. В качестве вторичной защиты можно использовать tripwire.
ССЫЛКА
Более подробно об ipchains рассказывается в главе 16.
Ежедневные/еженедельные/ежемесячные
процедуры
обеспечения безопасности
В главах 22 и 23 вы узнали о механизме протоколирования syslog. Помимо проверки файлов
SUID/SGID, целостности установленных файлов (rpm -qa и rpm -Va), поиска пользователей с идентификаторами UID/GID, равными нулю, и проверки пустых паролей вы должны уделять время анализу файлов журналов. Файлы журналов подскажут, что именно происходило в системе в то время, пока она была включена.
Если вы решили использовать пакет dailyscript (модифицированный для OpenLinux), возможно, вы захотите запускать этот сценарий один раз в день. Сценарий производит множество проверок корректности системы, он просматривает журналы в поисках аномалий, а также запускает сценарии проверки RPM
(check-package) и осуществляет проверки журналов почты. После этого сценарий отправляет по почте пользователю root результаты своей работы (надеюсь, в вашей системе создан почтовый псевдоним учетной записи root, благодаря чему почта, адресованная root, перенаправляется обычному пользователю).
Содержимое конфигурационного файла dailyscript показано в листинге 24.1.

ВНИМАНИЕ
Если вы используете программу, которая периодически выполняет смену файлов журналов, убедитесь в том, что
сценарий dailyscript выполняется и завершает свою работу до того, как программа смены файлов журналов
перемещает их на новое место.
Во-первых, сценарий dailyscript использует утилиту last (которая читает содержимое wtmp) для проверки списка пользователей, подключенных к системе. Если файл wtmp отсутствует, значит, этот раздел доклада dailyscript будет пустым. Некоторые записи также могут оказаться ошибочными. Например, там может указываться still logged in (до сих пор подключен) в то время, как на самом деле соединение с системой было завершено некорректно. Соединение, на самом деле являющееся удаленным, может показываться как удаленное или как локальное. В докладе будет показано, кто подключен к системе и в какое время произошло подключение.
Во-вторых, сценарий dailyscript просматривает файл /var/log/messages в поисках подозрительных сообщений, то есть таких, которые не соответствуют общему описанию (образцу, заданному при помощи регулярного выражения — regex). Благодаря этому вы получаете возможность просмотреть все странные сообщения из файла журнала /var/log/messages. После нескольких первых запусков вы поймете, что получаемый в результате такого поиска набор сообщений требует сокращения. Большинство исходящих сообщений ррр и chat не являются аномальными. Вы можете повлиять на критерий отбора подозрительных сообщений, разместив выбранные слова в конфигурационном файле /etc/dailyscript.conf в строке
ALWAYSIGNORE="nepeмeннaя". В качестве переменной следует указать перечень разделенных пробелами слов (как правило, это имена каналов syslog), которые следует игнорировать при просмотре
журналов. Таким образом, если параметр ALWAYSIGNORE содержит "ррр chat", вы не увидите связанных с ррр и chat сообщений, которые по большей части не представляют для вас интереса (см. листинг 24.1).


Поделитесь с Вашими друзьями:
1   ...   34   35   36   37   38   39   40   41   42


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал