Альтернативы Tripwire

ViperDB

Домашняя страница ViperDB:
FCHECK

Домашняя страница FCHECK:
Sentinel

Домашняя страница Sentinel:

Дополнительная документация.

Здесь перечислены некоторые страницы руководства (man), которые могут дать вам дополнительную информацию.

$ siggen (8) – сбор сигнатур кодов для Tripwire
$ tripwire (8) – программа проверки целостности файлов UNIX систем
$ twadmin (8) – административная и инструментальная программа Tripwire
$ twconfig (4) – конфигурационный файл Tripwire
$ twfiles (5) – краткий обзор фалов используемых Tripwire и процесса
резервного копирования файлов
$ twintro (8) – введение в Tripwire
$ twpolicy (4) – файл политик Tripwire
$ twprint (8) – база данных и печать отчетов Tripwire

Для получения большей информации вы можете прочитать страницы руководства (man) перечисленные ниже.

$ man siggen (8) – генератор сигнатур программ для Tripwire
$ man tripwire (8) – программа проверки целостности файлов для UNIX
$ man tw.config (5) – конфигурационный фал для Tripwire

Инсталлированные файлы.

> /etc/cron.daily/tripwire.verify > /etc/tw.config > /usr/man/man5/tw.config.5 > /usr/man/man8/siggen.8 > /usr/man/man8/tripwire.8 > /usr/sbin/tripwire > /usr/sbin/siggen > /var/spool/tripwire > /var/spool/tripwire/tw.db_TEST

Команды.

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

Так как ваш файл с политиками инсталлирован, то наступило время создать базу данных объектов файловой системы, базирующуюся на файле с политиками. Эта база данных будет выступать как основание для дальнейших проверок целостности.

Синтаксис для перехода в режим инициализации базы данных:
[root@deep /]# tripwire { --init }

Инициализируем вашу базу данных:
[root@deep /]# tripwire --init

Please enter your local passphrase:

Parsing policy file: /usr/TSS/policy/tw.pol

Generating the database...

*** Processing Unix File System ***

Wrote database file: /usr/TSS/db/deep.openna.com.twd

The database was successfully generated.

ЗАМЕЧАНИЕ. Когда команда выполнена, база данных готова и вы можете выполнить проверку целостности файловой системы и просматривать отчеты.
Запуск режима проверки целостности и интерактивного режима проверки.

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

Синтаксис для режима проверки целостности:
[root@deep /]# tripwire { --check }

Для запуска проверки целостности используйте команду:
[root@deep /]# tripwire --check

Tripwire может быть также запущен в режиме “Интерактивный режим проверки”. В этом режиме вы можете автоматически обновлять ваши изменения с терминала.

Для запуска интерактивного режима проверки используйте команду:
[root@deep /]# tripwire --check --interactive

В Tripwire есть опция email, которая позволяет отправлять письма. Эта опция определяет, что отчет должен быть отправлен по электронной почте адресату, определенному в файле политик.

Для запуска режима проверки целостности и отправки отчета по электронной почте, используйте команду:
[root@deep /]# tripwire --check --email-report Обновление базы данных после проверки целостности.

Если вы решили использовать “Режим проверки целостности ” вместо “Интерактивного режима проверки ”, вы должны обновить базу данных Tripwire, используя возможность “Режим обновления базы данных”. Этот процесс позволяет вам сэкономить время, обновляя базу данных без ее полного пересоздания, и также допускается выборочное обновление, которое не может быть осуществлена через восстановление.

Синтаксис режима обновления базы данных:
[root@deep /]# tripwire { --update -r}

Для обновления базы данных дайте команду:
[root@deep /]# tripwire --update -r /usr/TSS/report/deep.openna.com-200001-021854.twr

где “-r” читает определенный файл отчет (deep.openna.com-200001-021854.twr). Эта опция требуется, так как переменная REPORTFILE в текущем файле конфигурации использует $(DATE).

ЗАМЕЧАНИЕ: В режиме обновления базы данных или режиме интерактивной проверки, Tripwire выводит отчет на вашем терминале с местом для отметки напротив каждого нарушения политики. Вы можете принять изменения в файловой системе установив знак “x” или не обновлять базу данных убрав “x”. После того, как вы вышли из редактора и ввели локальную парольную фразу, Tripwire будет обновлять и записывать изменения.
Обновление файла с политиками.

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

Синтаксис для режима обновления политик:
[root@deep /]# tripwire { --update-policy /path/to/new/policy/file}

Для обновления файла с политиками используйте команду:
[root@deep /]# tripwire --update-policy /usr/TSS/policy/newtwpol.txt

Режим обновления политик по умолчанию запускается с опцией “--secure-mode high”. Вы можете столкнуться с ошибкой когда запускаете Tripwire с этой опцией, если файловая система изменилась по сравнению с последним обновлением базы данных, и если эти изменения будут причиной нарушений по новым правилам политики. После уточнения, что все отчеты о нарушениях в high security режиме санкционированы, вы можете обновить файл с политиками в low security режиме для решения этой проблемы:

Для обновления файла политик в low security режиме используйте команду:
[root@deep /]# tripwire --update-policy --secure-mode low /usr/TSS/policy/newtwpol.txt

Проинсталлированные файлы.

> /usr/TSS > /usr/bin > /usr/bin/siggen > /usr/bin/twprint > /usr/bin/twadmin > /usr/bin/tripwire > /usr/bin/twcfg.txt > /usr/bin/tw.cfg > /usr/TSS/policy > /usr/TSS/policy/policyguide.txt > /usr/TSS/policy/twpol.txt > /usr/TSS/policy/tw.pol > /usr/TSS/policy/twpol.txt.bak > /usr/TSS/report > /usr/TSS/db > /usr/TSS/key > /usr/TSS/key/site.key > /usr/TSS/key/deep.openna.com-local.key > /usr/man > /usr/man/man4 > /usr/man/man4/twconfig.4 > /usr/man/man4/twpolicy.4 > /usr/man/man5 > /usr/man/man5/twfiles.5 > /usr/man/man8 > /usr/man/man8/siggen.8 > /usr/man/man8/tripwire.8 > /usr/man/man8/twadmin.8 > /usr/man/man8/twintro.8 > /usr/man/man8/twprint.8 > /usr/README > /usr/Release_Notes > /usr/License.txt

Компиляция и оптимизация.

Редактируйте файл utils.c (vi +462 src/utils.c) и измените следующую строку:

