From owner-freebsd-www@FreeBSD.ORG Tue Feb 9 10:00:11 2010 Return-Path: Delivered-To: freebsd-www@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6136E106566C for ; Tue, 9 Feb 2010 10:00:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1F00F8FC16 for ; Tue, 9 Feb 2010 10:00:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o19A0A0w003810 for ; Tue, 9 Feb 2010 10:00:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o19A0ARe003809; Tue, 9 Feb 2010 10:00:10 GMT (envelope-from gnats) Resent-Date: Tue, 9 Feb 2010 10:00:10 GMT Resent-Message-Id: <201002091000.o19A0ARe003809@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-www@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, pluknet Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 470A11065787 for ; Tue, 9 Feb 2010 09:57:55 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 34CC38FC0C for ; Tue, 9 Feb 2010 09:57:55 +0000 (UTC) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o199vtgm060179 for ; Tue, 9 Feb 2010 09:57:55 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id o199vte2060178; Tue, 9 Feb 2010 09:57:55 GMT (envelope-from nobody) Message-Id: <201002090957.o199vte2060178@www.freebsd.org> Date: Tue, 9 Feb 2010 09:57:55 GMT From: pluknet To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: www/143695: ru/security/security.sgml: MFen 1.151 -> 1.209 X-BeenThere: freebsd-www@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD Project Webmasters List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 10:00:11 -0000 >Number: 143695 >Category: www >Synopsis: ru/security/security.sgml: MFen 1.151 -> 1.209 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-www >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Tue Feb 09 10:00:10 UTC 2010 >Closed-Date: >Last-Modified: >Originator: pluknet >Release: >Organization: >Environment: >Description: The "http://www.freebsd.org/ru/security/" page contains a much outdated Security information in Russian. The attached patch brings the Russian Security page up to date. Some links are (still) going to English www version (e.g. www/security/charter.html) I plan to submit more PRs to make those links follow to Russian www. Link integrity, style, etc are locally compile/look-tested. >How-To-Repeat: >Fix: Patch attached with submission follows: --- www.orig/ru/security/security.sgml 2010-02-07 19:06:53.000000000 +0300 +++ www/ru/security/security.sgml 2010-02-09 12:52:06.000000000 +0300 @@ -4,7 +4,7 @@ $FreeBSD: www/ru/security/security.sgml,v 1.18 2006/08/19 21:25:55 hrs Exp $ $FreeBSDru: frdp/www/ru/security/security.sgml,v 1.33 2004/09/21 07:31:12 den Exp $ - Original revision: 1.151 + Original revision: 1.209 --> + %developers; ]> @@ -20,110 +21,110 @@

Введение

-

Эта веб-страница создана для того, чтобы помочь как начинающим, так и +

