Руководство Freebsd icon

Руководство Freebsd


Смотрите также:
Руководство Freebsd...
Ермаков В. И. ред...
Avira AntiVir PersonalEdition...
Киев, пр-т Освободителей 25, кв. 15...
Техническое задание на разработку сайта...
Frenzy 0 информация о релизе...
Руководство по парашютной подготовке авиации досааф россии (рпп-2010) (далее Руководство)...
Методологическое руководство по мониторингу и оценке...
Методологическое руководство по мониторингу и оценке вич/спид, туберкулез и малярия июнь 2004 г...
Руководство пользователя Сетевой цифровой видеорекордер...
Руководство проведением конкурса Общее руководство, организацию подготовки...
Методическое руководство по дипломному проектированию...



страницы: 1   ...   5   6   7   8   9   10   11   12   ...   27
вернуться в начало
^

14.4. DES, MD5, и шифрование


Частично переписал и обновил Bill Swingle.

У каждого пользователя UNIX системы есть пароль, связанный с его учётной записью. Очевидно, что эти пароли должны быть известны только пользователю и соответствующей операционной системе. Для защиты паролей они шифруются способом, известным как ''односторонний хэш'', то есть их можно легко зашифровать, но нельзя расшифровать. Другими словами, то, что мы сказали чуть раньше было очевидно, но не совсем верно: операционной системе сам пароль неизвестен. Ей известен только пароль в зашифрованной форме. Единственный способ получить ''обычный'' пароль это простой перебор всех возможных паролей.

К сожалению, единственный способ шифрования пароля при появлении UNIX был основан на DES, Data Encryption Standard. Это не было проблемой для пользователей, живущих в США, но поскольку исходный код DES нельзя было экспортировать из США, FreeBSD нашла способ одновременно не нарушать законов США и сохранить совместимость со всеми другими вариантами UNIX, где все еще использовался DES.

Решение было в разделении библиотек шифрования, чтобы пользователи в США могли устанавливать и использовать библиотеки DES, а у остальных пользователей был метод шифрования, разрешенный к экспорту. Так FreeBSD пришла к использованию MD5 в качестве метода шифрования по умолчанию. MD5 считается более безопасным, чем DES, поэтому установка DES рекомендуется в основном из соображений совместимости.
^

14.4.1. Определения механизма шифрования


До FreeBSD 4.4 libcrypt.a была символической ссылкой на библиотеку, используемую для шифрования. В FreeBSD 4.4 libcrypt.a была изменена для предоставления настраиваемой библиотеки аутентификации по хэшу пароля. На данный момент библиотека поддерживает хэши DES, MD5 и Blowfish. По умолчанию FreeBSD использует для шифрования паролей MD5.

Довольно легко определить какой метод шифрования используется в FreeBSD. Один из способов это проверка файла /etc/master.passwd. Пароли, зашифрованные в хэш MD5 длиннее, чем те, что зашифрованы с помощью DES и начинаются с символов $1$. Пароли, начинающиеся с символов $2a$ зашифрованы с помощью Blowfish. Пароли, зашифрованные DES не содержат каких-то определенных идентифицирующих символов, но они короче, чем пароли MD5 и закодированы в 64-символьном алфавите, не содержащем символа $, поэтому относительно короткая строка, не начинающаяся с этого символа это скорее всего DES пароль.

Формат паролей, используемых для новых паролей, определяется параметром passwd_format в /etc/login.conf, которое может принимать значения des, md5 или blf. Обратитесь к странице справочника login.conf(5) за дополнительной информацией о параметрах login.
^

14.5. Одноразовые пароли


S/Key это схема с одноразовыми паролями, основанная на одностороннем хэше. FreeBSD использует хэш MD4 для совместимости, но другие системы используют MD5 и DES-MAC. S/Key была частью базовой системы FreeBSD начиная с версии 1.1.5 и используется также во все большем числе операционных систем. S/Key это зарегистрированная торговая марка Bell Communications Research, Inc.

Начиная с FreeBSD версии 5.0, S/Key была замещена на функциональный эквивалент — OPIE (One-time Passwords In Everything). OPIE по умолчанию использует MD5.

Есть три различных вида паролей, о которых мы поговорим ниже. Первый вид это ваш обычный пароль UNIX или пароль Kerberos; мы будем называть его ''пароль UNIX''. Второй вид это одноразовый пароль, сгенерированный программой S/Key key или программой OPIE opiekey(1) и принимаемый командами keyinit или opiepasswd(1) и в приглашении login; мы будем называть их ''одноразовыми паролями''. Последний вид паролей это защищенные пароли, которые вы передаете программам key/opiekey (и иногда программам keyinit/opiepasswd), и которые эти программы используют для создания одноразовых паролей; мы будем называть его ''защищенными паролями'' или просто ''паролями''.

Защищенный пароль не имеет никакого отношения к вашему паролю UNIX; они могут быть одинаковыми, но это не рекомендуется. Защищенные пароли S/Key и OPIE не ограничены 8-ю символами, как старые UNIX пароли1, они могут быть настолько длинными, насколько вы захотите. Очень часто используются пароли длиной в шесть или семь символов. По большей части система S/Key или OPIE работает полностью независимо от системы паролей UNIX.

Помимо паролей, есть два других вида данных, важных для S/Key и OPIE. Первый, известный как ''seed'' или ''ключ'', состоит из двух букв и пяти цифр. Другой, называемый ''счетчиком цикла'', это номер от 1 до 100. S/Key создает одноразовый пароль, соединяя ключ и защищенный пароль, а затем применяя MD4/MD5 столько раз, сколько указано счетчиком цикла и выдает результат в виде шести коротких слов на английском. Эти шесть слов на английском и есть ваш одноразовый пароль. Система аутентификации (как правило PAM) хранит последний использованный одноразовый пароль, и пользователь аутентифицируется если хэш вводимого пользователем пароля совпадает с предыдущим паролем. Поскольку используется односторонний хэш, невозможно сгенерировать следующий одноразовый пароль если получен предыдущий; счетчик цикла уменьшается после каждого успешного входа для поддержки синхронизации пользователя с программой login. Когда счетчик цикла уменьшается до 1, S/Key и OPIE должны быть переинициализированы.

В каждой из обсуждаемых ниже систем задействованы три программы. Программы key и opiekey получают счетчик цикла, ключ и защищенный пароль и создают одноразовый пароль или последовательный список одноразовых паролей. Программы keyinit и opiepasswd используются для инициализации S/Key и OPIE соответственно, и для смены паролей, счетчиков цикла, или ключей; они принимают защищенный пароль или счетчик цикла, ключ и одноразовый пароль. Программы keyinfo и opieinfo проверяют соответствующие файлы (/etc/skeykeys или /etc/opiekeys) и печатают текущий счетчик цикла и ключ вызывающего пользователя.

Мы рассмотрим четыре вида операций. Первая это использование keyinit или opiepasswd через защищенное соединение для первоначальной настройки системы одноразовых паролей, или для изменения пароля или ключа. Вторая операция это использование в тех же целях keyinit или opiepasswd через незащищенное соединение, в сочетании с key или opiekey через защищенное соединение. Третья это использование key/opiekey для входа через незащищенное соединение. Четвертая это использование key или opiekey для генерации набора ключей, которые могут быть записаны или распечатаны для соединения из места, где защищенное соединение недоступно.
^

14.5.1. Защищенная установка соединения


Для первоначальной настройки S/Key, измените ваш пароль или ключ при входе через защищенное соединение (например, с консоли компьютера или через ssh), используйте команду keyinit без параметров при входе под своим именем:

% keyinit

Adding unfurl:

Reminder - Only use this method if you are directly connected.

If you are using telnet or rlogin exit with no password and use keyinit -s.

Enter secret password:

Again secret password:


ID unfurl s/key is 99 to17757

DEFY CLUB PRO NASH LACE SOFT

Для OPIE, вместо этого используется opiepasswd:

% opiepasswd -c

[grimreaper] ~ $ opiepasswd -f -c

Adding unfurl:

Only use this method from the console; NEVER from remote. If you are using

telnet, xterm, or a dial-in, type ^C now or exit with no password.

Then run opiepasswd without the -c parameter.

Using MD5 to compute responses.

Enter new secret pass phrase:

Again new secret pass phrase:

ID unfurl OTP key is 499 to4268

MOS MALL GOAT ARM AVID COED

В приглашениях Enter new secret pass phrase: или Enter secret password:, введите пароль или фразу. Запомните, это не тот пароль, с которым вы будете входить, он используется для генерации одноразовых паролей. Строка ''ID'' содержит информацию для вашего конкретного случая: имя пользователя, счетчик цикла и ключ. При входе система запомнит эти параметры и отправит их вам, поэтому их не надо запоминать. В последней строке находится одноразовый пароль, соответствующий этим параметрам и секретному паролю; если вы войдете в систему сразу, используйте этот одноразовый пароль.
^

14.5.2. Незащищенная установка соединения


Для инициализации или изменения защищенного пароля через незащищенное соединение, вам потребуется существующее защищенное соединение куда-то, где вы сможете запустить key или opiekey; это может быть средство доступа Macintosh или shell на компьютере, которому вы доверяете. Вам потребуется также установить значение счетчика цикла (100 возможно подойдет), и задать ключ или использовать сгенерированный. Через незащищенное соединение (к компьютеру, на котором производится настройка), используйте команду keyinit -s:

% keyinit -s

Updating unfurl:

Old key: to17758

Reminder you need the 6 English words from the key command.

Enter sequence count from 1 to 9999: 100

Enter new key [default to17759]:

s/key 100 to 17759

s/key access password:

s/key access password:CURE MIKE BANE HIM RACY GORE

Для OPIE, используйте opiepasswd:

% opiepasswd


Updating unfurl:

You need the response from an OTP generator.

Old secret pass phrase:

otp-md5 498 to4268 ext

Response: GAME GAG WELT OUT DOWN CHAT

New secret pass phrase:

otp-md5 499 to4269

Response: LINE PAP MILK NELL BUOY TROY


ID mark OTP key is 499 gr4269

LINE PAP MILK NELL BUOY TROY

Чтобы принять ключ по умолчанию нажмите ^ Enter. Затем, перед вводом пароля доступа введите те же параметры в вашем защищенном соединении или средстве доступа S/Key:

% key 100 to17759

Reminder - Do not use this program while logged in via telnet or rlogin.

Enter secret password:

CURE MIKE BANE HIM RACY GORE

Или для OPIE:

% opiekey 498 to4268

Using the MD5 algorithm to compute response.

Reminder: Don't use opiekey from telnet or dial-in sessions.

Enter secret pass phrase:

GAME GAG WELT OUT DOWN CHAT

Теперь переключитесь на незащищенное соединение и скопируйте одноразовый пароль, сгенерированный соответствующей программой.
^

14.5.3. Создание одного одноразового пароля


Как только вы настроите S/Key или OPIE, во время входа появится приглашение вроде этого:

% telnet example.com

Trying 10.0.0.1...

Connected to example.com

Escape character is '^]'.


FreeBSD/i386 (example.com) (ttypa)


login:

s/key 97 fw13894

Password:

Или для OPIE:

% telnet example.com

Trying 10.0.0.1...

Connected to example.com

Escape character is '^]'.


FreeBSD/i386 (example.com) (ttypa)


login:

otp-md5 498 gr4269 ext

Password:

Кроме того, у S/Key и OPIE есть полезная особенность (не показанная здесь): если вы нажмете Enter в приглашении на ввод пароля, включится эхо, и вы сможете увидеть то, что вводите. Это может быть очень полезно, если вы пытаетесь ввести пароль вручную, например с распечатки.

В этот момент вам потребуется сгенерировать одноразовый пароль, чтобы ввести его в приглашение. Это должно быть выполнено на защищенной системе, в которой вы можете запустить key или opiekey (есть версии для DOS, Windows и Mac OS). Им требуются значения счетчика цикла и ключ в качестве параметров командной строки. Вы можете скопировать и вставить их прямо из приглашения login компьютера, на который входите.

В защищенной системе:

% key 97 fw13894

Reminder - Do not use this program while logged in via telnet or rlogin.

Enter secret password:

WELD LIP ACTS ENDS ME HAAG

Для OPIE:

% opiekey 498 to4268

Using the MD5 algorithm to compute response.

Reminder: Don't use opiekey from telnet or dial-in sessions.

Enter secret pass phrase:

GAME GAG WELT OUT DOWN CHAT

Теперь, когда у вас есть одноразовый пароль, можете продолжить вход в систему:

login:

s/key 97 fw13894

Password:

s/key 97 fw13894

Password [echo on]: WELD LIP ACTS ENDS ME HAAG

Last login: Tue Mar 21 11:56:41 from 10.0.0.2 ...
^

14.5.4. Создание нескольких одноразовых паролей


Иногда вы отправляетесь туда, где нет доступа к защищенному компьютеру или защищенному соединению. В этом случае, можно использовать команды key и opiekey для создания нескольких одноразовых паролей, которые вы сможете распечатать и забрать с собой. Например:

% key -n 5 30 zz99999

Reminder - Do not use this program while logged in via telnet or rlogin.

Enter secret password:

26: SODA RUDE LEA LIND BUDD SILT

27: JILT SPY DUTY GLOW COWL ROT

28: THEM OW COLA RUNT BONG SCOT

29: COT MASH BARR BRIM NAN FLAG

30: CAN KNEE CAST NAME FOLK BILK

Или для OPIE:

% opiekey -n 5 30 zz99999

Using the MD5 algorithm to compute response.

Reminder: Don't use opiekey from telnet or dial-in sessions.

Enter secret pass phrase:

26: JOAN BORE FOSS DES NAY QUIT

27: LATE BIAS SLAY FOLK MUCH TRIG

28: SALT TIN ANTI LOON NEAL USE

29: RIO ODIN GO BYE FURY TIC

30: GREW JIVE SAN GIRD BOIL PHI

Параметр -n 5 запрашивает пять паролей, 30 указывает значение последнего счетчика цикла. Обратите внимание, что пароли печатаются в обратном по сравнению с обычным использованием порядке. Если вы действительно параноик, перепишите результат вручную; иначе скопируйте и передайте его lpr. Обратите внимание, что каждая линия содержит как счетчик цикла, так и одноразовый пароль; вам может показаться удобным отрывать пароль после использования.
^

14.5.5. Ограничение использования UNIX® паролей


S/Key может наложить ограничения на использование UNIX паролей на основе имени хоста, имени пользователя, порта терминала или IP адреса сессии. Эти ограничения можно найти в файле настройки /etc/skey.access. Страница справочника skey.access(5) содержит дополнительную информацию о полном формате файла а также детали о некоторых предосторожностях, которые должны быть предприняты перед тем, как положиться в вопросах безопасности на этот файл.

Если файла /etc/skey.access нет (это ситуация по умолчанию в системах FreeBSD 4.X), всем пользователям будет разрешено входить с паролями UNIX. Если файл существует, использование S/Key станет обязательно для всех, если только параметры настройки в файле skey.access не указывают иначе. В любом случае, пароли UNIX разрешены при входе с консоли.

Вот пример файла настройки skey.access, иллюстрирующий три наиболее распространенных вида параметров настройки:

permit internet 192.168.0.0 255.255.0.0

permit user fnord

permit port ttyd0

Первая строка (permit internet) разрешает пользователям, чей IP адрес (который подвержен подделке) соответствует заданному значению и маске, входить с использованием паролей UNIX. Это должно рассматриваться не как механизм безопасности, а как напоминание пользователям, что они работают через небезопасное соединение и должны использовать для аутентификации S/Key.

Вторая строка (permit user) позволяет определенным пользователям, в данном случае fnord, всегда использовать пароли UNIX. Вообще говоря, это должно использоваться только для тех, кто не может использовать программу key, например если они работают с простых терминалов или необучаемы.

Третья строка (permit port) позволяет всем пользователям, вошедшим с определенного терминала использовать пароли UNIX; этот параметр должен использоваться для подключений по dial-up.

OPIE может ограничивать использование паролей UNIX на основе IP адреса как и S/Key. Соответствующий файл называется /etc/opieaccess, он существует по умолчанию в FreeBSD 5.0 и более современных системах. Обратитесь к opieaccess(5) за более подробной информацией об этом файле и о предосторожностях, которые вы должны предпринять при использовании этого файла.

Вот пример файла opieaccess:

permit 192.168.0.0 255.255.0.0

Эта строка позволяет пользователям, чей IP адрес (который подвержен подделке) соответствует указанному значению и маске, входить с паролем UNIX.

Если ни одно из правил в opieaccess не сработало, поведением по умолчанию является запрет всех не-OPIE входов.
^

14.6. TCP Wrappers


Написал: Tom Rhodes.

Каждый, кто знаком с inetd(8), возможно когда-то слышал о TCP Wrappers. Но немногие полностью понимают их полезность в сетевой среде: большинство используют брандмауэр. Хотя его применимость очень широка, есть вещи, с которыми брандмауэр не может работать, такие как отправка текста обратно вызывающей стороне. Программное обеспечение уровня TCP может делать это и многое другое. В следующих нескольких разделах обсуждаются многие возможности TCP Wrappers, и, когда это необходимо, даются примеры настроек.

Программное обеспечение TCP Wrappers расширяет возможность inetd по поддержке каждого даемона. С ним становится возможным протоколирование, возврат сообщений вызывающей стороне, ограничение подключений внутренней сетью и т.п. Хотя некоторые из этих возможностей могут быть реализованы брандмауэром, TCP Wrappers не только предоставляют дополнительный уровень защиты, но и дают больше контроля над системой, чем это возможно с брандмауэром.

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

Поскольку рассматривается расширение к настройкам inetd, предполагается, что читатель ознакомился с разделом о настройке inetd.

Замечание: Хотя программы, запускаемые из inetd(8), на самом деле не соответствуют термину ''даемоны'', существует традиция называть их именно так. Этот термин и используется в данном разделе.
^

14.6.1. Начальная настройка


Единственное требование для использования TCP Wrappers в FreeBSD это наличие в rc.conf параметров запуска inetd -Ww; это настройки по умолчанию. Конечно, ожидается также наличие правильной настройки /etc/hosts.allow, но syslogd(8) отправит сообщения в системный протокол если что-то не так.

Замечание: В отличие от других реализаций TCP Wrappers, использование hosts.deny не поддерживается. Все параметры настройки должны быть помещены в /etc/hosts.allow.

В простейшей конфигурации, политика подключения сводится к разрешению или блокированию в зависимости от параметров в /etc/hosts.allow. Настройка в FreeBSD по умолчанию заключается в разрешении подключения к любому даемону, запущенному из inetd. Изменение этого поведения будет обсуждаться только после рассмотрения базовой настройки.

Базовая настройка обычно принимает форму daemon : address : action, где daemon это имя даемона, который запускается inetd. В поле address может находиться имя хоста, IP адрес, или IPv6 адрес, заключенный в квадратные скобки ([ ]). Поле action может принимать значения allow или deny, чтобы соответственно разрешать или запрещать доступ. Помните, что поиск правил производится до первого совпадения. При обнаружении совпадения применяется соответствующее правило и поиск прерывается.

Существуют и другие параметры, но они будут описаны в следующих разделах. Простая конфигурация может быть, например, такой: для разрешения соединений по протоколу POP3 к даемону mail/qpopper, в hosts.allow необходимо добавить следующие строки:

# This line is required for POP3 connections:

qpopper : ALL : allow

После добавления этой строки, inetd необходимо перезапустить. Это можно выполнить командой kill(1) или скриптом /etc/rc.d/inetd с параметром restart.
^

14.6.2. Расширенная конфигурация


У TCP Wrappers имеются дополнительные параметры; они дают дополнительные возможности контроля над соединениями. Иногда бывает полезно возвращать комментарий определенным хостам или при подключении к определенным даемонам. В других случаях может быть необходимо добавить запись в лог файл, или отправить письмо администратору. В определенных ситуациях сервис должен использоваться только для локальных соединений. Все это возможно с использованием параметров c шаблонами, символами подстановки и путем выполнения внешних команд. Следующие два раздела посвящены этим типам настроек.
^
14.6.2.1. Внешние команды

Предположим ситуацию, в которой соединение должно быть запрещено, а о причине необходимо сообщить вызывающей стороне. Как это можно сделать? Соответствующую возможность предоставляет параметр twist. При попытке подключения выполняется команда или скрипт, заданный этим параметром. Пример дан в файле hosts.allow:

# The rest of the daemons are protected.

ALL : ALL \

: severity auth.info \

: twist /bin/echo "You are not welcome to use %d from %h."

В этом примере сообщение, ''You are not allowed to use daemon from hostname.'' будет возвращено от всех даемонов, которые не были предварительно настроены в файле доступа. Обратите внимание, что возвращаемое сообщение должно быть заключено в кавычки; из этого правила нет исключений.

Внимание: Возможна реализация DoS атаки, когда группа атакующих производит множество запросов на подключение.

Возможно также использование параметра spawn. Как и параметр twist, параметр spawn подразумевает запрет соединения и может использоваться для запуска команд или скриптов. В отличие от twist, spawn не отправляет ответ вызывающей стороне. Например, следующая конфигурация:

# We do not allow connections from example.com:

ALL : .example.com \

: spawn (/bin/echo %a from %h attempted to access %d >> \

/var/log/connections.log) \

: deny

отклонит все попытки соединения из домена *.example.com; имя хоста, IP адрес и даемон протоколируются в файл /var/log/connections.log.

Помимо приведенных выше символов подстановки, например %a, существует еще несколько символов. Обратитесь к странице hosts_access(5) справочной системы за полным списком.
^
14.6.2.2. Параметры – шаблоны

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

# Block possibly spoofed requests to sendmail:

sendmail : PARANOID : deny

В этом примере все запросы на подключения к sendmail от хостов, IP адрес которых не соответствует имени хоста, будут отклонены.

Предостережение: Использование PARANOID невозможно, если у клиента или сервера неправильно настроен DNS. В таких случаях необходимо вмешательство администратора.

Более подробная информация о шаблонах и их возможностях дана на странице hosts_access(5) справочной системы.

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

14.7. KerberosIV


Предоставил Mark Murray. Оригинальный текст предоставил Mark Dapoz.

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

Последующие инструкции могут использоваться в качестве руководства по настройке поставляемого с FreeBSD Kerberos. Тем не менее, вам могут потребоваться страницы справочника полного дистрибутива.
^

14.7.1. Установка KerberosIV


Kerberos это опциональный компонент FreeBSD. Простейший способ установки этой программы это выбор krb4 или krb5 из sysinstall во время первой установки FreeBSD. Будет установлен ''eBones'' (KerberosIV) или ''Heimdal'' (Kerberos5) вариант Kerberos. Включение этих реализаций объясняется тем, что они разработаны вне США/Канады и доступны вне этих стран, поскольку на них не влияют ограничения на экспорт криптографического кода из США.

Кроме того, реализация MIT Kerberos доступна из Коллекции Портов в виде пакета security/krb5.
^

14.7.2. Создание базы данных


Это необходимо сделать только на сервере Kerberos. Во-первых, убедитесь что не осталось старой базы данных Kerberos. Войдите в каталог /etc/kerberosIV и убедитесь, что в нем находятся только эти файлы:

# cd /etc/kerberosIV

# ls

README krb.conf krb.realms

Если присутствуют еще какие-то файлы (такие как principal.* или master_key), используйте команду kdb_destroy для удаления старой базы данных Kerberos, или, если Kerberos не запущен, просто удалите эти файлы.

Затем отредактируйте файлы krb.conf и krb.realms, введя ваши данные. В этом примере уникальный идентификатор EXAMPLE.COM, сервер grunt.example.com. Отредактируем или создадим файл krb.conf:

# cat krb.conf

EXAMPLE.COM

EXAMPLE.COM grunt.example.com admin server

CS.BERKELEY.EDU okeeffe.berkeley.edu

ATHENA.MIT.EDU kerberos.mit.edu

ATHENA.MIT.EDU kerberos-1.mit.edu

ATHENA.MIT.EDU kerberos-2.mit.edu

ATHENA.MIT.EDU kerberos-3.mit.edu

LCS.MIT.EDU kerberos.lcs.mit.edu

TELECOM.MIT.EDU bitsy.mit.edu

ARC.NASA.GOV trident.arc.nasa.gov

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

Первая строка содержит идентификатор, под которым работает эта система. Остальные строки связывают идентификаторы с именами хостов. Сначала указывается идентификатор, затем хост под этим идентификатором, работающий как ''центр распространения ключей''. Слова admin server с последующим именем хоста означают, что этот хост также является сервером администрирования базы данных. За дальнейшей информацией об этих терминах обратитесь к страницам справочника по Kerberos.

Мы добавили grunt.example.com к идентификатору EXAMPLE.COM и кроме того сопоставили всем хостам в домене .example.com идентификатор EXAMPLE.COM. Файл krb.realms будет выглядеть так:

# cat krb.realms

grunt.example.com EXAMPLE.COM

.example.com EXAMPLE.COM

.berkeley.edu CS.BERKELEY.EDU

^ .MIT.EDU ATHENA.MIT.EDU

.mit.edu ATHENA.MIT.EDU

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

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

Теперь мы готовы к созданию базы данных. Потребуется всего лишь запустить сервер Kerberos (или центр распространения ключей). Используйте для этого kdb_init:

# kdb_init

Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM

You will be prompted for the database Master Password.

It is important that you NOT FORGET this password.


Введите главный ключ Kerberos:

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

# kstash


Enter Kerberos master key:


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Этой командой зашифрованный главный пароль сохранен в /etc/kerberosIV/master_key.
^

14.7.3. Запуск Kerberos


Для каждой системы, защищаемой Kerberos, в базу данных должны быть добавлены две записи. Это kpasswd и rcmd. Они добавляются вместе с именем системы.

Эти даемоны, kpasswd и rcmd позволяют другим системам изменять пароли Kerberos и запускать такие команды как rcp(1), rlogin(1), rsh(1).

Теперь добавим эти записи:

# kdb_edit

Opening database...


Enter Kerberos master key:


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Previous or default values are in [brackets] ,

enter return to leave the same, or new value.


Principal name: passwd

Instance: grunt


, Create [y] ? y


Principal: passwd, Instance: grunt, kdc_key_ver: 1

New Password: <---- enter RANDOM here

Verifying password


New Password: <---- enter RANDOM here


Random password [y] ? y


Principal's new key version = 1

Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?

Max ticket lifetime (*5 minutes) [ 255 ] ?

Attributes [ 0 ] ?

Edit O.K.

Principal name: rcmd

Instance: grunt


, Create [y] ?


Principal: rcmd, Instance: grunt, kdc_key_ver: 1

New Password: <---- enter RANDOM here

Verifying password


New Password: <---- enter RANDOM here


Random password [y] ?


Principal's new key version = 1

Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?

Max ticket lifetime (*5 minutes) [ 255 ] ?

Attributes [ 0 ] ?

Edit O.K.

Principal name: <---- null entry here will cause an exit
^

14.7.4. Создание файла настройки сервера


Теперь необходимо создать все записи сервисов, которые были определены для каждого компьютера. Используем для этого команду ext_srvtab. Будет создан файл, который должен быть скопирован или перемещен безопасным способом в каталог /etc/kerberosIV каждого Kerberos клиента. Этот файл должен присутствовать на каждом сервере и клиенте, он необходим для работы Kerberos.

# ext_srvtab grunt

Enter Kerberos master key:


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Generating 'grunt-new-srvtab'....

Эта команда создаст временный файл, который должен быть переименован в srvtab, чтобы серверы смогли обратиться к нему. Используйте команду mv(1) для перемещения его в исходной системе:

# mv grunt-new-srvtab srvtab

Если файл предназначен для клиентской системы, и сеть не безопасна, скопируйте client-new-srvtab на съемный носитель и перенесите файл с его помощью. Убедитесь, что переименовали его в srvtab в каталоге /etc/kerberosIV клиента, и что режим доступа к нему 600:

# mv grumble-new-srvtab srvtab

# chmod 600 srvtab
^

14.7.5. Пополнение базы данных


Теперь необходимо добавить в базу данных пользователей. Во-первых, создадим запись для пользователя jane. Используйте команду kdb_edit:

# kdb_edit

Opening database...


Enter Kerberos master key:


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Previous or default values are in [brackets] ,

enter return to leave the same, or new value.


Principal name: jane

Instance:


, Create [y] ? y


Principal: jane, Instance: , kdc_key_ver: 1

New Password: <---- enter a secure password here

Verifying password


New Password: <---- re-enter the password here

Principal's new key version = 1

Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?

Max ticket lifetime (*5 minutes) [ 255 ] ?

Attributes [ 0 ] ?

Edit O.K.

Principal name: <---- null entry here will cause an exit
^

14.7.6. Тестирование всей системы


Во-первых, запустите даемоны Kerberos. При правильном редактировании файла /etc/rc.conf они запустятся автоматически при перезагрузке. Это необходимо только на сервере Kerberos. Клиенты Kerberos получат все необходимые данные из каталога /etc/kerberosIV.

# kerberos &

Kerberos server starting

Sleep forever on error

Log file is /var/log/kerberos.log

Current Kerberos master key version is 1.


Master key entered. BEWARE!


Current Kerberos master key version is 1

Local realm: EXAMPLE.COM

# kadmind -n &

KADM Server KADM0.0A initializing

Please do not use 'kill -9' to kill this job, use a

regular kill instead


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Теперь для получения доступа через созданного пользователя jane используйте kinit:

% kinit jane

MIT Project Athena (grunt.example.com)

Kerberos Initialization for "jane"

Password:

Попробуйте просмотреть имеющиеся данные с помощью klist:

% klist

Ticket file: /tmp/tkt245

Principal: jane@EXAMPLE.COM


Issued Expires Principal

Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM

Теперь попробуйте изменить пароль с помощью passwd(1), чтобы убедиться, что даемон kpasswd может получить информацию из базы данных Kerberos:

% passwd

realm EXAMPLE.COM

Old password for jane:

New Password for jane:

Verifying password

New Password for jane:

Password changed.
^

14.7.7. Включение su


Kerberos позволяет назначить каждому пользователю, который нуждается в привилегиях root, свой собственный пароль su(1). Необходимо добавить учётную запись, которой разрешено получать root доступ через su(1). Это делается путем связывания учётной записи root с пользовательской учётной записью. Создадим в базе данных Kerberos запись jane.root с помощью kdb_edit:

# kdb_edit

Opening database...


Enter Kerberos master key:


Current Kerberos master key version is 1.


Master key entered. BEWARE!

Previous or default values are in [brackets] ,

enter return to leave the same, or new value.


Principal name: jane

Instance: root


, Create [y] ? y


Principal: jane, Instance: root, kdc_key_ver: 1

New Password: <---- enter a SECURE password here

Verifying password


New Password: <---- re-enter the password here


Principal's new key version = 1

Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?

Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!

Attributes [ 0 ] ?

Edit O.K.

Principal name: <---- null entry here will cause an exit

Теперь проверим работоспособность этой записи:

# kinit jane.root

MIT Project Athena (grunt.example.com)

Kerberos Initialization for "jane.root"

Password:

Необходимо добавить пользователя к root файлу .klogin:

# cat /root/.klogin

jane.root@EXAMPLE.COM

Теперь попробуйте выполнить su(1):

% su

Password:

и посмотрите на имеющиеся данные:

# klist

Ticket file: /tmp/tkt_root_245

Principal: jane.root@EXAMPLE.COM


Issued Expires Principal

May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM
^

14.7.8. Использование других команд


В примере выше мы создали запись (principal) jane с доступом к root (instance). Она основана на пользователе с таким же именем, как и идентификатор, что принято Kerberos по умолчанию;
. в форме .root позволяет использовать su(1) для доступа к root, если соответствующие записи находятся в файле .klogin домашнего каталога root:

# cat /root/.klogin

jane.root@EXAMPLE.COM

Подобно этому, если в файле .klogin из домашнего каталога пользователя есть строки в форме:

% cat ~/.klogin

jane@EXAMPLE.COM

jack@EXAMPLE.COM

это позволит любому с идентификатором EXAMPLE.COM, кто аутентифицировался как jane или jack (с помощью команды kinit, см. выше) получить доступ к учётной записи пользователя jane или файлам этой системы (grunt) через rlogin(1), rsh(1) или rcp(1).

Например, jane может входить в другую систему используя Kerberos:

% kinit

MIT Project Athena (grunt.example.com)

Password:

% rlogin grunt

Last login: Mon May 1 21:14:47 from grumble

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California. All rights reserved.


FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Или jack входит в учётную запись jane's на этом же компьютере (файл .klogin jane настроен как показано выше, и в Kerberos настроена учётная запись jack):

% kinit

% rlogin grunt -l jane

MIT Project Athena (grunt.example.com)

Password:

Last login: Mon May 1 21:16:55 from grumble

Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California. All rights reserved.

FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

14.8. Kerberos5


Предоставил Tillman Hodgson. Оригинальный материал предоставил Mark Murray.

Все релизы FreeBSD после FreeBSD-5.1 включают поддержку только Kerberos5. Таким образом, Kerberos5 это единственная включаемая в поставку версия и его конфигурация похожа на KerberosIV во многих аспектах. Эта информация применима только к Kerberos5 из релизов после FreeBSD-5.0. Пользователи, желающие использовать пакет KerberosIV, могут установить его из порта security/krb4.

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

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

Следовательно крайне рекомендуется использовать Kerberos с другими методами безопасности, предоставляющими сервисы авторизации и аудита.

Последующие инструкции могут использоваться в качестве руководства по настройке Kerberos, поставляемого с FreeBSD. Тем не менее, вам потребуется обратиться к соответствующим страницам справочника за полным описанием.

В целях демонстрации установки Kerberos, будут применены следующие обозначения:

• DNS домен (''зона'') example.org.

• Уникальный идентификатор Kerberos EXAMPLE.ORG.

Замечание: Используйте действующие имена доменов при настройке Kerberos даже если вы будете использовать его во внутренней сети. Это позволит избежать проблем с DNS и гарантирует возможность связи с Kerberos под другими идентификаторами.

14.8.1. История


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

Kerberos это и имя сетевого протокола аутентификации и общий термин для описания программ, где он реализован (например, Kerberos telnet). Текущая версия протокола 5 описана в RFC 1510.

Доступно несколько свободных реализаций этого протокола, работающих на множестве операционных систем. Massachusetts Institute of Technology (MIT), где Kerberos был первоначально разработан, продолжает разрабатывать собственный пакет Kerberos. Он обычно использовался в США как криптографический продукт, и в этом качестве попадал под действие ограничений на экспорт. MIT Kerberos доступен в виде порта (security/krb5). Heimdal Kerberos это другая реализация версии 5, которая разрабатывалась исключительно вне США для обхода экспортных ограничений (и поэтому часто включалась в некоммерческие реализации UNIX). Heimdal Kerberos доступен в виде порта (security/heimdal), его минимальный комплект включен в базовую установку FreeBSD.

В целях получения наибольшей аудитории, в этих инструкциях предполагается использование Heimdal включаемого в FreeBSD.
^

