diff --git a/ru/security/security.sgml b/ru/security/security.sgml
index 850e7db9f6..fb062ddbf7 100644
--- a/ru/security/security.sgml
+++ b/ru/security/security.sgml
@@ -1,663 +1,328 @@
-
+
+ %developers;
]>
&header;
Введение
- Эта веб-страница создана для того, чтобы помочь как начинающим, так и
+
Эта веб-страница предназначена для помощи начинающим и
опытным пользователям в области информационной безопасности FreeBSD.
Во FreeBSD вопросы безопасности воспринимаются весьма серьёзно и постоянно
- работают над тем, чтобы сделать ОС защищённой настолько, насколько это
+ идет работа над тем, чтобы сделать ОС защищённой настолько, насколько это
вообще возможно.
- Здесь вы найдёте информацию или ссылки на информацию о том, как защитить
- вашу систему от различных типов атак, с кем связаться, если вы
- нашли недочёт в системе безопасности и так далее. Сюда также включён
- раздел, в котором описаны различные способы, прибегнув к которым, системный
- программист может с большей вероятностью избегнуть дыр в защите.
-
-
Содержание
- Политика отработки информации
-
- Бюллетени безопасности FreeBSD
-
- Информация о списках рассылки, посвящённых
- информационной безопасности FreeBSD
+ Дополнительные ресурсы, посвященные информационной безопасности
- Советы и рекомендации по обеспечению безопасности
+
- Рекомендации по безопасному программированию
+
+ Как и куда сообщать о проблеме информационной безопасности FreeBSD
- Прочая информация, касающаяся безопасности
+ Все проблемы информационной безопасности FreeBSD следует направлять на
+ адрес службы информационной
+ безопасности FreeBSD или, если необходим более высокий уровень
+ конфиденциальности, в зашифрованном в PGP виде на адрес службы Офицера информационной
+ безопасности, используя
+ ключ PGP Офицера информационной безопасности. Как минимум, все
+ сообщения должны содержать:
+
+
+ - Описание уязвимости.
+ - Какие версии FreeBSD предположительно затронуты, по возможности.
+ - Любые состоятельные пути обхода проблемы.
+ - Примеры кода, по возможности.
+ После сообщения этой информации с вами свяжется Офицер информационной
+ безопасности или представитель службы информационной безопасности.
+
+ Спам-фильтры
+
+ В связи с высоким уровнем спама основные контактные почтовые адреса
+ по информационной безопасности подвергаются фильтрации спама. Если Вы
+ не можете связаться с Офицерами информационной безопасности FreeBSD или
+ со службой информационной безопасности из-за спам-фильтров (или
+ предполагаете, что ваш адрес был отфильтрован), пожалуйста, отправьте
+ письмо на security-officer-XXXX@FreeBSD.org с заменой
+ XXXX на 3432 вместо использования обычных адресов.
+ Обратите внимание, что этот адрес будет периодически меняться, поэтому
+ следует проверять здесь последний адрес. Сообщения на этот адрес будут
+ перенаправлены службе Офицера информационной безопасности FreeBSD.
Офицер информационной безопасности FreeBSD и служба информационной
безопасности FreeBSD
- Для того, чтобы лучше координировать обмен информацией с сообществом,
- занимающимся вопросами безопасности, во FreeBSD имеется точка для
- соответствующих коммуникаций: Офицер информационной безопасности
- FreeBSD.
-
- Если вы хотите обратиться в Проект FreeBSD по поводу возможной проблемы в
- информационной безопасности, то вы должны написать письмо Офицеру
- информационной безопасности с описанием того, что вы нашли и
- характером нарушения безопасности, с которым вы столкнулись.
-
Для того, чтобы Проект FreeBSD мог оперативно реагировать на сообщения об
уязвимостях, почтовый алиас Офицера информационной безопасности
- соответствует четырём персонам: Офицер информационной безопасности,
- заместитель Офицера информационной безопасности и два члена
- Основной группы разработчиков. Таким образом, сообщения, посланные в адрес
+ соответствует трем персонам: Офицер информационной безопасности,
+ заместитель Офицера информационной безопасности и один член
+ Основной группы разработчиков. Таким образом, сообщения, посланные на адрес
почтового алиаса
<security-officer@FreeBSD.org>, доставляются следующим лицам:
- | Jacques Vidrine <nectar@FreeBSD.org> |
-
+ &a.cperciva; <cperciva@FreeBSD.org> |
Офицер информационной безопасности |
-
- | Chris Faulhaber <jedgar@FreeBSD.org> |
-
+ &a.simon <simon@FreeBSD.org> |
Заместитель Офицера информационной безопасности |
-
- | Robert Watson &a.rwatson <rwatson@FreeBSD.org> |
-
- Член Основной группы разработчиков FreeBSD, представитель группы по
- выпуску релизов,
+ | Представитель Основной группы разработчиков FreeBSD, представитель
+ группы по выпуску релизов,
представитель Проекта TrustedBSD, эксперт по архитектуре системной
безопасности |
-
-
- | Warner Losh <imp@FreeBSD.org> |
-
- Представитель Основной группы разработчиков FreeBSD, Офицер
- безопасности в отставке |
-
Офицер информационной безопасности поддерживается Службой безопасности FreeBSD
- <security-team@FreeBSD.org>, группой коммиттеров, которую он
- выбирает сам.
-
- Пожалуйста, используйте PGP-ключ
- Офицера информационной безопасности для шифрования своих сообщений,
- направляемых ему, когда это требуется.
+ href="&enbase;/administration.html#t-secteam" >Службой безопасности
+ FreeBSD <secteam@FreeBSD.org>,
+ небольшой группой коммиттеров, которую он выбирает сам.
- Политика отработки информации
+ Политика обработки информации
Как общее правило, Офицер безопасности FreeBSD предпочитает полное
раскрытие информации об уязвимости после достаточного перерыва на
выполнение тщательного анализа и устранения уязвимости, а также
соответствующего тестирования исправления и взаимодействия с другими
затронутыми командами.
Офицер безопасности будет уведомлять одного или большее
- количество администраторов кластера
- FreeBSD об уязвимостях, которые подвергают ресурсы Проекта FreeBSD
- непосредственной опасности.
+ количество администраторов кластера об уязвимостях, которые подвергают
+ ресурсы Проекта FreeBSD непосредственной опасности.
Офицер безопасности может привлечь дополнительных разработчиков FreeBSD
или внешних разработчиков к обсуждению предоставленной информации об
уязвимости, если требуется их экспертиза для полного понимания или
исправления проблемы. Будет выполнено необходимое разграничение для
минимизации ненужного распространения информации о представленной
уязвимости, и все привлечённые эксперты будут действовать в соответствии с
указаниями Офицера безопасности. В прошлом привлекались эксперты с большим
опытом работы с высокосложными компонентами операционной системы, включая
- FFS, подсистема VM и стек сетевых протоколов.
+ FFS, подсистему VM и стек сетевых протоколов.
Если уже выполняется процесс выпуска релиза FreeBSD, то инженер,
ответственный за выпуск релиза, может также быть оповещён об имеющейся
уязвимости и её серьёзности, чтобы было принято решение об информировании
относительно цикла выпуска релиза и наличии каких-либо серьёзных ошибок
в программном обеспечении, связанном с готовящимся релизом. Если
это будет необходимо, то Офицер безопасности не будет сообщать подробную
информацию о природе уязвимости Инженеру по выпуску релиза, ограничиваясь
информацией о её существовании и серьёзности.
Офицер безопасности FreeBSD поддерживает тесные рабочие отношения со
многими другими организациями, включая сторонних разработчиков, имеющих
- с FreeBSD общий код (проекты OpenBSD и NetBSD, Apple и другие разработчики,
+ с FreeBSD общий код (проекты OpenBSD, NetBSD и DragonFlyBSD, Apple и
+ другие разработчики,
программное обеспечение которых основано на FreeBSD, а также разработчики
Linux), и организации, которые отслеживают уязвимости и случаи нарушения
информационной безопасности, такие, как CERT. Зачастую уязвимости выходят
за рамки реализации FreeBSD, и (наверное, реже) могут иметь широкий
резонанс для всего сетевого сообщества. В таких условиях Офицер
безопасности может раскрыть информацию об уязвимости этим сторонним
организациям: если вы не хотите, чтобы Офицер безопасности это делал,
пожалуйста, явно укажите это в своих сообщениях.
Сообщающие должны тщательно и явно указать любые свои требования
- относительно отработки сообщённой информации.
+ относительно обработки сообщённой информации.
Если сообщающий об уязвимости заинтересован в координации процесса
раскрытия с ним и/или другими разработчиками, это должно быть явно указано
в сообщениях. При отсутствии явных требований Офицер безопасности FreeBSD
выберет план раскрытия информации, который учитывает как требования
оперативности, так и тестирования любых решений. Сообщающие должны иметь
в виду, что если уязвимость активно обсуждается в открытых форумах (таких,
как bugtraq) и используется, то Офицер Безопасности может решить не
следовать предлагаемому плану по её раскрытию, для того, чтобы дать
пользовательскому сообществу максимально эффективную защиту.
- Сообщающие должны иметь в виду, что Проект FreeBSD является проектом с
- открытым кодом, и информация о любом изменении в дереве исходного кода
- FreeBSD доступна всем. Если предложен план по раскрытию уязвимости, то
- он должен принимать во внимание как официальный выпуск бюллетеня по
- безопасности, патча и информации об обновлении, а также изначальное
- включение исправлений в дерево исходного кода FreeBSD. Обязателен
- временной промежуток между включением исправлений в дерево и созданием
- и выпуском официальных объявлений, патчей, двоичных обновлений, так как
- для их создания используется система управления исходным кодом.
-
Сообщения могут быть защищены с помощью PGP. Если это нужно, то ответы
также будут защищены посредством PGP.
-
- Бюллетени безопасности FreeBSD
+
+ Поддерживаемые релизы FreeBSD
- Служба информационной безопасности FreeBSD выпускает бюллетени
+
Офицер информационной безопасности FreeBSD выпускает бюллетени
безопасности для нескольких разрабатываемых веток FreeBSD. Это
Ветки -STABLE и Ветки Security. (Бюллетени не
выпускаются для Ветки -CURRENT.)
- Обычно здесь присутствует только одна ветка -STABLE, хотя в процессе
- перехода от одной основной линии разработки к другой (например, с FreeBSD
- 4.x на 5.x) имеется временной интервал, в котором существуют две ветки
- -STABLE. Тэги ветки -STABLE носят имена типа RELENG_4.
- Соответствующие версии носят названия типа FreeBSD
- 4.6-STABLE.
Тэги ветки -STABLE носят
+ имена типа RELENG_7. Соответствующие сборки носят
+ названия типа FreeBSD 7.0-STABLE.
Каждому релизу FreeBSD поставлена в соответствие ветка безопасности
- (Security Branch). Метки веток безопасности именуются как
- RELENG_4_6. Соответствующие построенные версии носят названия
- типа FreeBSD 4.6-RELEASE-p7.
- Каждая ветка поддерживается службой безопасности ограниченное время,
- обычно до 12 месяцев после релиза. Ожидаемые времена жизни для
- поддерживаемых в настоящее время веток даны ниже. В колонке
- Ожидаемое время жизни указана ближайшая дата, по истечение
- которой ветка будет брошена. Пожалуйста, учтите, что эти сроки в будущем
- могут быть увеличены, но только исключительные обстоятельства могут
- привести к отказу от поддержки ветки раньше указанной даты.
+ Проблемы, затрагивающие Коллекцию портов FreeBSD, описываются в документе FreeBSD VuXML.
+
+ Каждая ветка поддерживается Офицером безопасности в течение
+ ограниченного времени. Ветки разделены на типы, которые определяют срок
+ жизни, как показано ниже.
+
+
+ - Раннее внедрение (Early Adopter)
+ - Релизы, выпускаемые из ветки -CURRENT, будут поддерживаться Офицером
+ безопасности как минимум в течение 6 месяцев после выхода.
+ - Обычный (Normal)
+ - Релизы, выпускаемые из ветки -STABLE, будут поддерживаться Офицером
+ безопасности как минимум в течение 12 месяцев после выхода и в течение
+ дополнительного времени (если потребуется), достаточного, чтобы
+ следующий релиз был выпущен по крайней мере за 3 месяца до истечения
+ срока поддержки предыдущего Обычного релиза.
+
+ - Расширенный (Extended)
+ - Отобранные релизы (обычно, каждый второй релиз и последний релиз из
+ каждой ветки -STABLE) будут поддерживаться Офицером безопасности как
+ минимум в течение 24 месяцев после выхода и в течение дополнительного
+ времени (если потребуется), достаточного, чтобы следующий Расширенный
+ релиз был выпущен по крайней мере за 3 месяца до истечения срока
+ поддержки предыдущего Расширенного релиза.
+
+
+
+
+
+ Ниже приводятся текущее назначение и ожидаемое время жизни для
+ поддерживаемых в настоящее время веток. В колонке
+ Ожидаемое окончание срока жизни указана ближайшая дата, по истечении
+ которой будет прекращена поддержка ветки. Пожалуйста, учтите, что эти
+ даты могут быть сдвинуты в будущее, но только исключительные обстоятельства
+ могут привести к отказу от поддержки ветки раньше указанной даты.
| Ветка |
Релиз |
- Ожидаемое время жизни |
+ Тип |
+ Дата выхода |
+ Ожидаемое окончание срока жизни |
-
- | RELENG_4 |
+ RELENG_6 |
n/a |
- 31 октября 2004 |
+ n/a |
+ n/a |
+ 30 ноября 2010 |
-
- | RELENG_4_8 |
- 4.8-RELEASE |
- 31 марта 2004 |
+ RELENG_6_4 |
+ 6.4-RELEASE |
+ Расширенный |
+ 28 ноября 2008 |
+ 30 ноября 2010 |
-
- | RELENG_4_9 |
- 4.9-RELEASE |
- 31 октября 2004 |
+ RELENG_7 |
+ n/a |
+ n/a |
+ n/a |
+ последний релиз + 2 года |
-
- | RELENG_5_2 |
- 5.2-RELEASE |
- 31 июля 2004 |
+ RELENG_7_1 |
+ 7.1-RELEASE |
+ Расширенный |
+ 4 января 2009 |
+ 31 января 2011 |
+
+
+ | RELENG_7_2 |
+ 7.2-RELEASE |
+ Обычный |
+ 4 мая 2009 |
+ 31 мая 2010 |
+
+
+ | RELENG_8 |
+ n/a |
+ n/a |
+ n/a |
+ последний релиз + 2 года |
+
+
+ | RELENG_8_0 |
+ 8.0-RELEASE |
+ Обычный |
+ 25 ноября 2009 |
+ 30 ноября 2010 |
Более старые релизы не поддерживаются, а их пользователям настоятельно
рекомендуется произвести обновление до одной из поддерживаемых версий,
указанных выше.
- Как и все направления разработки, исправления в защите системы сначала
- испытываются в ветке
- FreeBSD-current. После нескольких дней некоторого тестирования
- исправления переносятся в поддерживаемые ветки FreeBSD-stable и
- выпускается очередной бюллетень.
-
- Немного статистики по бюллетеням, выпущенным в течение 2002 года:
-
-
- - 44 бюллетеня с проблемами различной степени опасности касались
- базовой системы.
-
- - 12 бюллетеней описывали уязвимости, касающиеся только FreeBSD.
- Остальные 32 бюллетеня являлись проблемами, общими как минимум с одной
- из других ОС (часто по причине использования одного и того же кода).
-
- - Было выпущено 6 замечаний по безопасности, которые касались 95 проблем
- в дополнительных приложениях сторонних разработчиков, входящих в
- Коллекцию Портов.
-
-
Бюллетени рассылаются в следующие списки рассылки FreeBSD:
-
- FreeBSD-security-notifications@FreeBSD.org
- FreeBSD-security@FreeBSD.org
- FreeBSD-announce@FreeBSD.org
- Бюллетени всегда подписываются с помощью PGP-ключа
- Офицера Безопасности и помещаются, вместе с соответствующими исправлениями,
- в наш архив. На
- момент написания этого текста вышли следующие бюллетени (заметьте, что этот
- список может быть устаревшим на несколько дней - самые последние бюллетени
- находятся на
- FTP-сервере):
+ Список выпущенных бюллетеней можно найти на странице FreeBSD Security Advisories.
- &advisories.html.inc;
-
-
- Информация о списках рассылки, посвящённых безопасности FreeBSD
-
- Если вы администрируете или эксплуатируете некоторое количество систем
- FreeBSD, вам полезно быть подписанным на один или несколько из следующих
- списков рассылки:
-
-
-
-
-
- Рекомендации по безопасному программированию
-
-
-- Никогда не доверяйте никаким входным данным, будь то аргументы командной
- строки, переменные окружения, конфигурационные файлы, входящие пакеты
- 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_EXCL
-
- Если вы используете 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 для любых открываемых файловых дескрипторов.
-
-
-
- Полезным инструментом аудита является порт its4, находящийся в каталоге
- /usr/ports/security/its4/. Это автоматизированный аудитор кода на языке C,
- который выявляет потенциальные проблемы в коде. Это полезная однопроходная
- утилита, но на неё не стоит полагаться, а полный аудит должен включать
- проверка всего кода человеком.
-
- За дополнительной информацией о технике безопасного программирования
- и посвящённым этому вопросу ресурсах обратитесь к странице How to Write Secure Code.
-
-
- Советы и рекомендации по безопасности 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 также предоставляет
- подробную информацию
- о том, что нужно предпринять в случае нарушения безопасности системы.
-
-
- Другие источники информации, касающиеся безопасности
-
-
+ Бюллетени всегда подписываются с использованием PGP-ключа
+ Офицера Безопасности и помещаются, вместе с соответствующими
+ исправлениями, на web-сервер http://security.FreeBSD.org/
+ в поддиректории advisories и patches.
&footer
-
-
+