diff --git a/ru/security/security.sgml b/ru/security/security.sgml
new file mode 100644
index 0000000000..8f329ead5f
--- /dev/null
+++ b/ru/security/security.sgml
@@ -0,0 +1,497 @@
+
+
+
+ %includes;
+]>
+
+
+
+ &header;
+
+Введение
+
+Эта веб-страница создана для того, чтобы помочь как начинающим, так и
+ опытным пользователям, в области безопасности операционной системы FreeBSD.
+ Команда разработчиков FreeBSD воспринимает вопросы безопасности очень
+ серьезно и постоянно работает над тем, чтобы сделать ОС защищенной
+ настолько, насколько это вообще возможно.
+
+Здесь вы найдете информацию или ссылки на информацию о том, как защитить
+ вашу систему от различных типов внешних атак, с кем связаться, если вы
+ нашли недочет в системе безопасности, итд. Сюда также включен раздел,
+ в котором описаны различные способы, прибегнув к которым, системный
+ программист может с большей вероятностью избегнуть дыр в защите.
+
+Содержание
+
+
+
+Офицер Безопасности FreeBSD
+
+Для того, чтобы лучше координировать обмен информацией с сообществом,
+ занимающимся вопросами безопасности, во FreeBSD имеется точка для
+ соответствующих коммуникаций: офицер безопасности.
+ Эту должность занимает группа выделенных для этого офицеров
+ безопасности, их главной задачей является рассылка бюллетеней при
+ обнаружении дыр в системе безопасности и реагирование на сообщения о
+ возможных проблемах с безопасностью во FreeBSD.
+
+Если вы хотите связаться с кем-нибудь из команды FreeBSD по поводу
+ возможной ошибки в защите, то, пожалуйста, напишите письмо Офицеру
+ Безопасности с описанием того, что вы нашли и характером нарушения
+ безопасности, с которым вы столкнулись. Офицеры Безопасности также
+ общаются с различными командами из CERT
+ и FIRST по всему миру, распространяя
+ информацию о возможных нарушениях безопасности во FreeBSD и утилитах,
+ часто используемых во FreeBSD. Офицеры Безопасности также являются
+ активными членами этих организаций.
+
+Если вы хотите обратиться к Офицеру Безопасности по поводу некоторой
+ особо щепетильной проблемы, воспользуйтесь ключами
+ PGP для шифрования вашего сообщения перед его отправкой.
+
+
+Бюллетени безопасности FreeBSD
+
+Офицеры Безопасности FreeBSD выпускают бюллетени безопасности для
+ следующих релизов FreeBSD:
+
+
+- Самый последний официальный релиз FreeBSD.
+
- FreeBSD-current.
+
- FreeBSD-stable, после того, как из этой ветки было выпущено по
+ крайней мере 2 релиза.
+
- Предыдущая ветка FreeBSD-stable, пока из новой ветви -stable еще
+ не выпущено 2 релиза.
+
+
+В настоящее время бюллетени безопасности имеются для:
+
+- FreeBSD 3.3
+
- FreeBSD 3.4
+
- FreeBSD-current
+
- FreeBSD-stable
+
+
+Более старые релизы не поддерживаются и пользователям строго рекомендуется
+ произвести обновление до одной из поддерживаемых версий, указанных
+ выше.
+
+Как и все направления разработки, исправления в защите системы сначала
+ испытываются в ветке FreeBSD-current. После
+ нескольких дней некоторого тестирования исправления переносятся в
+ поддерживаемые ветки FreeBSD-stable и выпускается очередной бюллетень.
+
+Бюллетени рассылаются в следующие списки рассылки FreeBSD:
+
+- FreeBSD-security-notifications@FreeBSD.org
+
- FreeBSD-security@FreeBSD.org
+
- FreeBSD-announce@FreeBSD.org
+
+
+
+Бюллетени всегда подписываются с помощью PGP-ключа
+ Офицера Безопасности и помещаются, вместе с соответствующими исправлениями,
+ в наш архив. На
+ момент написания этого текста вышли следующие бюллетени:
+
+
+
+
+Информация о списках рассылки, посвященных безопасности FreeBSD
+
+Если вы администрируете или эксплуатируете некоторое количество систем
+ FreeBSD, вам полезно быть подписанным на один или несколько из следующих
+ списков рассылки:
+
+
+ freebsd-security Обсуждение общих вопросов безопасности
+ freebsd-security-notifications Уведомления, касающиеся безопасности (модерируемый список рассылки)
+
+
+ Пошлите письмо на адрес
+ majordomo@FreeBSD.ORG со строчкой
+
+ subscribe <listname> [<optional address>]
+
+ в тексте письма для того, чтобы подписаться. Например, так:
+
+ % echo "subscribe freebsd-security" | mail majordomo@FreeBSD.org
+
+ и если вы хотите отписаться от списка рыссылки:
+
+ % echo "unsubscribe freebsd-security" | mail majordomo@FreeBSD.org
+
+
+
+Рекомендации по безопасному программированию
+
+
+- Никогда не доверяйте никаким входным данным, будь то аргументы командной
+ строки, переменные окружения, конфигурационные файлы, входящие пакеты
+ TCP/UDP/ICMP, имена хостов, аргументы функций итд. Если размер
+ полученных данных является фактором, контролируемым извне, то программа
+ или функция должна эти данные проверять при копировании. Особо стоит
+ обратить внимание на следующие моменты:
+
+
+- strcpy() и sprintf(), применяемые к данным, размер которых неизвестен.
+ Используйте strncpy и snprintf(), когда размер известен (или выполняйте
+ какие-то другие формы проверки границ данных, когда их длина неизвестна).
+ В частности, никогда не используйте функции gets() или sprintf(), точка.
+ Если вы все же будете это делать, мы вас проклянем.
+
+
+- Если вы осуществляете проверку ввода пользователя на то, чтобы он не
+ содержал неверные символы, НЕ проверяйте наличие неправильных символов.
+ Вместо этого просто проверяйте, что во входном потоке содержатся ТОЛЬКО
+ разрешенные символы. Общий принцип: запрет всего, что явно не разрешено.
+
+
+- Прочтите страницы Справочника по функциям strncpy() и strncat().
+ Удостоверьтесь, что вы правильно понимаете их работу!!! Функция strncpy()
+ может не добавлять терминирующий \0, когда как strncat() это делает.
+
+
+- Отслеживайте использование функций strvis() и getenv(). При использовании
+ strvis() легко получить неправильную целевую строку, а getenv()
+ может вернуть результатом строчки, намного превышающие то, что ожидает ваша
+ программа. Использование этих функций является одним из основных методов
+ выполнения атак на систему, при которой установка необычных значений
+ переменных окружения приводит к изменению значения стека и переменных
+ внутри программы. Если ваша программа использует переменные окружения,
+ будьте осторожны. Будьте сверхосторожны!
+
+
+- Каждый раз при использовании вызовов open() или stat() спросите себя:
+ "Что, если это - символическая ссылка?"
+
+
+- Всегда используйте mkstemp() вместо mktemp(), tempnam(), итд. Также
+ в общем будьте осторожны при работе в /tmp, имея в виду, что в /tmp
+ очень мало атомарных операций:
+
+ - Создание каталога. Оно может быть удачным или с ошибкой.
+ - Открытие файла O_CREAT | O_EXECL
+
+ Если вы используете mkstemp(), то вышеуказанные случаи обрабатываются
+ корректно. Поэтому все временные файлы должны быть созданы с
+ использованием mkstemp() для гарантии того, что нет совпадения имен и
+ все права доступа выставляются верно.
+
+
+- Если атакующий может посылать пакеты от имени другой произвольной
+ системы, то он получает полный контроль над данными, которые мы получаем
+ и НИКАКИМ из них мы не должны доверять.
+
+
+- Никогда не полагайтесь на то, что конфигурационный файл имеет
+ правильный формат или что он сгенерирован соответствующей утилитой. Не
+ доверяйте пользовательскому вводу, который касается имен терминалов и
+ не думайте, что в вводимых строках не будет подстрок '/' или '../../../',
+ если есть хоть какой-то шанс, что они будут использованы в качестве
+ маршрута к файлу. Не доверяйте НИКАКИМ путям, которые ввел
+ пользователь, когда вы работаете с правами суперпользователя.
+
+
+- Ищите бреши и недочеты в способе хранения данных. Все временные
+ файлы должны иметь права 600 для того, чтобы быть защищенными от
+ любопытных глаз.
+
+
+- Не просто ищите обычные подозрительные места в программах, которые
+ выполняются с повышенными привилегиями. Просмотрите код строчку за
+ строчкой в поиске возможных в этих случаях переполнений, так как имеется
+ гораздо больше способов вызвать переполнение буфера, чем просто используя
+ strcpy() со товарищи.
+
+
+- Если вы где-то понизили привилегии, это вовсе не значит, что в программа
+ не подвержена атакам. Атакующий может поместить соответствующий код в
+ стек, чтобы вернуть привилегированный режим перед выполнением
+ /bin/sh.
+
+
+- Управляйте значением uid. Меняйте привилегии как можно быстрее, и
+ меняйте их на самом деле. Переключение между euid и uid НЕ достаточно.
+ Используйте setuid() везде, где это возможно.
+
+
+- Никогда не выводите содержимого конфигурационного файла при возникновении
+ ошибок. Достаточно номера строки и может быть, позиции в строке. Это
+ нужно делать для всех библиотек и любой программы с установленными битами
+ suid/sgid.
+
+
+- Советы для тех, кто проверяет имеющийся код на наличие проблем
+ с безопасностью:
+
+
+- Если вы не уверены в правильности ваших исправлений, пошлите их
+ обозревателю, с которым у вас уже есть договоренность на просмотр вашего
+ кода. Не выполняйте коммит кода, в котором вы не уверены, так как
+ нарушение работы чего-либо из-за исправлений во имя безопасности приводит
+ в некоторое замешательство.
+
+
+- Те, у кого нет привилегий на CVS для выполнения операции commit, должны
+ понимать, что обозреватель с такими привилегиями должен просмотреть
+ изменения. Этот человек должен просмотреть и включить окончательную версию
+ в дерево CVS.
+
+
+- При посылке изменений для просмотра, всегда используйте diff в форматах
+ context или unidiff - в этих случаях изменения могут быть легко переданы
+ программе patch(1). Не посылайте просто файлы полностью. Файлы diff
+ гораздо легче читать и вносить изменения из них в исходные тексты (особенно
+ когда может иметь место много изменений в разных местах). Все изменения
+ должны делаться в ветке -current.
+
+
+- Всегда тестируйте ваши изменения непосредственно (например, компилируя
+ и запуская затрагиваемые программы) перед тем, как послать их обозревателю.
+ Никому не нравится получать нерабочий код для обозрения, что обычно
+ означает, что посылающий туда даже не заглядывал (что ещё более усиливает
+ недоверие к человеку). Если вам нужен вход на машину с конкретной версией,
+ которой у вас нет - просто спросите. У нас имеются ресурсы именно с
+ таким назначением.
+
+
+- Замечание для коммиттеров: не забудьте перенести патчи из ветки -current
+ в соответствующие места ветки -stable.
+
+
+- Не нужно без необходимости переписывать код в соответствии с вашим
+ стилем/вкусом - это только затруднит работу обозревателя. Делайте это,
+ если только на то имеются веские причины.
+
+
+- Обратите внимание на программы, которые выполняют сложные манипуляции
+ с обработчиками сигналов. Многие подпрограммы в различных библиотеках
+ недостаточно реентерабельны, чтобы делать это корректно.
+
+
+- Особое внимание уделите использованию realloc() - эта функция чаще всего
+ используется неправильно.
+
+
+- При использовании буферов фиксированного размера используйте sizeof()
+ во избежание несоответствия, когда размер буфера меняется, а код, который
+ его использует, нет. Например:
+
+ char buf[1024];
+ struct foo { ... };
+ ...
+ПЛОХО:
+ xxx(buf, 1024)
+ xxx(yyy, sizeof(struct foo))
+ХОРОШО:
+ xxx(buf, sizeof(buf))
+ xxx(yyy, sizeof(yyy))
+
+ Будьте внимательны при использовании sizeof() с указателями, когда вы
+ на самом деле хотите выяснить размер данных, к которым относится указатель!
+
+
+- Каждый раз, когда вы видите "char foo[###]", проверьте каждое
+ использование массива foo, чтобы удостовериться, что он не может быть
+ переполнен. Если вы не можете избежать переполнения (а такие случаи могут
+ иметь место), то, по крайней мере, выделяйте память под буфер операцией
+ malloc, чтобы никто не смог получить доступ к стеку.
+
+
+- Всегда закрывайте файловые дескрипторы, как только это можно сделать -
+ это делает более вероятным сброс содержимого буфера стандартного
+ ввода/вывода. В библиотечных процедурах всегда устанавливайте параметр
+ close-on-exec для любых открываемых файловых дескрипторов.
+
+
+
+
+Советы и рекомендации по безопасности FreeBSD
+Вот некоторые действия, которые вы должны предпринять, чтобы защитить
+ FreeBSD или фактически любую Unix-систему:
+
+
+- Отключение потенциально опасного программного обеспечения
+
+ Имеется большое количество программного обеспечения, которое для
+ использования специфических ресурсов запускается с правами особого
+ привилегированного пользователя, для чего на выполнимые файлы устанавливается
+ бит set-uid. Примерами таких программ являются UUCP и PPP, которые
+ используют последовательный порт, или sendmail, который работает с почтовой
+ очередью и привязывается к привилегированному сетевому порту. Если вы не
+ используете UUCP, вовсе не обязательно иметь ее в системе, и его можно
+ просто убрать. Конечно, это требует хорошего знания того, что может быть
+ выброшено, а что нет, и хорошее представление о том, захотите ли вы иметь
+ эту функциональность в будущем.
+
+ Вы можете обнаружить, что некоторые утилиты недостаточно полезны для того,
+ чтобы иметь их в системе с риском для безопасности, например, swapinfo.
+ Если вы уберете бит set-uid с выполнимого файла (с помощью команды
+ 'chmod ug-s filename'), вы сможете воспольоваться swapinfo, работая как
+ пользователь root. Однако это является не такой уж хорошей идеей, если,
+ убрав все биты set-uid, вам придется все время работать как
+ root.
+
+ Удалите не только программы, которыми вы не пользуетесь, но и сервисы,
+ которые вы не хотите или которые вам не нужно предоставлять. Это может быть
+ сделано путем редактирования файлов /etc/inetd.conf и
+ /etc/rc.conf с отключением в нем всех неиспользуемых
+ сервисов.
+
+ - Исправление программного обеспечения, в котором имеются проблемы с
+ безопасностью (или как быть на один шаг впереди крэкеров)
+
+ Подпишитесь на различные списки рассылки по безопасности
+ FreeBSD, чтобы получать известия об ошибках в безопасности и
+ исправления. Вносите исправления немедленно.
+
+ - Создание архивных копий для восстановления системы в случае нарушения
+ безопасности
+
+ Всегда имейте архивную копию и чистую версию операционной системы
+ (например, на CD-Rom). Проверьте, что архивные копии не содержат данных,
+ поврежденных или измененных в результате атаки.
+
+ - Установка программного обеспечения для отслеживания состояния
+ системы
+
+ Программы типа tcp wrappers и tripwire (оба находятся среди
+ пакаджей/портов) могут помочь проводить мониторинг работы системы. Это
+ облегчает обнаружение попыток взлома. Также читайте результаты работы
+ скриптов из /etc/security, которые запускаются ежедневно и посылают свои
+ сообщения по электронной почте пользователю root.
+
+ - Обучение людей, работающих в системе
+
+ Пользователи должны знать, что они делают. Им должно быть сказано, чтобы
+ они никому не передавали свои пароли и делали их трудными для отгадывания.
+ Дайте им понять, что безопасность системы/сети отчасти находится в
+ их руках.
+
+
+Имеется также документ FreeBSD Security How-To, в котором даются
+ некоторые подробные советы по усилению безопасности вашей системы. Вы
+ можете найти его по адресу
+ http://www.FreeBSD.org/~jkb/howto.html.
+
+Обеспечение безопасности - это динамичный процесс. Следуйте последним
+ разработкам в этой области.
+
+
+Что делать, если вы обнарущили нарушение безопасности
+
+
+- Определите серьезность нарушения безопасности
+ Какие привилегии получил атакующий? Получил ли он доступ с привилегиями
+ системного администратора? Или атакующий получил только доступ на уровне
+ обычного пользователя?
+
+- Определите, было ли изменено состояние системы (ядро или
+ пользовательская часть)
+
+ Какое программное обеспечение было изменено? Было ли установлено новое
+ ядро? Были ли модифицированы какие-либо системные программы (такие, как
+ telnetd, login, итд.)? Если вы полагаете, что атакующий мог сделать какие
+ угодно изменения в ОС, вы можете переустановить операционную систему с
+ безопасного носителя.
+
+- Определите, как был осуществлен взлом
+
+ Был ли взлом осуществел через хорошо известную ошибку в безопасности? Если
+ это так, установите соответствующие патчи. Был ли взлом осуществлен из-за
+ неправильной конфигурации? Или это была новая ошибка? Если вы думаете,
+ что это было неизвестная ошибка, вы должны прдупредить Офицера Безопасности
+ FreeBSD.
+
+- Устранение дыры в безопасности
+ Для устраниения проблемы установите новое программное обеспечение или патчи
+ к старому. Отключите всех пользователей, бюджеты которых были
+ взломаны.
+
+- Другие ресурсы
+ CERT также предоставляет
+ подробную информацию
+ о том, что нужно предпринять в случае нарушения безопасности системы.
+
+
+Другие источники информации, касающиеся безопасности
+
+
+ &footer
+
+