14.8.2. Настройка Heimdal KDC


Центр распространения ключей (Key Distribution Center, KDC) это централизованный сервис аутентификации, предоставляемый Kerberos — это компьютер, который предоставляет доступ через Kerberos. KDC считается доверяемым всеми другими компьютерами с определенным идентификатором Kerberos и поэтому к нему предъявляются высокие требования безопасности.

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

Перед началом настройки KDC, убедитесь что в файле /etc/rc.conf содержатся правильные настройки для работы в качестве KDC (вам может потребоваться изменить пути в соответствии с собственной системой):

kerberos5_server_enable="YES"

kadmind5_server_enable="YES"

kerberos_stash="YES"

Замечание: Параметр kerberos_stash существует только в FreeBSD 4.X.

Затем приступим к редактированию файла настройки Kerberos, /etc/krb5.conf:

[libdefaults]

default_realm = EXAMPLE.ORG

[realms]

^ EXAMPLE.ORG = {

kdc = kerberos.example.org

admin_server = kerberos.example.org

}

[domain_realm]

.example.org = EXAMPLE.ORG

Обратите внимание что в файле /etc/krb5.conf подразумевается наличие у KDC полного имени kerberos.example.org. Вам потребуется добавить CNAME (синоним) к файлу зоны, если у KDC другое имя.

Замечание: Для больших сетей с правильно настроенным сервером BIND DNS пример выше может быть урезан до:

[libdefaults]

default_realm = EXAMPLE.ORG

Со следующими строками, добавленными в файл зоны example.org:

_kerberos._udp IN SRV 01 00 88 kerberos.example.org.

_kerberos._tcp IN SRV 01 00 88 kerberos.example.org.

_kpasswd._udp IN SRV 01 00 464 kerberos.example.org.

_kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org.

_kerberos IN TXT EXAMPLE.ORG

Замечание: Чтобы клиенты могли найти сервисы Kerberos, необходимо наличие или полностью настроенного /etc/krb5.conf или минимально настроенного /etc/krb5.conf и правильно настроенного DNS сервера.

Создадим теперь базу данных Kerberos. Эта база данных содержит ключи всех основных хостов, зашифрованных с помощью главного пароля. Вам не требуется помнить этот пароль, он хранится в файле (/var/heimdal/m-key). Для создания главного ключа запустите kstash и введите пароль.

Как только будет создан главный ключ, вы можете инициализировать базу данных с помощью программы kadmin с ключом -l (означающим ''local''). Этот ключ сообщает kadmin обращаться к файлам базы данных непосредственно вместо использования сетевого сервиса kadmind. Это помогает решить ''проблему курицы и яйца'', когда обращение идет к еще не созданной базе данных. Как только вы увидите приглашение kadmin, используйте команду init для создания базы данных идентификаторов.

Наконец, оставаясь в приглашении kadmin, создайте первую запись с помощью команды add. Оставьте неизменными параметры по умолчанию, вы всегда сможете изменить их позже с помощью команды modify. Обратите внимание, что вы всегда можете использовать команду ? для просмотра доступных параметров.

Пример создания базы данных показан ниже:

# kstash

Master key: xxxxxxxx

Verifying password - Master key: xxxxxxxx


# kadmin -l

kadmin> init EXAMPLE.ORG

Realm max ticket life [unlimited]:

kadmin> add tillman

Max ticket life [unlimited]:

Max renewable life [unlimited]:

Attributes []:

Password: xxxxxxxx

Verifying password - Password: xxxxxxxx

Теперь пришло время запустить сервисы KDC. Выполните команды /etc/rc.d/kerberos start и /etc/rc.d/kadmind start для запуска сервисов. Заметьте, что ни один из поддерживающих Kerberos даемонов на этот момент запущен не будет, но у вас должна быть возможность убедиться в том, что KDC функционирует путем получения списка доступа для пользователя, которого вы только что самостоятельно создали из командной строки самого KDC:

% k5init tillman

tillman@EXAMPLE.ORG's Password:


% k5list

Credentials cache: FILE:/tmp/krb5cc_500

Principal: tillman@EXAMPLE.ORG


Issued Expires Principal

Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
^

14.8.3. Сервер Kerberos с сервисами Heimdal


Для начала нам потребуется копия файла настройки Kerberos, /etc/krb5.conf. Просто скопируйте его с KDC на клиентский компьютер безопасным способом (используя сетевые утилиты, такие как scp(1), или физически, с помощью дискеты).

Затем вам понадобится файл /etc/krb5.keytab. Это основное различие между сервером, поддерживающим Kerberos и рабочими станциями — на сервере должен быть файл keytab. В этом файле находится центральный ключ сервера, который позволяет KDC проверять все другие идентификаторы. Он должен быть помещен на сервер безопасным способом, поскольку безопасность сервера может быть нарушена, если ключ станет общедоступен. Это означает, что его передача через прозрачный канал, такой как FTP — очень плохая идея.

Обычно перенос файла keytab на сервер производится с помощью программы kadmin. Это удобно, поскольку вам потребуется также создать запись хоста (KDC часть krb5.keytab) с помощью kadmin.

Обратите внимание, что должны быть уже зарегистрированы в системе и необходимо наличие прав на использование интерфейса kadmin в файле kadmind.acl. Обратитесь к разделу ''Remote administration'' в info страницах Heimdal (info heimdal) за деталями по составлению списка доступа. Если вы не хотите включать удаленный доступ kadmin, можете просто подключиться к KDC через защищенное соединение (локальную консоль, ssh(1) или Kerberos telnet(1)) и выполнять администрирование локально с помощью kadmin -l.

После добавления файла /etc/krb5.conf, вы можете использовать kadmin с сервера Kerberos. Команда add --random-key позволит вам добавить запись для сервера, а команда ext позволит перенести эту запись в собственный keytab файл сервера. Например:

# kadmin

kadmin> add --random-key host/myserver.example.org

Max ticket life [unlimited]:

Max renewable life [unlimited]:

Attributes []:

kadmin> ext host/myserver.example.org

kadmin> exit

Обратите внимание, что команда ext (сокращение от ''extract'') сохраняет полученный ключ в файле /etc/krb5.keytab по умолчанию.

Если на KDC не запущен kadmind (возможно по соображениям безопасности) и вы не можете получить доступ к kadmin удаленно, возможно добавление записи хоста (host/myserver.EXAMPLE.ORG) непосредственно на KDC с последующим извлечением ее во временный файл (и перезаписью /etc/krb5.keytab на KDC) примерно так:

# kadmin

kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org

kadmin> exit

Затем вы можете скопировать keytab на сервер защищенным способом (например, используя scp или дискету). Убедитесь, что используемое имя keytab не совпадает с именем по умолчанию во избежание перезаписывания keytab на KDC.

Теперь ваш сервер может связываться с KDC (добавлен файл krb5.conf) и идентифицировать себя (добавлен файл krb5.keytab). Теперь вы готовы к включению некоторых сервисов Kerberos. В этом примере мы включим сервис telnet, поместив в /etc/inetd.conf нижеприведенную строку и перезапустив сервис inetd(8) командой /etc/rc.d/inetd restart:

telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user

Очень важно установить ключ -a (тип аутентификации) в user. Обратитесь к странице справочника telnetd(8) за подробной информацией.
^

14.8.4. Клиент Kerberos с Heimdal


Настройка клиентского компьютера почти тривиально проста. Как только настройка Kerberos закончена, вам потребуется только файл настройки Kerberos, /etc/krb5.conf. Просто скопируйте его безопасным способом на клиентский компьютер с KDC.

Протестируйте клиентский компьютер, попытавшись использовать kinit, klist, и kdestroy для получения, отображения и удаления списка доступа. Соединитесь с Kerberos севером используя клиент Kerberos, если соединение не работает и получение доступа является проблемой, это скорее всего проблема сервера, а не клиента или KDC.

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

Основные клиентские приложения Kerberos (традиционно называющиеся kinit, klist, kdestroy, и kpasswd) находятся в базовой установке FreeBSD. Обратите внимание, что в FreeBSD версий до 5.0 они были переименованы в k5init, k5list, k5destroy, k5passwd, и k5stash (хотя их обычно использовали лишь однократно).

Различные неосновные клиентские приложения Kerberos также устанавливаются по умолчанию. Здесь проявляется ''минимальность'' базовой установки Heimdal: telnet это единственное приложение, поддерживающее Kerberos.

Порт Heimdal добавляет некоторые отсутствующие клиентские приложения: поддерживающие Kerberos версии ftp, rsh, rcp, rlogin, и некоторые другие реже используемые программы. Порт MIT также содержит полный пакет клиентских приложений Kerberos.
^

14.8.5. Пользовательские файлы настройки: .k5login и .k5users


Учётные записи пользователя в Kerberos (например tillman@EXAMPLE.ORG) обычно связаны с локальными учётными записями (например с локальной учётной записью6 tillman). Клиентские приложения, такие как telnet, обычно не требуют указания имени пользователя или учётной записи.

Тем не менее, время от времени вам может потребоваться дать доступ к локальной учётной записи кому-то, у кого нет соответствующей учётной записи Kerberos. Например, пользователю tillman@EXAMPLE.ORG может потребоваться доступ к локальной учётной записи webdevelopers. Другим учётным записям также может потребоваться доступ к этой локальной учётной записи.

Файлы .k5login и .k5users, помещенные в домашний каталог пользователя, могут быть использованы подобно действенной комбинации .hosts и .rhosts для решения этой проблемы. Например, файл .k5login со следующим содержанием:

tillman@example.org

jdoe@example.org

помещен в домашний каталог локального пользователя webdevelopers, то обе упомянутые учётные записи получат доступ к этой учётной записи без необходимости наличия общего пароля.

Рекомендуется прочитать страницу справочника по этим командам. Обратите внимание, что страница справочника о ksu содержит информацию по .k5users.
^

14.8.6. Подсказки, советы и решение проблем с Kerberos


• При использовании портов как Heimdal так и MIT Kerberos убедитесь, что в PATH версии Kerberos клиентов указаны перед их версиями в базовой системе.

• Все ли компьютеры в пределах данного realm синхронизированы по времени? Если нет, аутентификация может завершиться неудачно. Разд. 25.11 описывает как синхронизировать часы с использованием NTP.

• MIT и Heimdal успешно взаимодействуют. За исключением kadmin, протокол для которого не стандартизован.

• Если вы изменяете hostname, потребуется также изменить учётную запись host/ и обновить keytab. Это также необходимо для специальных записей в keytab, таких как www/ запись модуля Apache www/mod_auth_kerb.

• Все хосты под общим идентификатором должны разрешаться DNS (прямое и обратное разрешение), или как минимум через /etc/hosts. Записи CNAME будут работать, но записи A и PTR должны быть корректны и находиться на своем месте. Сообщение об ошибке не всегда интуитивно понятно: Kerberos5 refuses authentication because Read req failed: Key table entry not found.

• Некоторые операционные системы, способные работать в качестве клиентов KDC не устанавливают права для ksu в setuid root. Это означает, что ksu не работает, что хорошо является хорошей идеей для безопасности, но неудобно. Это не ошибка KDC.

• С MIT Kerberos, если вы хотите продлить действие доступа до значения большего, чем десять часов по умолчанию, используйте команду modify_principal в kadmin для изменения maxlife доступа к самой учётной записи и к учётной записи krbtgt. Затем возможно использование kinit с параметром -l для запроса доступа с большим временем действия.



Замечание: Если вы запускаете перехватчик пакетов на KDC для разрешения проблем, а затем запускаете kinit с рабочей станции, то увидите, что TGT посылается непосредственно при запуске kinit — даже до того, как вы введете пароль! Объяснение в том, что сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровка TGT, который уже получен kinit. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее ''удостоверение''. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT.

• Если вы хотите установить большое время жизни доступа (например, неделю), и используете ^ OpenSSH для соединения с компьютером, где хранится ''билет'', убедитесь, что параметр Kerberos TicketCleanup установлен в no в файле sshd_config, или билеты будут уничтожены при выходе из сеанса.

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

• При настройке файла krb5.dict на предотвращение использования определенных плохих паролей (страница справочника для kadmind кратко рассказывает об этом), запомните, что это применимо только к учётным записям, для которых действует политика паролей. Формат файла krb5.dict прост: одно слово на строку. Может помочь создание символической ссылки на /usr/share/dict/words.
^

14.8.7. Отличия от порта MIT


Основное различие между установками MIT и Heimdal относится к программе kadmin, которая имеет другой (но эквивалентный) набор команд и использует другой протокол. Если ваш KDC работает на MIT, вы не сможете использовать kadmin для удаленного администрирования KDC (и наоборот, по этой же причине).