Эта веб-страница предназначена для помощи начинающим и опытным пользователям в области информационной безопасности 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 предпочитает полное раскрытие информации об уязвимости после достаточного перерыва на @@ -132,9 +133,8 @@ затронутыми командами.

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

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

    Офицер безопасности может привлечь дополнительных разработчиков FreeBSD или внешних разработчиков к обсуждению предоставленной информации об @@ -144,7 +144,7 @@ уязвимости, и все привлечённые эксперты будут действовать в соответствии с указаниями Офицера безопасности. В прошлом привлекались эксперты с большим опытом работы с высокосложными компонентами операционной системы, включая - FFS, подсистема VM и стек сетевых протоколов.

    + FFS, подсистему VM и стек сетевых протоколов.

    Если уже выполняется процесс выпуска релиза FreeBSD, то инженер, ответственный за выпуск релиза, может также быть оповещён об имеющейся @@ -157,7 +157,8 @@

    Офицер безопасности FreeBSD поддерживает тесные рабочие отношения со многими другими организациями, включая сторонних разработчиков, имеющих - с FreeBSD общий код (проекты OpenBSD и NetBSD, Apple и другие разработчики, + с FreeBSD общий код (проекты OpenBSD, NetBSD и DragonFlyBSD, Apple и + другие разработчики, программное обеспечение которых основано на FreeBSD, а также разработчики Linux), и организации, которые отслеживают уязвимости и случаи нарушения информационной безопасности, такие, как CERT. Зачастую уязвимости выходят @@ -168,7 +169,7 @@ пожалуйста, явно укажите это в своих сообщениях.

    Сообщающие должны тщательно и явно указать любые свои требования - относительно отработки сообщённой информации.

    + относительно обработки сообщённой информации.

    Если сообщающий об уязвимости заинтересован в координации процесса раскрытия с ним и/или другими разработчиками, это должно быть явно указано @@ -180,78 +181,122 @@ следовать предлагаемому плану по её раскрытию, для того, чтобы дать пользовательскому сообществу максимально эффективную защиту.

    -

    Сообщающие должны иметь в виду, что Проект 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.

      • + (Security Branch). Тэги веток безопасности именуются как + RELENG_7_0. Соответствующие сборки носят названия + типа FreeBSD 7.0-RELEASE-p1.

    -

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

    +

    Проблемы, затрагивающие Коллекцию портов FreeBSD, описываются в документе FreeBSD VuXML.

    + +

    Каждая ветка поддерживается Офицером безопасности в течение + ограниченного времени. Ветки разделены на типы, которые определяют срок + жизни, как показано ниже.

    + +
    +
    Раннее внедрение (Early Adopter)
    +
    Релизы, выпускаемые из ветки -CURRENT, будут поддерживаться Офицером + безопасности как минимум в течение 6 месяцев после выхода.
    +
    Обычный (Normal)
    +
    Релизы, выпускаемые из ветки -STABLE, будут поддерживаться Офицером + безопасности как минимум в течение 12 месяцев после выхода и в течение + дополнительного времени (если потребуется), достаточного, чтобы + следующий релиз был выпущен по крайней мере за 3 месяца до истечения + срока поддержки предыдущего Обычного релиза. +
    +
    Расширенный (Extended)
    +
    Отобранные релизы (обычно, каждый второй релиз и последний релиз из + каждой ветки -STABLE) будут поддерживаться Офицером безопасности как + минимум в течение 24 месяцев после выхода и в течение дополнительного + времени (если потребуется), достаточного, чтобы следующий Расширенный + релиз был выпущен по крайней мере за 3 месяца до истечения срока + поддержки предыдущего Расширенного релиза. +
    +
    + + + +

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

    - + + + - - + + - + + - - - - + + + + + - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - + + + + +
    Ветка РелизОжидаемое время жизниТипДата выходаОжидаемое окончание срока жизни
    RELENG_4RELENG_6n/a n/a31 октября 2004n/a30 ноября 2010
    RELENG_4_84.8-RELEASE31 марта 2004RELENG_6_46.4-RELEASEРасширенный28 ноября 200830 ноября 2010
    RELENG_4_94.9-RELEASE31 октября 2004RELENG_7n/an/an/aпоследний релиз + 2 года
    RELENG_7_17.1-RELEASEРасширенный4 января 200931 января 2011
    RELENG_7_27.2-RELEASEОбычный4 мая 200931 мая 2010
    RELENG_8n/an/an/aпоследний релиз + 2 года
    RELENG_5_25.2-RELEASE31 июля 2004RELENG_8_08.0-RELEASEОбычный25 ноября 200930 ноября 2010
    @@ -259,405 +304,25 @@ рекомендуется произвести обновление до одной из поддерживаемых версий, указанных выше.

    -

    Как и все направления разработки, исправления в защите системы сначала - испытываются в ветке - 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-сервере):

    - - &advisories.html.inc; - - -

    Информация о списках рассылки, посвящённых безопасности FreeBSD

    - -

    Если вы администрируете или эксплуатируете некоторое количество систем - FreeBSD, вам полезно быть подписанным на один или несколько из следующих - списков рассылки:

    - - - - - - - +

    Список выпущенных бюллетеней можно найти на странице FreeBSD Security Advisories.

    - - - - - -
    - freebsd-securityОбсуждение общих вопросов безопасности
    - freebsd-security-notificationsУведомления, касающиеся безопасности (модерируемый список - рассылки)
    - - - -

    Рекомендации по безопасному программированию

    -

      - -
    • Никогда не доверяйте никаким входным данным, будь то аргументы командной - строки, переменные окружения, конфигурационные файлы, входящие пакеты - 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 - - + >Release-Note: >Audit-Trail: >Unformatted: