%includes;
]>
&header;
Введение
Эта веб-страница создана для того, чтобы помочь как начинающим, так и
опытным пользователям в области безопасности операционной системы FreeBSD.
Команда разработчиков FreeBSD воспринимает вопросы безопасности очень
серьёзно и постоянно работает над тем, чтобы сделать ОС защищённой
настолько, насколько это вообще возможно.
Здесь вы найдёте информацию или ссылки на информацию о том, как защитить
вашу систему от различных типов внешних атак, с кем связаться, если вы
нашли недочёт в системе безопасности и так далее. Сюда также включен
раздел, в котором описаны различные способы, прибегнув к которым, системный
программист может с большей вероятностью избегнуть дыр в защите.
Содержание
Служба Безопасности FreeBSD
Для того, чтобы лучше координировать обмен информацией с сообществом,
занимающимся вопросами безопасности, во FreeBSD имеется точка для
соответствующих коммуникаций: служба безопасности.
Должности в этом отделе занимает группа выделенных для этого офицеров
безопасности, их главной задачей является рассылка бюллетеней при
обнаружении дыр в системе безопасности и реагирование на сообщения о
возможных проблемах с безопасностью во FreeBSD.
Если вы хотите связаться с кем-нибудь из команды FreeBSD по поводу
возможной ошибки в защите, то, пожалуйста, напишите письмо Офицеру
Безопасности с описанием того, что вы нашли и характером нарушения
безопасности, с которым вы столкнулись. Офицеры Безопасности также
общаются с различными командами из CERT
и FIRST по всему миру, распространяя
информацию о возможных нарушениях безопасности во FreeBSD и утилитах,
часто используемых во FreeBSD. Офицеры Безопасности также являются
активными членами этих организаций.
Если вы хотите обратиться к Офицеру Безопасности по поводу некоторой
особо щепетильной проблемы, воспользуйтесь ключами
PGP для шифрования вашего сообщения перед его отправкой.
Бюллетени безопасности FreeBSD
Офицеры Безопасности FreeBSD выпускают бюллетени безопасности для
следующих релизов FreeBSD:
- Самый последний официальный релиз FreeBSD.
- FreeBSD-stable, после того, как из этой ветки было выпущено по
крайней мере 2 релиза.
- Предыдущая ветка FreeBSD-stable, пока из новой ветви -stable ещё
не выпущено 2 релиза.
В настоящее время бюллетени безопасности будут выпускаться для:
- FreeBSD 3.5.1-STABLE (только уязвимости, которыми можно пользоваться
в режиме удалённого доступа)
- FreeBSD 4.3-RELEASE
- FreeBSD 4.4-RELEASE
- FreeBSD 4.4-STABLE
Более старые релизы не поддерживаются и пользователям строго рекомендуется
произвести обновление до одной из поддерживаемых версий, указанных
выше.
Как и все направления разработки, исправления в защите системы сначала
испытываются в ветке FreeBSD-current. После
нескольких дней некоторого тестирования исправления переносятся в
поддерживаемые ветки FreeBSD-stable и выпускается очередной бюллетень.
Немного статистики по бюллетеням, выпущенным в течение 2000 года:
- Всего был выпущен 81 бюллетень, и они касались как базовой
системы (то есть установки FreeBSD по умолчанию), так и дополнительных
приложений сторонних разработчиков, включенных в коллекцию портов.
- 24 бюллетеня (с проблемами различной степени опасности) касались
базовой системы, и оставшиеся 57 относились к дополнительным приложениям
сторонних разработчиков, доступным из коллекции портов.
- 19 уязвимостей (8 в базовой системе и 11 в портах) было обнаружено
участниками команды FreeBSD в процессе аудита исходного кода.
- 9 бюллетеней описывают уязвимости, найденные только во FreeBSD (6
бюллетеней по базовой системе и 3 по портам), остальные 72 бюллетеня
являлись проблемами, общими как мимнимум с одной другой ОС (часто
по причине использовани одного и того же кода).
Бюллетени рассылаются в следующие списки рассылки FreeBSD:
- FreeBSD-security-notifications@FreeBSD.org
- FreeBSD-security@FreeBSD.org
- FreeBSD-announce@FreeBSD.org
Бюллетени всегда подписываются с помощью PGP-ключа
Офицера Безопасности и помещаются, вместе с соответствующими исправлениями,
в наш архив. На
момент написания этого текста вышли следующие бюллетени (заметьте, что этот
список может быть устаревшим на несколько дней - самые последние бюллетени
находятся на
FTP-сервере):
Выпущена FreeBSD 4.3-RELEASE.
Информация о списках рассылки, посвященных безопасности 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_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 также предоставляет
подробную информацию
о том, что нужно предпринять в случае нарушения безопасности системы.
Другие источники информации, касающиеся безопасности
&footer