Опции командной строки клиентов также могут немного отличаться для одинаковых задач. Рекомендуется следование инструкциям на MIT Kerberos Web-сайте (http://web.mit.edu/Kerberos/www/). Будьте внимательны при определении PATH: порт MIT устанавливается по умолчанию в /usr/local/, и если в PATH вначале указаны системные каталоги, вместо приложений MIT могут быть запущены системные приложения.

Замечание: С портом MIT security/krb5, предоставляемым FreeBSD, убедитесь что файл /usr/local/share/doc/krb5/README.FreeBSD установлен портом, если вы хотите понять почему вход через telnetd и klogind иногда происходит так странно. Наиболее важно, исправление ''incorrect permissions on cache file'' требует использования бинарного файла login.krb5 для аутентификации, чтобы права на переданное удостоверение передавались правильно.
^

14.8.8. Преодоление ограничений, обнаруженных в Kerberos

14.8.8.1. Kerberos это все или ничего

Каждый сервис, работающий в сети, должен быть модифицирован для работы с Kerberos (или другим способом защищен от атак по сети) или удостоверения пользователей могут быть украдены или использованы повторно. В качестве примера может быть приведено использование Kerberos версий оболочек для удаленной работы (например через rsh и telnet), при наличии POP3 сервера, получающего пароли в незашифрованном виде.
^
14.8.8.2. Kerberos предназначен для однопользовательских рабочих станций

В многопользовательской среде Kerberos менее безопасен. Это потому, что он хранит билеты в каталоге /tmp, которая доступна для чтения всем. Если пользователь работает с несколькими другими пользователями одновременно на одном компьютере (т.е. в многопользовательской среде), возможна кража (копирование) билета другим пользователем.

Решить проблему можно с помощью параметра командной строки -c или (предпочтительно) с помощью переменной окружения KRB5CCNAME, но это делается редко. Для преодоления ограничения достаточно сохранять билет в домашнем каталоге пользователя и использовать простые ограничения на доступ к файлам.
^
14.8.8.3. От KDC зависит вся система

Архитектура системы такова, что KDC должен быть максимально защищен, поскольку главный пароль базы данных содержится в нем. На KDC не должно быть запущено никаких других сервисов и он должен быть защищен физически. Опасность велика, поскольку Kerberos хранит все пароли зашифрованными одним ключом (''главным'' ключом), который хранится в файле на KDC.

Хорошей новостью является то, что кража главного ключа не станет такой проблемой, как может показаться. Главный ключ используется только для шифрования базы данных Kerberos и в качестве seed для генератора случайных чисел. Поскольку доступ к KDC защищен, атакующий мало что сможет сделать с главным ключом.

Кроме того, если KDC станет недоступен (возможно по причине атак DoS или проблем в сети) сетевые сервисы будет невозможно использовать, поскольку аутентификация не может быть выполнена. Уменьшить последствия можно при наличии нескольких KDC (один главный и один или несколько резервных) и с аккуратно реализованной резервной аутентификацией (отлично подойдет PAM).
^
14.8.8.4. Недостатки Kerberos

Kerberos позволяет пользователям, хостам и сервисам производить аутентификацию друг друга. В нем нет механизма аутентификации KDC для пользователей, хостов или сервисов. Это означает, что поддельный kinit (например) может записывать все имена пользователей и паролей. Помочь решить проблему может security/tripwire или другой инструмент проверки целостности файловой системы.
^

14.8.9. Ресурсы и информация для дальнейшего изучения


Kerberos FAQ (http://www.faqs.org/faqs/Kerberos-faq/general/preamble.html)

• Разработка системы аутентификации: диалог в четырех сценах (http://web.mit.edu/Kerberos/www/dialogue.html)

• RFC 1510, Kerberos Network Authentication Service (V5) (http://www.ietf.org/rfc/rfc1510.txt?number=1510)

• Домашняя страница MIT Kerberos (http://web.mit.edu/Kerberos/www/)

• Домашняя страница Heimdal Kerberos (http://www.pdc.kth.se/heimdal/)

14.9. OpenSSL


Написал: Tom Rhodes.

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

OpenSSL может использоваться для шифрования соединений почтовых клиентов, транзакций через интернет, например для кредитных карт, и многого другого. Многие порты, такие как www/apache13-ssl и mail/sylpheed-claws собираются с OpenSSL.

Замечание: В большинстве случаев в Коллекции Портов будет сделана попытка построения порта security/openssl, если только переменная WITH_OPENSSL_BASE не установлена явно в ''yes''.

Версия OpenSSL, включаемая в FreeBSD, поддерживает сетевые протоколы безопасности Secure Sockets Layer v2/v3 (SSLv2/SSLv3), Transport Layer Security v1 (TLSv1) и может быть использована в качестве основной криптографической библиотеки.

Замечание: Хотя OpenSSL поддерживает алгоритм IDEA, по умолчанию он отключен из-за патентных ограничений Соединенных Штатов. Для его использования необходимо ознакомиться с лицензией, и, если ограничения приемлемы, установить в make.conf переменную MAKE_IDEA.

Наиболее часто OpenSSL используется для создания сертификатов, используемых программными пакетами. Эти сертификаты подтверждают, что данные компании или частного лица верны и не подделаны. Если рассматриваемый сертификат не был проверен одним из нескольких сертификационных центров (''Certificate Authorities'' - CA), обычно выводится предупреждение. Центр сертификации представляет собой компанию, такую, как VeriSign (http://www.verisign.com), которая подписывает сертификаты для подтверждения данных частных лиц или компаний. Эта процедура не бесплатна и не является абсолютно необходимой для использования сертификатов; однако может успокоить некоторых особо осторожных пользователей.
^

14.9.1. Генерирование сертификатов


Для генерирования сертификатов доступна следующая команда:

# openssl req -new -nodes -out req.pem -keyout cert.pem

Generating a 1024 bit RSA private key

................++++++

.......................................++++++

writing new private key to 'cert.pem'

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:US

State or Province Name (full name) [Some-State]:PA

Locality Name (eg, city) []:Pittsburgh

Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company

Organizational Unit Name (eg, section) []:Systems Administrator

Common Name (eg, YOUR name) []:localhost.example.org

Email Address []:trhodes@FreeBSD.org


Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:^ SOME PASSWORD

An optional company name []:Another Name

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

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

Когда подпись CA не требуется, может быть создан самоподписанный сертификат. Сначала создайте ключ RSA:

# openssl dsaparam -rand -genkey -out myRSA.key 1024

Теперь создайте ключ CA:

# openssl gendsa -des3 -out myca.key myRSA.key

Используйте этот ключ при создании сертификата:

# openssl req -new -x509 -days 365 -key myca.key -out new.crt

В каталоге должно появиться два новых файла: подпись сертификата, myca.key и сам сертификат, new.crt. Они должны быть помещены в каталог, доступный для чтения только root, желательно внутри /etc. Права на каталог можно изменить chmod с параметрами 0700.
^

14.9.2. Использование сертификатов, пример


Итак, что могут сделать эти файлы? Хорошим применением может стать шифрование соединений для Sendmail MTA. Это сделает ненужным использование простой текстовой аутентификации для тех, кто отправляет почту через локальный MTA.

Замечание: Это не лучшее из возможных использований, поскольку некоторые MUA выдадут ошибку, если сертификат не установлен локально. Обратитесь к поставляемой с программой документации за информацией по установке сертификата.

Следующие строки должны быть помещены в локальный файл .mc:

dnl SSL Options

define(`confCACERT_PATH',`/etc/certs')dnl

define(`confCACERT',`/etc/certs/new.crt')dnl

define(`confSERVER_CERT',`/etc/certs/new.crt')dnl

define(`confSERVER_KEY',`/etc/certs/myca.key')dnl

define(`confTLS_SRV_OPTIONS', `V')dnl

Где /etc/certs/ это каталог для локального хранения сертификата и ключей. После настройки необходимо собрать локальный файл .cf. Это легко сделать, набрав make install в каталоге /etc/mail. Затем выполните команду make restart, которая должна запустить даемон Sendmail.

Если все пройдет нормально, в файле /var/log/maillog не появятся сообщения об ошибках и запустится процесс Sendmail.

Для проведения простого теста подключитесь к почтовому серверу программой telnet(1):

# telnet example.com 25

Trying 192.0.34.166...

Connected to example.com.

Escape character is '^]'.

220 example.com ESMTP Sendmail 8.12.10/8.12.10; Tue, 31 Aug 2004 03:41:22 -0400 (EDT)

ehlo example.com

250-example.com Hello example.com [192.0.34.166], pleased to meet you

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-8BITMIME

250-SIZE

250-DSN

250-ETRN

^ 250-AUTH LOGIN PLAIN

250-STARTTLS

250-DELIVERBY

250 HELP

quit

221 2.0.0 example.com closing connection

Connection closed by foreign host.

Если в выводе появилась строка ''STARTTLS'', все работает правильно.
^

14.10. VPN через IPsec


Написал Nik Clayton.

Создание VPN между двумя сетями, соединенными через интернет, с использованием шлюзов FreeBSD.

14.10.1. Принципы работы IPsec


Написал Hiten M. Pandya.

Этот раздел послужит вам руководством по настройке IPsec и его использованию в среде FreeBSD и Microsoft Windows 2000/XP, соединяемых безопасным способом. Для настройки IPsec необходимо ознакомиться с процессом сборки ядра (Гл. 8).

IPsec это протокол, расположенный поверх слоя Internet Protocol (IP). Он позволяет двум или более хостам связываться защищенным способом (отсюда и название протокола). ''Сетевой стек'' FreeBSD IPsec основан на реализации KAME (http://www.kame.net/), поддерживающей оба семейства протоколов, IPv4 и IPv6.

Замечание: FreeBSD 5.X содержит ''аппаратно поддерживаемый'' стек IPsec, известный как ''Fast IPsec'', заимствованный из OpenBSD. Для оптимизации производительности IPsec он задействует криптографическое оборудование (когда оно доступно) через подсистему crypto(4). Это новая подсистема и она не поддерживает всех возможностей, доступных в KAME версии IPsec. Для включения IPsec с аппаратной поддержкой необходимо добавить в файл настройки ядра следующий параметр:

options FAST_IPSEC # new IPsec (cannot define w/ IPSEC)

Обратите внимание, что на данный момент невозможно использовать подсистему ''Fast IPsec'' вместе с KAME реализацией IPsec. Обратитесь к странице справочника fast_ipsec(4) за дальнейшей информацией.

IPsec состоит из двух подпротоколов:

^ Encapsulated Security Payload (ESP), защищающей данные IP пакета от вмешательства третьей стороны путем шифрования содержимого с помощью симметричных криптографических алгоритмов (таких как Blowfish,3DES).

^ Authentication Header (AH), защищающий заголовок IP пакета от вмешательства третьей стороны и подделки путем вычисления криптографической контрольной суммы и хеширования полей заголовка IP пакета защищенной функцией хеширования. К пакету добавляется дополнительный заголовок с хэшем, позволяющий аутентификацию информации пакета.

ESP и AH могут быть использованы вместе или по отдельности, в зависимости от обстоятельств.

IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения ''виртуальных туннелей'' между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Последний обычно называют виртуальной частной сетью (Virtual Private Network, VPN). За детальной информацией о подсистеме IPsec в FreeBSD обратитесь к странице справочника ipsec(4).

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

options IPSEC #IP security

options IPSEC_ESP #IP security (crypto; define w/ IPSEC)

Если желательна поддержка отладки IPsec, должна быть также добавлена следующая строка:

options IPSEC_DEBUG #debug for IP security


14.10.2. Проблема


Не существует стандарта VPN. Они могут быть реализованы множеством различных технологий, каждая из которых имеет свои сильные и слабые стороны. Этот раздел представляет сценарий и стратегию реализации VPN для этого сценария.
^

14.10.3. Сценарий: Две сети, подключенных к интернет, работающие как одна


Исходные условия таковы:

• Существует как минимум две сети

• Внутри обеих сетей используется IP

• Обе сети соединены через интернет через шлюз, работающий на FreeBSD.

• У шлюза каждой из сетей есть как минимум один публичный IP адрес.

• Внутренние IP адреса двух сетей могут быть публичными или приватными, не имеет значения. На шлюзе может работать NAT, если это необходимо.

• Внутренние IP адреса двух сетей не должны пересекаться. Хотя вероятно теоретически возможно использование комбинации VPN технологии и NAT для настройки такой конфигурации, эта конфигурация будет кошмарна.

Если две сети, которые вы пытаетесь соединить, используют один и тот же диапазон приватных адресов (например, обе используют 192.168.1.x), номера в одной из сетей необходимо изменить.

Топология сети может выглядеть примерно так:



Заметьте, что здесь присутствуют два публичных IP-адреса. В дальнейшем для их обозначения будут использоваться буквы. Если вы увидите эти буквы, замените их на свои публичные IP адреса. Также обратите внимание, что у обеих шлюзов внутренний адрес заканчивается на .1 и диапазоны приватных адресов двух сетей различны (192.168.1.x и 192.168.2.x соответственно). Все компьютеры локальных сетей настроены на использование в качестве шлюза по умолчанию компьютера с адресом, оканчивающимся на .1.

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

Это означает, что (например) компьютер 192.168.1.20 может запустить

ping 192.168.2.34

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

И все это безопасным способом. Это означает, что трафик между сетями зашифрован.

Создание VPN между этими двумя сетями это многошаговый процесс. Этапы создания VPN таковы:

1. Создание ''виртуального'' сетевого подключения между двумя сетями через интернет. Тестирование подключения с помощью таких инструментов как ping(8), чтобы убедиться, что оно работает.

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

3. Настройка дополнительных программ на шлюзах FreeBSD, чтобы компьютеры Windows из одной сети видели компьютеры в другой через VPN.
^
14.10.3.1. Шаг 1: Создание и тестирование ''виртуального'' сетевого подключения

Предположим, что вы работаете на шлюзе сети #1 (с публичным адресом A.B.C.D, приватным адресом 192.168.1.1) и запускаете ping 192.168.2.1, т.е. на приватный адрес машины с IP адресом W.X.Y.Z. Что должно произойти, чтобы это сработало?

1. Шлюз должен знать, как достичь 192.168.2.1. Другими словами, у него должен быть маршрут к 192.168.2.1.

2. Приватные IP адреса, такие как диапазон 192.168.x не адресуются в интернет. Каждый пакет, отправляемый на 192.168.2.1 должен быть ''завернут'' в другой пакет. Исходным адресом пакета должен быть A.B.C.D, а адресом назначения W.X.Y.Z. Этот процесс называется инкапсуляцией.

3. Как только этот пакет достигнет W.X.Y.Z, необходимо будет ''декапсулировать'' его и доставить к 192.168.2.1.

Как вы можете увидеть, это требует ''туннеля'' между двумя сетями. Два конца ''туннеля'' это IP адреса A.B.C.D и W.X.Y.Z. Туннель используется для передачи трафика с приватными IP адресами через интернет.

В FreeBSD этот туннель создается с помощью устройства generic interface, или gif. Как вы можете догадаться, интерфейс gif на каждом хосте должен быть настроен с четырьмя IP адресами; два для публичных IP адресов и два для приватных IP адресов.

В ядро обеих компьютеров FreeBSD должна быть встроена поддержка устройства gif. Вы можете сделать это, добавив строку:

device gif

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

Настройка туннеля это двухшаговый процесс. Во-первых, необходимо задать сведения о внешнем (или публичном) IP адресе с помощью gifconfig(8). Затем о приватном IP адресе с помощью ifconfig(8).

Замечание: В FreeBSD 5.X функциональность, предоставляемая утилитой gifconfig(8), была внесена в ifconfig(8).

На шлюзе сети #1 для настройки туннеля вам потребуется запустить следующие две команды.

gifconfig gif0 A.B.C.D W.X.Y.Z

ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

На другом шлюзе подобные команды, но с IP адресами в обратном порядке.

gifconfig gif0 W.X.Y.Z A.B.C.D

ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff

Затем вы можете запустить:

gifconfig gif0

для просмотра настройки. Например, на шлюзе сети #1 вы увидите:

# gifconfig gif0

gif0: flags=8011 mtu 1280

inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff

physical address inet A.B.C.D --> W.X.Y.Z

Как вы можете видеть, был создан туннель между физическими адресами A.B.C.D и W.X.Y.Z, для туннелирования разрешен трафик между 192.168.1.1 и 192.168.2.1.

Это также добавляет запись к таблице маршрутизации на обеих машинах, вы можете проверить запись командой netstat -rn. Вот вывод этой команды на шлюзе сети #1.

# netstat -rn

Routing tables


Internet:

Destination Gateway Flags Refs Use Netif Expire

...

192.168.2.1 192.168.1.1 UH 0 0 gif0

...

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

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

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

ipfw add 1 allow ip from any to any via gif0

разрешит весь трафик между двумя концами VPN без влияния на другие правила брандмауэра. Очевидно, вам потребуется запустить эту команду на обеих шлюзах.

Этого достаточно для включения ping с одного шлюза на другой. На 192.168.1.1, вы сможете запустить

ping 192.168.2.1

и получить ответ, и аналогично на другом шлюзе.

Однако, машины в другой сети пока недоступны. Это из-за маршрутизации — хотя шлюзы знают, как связаться друг с другом, они не знают, как связаться с сетью за другим шлюзом.

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

route add 192.168.2.0 192.168.2.1 netmask 0xffffff00

Она говорит ''Для достижения хостов в сети 192.168.2.0, отправляйте пакеты хосту 192.168.2.1''. Вам потребуется запустить похожую команду на другом шлюзе, но с адресами 192.168.1.x.

IP трафик с хостов в одной сети теперь может достичь хосты в другой сети.

Теперь создано две трети VPN между двумя сетями, поскольку это ''виртуальная (virtual)'' ''сеть (network)''. Она еще не приватная (private). Вы можете протестировать ее с помощью ping(8) и tcpdump(1). Войдите на шлюз и запустите

tcpdump dst host 192.168.2.1

В другой сессии на этом же хосте запустите

ping 192.168.2.1

Вы увидите примерно такие строки:

16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request

16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply

16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request

16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply

16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request

16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply

Как вы видите, ICMP сообщения пересылаются вперед и назад незашифрованными. Если вы использовали с tcpdump(1) параметр -s для получения большего объема данных пакета, то увидите больше информации.

Конечно же это неприемлемо. В следующем разделе мы обсудим защиту соединения между двумя сетями, так что весь трафик будет автоматически шифроваться.

Резюме:

• Настройте оба ядра с ''device gif''.

• Отредактируйте /etc/rc.conf на шлюзе #1 и добавьте следующие строки (подставляя IP адреса где необходимо).

gifconfig_gif0="A.B.C.D W.X.Y.Z"

ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"

static_routes="vpn"

route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"

• Отредактируйте скрипт брандмауэра (/etc/rc.firewall, или подобный) на обеих хостах и добавьте

ipfw add 1 allow ip from any to any via gif0

• Выполните соответствующие изменения в /etc/rc.conf на шлюзе #2, меняя порядок IP адресов.
^
14.10.3.2. Шаг 2: Защита соединения

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

Здесь будут рассмотрены два аспекта настройки.

1. У хостов должен быть способ согласования используемого алгоритма шифрования. Как только хосты договорятся об этом, можно говорить об установленном между ними ''безопасном соединении''.

2. Должен быть механизм определения, какой трафик необходимо шифровать. Конечно, вам не требуется шифровать весь исходящий трафик — достаточно шифровать только трафик, идущий через VPN. Правила, определяющие то, какой трафик необходимо шифровать, называются ''политикой безопасности''.

Безопасное соединение и политика безопасности поддерживаются ядром, и могут быть изменены программами пользователя. Однако перед тем, как вы сможете сделать это, необходимо настроить поддержку протоколов IPsec и Encapsulated Security Payload (ESP) в ядре. Это делается добавлением в настройку ядра параметров:

options IPSEC

options IPSEC_ESP

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

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

Рекомендуется последнее. Помимо прочего, этот способ более прост.

Редактирование и отображение политики безопасности выполняется с помощью setkey(8). По аналогии, setkey используется для настройки таблиц политики безопасности ядра так же, как route(8) используется для настройки таблиц маршрутизации ядра. setkey также может отображать текущие параметры безопасности, и продолжая аналогию дальше, это соответствует netstat -r.

Существует множество даемонов для управления параметрами безопасности в FreeBSD. Здесь будет описано использование одного из них, racoon — он доступен в составе порта security/ipsec-tools в Коллекции Портов FreeBSD.

Даемон racoon должен работать на обеих шлюзах. На каждом из хостов он настраивается с IP адресом другого конца VPN, и секретным ключом (по вашему выбору, должен быть одним и тем же на обеих шлюзах).

Эти два даемона подключаются друг к другу, подтверждают, что они именно те, за кого себя выдают (используя секретный ключ, заданный вами). Затем даемоны генерируют новый секретный ключ и используют его для шифрования трафика через VPN. Они периодически изменяют этот ключ, так что даже если атакующий сломает один из ключей (что теоретически почти невозможно) это не даст ему слишком много — он сломал ключ, который два даемона уже сменили на другой.

Настройки racoon сохраняются в файле ${PREFIX}/etc/racoon. Этот файл не требует слишком больших изменений. Другим компонентом настройки racoon, который потребуется изменить, является ''предварительный ключ''.

В настройке по умолчанию racoon ищет его в файле ${PREFIX}/etc/racoon/psk.txt. Необходимо отметить, что предварительный ключ не используется для шифрования трафика через VPN соединение это просто маркер, позволяющий управляющим ключами даемонам доверять друг другу.

psk.txt содержит строку для каждого удаленного сервера, с которым происходит соединение. В этом примере два сервера, каждый файл psk.txt будет содержать одну строку (каждый конец VPN общается только с другим концом.

На шлюзе #1 эта строка будет выглядеть примерно так:

W.X.Y.Z secret

То есть публичный IP-адрес противоположной стороны, пробел и текстовая строка c секретной фразой. Конечно, вам не стоит использовать в качестве ключевой фразы слово ''secret'' -- здесь применяются обычные правила выбора паролей.

На шлюзе #2 строка будет выглядеть примерно так:

A.B.C.D secret

То есть публичный IP адрес удаленной стороны и та же секретная фраза. Перед запуском racoon режим доступа к файлу psk.txt должен быть установлен в 0600 (т.е. запись и чтение только для root).

Вы должны запустить racoon на обоих шлюзах. Вам также потребуется добавить правила для включения IKE трафика, передающегося по UDP через порт ISAKMP (Internet Security Association Key Management Protocol). Опять же, они должны быть расположены насколько возможно ближе к началу набора правил.

ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp

ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp

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

Как только параметры безопасности установлены, вы можете просмотреть их используя setkey(8). Запустите

setkey -D

на любом из хостов для просмотра информации о параметрах безопасности.

Это одна сторона проблемы. Другая сторона это настройка политики безопасности.

Для создания разумной политики безопасности давайте вспомним, что уже было настроено. Это рассмотрение относится к обеим концам соединения.

Каждый отправляемый IP пакет имеет заголовок, содержащий информацию о пакете. Заголовок включает IP адреса источника и назначения. Как мы уже знаем, приватные IP адреса, такие как 192.168.x.y, не могут появиться в интернет. Они должны быть сначала включены внутрь другого пакета. В этом пакете приватные IP адреса источника и назначения заменяются публичными IP адресами.

То есть исходящий пакет, который выглядит примерно так:



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

Конечно, мы хотим зашифровать весь трафик между VPN. Вы можете сформулировать это на словах так:

''Если пакет отправляется с A.B.C.D, и предназначен для W.X.Y.Z, расшифровать его, используя необходимые параметры безопасности.''

''Если пакет отправляется с W.X.Y.Z, и предназначен для A.B.C.D, расшифровать его, используя необходимые параметры безопасности.''

Это похоже на желаемое, но не совсем то. Если вы сделаете это, весь трафик от и к W.X.Y.Z, даже если он не является частью VPN, будет зашифрован. Правильная политика такова:

''Если пакет отправляется с A.B.C.D, в нем инкапсулирован другой пакет и адрес назначения W.X.Y.Z, зашифровать его, используя необходимые параметры безопасности.''

''Если пакет отправляется с W.X.Y.Z, в нем инкапсулирован другой пакет и адрес назначения A.B.C.D, зашифровать его, используя необходимые параметры безопасности.''

Тонкое, но необходимое различие.

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

Настройка на шлюзе #1 (где есть публичный IP адрес A.B.C.D) для включения шифрования всего предназначенного W.X.Y.Z трафика:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Поместите эти команды в файл (например, /etc/ipsec.conf) и запустите

# setkey -f /etc/ipsec.conf

spdadd указывает setkey(8) добавить правило к базе данных политики безопасности. Остальная часть строки указывает какие пакеты будут соответствовать политике. A.B.C.D/32 и W.X.Y.Z/32 это IP адреса и сетевые маски, определяющие сети или хосты, к которым будет применяться данная политика. В данном случае мы хотим применить их к трафику между этими двумя хостами. Параметр ipencap сообщает ядру, что эта политика должна применяться только к пакетам, инкапсулирующим другие пакеты. Параметр -P out сообщает, что эта политика применяется к исходящим пакетам, и ipsec — то, что пакеты будут зашифрованы.

Оставшаяся часть строки определяет, как эти пакеты будут зашифрованы. Будет использоваться протокол esp, а параметр tunnel показывает, что пакет в дальнейшем будет инкапсулирован в IPsec пакет. Повторное использование A.B.C.D и W.X.Y.Z предназначено для выбора используемых параметров безопасности, и наконец параметр require разрешает шифрование пакетов, попадающих под это правило.

Это правило соответствует только исходящим пакетам. Вам потребуется похожее правило, соответствующее входящим пакетам.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

Обратите внимание, что вместо in используется out и IP адреса переставлены.

Другому шлюзу (с публичным IP адресом W.X.Y.Z) потребуются похожие правила.

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Наконец, вам потребуется добавить правила к брандмауэру для включения прохождения пакетов ESP и IPENCAP в обе стороны. На обеих хостах потребуется добавить следующие правила:

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z

ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D

ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z

ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D

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

Исходящие пакеты теперь будут выглядеть примерно так:



Когда эти пакеты будут получены на удаленном конце VPN соединения, они будут расшифрованы (используя параметры безопасности, о которых договорился racoon). Затем они будут переданы интерфейсу gif, который ''развернет'' второй слой, оставив пакет с внутренними адресами, который сможет попасть во внутреннюю сеть.

Вы можете проверить безопасность тем же ping(8), который использовался ранее. Сначала войдите на шлюз A.B.C.D и запустите:

tcpdump dst host 192.168.2.1

В другой сессии на том же хосте запустите

ping 192.168.2.1

В этот момент вы должны увидеть примерно это:

XXX tcpdump output

Теперь, как видите, tcpdump(1) показывает ESP пакеты. Если вы попытаетесь просмотреть их с параметром -s, то вероятно увидите нечто непонятное, поскольку применяется шифрование.

Поздравляем. Вы только что настроили VPN между двумя удаленными сетями.

Резюме

• Настройте оба ядра с:

options IPSEC

options IPSEC_ESP

• Установите security/ipsec-tools. Отредактируйте ${PREFIX}/etc/racoon/psk.txt на обеих шлюзах, добавив запись для каждого IP адреса удаленного хоста и секретный ключ, который будет известен им обеим. Убедитесь, что режим доступа к файлу 0600.

• Добавьте к /etc/rc.conf на каждом хосте следующие строки:

ipsec_enable="YES"

ipsec_file="/etc/ipsec.conf"

• Создайте /etc/ipsec.conf на каждом хосте с необходимыми строками spdadd. На шлюзе #1 он будет таким:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec

esp/tunnel/A.B.C.D-W.X.Y.Z/require;

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec

esp/tunnel/W.X.Y.Z-A.B.C.D/require;

А на шлюзе #2 таким:

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec

esp/tunnel/W.X.Y.Z-A.B.C.D/require;

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec

esp/tunnel/A.B.C.D-W.X.Y.Z/require;

• Добавьте правила к брандмауэрам обеих хостов для включения IKE, ESP и IPENCAP трафика:

ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp

ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z

ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D

ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z

ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D

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

14.11. OpenSSH


Предоставил Chern Lee.

OpenSSH это набор сетевых инструментов, используемых для защищенного доступа к удаленным компьютерам. Он может быть использован в качестве непосредственной замены rlogin, rsh, rcp и telnet. Кроме того, через SSH могут быть безопасно туннелированы и/или перенаправлены произвольные TCP/IP соединения. OpenSSH шифрует весь трафик, эффективно предотвращая кражу данных, перехват соединения и другие сетевые атаки.

OpenSSH поддерживается проектом OpenBSD, он основан на SSH v1.2.12 со всеми последними исправлениями и обновлениями, совместим с протоколами SSH версий 1 и 2. OpenSSH включен в базовую систему начиная с FreeBSD 4.0.
^

14.11.1. Преимущества использования OpenSSH


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

14.11.2. Включение sshd


В FreeBSD версии 4.X даемон sshd запускается по умолчанию; начиная с версий 5.X FreeBSD он должен быть разрешен в процессе инсталляции. За запуск ответственна следующая строка в файле rc.conf:

sshd_enable="YES"

При следующей загрузке системы будет запущен sshd(8), даемон для OpenSSH. Вы можете также воспользоваться скриптом /etc/rc.d/sshd системы rc(8) для запуска OpenSSH:

/etc/rc.d/sshd start
^

14.11.3. SSH клиент


Утилита ssh(1) работает подобно rlogin(1).

# ssh user@example.com

Host key not found from the list of known hosts.

Are you sure you want to continue connecting (yes/no)? yes

Host 'example.com' added to the list of known hosts.

user@example.com's password: *******

Вход продолжится так же, как если бы сессия была инициирована с использованием rlogin или telnet. SSH использует систему опознавательных ключей для проверки подлинности сервера при подключении клиента. Пользователю предлагается yes только при первом подключении. Дальнейшие попытки входа предваряются проверкой сохраненного ключа сервера. SSH клиент сообщит вам, если сохраненный ключ будет отличаться от только что полученного. Ключи серверов сохраняются в ~/.ssh/known_hosts, или в ~/.ssh/known_hosts2 для SSH v2.

По умолчанию современные серверы OpenSSH настроены на приём только соединений SSH v2. Клиент будет использовать версию 2 там, где это возможно, а затем версию 1. Также, клиент можно заставить использовать конкретную версию при помощи опций -1 и -2 для указания соответствующей версии протокола. Версия 1 поддерживается ради совместимости со старыми серверами.
^

14.11.4. Безопасное копирование


Команда scp(1) работает подобно rcp(1); она копирует файл с удаленного компьютера, но делает это безопасным способом.

# scp user@example.com:/COPYRIGHT COPYRIGHT

user@example.com's password: *******

^ COPYRIGHT 100% |*****************************| 4735 00:00

#

Поскольку в предыдущем примере ключ сервера уже был сохранен, в этом примере он проверяется при использовании scp(1).

Параметры, передаваемые scp(1), похожи на параметры cp(1), с файлом или файлами в качестве первого аргумента и приемником копирования во втором. Поскольку файлы файлы передаются по сети через SSH, один или более аргументов принимают форму user@host:
.

14.11.5. Настройка


Системные файлы настройки для даемона и клиента OpenSSH расположены в каталоге /etc/ssh.

Файл ssh_config используется для настройки клиента, а sshd_config для даемона.

Кроме того, параметры sshd_program (по умолчанию /usr/sbin/sshd), и sshd_flags rc.conf дают дополнительные возможности настройки.

14.11.6. ssh-keygen


Вместо использования паролей, с помощью ssh-keygen(1) можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться:

% ssh-keygen -t dsa

Generating public/private dsa key pair.

Enter file in which to save the key (/home/user/.ssh/id_dsa):

Created directory '/home/user/.ssh'.

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/user/.ssh/id_dsa.

Your public key has been saved in /home/user/.ssh/id_dsa.pub.

The key fingerprint is:

bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

ssh-keygen(1) создаст пару публичного и приватного ключей, используемых для аутентификации. Приватный ключ сохраняется в ~/.ssh/id_dsa или ~/.ssh/id_rsa, а публичный в ~/.ssh/id_dsa.pub или ~/.ssh/id_rsa.pub (для ключей DSA и RSA соответственно). Для включения аутентификации по ключам публичный ключ должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере.

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

Если при генерации ключей был использован пароль, каждый раз для при использовании приватного ключа он будет запрашиваться у пользователя. Для того, чтобы избежать непрерывного набора кодовой фразы, можно использовать утилиту ssh-agent(1), как описано в разделе Разд. 14.11.7 ниже.

Внимание: Параметры и имена файлов могут различаться для разных версий OpenSSH, установленных в системе, для решения проблем обратитесь к странице справочника ssh-keygen(1).
^

14.11.7. Утилиты ssh-agent и ssh-add


Утилиты ssh-agent(1) и ssh-add(1) позволяют сохранять ключи SSH в памяти, чтобы не набирать кодовые фразы при каждом использовании ключа.

Утилита ssh-agent(1) обеспечивает процесс аутентификации загруженными в нее секретными ключами; для этого утилита ssh-agent(1) должна запустить внешний процесс. В самом простом случае это может быть шелл-процесс; в чуть более продвинутом — оконный менеджер.

Для использования ssh-agent(1) совместно с шеллом, ssh-agent(1) должен быть запущен с именем этого шелла в качестве аргумента. После этого в его память при помощи утилиты ssh-add(1) могут быть добавлены необходимые ключи; при этом будут запрошены соответствующие кодовые фразы. Добавленные ключи могут затем использоваться для ssh(1) на машины, на которых установлены соответствующие публичные ключи:

% ssh-agent csh

% ssh-add

Enter passphrase for /home/user/.ssh/id_dsa:

Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)

%

Для того чтобы использовать ssh-agent(1) в X11, вызов ssh-agent(1)должен быть помещен в файл ~/.xinitrc. Это обеспечит поддержкой ssh-agent(1) все программы, запущенные в X11. Файл ~/.xinitrc может выглядеть, например, так:

exec ssh-agent startxfce4

При этом будет запущен ssh-agent(1), который, в свою очередь, вызовет запуск XFCE, при каждом старте X11. После запуска X11, выполните команду ssh-add(1) для добавления ваших SSH-ключей.
^

14.11.8. Туннелирование SSH


OpenSSH поддерживает возможность создания туннеля для пропуска соединения по другому протоколу через защищенную сессию.

Следующая команда указывает ssh(1) создать туннель для telnet:

% ssh -2 -N -f -L 5023:localhost:23 user@foo.example.com

%

Команда ssh используется со следующими параметрами:

-2

  Указывает ssh использовать версию 2 протокола (не используйте этот параметр, если работаете со старыми SSH серверами).

-N

  Означает использование в не-командном режиме, только для туннелирования. Если этот параметр опущен, ssh запустит обычную сессию.

-f

  Указывает ssh запускаться в фоновом режиме.

-L

  Означает локальный туннель в стиле localport:remotehost:remoteport.

user@foo.example.com

  Удаленный сервер SSH.

Туннель SSH создается путем создания прослушивающего сокета на определенном порту localhost. Затем все принятые на локальном хосту/порту соединения переправляются на через SSH на определенный удаленный хост и порт.

В этом примере, порт ^ 5023 на localhost перенаправляется на порт 23 на localhost удаленного компьютера. Поскольку 23 это порт telnet, будет создано защищенное соединение telnet через туннель SSH.

Этот метод можно использовать для любого числа небезопасных протоколов, таких как SMTP, POP3, FTP, и так далее.

Пример 14-1. Использование SSH для создания защищенного туннеля на SMTP

% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com

user@mailserver.example.com's password: *****

% telnet localhost 5025

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

220 mailserver.example.com ESMTP

Этот метод можно использовать вместе с ssh-keygen(1) и дополнительными пользовательскими учётными записями для создания более удобного автоматического SSH туннелирования. Ключи могут быть использованы вместо паролей, и туннели могут запускаться от отдельных пользователей.
^
14.11.8.1. Практические примеры SSH туннелирования
14.11.8.1.1. Защищенный доступ к серверу POP3

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

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com

user@ssh-server.example.com's password: ******

Когда туннель включен и работает, вы можете настроить почтовый клиент для отправки запросов POP3 на localhost, порт 2110. Соединение будет безопасно переправлено через туннель на mail.example.com.
14.11.8.1.2. Прохождение через Драконовский Брандмауэр

Некоторые сетевые администраторы устанавливают на брандмауэрах драконовские правила, фильтруя не только входящие соединения, но и исходящие. Вам может быть разрешен доступ к удаленным компьютерам только по портам 22 и 80, для SSH и просмотра сайтов.

Вам может потребоваться доступ к другому (возможно, не относящемуся к работе) сервису, такому как Ogg Vorbis для прослушивания музыки. Если этот сервер Ogg Vorbis выдает поток не с портов 22 или 80, вы не сможете получить к нему доступ.

Решение состоит в создании SSH соединения с компьютером вне брандмауэра и использование его для туннелирования сервера Ogg Vorbis.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org

user@unfirewalled-system.example.org's password: *******

Клиентскую программу теперь можно настроить на localhost порт 8888, который будет перенаправлен на music.example.com порт 8000, успешно обойдя брандмауэр.
^

14.11.9. Параметр ограничения пользователей AllowUsers


Зачастую хорошие результаты даёт ограничение того, какие именно пользователи и откуда могут регистрироваться в системе. Задание параметра AllowUsers является хорошим способом добиться этого. К примеру, для разрешения регистрации только пользователю root с машины 192.168.1.32, в файле /etc/ssh/sshd_config нужно указать нечто вроде следующего:

AllowUsers root@192.168.1.32

Для разрешения регистрации пользователя admin из любой точки, просто укажите имя пользователя:

AllowUsers admin

Несколько пользователей должны перечислять в одной строке, как здесь:

AllowUsers root@192.168.1.32 admin

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

После внесения изменений в /etc/ssh/sshd_config вы должны указать sshd(8) на повторную загрузку конфигурационных файлов, выполнив следующую команду:

# /etc/rc.d/sshd reload
^

14.11.10. Дополнительная литература


OpenSSH (http://www.openssh.com/)

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

14.12. Списки контроля доступа файловой системы (ACL)


Предоставил Tom Rhodes.

В дополнение к другим расширениям файловой системы, таким как снимки (snapshots), FreeBSD 5.0 и более поздние версии системы предлагают защиту с помощью списков контроля доступа файловой системы (File System Access Control Lists, ACLs).

Списки контроля доступа расширяют стандартную модель прав UNIX высоко совместимым (POSIX.1e) способом. Эта возможность позволяет администратору получить преимущество от использования более интеллектуальной модели безопасности.

Для включения поддержки ACL в файловой системе UFS, следующая строка:

options UFS_ACL

должна быть добавлена в файл настройки ядра. Если параметр не добавлен, при попытке монтирования систем, поддерживающих ACL, появится предупреждающее сообщение. Этот параметр включен в ядро GENERIC. ACL основывается на дополнительных атрибутах, встроенных в файловую систему. Дополнительные атрибуты поддерживаются по умолчанию следующим поколением файловых систем UNIX, UFS2.

Замечание: Для включения дополнительных атрибутов в UFS1 требуется больше усилий по сравнению с UFS2. Производительность дополнительных атрибутов в UFS2 также существенно выше. По этим причинам для работы с списками контроля доступа предпочтительно использование UFS2

ACL включаются во время монтирования флагом acls, который добавляется к /etc/fstab. Этот флаг также можно сделать постоянным с помощью tunefs(8), изменив флаг ACL в заголовке файловой системы. Вообще говоря, использование флага в суперблоке предпочтительно по нескольким причинам:

• Постоянный ACL флаг не может быть изменен путем перемонтирования системы (mount(8) -u), а только через umount(8) и mount(8). Это означает, что ACL нельзя включить на корневой файловой системе после загрузки. Это также означает, что вы не можете изменить флаг на используемой файловой системе.

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

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

Файловые системы с включенными ACLs показывают знак + при просмотре прав на файлы. Например:

drwx------ 2 robert robert 512 Dec 27 11:54 private

drwxrwx---+ 2 robert robert 512 Dec 23 10:57 directory1

drwxrwx---+ 2 robert robert 512 Dec 22 10:20 directory2

drwxrwx---+ 2 robert robert 512 Dec 27 11:57 directory3

drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html

Здесь мы видим, что каталоги directory1, directory2, и directory3 используют преимущества ACL. Каталог public_html их не использует.
^

14.12.1. Использование ACL


ACL файловой системы можно просмотреть с помощью утилиты getfacl(1). Например, для просмотра настроек ACL файла test, может использоваться команда:

% getfacl test

#file:test

#owner:1001

#group:1001

user::rw-

group::r--

other::r--

Для изменения ACL этого файла, вызовите утилиту setfacl(1). Выполните:

% setfacl -k test

Параметр -k удалит все установленные на данный момент ACL из файла или файловой системы. Более предпочтительный метод это использование параметра -b, который оставит необходимые для работы ACL поля.

% setfacl -m u:trhodes:rwx,group:web:r--,o::--- test

В вышеприведенной команде параметр -m использован для изменения записей ACL по умолчанию. Поскольку предустановленных записей не было (они были удалены предыдущей командой), эта команда восстановит параметры по умолчанию и задаст приведенные параметры. Имейте ввиду, при добавлении пользователя или группы, которых нет в системе, на stdout будет выведена ошибка Invalid argument.
^

14.13. Мониторинг вопросов безопасности в ПО сторонних разработчиков


Текст предоставил Том Родес.

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

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

Порт security/portaudit обращается к базе данных, обновляемой и поддерживаемой Группой информационной безопасности FreeBSD и разработчиками портов, для получения информации об известных проблемах с защитой.

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

# cd /usr/ports/security/portaudit && make install clean

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

После установки администратор может обновить базу данных и посмотреть список известных уязвимостей в установленных пакетах при помощи команды

# portaudit -Fda

Замечание: База данных будет автоматически обновлена при запуске periodic(8); таким образом, предыдущая команду можно полностью опустить. Она требуется только для следующих примеров.

Для аудита утилит сторонних разработчиков, установленных как часть Коллекции Портов, администратору достаточно запускать только следующую команду:

# portaudit -a

Утилита portaudit выдаст примерно следующее:

Affected package: cups-base-1.1.22.0_1

Type of problem: cups-base -- HPGL buffer overflow vulnerability.

Reference:


1 problem(s) in your installed packages found.


You are advised to update or deinstall the affected package(s) immediately.

Перейдя в Web-браузере по показанному URL, администратор может получить более подробную информацию о показанной уязвимости. В неё войдёт перечисление версий, затронутых соответствующей версией порта FreeBSD, а также другие Web-сайты, которые могут содержать бюллетени безопасности.

Если описывать вкратце, то Portaudit является мощной и, при использовании вместе с портом Portupgrade, чрезвычайно полезной утилитой.
^

14.14. Сообщения безопасности FreeBSD


Предоставил Tom Rhodes.

Как многие и высококачественные операционные системы, FreeBSD публикует ''Сообщения безопасности'' (''Security Advisories''). Эти сообщения обычно отправляются по почте в списки рассылки, посвященные безопасности и публикуются в списке проблем только после выхода исправлений к соответствующим релизам. В этом разделе разъясняется, что такое сообщения безопасности, как их читать и какие меры принимать для исправления системы.
^

14.14.1. Как выглядит сообщение?


Сообщение безопасности FreeBSD выглядит подобно сообщению ниже, взятому из списка рассылки freebsd-security-notifications (http://lists.FreeBSD.org/mailman/listinfo/freebsd-security-notifications).

=============================================================================

FreeBSD-SA-XX:XX.UTIL Security Advisory

The FreeBSD Project


Topic: denial of service due to some problem


Category: core

Module: sys

Announced: 2003-09-23

Credits: Person@EMAIL-ADDRESS

Affects: All releases of FreeBSD

FreeBSD 4-STABLE prior to the correction date

Corrected: 2003-09-23 16:42:59 UTC (RELENG_4, 4.9-PRERELEASE)

2003-09-23 20:08:42 UTC (RELENG_5_1, 5.1-RELEASE-p6)

2003-09-23 20:07:06 UTC (RELENG_5_0, 5.0-RELEASE-p15)

2003-09-23 16:44:58 UTC (RELENG_4_8, 4.8-RELEASE-p8)

2003-09-23 16:47:34 UTC (RELENG_4_7, 4.7-RELEASE-p18)

2003-09-23 16:49:46 UTC (RELENG_4_6, 4.6-RELEASE-p21)

2003-09-23 16:51:24 UTC (RELENG_4_5, 4.5-RELEASE-p33)

2003-09-23 16:52:45 UTC (RELENG_4_4, 4.4-RELEASE-p43)

2003-09-23 16:54:39 UTC (RELENG_4_3, 4.3-RELEASE-p39)

CVE Name: CVE-XXXX-XXXX


For general information regarding FreeBSD Security Advisories,

including descriptions of the fields above, security branches, and the

following sections, please visit

http://www.FreeBSD.org/security/.


I. Background


II. Problem Description(10)


III. Impact(11)


IV. Workaround(12)


V. Solution(13)


VI. Correction details(14)


VII. References(15)

 Поле Topic показывает в чем именно заключается проблема. Это обычно введение в сообщение безопасности, упоминающее утилиту, в которой возникла ошибка.

 Поле Category относится к затронутой части системы и может быть выбрана из core, contrib, или ports. Категория core означает, что уязвимость затрагивает основной компонент операционной системы FreeBSD. Категория contrib означает, что уязвимость затрагивает программы, предоставленные проекту FreeBSD, например sendmail. Наконец, категория ports означает, что уязвимость затрагивает программное обеспечение, доступное из Коллекции Портов.

 Поле Module указывает на местоположение компонента, например sys. В этом примере мы видим, что затронут модуль sys, следовательно, эта уязвимость относится к компоненту, используемому в ядре.

 Поле Announced отражает дату публикации сообщения безопасности, или его анонсирования. Это означает, что команда обеспечения безопасности убедилась, что проблема существует и что патч помещён в хранилище исходных текстов FreeBSD.

 Поле Credits упоминает частное лицо или организацию, обнаружившую уязвимость и сообщившую о ней.

 Поле Affects дает информацию о релизах FreeBSD, к которым относится данная уязвимость. Для базовой системы, просмотр вывода команды ident для файлов, затронутых уязвимостью, поможет определить ревизию. Номер версии портов приведен после имени порта в каталоге /var/db/pkg. Если система не синхронизируется с CVS-хранилищем FreeBSD и не пересобирается ежедневно, высок шанс, что она затронута уязвимостью.

 Поле Corrected показывает дату, время, смещение во времени и релиз, в котором исправлена ошибка.

 Зарезервировано для идентификации уязвимости в общей базе данных CVD (Common Vulnerabilities Database).

 Поле Background дает информацию именно о той утилите, для которой выпущено сообщение. Как правило информация о том, зачем утилита присутствует в FreeBSD, для чего она используется, и немного информации о том, как появилась эта утилита.

(10) Поле Problem Description дает более глубокие разъяснения возникшей проблемы. Оно может включать информацию об ошибочном коде, или даже о том, как утилита может быть использована для создания бреши в системе безопасности.

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

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

(13) Поле Solution предлагает инструкции по исправлению затронутой системы. Это пошаговое руководство, протестированный метод восстановления безопасности системы.

(14) Поле Correction Details показывает ветвь CVS (имя релиза с точками, замененными на символы подчеркивания). Здесь также показан номер ревизии каждого файла из каждой ветви.

(15) Поле References обычно упоминает другие источники информации. Это могут быть Web-страницы, книги, списки рассылки и группы новостей.
^

14.15. Учёт используемых ресурсов


Текст предоставил Том Родес.

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

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

14.15.1. Активация и использование учёта ресурсов


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

# touch /var/account/acct


# accton /var/account/acct


# echo 'accounting_enable="YES"' >> /etc/rc.conf

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

Для просмотра информации о запущенных командах, необходимо воспользоваться утилитой lastcomm(1). Команду lastcomm можно использовать, например, для выдачи списка директив, выданных пользователями определённого терминала ttys(5):

# lastcomm ls trhodes ttyp1

Эта команда выдаст все зафиксированные использования команды ls пользователем trhodes на терминале ttyp1.

Существует многие другие полезные параметры, которые описаны на соответствующих справочных страницах lastcomm(1), acct(5) и sa(8).

Примечания

1. В FreeBSD стандартный пароль может быть до 128 символов длиной.
^

Глава 15. Принудительный контроль доступа (MAC)


Написал Tom Rhodes. Перевод на русский язык: Денис Пеплин.

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


FreeBSD 5.X представляет новые расширения системы безопасности от проекта TrustedBSD, основанные на документах POSIX.1e. Два из наиболее важных нововведений в механизмах безопасности это списки контроля доступа файловой системы (Access Control Lists, ACLs) и принудительный контроль доступа Mandatory Access Control, MAC). Инфраструктура позволяет загружать новые модули контроля доступа, реализуя новые политики безопасности. Некоторые из них предоставляют защиту ключевых подсистем, защищая определенный сервис, в то время как другие предоставляют исчерпывающую систему безопасности с метками на всех субъектах и объектах. Контроль называется принудительным, поскольку применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа (Discretionary Access Control, DAC, стандартные файловые и System V IPC права в FreeBSD).

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

После прочтения этой главы вы узнаете:

• Какие модули MAC включены в настоящее время в FreeBSD, какие политики с ними связаны.

• Что способны реализовать политики MAC, различие между политиками с метками (label) и без меток.

• Как эффективно настроить систему для использования инфраструктуры MAC.

• Как настроить различные политики, используемые модулями MAC.

• Как реализовать более защищенную среду, используя инфраструктуру MAC и приведенные примеры.

• Как протестировать настройку MAC, чтобы убедиться, что инфраструктура была реализована правильно.

Перед прочтением этой главы вам потребуется:

• Понимание основ UNIX и FreeBSD (Гл. 3).

• Ознакомиться с основами настройки/компилирования ядра (Гл. 8).

• Иметь некоторые понятия о безопасности и как она относится к FreeBSD (Гл. 14).

Внимание: Неправильное использование информации этой главы может вызвать потерю доступа к системе, проблемы у пользователей, или невозможность запуска XFree86. Что более важно, MAC не должен восприниматься как полная защита системы. Инфраструктура MAC лишь усиливает имеющуюся систему безопасности: без применения методов защиты и регулярных проверок, система никогда не станет полностью защищенной.

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

15.1.1. Что не будет затронуто


В этой главе охвачен широкий спектр вопросов безопасности, относящихся к инфраструктуре MAC. однако разработка политик MAC не будет затронута. Несколько модулей, включенных в инфраструктуру MAC, имеют особые характеристики, которые предназначены для тестирования и разработки новых модулей. Это относится к модулям/политикам mac_test(4), mac_stub(4) и mac_none(4). За дальнейшей информацией по этим модулям и различным предоставляемым ими механизмам, обратитесь к соответствующим страницам справочника.
^

15.2. Ключевые термины этой главы


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

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

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

метка (label): Метка является инструментом безопасности, она может быть применена к файлам, каталогам и другим сущностям системы. Ее можно представить как штамп конфиденциальности; метка, помещенная на файл, описывает уровень секретности данного файла и разрешит доступ только файлам, пользователям, ресурсам и т.д. с теми же или меньшими установками безопасности. Некоторые из политик могут обрабатывать метки различными способами; это будет обсуждаться в разделе политик ниже.

multilabel (множественные метки): свойство multilabel это параметр файловой системы, который может быть установлен в однопользовательском режиме с помощью утилиты tunefs(8), во время загрузки через файл fstab(5), или при создании новой файловой системы. Этот параметр позволяет администратору помещать различные метки MAC на различные объекты. разрешает помещение множественных MAC меток на файлы и каталоги файловой системы. Этот параметр применим только к политикам с метками.

объект (object): Объект или системный объект это сущность, через которую информация проходит к субъекту. Это могут быть каталоги, файлы, поля, экраны, клавиатуры, память, магнитные накопители, принтеры или любые другие устройства хранения/перемещения данных. В сущности это контейнер данных или ресурс системы; доступ к объекту фактически означает доступ к данным.

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

чувствительность (sensitivity): Обычно используется при обсуждении MLS. Уровень чувствительности это термин, используемый для описания того, насколько важны или секретны данные. Увеличение уровня чувствительности означает важность данных.

одиночная метка (single label): означает, что вся файловая система использует одну метку для определения доступа всего потока данных. Когда файловая система использует эту установку, что происходит всегда, если не установлен параметр multilabel, ко всем файлам будет применяться одна и та же установка метки.

субъект (subject): субъект это любая активная сущность, вызывающая перемещение информации между объектами; т.е. пользователь, пользовательский обработчик, системный процесс и т.д. В FreeBSD это почти всегда поток, работающий в процессе или представляющий пользователя.
^

15.3. Описание MAC


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

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

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

Право выбора правильных политик безопасности принадлежит только системному администратору. В некоторых случаях может потребоваться ограничение доступа через сеть; для этого могут пригодиться mac_portacl(4), mac_ifoff(4) и даже mac_biba(4). В других случаях может быть необходима строгая конфиденциальность объектов в файловой системе. Для этого существуют политики mac_bsdextended(4) и mac_mls(4).

Выбор политики может быть сделан на основе конфигурации сети. Возможно только определенным пользователям можно разрешить доступ через ssh(1) к сети или интернет. В таких ситуациях подойдет политика mac_portacl(4). Но что необходимо сделать для файловых систем? Должен ли доступ к определенным каталогам быть запрещен для других групп или определенных пользователей? Или мы должны ограничить доступ пользователей или утилит к определенным файлам путем классификации определенных объектов?

В случае файловой системы, доступ может считаться конфиденциальным для отдельных пользователей, но не для всех. Например, большая команда разработчиков может быть разбита на небольшие группы. Разработчикам проекта A может быть не разрешен доступ к объектам, написанным разработчиками из проекта B. Хотя им может понадобиться доступ к объектам, созданным разработчиками проекта C; это реально встречающаяся ситуация. С помощью различных политик, предоставляемых инфраструктурой MAC, пользователи могут быть разделены на эти три группы и затем получить доступ к соответствующим областям без опасности утечки информации.

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

Стандартное ядро FreeBSD не включает параметр MAC; необходимо добавить следующий параметр ядра перед тем, как пробовать какие-либо из примеров или применять информацию этой главы:

options MAC

Затем необходимо пересобрать и переустановить ядро.

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

15.4. Метки MAC


Метка MAC это атрибут безопасности, который может быть применен к субъектам и объектам всей системы.

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

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

Например, установка метки в biba/low на файле присвоит этому файлу метку, обрабатываемую политикой Biba со значением ''low''.

Несколько политик, поддерживающих метки в FreeBSD, предоставляют три определенные предустановленные метки. Это низкая, высокая и равная метки. Хотя они устанавливают контроль различными способами для каждой политики, вы можете быть уверены, что низкая метка задаст минимальные установки, равная метка означает отмену или недействительность, а высокая метка установит максимально возможные настройки в политиках Biba и MLS.

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

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

В большинстве случаев системный администратор использует только одну метку на всю файловую систему.

^ Постойте, но это же похоже на DAC! Я думал, что MAC дает контроль только администратору. Это утверждение все еще верно, только root контролирует и настраивает политики, так что пользователи помещаются в соответствующие категории/уровни доступа. Многие политики могут ограничить также и пользователя root. Базовый контроль над объектами затем передается группе, но пользователь root может отменить или изменить эти настройки в любое время. Данная иерархическая модель соответствует таким политикам как Biba и MLS.
^

15.4.1. Настройка меток


Практически все действия по настройке политики с метками могут быть выполнены с использованием утилит базовой системы. Эти команды обеспечивают простой интерфейс для настройки объектов или субъектов, или для изменения и проверки настроек.

Все настройки могут быть выполнены с использованием утилит setfmac(8) и setpmac(8). Команда setfmac используется для установки меток MAC на системные объекты, а команда setpmac используется для установки меток на системные субъекты. Выполните:

# setfmac biba/high test

Если не произойдет ошибок, будет возвращено приглашение командной строки, как и после команд chmod(1) и chown(8). В некоторых случаях может появиться ошибка Permission denied, и она обычно появляется при установке или изменении метки на объект с ограничениями. 1 Системный администратор для обхода этой проблемы может использовать следующие команды:

# setfmac biba/high test

Permission denied

# setpmac biba/low setfmac biba/high test

# getfmac test

test: biba/high

Как видно из примера выше, команда setpmac может быть использована для изменения установок политики путем присвоения иной метки вызывающему процессу. Утилита getpmac обычно используется с существующим на данный момент процессом, таким как sendmail, хотя она принимает PID вместо команды, ее действие аналогично. Если пользователи попытаются манипулировать файлами, к которым у них нет доступа в соответствии с правилами загруженных политик, функцией mac_set_link будет выдано сообщение об ошибке Operation not permitted.
^
15.4.1.1. Пользователи и установки меток

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

Пример записи, содержащей все политики, приведенные ниже:

default:\

:copyright=/etc/COPYRIGHT:\

:welcome=/etc/motd:\

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\

:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\

:manpath=/usr/share/man /usr/local/man:\

:nologin=/usr/sbin/nologin:\

:cputime=1h30m:\

:datasize=8M:\

:vmemoryuse=100M:\

:stacksize=2M:\

:memorylocked=4M:\

:memoryuse=8M:\

:filesize=8M:\

:coredumpsize=8M:\

:openfiles=24:\

:maxproc=32:\

:priority=0:\

:requirehome:\

:passwordtime=91d:\

:umask=022:\

:ignoretime@:\

:label=partition/13,mls/5,biba/10(5-15),lomac10[2]:

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

Замечание: Пользователи могут изменить свою метку после входа; однако политика накладывает ограничение на это изменение. В примере выше политике Biba указано, что минимальная целостность процесса 5, максимальная 15, а эффективная целостность по умолчанию 10. Процесс будет работать на уровне 10, пока метка не будет изменена, например если пользователь использует команду setpmac, которую Biba ограничит диапазоном, установленным при входе.

Во всех случаях после изменения login.conf, база данных ''login class capability'' должна быть пересобрана с использованием команды cap_mkdb и это будет отражено в каждом последующем примере главы.

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

В будущих версиях FreeBSD появится новый способ связывания пользователей с метками; однако, он будет доступен только через некоторое время после выхода FreeBSD 5.3.
^
15.4.1.2. Сетевые интерфейсы и установка меток

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

Для установки MAC меток на сетевых интерфейсах параметр maclabel может быть передан ifconfig. Например:

# ifconfig bge0 maclabel biba/equal

установит MAC метку biba/equal на интерфейс bge(4). При использовании метки, подобной biba/high(low-high) вся метка должна быть взята в кавычки, иначе будет выдано сообщение об ошибке.

Каждая политика, использующая метки, снабжена переменной sysctl, которая может быть использована для отключения MAC меток на сетевых интерфейсах. Установка метки в equal будет иметь подобный эффект. Просмотрите вывод команды sysctl, страницы справочника для политик, или дальнейшую информацию из этой главы по этим переменным.
^

15.4.2. Одиночные или множественные метки?


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

singlelabel (одиночная метка) разрешает использование только одной метки, например biba/high, для каждого объекта или субъекта. Ее преимущество в меньшей нагрузке на системного администратора, а недостаток в малой гибкости политик, поддерживающих метки. Многие администраторы в своих политиках безопасности могут предпочесть использование параметра multilabel.

С параметром multilabel каждый субъект или объект может иметь собственную метку MAC, в то время как со стандартным параметром singlelabel возможна только одна метка на весь раздел. Параметры multilabel и singlelabel требуются только для политик, реализующих метки, включая Biba, Lomac, MLS и SEBSD.

Во многих случаях multilabel может вообще не потребоваться. Предположим следующую ситуацию и модель безопасности:

• FreeBSD веб-сервер, использующий инфраструктуру MAC и набор различных политик.

• Этому компьютеру потребуется лишь одна метка, biba/high, для всей системы. Файловой системе не нужен параметр multilabel, поскольку по умолчанию работает одиночная метка.

• Но поскольку этот компьютер будет веб сервером, процесс веб сервера должен быть запущен с biba/low для предотвращения записи. Политика Biba и то, как она работает, будет обсуждаться позже, поэтому предыдущий комментарий сложно интерпретировать; просто продолжайте чтение. Сервер может использовать дисковый раздел с установленной меткой biba/low для большинства, если не для всех своих операций. В этом примере отсутствуют многие детали, такие как ограничения на данные, конфигурация системы и установки пользователей; однако, это лишь предварительный пример.

Если используется любая из политик, не поддерживающих метки, параметр multilabel не требуется. Сюда включаются политики seeotheruids, portacl и partition.

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

Следующая команда установит параметр multilabel на файловых системах. Это может быть сделано только в однопользовательском режиме:

# tunefs -l enable /

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

Замечание: Некоторые пользователи сталкиваются с проблемами при установке флага multilabel на корневой раздел. В данном случае обратитесь к Разд. 15.16.
^

15.4.3. Настройка MAC переменными sysctl


Независимо от загрузки модулей, существует несколько частей MAC, которые могут быть настроены с использованием интерфейса sysctl. Эти переменные описаны ниже и во всех случаях значение 1 означает включение, а 0 — отключение:

• security.mac.enforce_fs по умолчанию установлена в 1 и включает политики MAC на файловых системах.

• security.mac.enforce_kld по умолчанию 1 и включает линкование политик MAC в ядре (см. kld(4)).

• security.mac.enforce_network по умолчанию 1 и включает сетевые политики MAC.

• security.mac.enforce_pipe по умолчанию 1 и включает политики MAC для каналов (pipe).

• security.mac.enforce_process по умолчанию 1 и включает политики MAC для процессов, использующих средства межпроцессного взаимодействия.

• security.mac.enforce_socket по умолчанию 1 и включает политики MAC на сокетах (см. страницу справочника socket(2)).

• security.mac.enforce_system по умолчанию 1 и включает политики MAC для действий системы, таких как учет (accounting) и перезагрузка.

• security.mac.enforce_vm по умолчанию 1 и включает политики MAC для системы виртуальной памяти.

Замечание: Каждая политика MAC поддерживает переменные sysctl. Они обычно попадают в дерево security.mac.
. Для просмотра всех переменных MAC, используйте следующую команду:

# sysctl -da | grep mac

Это должно быть интерпретировано так, что все основные политики MAC включены по умолчанию. Если модули встроены в ядро, система будет заблокирована, и скорее всего не сможет связаться с локальной сетью или с интернет, и т.д. Поэтому встраивание модулей в ядро не рекомендуется. Не потому, что это ограничит возможность отключения командой sysctl, а потому, что включение политик в виде модулей позволит администратору переключать политики системы без необходимости пересборки и переустановки новой системы.
^

15.5. Настройка модулей


Каждый модуль, включенный в инфраструктуру MAC, может быть или встроен в ядро, как упоминалось выше, или загружен в виде модуля ядра. Рекомендуется добавление имени модуля в файл /boot/loader.conf, этот модуль будет активирован в самом начале загрузки.

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

Конфигурация с одной меткой не допускает применение нескольких меток в системе, поэтому параметр tunefs называется multilabel.
^

15.5.1. Модуль MAC seeotheruids


Имя модуля: mac_seeotheruids.ko

Строка в конфигурации ядра: options MAC_SEEOTHERUIDS

Параметр загрузки: mac_seeotheruids_load="YES"

Модуль mac_seeotheruids(4) копирует и расширяет переменные sysctl security.bsd.see_other_uids и security.bsd.see_other_gids. Он не требует установки меток и может прозрачно работать с другими модулями.

После загрузки модуля, для управления им могут быть использованы следующие переменные sysctl:

• security.mac.seeotheruids.enabled включит модуль с настройками по умолчанию. Эти настройки запрещают пользователям просмотр процессов и сокетов, принадлежащих другим пользователям.

• security.mac.seeotheruids.specificgid_enabled позволит исключить определенные группы из этой политики. Для исключения определенной группы, используйте переменную sysctl security.mac.seeotheruids.specificgid=XXX. В примере выше необходимо заменить XXX на числовой ID группы.

• security.mac.seeotheruids.primarygroup_enabled используется для исключения определенной основной группы из этой политики. При использовании этой переменной security.mac.seeotheruids.specificgid_enabled может быть не установлена.

Необходимо отметить, что пользователь root не является исключением из этой политики. Это одно из самых существенных различий между MAC версией и обычными переменными, существующими по умолчанию: security.bsd.seeotheruids.
^

15.6. Модуль MAC bsdextended


Имя модуля: mac_bsdextended.ko

Строка конфигурации ядра: options MAC_BSDEXTENDED

Параметр загрузки: mac_bsdextended_load="YES"

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

Политика может быть создана с помощью утилиты, ugidfw(8), синтаксис которой похож на синтаксис ipfw(8). Другие инструменты могут быть написаны с использованием функций библиотеки libugidfw(3).

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

15.6.1. Примеры


После загрузки модуля mac_bsdextended(4) для просмотра текущей настройки правил может быть использована следующая команда:

# ugidfw list

0 slots, 0 rules

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

# ugidfw add subject not uid root new object not uid root mode n

Замечание: В релизах FreeBSD до 5.3, параметр add не существует. Вместо него необходимо использовать set. Пример дан ниже.

Это очень плохая идея, поскольку такое правило запретит пользователям использовать даже самые простые команды, такие как ls. Более патриотический список правил может быть таким:

# ugidfw set 2 subject uid user1 object uid user2 mode n

# ugidfw set 3 subject uid user1 object gid user2 mode n

Эти команды запретят весь и любой доступ пользователя user1, включая просмотр подкаталогов, к домашнему каталогу пользователя user2.

Вместо user1 может быть задано not uid user2. Это включит те ограничения, о которых говорилось выше, для всех пользователей кроме одного.

Замечание: На пользователя root эти изменения не повлияют.

Материал выше должен дать общую идею как модуль mac_bsdextended(4) может быть использован в качестве средства защиты файловой системы. За дальнейшей информацией обращайтесь к страницам справочника mac_bsdextended(4) и ugidfw(8).
^

15.7. Модуль MAC ifoff


Имя модуля: mac_ifoff.ko

Строка конфигурации ядра: options MAC_IFOFF

Параметр загрузки: mac_ifoff_load="YES"

Модуль mac_ifoff(4) существует только для отключения сетевых интерфейсов в работающей системе и удержания их от отправки пакетов во время начальной загрузки. Это не требует установления в системе каких-либо меток, нет и зависимости от других модулей MAC.

Большая часть управления может быть выполнена через переменные sysctl.

• security.mac.ifoff.lo_enabled включает/выключает весь трафик на loopback (lo(4)) интерфейсе.

• security.mac.ifoff.bpfrecv_enabled включает/выключает весь трафик на интерфейсе Berkeley Packet Filter (bpf(4)).

• security.mac.ifoff.other_enabled включает/выключает весь трафик на всех других интерфейсах.

Одно из наиболее частых использований mac_ifoff(4) это сетевой мониторинг в среде, где сетевой трафик не должен быть разрешен во время загрузки. Другое предлагаемое применение это написание скрипта, использующего security/aide для автоматического блокирования сетевого трафика, если будут обнаружены новые или измененные файлы в защищаемых каталогах.
^

15.8. Модуль MAC portacl


Имя модуля: mac_portacl.ko

Строка конфигурации ядра: MAC_PORTACL

Параметр загрузки: mac_portacl_load="YES"

Модуль mac_portacl(4) используется для ограничения привязки (binding) к локальным портам TCP и UDP, используя различные переменные sysctl. По сути mac_portacl(4) делает возможной привязку к привилегированным портам, т.е. к портам с номерами меньше 1024 для не-root пользователей.

После загрузки этот модуль включит политику MAC на всех сокетах. Доступны следующие переменные sysctl:

• security.mac.portacl.enabled включает/отключает политику целиком. 2

• security.mac.portacl.port_high установит наибольший номер порта, для которого mac_portacl(4) включает защиту.

• security.mac.portacl.suser_exempt, если установлена в ненулевое значение, исключает пользователя root из этой политики.

• security.mac.portacl.rules задает действующую политику mac_portacl: см. ниже.

Действующая политика mac_portacl, указанная в security.mac.portacl.rules, это текстовая строка в форме rule[,rule,...] с таким количеством правил, которое требуется. Каждое правило задается в формате: idtype:id:protocol:port. Параметр idtype может принимать значения uid или gid и используется для интерпретации параметра id, в качестве id пользователя или группы соответственно. Параметр protocol используется для определения применимости этого правила к протоколу TCP или UDP, он может принимать значения tcp или udp. Последний параметр, port, задает номер порта, к которому разрешается привязка указанного пользователя или группы.

Замечание: Поскольку набор правил интерпретируется непосредственно ядром, для ID пользователя, группы и номера порта могут быть использованы только числовые значения. Т.е. имена пользователей, групп и сервисов портов не могут быть использованы.

По умолчанию в UNIX-подобных системах порты с номерами менее чем 1024 могут быть использованы только привилегированными процессами, т.е. теми, что запущены от root. С mac_portacl(4) для разрешения привязки непривилегированных процессов к портам с номерами ниже 1024 эти стандартные ограничения UNIX должны быть отменены. Это может быть выполнено путем установки переменных sysctl(8) net.inet.ip.portrange.reservedlow и net.inet.ip.portrange.reservedhigh в ноль.

Обратитесь к примерам ниже или к странице справочника mac_portacl(4) за дальнейшей информацией.

15.8.1. Примеры


Следующие примеры должны осветить обсуждение выше чуть лучше:

# sysctl security.mac.portacl.port_high=1023

# sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0

Сначала мы настраиваем mac_portacl(4) для работы со стандартными привилегированными портами и отмены обычных ограничений UNIX на привязку.

# sysctl security.mac.portacl.suser_exempt=1

Пользователь root должен быть исключен из этой политики, для этого переменная security.mac.portacl.suser_exempt установлена в ненулевое значение. Модуль mac_portacl(4) теперь настроен на то поведение UNIX-подобных систем по умолчанию.

# sysctl security.mac.portacl.rules=uid:80:tcp:80

Разрешает пользователю с UID 80 (обычно это пользователь www) привязку к порту 80. Теперь пользователь www сможет запустить веб сервер даже без привилегии root.

# sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995

Разрешит пользователю с UID 1001 привязку к TCP портам 110 (''pop3'') и 995 (''pop3s''). Это позволит данному пользователю запустить сервер, принимающий соединения на портах 110 и 995.
^

15.9. Политики MAC, использующие метки


В следующих нескольких разделах будут обсуждаться политики MAC, использующие метки.

С этого момента обсуждение будет сфокусировано на возможностях mac_biba(4), mac_lomac(4), mac_partition(4), и mac_mls(4).

Замечание: Это лишь примерные настройки, они не должны использоваться непосредственно в реальных задачах. Цель изложения в том, чтобы документировать и показать синтаксис, а также примеры реализации и тестирования.

Для правильной работы этих политик необходимо выполнить некоторые приготовления.
^

15.9.1. Приготовления к использованию политик с метками


В файл login.conf необходимо внести следующие изменения:

• Должен быть добавлен класс insecure, или другой подобный класс. Наличие класса insecure не обязательно, он приводится здесь в качестве примера; другие конфигурации могут использовать другое имя класса.

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

insecure:\

:copyright=/etc/COPYRIGHT:\

:welcome=/etc/motd:\

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\

:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\

:manpath=/usr/share/man /usr/local/man:\

:nologin=/usr/sbin/nologin:\

:cputime=1h30m:\

:datasize=8M:\

:vmemoryuse=100M:\

:stacksize=2M:\

:memorylocked=4M:\

:memoryuse=8M:\

:filesize=8M:\

:coredumpsize=8M:\

:openfiles=24:\

:maxproc=32:\

:priority=0:\

:requirehome:\

:passwordtime=91d:\

:umask=022:\

:ignoretime@:\

:label=partition/13,mls/5,biba/low:

Перед тем, как переключать пользователей на новый класс, необходимо запустить команду cap_mkdb(1) на login.conf(5).

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

• Убедитесь, что все разделы, на которых будут установлены метки MAC, поддерживают параметр multilabel. Нам необходимо сделать это, поскольку многие из примеров здесь содержат различные метки в целях тестирования. Просмотрите вывод команды mount в качестве необходимой предосторожности.

• Переключите всех пользователей, которые будут использовать новые механизмы безопасности, на этот класс. Информация по этой процедуре находится в pw(8) или vipw(8).
^

15.10. Модуль MAC partition


Имя модуля: mac_partition.ko

Строка настройки ядра: options MAC_PARTITION

Параметр загрузки: mac_partition_load="YES"

Политика mac_partition(4) распределяет процессы по ''разделам'' на основе их MAC меток. Это может быть представлено как особый тип jail(8), хотя такое сравнение едва ли подходит.

Этот модуль должен быть добавлен в loader.conf(5), чтобы политика была загружена и включена при загрузке системы.

Большая часть настройки этой политики выполняется с помощью утилиты setpmac(8), которая будет описана ниже. Для данной политики имеется также следующая переменная sysctl:

• security.mac.partition.enabled включит MAC разделение процессов.

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

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

# setpmac partition/13 top

Команда top будет добавлена к метке, установленной для пользователей класса insecure. Обратите внимание, что все процессы, порожденные пользователями класса insecure, останутся с меткой partition/13.

15.10.1. Примеры


Следующая команда покажет вашу метку раздела и список процессов:

# ps Zax

Следующей командой можно просмотреть метку раздела процессов других пользователей и их запущенные процессы:

# ps -ZU trhodes

Замечание: Пользователи могут могут увидеть процессы root, если не загружена политика mac_seeotheruids(4).

Действительно ''продвинутая'' реализация должна отключать все сервисы через /etc/rc.conf и запускать их через скрипт, который установит правильный набор меток.

Замечание: Следующие политики поддерживают целочисленные установки вместо трех меток по умолчанию. Эти опции, включая их ограничения, описываются более подробно в страницах справочника модулей.
^

15.11. Модуль многоуровневой безопасности MAC (MLS)


Имя модуля: mac_mls.ko

Строка конфигурации ядра: options MAC_MLS

Параметр загрузки: mac_mls_load="YES"

Политика mac_mls(4) контролирует взаимодействие субъектов и объектов системы путем применения строгой политики к потоку информации.

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

Эти метки mls/low, mls/equal и mls/high. Поскольку эти метки подробно описываются в справочнике, здесь мы дадим только краткое описание:

• Метка mls/low содержит минимальную настройку, что позволяет доминирование над ней всех других объектов. Все, что помечено с mls/low, находится на низком уровне доступа и доступ к более высоким уровням будет запрещен. Кроме того, эта метка предотвратит запись или передачу информации объектам с более высоким уровнем доступа.

• Метка mls/equal должна быть помещена на объекты, являющиеся исключением из политики.

• Метка mls/high это наибольший возможный уровень доступа. Объекты с этой меткой будут доминировать над всеми другими объектами системы; однако, утечка информации от них к объектам более низкого класса невозможна.

MLS представляет собой:

• Иерархические уровни безопасности с набором не иерархических категорий;

• Фиксированные правила: нет чтения сверху, нет записи вниз (субъект может иметь доступ на чтение объектов собственного уровня или ниже, но не выше. Аналогично, субъект может иметь доступ на запись в объекты своего уровня или выше, но не наоборот.);

• Секретность (предотвращение неавторизованного раскрытия данных);

• Основа для разработки систем, одновременно работающих с данными на нескольких уровнях секретности (без утечки информации).

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

• security.mac.mls.enabled используется для включения/отключения политики MLS.

• security.mac.mls.ptys_equal пометит все устройства pty(4) как mls/equal во время создания.

• security.mac.mls.revocation_enabled используется для запрета доступа к объектам после того, как их метка изменится в меньшую сторону.

• security.mac.mls.max_compartments используется для установки максимального количества уровней отделов на объекты; обычно это максимальное количество отделов, разрешенных в системе.

Для управления метками MLS существует команда setfmac(8). Для присвоения метки объекту, выполните следующую команду:

# setfmac mls/5 test

Для получения метки MLS файла test, выполните следующую команду:

# getfmac test

Выше представлен краткий обзор возможностей политики MLS. Существует метод, связанный с созданием основного файла политики в каталоге /etc, где будет определена необходимая для политики MLS информация, которая будет передана команде setfmac. Этот метод будет описан после рассмотрения всех политик.

Итоги: объект с низким уровнем доступа не может прочесть данные объекта с высоким уровнем доступа. Базовая политика должна устанавливать mls/high на всем, что не должно быть прочитано, даже если туда необходимо записывать. На всем, куда нельзя писать, должна быть установлена метка mls/low, даже если это необходимо читать. Наконец, на всем остальном установите mls/equal. Все пользователи, помеченные как insecure, должны иметь метку mls/low.
^

15.12. Модуль MAC Biba


Имя модуля: mac_biba.ko

Строка конфигурации ядра: options MAC_BIBA

Параметр загрузки: mac_biba_load="YES"

Модуль mac_biba(4) загружает MAC политику Biba. Эта политика работает в основном так же, как и MLS, за исключением того, что правила потока информации изменены на противоположные. Они предназначены для предотвращения передачи потока секретной информации вверх, в то время как политика MLS предотвращает передачу потока секретной информации вниз; таким образом, большая часть этого раздела применима к обеим политикам.

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

Поддерживаемые метки biba/low, biba/equal, и biba/high; описаны ниже:

• Метка biba/low обеспечивает наименьшую целостность объекта или субъекта. Установка ее на объект или субъект заблокирует их доступ к объектам или субъектам, имеющим более высокую метку. Тем не менее, у них остается доступ на чтение.

• Метка biba/equal должна помещаться только на объекты, исключающиеся из политики.

• Метка biba/high разрешит запись в объекты с более низкой меткой, но не разрешит чтение из этих объектов. Рекомендуется помещать такую метку на объекты, влияющие на целостность всей системы.

Biba представляет собой:

• Иерархические уровни целостности с набором не иерархических категорий;

• Фиксированные правила: нет записи наверх, нет чтения снизу (обратно MLS). Субъект может иметь доступ на запись к объектам своего уровня или ниже, но не выше. Аналогично, субъект может иметь доступ на чтение к объектам своего уровня или выше, но не ниже;

• Целостность (предотвращение неавторизованного изменения данных);

• Уровни целостности (вместо уровней секретности MLS).

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

• security.mac.biba.enabled может использоваться для включения/выключения политики Biba.

• security.mac.biba.ptys_equal может использоваться для отключения политики Biba на устройствах pty(4).

• security.mac.biba.revocation_enabled включит отмену доступа к объектам, если метка изменена на более высокую, чем у субъекта.

Для выполнения настроек политики Biba на системных объектах, применяются команды setfmac и getfmac:

# setfmac biba/low test

# getfmac test

test: biba/low

Итоги: субъект с низким уровнем целостности не может писать в субъект с высоким уровнем целостности; субъект с высоким уровнем целостности не может читать из субъекта с низким уровнем целостности.
^

15.13. Модуль MAC LOMAC


Имя модуля: mac_lomac.ko

Строка конфигурации ядра: options MAC_LOMAC

Параметр загрузки: mac_lomac_load="YES"

В отличие от политики MAC Biba, политика mac_lomac(4) разрешает доступ к объектам с более низким уровнем целостности только после уменьшения уровня целостности, чтобы не нарушать каких-либо правил целостности.

MAC версия политики целостности Low-watermark, чтобы не пересекаться со старой реализацией lomac(4), работает почти так же, как и Biba, за исключением использования плавающих меток для поддержки понижения метки субъекта через отдел для вспомогательной градации (auxiliary grade compartment). Этот вспомогательный отдел принимает вид [auxgrade]. При включении политики lomac с вспомогательной градацией метка должна выглядеть приблизительно так: lomac/10[2], где номер 2 это вспомогательная градация.

Политика MAC LOMAC основана на тотальной пометке всех системных объектов метками целостности, разрешая субъектам читать из объектов с более низкой степенью целостности и с уменьшением метки субъекта для предотвращения последующей записи в объекты с более высокой степенью целостности. Параметр [auxgrade] обсуждался выше, таким образом политика может быть более совместимой и требовать меньшей первоначальной настройки, чем Biba.

15.13.1. Примеры


Как и для политик Biba и MLS, для установки меток на системные объекты и субъекты могут быть использованы утилиты setfmac и setpmac:

# setfmac /usr/home/trhodes lomac/high[low]

# getfmac /usr/home/trhodes lomac/high[low]

Обратите внимание, что вспомогательная градация здесь low, эта возможность предоставляется только политикой MAC LOMAC policy.
^

15.14. Реализация защищенной среды с MAC


Нижеследующая демонстрация реализует защищенную среду с использованием различных MAC модулей с соответственно настроенными политиками. Используйте этот пример только для тестирования, он не предназначен для удовлетворения всех требований к защите. Реализация этих политик без понимания принципа их работы неприменима в реальных задачах.

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

15.14.1. Создание insecure класса пользователя


Начните процедуру добавлением следующего класса пользователя к файлу /etc/login.conf:

insecure:\

:copyright=/etc/COPYRIGHT:\

:welcome=/etc/motd:\

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\

:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

:manpath=/usr/share/man /usr/local/man:\

:nologin=/usr/sbin/nologin:\

:cputime=1h30m:\

:datasize=8M:\

:vmemoryuse=100M:\

:stacksize=2M:\

:memorylocked=4M:\

:memoryuse=8M:\

:filesize=8M:\

:coredumpsize=8M:\

:openfiles=24:\

:maxproc=32:\

:priority=0:\

:requirehome:\

:passwordtime=91d:\

:umask=022:\

:ignoretime@:\

:label=partition/13,mls/5:

и добавлением следующей строки к default классу пользователя:

:label=mls/equal,biba/equal,partition/equal:

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

# cap_mkdb /etc/login.conf
^

15.14.2. Загрузка с необходимыми модулями


Добавьте к /boot/loader.conf следующие строки, чтобы необходимые модули были загружены при старте системы:

mac_biba_load="YES"

mac_mls_load="YES"

mac_seeotheruids_load="YES"

mac_partition_load="YES"
^

15.14.3. Установка всех пользователей в insecure


Всем учетным записям, кроме root или системных пользователей теперь потребуется присвоить класс (login class). При отсутствии класса пользователи не смогут получить доступа к обычным командам, таким как vi(1). Следующий скрипт sh сделает все необходимое:

# for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \

/etc/passwd`; do pw usermod $x -L insecure; done;

После этого изменения необходимо запустить команду cap_mkdb на файле /etc/master.passwd.
^

15.14.4. Завершение настройки


Должен быть создан файл контекста; следующий пример взят из примера политики от Robert Watson, он может быть помещен в /etc/policy.contexts:

# This is the default BIBA/MLS policy for this system.


.* biba/high,mls/high

/sbin/dhclient biba/high(low),mls/high(low)

/dev(/.*)? biba/equal,mls/equal

# This is not an exhaustive list of all "privileged" devices.

/dev/mdctl biba/high,mls/high

/dev/pci biba/high,mls/high

/dev/k?mem biba/high,mls/high

/dev/io biba/high,mls/high

/dev/agp.* biba/high,mls/high

(/var)?/tmp(/.*)? biba/equal,mls/equal

/tmp/\.X11-unix biba/high(equal),mls/high(equal)

/tmp/\.X11-unix/.* biba/equal,mls/equal

/proc(/.*)? biba/equal,mls/equal

/mnt.* biba/low,mls/low

(/usr)?/home biba/high(low),mls/high(low)

(/usr)?/home/.* biba/low,mls/low

/var/mail(/.*)? biba/low,mls/low

/var/spool/mqueue(/.*)? biba/low,mls/low

(/mnt)?/cdrom(/.*)? biba/high,mls/high

(/usr)?/home/(ftp|samba)(/.*)? biba/high,mls/high

/var/log/sendmail\.st biba/low,mls/low

/var/run/utmp biba/equal,mls/equal

/var/log/(lastlog|wtmp) biba/equal,mls/equal

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

Он может быть внесен в систему следующими командами:

# setfsmac -ef /etc/policy.contexts /

# setfsmac -ef /etc/policy.contexts /usr

Замечание: Раскладка вышеприведенной файловой системы может быть различной для разных систем.

Файл /etc/mac.conf требует следующих изменений в основном разделе:

default_labels file ?biba,?mls

default_labels ifnet ?biba,?mls

default_labels process ?biba,?mls,?partition

default_labels socket ?biba,?mls
^

15.14.5. Тестирование настройки


Добавьте пользователя с помощью команды adduser и поместите его в класс insecure для этих тестов.

В примерах ниже тестирование root и обычных пользователей будет смешиваться; форма приглашения поможет различить этих пользователей.
^
15.14.5.1. Основное тестирование меток

% getpmac

biba/15(15-15),mls/15(15-15),partition/15

# setpmac partition/15,mls/equal top

Замечание: Процесс top будет уничтожен перед тем, как мы запустим другой процесс top.
^
15.14.5.2. Тестирование MAC seeotheruids

% ps Zax

biba/15(15-15),mls/15(15-15),partition/15 1096 #C: S 0:00.03 -su (bash)

biba/15(15-15),mls/15(15-15),partition/15 1101 #C: R+ 0:00.01 ps Zax

Просмотр процессов всех других пользователей должен быть запрещен.
^
15.14.5.3. Тестирование MAC partition

Отключите политику MAC seeotheruids для остальных тестов:

# sysctl security.mac.seeotheruids.enabled=0

% ps Zax

LABEL PID TT STAT TIME COMMAND

biba/equal(low-high),mls/equal(low-high),partition/15 1122 #C: S+ 0:00.02 top

biba/15(15-15),mls/15(15-15),partition/15 1096 #C: S 0:00.05 -su (bash)

biba/15(15-15),mls/15(15-15),partition/15 1123 #C: R+ 0:00.01 ps Zax

Все пользователи должны видеть каждый процесс в своем разделе (partition).
^
15.14.5.4. Тестирование меток Biba и MLS

# setpmac partition/15,mls/equal,biba/high\(high-high\) top

% ps Zax

LABEL PID TT STAT TIME COMMAND

biba/high(high-high),mls/equal(low-high),partition/15 1251 #C: S+ 0:00.02 top

biba/15(15-15),mls/15(15-15),partition/15 1096 #C: S 0:00.06 -su (bash)

biba/15(15-15),mls/15(15-15),partition/15 1157 #C: R+ 0:00.00 ps Zax

Политика Biba позволяет чтение объектов с более высокими метками.

# setpmac partition/15,mls/equal,biba/low top

% ps Zax

^ LABEL PID TT STAT TIME COMMAND

biba/15(15-15),mls/15(15-15),partition/15 1096 #C: S 0:00.07 -su (bash)

biba/15(15-15),mls/15(15-15),partition/15 1226 #C: R+ 0:00.01 ps Zax

Политика Biba не позволяет чтение объектов с более низкими метками; тем не менее, MLS разрешает это.

% ifconfig bge0 | grep maclabel

maclabel biba/low(low-low),mls/low(low-low)

% ping -c 1 192.0.34.166

PING 192.0.34.166 (192.0.34.166): 56 data bytes

ping: sendto: Permission denied

Пользователи не могут выполнить ping на example.com, или на любой домен по этой причине.

Для устранения этой ошибки, запустите следующую команду:

# sysctl security.mac.biba.trust_all_interfaces=1

Она устанавливает метку интерфейса по умолчанию в незащищенный режим, так что политика Biba по умолчанию не будет применена.

# ifconfig bge0 maclabel biba/equal\(low-high\),mls/equal\(low-high\)

% ping -c 1 192.0.34.166

PING 192.0.34.166 (192.0.34.166): 56 data bytes

64 bytes from 192.0.34.166: icmp_seq=0 ttl=50 time=204.455 ms

--- 192.0.34.166 ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

round-trip min/avg/max/stddev = 204.455/204.455/204.455/0.000 ms

Установив более корректную метку, мы можем использовать ping.

Теперь создадим файлы для процедуры тестирования чтения и записи:

# touch test1 test2 test3 test4 test5

# getfmac test1

test1: biba/equal,mls/equal

# setfmac biba/low test1 test2; setfmac biba/high test4 test5; \

setfmac mls/low test1 test3; setfmac mls/high test2 test4

# setfmac mls/equal,biba/equal test3 && getfmac test?

test1: biba/low,mls/low

test2: biba/low,mls/high

test3: biba/equal,mls/equal

test4: biba/high,mls/high

test5: biba/high,mls/equal

# chown testuser:testuser test?

Все эти файлы должны принадлежать пользователю testuser. Тесты на чтение:

% ls

test1 test2 test3 test4 test5

% ls test?

ls: test1: Permission denied

ls: test2: Permission denied

ls: test4: Permission denied

test3 test5

Доступ на чтение не должен быть разрешен для пар: (biba/low,mls/low), (biba/low,mls/high) и (biba/high,mls/high). Теперь несколько тестов на запись:

% for i in `echo test*`; do echo 1 > $i; done

-su: test1: Permission denied

-su: test4: Permission denied

-su: test5: Permission denied

Подобно тестам на чтение, доступ на запись должен быть запрещен для пар: (biba/low,mls/high) и (biba/equal,mls/equal).

% cat test?

cat: test1: Permission denied

cat: test2: Permission denied

1

cat: test4: Permission denied

А теперь от root:

# cat test2

1
^

15.15. Другой пример: Использование MAC для защиты веб сервера


Будет создано отдельное хранилище для веб данных, к которому пользователи должны иметь доступ. Это позволит biba/high управлять доступом к веб данным.

Начните с создания каталога для хранения веб данных:

# mkdir /usr/home/cvs

Теперь инициализируйте его командой cvs:

# cvs -d /usr/home/cvs init

Для начала необходимо включить политику biba, добавив mac_biba_enable="YES" в /boot/loader.conf. Предполагается, что ядро скомпилировано с поддержкой MAC.

Далее установите метку biba/high для всей системы по умолчанию.

В файл login.conf, класс default, необходимо внести следующие изменения:

:ignoretime@:\

:umask=022:\

:label=biba/high:

Каждого пользователя необходимо поместить в класс по умолчанию; такая команда:

# for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \

/etc/passwd`; do pw usermod $x -L default; done;

быстро решит эту задачу.

Теперь создадим другой класс, web, копию класса default с меткой, установленной в biba/low.

Создайте пользователя для работы с основными веб данными, хранящимися в репозитории cvs. Этого пользователя необходимо поместить в новый класс, web.

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

Все, что потребуется, это следующий sh(1) скрипт, который может быть запущен из cron(8):

PATH=/bin:/usr/bin:/usr/local/bin; export PATH;

CVSROOT=/home/repo; export CVSROOT;

cd /home/web;

cvs -qR checkout -P htdocs;

exit;

Замечание: Во многих случаях в веб файлы cvs необходимо поместить теги Id.

Этот скрипт теперь может быть помещен в домашний каталог каталог пользователя web, необходимо также добавить следующую запись crontab(1):

# Выполнять checkout web данных под меткой biba/low каждые 12 часов:

0 */12 * * * web /home/web/checkout.sh

Эта запись будет извлекать HTML страницы каждые двенадцать часов.

Метод запуска веб сервера по умолчанию также должен быть изменен для запуска процесса с меткой biba/low. Это может быть сделано путем следующего изменения в скрипте /usr/local/etc/rc.d/apache.sh:

command="setpmac biba/low /usr/local/sbin/httpd"

Настройки Apache должны быть изменены для работы с политикой biba/low. В этом случае необходимо указать для хранения лог файлов каталог с меткой biba/low, иначе будут возвращены ошибки access denied.

Замечание: В этом примере необходимо указать в директиве docroot каталог /home/web/htdocs; или, Apache не сможет найти каталог с документами.

Необходимо также изменить другие параметры конфигурации, включая PID файл, Scoreboardfile, DocumentRoot, или любые другие настройки для каталогов, где необходим доступ на запись. При использовании biba будет запрещен доступ на запись во все каталоги сервера, на которых нет метки biba/low.
^

15.16. Решение проблем с инфраструктурой MAC


На стадии разработки несколько пользователей сообщали о проблемах при обычных настройках. Некоторые из этих проблем приведены ниже:
^

15.16.1. Параметр multilabel не может быть включен на /


Параметр multilabel не включается на моем корневом (/) разделе!

Похоже, что каждый пятидесятый пользователь сталкивается с этой проблемой; на самом деле, и у нас была эта проблема в первых настройках. Дальнейшие наблюдения за этой так называемой ''ошибкой'' привели меня к мнению, что это результат или некорректной документации, или неправильной интерпретации этой документации. Независимо от того, почему это случилось, для решения этой проблемы могут быть предприняты следующие шаги:

1. Отредактируйте /etc/fstab и установите для корневого раздела параметр только для чтения (ro).

2. Перегрузитесь в однопользовательский режим.

3. Запустите команду tunefs -l enable на /.

4. Перегрузите систему в нормальный режим.

5. Запустите mount -urw / и измените параметр ro обратно на rw в /etc/fstab; перегрузите систему опять.

6. Дважды проверьте вывод mount, чтобы убедиться, что параметр multilabel был установлен на корневой файловой системе.
^

15.16.2. Не могу запустить XFree86 после MAC


После настройки системы безопасности MAC, я больше не могу запускать XFree86!

Это может быть вызвано политикой MAC partition или путем неправильной установки меток одной из политик MAC. Для отладки попробуйте следующее:

1. Просмотрите сообщение об ошибке; если пользователь находится в классе insecure, проблема может быть в политике partition. Попробуйте установить класс пользователя обратно в default и пересобрать базу данных командой cap_mkdb. Если это не решит проблемы, попробуйте шаг два.

2. Дважды проверьте политики с метками. Убедитесь, что политики настроены правильно для рассматриваемого пользователя, приложения XFree86, и устройств в /dev.

3. Если проблема не решена, отправьте сообщение об ошибке и описание вашей системы в список рассылки TrustedBSD, находящийся на веб сайте TrustedBSD (http://www.TrustedBSD.org) или в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD (http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions).
^

15.16.3. Error: _secure_path(3) cannot stat .login_conf


При попытке переключения от root на другого пользователя системы, появляется сообщение об ошибке _secure_path: unable to state .login_conf.

Это сообщение обычно показывается, когда у пользователя более высокая метка, чем у пользователя, которым он пытается стать. Например, у пользователя системы joe метка по умолчанию biba/low. Пользователь root, метка которого biba/high, не может просматривать домашний каталог пользователя joe. Это не зависит от того, использует ли пользователь root команду su joe или нет. В этом сценарии модель целостности Biba не позволит root просматривать объекты с низким уровнем целостности.
^

15.16.4. Пользователя root нет!


В нормальном или даже однопользовательском режиме root не обнаруживается. Команда whoami возвращает 0 (нуль) и su возвращает who are you?. Что можно сделать?

Это может произойти, если политика с метками была отключена, или через sysctl(8), или путем выгрузки модуля политики. Если политика была постоянно или временно отключена, базу данных login необходимо перенастроить. Дважды проверьте login.conf, чтобы убедиться, что все параметры label были удалены и пересоберите базу данных командой cap_mkdb.

Примечания

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

2. Вследствие ошибки переменная sysctl security.mac.portacl.enabled не будет работать в FreeBSD 5.2.1 или более ранних релизах.
^

Глава 16. Аудит событий безопасности


Автор Tom Rhodes. Перевод на русский язык: Денис Баров.

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


FreeBSD 7-CURRENT включает в себя поддержку Аудита Событий Безопасности (Security Event Auditing), стандарт которого описан в проекте POSIX.1e и в опубликованном корпорацией Sun описании BSM API. Система аудита позволяет отслеживать события, важные для безопасности системы. Анализ лога событий может быть жизненно необходим в случае краха системы, для обнаружения нежелательных вторжений и для ликвидации последствий событий подобного рода. После тестирования во FreeBSD 7-CURRENT поддержка системы аудита будет добавлена во FreeBSD 6-STABLE и более ранние ветви FreeBSD.

Внимание: Поддержка аудита во FreeBSD считается экспериментальной, использование системы аудита должно производиться только после тщательного ознакомления со всеми рисками использования экспериментального программного обеспечения.

В этой главе описывается, в основном, процесс установки и конфигурирования системы аудита. В том числе, приводится разъяснение политик аудита, а так же примеры конфигурационных файлов.

После прочтения этой главы вы будете знать:

• Что такое система аудита и как она работает.

• Как настроить систему аудита во FreeBSD для мониторинга пользователей и процессов.

Перед прочтением этой главы вы должны:

• Понимать основы UNIX и FreeBSD (Гл. 3).

• Уметь конфигурировать и компилировать ядро (Гл. 8).

• Понимать основные принципы безопасности в применении к операционной системе FreeBSD (Гл. 14).

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

Реализация системы аудита во FreeBSD похожа на реализацию библиотеки Базового Модуля Безопасности корпорации Sun (Sun™ Basic Security Module, BSM). Поэтому, его конфигурация почти полностью совпадает с конфигурацией аналогичных по назначению модулей в операционных системах Solaris и Mac OS X/Darwin.
^

16.2. Ключевые понятия - краткий словарь.


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

событие(event): Событие, которое может быть занесено в журнал. Администратор может выбирать, какие именно события будут журналироваться подсистемой аудита. Список важных для безопасности системы событий включает: создание файла, инициализацию сетевого соединения, вход пользователя в систему. События разделяются на ''приписываемые'' (attributable) - те, которые могут быть отнесены к конкретному пользователю - и ''не-приписываемые'' (non-attributable). Пример не-приписываемого события - любое событие, произошедшее до авторизации пользователя, такое, как неудачный вход пользователя в систему.

Класс(class): События могут быть отнесены к одному или более классам, обычно основываясь на категории события: ''создание файла'', ''доступ к файлу'',''сеть''. События входа в систему и выхода из нее относятся к классу lo. Использование классов позволяет администратору создавать высокоуровневые правила аудита без указания конкретных операций, отчет о которых должен добавляться в журнал.

Запись(record): ''Запись'' - это единичная запись в журнале, описывающая то или иное событие. Запись обычно содержит информацию о типе события, информацию о субъекте события (пользователе), время события, информацию об объектах события (например, файлах) и информацию об успешности выполнения операции, породившей событие.

Журнал(trail): ''журнал'' аудита, или лог-файл - содержит серию ''записей'' о системных событиях. Как правило, журнал содержит записи в строгом хронологическом порядке по времени завершения события. Только авторизованные процессы (например, auditd) имеют доступ к журналу.

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

16.3. Установка системы аудита


Система аудита обычно устанавливается в процессе установки системы installworld. Администратор может проверить, установлена ли система аудита, просмотрев содержимое каталога /etc/security. В нём должны находиться файлы, начинающиеся со слова audit. Например, audit_event.

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

options AUDIT

Процесс сборки и установки ядра подробно описан в главе Гл. 8.

После этого, необходимо разрешить запуск даемона аудита, добавив следующую строку в rc.conf(5):

auditd_enable="YES"

Для запуска даемона со специфическими параметрами нужно указать эти параметры в опции auditd_flags файла rc.conf(5).
^

16.4. Настройка системы аудита


Все конфигурационные файлы системы аудита находятся в каталоге /etc/security. Перед запуском даемона аудита там должны находиться следующие файлы:

• audit_class - Содержит определения классов аудита.

• audit_control - Параметры системы аудита: классы по умолчанию, минимальное дисковое пространство, которое должно оставаться на разделе журнала аудита, и другие.

• audit_event - Определяет основные события аудита. Это, в основном, системные вызовы.

• audit_user - События аудита для для отдельных пользователей. Пользователи, не упоминаемые в этом файле, будут рассматриваться как субъекты конфигурации по-умолчанию в файле audit_control.

• audit_warn - Скрипт командного интерпретатора Bourne Shell, который используется, чтобы сгенерировать предупреждающие сообщения об исключительных ситуациях, например, когда заканчивается свободное дисковое пространство для записей журналов аудита.
^

16.4.1. Формат конфигурационного файла


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

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

Следующий список содержит все поддерживаемые классы:

• all - all - Установить все флаги.

• ad - administrative - Аудит административных действий, произошедших в системе.

• ap - application - Аудит события, вызванного каким-либо приложением.

• cl - file_close - Аудит вызовов системной функции close.

• ex - exec - Аудит запуска приложения.

• fa - file_attr_acc - Аудит доступа к атрибутам объектов и их изменению, например через stat(1), pathconf(2), а также подобных этим событий.

• fc - file_creation - Аудит событий, в результате которых создаются файлы.

• fd - file_deletion - Аудит событий, в результате которых удаляются файлы.

• fm - file_attr_mod - Аудит событий, в результате которых изменяются атрибуты файлов, например, chown(8), chflags(1), flock(2).

• fr - file_read - Аудит событий, в результате которых происходит чтение данных, открываются файлы на чтение и т.п.

• fw - file_write - - Аудит событий, в результате которых происходит запись данных, изменение файлов и так далее.

• io - ioctl - Аудит вызовов системной функции ioctl(2).

• ip - ipc - Аудит различных видов взаимодействия процессов, включая создание не-именованных каналов (pipe) и взаимодействие процессов в стиле System V IPC.

• lo - login_logout - Аудит событий login(1) и logout(1).

• na - non_attrib - Аудит не-приписываемых событий.

• no - no_class - Пустой класс, используется для отключения аудита.

• nt - network - Аудит событий, связанных с сетевыми подключениями, например connect(2) и accept(2).

• ot - other - Аудит событий, не вошедших в другие классы.

• pc - process - Аудит действий процессов, таких как exec(3) и exit(3).

Далее перечислены все поддерживаемые префиксы:

• [пустой префикс] - Аудит проводится как для успешного, так и для ошибочного события. Например, просто указание класса без префикса приведёт к занесению события в журнал при любом результате операции.

• + - Аудит только успешных событий.

• - - Аудит только ошибочных событий.

Внимание: Использование класса all с любым префиксом может привести к генерации огромного количества данных с очень большой частотой.

Дополнительные префиксы, которые могут использоваться для изменения настроек по умолчанию:

• ^- - Отключение аудита ошибочных событий.

• ^+ - Включение аудита успешных событий.

• ^ - Отключение аудита как успешных, так и ошибочных событий.
^

16.4.2. Конфигурационные файлы


В большинстве случаев администратору придётся вносить изменения только в два конфигурационных файла системы аудита: audit_control и audit_user. Первый из них содержит общие настройки системы аудита и установки по умолчанию как для приписываемых, так и для не-приписываемых событий. Второй используется для настройки аудита пользовательских событий.
^
16.4.2.1. Файл audit_control

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

dir:/var/audit

flags:lo

minfree:20

naflags:lo

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

Параметр flags используется для установки глобальных опций. Значение этого параметра lo настраивает аудит для всех событий login(1) и logout(1). Более подробный пример:

dir:/var/audit

flags:lo,ad,-all,^-fa,^-fc,^-cl

minfree:20

naflags:lo

Такое значение параметра flags приведёт к аудиту всех событий login(1) и logout(1), всех административных событий, всех ошибочных системных событий и, наконец, отключает аудит всех ошибочных событий классов fa, fc и cl. Несмотря на то, что параметр -all указывает на необходимость аудита всех системных событий, префикс ^- отменяет это поведение для всех последующих опций.

Заметьте, что значения считываются слева направо. Поэтому находящиеся справа значения переопределяют значения, находящиеся слева.

Параметр minfree определяет минимальное значение свободного дискового пространства на разделе, в который сохраняются файлы журналов аудита. Например, если значение параметра dir установлено в /var/audit, а параметр minfree равен двадцати (20), то предупреждающее сообщение будет выдано, когда раздел /var будет заполнен на восемьдесят (80%) процентов.

Параметр naflags определяет классы аудита для не-приписываемых событий, то есть событий, для которых не определён конкретный пользователь.
^
16.4.2.2. Файл audit_user

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

По умолчанию файл audit_user содержит:

root:lo:no

audit:fc:no

Обратите внимание: по умолчанию производится аудит всех login/logout событий и отключается аудит всех других событий для пользователя root. Эта конфигурация также включает аудит всех событий, связанных с созданием файлов и отключает аудит всех других событий для пользователя audit. Хотя использование системы аудита не требует наличия в системе специального пользователя, в некоторых конфигурациях, особенно использующих MAC (Mandatory Access Control), это может быть необходимо.
^

16.5. Администрирование системы аудита


Журнал событий, записываемый ядром системы аудита не может быть прочитан или отредактирован как простой текст. Данные сохраняются и считываются методами, схожими с ktrace(1) и kdump(1), поэтому, журналы можно просмотреть только с помощью команды praudit. Информация из журналов может быть отфильтрована при помощи команды auditreduce, которая выбирает записи из журналов, основываясь на определённых параметрах, таких как пользователь, время события или тип операции.

Например, praudit может вывести всё содержимое определённого журнала в текстовом формате. Для этого выполните команду:

# praudit /var/audit/AUDITFILE

Здесь AUDITFILE - имя файла журнала по вашему выбору. Поскольку, файлы журналов могут содержать гигантское количество данных, администратору может понадобиться выбирать записи событий только одного пользователя. Это возможно с помощью следующей команды, в которой trhodes - имя пользователя:

# auditreduce -e trhodes /var/audit/AUDITFILE | praudit

Результатом будет выборка из файла AUDITFILE всех событий, связанных с пользователем trhodes.

Есть ряд других параметров для чтения журналов аудита, для более детального изучения смотрите страницу справки команды praudit.
^

16.5.1. Ротация лог-файлов системы аудита


Исходя из соображений безопасности, запись в журнал аудита производится только ядром системы; все управление журналом осуществляется даемоном auditd. Администраторы не должны пытаться использовать newsyslog.conf(5) или другие инструменты для прямой ротации логов системы аудита. Вместо этого, для остановки, переконфигурации системы аудита и для ротации лог-файлов используйте утилиту управления audit. Следующая команда заставит даемон auditd создать новый лог-файл и переключить систему аудита на его использование. Старый лог-файл будет переименован:

# audit -n

Внимание: Если даемон auditd не запущен, команда завершится с ошибкой.

Добавление следующей строки в файл /etc/crontab приведёт к автоматической ротации лог-файлов каждые двенадцать часов при помощи cron(8):

* */12 * * * root /usr/sbin/audit -n

Изменения вступят в силу сразу же после сохранения файла /etc/crontab.
^

16.5.2. Передача прав на просмотр журнала аудита


По умолчанию, только пользователь root имеет право просматривать журналы аудита. Тем не менее, эти права могут быть переданы, например, пользователям, входящим в группу audit. Для этого необходимо передать каталог системы аудита и файлы журналов аудита группе audit. После этого нужно дать группе права на чтение каталога и находящихся в нём файлов. Например, если раздел журналов аудита смонтирован в /var/audit, нужно выполнить команды:

# chown -R :audid /var/audit

# chmod -R g+r /var/audit

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

Глава 17. Устройства хранения


Перевод на русский язык: Андрей Захватов.

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


В этой главе описывается использование дисков во FreeBSD. К ним относятся диски в памяти, диски, подключенные по сети, обычные устройства хранения SCSI/IDE и устройства, использующие интерфейс USB.

После чтения этой главы вы будете знать:

• Терминологию, используемую во FreeBSD для описания организации данных на физическом диске (разделы и слайсы).

• Как добавить дополнительные винчестеры к вашей системе.

• Как настроить FreeBSD для использования дисковых устройств USB.

• Как настроить виртуальные файловые системы, такие, как диски в оперативной памяти.

• Как использовать квоты для ограничения использования дискового пространства.

• Как зашифровать диски, чтобы защитить их от взлома.

• Как создавать и записывать CD и DVD во FreeBSD.

• Различные варианты использования устройств хранения для резервных копий.

• Как использовать программы резервного копирования, имеющиеся для FreeBSD.

• Как выполнять резервное копирование на дискеты.

• Что такое мгновенные копии файловых систем и как их эффективно использовать

Перед прочтением этой главы вам потребуется:

• Узнать как настраивать и устанавливать новое ядро FreeBSD (Гл. 8).
^

17.2. Имена устройств


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

Таблица 17-1. Соглашения по именованию физических дисков

^ Тип диска

Имя дискового устройства

Винчестеры IDE

ad

Приводы IDE CDROM

acd

Винчестеры SCSI и дисковые устройства USB

da

Приводы SCSI CDROM

cd

Различные нестандартные приводы CDROM

mcd для Mitsumi CD-ROM, scd для Sony CD-ROM, matcd для Matsushita/Panasonic CD-ROM a

Дискеты

fd

Ленточные приводы SCSI

sa

Ленточные приводы IDE

ast

Флэш-диски

fla для флэш-устройств DiskOnChip®

Диски RAID

aacd для Adaptec AdvancedRAID, mlxd и mlyd для Mylex, amrd для AMI MegaRAID, idad для Compaq Smart RAID, twed для 3ware® RAID.

Примечания:

a. 5 октября 2002 года драйвер matcd(4) был удалён из ветки FreeBSD 4.X и отсутствует во FreeBSD 5.0 и последующих релизах.



^

17.3. Добавление дисков


Изначальный текст предоставил David O'Brien.

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

Войдите в систему как пользователь root. После того, как вы установили диск, просмотрите файл /var/run/dmesg.boot, чтобы убедиться, что новый диск был найден. Продолжая наш пример, только что добавленный диск будет называться da1 и мы хотим смонтировать его в каталог /1 (если вы добавляете диск IDE, то устройство будет называться wd1 в системах, предшествовавших 4.0, и ad1 в системах 4.X и 5.X).

FreeBSD работает на IBM-PC совместимых компьютерах, поэтому она должна уметь работать с разделами PC BIOS. Однако они отличаются от традиционных разделов BSD. Диск ПК может иметь до четырёх записей разделов BIOS. Если диск на самом деле будет использоваться исключительно под FreeBSD, вы можете использовать режим dedicated. В противном случае FreeBSD будет располагаться в одном из разделов PC BIOS. Во FreeBSD разделы PC BIOS называются слайсами, чтобы не путать их с традиционными разделами BSD. Вы также можете использовать слайсы и с диском, предназначенным исключительно для FreeBSD, однако используемым в компьютере, на котором имеется дополнительная операционная система. Это является хорошим способом избежать путаницы в утилите fdisk других операционных систем, не связанных с FreeBSD.

В случае слайсов диск будет добавлен как /dev/da1s1e. Это интерпретируется следующим образом: диск SCSI, устройство номер 1 (второй диск SCSI), слайс 1 (раздел PC BIOS 1), и раздел BSD e. В случае использования в выделенном режиме диск будет добавлен просто как /dev/da1e.

Вследствие использования 32-разрядных целых чисел для адресации секторов, bsdlabel(8) (называемый disklabel(8) в FreeBSD 4.X) ограничен 2^32-1 секторами на диск, или 2TB в в большинстве случаев. Формат fdisk(8) позволяет наличие первого сектора со смещением не более 2^32-1 и длину не более 2^32-1, что ограничивает размер раздела до 2TB, а размер диска до 4TB в большинстве случаев. Формат sunlabel(8) ограничен 2^32-1 секторами на раздел и 8 разделами, что составляет 16TB. Для дисков большего раздела могут быть использованы разделы gpt(8).
^

17.3.1. Использование утилиты sysinstall(8)


1. Использование Sysinstall

Вы можете использовать простые меню утилиты sysinstall (/stand/sysinstall во FreeBSD версий, более старых, чем 5.2) для разбиения на разделы и разметки нового диска. Войдите как пользователь root или воспользуйтесь командой su. Запустите команду sysinstall и войдите в меню Configure. Внутри FreeBSD Configuration Menu, пролистайте и выберите пункт Fdisk.

2. Редактор разделов fdisk

При работе с утилитой fdisk ввод A используется для выделения под FreeBSD полностью всего диска. Когда будет задан вопрос о том, хотите ли вы ''сохранить совместимость с другими возможными операционными системами в будущем'', ответьте YES. Запишите изменения на диск при помощи команды W. А теперь выйдите из редактора FDISK, нажав q. В этот момент вам будет задан вопрос о ''Master Boot Record'' (главной загрузочной записи). Так как вы добавляете диск к уже работающей системе, выберите None.

3. Редактор метки диска

Теперь вам нужно выйти из sysinstall и запустить эту утилиту снова. Следуйте указаниям выше, но на этот раз выберите пункт Label. Вы перейдёте к меню Disk Label Editor. Здесь вы создадите традиционные разделы BSD. На диске может быть до восьми разделов, имеющих метки a-h. Некоторые из меток разделов имеют особый смысл. Раздел a используется для размещения корневого раздела (/). По этой причине только ваш системный диск (например, тот, с которого происходит загрузка), должен иметь раздел a. Раздел b используется под раздел подкачки, и вы можете иметь много дисков с разделами подкачки. Раздел c используется для доступа ко всему диску в режиме эксклюзивного использования или ко всему слайсу FreeBSD при работе в режиме с использованием слайсов. Остальные разделы имеют обычное предназначение.

Редактор метки диска программы sysinstall использует раздел e для некорневого раздела и не для раздела подкачки. Внутри редактора метки диска создайте отдельную файловую систему, нажав C. Когда будет задан вопрос о том, будет ли это раздел с файловой системой (FS) или это будет раздел подкачки, выберите FS и наберите точку монтирования (например, /mnt). При добавлении диска после установки системы, программа sysinstall не будет автоматически создавать записи в файле /etc/fstab, поэтому точка монтирования не так уж и важна.

Теперь вы готовы записать новую метку на диск и создать на нем файловую систему. Сделайте это, набрав ^ W. Проигнорируйте сообщения об ошибках от sysinstall о невозможности смонтировать новый раздел. Полностью выйдите из редактора метки диска и из программы sysinstall.

4. Завершение

Последний шаг заключается в редактировании файла /etc/fstab и добавлении записи для вашего нового диска.
^

17.3.2. Использовании утилит командной строки

17.3.2.1. Работа со слайсами

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

# dd if=/dev/zero of=/dev/da1 bs=1k count=1

# fdisk -BI da1 # Инициализируем новый диск.

# disklabel -B -w -r da1s1 auto # Размечаем его.

# disklabel -e da1s1 # Редактируем только что созданную метку диска и добавляем разделы.

# mkdir -p /1

# newfs /dev/da1s1e # Повторяем этот шаг для всех созданных разделов.

# mount /dev/da1s1e /1 # Монтируем раздел(ы)

# vi /etc/fstab # Добавляем соответствующую запись/записи в файл /etc/fstab.

Если у вас установлен диск IDE, подставьте ad вместо da. На системах версий ранее 4.X используйте wd.
^
17.3.2.2. Эксклюзивный режим

Если вы не будете использовать новый диск совместно с другой операционной системой, то вы можете использовать режим эксклюзивного использования. Отметьте, что этот режим может ввести в заблуждение операционные системы от Microsoft; однако информацию они не разрушат. А вот OS/2 компании IBM будет ''забирать себе'' любой раздел, который она найдет и не сможет распознать.

# dd if=/dev/zero of=/dev/da1 bs=1k count=1

# disklabel -Brw da1 auto

# disklabel -e da1 # create the `e' partition

# newfs -d0 /dev/da1e

# mkdir -p /1

# vi /etc/fstab # add an entry for /dev/da1e

# mount /1

Альтернативный метод заключается в следующем:

# dd if=/dev/zero of=/dev/da1 count=2

# disklabel /dev/da1 | disklabel -BrR da1 /dev/stdin

# newfs /dev/da1e

# mkdir -p /1

# vi /etc/fstab # add an entry for /dev/da1e

# mount /1

Замечание: Начиная с FreeBSD 5.1-RELEASE, на смену старой программе disklabel(8) пришла утилита bsdlabel(8). У bsdlabel(8) отсутствуют некоторые устаревшие опции и параметры; в примере выше параметр -r не может использоваться с bsdlabel(8). Для получения дополнительной информации обратитесь к справочной странице п о bsdlabel(8).

17.4. RAID

^

17.4.1. Программный RAID

17.4.1.1. Конфигурация драйвера объединённого диска (CCD)

Оригинальный текст предоставил Christopher Shumway. Изменения внёс Jim Brown.

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

При проектировании описываемой далее системы в качестве самого важного фактора была выбрана её стоимость, затем быстродействие и надёжность. Скорость передачи данных для этой системы ограничивалась только пропускной способностью сети. И, хотя надёжность очень важна, CCD-диск, описываемый ниже, обслуживал работу с данными, полные копии которых уже хранились на дисках CD-R, так они могли быть с лёгкостью обновлены.

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

Кроме системного IDE-диска, основу описываемого далее CCD-диска общим объёмом примерно в 90 Гбайт составили три IDE-диска Western Digital 30GB, 5400 RPM. В идеальном случае каждый диск IDE имеет собственный контроллер и кабель, но для минимизации стоимости дополнительные контроллеры IDE не использовались. Вместо этого диски были настроены при помощи переключателей так, что на каждом IDE-контроллере находилось по одному ведущему и одному ведомому диску.

До перезагрузки BIOS системы была настроена на автоматическое распознавание подключенных дисков. Более важно то, что при перезагрузке их распознала FreeBSD:

ad0: 19574MB [39770/16/63] at ata0-master UDMA33

ad1: 29333MB [59598/16/63] at ata0-slave UDMA33

ad2: 29333MB [59598/16/63] at ata1-master UDMA33

ad3: 29333MB [59598/16/63] at ata1-slave UDMA33

Замечание: Если FreeBSD не распознала все диски, проверьте корректность положения переключателей на них. На большинстве IDE-дисков имеется также переключатель ''Cable Select''. Он не имеет отношения к выбору ведущего и ведомого устройств. Для получения помощи по правильному положению переключателей обратитесь к документации по устройствам.

Затем определите, как сделать их частью файловой системы. Изучите справку по vinum(8) (Гл. 19) и ccd(4). В нашем конкретном случае была выбрана технология ccd(4).
17.4.1.1.2. Настройка CCD

Драйвер ccd(4) позволяет вам взять несколько идентичных дисков и объединить их в одну логическую файловую систему. Для использования ccd(4) нужно ядро со встроенной поддержкой ccd(4). Добавьте такую строку в файл конфигурации ядра, перестройте и установите новое ядро:

pseudo-device ccd 4

В системах 5.X вместо этого вам нужно использовать такую строку:

device ccd

Замечание: Во FreeBSD 5.X нет нужды указывать количество устройств ccd(4) так как драйвер устройства ccd(4) теперь клонируется сам — новые экземпляры устройств будут создаваться автоматически по необходимости.

Во FreeBSD 3.0 и последующих версиях поддержка ccd(4) также может быть обеспечена загрузкой подгружаемого модуля ядра.

Для настройки ccd(4) сначала вам нужно воспользоваться утилитой disklabel(8) для разметки дисков:

disklabel -r -w ad1 auto

disklabel -r -w ad2 auto

disklabel -r -w ad3 auto

При этом создаются метки для ad1c, ad2c и ad3c, которые занимают диск полностью.

Замечание: Начиная с FreeBSD 5.1-RELEASE, на смену старой программе disklabel(8) пришла утилита bsdlabel(8). У bsdlabel(8) отсутствуют некоторые устаревшие опции и параметры; в примере выше параметр -r не может использоваться с bsdlabel(8). Для получения дополнительной информации обратитесь к справочной странице п о bsdlabel(8).

Следующим шагом является изменение типа метки диска. Для редактирования дисков можно использовать утилиту disklabel(8):

disklabel -e ad1

disklabel -e ad2

disklabel -e ad3

При этом в редакторе, задаваемом переменной окружения EDITOR (обычно это vi(1)), открывается текущая метка каждого диска.

Немодифицированная метка диска будет выглядеть примерно следующим образом:

8 partitions:

# size offset fstype [fsize bsize bps/cpg]

c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)

Добавьте новый раздел e для использования драйвером ccd(4). Как правило, он может быть скопирован с раздела c, но поле fstype должно иметь значение 4.2BSD. Теперь метка диска должна выглядеть примерно так:

8 partitions:

# size offset fstype [fsize bsize bps/cpg]

c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)

e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597)
17.4.1.1.3. Построение файловой системы

Файл устройства для ccd0c может ещё не существовать, так что для его создания предварительно выполните такие команды:

cd /dev

sh MAKEDEV ccd0

Замечание: Во FreeBSD 5.0 devfs(5) будет управлять файлами устройств в каталоге /dev автоматически, так что в использовании MAKEDEV необходимости нет.

Теперь, когда все диски размечены, вы должны построить ccd(4). Для этого используйте утилиту ccdconfig(8) с параметрами, подобными следующим:

ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e

Использование и значение каждого параметра описывается ниже:

 Первым аргументом является конфигурируемое устройство, в нашем случае /dev/ccd0c. Часть /dev/ является необязательной.

 Чередование для файловой системы. Оно определяет размер единицы блока данных в количестве дисковых блоков, каждый из которых обычно имеет объём в 512 байт. Таким образом, при чередовании в 32 это будет составлять 16384 байт.

 Опции для ccdconfig(8). Если вы хотите включить зеркалирование диска, то можете задать это здесь. В нашей конфигурации зеркалирование для ccd(4) не предусмотрено, поэтому здесь задан 0 (ноль).

 Последним параметром для ccdconfig(8) является список устройств для объединения в массив. Для каждого устройства нужно задавать полное имя.

После запуска ccdconfig(8) устройство ccd(4) будет отконфигурировано. Может будет построить файловую систему. Обратитесь к справке по команде newfs(8) для выяснения требуемых параметров, или просто запустите:

newfs /dev/ccd0c
17.4.1.1.4. Автоматическое выполнение

Вообще говоря, вам потребуется монтировать ccd(4) при каждой перезагрузке. Для этого сначала вы должны отконфигурировать это устройство. Запишите вашу текущую конфигурацию в файл /etc/ccd.conf при помощи такой команды:

ccdconfig -g > /etc/ccd.conf

При перезагрузке скрипт /etc/rc запускает команду ccdconfig -C, если существует файл /etc/ccd.conf. При этом ccd(4) автоматически конфигурируется так, чтобы он мог быть смонтирован.

Замечание: Если при загрузке вы входите в однопользовательский режим, то перед тем, как выполнять монтирование ccd(4) по команде mount(8), вам нужно для конфигурации массива запустить следующую команду:

ccdconfig -C

Для автоматического монтирования ccd(4) поместите запись о ccd(4) в файл /etc/fstab, чтобы он мог быть смонтирован во время загрузки системы:

/dev/ccd0c /media ufs rw 2 2
^
17.4.1.2. Менеджер томов Vinum

Менеджер томов Vinum является драйвером блочного устройства, который реализует виртуальные диски. Он отделяет дисковое оборудование от интерфейса блочного устройства и работает с данными таким образом, что в результате повышается гибкость, производительность и надёжность по сравнению с традиционным взглядом на дисковое хранилище как на кусок дискового пространства. vinum(8) реализует модели RAID-0, RAID-1 и RAID-5, как по отдельности, так и в комбинациях.

Обратитесь к Гл. 19 для получения более полной информации о vinum(8).
^

17.4.2. Аппаратный RAID


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

При помощи встроенной в адаптер BIOS, он сам управляет большинством дисковых операций. Далее следует краткое описание установки при помощи контроллера Promise IDE RAID. После установки адаптера и запуска системы, выдаётся запрос на ввод. Следуйте указаниям для входа в настройку адаптера. Отсюда вы можете объединить все подключенные диски. После этого во FreeBSD диск(и) будут выглядеть как один диск. Аналогично могут быть настроены и другие уровни RAID.
^

17.4.3. Перестроение массивов ATA RAID1


FreeBSD позволяет вам выполнять горячую замену вышедшего из строя диска. При этом требуется, чтобы вы заметили это до перезагрузки.

Вероятно, в файле /var/log/messages или в выдаче команды dmesg(8) вы увидите примерно следующее:

ad6 on monster1 suffered a hard error.

ad6: READ command timeout tag=0 serv=0 - resetting

ad6: trying fallback to PIO mode

ata3: resetting devices .. done

ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11)\\

status=59 error=40

ar0: WARNING - mirror lost

При помощи atacontrol(8) получите дополнительную информацию:

# atacontrol list

ATA channel 0:

Master: no device present

Slave: acd0 ATA/ATAPI rev 0


ATA channel 1:

Master: no device present

Slave: no device present


ATA channel 2:

Master: ad4 ATA/ATAPI rev 5

Slave: no device present


ATA channel 3:

Master: ad6 ATA/ATAPI rev 5

Slave: no device present


# atacontrol status ar0

ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED

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

# atacontrol detach ata3

2. Замените диск.

3. Повторно подключите канал дискового контроллера:

# atacontrol attach ata3

Master: ad6 ATA/ATAPI rev 5

Slave: no device present

4. Добавьте новый диск к массиву в качестве резервного:

# atacontrol addspare ar0 ad6

5. Перестройте массив:

# atacontrol rebuild ar0

6. Проверить состояние дел можно при помощи следующей команды:

# dmesg | tail -10

[выдача удалена]

ad6: removed from configuration

ad6: deleted from ar0 disk1

ad6: inserted into ar0 disk1 as spare


# atacontrol status ar0

ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed

7. Дождитесь завершения этой операции.
^

17.5. USB устройства хранения


Предоставил Marc Fonvieille.

Множество современных устройств хранения используют Universal Serial Bus (USB): жесткие диски, брелоки USB, CD-R приводы, и т.д. FreeBSD предоставляет поддержку этих устройств.

17.5.1. Настройка


Драйвер umass(4) предоставляет поддержку устройств хранения USB. Если вы используете GENERIC ядро, изменять что-либо в настройках не потребуется. Если вы используете настроенное ядро, убедитесь, что в файле настройки присутствуют следующие строки:

device scbus

device da

device pass

device uhci

device ohci

device usb

device umass

Для доступа к устройствам хранения USB драйвер umass(4) использует подсистему SCSI, ваши устройства USB будут видны системе как SCSI устройства. В зависимости от чипсета USB на материнской плате, вам потребуется только один из параметров device uhci или device ohci. Однако, наличие обоих этих параметров не помешает. Не забудьте скомпилировать и установить новое ядро после добавления каких-либо строк.

Замечание: Если ваше USB устройство это пишущий привод CD-R или DVD, необходимо добавить в ядро SCSI CD-ROM драйвер, cd(4), следующей строкой:

device cd

Поскольку устройство записи видно как SCSI диск, драйвер atapicam(4) не должен использоваться в файле настройки.

Поддержка USB 2.0 контроллеров предоставляется в FreeBSD 5.X, и в ветви 4.X с FreeBSD 4.10-RELEASE. Добавьте:

device ehci

в файл настройки ядра для поддержки USB 2.0. Обратите внимание, что драйверы uhci(4) и ohci(4) все еще нужны, если необходима поддержка USB 1.X.

Замечание: В FreeBSD 4.X, необходимо запустить USB даемона (usbd(8)), чтобы увидеть некоторые USB устройства. Для этого добавьте usbd_enable="YES" в файл /etc/rc.conf и перезагрузите компьютер.
^

17.5.2. Тестирование конфигурации


Конфигурация готова к тестированию, подключите устройство USB, и в буфере системных сообщений (dmesg(8)), диск должен отобразиться примерно так:

umass0: USB Solid state disk, rev 1.10/1.00, addr 2

GEOM: create disk da0 dp=0xc2d74850

da0 at umass-sim0 bus 0 target 0 lun 0

da0: Removable Direct Access SCSI-2 device

da0: 1.000MB/s transfers

da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C)

Конечно, производитель, имя устройства (da0) и другие детали могут отличаться в зависимости от конфигурации.

Поскольку устройство USB видится как SCSI, команда camcontrol может быть использована для вывода списка устройств хранения USB, подключенных к системе:

# camcontrol devlist

at scbus0 target 0 lun 0 (da0,pass0)

Если на диске есть файловая система, у вас должна быть возможность смонтировать ее. Разд. 17.3 поможет вам создать и отформатировать разделы на диске USB если потребуется.

Если вы отключите устройство (диск должен быть сначала размонтирован), вы должны увидеть в буфере системных сообщений что-то подобное:

umass0: at uhub0 port 1 (addr 2) disconnected

(da0:umass-sim0:0:0:0): lost device

(da0:umass-sim0:0:0:0): removing device entry

GEOM: destroy disk da0 dp=0xc2d74850

umass0: detached
^

17.5.3. Дополнительная информация


Помимо разделов Добавление дисков и Монтирование и размонтирование файловых систем, также может быть полезно чтение различных страниц справочника: umass(4), camcontrol(8), и usbdevs(8).
^

17.6. Запись и использование оптических носителей (CD)


Текст предоставил Mike Meyer.

17.6.1. Введение


Компакт-диски (CD) имеют несколько особенностей, отличающих их от обычных дисков. Во-первых, на них невозможно производить запись. Они спроектированы с расчетом на то, что их можно читать последовательно без задержек на перемещение головки между дорожками. К тому же их гораздо проще переносить от системы к системе, чем носители близкого объема.

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

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

Для создания файла данных, содержащего файловую систему ISO 9660, используется программа mkisofs(8), которая включена в порт sysutils/cdrtools. Она имеет опции, поддерживающие различные расширения, и описана ниже.

Какой инструмент использовать для записи CD, зависит от того, является ли ваше устройство для записи CD устройством ATAPI или каким-либо другим. С устройствами для записи стандарта ATAPI используется программа burncd, которая является частью комплекта поставки системы. С устройствами SCSI и USB нужно использовать cdrecord из порта sysutils/cdrtools. Утилиту cdrecord и другие инструменты для SCSI-приводов также можно использовать при работе с ATAPI-оборудованием через модуль ATAPI/CAM.

Если для записи CD вам нужна программа с графическим интерфейсом пользователя, взгляните на X-CD-Roast или K3b. Они доступны в виде пакетов или из портов sysutils/xcdroast и sysutils/k3b. Программам X-CD-Roast и K3b для работы с оборудованием ATAPI требуется модуль ATAPI/CAM.

17.6.2. mkisofs


Программа mkisofs(8), поставляемая с портом sysutils/cdrtools создаёт файловую систему ISO 9660, которая является образом дерева каталогов в пространстве имён файловой системы UNIX. В самом простом случае она используется так:

# mkisofs -o imagefile.iso /path/to/tree

Эта команда создаст файл imagefile.iso, содержащий файловую систему ISO 9660, которая является копией дерева каталогов /path/to/tree. Во время работы она будет преобразовывать имена файлов в имена, которые удовлетворяют ограничениям файловой системы ISO 9660, и исключит файлы, которые носят имена, неподходящие для файловой системы ISO.

Для того, чтобы обойти эти ограничения, имеется несколько опций. В частности, -R включает использование расширений Rock Ridge, распространенных в UNIX-системах, с -J будут применены расширения Joliet, используемые в системах от Microsoft, а -hfs может использоваться для создания файловых систем HFS, используемых в Mac OS.

Для CD, которые будут использоваться только с системами FreeBSD, может использоваться опция -U, отменяющая все ограничения на имена файлов. При использовании с опцией -R генерируется образ файловой системы, идентичный начальному дереву FreeBSD, хотя при этом стандарт ISO 9660 может нарушаться в нескольких местах.

Последней часто используемой опцией является -b. Она используется для указания загрузочного образа для использования при создании загрузочного CD в стандарте ''El Torito''. Этой опции указывается аргумент, который является маршрутом к загрузочному образу из корня дерева, записываемого на CD. По умолчанию, mkisofs(8) создает образ ISO в так называемом режиме ''эмуляции флоппи-диска'', и потому ожидает загрузочный образ размера строго 1200, 1440 или 2880 KB. Некоторые загрузчики, в том числе и тот, что используется на дистрибутивных дисках FreeBSD, не используют режим эмуляции; в этом случае должна использоваться опция -no-emul-boot. Так что, если /tmp/myboot содержит загрузочную систему FreeBSD с загрузочным образом в /tmp/myboot/boot/cdboot, вы можете создать образ файловой системы ISO 9660 в /tmp/bootable.iso следующим образом:

# mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot

Сделав это, и имея в ядре отконфигурированное устройство vn (для FreeBSD 4.X) или md (при использовании FreeBSD 5.X), вы можете смонтировать файловую систему, выполнив:

# vnconfig -e vn0c /tmp/bootable.iso

# mount -t cd9660 /dev/vn0c /mnt

в случае использования FreeBSD 4.X, а для FreeBSD 5.X:

# mdconfig -a -t vnode -f /tmp/bootable.iso -u 0

# mount -t cd9660 /dev/md0 /mnt

В этот момент вы можете проверить, что /mnt и /tmp/myboot идентичны.

Имеется много других опций, которые можно использовать с программой mkisofs(8) для тонкой настройки её поведения. В частности: модификации в размещении ISO 9660 и создание дисков в форматах Joliet и HFS. Обратитесь к справочным страницам по mkisofs(8) для получения более подробной информации.

17.6.3. burncd


Если ваше устройство для записи CD соответствует стандарту ATAPI, то для записи ISO-образа на компакт-диск вы можете воспользоваться командой burncd. burncd входит в базовый комплект операционной системы и установлена как /usr/sbin/burncd. Использовать её очень просто, так как параметров у ней немного:

# burncd -f cddevice data imagefile.iso fixate

По этой команде файл imagefile.iso будет скопирован на cddevice. По умолчанию используется устройство /dev/acd0 (или /dev/acd0c в FreeBSD 4.X). Для получения информации о параметрах, задающих скорость записи, выброс диска после записи и запись звуковых данных, обратитесь к burncd(8).

17.6.4. cdrecord


Если ваше устройство для записи CD не соответствует стандарту ATAPI, то для записи компакт-дисков вам нужно пользоваться программой cdrecord. cdrecord не входит в комплект поставки системы; вы должны установить её из порта sysutils/cdrtools или из соответствующего пакета. Изменения в системе могут приводить к тому, что откомпилированные версии этой программы работать не будут, или приводить к порче дисков. Поэтому вы должны при обновлении системы либо обновить порт, либо, если вы следуете -STABLE, обновить порт при появлении его новой версии.

Хотя cdrecord имеет много опций, в основном использовать её ещё проще, чем burncd. Запись образа ISO 9660 делается такой командой:

# cdrecord dev=device imagefile.iso

Тонким моментом при использовании cdrecord является определение правильного устройства dev. Чтобы задать параметр правильно, воспользуйтесь флагом -scanbus команды cdrecord, в результате чего может получиться примерно такой результат:

# cdrecord -scanbus

Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jцrg Schilling

Using libscg version 'schily-0.1'

scsibus0:

0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk

0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk

0,2,0 2) *

0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk

0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM

0,5,0 5) *

0,6,0 6) *

0,7,0 7) *

scsibus1:

1,0,0 100) *

1,1,0 101) *

1,2,0 102) *

1,3,0 103) *

1,4,0 104) *

1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM

1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner

1,7,0 107) *