else if (iscntrl(*pcin)) {

Должна читаться:
else if (!(*pcin & 0x80) && iscntrl(*pcin)) {

Редактируйте файл config.parse.c file (vi +356 src/config.parse.c) и измените следующую строку:

rewind(fpout);

Должна читаться:
else {

rewind(fpin);

}

Редактируйте файл config.h (vi +106 include/config.h) и измените следующие строки:

#define CONFIG_PATH "/usr/local/bin/tw"

#define DATABASE_PATH "/var/tripwire"

Должны читаться:
#define CONFIG_PATH "/etc"

#define DATABASE_PATH "/var/spool/tripwire"

Редактируйте файл config.h (vi +165 include/config.h) и измените следующую строку:

#define TEMPFILE_TEMPLATE "/tmp/twzXXXXXX"

Должна читаться:
#define TEMPFILE_TEMPLATE "/var/tmp/.twzXXXXXX"

Редактируйте файл config.pre.y (vi +66 src/config.pre.y) и измените следующую строку:

#ifdef TW_LINUX

Должна читаться:
#ifdef TW_LINUX_UNDEF

Редактируйте файл Makefile (vi +13 Makefile) и измените следующие строки:

DESTDIR = /usr/local/bin/tw

Должна читаться:
DESTDIR = /usr/sbin

DATADIR = /var/tripwire

Должна читаться:
DATADIR = /var/spool/tripwire

LEX = lex

Должна читаться:
LEX = flex

CC=gcc

Должна читаться:
CC=egcs

CFLAGS = -O

Должна читаться:
CFLAGS = -O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions

[root@deep tw_ASR_1.3.1_src]# make

[root@deep tw_ASR_1.3.1_src]# make install

[root@deep tw_ASR_1.3.1_src]# chmod 700 /var/spool/tripwire/

[root@deep tw_ASR_1.3.1_src]# chmod 500 /usr/sbin/tripwire

[root@deep tw_ASR_1.3.1_src]# chmod 500 /usr/sbin/siggen

[root@deep tw_ASR_1.3.1_src]# rm -f /usr/sbin/tw.config

Команды “make” и “make install” настаивают программное обеспечение, чтобы удостовериться, что ваша система имеет необходимые возможности и библиотеки для успешной компиляции пакета, компилируют все исходные файлы в исполняемые, и затем инсталлирует их и сопутствующие им файлы в определенное место.

Команда “chmod” изменяет права доступа по умолчанию к каталогу “tripwire” на 700 (drwx------), чтение, запись и исполнение только для пользователя “root”. И изменяет права доступа на чтение и исполнение только пользователем root (- r-x------) для программ “/usr/sbin/tripwire” и “/usr/sbin/siggen”. Команда “rm” используется для удаления файла “tw.config” расположенного в “/usr/sbin”. Нам этот файл не нужен, так как мы создадим подобный новый файл позже в каталоге “/etc”.
Очистка после работы.

[root@deep /]# cd /var/tmp

[root@deep tmp]# rm -rf tw_ASR_version/ Tripwire-version.tar.gz

Команда “rm”, использованная выше, будет удалять все исходные коды, которые мы использовали при компиляции и инсталляции Tripwire. Она также удалит .tar.gz архив.

Конфигурации.

Все программное обеспечение, описанное в книге, имеет определенный каталог и подкаталог в архиве “floppy.tgz”, включающей все конфигурационные файлы для всех программ. Если вы скачаете этот файл, то вам не нужно будет вручную воспроизводить файлы из книги, чтобы создать свои файлы конфигурации. Скопируйте файл из архива и измените его под свои требования. Затем поместите его в соответствующее место на сервере, так как это показано ниже. Файл с конфигурациями вы можете скачать с адреса:

Для запуска Tripwire под Linux следующий файл должен быть создан или скопирован в требуемый каталог:

Копируйте файл twpol.txt в каталог “/usr/TSS/policy”.

Для запуска Tripwire следующие файлы должны быть созданы или скопированы в нужный каталог:

Копируйте файл tw.config в “/etc”.
Копируйте скрипт tripwire.verify в каталог “/etc/cron.daily”.

Вы можете взять эти файлы из нашего архива floppy.tgz.

Конфигурирование файла “/var/tmp/install.cfg”.

Помните, что Tripwire не является программой с открытыми исходными кодами, поэтому процесс компиляции не выглядит как обычно; вместо этого, вы должны модифицировать файл “install.cfg” (который будет автоматически инсталлировать Tripwire), чтобы определить в нем все необходимые пути. Мы должны это сделать так, чтобы он был совместим со структурой файловой системы Red Hat и исполняемые файлы Tripwire попали под переменную PATH.
Шаг 1

Редактируйте файл install.cfg (vi install.cfg) и измените этот файл следующим образом: # # install.cfg # # default install.cfg for: # Tripwire(R) 2.2.1 for Unix # # NOTE: Это Bourne shell скрипт, который ваши запоминает инсталляционные # параметры. Инсталлятор будет выполнять этот файл, чтобы создать # ваш конфигурационный файл, а также определит место любой # специальной конфигурации нужной для инсталляции. # Защитите этот файл, потому что в нем могут разместить вредоносный # код. # # Определите ваш корневой каталог для инсталляции, установив TWROOT= во # что-нибудь иное, чем /usr/TSS. # #======================================================= # Если CLOBBER истина, то существующие файлы будут переписываться. # Если CLOBBER ложь, то существующие файлы не переписываются. CLOBBER=false # Корень дерева каталогов TSS. TWROOT="/usr" # Исполняемые файлы Tripwire хранятся в TWBIN. TWBIN="${TWROOT}/bin" # Файлы политик Tripwire хранятся в TWPOLICY. TWPOLICY="${TWROOT}/TSS/policy" # Руководства пользователя (manual pages) Tripwire хранятся в TWMAN. TWMAN="${TWROOT}/man" # Файлы базы данных Tripwire хранятся в TWDB. TWDB="${TWROOT}/TSS/db" # Файлы ключей сайта Tripwire хранятся в TWSITEKEYDIR. TWSITEKEYDIR="${TWROOT}/TSS/key" # Файлы локальных ключей Tripwire хранятся в TWLOCALKEYDIR. TWLOCALKEYDIR="${TWROOT}/TSS/key" # Файлы отчетов Tripwire хранятся TWREPORT. TWREPORT="${TWROOT}/TSS/report" # Определяется текстовый редактор по умолчанию для Tripwire. TWEDITOR="/bin/vi" # TWLATEPROMTING контролирует место когда tripwire спрашивает пароль. TWLATEPROMPTING=false # TWLOOSEDIRCHK определяет должен ли проверяться каталог на # свойства которые могут изменяться, когда файлы в нем проверена. TWLOOSEDIRCHK=false # TWMAILNOVIOLATIONS определяет должен ли Tripwire посылать отчет # когда при проверки целостности с опцией --email-report нарушений найдено # не было. Это позволяет администратору узнать, что проверка была # произведена. TWMAILNOVIOLATIONS=true # TWEMAILREPORTLEVEL определяет словесное наполнение e-mail отчетов. TWEMAILREPORTLEVEL=3 # TWREPORTLEVEL определяет словесное наполнение печатаемых отчетов. TWREPORTLEVEL=3 # TWSYSLOG определяет должен ли Tripwire регистрировать события в # системные файлы регистраций TWSYSLOG=false ##################################### # Почтовые опции – Выберите подходящий # метод и комментируйте другие секции ##################################### ##################################### # Опции SENDMAIL – по умолчанию # # SENDMAIL или SMTP может быть использованы для отправки отчетов # через TWMAILMETHOD. # Определяет какая программа sendmail используется. ##################################### TWMAILMETHOD=SENDMAIL TWMAILPROGRAM="/usr/lib/sendmail -oi -t" ##################################### # Опции SMTP # # TWSMTPHOST выбирает SMTP сервер, используемый для отправки отчетов. # SMTPPORT выбирает SMTP порт, используемой почтовой программой SMTP. ##################################### # TWMAILMETHOD=SMTP # TWSMTPHOST="mail.domain.com" # TWSMTPPORT=25 ##################################################################### ########### # Copyright (C) 1998-2000 Tripwire (R) Security Systems, Inc. Tripwire (R) is a # registered trademark of the Purdue Research Foundation and is licensed # exclusively to Tripwire (R) Security Systems, Inc. ##################################################################### ###########

ЗАМЕЧАНИЕ. Файл “install.cfg” используются Bourne shell скриптом при инсталляции для определения конфигурационных переменных. Они определяют места куда устанавливаются файлы и предпринимаемые действия, если подобные файлы существуют.
Шаг 2

Сейчас мы должны запустить инсталляционный скрипт для установки исполняемых и сопутствующих файлов Tripwire.

Для запуска инсталляционного скрипта и установки Tripwire, используйте следующую команду:
[root@deep tmp]# ./install.sh

Замечание. Файл “install.sh” – это инсталляционный скрипт, который запускается для начала установки Tripwire.

Во время инсталляции вы будете:

Отвечать на некоторые вопросы, связанные с инсталляцией.

Задавать две парольные фразы (pass phrases) соответственно для ключа сервера и локального ключа.

Шаг 3

Когда Tripwire установится на вашу систему, она скопирует файлы “License.txt”, “README” и “Release_Notes” в каталог “/usr”. Конечно, после прочтения, вы можете спокойно удалить их следующей командой:
[root@deep /usr]# rm -f /usr/License.txt README Release_Notes

Очистка после работы.[root@deep /]# cd /var/tmp

[root@deep tmp]# rm -rf License.txt README Release-Notes install.cfg install.sh pkg/Tripwire_version_for_Linux_x86_tar.gz

Команда “rm”, использованная выше, будет удалять все исходные коды, которые мы использовали при компиляции и инсталляции Tripwire. Она также удалит .tgz архив.

Конфигурирование скрипта “/etc/cron.daily/tripwire.verify”.

“/etc/cron.daily/tripwire.verify” это небольшой скрипт, запускаемый crond-ом на вашем сервере каждый день, для сканирования жесткого диска на предмет возможных изменений в файлах и каталогах и отправки результатов по электронной почте системному администратору. Этот скрипт автоматически выполнит проверку целостности файловой системы. Если вы хотите автоматизировать эту задачу выполните шаги, описанные ниже.
Шаг 1.

Создайте скрипт tripwire.verify (touch /etc/cron.daily/tripwire.verify) и добавьте в него: #!/bin/sh /usr/sbin/tripwire -loosedir -q | (cat <<EOF Это отчет о возможных изменениях в целостности файловой системы, Автоматически созданный программой Tripwire. Чтобы сообщить Tripwire Что файлы и содержимое каталогов верно, выполните как root следующую команду:

/usr/sbin/tripwire -update [pathname|entry]

Если вы хотите войти в интерактивный режим проверки целостности и контроля сессии, выполните как root:

/usr/sbin/tripwire -interactive

Измененные файлы/каталоги включают: EOF cat ) | /bin/mail -s "Отчет о целостности файлов" root

Шаг 2

Сейчас, сделайте скрипт исполняемым и измените режим доступа к нему на 0700 следующей командой:
[root@deep /]# chmod 700 /etc/cron.daily/tripwire.verify

Инсталляция типичного Red Hat Linux

Инсталляция типичного Red Hat Linux сервера включает в среднем около 30400 файлов. Администратор не в состоянии проконтролировать целостность всех системных файлов, и если хакер получит доступ к серверу и сможет модифицировать какие-либо файлы, то вы можете об этом не узнать. Для решения этих проблем было создано несколько программ.

Согласно информации опубликованной на официальном сайте Tripwire:
Tripwire работает на самом фундаментальном уровне, защищая сервера и рабочие станции, представляющие основу корпоративной сети. Запускаемая первый раз, она сканирует компьютер и создает базу данных системных файлов, компактный цифровой “снимок” системы в безопасном состоянии. Пользователи могут настраивать Tripwire очень точно, определяя конкретные файлы и каталоги на каждой машине, или создавая стандартный шаблон, который может использоваться на всех машинах предприятия.

Как только такая базовая база данных создана, администратор может запускать Tripwire для проверки целостности системы в любое время. Она сканирует текущую систему и сравнивает результаты со своей базой. Tripwire определяет и рапортует о любых дополнения, удаления и изменениях произошедших среди контролируемых ею файлов. Если изменения правильные, то администратор может обновить базу данных новой информацией. Если были найдены злонамеренный изменения, то администратор будет знать на какую часть системы было оказано воздействие.

Эта версия Tripwire имеет значительные изменения по сравнению с предыдущей. Некоторые расширения включают:

Множество уровней сообщений позволяет вам выбрать различную информационность отчетов.

Опция Syslog посылает информация об инициализации и обновлении базы данных, изменении политики, и целостности в syslog.

Производительность базы данных может быть оптимизирована для увеличения эффективности проверки целостности

Разные разделы отчета могут быть посланы разным получателям

Поддержка отправки отчетов по почте через SMTP

Режим тестирования почты для проверки правильности почтовых настроек

Возможность создания нескольких независимо исполняемых секций с политиками

Эти инструкции предполагают.
Unix-совместимые команды.
Путь к исходным кодам “/var/tmp” (возможны другие варианты).
Инсталляция была проверена на Red Hat Linux 6.1 и 6.2.
Все шаги инсталляции осуществляются суперпользователем “root”.
Tripwire версии 2.2.1

Пакеты.

Домашняя страница Tripwire :
Вы должны скачать: Tripwire_221_for_Linux_x86_tar.gz

Раскройте тарбол:
[root@deep /]# cp Tripwire_version_for_Linux_x86_tar.gz /var/tmp
[root@deep /]# cd /var/tmp
[root@deep tmp]# tar xzpf Tripwire_version_for_Linux_x86_tar.gz

ЗАМЕЧАНИЕ. После раскрытия архива Tripwire в каталоге “/var/tmp” вы увидите файлы, связанные с Tripwire: License.txt, README, Release_Notes, install.cfg, install.sh, созданный каталог и Tripwire_version_for_Linux_x86_tar.gz.

так как она может быть

Tripwire ASR 1.3.1 это “Academic Source Release (ASR)” программы Tripwire. Лично я предпочитаю версию 1.3.1 версии 2.2.1, так как она может быть скомпилирована и инсталлирована без каких-либо проблем с совместимостью на всех версиях Linux

В задачах Tripwire ASR написано:

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

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

Эти инструкции предполагают.

Unix-совместимые команды.
Путь к исходным кодам “/var/tmp” (возможны другие варианты).
Инсталляция была проверена на Red Hat Linux 6.1 и 6.2.
Все шаги инсталляции осуществляются суперпользователем “root”.
Tripwire версии 1.3.1-1

Пакеты.

Домашняя страница Tripwire:
Вы должны скачать: Tripwire-1.3.1-1.tar.gz

Тарболы.

Хорошей идеей будет создать список файлов установленных в вашей системе до инсталляции Tripwire и после, в результате, с помощью утилиты diff вы сможете узнать какие файлы были установлены. Например,

До инсталляции:
find /* > Tripwire1

После инсталляции:
find /* > Tripwire2

Для получения списка установленных файлов:
diff Tripwire1 Tripwire2 > Tripwire-Installed

Раскройте тарбол:
[root@deep /]# cp Tripwire-version.tar.gz /var/tmp

[root@deep /]# cd /var/tmp

[root@deep tmp]# tar xzpf Tripwire-version.tar.gz

Настройка файла “/etc/tw.config”

“/etc/tw.config” это конфигурационный файл для Tripwire, в котором определяется какие файл и каталоги должны контролироваться. Обратите внимание, что при редактировании этого файла необходимы обширные испытания и опыты, прежде чем удастся получить работающие файлы отчетов. Следующий работающий пример вы можете использовать, как стартовую площадку для ваших настроек.
Шаг 1.

Создайте файл tw.config (touch /etc/tw.config) и добавьте в него все файлы и каталоги, которые вы хотите контролировать. Формат конфигурационного файла описан в его заголовке и в странице руководства (man) для tw.config (5): # Gerhard Mourani: gmourani@videotron.ca # last updated: 1999/11/12 # Первое, домашний каталог root-а /root R !/root/.bash_history / R # это ядро /boot/vmlinuz R # критичные файлы загрузки /boot R # Критичные каталоги и файлы /chroot R /etc R /etc/inetd.conf R /etc/nsswitch.conf R /etc/rc.d R /etc/mtab L /etc/motd L /etc/group R /etc/passwd L # другие популярные файловые системы /usr R /usr/local R /dev L-am /usr/etc R # исключаем home =/home R # каталог var =/var/spool L /var/log L /var/lib L /var/spool/cron L !/var/lock # особые каталоги =/proc E =/tmp =/mnt/cdrom =/mnt/floppy

Шаг 2.

Сейчас, из соображений безопасности, изменим режим доступа к этому файлу:
[root@deep /]# chmod 600 /etc/tw.config

Настройка файла “/usr/TSS/policy/twpol.txt”.

“/usr/TSS/policy/twpol.txt” – это текстовый файл политик Tripwire, где вы можете определить файлы и каталог для проверки. Обратите внимание, что при редактировании этого файла необходимы обширные испытания и опыты, прежде чем удастся получить работающие файлы отчетов. Следующий работающий пример вы можете использовать, как стартовую площадку для ваших настроек.
Шаг 1.

Вы должны редактировать файл политик, заданный по умолчанию, для получения вашей версии. Файл “policyguide.txt” в каталоге “/usr/TSS/policy” может вам помочь. Откройте файл “twpol.txt” в текстовом редакторе (vi /usr/TSS/policy/twpol.txt) и измените все, что нужно: @@section GLOBAL TWROOT="/usr"; TWBIN="/usr/bin"; TWPOL="/usr/TSS/policy"; TWDB="/usr/TSS/db"; TWSKEY="/usr/TSS/key"; TWLKEY="/usr/TSS/key"; TWREPORT="/usr/TSS/report"; HOSTNAME=deep.openna.com; @@section FS SEC_CRIT = $(IgnoreNone)-SHa; # Критические файлы – мы не можем пропустить любые изменения. SEC_SUID = $(IgnoreNone)-SHa; # Исполняемые с установленными флагами SUID или SGID. SEC_TCB = $(ReadOnly); # Члены базы доверенных компьютеров (Trusted Computing Base). SEC_BIN = $(ReadOnly); # Исполняемые, которые не должны изменяться SEC_CONFIG = $(Dynamic); # Конфигурационные файлы, которые изменяются редко, но часто читаются. SEC_LOG = $(Growing); # Файлы, которые растут, но которые никогда не должны изменять монопольное использование. SEC_INVARIANT = +pug; # Каталоги, которые никогда не изменяют права доступа и владельца. SIG_LOW = 33; # Не критичные файлы, которые имеют минимальный риск при проведении атаки SIG_MED = 66; # Не критичные файлы, которые важны при ударе по безопасности SIG_HI = 100; # Критические файлы, которые являются важным местом уязвимости # Исполняемы файлы Tripwire (emailto = admin@openna.com, rulename = "Tripwire Binaries", severity = $(SIG_HI)) { $(TWBIN)/siggen -> $(ReadOnly); $(TWBIN)/tripwire -> $(ReadOnly); $(TWBIN)/twadmin -> $(ReadOnly); $(TWBIN)/twprint -> $(ReadOnly); } # Файлы данных Tripwire – конфигурационные файлы, файлы политик, ключи, отчеты, базы данных (emailto = admin@openna.com, rulename = "Tripwire Data Files", severity = $(SIG_HI)) { # Замечание: Удаляем атрибут inode, потому что когда Tripwire создает # резервные копии он переименовывает старый файл и создает новый # (который будет иметь новый номер inode). Оставляем inode включенным # для ключей, которые никогда не должны изменяться. # ЗАМЕЧАНИЕ. это правило будет срабатывать при первой проверки целостности # после инициализации базы данных и каждый раз при проверке целостности # позже, пока не будет выполнена модификация базы данных, так как база # данных не будет существовать до этого момента $(TWDB) -> $(Dynamic) -i; $(TWPOL)/tw.pol -> $(SEC_BIN) -i; $(TWBIN)/tw.cfg -> $(SEC_BIN) -i; $(TWLKEY)/$(HOSTNAME)-local.key -> $(SEC_BIN) ; $(TWSKEY)/site.key -> $(SEC_BIN) ; # не сканировать персональные отчеты $(TWREPORT) -> $(Dynamic) (recurse=0); } # Эти файлы критичны для корректной загрузки системы. (emailto = admin@openna.com, rulename = "Critical system boot files", severity = 100) { /boot -> $(SEC_CRIT) ; !/boot/System.map ; !/boot/module-info ; } # Эти файлы изменяют поведение бюджета root (emailto = admin@openna.com, rulename = "Root config files", severity = 100) { /root -> $(SEC_CRIT) ; /root/.bash_history -> $(SEC_LOG) ; } # Общедоступные каталоги, которые должны оставаться статическими # относительно владельца и группы (emailto = admin@openna.com, rulename = "Invariant Directories", severity = $(SIG_MED)) { / -> $(SEC_INVARIANT) (recurse = 0); /home -> $(SEC_INVARIANT) (recurse = 0); /etc -> $(SEC_INVARIANT) (recurse = 0); /chroot -> $(SEC_INVARIANT) (recurse = 0); /cache -> $(SEC_INVARIANT) (recurse = 0); } (emailto = admin@openna.com, rulename = "Shell Binaries") { /bin/bsh -> $(SEC_BIN); /bin/csh -> $(SEC_BIN); /bin/sh -> $(SEC_BIN); } # Месторасположение критичных исполняемых файлов (emailto = admin@openna.com, rulename = "OS executables and libraries", severity = $(SIG_HI)) { /bin -> $(ReadOnly) ; /lib -> $(ReadOnly) ; } # Локальные файлы (emailto = admin@openna.com, rulename = "User binaries", severity = $(SIG_MED)) { /sbin -> $(SEC_BIN) (recurse = 1); /usr/sbin -> $(SEC_BIN) (recurse = 1); /usr/bin -> $(SEC_BIN) (recurse = 1); } # Каталоги с временными файлами (emailto = admin@openna.com, rulename = "Temporary directories", recurse = false, severity = $(SIG_LOW)) { /usr/tmp -> $(SEC_INVARIANT); /var/tmp -> $(SEC_INVARIANT); /tmp -> $(SEC_INVARIANT); } # Библиотеки (emailto = admin@openna.com, rulename = "Libraries", severity = $(SIG_MED)) { /usr/lib -> $(SEC_BIN); } # Включаемы файлы (Include) (emailto = admin@openna.com, rulename = "OS Development Files", severity = $(SIG_MED)) { /usr/include -> $(SEC_BIN); } # Разделяемые (Shared) (emailto = admin@openna.com, rulename = "OS Shared Files", severity = $(SIG_MED)) { /usr/share -> $(SEC_BIN); } # Заголовочные файлы ядра (emailto = admin@openna.com, rulename = "Kernel Headers Files", severity = $( SIG_HI)) { /usr/src/linux-2.2.14 -> $(SEC_BIN); } # setuid/setgid root программы (emailto = admin@openna.com, rulename = "setuid/setgid", severity = $(SIG_HI)) { /bin/su -> $(SEC_SUID); /sbin/pwdb_chkpwd -> $(SEC_SUID); /sbin/dump -> $(SEC_SUID); /sbin/restore -> $(SEC_SUID); /usr/bin/at -> $(SEC_SUID); /usr/bin/passwd -> $(SEC_SUID); /usr/bin/suidperl -> $(SEC_SUID); /usr/bin/crontab -> $(SEC_SUID); /usr/sbin/sendmail -> $(SEC_SUID); /usr/bin/man -> $(SEC_SUID); /usr/bin/sperl5.00503 -> $(SEC_SUID); /usr/bin/slocate -> $(SEC_SUID); /usr/sbin/utempter -> $(SEC_SUID); /sbin/netreport -> $(SEC_SUID); } (emailto = admin@openna.com, rulename = "Configuration Files") { /etc/hosts -> $(SEC_CONFIG); /etc/inetd.conf -> $(SEC_CONFIG); /etc/initlog.conf -> $(SEC_CONFIG); /etc/inittab -> $(SEC_CONFIG); /etc/resolv.conf -> $(SEC_CONFIG); /etc/syslog.conf -> $(SEC_CONFIG); } (emailto = admin@openna.com, rulename = "Security Control") { /etc/group -> $(SEC_CRIT); /etc/security/ -> $(SEC_CRIT); /lib/security/ -> $(SEC_CRIT); /var/spool/cron -> $(SEC_CRIT); } (emailto = admin@openna.com, rulename = "Login Scripts") { /etc/csh.login -> $(SEC_CONFIG); /etc/profile -> $(SEC_CONFIG); } # Эти файлы изменяются при каждой загрузке системы (emailto = admin@openna.com, rulename = "System boot changes", severity = $(SIG_HI)) { /dev/log -> $(Dynamic) ; /dev/cua0 -> $(Dynamic) ; /dev/console -> $(Dynamic) ; /dev/tty2 -> $(Dynamic) ; # tty devices /dev/tty3 -> $(Dynamic) ; # are extremely /dev/tty4 -> $(Dynamic) ; # variable /dev/tty5 -> $(Dynamic) ; /dev/tty6 -> $(Dynamic) ; /dev/urandom -> $(Dynamic) ; /dev/initctl -> $(Dynamic) ; /var/lock/subsys -> $(Dynamic) ; /var/run -> $(Dynamic) ; # daemon PIDs /var/log -> $(Dynamic) ; /etc/ioctl.save -> $(Dynamic) ; /etc/.pwd.lock -> $(Dynamic) ; /etc/mtab -> $(Dynamic) ; /lib/modules -> $(Dynamic) ; } # Критические конфигурационные файлы (emailto = admin@openna.com, rulename = "Critical configuration files", severity = $(SIG_HI)) { /etc/conf.modules -> $(ReadOnly) ; /etc/crontab -> $(ReadOnly) ; /etc/cron.hourly -> $(ReadOnly) ; /etc/cron.daily -> $(ReadOnly) ; /etc/cron.weekly -> $(ReadOnly) ; /etc/cron.monthly -> $(ReadOnly) ; /etc/default -> $(ReadOnly) ; /etc/fstab -> $(ReadOnly) ; /etc/group- -> $(ReadOnly) ; # изменения должны быть не частыми /etc/host.conf -> $(ReadOnly) ; /etc/hosts.allow -> $(ReadOnly) ; /etc/hosts.deny -> $(ReadOnly) ; /etc/lilo.conf -> $(ReadOnly) ; /etc/logrotate.conf -> $(ReadOnly) ; /etc/pwdb.conf -> $(ReadOnly) ; /etc/securetty -> $(ReadOnly) ; /etc/sendmail.cf -> $(ReadOnly) ; /etc/protocols -> $(ReadOnly) ; /etc/services -> $(ReadOnly) ; /etc/rc.d/init.d -> $(ReadOnly) ; /etc/rc.d -> $(ReadOnly) ; /etc/motd -> $(ReadOnly) ; /etc/passwd -> $(ReadOnly) ; /etc/passwd- -> $(ReadOnly) ; /etc/profile.d -> $(ReadOnly) ; /etc/rpc -> $(ReadOnly) ; /etc/sysconfig -> $(ReadOnly) ; /etc/shells -> $(ReadOnly) ; /etc/nsswitch.conf -> $(ReadOnly) ; } # Критичные устройства (emailto = admin@openna.com, rulename = "Critical devices", severity = $(SIG_HI), recurse = false) { /dev/kmem -> $(Device) ; /dev/mem -> $(Device) ; /dev/null -> $(Device) ; /dev/zero -> $(Device) ; /proc/devices -> $(Device) ; /proc/net -> $(Device) ; /proc/tty -> $(Device) ; /proc/sys -> $(Device) ; /proc/cpuinfo -> $(Device) ; /proc/modules -> $(Device) ; /proc/mounts -> $(Device) ; /proc/dma -> $(Device) ; /proc/filesystems -> $(Device) ; /proc/ide -> $(Device) ; /proc/interrupts -> $(Device) ; /proc/ioports -> $(Device) ; /proc/scsi -> $(Device) ; /proc/kcore -> $(Device) ; /proc/self -> $(Device) ; /proc/kmsg -> $(Device) ; /proc/stat -> $(Device) ; /proc/ksyms -> $(Device) ; /proc/loadavg -> $(Device) ; /proc/uptime -> $(Device) ; /proc/locks -> $(Device) ; /proc/version -> $(Device) ; /proc/meminfo -> $(Device) ; /proc/cmdline -> $(Device) ; /proc/misc -> $(Device) ; }

ЗАМЕЧАНИЕ. Это пример файла политик, который мы вам предоставляем, конечно, вы должны модифицировать его под вашу систему.
Шаг 2

Так как мы уже готовы использовать наш файл политик в первый раз, инсталлируйте его следующей командой:
[root@deep /]# twadmin --create-polfile /usr/TSS/policy/twpol.txt

Please enter your site passphrase:

Wrote policy file: /usr/TSS/policy/tw.pol

Некоторые возможные места использования Tripwire

Tripwire может быть использован для:

Проверки целостности файловой системы.

Получения списка новых инсталлированных или удаленных файлов в вашей системе.

Организация защиты Tripwire.

Рекомендуется, из соображений безопасности, переместить базы данных Tripwire (tw.db_[hostname]) в какое-либо место (например, на дискету), где они не могут быть модифицированы. Это важно, потому что данные Tripwire заслуживают такого же доверия, что и ее базы данных. Также рекомендуется сделать сразу распечатку базы данных. Если вы начнете подозревать, что целостность вашей базы данных нарушена, то сможете вручную проверить ее.

Организация защиты Tripwire для Linux

Важно удостовериться, что целостность системы уже не была нарушена. Для максимальной безопасности вашей основной базы данных, вы должны инсталлировать систему с оригинальных носителей. Также рекомендуется удалить текстовую копию конфигурационного файла Tripwire “twcfg.txt”, расположенного в каталоге “/usr/bin”, для сокрытия месторасположения файлов Tripwire и предотвращения создания альтернативного конфигурационного файла.
[root@deep /]# rm -f /usr/bin/twcfg.txt

Дополнительная документация.

Чтобы получить больше информации, читайте следующие страницы руководства:

$ man edquota (8) – редактирование пользовательских квот
$ man quota (1) – вывод информации об использовании диска и ограничениях
$ man quotacheck (8) – сканирование файловой системы о использовании диска
$ man quotactl (2) – манипулирование дисковыми квотами
$ man quotaon, quotaoff (8) – включение или выключение квот на файловой системе
$ man repquota (8) – суммирование квот на файловой системе
$ man rquota (3) – осуществление квот на удаленной машине

Инсталлированные файлы

> /usr/bin/gpg > /usr/lib/gnupg > /usr/lib/gnupg/rndunix > /usr/lib/gnupg/rndegd > /usr/lib/gnupg/tiger > /usr/man/man1/gpg.1 > /usr/share/gnupg > /usr/share/gnupg/options.skel

Команды.

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

Для создания новой пары ключей используйте следующую команду:
[root@deep /]# gpg --gen-key

This program comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it

under certain conditions. See the file COPYING for details.

gpg: /root/.gnupg: directory created

gpg: /root/.gnupg/options: new options file created

gpg: you have to start GnuPG again, so it can read the new options file

This asks some questions and then starts key generation.

Шаг 2

Мы вновь запускаем GnuPG следующей командой:
[root@deep /]# gpg --gen-key

This program comes with ABSOLUTELY NO WARRANTY.

This is free software, and you are welcome to redistribute it

under certain conditions. See the file COPYING for details.

gpg: /root/.gnupg/secring.gpg: keyring created

gpg: /root/.gnupg/pubring.gpg: keyring created

Please select what kind of key you want:

(1) DSA and ElGamal (default)

(2) DSA (sign only)

(4) ElGamal (sign and encrypt)

Your selection? 1

DSA keypair will have 1024 bits.

About to generate a new ELG-E keypair.

minimum keysize is 768 bits

default keysize is 1024 bits

highest suggested keysize is 2048 bits

What keysize do you want? (1024) 2048

Do you really need such a large keysize? y

Requested keysize is 2048 bits

Please specify how long the key should be valid.

0 = key does not expire

<n> = key expires in n days

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

Для подписания ключа компании Red Hat, который мы добавили выше, используйте команду:
[root@deep /]# gpg --sign-key <UID>

Например:
[root@deep /]# gpg --sign-key RedHat

pub 1024D/DB42A60E created: 1999-09-23 expires: never trust: -/q

sub 2048g/961630A2 created: 1999-09-23 expires: never

(1) Red Hat, Inc <security@redhat.com>

pub 1024D/DB42A60E created: 1999-09-23 expires: never trust: -/q

Fingerprint: CA20 8686 2BD6 9DFC 65F6 ECC4 2191 80CD DB42 A60E

Red Hat, Inc <security@redhat.com>

Are you really sure that you want to sign this key

with your key: "Gerhard Mourani <gmourani@videotron.ca>"

Really sign? y

You need a passphrase to unlock the secret key for

user: "Gerhard Mourani <gmourani@videotron.ca>"

1024-bit DSA key, ID E92D6C97, created 1999-12-30

Enter passphrase:

ЗАМЕЧАНИЕ. Вы должны подписывать ключ только когда абсолютно уверенны, что ключ действительно настоящий! Вы никогда не должны подписывать ключ, базирующийся на любых предположении.
Шифрование и дешифрование

После инсталляции, импортирования, подписания и конфигурирования мы можем начать шифровать и расшифровывать нашу работу.

Для шифрования и подписания данных для пользователя RedHat, ключ которого мы добавили выше, используйте следующую команду:
[root@deep /]# gpg -sear RedHat <file>

Например:
[root@deep /]# gpg -sear RedHat message-to-RedHat.txt

You need a passphrase to unlock the secret key for

user: "Gerhard Mourani (Open Network Architecture) <gmourani@videotron.ca>"

1024-bit DSA key, ID BBB4BA9B, created 1999-10-26

Enter passphrase:

Аргументы, которые использовались обозначают следующее, “s” – подписание (уменьшение риска что кто-то попытается представиться вами, очень полезно подписывать все, что вы шифруете), “e” - шифрование, “a” – создание ASCII защищенного вывода (“.asc” готовые для отправки по почте), “r” – шифрование имени идентификатора пользователя и <file> это сообщение, которое вы хотите зашифровать.

Для расшифровки данных используйте следующую команду:
[root@deep /]# gpg -d <file>

Например:
[root@deep /]# gpg -d message-to-Gerhard.asc

You need a passphrase to unlock the secret key for

user: "Gerhard Mourani (Open Network Architecture) <gmourani@videotron.ca>"

2048-bit ELG-E key, ID 71D4CC44, created 1999-10-26 (main key ID BBB4BA9B)

Enter passphrase:

Где “-d” означает расшифровку и <file> сообщение, которое вы хотите расшифровать. Важно, чтобы публичный ключ отправителя сообщения, которое мы хотим расшифровать, был в нашей базе ключей или ничего работать не будет.
Экспортирование вашего публичного ключа.

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

• Для извлечения вашего публичного ключа в ASCII защищенный вывод используйте команду:
[root@deep /]# gpg --export --armor > Public-key.asc

где “--export” для извлечения вашего публичного ключа из зашифрованного файла, “--armor” создать ASCII защищенный вывод, который вы можете отправлять, публиковать или выкладывать на веб-странице и “> Public-key.asc” говорит, что результат надо поместить в файл с именем Public-key.asc.
Проверка signature

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

• Для проверки сигнатуры шифрованных данных используйте команду:
[root@deep /]# gpg --verify <Data>

Опция “--verify” будет проверять сигнатуру, а <Data> - зашифрованные данные/файл, который вы хотите проверить.

Компиляция и оптимизация.

Переместитесь в новый каталог GnuPG и выполните следующие команды:
CC="egcs" \

CFLAGS="-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions" \

./configure \

--prefix=/usr \

--enable-shared

[root@deep gnupg-1.0.1]# make

[root@deep gnupg-1.0.1]# make check

[root@deep gnupg-1.0.1]# make install

[root@deep gnupg-1.0.1]# strip /usr/bin/gpg

команда make компилирует исходные коды в исполняемые двоичные файлы;
команда make check запускает все тесты, входящие в пакет;
команда make install инсталлирует исполняемые и сопутствующие им файлы в определенный каталог;
strip будет уменьшать размер, увеличивая производительность программы.
Очистка после работы.

[root@deep /]# cd /var/tmp

[root@deep tmp]# rm -rf gnupg-version/ gnupg-version.tar.gz

Команда “rm”, использованная выше, будет удалять все исходные коды, которые мы использовали при компиляции и инсталляции GnuPG. Она также удалит .tar.gz архив.

Linux GnuPG

Краткий обзор.

Шифрование данных это бесценная возможность, которая сильно увеличивает конфиденциальность вашей работы. Утилиты подобные GnuPG делаю намного больше, чем просто шифруют почтовые сообщения. Они могут быть использованы для всех видов шифрования данных и их использование может быть ограничено только вашей фантазией. RPM пакет GnuPG уже может быть инсталлирован на вашем компьютере, но эта версия не является последней и поэтому мы рекомендуем инсталлировать последний релиз соответствующий вашему серверу и архитектуре CPU.

Согласно официальному README файлу GnuPG:

GnuPG – это GNU утилита для безопасной передачи информации и хранения данных. Она может быть использована для шифрования данных и создания цифровых сигнатур. GnuPG включает продвинутый менеджер ключей и совместима с OpenPGP Internet стандартом, описанном в RFC2440. Так как GnuPG не использует каких-либо патентованных алгоритмов, она не может быть совместима с PGP2. PGP 2.x использует только IDEA (запатентован) и RSA (который запатентован в США до 20 сентября 2000).

Эти инструкции предполагают.

Unix-совместимые команды.
Путь к исходным кодам “/var/tmp” (возможны другие варианты).
Инсталляция была проверена на Red Hat Linux 6.1 и 6.2.
Все шаги инсталляции осуществляются суперпользователем “root”.
GnuPG версии 1.0.1

Пакеты.

Домашняя страница GnuPG:
Вы должны скачать: gnupg-1.0.1.tar.gz

Тарболы.

Хорошей идеей будет создать список файлов установленных в вашей системе до инсталляции GnuPG и после, в результате, с помощью утилиты diff вы сможете узнать какие файлы были установлены. Например,

До инсталляции:
find /* > GnuPG1

После инсталляции:
find /* > GnuPG2

Для получения списка установленных файлов:
diff GnuPG1 GnuPG2 > GnuPG

Раскройте тарбол:
[root@deep /]# cp gnupg-version.tar.gz /var/tmp

[root@deep /]# cd /var/tmp

[root@deep tmp]# tar xzpf gnupg-version.tar.gz

Модификация файла “/etc/fstab”

Файл “/etc/fstab” содержит информацию обо всех файловых системах, инсталлированных на вашем Linux сервере. Квоты должны быть включены в нем, чтобы их можно было использовать. Так как квоты должны быть определены для каждой файловой системы независимо и каждая файловая система описывается в файле “/etc/fstab” в отдельной строке, то квота должна быть установлена для каждой строки, где вы хотите включить их поддержку. Используя прорамму квота, в зависимости от ваших нужд, вы можете включить квоты только для групп, пользователей или и тех и других одновременно. Для всех нижеприведенных примеров, мы используем каталог “/home”, размещенный на разделе “/dev/sda6”.
Возможность 1.

Для включения квот для пользователей на определенной файловой системы, отредактируйте ваш “/etc/fstab” файл (vi /etc/fstab) и добавьте опцию "usrquota" в четвертое поле после слова "defaults" или любой другой опции.

Например:
/dev/sda6 /home ext2 defaults 1 2 (как пример: слово “defaults”)

/dev/sda6 /home ext2 nosuid,nodev 1 2 (как пример: любая другая опция)

Должен читаться:
/dev/sda6 /home ext2 defaults,usrquota 1 2

/dev/sda6 /home ext2 nosuid,nodev,usrquota 1 2

Возможность 2.

Для включения квот для групп на определенной файловой системы, отредактируйте ваш “/etc/fstab” файл (vi /etc/fstab) и добавьте опцию "grpquota" в четвертое поле после слова "defaults" или любой другой опции.

Например:
/dev/sda6 /home ext2 defaults 1 2 (как пример: слово “defaults”)

/dev/sda6 /home ext2 nosuid,nodev 1 2 (как пример: любая другая опция)

Должен читаться:
/dev/sda6 /home ext2 defaults,grpquota 1 2

/dev/sda6 /home ext2 nosuid,nodev,grpquota 1 2

Возможность 3.

Для включения квот для пользователей и групп на определенной файловой системы, отредактируйте ваш “/etc/fstab” файл (vi /etc/fstab) и добавьте опции "usrquota, grpquota" в четвертое поле после слова "defaults" или любой другой опции.

Например:
/dev/sda6 /home ext2 defaults 1 2 (как пример: слово “defaults”)

/dev/sda6 /home ext2 nosuid,nodev 1 2 (как пример: любая другая опция)

Должен читаться:
/dev/sda6 /home ext2 defaults,usrquota,grpquota 1 2

/dev/sda6 /home ext2 nosuid,nodev,usrquota,grpquota 1 2

Назначение квот для Пользователей и групп

После того, как система перезагрузилась, вы можете назначить квоты пользователям и группам пользователей. Это операция осуществляется при помощи команды “edquota”. edquota (8).
Программа edquota.

Edquota – это редактор квот, который создает временный файл с текущими дисковыми квотами, используемый пользователем “root” для их установки для пользователей и групп пользователей. Нижеприведенный пример покажет как установить квоты для пользователя и группы пользователей.
Установка квоты для пользователя.

Предположим, для примера, что у вас есть пользователь с именем “wahib”. Следующая команда вызывает редактор (vi), чтобы изменить и установить квоты для пользователя “wahib” на каждый раздел, где включены квоты:
Шаг 1

Для редактирования и можификации квот для пользователя “wahib” используйте следующую команду:
[root@deep /]# edquota -u wahib

Quotas for user wahib:

/dev/sda6: blocks in use: 6, limits (soft = 0, hard = 0)

inodes in use: 5, limits (soft = 0, hard = 0)

После выполнения этой команды, вы увидите на экране строки связанные с пользователем “wahib”. "blocks in use:" отображает общее число блоков (в килобайтах) расходуемых пользователем на разделе. "inodes in use:" отображает общее число файлов, которое имеет пользователь на разделе. Эти параметры (“blocks in use, and inodes in use”) контролируются и устанавливаются автоматически системой и вы не можете установить или изменить их.
Шаг 2

Назначим 5MB квоту для пользователя “wahib”, изменив следующие параметры в редакторе vi:
Quotas for user wahib:

/dev/sda6: blocks in use: 6, limits (soft = 0, hard = 0)

inodes in use: 5, limits (soft = 0, hard = 0)

Должна читаться:
Quotas for user wahib:

/dev/sda6: blocks in use: 6, limits (soft = 5000, hard = 0)

inodes in use: 5, limits (soft = 0, hard = 0)

“soft limit” (soft =) определяет максимальное количество дискового пространства, которое пользователь может иметь.
“hard limit” (hard =) определяет абсолютное ограничение использования пользоватлем дискового пространства. Пользователь не может превзойти его. Следует заметить, что “hard limit” работает только когда установлен параметр “grace period”.
Параметр grace period

Параметр “ grace period” позволяет вам установить время, прежде чем значение soft limit будет приведено в жизнь на файловой системе с включенными квотами. Например этот параметр может быть использован для предупреждения ваших пользователей о новой политике, которая установит дисковую квоту в 5MB на их домашний каталог через 7 дней. Вы можете установить это значение в 0 дней (по умолчанию) для любого отрезка времени. Чтобы изменить это требуется два следующих шага (в моем примере я принимаю 7 дней).
Шаг 1

Редактируем значение по умолчанию параметра период любезности (grace period), используя следующую команду:
[root@deep /]# edquota -t

Time units may be: days, hours, minutes, or seconds

Grace period before enforcing soft limits for users:

/dev/sda6: block grace period: 0 days, file grace period: 0 days

Шаг 2

Модифицируем период любезности (grace period) до 7 дней. Измените или установите следующие параметры в редакторе vi:
Time units may be: days, hours, minutes, or seconds

Grace period before enforcing soft limits for users:

/dev/sda6: block grace period: 0 days, file grace period: 0 days

Должно читаться:
Time units may be: days, hours, minutes, or seconds

Grace period before enforcing soft limits for users:

/dev/sda6: block grace period: 7 days, file grace period: 7 days

Замечание. Команда “edquota -t” редактирует параметр soft time limits для каждой файловой системы с включенными квотами.
Назначение квот для отдельных групп

Предположим, например, что у вас есть группа с именем “webusers”. Следующая команда вызовет редактор vi для редактирования квот для группы “webusers” на каждой файловой системе, где квоты разрешены.:
[root@deep /]# edquota -g webusers

Quotas for group webusers:

/dev/sda6: blocks in use: 6, limits (soft = 0, hard = 0)

inodes in use: 6, limits (soft = 0, hard = 0)

Процедура такая же как и при назначении квот для пользователей; как описано выше, вы должны модифицировать параметр “soft =” и записать изменения.
Назначение квот для групп пользователей с теми же значениями

Программа edquota имеет специальную опцию (-p), которая назначает квоты для групп пользователей с некоторым значением назначенным при инициализации пользователя. Допустим, вы хотите назначить пользователям UID-ы которых начинаются с 500 то же значение, что и для пользователя “wahib”. Сперва, мы редактируем квоты для пользователя “wahib”, а затем выполняем следующую команду:
[root@deep /]# edquota -p wahib `awk -F: '$3 > 499 {print $1}' /etc/passwd`

Программа edquota будет дуплицировать квоты, которые установлены для пользователя “wahib”, на всех пользователей с UID больше 499 из файла “/etc/passwd”

Некоторые области применения GnuPG

GnuPG может быть использован:

Отправки зашифрованных почтовых сообщений.

Шифрование резервных копий файлов перед отправкой через сеть.

Шифрование личных чувствительных фалов (например, файл содержащий все ваши пароли).

Создание файлов "quota.user" и "quota.group"

После модификации файла “/tc/fstab”, чтобы квоты начали действовать, в корневой каталог файловой системы (например, “/home”) помещается файл “quota.user”, если вы хотите использовать пользовательские квоты, или “quota.group”, для групповых квот, или и тот и другой для комбинированных квот. Владельцем обоих файлов является “root”.

Шаг 1.

Для создания файлов “quota.user” и/или “quota.group”, как “root” перейдите в корневой каталог раздела, где вы хотите активизировать квоты (например, /home), создайте “quota.user” и/или “quota.group”, для этого выполните следующие команды:
[root@deep /]# touch /home/quota.user

[root@deep /]# touch /home/quota.group

[root@deep /]# chmod 600 /home/quota.user

[root@deep /]# chmod 600 /home/quota.group

Команда “touch” будет создавать новые пустые файлы в каталоге “home” с именами “quota.user” и “quota.group”. Команда “chmod” будет устанавливать права доступа к этим файлам в чтение-запись только для root.

ЗАМЕЧАНИЕ. Оба файла “quota.user” и “quota.group”, должны принадлежать root, с правами чтение-запись только для владельца.
Шаг 2

Сейчас мы должны инициализировать файлы “quota.user” и “quota.group” в корневом каталоге файловой системы, чтобы не получать сообщений об ошибках о квотах во время перезагрузки сервера.

Для инициализации файлов “quota.user” и/или “quota.group”, используйте следующие команды:
[root@deep /]# edquota -u wahib

[root@deep /]# edquota -g wahib

Вышеприведенные команды необходимы только для инициализации файлов “quota.user” и/или “quota.group”; команда edquota (-u) будет редактировать квоты для пользователя “wahib” и (-g) будет редактировать квоты для группы. Заметим, что вы должны редактировать существующие в вашей системе UID/GID, чтобы инициализация файлов прошла успешно.
Шаг 3

После того как вы закончили устанавливать необходимые опции в файле “/etc/fstab”, создали и инициализировали файлы “quota.users” и/или “quota.group”, вы должны перезагрузить систему, чтобы внесенные изменения в файлы “/etc/fstab”, “quota.user” и/или “quota.group” вступили в силу. Для перезагрузки системы используйте следующую команду:
[root@deep /]# reboot

Создание ядра с поддержкой квот

Первое, что вам необходимо сделать, это создать ядро с поддержкой квот. В ядре 2.2.14 надо удостовериться, что вы ответили “Y” на вопрос:
Filesystems

Quota support (CONFIG_QUOTA) [N/y/?] Y

ЗАМЕЧАНИЕ. Если при компиляции ядра вы руководствовались соответствующей главой из этой книги, то поддержка квот у вас включена.

Установка поддержки квот на вашей Linux системе.

Краткий обзор.

Квота – это административная утилита для мониторинга и ограничения использования дискового пространства пользователями и группами на каждой файловой системе. Существует две возможных способа ограничений использования дисков. Первый, это число inode-ов (число файлов), которым может владеть пользователь или группа. Второй, число дисковых блоков (суммарное пространство в килобайтах), которое может выделяться в использование пользователю или группе. При помощи квот, системный администратор принуждает пользователя не расходовать неограниченный объем дискового пространства. Эта программа оперирует отдельно каждым пользователем и каждой файловой системой, поэтому для каждой файловой системы нужно определять квоты отдельно.

Административные средства DNS

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

dig

Утилита “dig” (domain information groper) может быть использована для обновления файла “db.cache”, который говорит вашему серверу какие сервера отвечают за корневую зоны. Такие сервера изменяются чрезвычайно редко. Хорошей идеей будет обновлять ваш файл каждые один-два месяца.

Используйте следующую команду для получения нового файла db.cache:

[root@deep /]# dig @.aroot-servers.net . ns > db.cache

Копируйте, полученный файл db.cache в каталог /var/named/.

[root@deep /]# cp db.cache /var/named/

Где @a.root-servers.net – это адрес root сервера у которого вы спрашиваете о новой файле db.cache и db.cache – имя вашего нового db.cache файла.

ndc

Утилита “ndc”, входящая в ISC BIND/DNS, позволяет системному администратору из терминала интерактивно контролировать деятельность сервера имен.

Наберите на вашем терминале ndc и затем help, чтобы увидеть список доступных команд.

[root@deep /]# ndc

Type help -or- /h if you need help.

ndc> help

getpid

status

stop

exec

reload [zone] ...

reconfig (just sees new/gone zones)

dumpdb

stats

trace [level]

notrace

querylog

qrylog

help

quit

ndc> /e

Инсталлированные файлы.

> /etc/rc.d/init.d/named > /etc/rc.d/rc0.d/K45named > /etc/rc.d/rc1.d/K45named > /etc/rc.d/rc2.d/K45named > /etc/rc.d/rc3.d/K45named > /etc/rc.d/rc4.d/K45named > /etc/rc.d/rc5.d/K45named > /etc/rc.d/rc6.d/K45named > /etc/named.conf > /usr/bin/addr > /usr/bin/nslookup > /usr/bin/dig > /usr/bin/dnsquery > /usr/bin/host > /usr/bin/nsupdate > /usr/bin/mkservdb > /usr/lib/bind > /usr/lib/bind/include/hesiod.h > /usr/lib/bind/include/sys > /usr/lib/bind/include/net > /usr/lib/bind/lib > /usr/lib/bind/lib/libbind.a > /usr/lib/bind/lib/libbind_r.a > /usr/lib/nslookup.help > /usr/man/man1/dig.1 > /usr/man/man1/host.1 > /usr/man/man1/dnsquery.1 > /usr/man/man1/dnskeygen.1 > /usr/man/man3/hesiod.3 > /usr/man/man3/gethostbyname.3 > /usr/man/man3/inet_cidr.3 > /usr/man/man3/resolver.3 > /usr/man/man3/getnetent.3 > /usr/man/man3/tsig.3 > /usr/lib/bind/include > /usr/lib/bind/include/arpa > /usr/lib/bind/include/arpa/inet.h > /usr/lib/bind/include/arpa/nameser.h > /usr/lib/bind/include/arpa/nameser_compat.h > /usr/lib/bind/include/isc > /usr/lib/bind/include/isc/eventlib.h > /usr/lib/bind/include/isc/misc.h > /usr/lib/bind/include/isc/tree.h > /usr/lib/bind/include/isc/logging.h > /usr/lib/bind/include/isc/heap.h > /usr/lib/bind/include/isc/memcluster.h > /usr/lib/bind/include/isc/assertions.h > /usr/lib/bind/include/isc/list.h > /usr/lib/bind/include/isc/dst.h > /usr/lib/bind/include/isc/irpmarshall.h > /usr/lib/bind/include/netdb.h > /usr/lib/bind/include/resolv.h > /usr/lib/bind/include/res_update.h > /usr/lib/bind/include/irs.h > /usr/lib/bind/include/irp.h > /usr/man/man3/getaddrinfo.3 > /usr/man/man3/getipnodebyname.3 > /usr/man/man5/resolver.5 > /usr/man/man5/irs.conf.5 > /usr/man/man5/named.conf.5 > /usr/man/man7/hostname.7 > /usr/man/man7/mailaddr.7 > /usr/man/man8/named.8 > /usr/man/man8/ndc.8 > /usr/man/man8/named-xfer.8 > /usr/man/man8/named-bootconf.8 > /usr/man/man8/nslookup.8 > /usr/man/man8/nsupdate.8 > /usr/sbin/ndc > /usr/sbin/named > /usr/sbin/named-xfer > /usr/sbin/irpd > /usr/sbin/dnskeygen > /usr/sbin/named-bootconf > /var/named

Кэширующий сервер имен

Кэширующий сервер имен не авторитетен для любых доменов, кроме 0.0.127.in- addr.arpa (localhost). Он ищет имена как внутри, так и за пределами ваших зон, как на первичных, так и на подчиненных серверах. В отличии от них, кэширующий сервер инициирует поиск имен в пределах вашей зоны, спрашивая один из первичных или подчиненных серверов.

Файлы необходимые для установки простого кэширующего сервера имен:

named.conf

db.127.0.0

db.cache

скрипт named

Конфигурация файла “/etc/named.conf” для простого кэширующего сервера имен.

Используйте эту конфигурацию для всех серверов в вашей сети, которые не выступают как основной или подчиненный сервера имен. Установка простого кэширующего севера на локальной клиентской машине уменьшит загрузку первичного сервера. Многие пользователи, использующие dialup соединения, могут использовать эту конфигурацию. Создайте файл named.conf (touch /etc/named.conf) и добавьте в него следующие строки:

options { directory "/var/named"; forwarders { 208.164.186.1; 208.164.186.2; }; forward only; }; // // a caching only nameserver config zone "." in { type hint; file "db.cache"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; };

В строке “forwarder” 208.164.186.1 и 208.164.186.2 это IP адреса ваших основного (Master) и подчиненного (Slave) BIND/DNS серверов. Это могут быть также адреса DNS серверов вашего провайдера или вообще любые другие сервера имен.

Для улучшения безопасности вашего BIND/DNS сервера вы можете запретить вашему серверу контактировать со сторонними серверами, если свои сервера не работают или не отвечают. С опцией “forward only”, установленной в файле “named.conf”, сервер имен не будет контактировать с другими серверами для поиска информации, если сервера на которые перенаправляются запросы не отвечают.

Компиляция и оптимизация.

Введите следующие команды на вашем терминале

[root@deep bind]# make -C src

[root@deep bind]# make clean all -C src SUBDIRS=../doc/man

[root@deep bind]# make install -C src

[root@deep bind]# make install -C src SUBDIRS=../doc/man

Команда “make” компилирует все исходные кода в двоичные исполняемые файлы, и затем команды “make install” инсталлируют исполняемые и сопутствующие им файлы в заданный каталог.

[root@deep bind]# strip /usr/bin/addr

[root@deep bind]# strip /usr/bin/dig

[root@deep bind]# strip /usr/bin/dnsquery

[root@deep bind]# strip /usr/bin/host

[root@deep bind]# strip /usr/bin/nslookup

[root@deep bind]# strip /usr/bin/nsupdate

[root@deep bind]# strip /usr/bin/mkservdb

[root@deep bind]# strip /usr/sbin/named

[root@deep bind]# strip /usr/sbin/named-xfer

[root@deep bind]# strip /usr/sbin/ndc

[root@deep bind]# strip /usr/sbin/dnskeygen

[root@deep bind]# strip /usr/sbin/irpd

[root@deep bind]# mkdir /var/named

Команда “strip” удаляет все символы из объектных файлов Это уменьшает размер исполняемых файла. Вследствие чего, улучшается производительность. “mkdir” создает новый каталог “/var/named”.

Очистка после работы.

[root@deep /]# cd /var/tmp

[root@deep tmp]# rm -rf bind/

Эти команды будут удалять все исходные коды, которые мы использовали при компиляции и инсталляции ISC BIND/DNS.

Конфигурации.

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

Для запуска кэширующего сервера имен необходимы следующие файлы, вы должны их либо создать либо скопировать в нужные каталоги сервера

Копируйте файл named.conf в каталог “/etc/”.

Копируйте файл db.127.0.0 в каталог “/var/named/”.

Копируйте файл db.cache в каталог “/var/named/”.

Копируйте скрипт named в каталог “/etc/rc.d/init.d/”.

Для запуска основного (master) сервера имен необходимы следующие файлы, вы должны их либо создать либо скопировать в нужные каталоги сервера

Копируйте файл named.conf в каталог “/etc/”.

Копируйте файл db.127.0.0 в каталог “/var/named/”.

Копируйте файл db.cache в каталог “/var/named/”.

Копируйте файл db.208.164.186 в каталог “/var/named/”.

Копируйте файл db.openna в каталог “/var/named/”.

Копируйте скрипт named в каталог “/etc/rc.d/init.d/”.

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

Копируйте файл named.conf в каталог “/etc/”.

Копируйте файл db.127.0.0 в каталог “/var/named/”.

Копируйте файл db.cache в каталог “/var/named/”.

Копируйте скрипт named в каталог “/etc/rc.d/init.d/”.

Вы можете взять эти файлы из нашего архива floppy.tgz.

Конфигурация файла “/etc/named.conf” для первичного мастер сервера

Используйте эту конфигурацию для серверов, которые выступают как мастер сервер имен. После компиляции DNS, вам необходимо установить первичное доменное имя сервера. Мы используем “openna.com”, как пример домена, предполагая, что используем IP сеть с адресом 208.164.186.0. Для этого, добавьте следующие строки файл “/etc/named.conf”.

Создайте файл named.conf (touch /etc/named.conf) и добавьте следующее:

options { directory "/var/named"; fetch-glue no; recursion no; allow-query { 208.164.186/24; 127.0.0/8; }; allow-transfer { 208.164.186.2; }; transfer-format many-answers; }; // Эти файлы не привязаны к какой-либо зоне zone "." in { type hint; file "db.cache"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; // Это файл вашей первичной зоны zone "openna.com" in { type master; file "db.openna "; }; zone "186.164.208.in-addr.arpa" in { type master; file "db.208.164.186"; };

Опция “fetch-glue no” может использоваться в связке с опцией “recursion no” для предотвращения роста и разрушения кэша сервера. Также, отключение рекурсии переведет ваш сервер имен в пассивный режим, говорящий ему никогда не посылать запросы от имени другого сервера имен или ресолвера. Не рекурсивные сервера имен очень сложно обмануть при помощи атаки spoof, так как они не отправляют никакие запросы и следовательно не кэшируют никакие данные.

В строке “allow-query”, 208.164.186/24 и 127.0.0/8 определяются IP адреса, которым разрешено осуществлять обычные запросы к серверу.

В строке “allow-transfer”, 208.164.186.2 это IP адрес, которому разрешается принимать пересылки зон с сервера. Вы должны обеспечить, чтобы только ваши вторичные сервера могли получать зоны с сервера. Эта информация часто используется спаммерами и IP spoofers.

ЗАМЕЧАНИЕ. Опции “recursion no”, “allow-query” и “allow-transfer” в файле “named.conf” используются для обеспечения большей безопасности сервера имен.

Используйте эту конфигурацию для сервера вполняющего роль вторичного сервера имен. Вы должны модифицировать файл “named.conf” на вторичном сервере имен. Измените каждое вхождение master на slave, сделав исключение для “0.0.127.in-addr.arpa”, и добавьте строку с IP адресом первичного сервера, как это показано ниже.

Создайте файл named.conf (touch /etc/named.conf) и добавьте в него:

options { directory "/var/named"; fetch-glue no; recursion no; allow-query { 208.164.186/24; 127.0.0/8; }; allow-transfer { 208.164.186.1; }; transfer-format many-answers; }; // These files are not specific to any zone zone "." in { type hint; file "db.cache"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; // These are our slave zone files zone "openna.com" in { type slave; file "db.openna"; masters { 208.164.186.1; }; }; zone "186.164.208.in-addr.arpa" in { type slave; file "db.208.164.186"; masters { 208.164.186.1; }; };

Этот файл говорит серверу, что он является вторичным для зоны “openna.com” и должен брать информацию об этой зоне с хоста “208.164.186.1”. Вторичному серверу имен нет необходимости получать все файлы (db) через сеть, так как db файлы “db.127.0.0” и “db.cache” одинаковы как для основного так и для вторичных серверов, поэтому вы можете создать их локальные копии на вторичном сервере.

Конфигурация файла “/var/named/db.127.0.0” для простого кэширующего сервера имен.

Используйте эту конфигурацию для всех серверов в вашей сети, которые не выступают как основной или подчиненный сервера имен. Файл “db.127.0.0” распространяется на сеть loopback. Создайте его в “/var/named/”.

Создайте файл db.127.0.0 (touch /var/named/db.127.0.0) и внесите в него следующие строки:

$TTL 345600 @ IN SOA localhost. root.localhost. ( 00 ; Serial 86400 ; Refresh 7200 ; Retry 2592000 ; Expire 345600 ) ; Minimum IN NS localhost.

1 IN PTR localhost.

Этот файл может быть использован как на основном, так и на вспомогательном серверах. Файл “db.127.0.0” описывает сеть loopback. Создайте файл db.127.0.0 (touch /var/named/db.127.0.0) и добавьте в него следующую информацию:

Конфигурация файла “/var/named/db.208.164.186” для основного сервера имен.

Используйте эту конфигурацию для сервера, который выступает в вашей сети, как основной сервер имен. Файл “db.208.164.186” привязывает имена хостов к адресам. Создайте следующий файл db.208.164.186 (touch /var/named/db.208.164.186) в каталоге “/var/named/”:

; Revision History: April 22, 1999 - admin@mail.openna.com ; Start of Authority (SOA) records. $TTL 345600 @ IN SOA deep.openna.com. admin.mail.openna.com. ( 00 ; Serial 86400 ; Refresh 7200 ; Retry 2592000 ; Expire 345600 ) ; Minimum ; Name Server (NS) records. NS deep.openna.com. NS mail.openna.com. ; Addresses Point to Canonical Names (PTR) for Reverse lookups 1 PTR deep.openna.com. 2 PTR mail.openna.com. 3 PTR www.openna.com.

Конфигурация файла “/var/named/db.cache” для простого кэширующего сервера имен.

Перед запуском вашего DNS сервера необходимо взять файл “db.cache” и поместить его в каталог “/var/named/”. “db.cache” определяет сервера корневой зоны.

Используйте следующие команды на другом UNIX компьютере для запроса нового файла db.cache для вашего DNS сервера или возьмите его с вашего Red Hat Linux CD-ROM:

Для запроса нового файла db.cache для вашего DNS сервера используйте следующую команду:

[root@deep]# dig @.aroot-servers.net . ns > db.cache

Не забудьте скопировать файл db.cache в каталог “/var/named/” на вашем сервере после получения его из Интернет.

ЗАМЕЧАНИЕ. Внутренние адреса, подобные 192.168.1/24, не включаются в файлы конфигурации DNS из соображений безопасности. Очень важно, чтобы между внутренними хостами и внешними не существовал DNS.

Конфигурация файла “/var/named/db.openna” для основного сервера имен

Используйте этот файл для сервера выступающего в роли основного сервера имен. Файл “db.openna” привязывает адреса к именам хостов. Создайте файл db.openna в каталоге “/var/named/” (touch /var/named/db.openna):

; Revision History: April 22, 1999 - admin@mail.openna.com ; Start of Authority (SOA) records. $TTL 345600 @ IN SOA deep.openna.com. admin.mail.openna.com. ( 00 ; Serial 86400 ; Refresh 7200 ; Retry 2592000 ; Expire 345600 ) ; Minimum ; Name Server (NS) records. NS deep.openna.com. NS mail.openna.com. ; Mail Exchange (MX) records. MX 0 mail.openna.com. ; Address (A) records. localhost A 127.0.0.1 deep A 208.164.186.1 mail A 208.164.186.2 www A 208.164.186.3 ; Aliases in Canonical Name (CNAME) records. ;www CNAME deep.openna.com.

Конфигурация файла “/var/named/db.cache” для основного и подчиненного серверов имен

Перед запуском вашего DNS сервера вы должны сделать копию файла “db.cache” и поместить его в каталог “/var/named/”. Он говорит серверу, какие сервера отвечают за корневую зону.

Используйте следующую команду на другом UNIX компьютере для получения нового файла db.cache или возьмите его с вашего Red Hat Linux CD-ROM:

[root@deep /]# dig @.aroot-servers.net . ns > db.cache

Не забудьте скопировать файл “db.cache” в каталог “/var/named/” после получения его из Интерент.

Конфигурация скрипта “/etc/rc.d/init.d/named” для всех типов серверов имен

Сконфигурируйте ваш скрипт “/etc/rc.d/init.d/named” для запуска и остановки демона BIND/DNS. Этот скрипт может быть использован для всех типов серверов (кэширующего, основного или подчиненного).

Создайте следующий скрипт named (touch /etc/rc.d/init.d/named):

#!/bin/sh # # named Этот скрипт командного интерпретатора отвечает за запуск и # остановку (BIND DNS сервера). # # chkconfig: - 55 45 # description: named (BIND) is a Domain Name Server (DNS) \ # that is used to resolve host names to IP addresses. # probe: true # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 0 [ -f /usr/sbin/named ] exit 0 [ -f /etc/named.conf ] exit 0 RETVAL=0 # See how we were called. case "$1" in start) # Start daemons. echo -n "Starting named: " daemon named RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/named echo ;; stop) # Stop daemons. echo -n "Shutting down named: " killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named echo ;; status) /usr/sbin/ndc status exit $? ;; restart) $0 stop $0 start ;; reload) /usr/sbin/ndc reload exit $? ;; probe) # named знает как правильно перезагружаться; мы не хотим использовать # linuxconf для перезагрузок /usr/sbin/ndc reload >/dev/null 2>&1 echo start exit 0 ;; *) echo "Usage: named {start|stop|status|restart}" exit 1 esac exit $RETVAL

Сейчас, надо сделать этот скрипт исполняемым и изменить права доступ, принятые по умолчанию:

[root@deep]# chmod 700 /etc/rc.d/init.d/named

Создайте символические rc.d ссылки для BIND/DNS:

[root@deep]# chkconfig --add named

Скрипт BIND/DNS не будет автоматически стартовать, когда вы перезагружаете сервер. Чтобы изменить это, выполните следующую команду:

[root@deep]# chkconfig --level 345 named on

Запустите вручную ваш DNS сервер:

[root@deep]# /etc/rc.d/init.d/named start

Starting named: [ OK ]

Конфигурирование и оптимизация.

Шаг 1.

ISC BIND не должен запускаться с правами root, поэтому мы должны завести пользователя не имеющего shell доступа.

[root@deep /]# useradd -c “DNS Server” -u 53 -s /bin/false -r -d /chroot/named named 2>/dev/null :

Шаг 2

Редактируем файл Makefile.set (vi src/port/linux/Makefile.set) и добавляем или модифицируем его:

'CC=egcs -D_GNU_SOURCE'

'CDEBUG=-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -arch=pentiumpro -fomit-frame-pointer -fno-exceptions -g’

'DESTBIN=/usr/bin'

'DESTSBIN=/usr/sbin'

'DESTEXEC=/usr/sbin'

'DESTMAN=/usr/man'

'DESTHELP=/usr/lib'

'DESTETC=/etc'

'DESTRUN=/var/run'

'DESTLIB=/usr/lib/bind/lib'

'DESTINC=/usr/lib/bind/include'

'LEX=flex -8 -I'

'YACC=yacc -d'

'SYSLIBS=-lfl'

'INSTALL=install'

'MANDIR=man'

'MANROFF=cat'

'CATEXT=$$N'

'PS=ps p'

'AR=ar crus'

'RANLIB=:'

Первая строки представляет имя вашего GCC компилятора (egcs), а вторая ваши флаги оптимизации. Срока “DESTLIB=” определяет путь, где будут располагаться файлы сервера BIND

Копируйте файл “db.127.0.0” с основного сервера на подчиненный.

Копируйте файл “db.cache” с основного сервера на подчиненный.

Linux DNS и BIND сервер

Краткий обзор.

Сейчас, когда мы установили все программное обеспечение предназначенное для зашиты сервера, самое время улучшить и настроить его сетевую часть. DNS наиболее важный сервис для IP сетей, и поэтому, все Linux машины - клиенты DNS, должны быть, как минимум, настроены на функцию кэширования. Такая настройка на клиентской машине уменьшит загрузку сервера. Кэширующий сервер ищет ответы на DNS запросы и сохраняет их до следующего раза. В результате время ответа на тот же запрос сильно сокращается.

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

В нашей конфигурации, мы будем запускать BIND/DNS от имени не root- пользователя и будем chroot-ить его окружение. Мы также предоставим вам три различные конфигурации: одну для простого кэширующего сервера (клиент), одну для вторичного сервера (secondary) и одну для основного (master) сервера.

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

На этой картинке изображена конфигурация, которую мы используем в этой книге.

Эти инструкции предполагают.

Unix-совместимые команды.

Путь к исходным кодам “/var/tmp” (возможны другие варианты).

Инсталляция была проверена на Red Hat Linux 6.1 и 6.2.

Все шаги инсталляции осуществляются суперпользователем “root”.

ISC BIND версии 8.2.2-patchlevel5

Пакеты.

Домашняя страница ISC BIND:

FTP сервер ISC BIND:

Вы должны скачать: bind-contrib.tar.gz, bind-doc.tar.gz, bind-src.tar.gz

Тарболы.

Хорошей идеей будет создать список файлов установленных в вашей системе до инсталляции BIND и после, в результате, с помощью утилиты diff вы сможете узнать какие файлы были установлены. Например,

До инсталляции:

find /* > DNS1

После инсталляции:

find /* > DNS2

Для получения списка установленных файлов:

diff DNS1 DNS2 > DNS-install

Раскройте тарбол:

[root@deep /]# mkdir /var/tmp/bind

[root@deep /]# cp bind-contrib.tar.gz /var/tmp/bind/

[root@deep /]# cp bind-doc.tar.gz /var/tmp/bind/

[root@deep /]# cp bind-src.tar.gz /var/tmp/bind/

Мы создаем каталог с именем “bind” и манипулируем tar архивами, копируя их в новый каталог.

Переходим в новый каталог bind (cd /var/tmp/bind) и разархивируем tar файлы:

[root@deep bind]# tar xzpf bind-contrib.tar.gz

[root@deep bind]# tar xzpf bind-doc.tar.gz

[root@deep bind]# tar xzpf bind-src.tar.gz

Основной сервер имен.

Первичный мастер сервер имен читает файл с данными о зоне и отвечает за эту зону.

Файлы необходимые для настройки первичного мастер сервера имен:

named.conf

db.127.0.0

db.208.164.186

db.openna

db.cache

скрипт named

Утилиты пользователя DNS

nslookup

Программа nslookup позволяет пользователям интерактивно или не интерактивно запрашивать сервера имен Интернет. В интерактивном режиме пользователи могут запрашивать у серверов имен информацию о различных хостах и доменах, печатать список хостов в домене. В не интерактивном режиме пользователь может получить имена и запросить информацию о хостах и доменах.

Интерактивный режим имеет много опций и команд; рекомендуется прочитать страницу руководства для nslookup или дать команду help в интерактивном режиме.

Для запуска nslookup в интерактивном режиме используйте команду:

[root@deep /]# nslookup

Default Server: deep.openna.com

Address: 208.164.186.1

> help

$Id: nslookup.help,v 8.4 1996/10/25 18:09:41 vixie Exp $

Команды: (идентификаторы представлены в верхнем регистре, что делать не обязательно)

NAME – печатает информацию о хосте/домене NAME, используя сервер по умолчанию

NAME1 NAME2 – то же, что и выше, но используется сервер NAME2

help или ? – печатает информацию об основных командах; смотрите nslookup(1) для деталей

set OPTION – устанавливает опции

all – печатает опции, текущий сервер и хост

[no]debug – печатает отладочную информацию

[no]d2 – печатает полную отладочную информацию

Для запуска в не интерактивном режиме используйте команду:

[root@deep /]# nslookup www.redhat.com

Server: deep.openna.com

Address: 208.164.186.1

Non-authoritative answer:

Name: www.portal.redhat.com

Addresses: 206.132.41.202, 206.132.41.203

Aliases: www.redhat.com

Где <www.redhat.com> это имя или Интернет адрес о котором вы хотите получить информацию.

dnsquery

Программа dnsquery запрашивает сервера имен через библиотеку определителей.Для организации запроса на сервер имен, используя библиоткеку определителей, введите следующую команду:

[root@deep /]# dnsquery <host>

Например:

[root@deep /]# dnsquery www.redhat.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40803

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; www.redhat.com, type = ANY, class = IN

www.redhat.com. 2h19m46s IN CNAME www.portal.redhat.com.

redhat.com. 2h18m13s IN NS ns.redhat.com.

redhat.com. 2h18m13s IN NS ns2.redhat.com.

redhat.com. 2h18m13s IN NS ns3.redhat.com.

redhat.com. 2h18m13s IN NS speedy.redhat.com.

ns.redhat.com. 1d2h18m8s IN A 207.175.42.153

ns2.redhat.com. 1d2h18m8s IN A 208.178.165.229

ns3.redhat.com. 1d2h18m8s IN A 206.132.41.213

speedy.redhat.com. 2h18m13s IN A 199.183.24.251

где <host> - имя хоста информацию о котором вы хотите получить.

host

Программа host определяет имя хоста, используя DNS. Для определения имен хоста используя сервер имен, введите следующую команду:

[root@deep /]# host <FQDN, domain names, host names, or host numbers>

Например:

[root@deep /]# host redhat.com

redhat.com has address 207.175.42.154

где <FQDN, domain names, host names, or host numbers> FDQN - полностью определенное имя домена (www.redhat.com), domain names – доменное имя (redhat.com), host names - имя хоста (www) или host numbers - адрес хоста (207.175.42.154).

Для поиска всей информации предоставляемой DNS о хосте используйте команду:

[root@deep /]# host <-a domain names >

Например:

[root@deep /]# host -a redhat.com

Trying null domain

rcode = 0 (Success), ancount=6

The following answer is not authoritative:

The following answer is not verified as authentic by the server:

redhat.com 8112 IN NS ns.redhat.com

redhat.com 8112 IN NS ns2.redhat.com

redhat.com 8112 IN NS ns3.redhat.com

redhat.com 8112 IN NS speedy.redhat.com

redhat.com 8112 IN A 207.175.42.154

redhat.com 11891 IN SOA ns.redhat.com noc.redhat.com(

2000021402 ;serial (version)

3600 ;refresh period

1800 ;retry refresh this often

604800 ;expiration period

86400 ;minimum TTL

)

For authoritative answers, see:

redhat.com 8112 IN NS ns.redhat.com

redhat.com 8112 IN NS ns2.redhat.com

redhat.com 8112 IN NS ns3.redhat.com

redhat.com 8112 IN NS speedy.redhat.com

Additional information:

ns.redhat.com 94507 IN A 207.175.42.153

ns2.redhat.com 94507 IN A 208.178.165.229

ns3.redhat.com 94507 IN A 206.132.41.213

speedy.redhat.com 8112 IN A 199.183.24.251

Для получения полного описания домена используйте команду:

[root@deep /]# host <-l domain names >

Например:

[root@deep /]# host -l openna.com

openna.com name server deep.openna.com

openna.com name server mail.openna.com

localhost.openna.com has address 127.0.0.1

deep.openna.com has address 208.164.186.1

mail.openna.com has address 208.164.186.2

www.openna.com has address 208.164.186.3

Эта опция вызовет получение всех данных о зоне для доменного имени “openna.com”. Подобная команды должна использоваться только если это действительно необходимо.

Вторичный сервер имен.

Основное назначение вторичного сервера имен – разделение нагрузки с основным сервером, и обработка запросов, если основной сервер не работает. Вторичный сервер загружает данные через сеть с другого сервера имен (обычно основного, но может и с другого вторичного). Этот процесс называется пересылкой зоны.

Файлы необходимые для установки вторичного сервера имен:

named.conf

db.127.0.0

db.cache

скрипт named

Запуск ISC BIND/DNS в chroot окружении.

Эта часть фокусируется на предотвращении использования ISC BIND/DNS, как точки прерывания для доступа к системе. Так как ISC BIND/DNS выполняет относительно большую и комплексную функцию, вероятность возникновения ошибки, затрагивающей защиту, высока. Фактически, в прошлом имелись дефекты, которые позволяли удаленному пользователю получить root доступ к серверу с запущенным BIND.

Чтобы минимизировать риск, ISC BIND/DNS может быть запущен как не root пользователь, который сможет нанести повреждения, как нормальный пользователь с локальным shell. Конечно, этого не достаточно для обеспечения безопасности большинства DNS серверов, поэтому может быть предпринят дополнительный шаг – запуск ISC BIND в chroot заключении.

Основная выгода chroot состоит в том, что в результате ограничивается часть файловой системы, которую DNS демон может видеть, корневым каталогом “окружения”. Так как “окружение” создается только для поддержки DNS, число программ связанных с ISC BIND/DNS и доступных в этой части файловой системы чрезвычайно ограничено. Наиболее важно то, что здесь отпадает необходимость в setuid-root программах, которые могут быть использованы для получения root доступа и взлома “окружения”.

ЗАМЕЧАНИЕ: Исполняемая программа “named” должна располагаться в каталоге, описанном в переменной PATH. В этом документе, я буду считать, что путь к named будет “/usr/sbin/named”.

Для запуска ISC BIND/DNS в chroot “окружении” необходимо сделать слеующие шаги:

Шаг 1

Мы должны найти совместно-используемые библиотеки от которых зависит named (named – это DNS демон). Их будет нужно позже скопировать в chroot “окружение”.

Для поиска подобных библиотек используйте следующую команду:

[root@deep /]# ldd /usr/sbin/named

libc.so.6 => /lib/libc.so.6 (0x40017000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

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

Шаг 2

Сейчас мы должны определить chroot окружение и создавать корневой каталог для него. Мы выбрали каталог “/chroot/named”, потому что хотим разместить ее на независимом разделе, чтобы предотвратить атаки на файловую систему. Раньше, во время инсталляции Linux мы создали раздел “/chroot” специально предназначенный для этого.

[root@deep /]# /etc/rc.d/init.d/named stop ( требуется ввести только если сещуствующий named демон запущен)

Shutting down named: [ OK ]

[root@deep /]# mkdir -p /chroot/named

Затем, создаем остальные каталоги:

[root@deep /]# mkdir /chroot/named/dev

[root@deep /]# mkdir /chroot/named/lib

[root@deep /]# mkdir /chroot/named/etc

[root@deep /]# mkdir -p /chroot/named/usr/sbin

[root@deep /]# mkdir -p /chroot/named/var/run

[root@deep /]# mkdir /chroot/named/var/named

Сейчас копируем основные конфигурационные файлы, файлы с описаниями зон, программы named named-xfer в необходимые места:

[root@deep /]# cp /etc/named.conf /chroot/named/etc/

[root@deep /]# cd /var/named ; cp -a . /chroot/named/var/named/

[root@deep /]# mknod /chroot/named/dev/null c 1 3

[root@deep /]# chmod 666 /chroot/named/dev/null

[root@deep /]# cp /usr/sbin/named /chroot/named/usr/sbin/

[root@deep /]# cp /usr/sbin/named-xfer /chroot/named/usr/sbin/

ВАЖНОЕ ЗАМЕЧАНИЕ. Для подчиненного сервера имен владельцем каталога “/chroot/named/var/named” и всех файлов расположенных в нем должен быть процесс с “named”, иначе вы не сможете осуществить пересылку зоны. Чтобы сделать на подчиненном сервере владельцем каталога “named” и всех файлов лежащих в нем пользователя “named” используйте следующую команду:

[root@deep /]# chown -R named.named /chroot/named/var/named/

Шаг 3

Копируйте разделяемые библиотеки определенные на шаге 1 в chroot каталог lib:

[root@deep /]# cp /lib/libc.so.6 /chroot/named/lib/

[root@deep /]# cp /lib/ld-linux.so.2 /chroot/named/lib/

Шаг 4

Копируйте файлы “localtime” и “nsswitch.conf” в chroot каталог etc, чтобы элементы файлов регистрации были правильно установлены для вашей временной зоны:

[root@deep /]# cp /etc/localtime /chroot/named/etc/

[root@deep /]# cp /etc/nsswitch.conf /chroot/named/etc/

Шаг 5

Для большей безопасности на некоторые файлы из каталога “/chroot/named/etc” мы должны установить бит постоянства:

[root@deep /]# cd /chroot/named/etc/

[root@deep etc]# chattr +i nsswitch.conf

[root@deep /]# cd /chroot/named/etc/

[root@deep etc]# chattr +i named.conf

Файл с атрибутом “+i” не может быть модифицирован, удален или переименован; к нему не может быть создана ссылка и никакие данные не могут быть записаны в него. Только суперпользователь может установить или снять этот атрибут.

Шаг 6

Добавьте новый UID и новый GID для запуска демона “named”, если они еще не определены. Это важно, так как запуск его как root нарушит правильное функционирование “окружения”, а использование существующих пользовательских id позволит вашему сервису получить доступ к другим ресурсам.

Проверьте файлы “/etc/passwd” и “/etc/group” на наличие свободных UID/GID. В нашем примере, мы используем номер “53” и имя “named”.

[root@deep /]# useradd -c “DNS Server” -u 53 -s /bin/false -r -d /chroot/named named 2>/dev/null :

Шаг 7

Мы должны сказать syslogd (демону системы syslog) о новом chrooted сервисе: Обычно, процессы обращаются к syslogd через “/dev/log”. chroot-овое “окружение”, этого сделать не сможет, поэтому syslogd необходимо объяснить, что нужно слушать “/chroot/named/dev/log” вместо принятого по умолчанию “dev/log”. Чтобы сделать это, нужно редактировать скрипт запуска syslog.

Редактируйте скрипт syslog (vi +24 /etc/rc.d/init.d/syslog) и измените следующую строку:

daemon syslogd -m 0

Должна читаться как:

daemon syslogd -m 0 -a /chroot/named/dev/log

Шаг 8

Скрипт для запуска ISC BIND/DNS по умолчанию настроен для запуска его вне chroot “окружения”. Мы должны внести следующие изменения в файл named (vi /etc/rc.d/init.d/named), чтобы исправить это:

[ -f /usr/sbin/named ] exit 0

Должна читаться:

[ -f /chroot/named/usr/sbin/named ] exit 0

[ -f /etc/named.conf ] exit 0

Должна читаться:

[ -f /chroot/named/etc/named.conf ] exit 0

daemon named

Должна читаться:

daemon /chroot/named/usr/sbin/named -t /chroot/named/ -unamed -gnamed

Опция “-t” говорит “named” запускаться, используя новое chroot окружение.

Опция “-u” определяет пользователя от имени которого стартует named.

Опция “-g” определяет группу от имени которой стартует named.

Шаг 9

В BIND 8.2, команда “ndc” стала двоичным файлом (ранее, это был скрипт), которая в этой конфигурации не работает. Чтобы исправить это, пакет ISC BIND/DNS должен быть скомпилирован из исходных кодов.

[root@deep /]# cp bind-src.tar.gz /vat/tmp

[root@deep /]# cd /var/tmp/

[root@deep tmp]# tar xzpf bind-src.tar.gz

[root@deep tmp]# cd src

[root@deep src]# cp port/linux/Makefile.set port/linux/Makefile.set-orig

Редактируем файл Makefile.set (vi port/linux/Makefile.set) и делаем в нем следующие изменения:

'CC=egcs -D_GNU_SOURCE'

'CDEBUG=-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions -g’

'DESTBIN=/usr/bin'

'DESTSBIN=/chroot/named/usr/sbin'

'DESTEXEC=/chroot/named/usr/sbin'

'DESTMAN=/usr/man'

'DESTHELP=/usr/lib'

'DESTETC=/etc'

'DESTRUN=/chroot/named/var/run'

'DESTLIB=/usr/lib/bind/lib'

'DESTINC=/usr/lib/bind/include'

'LEX=flex -8 -I'

'YACC=yacc -d'

'SYSLIBS=-lfl'

'INSTALL=install'

'MANDIR=man'

'MANROFF=cat'

'CATEXT=$$N'

'PS=ps p'

'AR=ar crus'

'RANLIB=:'

Различие между Makefile, который мы использовали прежде и новым, заключается в изменении строк “DESTSBIN=”, “DESTEXEC=” и “DESTRUN=”. В них мы задаем новое месторасположение файлов и теперь программа “ndc” будет знать, где находится “named”.

[root@deep src]# make clean

[root@deep src]# make

[root@deep src]# cp bin/ndc/ndc /usr/sbin/

[root@deep src]# cp: overwrite `/usr/sbin/ndc’? y

[root@deep src]# strip /usr/sbin/ndc

Мы создали двоичный файл, а затем копируем полученную программу “ndc” в “/usr/sbin”, переписывая старую. Мы не должны забыть выполнить команду strip для улучшения производительности.

Шаг 10

Также хорошей идеей будет создание новых двоичных файлов “named” и “named-xfer”, чтобы грантировано использовать одну и туже версию “named” и “ndc”.

Для named:

[root@deep /]# cd /var/tmp/src

[root@deep src]# cp port/linux/Makefile.set-orig port/linux/Makefile.set

[root@deep src]# cp: overwrite `port/linux/Makefile.set’? y

Редактируйте файл Makefile.set (vi port/linux/Makefile.set) и внесите в него следующие изменения:

'CC=egcs -D_GNU_SOURCE'

'CDEBUG=-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions -g’

'DESTBIN=/usr/bin'

'DESTSBIN=/usr/sbin'

'DESTEXEC=/usr/sbin'

'DESTMAN=/usr/man'

'DESTHELP=/usr/lib'

'DESTETC=/etc'

'DESTRUN=/var/run'

'DESTLIB=/usr/lib/bind/lib'

'DESTINC=/usr/lib/bind/include'

'LEX=flex -8 -I'

'YACC=yacc -d'

'SYSLIBS=-lfl'

'INSTALL=install'

'MANDIR=man'

'MANROFF=cat'

'CATEXT=$$N'

'PS=ps p'

'AR=ar crus'

'RANLIB=:'

[root@deep src]# rm -f .settings

[root@deep src]# make clean

[root@deep src]# make

[root@deep src]# cp bin/named/named /chroot/named/usr/sbin

[root@deep src]# cp: overwrite `/chroot/named/usr/sbin/named’? y

[root@deep src]# cp bin/named-xfer/named-xfer /chroot/named/usr/sbin

[root@deep src]# cp: overwrite `/chroot/named/usr/sbin/named-xfer’? y

[root@deep src]# strip /chroot/named/usr/sbin/named

[root@deep src]# strip /chroot/named/usr/sbin/named-xfer

Мы удалили файл “.settings”, так как система кэширует в нем переменные и выполнили команду “make clean”, чтобы убедиться, что у нас не возникнут старые наложения. После того, как создан файл “named”, мы копируем его вместе с “named-xfer” в chroot каталог и используем команду “strip” для улучшения производительности новых исполняемых файлов.

Step 11

Удаление ненужных файлов и каталогов.

[root@deep /]# rm -f /usr/sbin/named

[root@deep /]# rm -f /usr/sbin/named-xfer

[root@deep /]# rm -f /etc/named.conf

[root@deep /]# rm -rf /var/named/

Мы удаляем “named” и “named-xfer” из “/usr/sbin”, так как они будут теперь запускаться из chroot каталога. Тоже самое проделываем и для файла “named.conf” и каталога “/var/named”.

Шаг 12

Мы должны тестировать новую chroot-овую конфигурацию ISC BIND/DNS.

Первое, перезапустите ваш syslogd демон:

[root@deep /]# /etc/rc.d/init.d/syslog restart Shutting down kernel logger: [ OK ] Shutting down system logger: [ OK ] Starting system logger: [ OK ] Starting kernel logger: [ OK ]

Теперь можно запустить chroot версию ISC BIND/DNS:

[root@deep /]# /etc/rc.d/init.d/named start Starting named: [ OK ]

Проверяем, что ISC BIND/DNS запущен от имени пользователя “named” с новыми аргументами:

[root@deep /]# ps auxw | grep named

named 11446 0.0 1.2 2444 1580 ? S 23:09 0:00 /chroot/named/usr/sbin/named -t /chroot/named/ -u named –g named

Первая колонка говорит, что программа запущена с UID “named”. Конец строки должен содержать “named -t /chroot/named/ -u named –g named”, представляющие из себя новые аргументы.

Очистка после работы

[root@deep /]# rm -rf /var/tmp/src bind-src.tar.gz

Эта команда перемещает исходные файлы и tar архив, которые мы использовали при компиляции и инсталляции ISC BIND/DNS.

Дополнительная документация

Для получения большей информации вы можете читать следующие страницы руководства:

$ man dnsdomainname (1) – показывает доменное имя системы

$ man dnskeygen (1) – создает публичный, приватный и разделяемый секретные ключи для DNS Security

$ man dnsquery (1) – запрос доменного имени, используя распознаватель (resolver)

$ man named (8) – сервер доменной службы имен (DNS)

$ man hesiod_to_bind [hesiod] (3) – Интерфейсная библиотека к серверу имен Hesiod

$ man ldconfig (8) – определяет связи времени выполнения

$ man lesskey (1) – определяет ключ связанный с less

$ man raw (8) - привязывает “сырые” символьные устройства Linux

$ man mkfifo (1) – создает FIFO (именные каналы)

$ man named-bootconf (8) – конвертирует конфигурационный файл сервера имен

$ man named-xfer (8) – вспомогательный агент для входящей зонной пересылки

$ man named.conf [named] (5) – конфигурационный файл

$ man Opcode (3) – Отключает opcode-ы named, когда компилируется perl код

$ man dig (1) – посылает запросы к серверу имен

$ man nslookup (8) – создание интерактивных запросов к серверу имен

$ man ndc (8) – программа контролирующая работу сервера имен