Введение

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

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

Содержание

• Информация об Офицере информационной безопасности FreeBSD
• Политика отработки информации
• Бюллетени безопасности FreeBSD
• Информация о списках рассылки, посвящённых информационной безопасности FreeBSD
• Советы и рекомендации по обеспечению безопасности FreeBSD
• Рекомендации по безопасному программированию
• Прочая информация, касающаяся безопасности

Офицер информационной безопасности FreeBSD и служба информационной безопасности FreeBSD

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

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

Для того, чтобы Проект FreeBSD мог оперативно реагировать на сообщения об уязвимостях, почтовый алиас Офицера информационной безопасности соответствует четырём персонам: Офицер информационной безопасности, заместитель Офицера информационной безопасности и два члена Основной группы разработчиков. Таким образом, сообщения, посланные в адрес почтового алиаса <security-officer@FreeBSD.org>, доставляются следующим лицам:

Офицер информационной безопасности поддерживается Службой безопасности FreeBSD <security-team@FreeBSD.org>, группой коммиттеров, которую он выбирает сам.

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

Политика отработки информации

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

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

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

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

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

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

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

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

Сообщения могут быть защищены с помощью PGP. Если это нужно, то ответы также будут защищены посредством PGP.

Бюллетени безопасности FreeBSD

Служба информационной безопасности FreeBSD выпускает бюллетени безопасности для нескольких разрабатываемых веток FreeBSD. Это Ветки -STABLE и Ветки Security. (Бюллетени не выпускаются для Ветки -CURRENT.)

• Обычно здесь присутствует только одна ветка -STABLE, хотя в процессе перехода от одной основной линии разработки к другой (например, с FreeBSD 4.x на 5.x) имеется временной интервал, в котором существуют две ветки -STABLE. Тэги ветки -STABLE носят имена типа RELENG_4. Соответствующие версии носят названия типа FreeBSD 4.6-STABLE.

• Каждому релизу FreeBSD поставлена в соответствие ветка безопасности (Security Branch). Метки веток безопасности именуются как RELENG_4_6. Соответствующие построенные версии носят названия типа FreeBSD 4.6-RELEASE-p7.

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

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

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

Если вы администрируете или эксплуатируете некоторое количество систем 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 также предоставляет подробную информацию о том, что нужно предпринять в случае нарушения безопасности системы.

Другие источники информации, касающиеся безопасности

• Архив COAST содержит гигантскую коллекцию материалов, посвященных безопасности.
• Center for Education and Research in Information Assurance and Security (CERIAS) является местом, с которого следует начинать поиск материалов по безопасности. Здесь находятся сотни полезных ссылок. Всё, что вы хотели знать о безопасности... и больше.
• Различные группы CERT, такие как http://www.cert.org и http://www.auscert.org.au.
• Списки рассылки, такие как Bugtraq и Firewall Wizards.