Здесь приведены соответствующие значения параметров dev для имеющихся устройств. Найдите здесь ваше устройство для записи CD, а в качестве параметров для dev задавайте три числа через запятые. В нашем случае CRW-устройству соответствуют числа 1,5,0, так что правильным параметром будет dev=1,5,0. Имеется более простой способ задать эти значения; обратитесь к справочной информации о cdrecord(1) для выяснения подробностей. Там же находится информация о записи звуковых дорожек, управлении скоростью и другим вещам.
^

17.6.5. Копирование аудио CD


Вы можете копировать музыкальные CD, извлекая данные аудио с CD в набор файлов, а затем записывая эти файлы на чистый CD. Процесс несколько различен в случаях использования устройств ATAPI и SCSI.

^ Устройства SCSI

1. Используйте cdda2wav для извлечения данных аудио.

% cdda2wav -v255 -D2,0 -B -Owav

2. Воспользуйтесь cdrecord для записи файлов .wav.

% cdrecord -v dev=2,0 -dao -useinfo *.wav

Значение, соответствующее 2,0, должно быть установлено правильно, как это описано в Разд. 17.6.4.

Устройства ATAPI

1. Драйвер устройств ATAPI CD делает каждую дорожку доступной как /dev/acddtnn, где d является номером привода, а nn соответствует номеру дорожки, который записывается двумя десятичными цифрами с нулём в начале, если это нужно. Таким образом, первая дорожка на первом диске будет носить имя /dev/acd0t01, вторая будет именоваться /dev/acd0t02, третья будет носить имя /dev/acd0t03 и так далее.

Удостоверьтесь, что соответствующий файл имеется в каталоге /dev. При его отсутствии следует принудительно перечитать оглавление диска:

# dd if=/dev/acd0 of=/dev/null count=1

Замечание: В версиях FreeBSD 4.X номера треков не предваряются нулем. В случае отсутствия нужных файлов устройств, создайте их при помощи команды MAKEDEV:

# cd /dev

# sh MAKEDEV acd0t99

2. Извлеките каждую дорожку при помощи команды dd(1). При извлечении файлов вы должны также использовать специфическое значение для размера блока.

# dd if=/dev/acd0t01 of=track1.cdr bs=2352

# dd if=/dev/acd0t02 of=track2.cdr bs=2352

...

3. Запишите извлечённые файлы на диск при помощи утилиты burncd. Вы должны указать, что это файлы с аудио, и что burncd должна зафиксировать диск по окончании работы.

# burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate
^

17.6.6. Копирование компакт-дисков с данными


Вы можете скопировать CD с данными в файл образа, который функционально эквивалентен файлу образа, созданному командой mkisofs(8), и вы можете использовать его для копирования любого CD с данными. В приводимом здесь примере предполагается, что ваш привод CDROM называется acd0. Подставьте название вашего привода CDROM. В FreeBSD 4.X к имени устройства должен быть добавлен символ c для указания на то, что берётся весь раздел, а в случае CDROM, весь диск.

# dd if=/dev/acd0 of=file.iso bs=2048

Теперь, когда вы имеете образ, вы можете записать его на CD так, как это описано выше.
^

17.6.7. Использование компакт-диски с данными


Теперь, после того, как вы создали стандартный CDROM с данными, вы, наверное, захотите смонтировать его и считать с него данные. По умолчанию mount(8) предполагает, что файловая система имеет тип ufs. Если вы попытаетесь выполнить что-то вроде:

# mount /dev/cd0 /mnt

вы получите сообщение Incorrect super block, и диск не смонтируется. CDROM не является файловой системой UFS, поэтому попытки смонтировать его таким образом будут терпеть неудачу. Вам просто нужно указать команде mount(8), что файловая система имеет тип ISO9660, и всё должно заработать. Сделайте это, задав параметр -t cd9660 при вызове mount(8). К примеру, если вы хотите смонтировать устройство CDROM, /dev/cd0, в каталог /mnt, вы должны выполнить:

# mount -t cd9660 /dev/cd0 /mnt

Заметьте, что имя вашего устройства (/dev/cd0 в этом примере) может быть другим, в зависимости от интерфейса, используемого в CDROM. Кроме того, параметр -t cd9660 всего лишь задаёт выполнение утилиты mount_cd9660(8). Пример выше может быть упрощён до:

# mount_cd9660 /dev/cd0c /mnt

Таким способом, вообще говоря, вы можете использовать компакт-диски любого производителя. Диски с некоторыми расширениями ISO 9660 могут, однако, работать со странностями. К примеру диски Joliet хранят все имена файлов в виде последовательностей двухбайтовых символов Unicode. Ядро FreeBSD (пока ещё) не может работать с Unicode, поэтому не английские символы выводятся в виде знаков вопроса. (Если в работаете с FreeBSD 4.3 или более поздней версией, то в драйвере CD9660 имеется механизм для динамической загрузки соответствующей таблицы преобразования Unicode. Модули для некоторых распространённых кодировок могут быть получены из порта sysutils/cd9660_unicode.)

Время от времени вы можете получать сообщения Device not configured при попытке смонтировать CDROM. Это обычно означает, что привод CDROM полагает, что в нём нет диска, или что привод не виден на шине. Приводу CDROM может понадобиться несколько секунд, чтобы понять, что он был закрыт, так что будьте терпеливы.

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

options SCSI_DELAY=15000

Это укажет вашей шине SCSI выдерживать 15-секундную паузу во время загрузки, чтобы дать вашему приводу CDROM шанс ответить на сброс шины.
^

17.6.8. Запись необработанных данных на компакт-диски


Вы можете предпочесть запись файла непосредственно на CD без создания файловой системы ISO 9660. Некоторые поступают так при создании резервных копий. Это выполняется гораздо быстрее. чем запись стандартного компакт-диска:

# burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate

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

# tar xzvf /dev/acd1

Вы не можете монтировать этот диск как обычный CDROM. Такой компакт-диск не может быть прочитан ни в какой другой операционной системе, кроме FreeBSD. Если вы хотите монтировать CD или обменяться данными с другой операционной системой, то вы должны использовать mkisofs(8) так, как это было описано выше.
^

17.6.9. Использование драйвера ATAPI/CAM


Предоставил Marc Fonvieille.

Этот драйвер позволяет работать с ATAPI-устройствами (приводы CD-ROM, CD-RW, DVD и так далее) через подсистему SCSI, таким образом расширяя использование таких приложений, как sysutils/cdrdao или cdrecord(1).

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

device atapicam

Кроме того, в файле конфигурации ядра должны быть следующие строки:

device ata

device scbus

device cd

device pass

которые уже должны там присутствовать.

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

acd0: CD-RW at ata1-master PIO4

cd0 at ata1 bus 0 target 0 lun 0

cd0: Removable CD-ROM SCSI-0 device

cd0: 16.000MB/s transfers

cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed

Теперь с ним можно работать через устройство /dev/cd0, например, чтобы смонтировать CD-ROM в каталог /mnt, просто наберите следующую команду:

# mount -t cd9660 /dev/cd0 /mnt

Для получения SCSI-адреса пишущего привода, вы можете, работая как пользователь root, запустить такую команду:

# camcontrol devlist

at scbus1 target 0 lun 0 (pass0,cd0)

Таким образом, 1,0,0 будет SCSI-адресом для использования с cdrecord(1) и другими приложениями для работы со SCSI.

Для получения дополнительной информации об ATAPI/CAM и системе SCSI, обратитесь к страницам справочной системы по atapicam(4) и cam(4).
^

17.7. Создание и использование оптических носителей (DVD)


Предоставил Marc Fonvieille. Дополнения предоставил Andy Polyakov.

17.7.1. Введение


DVD это следующее после CD поколение оптических носителей. DVD может вмещать больше данных чем любой CD и является современным стандартом распространения видео.

Для записываемых DVD существует пять физических форматов записи:

• DVD-R: Был первым форматом записываемых DVD. Стандарт DVD-R был создан DVD Forum (http://www.dvdforum.com/forum.shtml). Это формат для однократной записи.

• DVD-RW: Это перезаписываемая версия стандарта DVD-R. Носители DVD-RW могут быть перезаписаны около 1000 раз.

• DVD-RAM: Это также перезаписываемый формат, поддерживаемый DVD Forum. DVD-RAM может быть виден как съемный жесткий диск. Однако, этот носитель не совместим с большинством приводов DVD-ROM и проигрывателями DVD-Video; лишь некоторые пишущие DVD поддерживают формат DVD-RAM. Более подробно о работе с DVD-RAM можно прочитать в разделе Разд. 17.7.9.

• DVD+RW: Это перезаписываемый формат, созданный DVD+RW Alliance (http://www.dvdrw.com/). Носитель DVD+RW может быть перезаписан около 1000 раз.

• DVD+R: Этот формат — однократно записываемая версия формата DVD+RW.

Однослойный записываемый DVD может хранить до 4,700,000,000 байт, что равно 4.38 Гбайт, или 4485 Мбайт (1 килобайт это 1024 байт).

Замечание: Необходимо различать физический носитель и приложение. Например, DVD-Video это определенная файловая раскладка, которая может быть помещена на записываемый DVD любого физического формата: DVD-R, DVD+R, DVD-RW и т.д. Перед выбором типа носителя вы должны убедиться, что и устройство записи и DVD-Video проигрыватель (отдельный или DVD-ROM привод компьютера) совместимы с данным носителем.

17.7.2. Настройка


Для записи DVD будет использоваться программа growisofs(1). Эта команда входит в набор утилит dvd+rw-tools (sysutils/dvd+rw-tools), который поддерживает все типы носителей DVD.

Эти утилиты используют подсистему SCSI для доступа к устройствам, следовательно необходимо добавить в ядро поддержку ATAPI/CAM. Если пишущий привод использует USB интерфейс, это добавление бесполезно и необходимо прочесть более подробную информацию по настройке устройств USB в Разд. 17.5

Вам также потребуется включить DMA доступ для устройств ATAPI, это можно сделать добавив в /boot/loader.conf следующую строку:

hw.ata.atapi_dma="1"

Перед использованием dvd+rw-tools вы должны свериться со списком совместимого оборудования dvd+rw-tools (http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html) с информацией по устройствам для записи DVD.

Замечание: Если вам нужен графический интерфейс пользователя, взгляните на K3b (sysutils/k3b), который предоставляет дружественный пользователю интерфейс к growisofs(1) и многим другим программам записи.
^

17.7.3. Запись DVD с данными


Команда growisofs(1) является оболочкой для mkisofs, она вызовет mkisofs(8) для создания файловой системы и запишет DVD. Это означает, что вам не потребуется создавать образ с данными перед началом процесса записи.

Для записи данных из каталога /path/to/data на DVD+R или DVD-R, используйте следующую команду:

# growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data

Параметры -J -R передаются mkisofs(8) для создания файловой системы (в данном случае: файловая система ISO 9660 с расширениями Joliet и Rock Ridge), обратитесь к странице справочника mkisofs(8) за более подробной информацией.

Параметр -Z используется для первой сессии записи в любом случае: для одной или нескольких сессий. Устройство DVD, /dev/cd0, должно быть изменено в соответствии с имеющимися настройками. Параметр -dvd-compat закроет диск и дозапись станет невозможна. Это должно улучшить совместимость с приводами DVD-ROM.

Возможна также запись предварительного (pre-mastered) образа, например, для записи imagefile.iso запустим:

# growisofs -dvd-compat -Z /dev/cd0=imagefile.iso

Скорость записи должна быть определена и автоматически установлена в соответствии с носителем и приводом. Если вы хотите явно указать скорость записи, используйте параметр -speed=. За дальнейшей информацией обратитесь к странице справочника growisofs(1).
^

17.7.4. Запись DVD-Video


DVD-Video это особая файловая система, базирующаяся на ISO 9660 и спецификациях micro-UDF (M-UDF). DVD-Video также представляет определенную иерархию структуры данных, поэтому для создания DVD потребуется особая программа, такая как multimedia/dvdauthor.

Если у вас уже есть образ файловой системы DVD-Video, просто запишите его как любой другой образ, примеры находятся в предыдущем разделе. Если вы создали DVD и результат находится в каталоге /path/to/video, для записи DVD-Video должна быть использована следующая команда:

# growisofs -Z /dev/cd0 -dvd-video /path/to/video

Параметр -dvd-video будет передан mkisofs(8) и укажет создать файловую систему DVD-Video. Помимо этого, параметр -dvd-video подразумевает параметр growisofs(1) -dvd-compat.
^

17.7.5. Использование DVD+RW


В отличие от CD-RW, новый DVD+RW необходимо отформатировать перед первым использованием. Программа growisofs(1) позаботится об этом сама при необходимости, и это рекомендованный способ. Тем не менее, для форматирования DVD+RW вы можете использовать команду dvd+rw-format:

# dvd+rw-format /dev/cd0

Эту операцию необходимо выполнить лишь однажды, помните, что только новые носители DVD+RW необходимо форматировать. Затем запишите DVD+RW тем способом, который описан в предыдущем разделе.

Если вы хотите записать новые данные (полностью новую файловую систему, а не дописать данные) на DVD+RW, его не нужно очищать, просто запишите поверх предыдущей записи (создав новую начальную сессию) примерно так :

# growisofs -Z /dev/cd0 -J -R /path/to/newdata

Формат DVD+RW делает возможным легко дописать данные к предыдущей записи. Операция состоит в присоединении предыдущей сессии к существующей, это не мультисессионная запись, growisofs(1) расширит (grow) файловую систему ISO 9660, существующую на носителе.

Например, для дозаписи данных к предыдущей сессии на DVD+RW, используется следующая команда:

# growisofs -M /dev/cd0 -J -R /path/to/nextdata

При последующих записях mkisofs(8) необходимо передавать те же параметры, что и при первой записи.

Замечание: Вы можете использовать параметр -dvd-compat для улучшения совместимости с приводами DVD-ROM. В случае DVD+RW это не помешает добавлению данных.

Если по какой-либо причине вам потребуется очистить носитель, используйте следующую команду:

# growisofs -Z /dev/cd0=/dev/zero
^

17.7.6. Использование DVD-RW


Существует два формата дисков DVD-RW: последовательно дополняемый и с ограниченной перезаписью. По умолчанию формат дисков DVD-RW последовательный.

Новый DVD-RW может быть записан непосредственно без необходимости форматирования, однако DVD-RW с данными в последовательном формате необходимо очистить перед созданием новой начальной сессии.

Для очистки DVD-RW в последовательном формате, запустите:

# dvd+rw-format -blank=full /dev/cd0

Замечание: Полная очистка (-blank=full) займет около одного часа на скорости 1x. Быструю очистку можно выполнить с параметром -blank, если DVD-RW будет записан в режиме Disk-At-Once (DAO). Для записи DVD-RW в режиме DAO, используйте команду:

# growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso

Параметр -use-the-force-luke=dao не должен потребоваться, поскольку growisofs(1) попытается определить был ли носитель быстро очищен и включить DAO запись.

Фактически, лучше использовать режим с ограниченной перезаписью с любым DVD-RW, этот формат более гибкий, чем формат по умолчанию с последовательной записью.

Для записи данных на последовательный DVD-RW, используйте ту же команду, что и для других форматов DVD:

# growisofs -Z /dev/cd0 -J -R /path/to/data

Если вы хотите добавить данные к предыдущей записи, используйте параметр growisofs(1) -M. Однако при добавлении данных на DVD-RW в последовательном режиме, на диске будет создана новая сессия и в результате получится мультисессионный диск.

В формате DVD-RW с ограниченной перезаписью не требуется очищать носитель перед созданием новой начальной сессии, вам всего лишь нужно переписать диск с параметром -Z, подобно DVD+RW. Возможно также увеличение существующей файловой системы ISO 9660, записанной на диск тем же способом, как для DVD+RW с параметром -M. В результате получится односессионный DVD.

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

# dvd+rw-format /dev/cd0

Для перевода обратно в последовательный формат, выполните:

# dvd+rw-format -blank=full /dev/cd0

17.7.7. Мультисессия


Лишь несколько DVD-ROM и проигрывателей поддерживают мультисессионные DVD, в основном они в лучшем случае прочтут только первую сессию. DVD+R, DVD-R и DVD-RW в последовательном формате могут работать с несколькими сессиями, и это не относится к форматам DVD+RW и DVD-RW в формате ограниченной перезаписи.

Использование следующей команды после первой (не закрытой) сессии для DVD+R, DVD-R, или DVD-RW в последовательном формате, добавит на диск новую сессию:

# growisofs -M /dev/cd0 -J -R /path/to/nextdata

Использование этой командной строки с DVD+RW или DVD-RW в режиме ограниченной перезаписи добавит данные, объединив новую сессию с предыдущей. В результате получится односессионный диск. Такой способ используется для добавления данных после первой записи на эти носители.

Замечание: Некоторый объем носителя используется между сессиями для завершения и начала сессии. Следовательно, для оптимизации объема хранения сессии должны быть большими. Количество сессий ограничено 154 для DVD+R, около 2000 для DVD-R и 127 для DVD+R Double Layer.
^

17.7.8. Дополнительная информация


Для получения дополнительной информации о DVD, можно запустить команду dvd+rw-mediainfo /dev/cd0, диск должен находиться в приводе.

Дополнительная информация о dvd+rw-tools может быть найдена на странице справочника growisofs(1), на Web-сайте dvd+rw-tools (http://fy.chalmers.se/~appro/linux/DVD+RW/) и в архивах списка рассылки cdwrite (http://lists.debian.org/cdwrite/).

Замечание: Вывод dvd+rw-mediainfo при записи или проблемный носитель необходимы для любого сообщения о проблеме. Без этого вывода будет совершенно невозможно помочь вам.
^

17.7.9. Использование DVD-RAM

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

Записывающие устройства DVD-RAM поставляются с интерфейсами SCSI и ATAPI. В последнем случае вы должны убедиться, что для них включен режим DMA, добавив в файл /boot/loader.conf строку

hw.ata.atapi_dma="1"
^
17.7.9.2. Подготовка носителя

Как указывалось ранее, DVD-RAM представляется съемным жестким диском. Как и другие дисковые устройства, DVD-RAM должет быть ''подготовлен'' к первому использованию. В нашем примере мы займём все пространство диска одной файловой системой UFS2.

Убедившись, что носитель находится в приводе, выполните от имени пользователя root команды

# dd if=/dev/zero of=/dev/acd0 count=2

# disklabel -Bw acd0

# newfs /dev/acd0

Имя устройства DVD device, acd0, должно соответствовать вашей конфигурации.
^
17.7.9.3. Использование носителя

После выполнения указанных выше команд, DVD-RAM может быть смонтирован как обычный жесткий диск:

# mount /dev/acd0 /mnt

После этого вы можете читать и писать на DVD-RAM.

17.8. Дискеты


Первоначальный текст предоставил Julio Merino. Переписал Martin Karlsson.

Хранение данных на дискетах иногда бывает полезным, например, когда нет других съёмных носителей или когда необходимо перенести небольшой объём данных на другой компьютер.

В этом разделе будет описано, как использовать дискеты во FreeBSD. В основном речь пойдёт о форматировании и использовании дискет DOS размером 3.5 дюйма, однако общие принципы применимы и для других форматов гибких дисков.
^

17.8.1. Форматирование дискет

17.8.1.1. Устройство

Доступ к гибким дискам, как, впрочем, и к остальным устройствам, осуществляется через соответствующие файлы в каталога /dev. Чтобы обратиться к дискете при использовании релизов 4.X и ранее, необходимо работать с /dev/fdN, где N обозначает номер привода, обычно 0, или /dev/fdNX, где X обозначает букву.

В 5.0 и более новых релизах просто используйте /dev/fdN.
17.8.1.1.1. Размер диска в 4.X и более ранних релизах

Имеются также устройства /dev/fdN.size, где size обозначает размер дискеты в килобайтах. Эти файлы устройств используются во время низкоуровневого форматирования для задания размера устройства. В последующих примерах будет использоваться размер в 1440kB.

Иногда записи в каталоге /dev необходимо создавать повторно. Для этого выполните следующее:

# cd /dev && ./MAKEDEV "fd*"
17.8.1.1.2. Размер диска в 5.0 и последующих релизах

В 5.0 devfs(5) управляет файлами устройств в каталоге /dev в автоматическом режиме, так что использование MAKEDEV необязательно.

Требуемый размер диска передаётся утилите fdformat(1) при помощи параметра -f. Поддерживаемые размеры перечислены в fdcontrol(8), но, по нашему мнению, лучше всего работает 1440kB.
17.8.1.2. Форматирование

Перед тем, как дискетой можно будет воспользоваться, её необходимо отформатировать на низком уровне. Обычно это выполняется производителем, однако форматирование является хорошим способом проверить целостность носителя. Большинство гибких дисков предназначены для использования с размером 1440kB, однако возможно задать меньший или больший размер.

Для низкоуровневого форматирования дискет вам нужно использовать fdformat(1). В качестве параметра этой утилите передаётся имя устройства.

Обратите внимание на появление сообщений об ошибках, так как они могут помочь определить, хорошая это дискета или плохая.
17.8.1.2.1. Форматирование в 4.X и более ранних релизах

Для форматирования дискет используйте устройства /dev/fdN.size. Вставьте новую 3.5-дюймовую дискету в дисковод и введите команду:

# /usr/sbin/fdformat /dev/fd0.1440
17.8.1.2.2. Форматирование в 5.0 и более новых релизах

Для форматирования гибких дисков используйте устройства /dev/fdN. Вставьте новую 3.5-дюймовую дискету в дисковод и введите команду:

# /usr/sbin/fdformat -f 1440 /dev/fd0
^

17.8.2. Метка диска


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

Новая метка диска будет касаться диска в целом, и будет содержать полную информацию о параметрах дискеты. Значения геометрии для метки диска перечислены в файле /etc/disktab.

Теперь вы можете запустить disklabel(8) примерно так:

# /sbin/disklabel -B -r -w /dev/fd0 fd1440

Замечание: Начиная с FreeBSD 5.1-RELEASE, на смену старой программе disklabel(8) пришла утилита bsdlabel(8). У bsdlabel(8) отсутствуют некоторые устаревшие опции и параметры; в примере выше параметр -r не может использоваться с bsdlabel(8). Для получения дополнительной информации обратитесь к справочной странице п о bsdlabel(8).
^

17.8.3. Файловая система


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

Файловой системой для дискеты может служить UFS или FAT. Вообще говоря, FAT для дискет походит лучше.

Для размещения на дискете новой файловой системы, выполните:

# /sbin/newfs_msdos /dev/fd0

Теперь диск готов к работе.
^

17.8.4. Использование дискет


Для работы с гибким диском смонтируйте его при помощи утилит mount_msdos(8) (для 4.X и более ранних релизов) или mount_msdosfs(8) (в 5.0 и последующих релизах). Можно также использовать пакет emulators/mtools из коллекции портов.
^

17.9. Создание и использование архивных копий на магнитной ленте


К наиболее часто используемым носителям на магнитной ленте следует отнести ленты шириной 4мм и 8мм, а также типа QIC, мини-картриджи и DLT.
^

17.9.1. 4мм (DDS: Digital Data Storage)


Ленты шириной 4мм заменяют QIC в качестве наиболее предпочтительного носителя для создания резервных копий. Эта тенденция значительно усилилась после покупки компанией Conner фирмы Archive, ведущего производителя накопителей QIC и последующего прекращения их выпуска. Накопители 4мм малы по размеру и мало шумят, но у них нет репутации носителя, обладающего надежностью приводов 8мм. Картриджи более дешевы и меньше по размеру (3 x 2 x 0.5 дюймов, 76 x 51 x 12 мм), чем 8мм-картриджи. Накопители для лент шириной 4мм, как и 8мм, имеют сравнительно малый срок службы головок, по причине использования в обоих случаях технологии спирального сканирования (helical scan).

Пропускная способность у таких накопителей начинается с цифры ~150 kB/s, пиковая достигает ~500 kB/s. Ёмкость накопителей начинается с 1.3 GB и может достигать 2.0 GB. Аппаратное сжатие, имеющееся на большинстве таких накопителей, даёт увеличение ёмкости примерно вдвое. Блоки многоприводных ленточных библиотек могут иметь до 6 накопителей в одном модуле с автоматической сменой ленты. Ёмкость библиотек может достигать 240 Гбайт.

Стандарт DDS-3 в настоящее время поддерживает ёмкости лент вплоть до 12 Гбайт (или 24 Гбайт сжатой информации).

В накопителях 4мм, как и в приводах 8мм, используется технология спирального сканирования. Все плюсы и минусы этой технологии относятся как к 4мм, так и 8мм приводам.

Не следует использовать ленты после того, как они были подвергнуты 2000 проходов, или были использованы для создания 100 полных копий.
^

17.9.2. 8мм (Exabyte)


Ленты шириной 8мм являются самым распространённым типом для ленточных SCSI-накопителей; они же являются наиболее удачным выбором при выборе типа носителей для обмена лентами. Наверное, каждый сервер имеет привод Exabyte шириной 8мм и объёмом 2 Гбайт. Эти приводы удобны, они работают надёжно и тихо. Картриджи дешевы и малы по размеру (4.8 x 3.3 x 0.6 дюймов; 122 x 84 x 15 мм). Одним минусом лент шириной 8мм является сравнительно малое время службы головок и лент из-за высокой скорости движения ленты вдоль головок.

Скорость передачи данных варьируется от ~250 kB/s до ~500 kB/s. Объём хранимых данных начинается с 300 Мбайт и может достигать 7 Гбайт. Аппаратное сжатие, имеющееся практически на всех таких приводах, увеличивает емкость примерно вдвое. Эти приводы существуют как в виде отдельных модулей, так и в виде многоприводных ленточных библиотек с 6 приводами и 120 лентами в одном отсеке. Ленты сменяются автоматически модулем. Емкости библиотек достигают величин, превышающих 840 Гбайт.

Модель Exabyte ''Mammoth'' поддерживает ёмкость ленты в 12 Гбайт (24 Гбайт со сжатием) и стоит примерно вдвое больше, чем обычный ленточный накопитель.

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

17.9.3. QIC


Ленты и накопители формата QIC-150, наверное, являются наиболее распространенным типом носителей. Приводы лент формата QIC являются самыми дешёвыми ''серьёзными'' накопителями для резервного копирования. Минусом является стоимость носителей. Ленты формата QIC по сравнению с лентами шириной 8мм или 4мм являются дорогими, превосходя их по стоимости хранения одного гигабайта в пять раз. Однако если вам будут достаточно половины ленты, QIC может оказаться правильным выбором. QIC является самым распространенным типом привода. Каждый сайт имеет привод QIC какой-либо емкости. QIC имеет большое количество плотностей на физически похожих (иногда даже идентичных) лентах. Приводы QIC работают вовсе не тихо. Эти накопители громко осуществляют поиск перед тем, как начать запись данных и достаточно шумны в процессе чтения, записи или поиска. Ленты QIC имеют размеры (6 x 4 x 0.7 дюймов; 152 x 102 x 17 мм).

Скорость обмена данными лежит в границах от ~150 kB/s до ~500 kB/s. Ёмкость накопителей варьируется от 40 Мбайт до 15 Гбайт. Аппаратное сжатие присутствует во многих современных накопителях QIC. Приводы QIC устанавливаются менее часто; они вытесняются накопителями DAT.

На ленту данные записываются в виде дорожек. Дорожки располагаются в длину вдоль всей ленты. Количество дорожек, и, в свою очередь, их ширина, меняется вместе с емкостью ленты. Большинство, если не все современные накопители обеспечивают обратную совместимость по крайней мере для чтения (однако зачастую и для режима записи). Формат QIC имеет хорошую репутацию в области надежности хранения данных (механика устроена проще и более надежна, чем в случае накопителей, построенных по технологии спирального сканирования).

Ленты не следует больше использовать после создания 5,000 резервных копий.

17.9.4. DLT


Формат DLT обладает самой высокой скоростью передачи данных среди всех перечисленных здесь накопителей. Лента шириной 1/2" (12.5мм) помещена в один картридж с катушкой (4 x 4 x 1 дюймов; 100 x 100 x 25 мм). Вдоль одной из сторон картриджа расположена сдвигающаяся крышечка. Механизм накопителя открывает эту крышку, чтобы вытащить конец ленты. На этом конце имеется овальное отверстие, которое используется для ''захвата'' ленты. Принимающая катушка размещена внутри накопителя. Все другие типы картриджей, перечисленные здесь (за исключением 9-дорожечных лент), имеют как подающий, так и принимающий барабаны внутри самого картриджа.

Скорость передачи данных равна примерно 1.5 MB/s, что в три раза больше скорости передачи данных для накопителей 4мм, 8мм или QIC. Ёмкость картриджей варьируется от 10 Гбайт до 20 Гбайт для одного накопителя. Приводы могут компоноваться как многоленточные роботизированные, так и многоленточные, многоприводные библиотеки лент, вмещающие от 5 до 900 лент и от 1 до 20 приводов, что даёт ёмкость хранилища от 50 Гбайт до 9 Тбайт.

Формат DLT Type IV поддерживает емкость до 70 Гбайт со сжатием.

Данные на ленту записываются в виде дорожек, параллельных направлению движения (точно также, как и для лент QIC). Одновременно записываются две дорожки. Срок жизни головок чтения/записи сравнительно велик; как только лента перестает двигаться, одновременно прекращается трение между головками и лентой.

17.9.5. AIT


AIT - это новый формат фирмы Sony, который позволяет хранить до 50 Гбайт (со сжатием) информации на одной ленте. Ленты содержат микросхемы памяти, на которых размещается каталог содержимого ленты. Этот каталог может быть быстро считан накопителем для определения расположения файлов на ленте, вместо того, чтобы тратить несколько минут на поиск, как это происходит с другими форматами. Такое программное обеспечение, как SAMS:Alexandria, может управлять сорока или большим количеством ленточных библиотек AIT, связываясь непосредственно с памятью лент для вывода их содержимого, определения того, какие файлы были скопированы на какую ленту, выбора нужной ленты, её загрузки и восстановления данных с ленты.

Библиотеки с такими функциями стоят в районе $20,000, выводя их из ниши любительского рынка.
^

17.9.6. Использование новой ленты первый раз


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

sa0(ncr1:4:0): NOT READY asc:4,1

sa0(ncr1:4:0): Logical unit is in process of becoming ready

На ленте отсутствует идентификационный блок (блок номер 0). Со времен принятия стандарта QIC-525 все накопители формата QIC записывают на ленту идентификационный блок (Identifier Block). Здесь имеется два решения:

• По команде mt fsf 1 ленточный накопитель записывает идентификационный блок на ленту.

• Воспользуйтесь кнопкой на передней панели для выброса ленты.

Вставьте ленту повторно и по команде dump сбросьте данные на ленту.

Программа dump выдаст DUMP: End of tape detected, а на консоли будет выведено: HARDWARE FAILURE info:280 asc:80,96.

перемотайте ленту такой командой: mt rewind.

Последующие операции с лентой будут успешными.
^

17.10. Создание резервных копий на дискетах

17.10.1. Можно ли использовать дискеты для создания резервных копий моих данных?


На самом деле дискеты не подходят для создания резервных копий, потому что:

• Носитель ненадёжен, особенно если речь идет о больших сроках хранения.

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

• Дискеты имеют весьма ограниченную емкость (дни, когда весь винчестер копировался на десяток или около того дискет, давно прошли).

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

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

17.10.2. Итак, как же сделать резервную копию данных на дискетах?


Самым лучшим методом создания резервной копии на дискете является использование утилиты tar(1) с опцией -M (многотомные архивы), которая позволяет размещать архивы на нескольких дискетах.

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

# tar Mcvf /dev/fd0 *

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

Prepare volume #2 for /dev/fd0 and hit return:

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

17.10.3. Можно ли резервные копии подвергнуть компрессии?


К сожалению, tar(1) при создании многотомных архивов не позволяет использовать опцию -z. Вы конечно же, можете скомпрессировать все файлы утилитой gzip(1), программой gzip(1) скопировать их на дискеты, а затем распаковать файлы снова утилитой gunzip(1)!
^

17.10.4. Как восстановить данные из моих резервных копий?


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

# tar Mxvf /dev/fd0

Есть два подхода к восстановлению только нужных вам файлов. В первом вы можете начать с первой дискеты и выдать такую команду:

# tar Mxvf /dev/fd0 filename

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

Как альтернатива, если вы знаете, на какой дискете расположен файл, то вы можете просто подать ее и дать ту же самую команду, что и выше. Заметьте, что если первый файл на дискете является продолжением предыдущего, то tar(1) выдаст предупреждение о том, что не может его восстановить, хотя вы этого и не просили делать!
^

17.11. Стратегии резервного копирования


Первоначально написаноLowell Gilbert.

При разработке плана резервного копирования первым делом надо продумать методы защиты от следующих проблем:

• Отказ жесткого диска

• Случайное удаление файлов

• Повреждение содержимого файлов

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

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

Вот несколько наиболее распространенных технологий, применяемых для резервного копирования:

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

• Снэпшоты файловых систем. Помогают только от случайного удаления файлов, но как раз в этом случае очень полезны и эффективны.

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

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

• Проверка отпечатков файлов (fingerprints). Для этого весьма полезна утилита mtree(8). Не являясь собственно технологией резервного копирования, этот метод помогает выяснять, когда вам пока обращаться к резервным копиям. В особенности это важно для "оффлайновых" резервных копий.

Довольно легко придумать и другие стратегии резервного копирования; многие из них будут композициями уже упомянутых. Наличие специальных требований, как правило, приводит к специализированным же технологиям (например, резервное копирование базы данных, как правило, требует использования методов, специфичных для соответствующей СУБД). Главным остается знание опасностей потери данных, от которых вы хотите себя оградить, и методов защиты от них.
^

17.12. Основы технологии резервного копирования


Тремя основными программами резервного копирования являются dump(8), tar(1) и cpio(1).

17.12.1. Dump и Restore


Для UNIX традиционными программами резервного копирования являются dump и restore. Они работают с приводом как с набором дисковых блоков, которые расположены ниже понятий файлов, связей и каталогов, создаваемых файловыми системами. Программа dump выполняет резервное копирование всей файловой системы, располагающейся на устройстве. Невозможно выполнить резервное копирование части файловой системы или дерева каталогов, которые располагаются более чем в одной файловой системе. Утилита dump не записывает на ленту файлы и каталоги, она записывает блоки данных, из которых строятся файлы и каталоги.

Замечание: Если вы используете программу dump для работы с корневым каталогом, при этом не будет выполняться резервное копирование /home, /usr и многих других каталогов, так как они обычно являются точками монтирования других файловых систем или символическими ссылками на эти файловые системы.

В программе dump имеются некоторые неудобства, оставшиеся от её ранних дней в составе Version 6 операционной системы AT&T UNIX (примерно 1975). Параметры, используемые по умолчанию, подходят для 9-дорожечных лент (6250 bpi), но не для современных носителей с высокой плотностью записи информации (до 62,182 ftpi). Для использования ёмкостей нынешних накопителей на магнитной ленте эти параметры могут быть заданы в командной строке.

При помощи rdump и rrestore возможно резервное копирование данных по сети на накопитель, подключенный к другому компьютеру. Обе программы используют в работе rcmd(3) и ruserok(3) для доступа к накопителю на магнитной ленте на удалённом компьютере. Поэтому пользователь, выполняющий резервное копирование, должен быть указан в файле .rhosts на удалённом компьютере. Аргументы для rdump и rrestore должны подходить для использования на другом компьютере. При выполнении копирования по команде rdump на компьютере с FreeBSD на накопитель Exabyte, подключенный к машине Sun по имени komodo, используйте такую команду:

# /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1

Будьте осторожны: есть проблемы с обеспечением безопасности при аутентификации посредством .rhosts. Внимательно рассмотрите вашу ситуацию.

Программы dump и restore можно использовать в более защищённом режиме посредством ssh.

^ Пример 17-1. Использование dump через ssh

# /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \

targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz

Либо воспользуйтесь встроенной в dump возможностью, задав переменную окружения RSH:

Пример 17-2. Использование dump при работе через ssh с заданием RSH

# RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr

17.12.2. tar


Утилита tar(1) также восходит корнями к Version 6 системы AT&T UNIX (около 1975). tar работает с файловой системой, записывая на ленту файлы и каталоги. Эта утилита поддерживает не полный набор опций, имеющихся в cpio(1), однако не требует необычного перенаправления в командной строке, которое используется в утилите cpio.

FreeBSD начиная с версии 5.3 содержит как GNU tar, так и используемую по умолчанию утилиту bsdtar. Версия GNU вызывается командой gtar, и поддерживает удалённые устройства в том же самом синтаксисе, что и rdump. Чтобы скопировать данные на накопитель Exabyte, подключенный к машине Sun по имени komodo, используйте такую команду:

# /usr/bin/gtar cf komodo:/dev/nsa8 . 2>&1

Тот же результат вы можете получить, используя bsdtar, воспользовавшись перенаправлением вывода и командой rsh для посылки данных на удалённый ленточный накопитель.

# tar cf - . | rsh hostname dd of=tape-device obs=20b

Если вы беспокоитесь о безопасности создания резервных копий по сети, то вместо rsh вам нужно использовать ssh.

17.12.3. cpio


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

cpio не поддерживает создание резервных копий по сети. Вы можете воспользоваться перенаправлением вывода и программой rsh для посылки данных на удалённый накопитель.

# for f in directory_list; do

find $f >> backup.list

done

# cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device"

Где directory_list это список директорий, c которых Вы хотите создать резервные копии, user@host это комбинация пользователь/хост которая описывает того кто занимается резервированием, и backup_device это устройство куда копии должны быть записаны (например, /dev/nsa0).

17.12.4. pax


pax(1) является ответом IEEE/POSIX на утилиты tar и cpio. В течение многих лет различные версии программ tar и cpio получались не совсем совместимыми. Так что вместо того, чтобы попытаться полностью их стандартизировать, POSIX создал новую утилиту для работы с архивами. pax пытается читать и писать различные форматы cpio и tar, и, кроме того, свои собственные новые форматы. Набор команд этой утилиты больше напоминает cpio, чем tar.

17.12.5. Amanda


Amanda (Advanced Maryland Network Disk Archiver) является целой клиент/серверной системой резервного копирования, а не отдельной программой. Сервер Amanda сможет осуществлять резервное копирование на единственный накопитель любого количества компьютеров, на которых имеется клиент Amanda и которые могут связываться по сети с сервером Amanda. Общей проблемой систем с большим количеством больших дисков является то, что время, требуемое для непосредственной записи данных на ленту, превышает лимит времени, выделенный на эту задачу. Amanda решает эту проблему. Amanda может использовать ''промежуточный диск'' для резервного копирования нескольких файловых систем одновременно. Amanda создаёт ''наборы архивов'': группа лент, используемых в некоторый период времени для создания полных копий всех файловых систем, перечисленных в конфигурационном файле системы Amanda. ''Архивный набор'' содержит также создаваемый каждую ночь инкрементальные (или дифференциальные) резервные копии всех файловых систем. Восстановление повреждённой файловой системы требует наличия самой последней полной копии и инкрементальных резервных копий.

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

17.12.6. Не делать ничего


''Не делать ничего'' - это не программа для компьютера, и в то же время это наиболее широко используемая стратегия резервного копирования. Здесь нет никаких первоначальных затрат. Здесь нет расписания, которому нужно следовать. Просто скажите нет. Если что-то случится с вашими данными, улыбнитесь и забудьте о них!

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

''Ничего не делать'' является правильным методом резервного копирования для /usr/obj и других деревьев каталогов, которые могут быть в точности перегенерированы вашим компьютером. Примером являются файлы, представляющие страницы этого Руководства в форматах HTML или PostScript. Они генерируются из входных файлов в формате SGML. Создавать резервные копии файлов в форматах HTML и PostScript не нужно. Исходные файлы в формате SGML копируются регулярно.
^

17.12.7. Какая программа резервного копирования самая лучшая?


dump(8) Точка. Elizabeth D. Zwicky протестировала все программы резервного копирования, обсуждаемые здесь. Беспроигрышным вариантом для сохранения всех ваших данных и особенностей файловых систем UNIX является dump. Элизабет создала файловые системы, содержащие большое количество необычных элементов (и некоторых не так уж необычных) и тестировала каждую из программ, выполняя резервное копирование и последующее восстановление этих файловых систем. В число необычных элементов входили: файлы с дырами, файлы с дырами и блоком пустого места, файлы с необычными символами в их именах, нечитаемые и незаписываемые файлы, устройства, меняющие свой размер во время резервного копирования, файлы, создаваемые и удаляемые во время копирования и тому подобное. Она представила результаты на конференции LISA V в октябре 1991 года. Посмотрите ссылку на сайте torture-testing Backup and Archive Programs (http://berdmann.dyndns.org/zwicky/testdump.doc.html).
^

17.12.8. Процедура восстановления при сбое

17.12.8.1. До того, как случится катастрофа

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

Во-первых, распечатайте разметку диска для всех ваших дисков (к примеру, disklabel da0 | lpr), таблицу файловых систем (/etc/fstab) и все сообщения, выводимые при загрузке, каждого по два экземпляра.

Во-вторых, определите, все ли устройства присутствуют на загрузочной и аварийной дискетах (boot.flp и fixit.flp). Самым простым способом проверки является перезагрузка вашей машины с загрузочной дискетой, вставленной в дисковод и последующая проверка сообщений при загрузке. Если все имеющиеся у вас устройства здесь будут перечислены и будут работоспособны, перейдите к третьему шагу.

В противном случае вам необходимо будет создать две особым образом сформированные загрузочные дискеты, на которых помещено ядро, могущее смонтировать все ваши диски и получить доступ к вашему стримеру. На этих дискетах должны быть: fdisk, disklabel, newfs, mount и какая-либо используемая вами программа резервного копирования. Эти программы должны быть скомпонованы статически. Если вы используете dump, то на дискете должна присутствовать и программа restore.

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

В-четвертых, проверяйте работу дискет (либо boot.flp и fixit.flp, либо двух дискет, которые вы сделали при выполнении второго шага) и лент с резервными копиями. Ведите журнал выполняемых действий. Храните эти записи вместе с загрузочной дискетой, распечатками и лентами. Вы просто обезумеете при восстановлении данных, если окажется, что записи могли бы избежать разрушения ваших резервных копий (Каким образом? Вместо команды tar xvf /dev/sa0 вы могли случайно набрать tar cvf /dev/sa0 и тем самым перезаписать вашу резервную копию).

Для дополнительной страховки, каждый раз создавайте загрузочные дискеты и две резервные копии на ленте. Храните одну из копий в каком-то удаленном месте и НЕ в том же здании, где находится ваш офис. Достаточно большое количество компаний во Всемирном Торговом Центре изучило это на своей шкуре. Это удаленное хранилище должно быть физически отделено на большое расстояние от ваших компьютеров и дисковых устройств.

^ Пример 17-3. Скрипт для создания загрузочной дискеты

#!/bin/sh

#

# create a restore floppy

#

# format the floppy

#

PATH=/bin:/sbin:/usr/sbin:/usr/bin


fdformat -q fd0

if [ $? -ne 0 ]

then

echo "Bad floppy, please use a new one"

exit 1

fi


# place boot blocks on the floppy

#

disklabel -w -B /dev/fd0c fd1440


#

# newfs the one and only partition

#

newfs -t 2 -u 18 -l 1 -c 40 -i 5120 -m 5 -o space /dev/fd0a


#

# mount the new floppy

#

mount /dev/fd0a /mnt


#

# create required directories

#

mkdir /mnt/dev

mkdir /mnt/bin

mkdir /mnt/sbin

mkdir /mnt/etc

mkdir /mnt/root

mkdir /mnt/mnt # for the root partition

mkdir /mnt/tmp

mkdir /mnt/var


#

# populate the directories

#

if [ ! -x /sys/compile/MINI/kernel ]

then

cat << EOM

The MINI kernel does not exist, please create one.

Here is an example config file:

#

# MINI -- A kernel to get FreeBSD onto a disk.

#

machine "i386"

cpu "I486_CPU"

ident MINI

maxusers 5


options INET # needed for _tcp _icmpstat _ipstat

# _udpstat _tcpstat _udb

options FFS #Berkeley Fast File System

options FAT_CURSOR #block cursor in syscons or pccons

options SCSI_DELAY=15 #Be pessimistic about Joe SCSI device

options NCONS=2 #1 virtual consoles

options USERCONFIG #Allow user configuration with -c XXX


config kernel root on da0 swap on da0 and da1 dumps on da0


device isa0

device pci0


device fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr

device fd0 at fdc0 drive 0


device ncr0


device scbus0


device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr

device npx0 at isa? port "IO_NPX" irq 13 vector npxintr


device da0

device da1

device da2


device sa0


pseudo-device loop # required by INET

pseudo-device gzip # Exec gzipped a.out's

EOM

exit 1

fi


cp -f /sys/compile/MINI/kernel /mnt


gzip -c -best /sbin/init > /mnt/sbin/init

gzip -c -best /sbin/fsck > /mnt/sbin/fsck

gzip -c -best /sbin/mount > /mnt/sbin/mount

gzip -c -best /sbin/halt > /mnt/sbin/halt

gzip -c -best /sbin/restore > /mnt/sbin/restore


gzip -c -best /bin/sh > /mnt/bin/sh

gzip -c -best /bin/sync > /mnt/bin/sync


cp /root/.profile /mnt/root


cp -f /dev/MAKEDEV /mnt/dev

chmod 755 /mnt/dev/MAKEDEV


chmod 500 /mnt/sbin/init

chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt

chmod 555 /mnt/bin/sh /mnt/bin/sync

chmod 6555 /mnt/sbin/restore


#

# create the devices nodes

#

cd /mnt/dev

./MAKEDEV std

./MAKEDEV da0

./MAKEDEV da1

./MAKEDEV da2

./MAKEDEV sa0

./MAKEDEV pty0

cd /


#

# create minimum filesystem table

#

cat > /mnt/etc/fstab <
/dev/fd0a / ufs rw 1 1

EOM


#

# create minimum passwd file

#

cat > /mnt/etc/passwd <<EOM

root:*:0:0:Charlie &:/root:/bin/sh

EOM


cat > /mnt/etc/master.passwd <<EOM

root::0:0::0:0:Charlie &:/root:/bin/sh

EOM


chmod 600 /mnt/etc/master.passwd

chmod 644 /mnt/etc/passwd

/usr/sbin/pwd_mkdb -d/mnt/etc /mnt/etc/master.passwd


#

# umount the floppy and inform the user

#

/sbin/umount /mnt

echo "The floppy has been unmounted and is now ready."
^
17.12.8.2. После сбоя

Главный вопрос: выжило ли ваше оборудование? Вы регулярно делали резервные копии, так что нет нужды беспокоиться о программном обеспечении.

Если оборудование было повреждено, должны быть заменены неисправные компоненты.

Если с оборудованием все в порядке, проверьте ваши дискеты. При использовании самостоятельно созданной загрузочной дискеты, загрузитесь в однопользовательском режиме (набрав -s в приглашении boot:). Пропустите следующий абзац.

Если вы используете дискеты boot.flp и fixit.flp, читайте дальше. Вставьте дискету boot.flp в первый дисковод и загрузите компьютер. На экран будет выведено оригинальное меню установки. Выберите пункт Fixit--Repair mode with CDROM or floppy. После вывода приглашения вставьте fixit.flp. restore и другие нужные вам программы находятся в каталоге /mnt2/rescue (/mnt2/stand во FreeBSD версий, предшествующих 5.2).

Восстановите по отдельности каждую файловую систему.

Попробуйте выполнить команду mount (например, mount /dev/da0a /mnt) по отношению к корневому разделу вашего первого диска. Если метка диска была испорчена, то воспользуйтесь командой disklabel для переразбиения на разделы и разметки диска так, чтобы получившаяся метка совпала с той, которая вами была распечатана и сохранена. Для повторного создания файловых систем используйте утилиту newfs. Повторно смонтируйте корневой раздел дискеты в режиме чтения-записи (mount -u -o rw /mnt). Воспользуйтесь вашей программой резервного копирования и резервными копиями на лентах для восстановления данных для этой файловой системы (например. restore vrf /dev/sa0). Размонтируйте файловую систему (например, umount /mnt). Повторите эту процедуру для каждой файловой системы, которая была повреждена.

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

17.13. Сетевые файловые системы, файловые системы в памяти и с отображением в файл


Реорганизацию и улучшения выполнил Marc Fonvieille.

Кроме дисков, которые вы физически устанавливаете в ваш компьютер; дискеты, компакт-диски, винчестеры и так далее, FreeBSD воспринимает и другие типы дисков - виртуальные диски.

Сюда могут быть отнесены сетевые файловые системы, такие, как Network File System и Coda, а также файловые системы с организацией в памяти и создаваемые в файлах.

В зависимости от версии FreeBSD, которую вы используете, для создания и работы с файловыми системами, отображаемыми в оперативную память или файлы, вам нужно будет пользоваться разными инструментами.

Замечание: Пользователи FreeBSD 4.X для создания требуемых устройств должны использовать MAKEDEV(8). Во FreeBSD 5.0 и более поздних версиях для создания файлов устройств используется devfs(5), которая выполняет это прозрачно для пользователей.
^

17.13.1. Файловая система в файле во FreeBSD 4.X


Утилита vnconfig(8) конфигурирует и позволяет использовать дисковые устройства на основе псевдо-устройств vnode. vnode представляет собой файл и отвечает за работу с файлом. Это означает, что vnconfig(8) использует файлы для создания и работы с файловой системой. Одним из возможных способов использования является монтирование образов дискет или образов компакт-дисков, сброшенных в файлы.

Для использования vnconfig(8) в конфигурационном файле ядра вам нужно включить поддержку vn(4):

pseudo-device vn

Чтобы смонтировать имеющийся образ файловой системы:

^ Пример 17-4. Использование vnconfig для монтирования имеющегося образа файловой системы во FreeBSD 4.X

# vnconfig vn0 diskimage

# mount /dev/vn0c /mnt

Для создания нового образа файловой системы с помощью vnconfig(8):

Пример 17-5. Создание нового диска в файле с помощью vnconfig

# dd if=/dev/zero of=newimage bs=1k count=5k

5120+0 records in

5120+0 records out

# vnconfig -s labels -c vn0 newimage

# disklabel -r -w vn0 auto

# newfs vn0c

Warning: 2048 sector(s) in last cylinder unallocated

/dev/vn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors

5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g)

super-block backups (for fsck -b #) at:

32

# mount /dev/vn0c /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/vn0c 4927 1 4532 0% /mnt
^

17.13.2. Файловые системы, отображаемые в файлы


Во FreeBSD 5.X и более поздних для конфигурации и подключения дисков md(4), отображаемых в оперативную память, используется утилита mdconfig(8). Для работы с mdconfig(8) вам нужно подгрузить модуль md(4) или добавить поддержку этих устройств в файл конфигурации ядра:

device md

Утилита mdconfig(8) поддерживает три типа виртуальных дисков, отображаемых в память: диски в памяти, которая выделяется запросами malloc(9) и диски в памяти, использующие в качестве устройств хранения файлы или раздел подкачки. Одним из возможных использований таких дисков является монтирование файлов с образами дискет или CD.

Для монтирования образа существующей файловой системы:

^ Пример 17-6. Использование mdconfig для монтирования файла с образом существующей файловой системы

# mdconfig -a -t vnode -f diskimage -u 0

# mount /dev/md0 /mnt

Для создания образа новой файловой системы при помощи mdconfig(8):

Пример 17-7. Создание нового диска, отображаемого в файл, при помощи mdconfig

# dd if=/dev/zero of=newimage bs=1k count=5k

5120+0 records in

5120+0 records out

# mdconfig -a -t vnode -f newimage -u 0

# bsdlabel -w md0 auto

# newfs md0a

/dev/md0c: 5.0MB (10224 sectors) block size 16384, fragment size 2048

using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes.

super-block backups (for fsck -b #) at:

160, 2720, 5280, 7840

# mount /dev/md0a /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/md0a 4710 4 4330 0% /mnt

Если в параметре -u вы не задали номер устройства, то mdconfig(8) для выбора неиспользуемого устройства будет использовать функцию автоматическое выделения в md(4). Имя выделенного устройства будет выдано на стандартное устройство выводы в виде, например, md4. Для получения более полной информации о mdconfig(8), пожалуйста, обратитесь к соответствующей странице справочной системы.

Утилита mdconfig(8) весьма полезна, однако для создания файла с файловой системой требуется произвести много действий. Вместе с FreeBSD 5.0 поставляется утилита под названием mdmfs(8), которая создаёт диск md(4) при помощи mdconfig(8), размещает на нём файловую систему UFS при помощи newfs(8) и монтирует её командой mount(8). Например, если вы хотите создать и смонтировать такой же образ файловой системе, как выше, просто наберите такую команду:

^ Пример 17-8. Настройка и монтирование диска, отображаемого в файл, при помощи команды mdmfs

# dd if=/dev/zero of=newimage bs=1k count=5k

5120+0 records in

5120+0 records out

# mdmfs -F newimage -s 5m md0 /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/md0 4718 4 4338 0% /mnt

Если вы используете параметр md без номера устройства, то mdmfs(8) будет использовать автоматическую нумерацию md(4) для автоматического выбора неиспользуемого устройства. Более полную информацию о mdmfs(8) можно найти на страницах справочной системы.
^

17.13.3. Файловая система в памяти во FreeBSD 4.X


Драйвер md(4) является простым и эффективным способом создания файловых систем в памяти во FreeBSD 4.X. Для выделения памяти используется malloc(9).

Просто возьмите файловую систему, которую вы приготовили при помощи, скажем, vnconfig(8) и:

Пример 17-9. Диск md в памяти во FreeBSD 4.X

# dd if=newimage of=/dev/md0

5120+0 records in

5120+0 records out

# mount /dev/md0c /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/md0c 4927 1 4532 0% /mnt

Для получения более полной информации, пожалуйста, обратитесь к страницам справочной системы по md(4).
^

17.13.4. Файловые системы с отображением в память


При работе с файловыми системами, отображаемыми в файл или память, используются одни и те же утилиты: mdconfig(8) или mdmfs(8). Обычно для отображаемых в память файловых систем следует использовать опцию ''хранение на области подкачки''. Это не означает, что такая файловая система будет сразу сброшена на диск: место под нее будет выделено из общего пула памяти, и при необходимости может перемещаться в область подкачки. Также, возможно выделение места под файловую систему в основной памяти (через malloc(9)); однако, следует помнить, что использование таких файловых систем, в особенности большого размера, может привести к панике системы от исчерпания ядерной памяти.

Пример 17-10. Создание нового диска с отображением в память при помощи mdconfig

# mdconfig -a -t swap -s 5m -u 1

# newfs -U md1

/dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048

using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes.

with soft updates

super-block backups (for fsck -b #) at:

160, 2752, 5344, 7936

# mount /dev/md1 /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/md1 4718 4 4338 0% /mnt

Пример 17-11. Создание нового диска с отображением в память при помощи mdmfs

# mdmfs -s 5m md2 /mnt

# df /mnt

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/md2 4846 2 4458 0% /mnt
^

17.13.5. Отключение диска, отображаемого в память, от системы


Если файловые системы, отображаемые в память или файл, больше не используются, вам нужно высвободить все ресурсы для системы. Первым делом нужно размонтировать файловую систему, затем воспользоваться mdconfig(8) для отключения диска от системы и освободить ресурсы.

К примеру, чтобы отключить и освободить все ресурсы, используемые /dev/md4:

# mdconfig -d -u 4

Для выдачи информации об отконфигурированных устройствах md(4) используется команда mdconfig -l.

Во FreeBSD 4.X для отключения устройства используется команда vnconfig(8). Например, для отключения и освобождения всех ресурсов, используемых /dev/vn4:

# vnconfig -u vn4
^

17.14. Мгновенные копии файловых систем


Текст предоставил Tom Rhodes.

Во FreeBSD 5.0 вместе с технологией Отложенных обновлений представлена новая возможность: генерация мгновенных копий файловых систем.

Мгновенные копии позволяют пользователю создавать образы заданных файловых систем и работать с ними как с файлами. Файлы мгновенных копий должны создаваться в той файловой системе, над которой производится действие, и пользователь может создавать не более 20 мгновенных копий для каждой файловой системы. Активные копии записываются в суперблок, так что они остаются в силе между операциями монтирования и размонтирования в процессе системных перезагрузок. Если мгновенная копия больше не нужна, она может быть удалена стандартной командой rm(1). Мгновенные копии могут удаляться в любом порядке, однако всё использованное пространство не может быть использовано, так как другая мгновенная копия может претендовать на некоторые блоки из освобождённых.

Неизменяемый флаг snapshot устанавливается на файл при помощи mksnap_ffs(8) после первоначального создания файла мгновенной копии. Команда unlink(1) делает исключение для файлов мгновенных копий, позволяя их удалять.

Мгновенные копии создаются при помощи утилиты mount(8). Чтобы создать мгновенную копию /var в файле /var/snapshot/snap, воспользуйтесь такой командой:

# mount -u -o snapshot /var/snapshot/snap /var

В качестве альтернативного средства создания мгновенных копий вы можете использовать утилиту mksnap_ffs(8):

# mksnap_ffs /var /var/snapshot/snap

Файлы мгновенных копий файловых систем (к примеру, /var) можно найти при помощи команды find(1):

# find /var -flags snapshot

После создания мгновенной копии есть несколько способов её использования:

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

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

• Запустить утилиту dump(8) с мгновенной копией. Будет создаваться дамп, соответствующий файловой системе на момент создания мгновенной копии. Утилита dump(8) при использовании опции -L тоже может работать с мгновенными копиями, создавать их дампы, а затем удалять за один проход.

• Смонтировать командой mount(8) мгновенную копию как замороженный образ файловой системы. Чтобы смонтировать командой mount(8) мгновенную копию /var/snapshot/snap, запустите:

# mdconfig -a -t vnode -f /var/snapshot/snap -u 4

# mount -r /dev/md4 /mnt

Теперь вы можете пройтись по иерархии вашей зафиксированной файловой системы /var, смонтированной в каталог /mnt. Первоначально всё будет в том же самом состоянии, в каком это было во время создания мгновенной копии. Единственным исключением будет то, что любые ранее сделанные мгновенные копии будут видны как файлы нулевой длины. Когда использование мгновенной копии закончено, она может быть удалена командой:

# umount /mnt

# mdconfig -d -u 4

Для получения более полной информации о softupdates и мгновенных копиях файловых систем, включая технической описание, вы можете посетить сайт Маршалла Кёрка МакКузика (Marshall Kirk McKusick) по адресу http://www.mckusick.com/.
^

17.15. Квотирование файловых систем


Квоты - это опциональная возможность операционной системы, которая позволяет ограничивать объем дискового пространства и/или количество файлов для конкретного пользователя или членов определенной группы в рамках одной файловой системы. Чаще всего эта возможность используется в системах разделения времени, когда желательно ограничить количество ресурсов, которые может использовать один пользователь или группа пользователей. Это позволит не допустить ситуации, когда один пользователь или группа пользователей заполняют всё доступное дисковое пространство.
^

17.15.1. Настройка вашей системы на использование дисковых квот


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

options QUOTA

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

Затем вам потребуется включить квотирование дисков в файле /etc/rc.conf. Это делается добавление такой строчки:

enable_quotas="YES"

Для более полного контроля над запуском квотирования имеется дополнительная переменная для настройки. Как правило, при загрузке целостность квот каждой файловой системы проверяется программой quotacheck(8). При работе программы quotacheck(8) проверяется точное соответствие данных в базе данных квот данным в файловой системе. Это весьма долгий процесс, что отражается на времени загрузки системы. Если вам захочется пропустить этот шаг, то для этого предназначена специальная переменная в файле /etc/rc.conf:

check_quotas="NO"

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

Для включения пользовательских квот для файловой системы, добавьте параметр userquota в поле параметров файловой системы, на которой вы хотите включить квотирование, в файле /etc/fstab. Например:

/dev/da1s2g /home ufs rw,userquota 1 2

Подобным же образом для включения квотирования на уровне групп, воспользуйтесь параметром groupquota вместо userquota. Чтобы включить квотирование как для пользователей, так и для групп, измените строчку следующим образом:

/dev/da1s2g /home ufs rw,userquota,groupquota 1 2

По умолчанию файлы квот хранятся в корневом каталоге файловой системы в файлах с именами quota.user и quota.group соответственно для пользовательских и групповых квот. Для получения подробной информации обратитесь к команде fstab(5). Хотя справочная страница по fstab(5) утверждает, что вы можете указать другое местоположение файлов с квотами, этого делать не рекомендуется, потому что различные утилиты для работы с квотами не могут нормально работать в такой ситуации.

На этом этапе вы должны перезагрузить вашу систему с новым ядром. Скрипт /etc/rc автоматически запустит соответствующие команды для создания начальных файлов для всех квот, которые вы создали в файле /etc/fstab, так что нет нужды вручную создавать никаких файлов квот нулевой длины.

При нормальной работе вам не потребуется вручную запускать программы quotacheck(8), quotaon(8) или quotaoff(8). Однако вам нужно хотя бы прочесть страницы справочника по этим командам, просто чтобы ознакомиться с их функциями.
^

17.15.2. Установка квот


Как только вы настроили вашу систему на использование квот, проверьте, что они действительно были задействованы. Простым способом сделать это является запуск такой команды:

# quota -v

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

Теперь вы действительно готовы задавать ограничения при помощи команды edquota(8).

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

Жёсткое ограничение не может быть превышено. Как только пользователь достиг своих ограничений, ресурсы соответствующей файловой системы ему больше выделяться не будут. Например, если пользователь имеет жесткое ограничение в 500 Кбайт на файловой системе и в текущий момент использует 490 Кбайт, то пользователь может получить дополнительно ещё 10 Кбайт. Попытка занять ещё 11 Кбайт окончится неудачно.

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

Далее приводится пример того, что вы можете наблюдать при запуске команды edquota(8). Когда вызывается команда edquota(8), вы оказываетесь в редакторе, заданном переменной переменной окружения EDITOR, или в редакторе vi, если переменная EDITOR не задана, и можете редактировать квоты.

# edquota -u test

Quotas for user test:

/usr: kbytes in use: 65, limits (soft = 50, hard = 75)

inodes in use: 7, limits (soft = 50, hard = 60)

/usr/var: kbytes in use: 0, limits (soft = 50, hard = 75)

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

Для каждой файловой системы, на которой включено квотирование, вы должны увидеть две строки. В одной строке приведены ограничения на блоки, а в другой на количество inode. Например, чтобы увеличить ограничения на количество блоков для пользователя с мягкого ограничения в 50 и жёсткого ограничения в 75, на мягкое ограничение в 500 и жёсткое ограничение в 600, измените:

/usr: kbytes in use: 65, limits (soft = 50, hard = 75)

на:

/usr: kbytes in use: 65, limits (soft = 500, hard = 600)

Новые ограничения вступят в силу после выхода из редактора.

Иногда желательно установить ограничения квот на некоторый диапазон UID (идентификаторов пользователей). Это можно сделать при помощи параметра -p в команде edquota(8). Во-первых, установите желаемое ограничение для пользователя, а затем запустите команду edquota -p protouser startuid-enduid. Например, если пользователь test имеет желаемые ограничения, то для дублирования этих ограничений на пользователей с UID от 10000 до 19999 может быть использована такая команда:

# edquota -p test 10000-19999

Дополнительную информацию можно получить из справочной страницы по команде edquota(8).
^

17.15.3. Проверка ограничений и использования диска


Для проверки квот и использования дисков вы можете использовать команды quota(1) или repquota(8). Команда quota(1) может быть использована для проверки квот отдельных пользователей, групп, а также использования дисков. Пользователь может только проверить собственную квоту и квоту той группы, к которой он принадлежит. Только администратор системы может проверить квоты всех пользователей и групп. Команду repquota(8) можно использовать для получения суммарной статистики всех квот и использования дисков для файловых систем с включенными квотами.

Далее приведен пример вывода команды quota -v для пользователя, который имеет ограничения на двух файловых системах.

Disk quotas for user test (uid 1002):

Filesystem usage quota limit grace files quota limit grace

/usr 65* 50 75 5days 7 50 60

/usr/var 0 50 75 0 50 60

В этом примере для файловой системы /usr пользователь превысил свое мягкое ограничение в 50 Кбайт на 15 Кбайт и имеет 5 дней до истечения отсрочки. Отметьте знак звездочки *, который указывает на превышение пользователем своего ограничения.

Как правило, файловые системы, на которых пользователь не занимает дискового пространства, не показываются в выводе команды quota(1), даже если ему выделена квота на этой файловой системе. При использовании параметра -v эти файловые системы выводятся, как, например, файловая система /usr/var в примере выше.
^

17.15.4. Квоты в NFS


Квоты определяются подсистемой квот на сервере NFS. Даемон rpc.rquotad(8) предоставляет информацию о квотах для программы quota(1) на клиентах NFS, позволяя пользователям на этих машинах смотреть свою статистику о квотах.

Включите rpc.rquotad в файле /etc/inetd.conf следующим образом:

rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad

Теперь перезапустите inetd:

# kill -HUP `cat /var/run/inetd.pid`
^

17.16. Шифрование дисковых разделов


Текст предоставил Lucky Green.

FreeBSD предоставляет прекрасную возможность по защите от несанкционированного доступа к данным. Права на доступ к файлам и технология принудительного контроля доступа MAC (Mandatory Access Control) (смотрите see Гл. 15) помогают предотвратить несанкционированный доступ посторонних лиц к данным, при условии работы операционной системы и компьютера. Однако права доступа, контролируемые операционной системой, не имеют значения, если нападающий получает физический доступ к компьютеру и может просто перенести жёсткий диск на другую машину для копирования и дальнейшего анализа важных данных.

Вне зависимости от того, как атакующий завладел жёстким диском или выключенным компьютером, технологии gbde (GEOM Based Disk Encryption - шифрование диска на уровне GEOM) и криптографическая подсистема geli FreeBSD могут защитить данные файловой системы компьютера даже против очень заинтересованной атакующей стороны с достаточными ресурсами. В отличие от громоздких систем шифрования, которые шифруют отдельные файлы, gbde и geli шифруют в прозрачном режиме файловую систему в целом, при этом данные в открытом виде на диск никогда не записываются.
^

17.16.1. Шифрование диска при помощи gbde


1. Получите права пользователя root

Настройка gbde требует права доступа администратора системы.

% su -

Password:

2. Проверьте номер версии операционной системы

Для работы gbde(4) требуется FreeBSD 5.0 и выше.

# uname -r

5.0-RELEASE

3. Включите поддержку gbde(4) в конфигурационный файл ядра

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

options GEOM_BDE

Перестройте ядро FreeBSD. Этот процесс описан в Гл. 8.

Перезагрузитесь, запустив новое ядро.
^
17.16.1.1. Подготовка зашифрованного жёсткого диска

В следующем примере предполагается, что в вашу систему вы добавляете новый винчестер, на котором будет располагаться единственный раздел с зашифрованными данными. Этот раздел будет монтироваться в каталог /private. gbde может также использоваться для шифрования /home и /var/mail, но это требует более сложной последовательности действий, что выходит за рамки этого вводного материала.

1. Подключите новый жёсткий диск

Установите новый диск в систему, как это описано в Разд. 17.3. В рамках этого примера раздел, соответствующий новому жёсткому диску, будет называться /dev/ad4s1c. Устройства /dev/ad0s1* представляют существующие стандартные разделы FreeBSD нашей тестовой системы.

# ls /dev/ad*

/dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1

/dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c

/dev/ad0s1a /dev/ad0s1d /dev/ad4

2. Создайте каталог для размещения файлов блокировок GBDE

# mkdir /etc/gbde

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

3. Инициализируйте раздел gbde

Перед началом работы с разделом gbde его необходимо проинициализировать. Эта инициализация производится только один раз:

# gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c

gbde(8) запустит редактор, что позволит вам задать в шаблоне различные конфигурационные параметры. При работе с файловыми системами UFS1 и UFS2 задайте значение sector_size равным 2048:

$FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $

#

# Sector size is the smallest unit of data which can be read or written.

# Making it too small decreases performance and decreases available space.

# Making it too large may prevent filesystems from working. 512 is the

# minimum and always safe. For UFS, use the fragment size

#

sector_size = 2048

[...]

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

По команде gbde init создаётся файл блокировок для вашего раздела gbde, который в нашем случае будет иметь имя /etc/gbde/ad4s1c.

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

4. Подключите зашифрованный раздел к системе

# gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c

Будет выдан запрос на ввод ключевой фразы, которую вы выбирали во время инициализации зашифрованного раздела. Новое защищённое устройство будет видно в каталоге /dev под названием /dev/device_name.bde:

# ls /dev/ad*

/dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1

/dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c

/dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde

5. Создайте файловую систему на зашифрованном устройстве

Как только защищённое устройство будет подключено к системе, вы сможете создать на нём файловую систему. Для этого используется утилита newfs(8). Так как инициализация новой файловой системы UFS2 происходит быстрее, чем инициализация файловой системы старого формата UFS1, то рекомендуется использовать newfs(8) с параметром -O2.

Замечание: Во FreeBSD 5.1-RELEASE и последующих релизах параметр -O2 используется по умолчанию.

# newfs -U -O2 /dev/ad4s1c.bde

Замечание: Запуск команды newfs(8) должен выполняться над подключенном разделе gbde, который идентифицируется по расширению *.bde в имени устройства.

6. Смонтируйте зашифрованный раздел

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

# mkdir /private

Смонтируйте защищённую файловую систему.

# mount /dev/ad4s1c.bde /private

7. Проверьте доступность зашифрованной файловой системы

Защищённая файловая система теперь должна быть доступна утилите df(1) и доступной для использования.

% df -H

Filesystem Size Used Avail Capacity Mounted on

/dev/ad0s1a 1037M 72M 883M 8%

/devfs 1.0K 1.0K 0B 100% /dev

/dev/ad0s1f 8.1G 55K 7.5G 0% /home

/dev/ad0s1e 1037M 1.1M 953M 0% /tmp

/dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr

/dev/ad4s1c.bde 150G 4.1K 138G 0% /private
^
17.16.1.2. Монтирование имеющихся зашифрованных файловых систем

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

1. Подключение gbde-раздела к системе

# gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c

Будет выдан запрос на ввод ключевой фразы, выбранной на этапе инициализации зашифрованного раздела gbde.

2. Проверка файловой системы на наличие ошибок

Так как защищаемая файловая система не может пока быть указана в файле /etc/fstab для автоматического монтирования, то она должны проверяться на наличие ошибок посредством ручного запуска fsck(8) до её монтирования.

# fsck -p -t ffs /dev/ad4s1c.bde

3. Монтирование зашифрованной файловой системы

# mount /dev/ad4s1c.bde /private

Теперь защищённая файловая система доступна для работы.
17.16.1.2.1. Автоматическое монтирование зашифрованных разделов

Для автоматического подключения, проверки и монтирования зашифрованного раздела можно создать скрипт, но по соображениям безопасности в этом скрипте пароля для gbde(8) быть не должно. Поэтому рекомендуется запускать такие скрипты вручную, а пароль задавать с консоли или сеанса ssh(1).

Начиная с версии FreeBSD 5.2-RELEASE, базовая система содержит скрипт rc.d для автоматического монтирования шифрованных разделов. Его аргументы могут быть указаны в файле rc.conf(5):

gbde_autoattach_all="YES"

gbde_devices="ad4s1c"

При этом ключевая фраза для gbde должна быть введена на этапе загрузки. После введения ключевой фразы зашифрованный раздел будет смонтирован автоматически. Такой подход может быть очень удобным для использования gbde на ноутбуках.
^
17.16.1.3. Криптографическая защита, применяемая в gbde

gbde(8) шифрует содержимое секторов при помощи 128-битного AES в режиме CBC. Каждый сектор диска шифруется различным ключом AES. Более полная информацию о системе шифрования gbde, включая алгоритм генерации ключей для секторов из ключевой фразы, вводимой пользователем, можно найти на страницах справочной системы о gbde(4).
^
17.16.1.4. Вопросы совместимости

sysinstall(8) несовместим с устройствами, зашифрованными gbde. Все устройства *.bde перед запуском sysinstall(8) должны быть отключены от системы, или эта утилита аварийно завершит работу на этапе обнаружения устройств. Для отключения защищённого устройства, используемого в нашем примере, воспользуйтесь такой командой:

# gbde detach /dev/ad4s1c

Также заметьте, что, так как vinum(4) работает не через подсистему geom(4), то вы не можете использовать тома vinum с gbde.
^

17.16.2. Шифрование дисков при помощи geli


Предоставлено Daniel Gerzo.

Начиная с версии 6.0 FreeBSD поддерживается новый класс GEOM — geli. В настоящий момент он поддерживается Pawel Jakub Dawidek
. Класс Geli отличается от gbde; он предоставляет другой комплекс возможностей и использует иную схему криптования.

Наиболее значимыми особенностями geli(8) являются:

• Использование инфраструктуры crypto(9): при наличии аппаратной криптографической поддержки, geli автоматически использует ее.

• Поддержка разнообразных криптоалгоритмов (в настоящее время AES, Blowfish и 3DES).

• Поддержка шифрованного корневого раздела. Для загрузки в такой ситуации потребуется ввести ключевую фразу.

• Поддержка двух независимых ключей шифрования (например, ''основного ключа'' и ''ключа компании'').

• Высокая скорость работы geli за счет простого криптования сектор-сектор.

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

• Поддержка криптования файловых систем случайным одноразовым ключом — например, для разделов подкачки или временных файловых систем.

Другие возможности класса geli описаны в его странице справочника: geli(8).

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

Для того чтобы использовать geli, вам потребуется FreeBSD версии 6.0-RELEASE или более поздней. Поскольку необходимо внести изменения в конфигурацию ядра, потребуются также привилегии суперпользователя.

1. Изменение конфигурацию ядра: включение geli

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

options GEOM_ELI

device crypto

Перестройте ядро, как описано в разделе Гл. 8.

Помимо этого, поддержка geli может быть активирована модулем ядра на этапе загрузки. Для этого добавьте в файл /boot/loader.conf строку:

geom_eli_load="YES"

Теперь ядро должно поддерживать geli(8).

2. Генерация главного ключа

Предлагаемый пример описывает процесс генерации ключевого файла, который послужит частью главного ключа для шифрованного провайдера, монтируемого в каталог /private. При помощи содержимого ключевого файла создается набор случайных данных, которым зашифровывается главный ключ. Кроме того, он будет защищен кодовой фразой. Размер сектора провайдера будет составлять 4kB. Наконец, мы обсудим, как присоединиться к провайдеру geli, создать на базе его файловую систему, как ее смонтировать и работать с ней, и, в заключение, как корректно завершить работу.

Больший чем обычно размер сектора (как в нашем примере, 4 кБ) рекомендуется для увеличения производительности.

Главный ключ будет защищен кодовой фразой; данные для ключевого файла берутся из /dev/random. Размер сектора создаваемого нами шифрованного провайдера /dev/da2.eli — 4кБ.

# dd if=/dev/random of=/root/da2.key bs=64 count=1

# geli init -s 4096 -K /root/da2.key /dev/da2

Enter new passphrase:

Reenter new passphrase:

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

Если в качестве имени ключевого файла указан ''-'', используется стандартный ввод. Это позволяет использовать более одного ключевого файла:

# cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2

3. Свяжите сгенерированный ключ с провайдером

# geli attach -k /root/da2.key /dev/da2

Enter passphrase:

Созданный при этом файл дискового устройства будет называться /dev/da2.eli.

# ls /dev/da2*

/dev/da2 /dev/da2.eli

4. Создайте новую файловую систему

# dd if=/dev/random of=/dev/da2.eli bs=1m

# newfs /dev/da2.eli

# mount /dev/da2.eli /private

Зашифрованная файловая система будет видна в выводе утилиты df(1) и готова к использованию:

# df -H

Filesystem Size Used Avail Capacity Mounted on

/dev/ad0s1a 248M 89M 139M 38% /

/devfs 1.0K 1.0K 0B 100% /dev

/dev/ad0s1f 7.7G 2.3G 4.9G 32% /usr

/dev/ad0s1d 989M 1.5M 909M 0% /tmp

/dev/ad0s1e 3.9G 1.3G 2.3G 35% /var

/dev/da2.eli 150G 4.1K 138G 0% /private

5. Размонтирование и деактивация провайдера

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

# umount /private

# geli detach da2.eli

Дополнительную информацию о geli(8) можно найти на соответствующей странице справочника.
^
17.16.2.1. Использование стартового скрипта rc.d geli

Для удобства использования подсистемы geli в комплект базовой системы FreeBSD входит стартовый скрипт, работой которого можно управлять из rc.conf(5):

geli_devices="da2"

geli_da2_flags="-p -k /root/da2.key"

При этом дисковый раздел /dev/da2 будет сконфигурирован как провайдер geli, связан с ключевым файлом /root/da2.key, а кодовая фраза не будет использоваться (отметим, что это возможно только в том случае, если при инициализации geli был указан ключ -P). Шифрованный провайдер geli будет отсоединен перед выключением системы.

Дополнительную информацию о конфигурации скриптов rc.d можно найти в соответствующей главе Руководства.
^

17.17. Шифрование области подкачки


Написано Christian Brьffer.

Шифрование области подкачки в FreeBSD доступно начиная с версии 5.3-RELEASE и достаточно легко конфигурируется. Варианты конфигурации слегка различаются в зависимости от версии системы. Начиная с версии 6.0-RELEASE, для шифрования разделов подкачки можно использовать утилиты gbde(8) или geli(8); в более ранних версиях доступно только решение при помощи gbde(8). В обоих случаях используется скрипт rc.d encswap.

Предыдущий раздел, Шифрование дисковых разделов, кратко описывает различные методы криптования.
^

17.17.1. Зачем шифровать область подкачки?


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

17.17.2. Подготовка


Замечание: В данном разделе мы будем считать, что разделом подкачки является ad0s1b.

До настоящего момента раздел подкачки не был зашифрован. Таким образом, на нем могут содержаться пароли или какая-либо иная важная информация в открытом виде. Чтобы избавиться от этого, заполним раздел подкачки случайными данными:

# dd if=/dev/random of=/dev/ad0s1b bs=1m
^

17.17.3. Шифрование раздела подкачки при помощи gbde(8)


В версиях FreeBSD начиная с 6.0-RELEASE в строку файла /etc/fstab, описывающую раздел подкачки, необходимо добавить суффикс .bde:

# Device Mountpoint FStype Options Dump Pass#

/dev/ad0s1b.bde none swap sw 0 0

В системах версий до FreeBSD 6.0-RELEASE, кроме того, потребуется следующая строка в файле конфигурации системы /etc/rc.conf:

gbde_swap_enable="YES"
^

17.17.4. Шифрование раздела подкачки при помощи geli(8)


Процедура при использовании geli(8) для шифрования раздела подкачки сходна с использованием gbde(8). В строку файла /etc/fstab, описывающую раздел подкачки, нужно добавить суффикс .eli:

# Device Mountpoint FStype Options Dump Pass#

/dev/ad0s1b.eli none swap sw 0 0

По умолчанию, geli(8) использует алгоритм криптования AES с длиной ключа 256 бит.

При необходимости эти параметры могут быть изменены в опции geli_swap_flags файла конфигурации /etc/rc.conf. Приведенная ниже строка указывает, что скрипт rc.d encswap должен использовать для криптования алгоритм Blowfish с ключом длиной 128 бит, размером сектора 4 килобайта и включенной опцией ''отсоединиться при последнем закрытии'':

geli_swap_flags="-a blowfish -l 128 -s 4096 -d"

За списком возможных опций обращайтесь к описанию команды onetime в странице справочника geli(8).
^

17.17.5. Окончательная проверка


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

В случае использования gbde(8):

% swapinfo

Device 1K-blocks Used Avail Capacity

/dev/ad0s1b.bde 542720 0 542720 0%

При использовании geli(8):

% swapinfo

Device 1K-blocks Used Avail Capacity

/dev/ad0s1b.eli 542720 0 542720 0%

Примечания

1. Советы по выбору легко запоминающихся ключевых фраз можно найти на сайте Diceware Passphrase (http://world.std.com/~reinhold/diceware.html).
^

Глава 18. GEOM: Модульная инфраструктура преобразования дисковых запросов


Написал Tom Rhodes. Перевод на русский язык: Денис Баров.

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


Эта глава описывает использование дисков, управляемых инфраструктурой GEOM во FreeBSD. Среди прочего, здесь описывается большая часть утилит управления RAID, использующих GEOM для настройки. В этой главе мы не будем вдаваться в подробности взаимодействия GEOM с подсистемой ввода/вывода или с программным кодом, эту информацию вы можете получить на странице справочника geom(4). Эта глава также не является подробным руководством по настройке RAID. Мы обсудим только типы RAID, поддерживаемые GEOM.

После прочтения этой главы вы будете знать:

• Какие типы RAID поддерживает GEOM.

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

• Как с помощью GEOM создавать зеркальные, последовательные и шифрованные дисковые последовательности, а так же последовательности из дисков, присоединённых удалённо.

• Как решать проблемы с дисками, присоединёнными к инфраструктуре GEOM.

Перед чтением этой главы вы должны:

• Понимать, как FreeBSD работает с дисками (Гл. 17).

• Уметь сконфигурировать и установить новое ядро FreeBSD (Гл. 8).
^

18.2. Введение в GEOM


GEOM позволяет классам — MBR, BSD labels, и так далее — получить доступ к устройству и управлять им, используя поставщиков GEOM (providers) или специальные файлы устройств, расположенные в каталоге /dev. GEOM поддерживает различные программные конфигурации RAID, и прозрачно предоставляет доступ к дискам системе и системным приложениям.
^

18.3. RAID0 - Создание дисковой последовательности (Striping)


Написали Tom Rhodes, Murray Stokely.

Создание дисковой последовательности (Striping) — метод, применяемый, чтобы скомбинировать несколько физических дисков в один логический. Во многих случаях это делается с использованием аппаратных контроллеров. Дисковая подсистема GEOM предоставляет программную поддержку RAID0, иногда называемую дисковой последовательностью (Stripe).

В RAID уровня 0 данные разбиваются на блоки, которые параллельно записываются на все диски массива. Вместо того, что бы ждать записи 256k на один диск, RAID0 может параллельно записывать по 64k на каждый из четырёх дисков, обеспечивая более высокую производительность ввода/вывода. Производительность также может быть увеличена за счет использования большего числа дисков.

Все диски последовательности RAID0 должны быть одного размера, так как запись и считывание с дисков происходят параллельно.



Создание дисковой последовательности из неформатированных ATA дисков

1. Загрузите модуль geom_stripe:

# kldload geom_stripe.ko

2. Убедитесь, что существует подходящая точка монтирования. Если вы планируете сделать логический диск корневым разделом, используйте временную точку монтирования, например /mnt:

# mkdir /mnt

3. Определите имена устройств, которые будут объединены в последовательность, и создайте новое устройство для последовательности. Например, выполнив следующую команду, вы создадите дисковую последовательность из двух неразмеченных ATA дисков: /dev/ad2 и /dev/ad3.

# gstripe label -v st0 /dev/ad2 /dev/ad3

4. Создайте таблицу разделов:

# bsdlabel -wB /dev/stripe/st0

5. Теперь в /dev/stripe кроме st0 появились ещё два устройства — st0a и st0c. Создайте файловую систему на устройстве st0a, используя newfs:

# newfs -U /dev/stripe/st0a

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

Смонтируйте его:

# mount /dev/stripe/st0a /mnt

Чтобы монтировать созданную дисковую последовательность автоматически во время загрузки, добавьте информацию о ней в /etc/fstab:

# echo "/dev/stripe/st0a /mnt ufs rw 2 2" \

>> /etc/fstab

Чтобы модуль geom_stripe автоматически загружался во время инициализации системы, добавьте строку в /boot/loader.conf:

# echo 'geom_stripe_load="YES"' >> /boot/loader.conf
^

18.4. RAID1 - Зеркалирование (Mirroring)


Зеркалирование (Mirroring) — технология, применяемая как в корпоративной среде, так и на домашних компьютерах. Она позволяет создавать резервные копии ''на лету''. Зеркалирование, по сути, означает, что диск A является копией диска B. Или, возможно, диск C+D является копией диска A+B. Вне зависимости от конфигурации, основной аспект — дублирование информации. Позже, эта информация может быть с легкостью восстановлена или сохранена как резервная копия без остановки системы, или даже физически помещена в хранилище данных.

Перед началом, убедитесь, что у вас есть два физических диска равной емкости. Далее в этом примере подразумевается, что это диски прямого доступа (direct access, da(4)) с интерфейсом SCSI.

Начните с установки FreeBSD на первый диск с двумя разделами. Один из этих разделов должен быть раздел swap, равный двум размерам RAM, а все остальное место отведено под корневую файловую систему (/). Возможно также иметь отдельные разделы и для остальных точек монтирования, но так как это в несколько раз увеличивает количество манипуляций с bsdlabel(8) и fdisk(8), то в данной главе мы остановимся на более простом варианте.

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

Создайте устройство /dev/mirror/gm и свяжите его с устройством /dev/da1:

# gmirror label -vnb round-robin gm0 /dev/da1

В ответ вы должны получить сообщение:

Metadata value stored on /dev/da1.

Done.

Инициализируйте GEOM; эта команда загрузит модуль ядра /boot/kernel/geom_mirror.ko:

# gmirror load

Замечание: Эта команда создаст устройства gm0, gm0s1, gm0s1a и gm0s1c в каталоге /dev/mirror.

Установите стандартную разметку fdisk и загрузчик на свежесозданное устройство gm0:

# fdisk -vBI /dev/mirror/gm0

Теперь установите стандартную разметку bsdlabel:

# bsdlabel -wB /dev/mirror/gm0s1

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

Используйте newfs(8), чтобы создать файловую систему на устройстве gm0s1a:

# newfs -U /dev/mirror/gm0s1a

Это заставит систему проассоциировать устройства, и это хорошо. Проверьте, не было ли сообщений об ошибках, и смонтируйте устройство в каталог /mnt:

# mount /dev/mirror/gm0s1a /mnt

Теперь переместите все данные с загрузочного диска на только что созданную файловую систему. Для этого используйте dump(8) и restore(8); в некоторых случаях можно использовать dd(1).

# dump -L -0 -f- / |(cd /mnt && restore -r -v -f-)

Проделайте это со всеми файловыми системами. Просто подставьте нужную файловую систему в предыдущую команду.

Теперь отредактируйте /mnt/etc/fstab и закомментируйте swap файл 1. Измените информацию о других файловых системах, размещенных на диске. Вот пример файла /mnt/etc/fstab:

# Device Mountpoint FStype Options Dump Pass#

#/dev/da0s2b none swap sw 0 0

/dev/mirror/gm0s1a / ufs rw 1 1

Создайте файл boot.conf на обоих разделах: созданном и существующем. С помощью этого файла BIOS сможет загрузить правильный диск:

# echo "1:da(1,a)/boot/loader" > /boot.config

# echo "1:da(1,a)/boot/loader" > /mnt/boot.config

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

Наконец, добавьте строку в новый файл /boot/loader.conf:

# echo 'geom_mirror_load="YES"' >> /mnt/boot/loader.conf

Это позволит утилите loader(8) загрузить модуль geom_mirror.ko во время инициализации системы.

Перезагрузитесь:

# shutdown -r now

Если все было сделано правильно, система загрузится с gm0s1a. Если же что-то пойдёт не так, обратитесь к секции ''Решение проблем''.

Теперь добавьте диск da0 к устройству gm0:

# gmirror configure -a gm0

# gmirror insert gm0 /dev/da0

Ключ -a даст утилите команду gmirror(8) использовать автоматическую синхронизацию, то есть автоматически дублировать запись на диски. Страница справки разъясняет, как перестраивать и заменять диски, Будьте внимательны, вместо gm0 там использовано обозначение data.
^

18.4.1. Решение проблем

18.4.1.1. Система не загружается

Если система прекращает загрузку и выдает строку:

ffs_mountroot: can't find rootvp

Root mount failed: 6

mountroot>

Перезагрузите компьютер кнопкой питания или кнопкой ''Reset''. В загрузочном меню выберите опцию (6). Это приведёт к тому, что система выдаст приглашение loader(8). Загрузите модуль ядра вручную:

OK? load geom_mirror.ko

OK? boot

Если это сработало, модуль ядра по какой-либо причине не загрузился правильно. Добавьте строку

options GEOM_MIRROR

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

Примечания

1. Следует заметить, что после комментирования записи о разделе подкачки в файле fstab вам, скорее всего, потребуется разрешить подкачку каким-либо другим способом. Обратитесь к Разд. 11.14 за дополнительной информацией.
^

Глава 19. Менеджер дискового пространства Vinum


Изначально написано Greg Lehey. Перевод на русский язык: Дмитрий Морозовский.

19.1. Краткая аннотация


Какие бы диски у вас ни были, они всегда будут подвержены ограничениям:

• Слишком маленькие

• Слишком медленные

• Недостаточно надежные

Для того, чтобы обойти эти ограничения, можно использовать несколько (и, возможно, избыточное число) дисков.

В дополнение к поддержке разнообразных контроллеров RAID, базовая система FreeBSD включает Менеджер дискового пространства Vinum — драйвер, реализующий поддержку виртуальных дисков.

Vinum позволяет более гибко оперировать дисковым пространством, повысить производительность и надежность дисковой подсистемы за счет реализации моделей RAID-0, RAID-1 и RAID-5, а также их комбинаций.

В данной главе кратко рассматриваются потенциальные проблемы традиционной системы хранения данных и методы их решения при помощи Vinum.

Замечание: Начиная с версии 5 FreeBSD, подсистема Vinum была переписана для того, чтобы стать совместимой с архитектурой GEOM (см. Гл. 18), при сохранении исходных идей, терминологии и формата хранимых на диске метаданных. Новая подсистема называется gvinum (сокращение от GEOM vinum). Дальнейший текст обычно использует термин Vinum как абстрактное название, вне зависимости от варианта реализации. Все реальные команды должны использовать gvinum, а имя модуля ядра сменено с vinum.ko на geom_vinum.ko; файлы устройств располагаются в каталоге /dev/gvinum, а не /dev/vinum. Начиная с FreeBSD 6, старая реализация Vinum удалена из дерева исходных текстов.
^

19.2. Диски слишком малы


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

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

19.3. Ограниченная пропускная способность


Современным системам часто необходим одновременный доступ ко многим данным. В частности, крупный FTP или HTTP-сервер может обслуживать тысячи одновременных соединений, поступающих по нескольким 100 Mbit/s каналам во внешний мир, что ощутимо превышает скорость передачи данных большинства дисков.

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

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

Рассмотрим типичный запрос на передачу 10 kB информации. Современные высокопроизводительные диски подводят головки в нужную позицию в среднем за 3.5 миллисекунды. Самые быстрые диски вращаются со скоростью 15000 об/мин, так что среднее время на подход первого сектора к головке (rotational latency, половина времени одного оборота) составит еще 2 миллисекунды. При линейной скорости передачи данных в 70 MB/s собственно чтение/запись займет около 150 микросекунд — исчезающе мало по сравнению с временем позиционирования. В нашем случае, эффективная скорость передачи данных падает почти до 1 MB/s и, очевидно, сильно зависит от размера передаваемого блока.

Традиционным и очевидным решением этой проблемы является принцип ''больше шпинделей'': вместо использования одного большого диска можно применить несколько дисков меньшего размера. Диски позиционируют головки и передают данные независимо, так что эффективная пропускная способность возрастает примерно во столько раз, сколько дисков мы применяем.

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

Равномерность распределения нагрузки на диски серьезно зависит от способа распределения по ним данных. В терминах дальнейшего обсуждения, будет удобно представить пространство хранения набором большого количества секторов с данными, которые адресуются по номеру, подобно страницам в книге. Наиболее очевидным методом будет поделить виртуальный диск на группы расположенных последовательно секторов размером с физический диск (которые будут подобны разделам книги). Этот метод называется конкатенацией или сцеплением (concatenation); его преимуществом является то, что он не налагает никаких ограничений на размеры применяемых дисков. Конкатенация эффективна, если нагрузка на дисковое пространство распределена равномерно. В случае концентрации нагрузки в малой области диска увеличение производительности не будет заметно. Организация секторов на сцепленных единицах хранения показана на Рис. 19-1.

^ Рисунок 19-1. Организация сцепленных дисков



По сравнению с зеркалированием преимуществом RAID-5 является гораздо меньшее требование к объему дисков. Скорость чтения сравнима с чтением в случае томов с перемежением, а вот запись происходит ощутимо медленнее (примерно вчетверо медленнее чтения). При отказе одного из дисков массив продолжает работать в "деградировавшем" режиме: запросы на чтение с оставшихся дисков производятся обычным образом, а блоки с отказавшего диска перевычисляются из данных остальных блоков страйпа.
^

19.5. Объекты Vinum


Для обеспечения необходимой функциональности Vinum использует четырехуровневую иерархию объектов:

• "Видимая снаружи" сущность — виртуальный диск, называемый томом (volume). Тома в основном аналогичны дискам UNIX, хотя имеются и мелкие различия. На тома нет ограничений по размеру.

• Тома образуются из наборов (plex), каждый из которых представляет полное адресное пространство тома. Данный уровень иерархии, таким образом, реализует избыточность. Наборы являются аналогами отдельных дисков в зеркалированном массиве; содержимое наборов идентично.

• Поскольку Vinum работает в среде подсистемы хранения данных UNIX, многодисковые наборы можно было бы реализовать на базе дисковых разделов UNIX. На практике, подобная реализация недостаточно гибка (диски UNIX могут иметь весьма ограниченное число разделов). Вместо этого Vinum вводит еще один уровень абстракции: единый дисковый раздел UNIX (drive в терминах Vinum) делится на непрерывные области, называемые поддисками (subdisk), которые и будут "строительным материалом" для наборов.

• Поддиски, как уже упоминалось, располагаются внутри приводов (drive) Vinum, существующих дисковых разделов UNIX. Привод может содержать неограниченное количество поддисков. Небольшая область в начале привода зарезервирована под хранение информации о конфигурации и состоянии Vinum; все остальное пространство пригодно для хранения данных.

Сейчас мы опишем, как эта иерархия обеспечивает необходимую функциональность для Vinum.
^

19.5.1. Размер тома


Наборы могут состоять из большого количества поддисков, распределенных по разным приводам Vinum. Стало быть, размеры отдельных дисков не ограничивают размер набора, а следовательно, и тома.

19.5.2. Избыточность


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

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

19.5.3. Производительность


Vinum поддерживает как конкатенацию, так и перемежение на уровне наборов:

Сцепленный набор использует пространство поддисков последовательно, склеивая их "встык".

Набор с перемежением разбивает данные по поддискам в соответствии с размером страйпа. Поддисков должно быть по меньшей мере два (чтобы отличить набор от сцепленного), и все они должны быть одинакового размера.
^

19.5.4. Организация наборов: что выбрать?


Vinum, распространяемый с FreeBSD версии 6.1 поддерживает два вида организации наборов:

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

• Основным преимуществом наборов с перемежением (RAID-0) является распределение "горячих точек" нагрузки; вы можете даже полностью уравнять ее, выбрав оптимальный размер страйпа (около 256 kB). Недостатки такой организации — более сложный код и ограничения на поддиски: все они должны быть строго одного размера. Кроме того, процесс добавления поддиска в набор с перемежением "на ходу" является настолько нетривиальной задачей, что в настоящее время Vinum не поддерживает эту операцию. Дополнительное (тривиальное) ограничение состоит в том, что набор с перемежением должен содержать как минимум два поддиска, иначе он будет неотличим от сцепленного.

Преимущества и недостатки различных методов организации наборов описаны в Табл. 19-1.

^ Таблица 19-1. Методы организации наборов Vinum

^ Тип набора

Поддисков, мин.

Расширяется "на лету"

Поддиски строго одного размера

Применение

сцепленный (concatenated)

1

да

нет

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

с перемежением (striped)

2

нет

да

Высокая производительность, в том числе в случае параллельного доступа к данным




Скачать 14.45 Mb.
оставить комментарий
страница9/27
Дата18.10.2011
Размер14.45 Mb.
ТипРуководство, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы: 1   ...   5   6   7   8   9   10   11   12   ...   27
отлично
  1
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Документы

Рейтинг@Mail.ru
наверх