Приведённая в заголовке знаменитая фраза
точно отражает суть дела. Информационная
безопасность - это не пакет, который можно
скачать/купить и получить готовую к
использованию систему безопасности, это
длительный и сложный процесс, состоящий из
множества элементов, и малейшая уязвимость
в любом из них неизбежно приводит к
существенному ослаблению всей системы.
Поэтому к информационной безопасности, как
и ко всякому другому мероприятию, нужен
комплексный подход. В данной статье я
расскажу об основных направлениях и
концепциях процесса обеспечения
информационной безопасности как для
предприятия, так и для пользовательской
машины, дам советы по выбору операционной
системы/софта, настройке сервера, приведу
куски программного кода и проч. Кроме того,
мы рассмотрим принципы и инструменты
создания защищённого кода, а в заключение
поговорим о вещах, от нас, в большинстве
своём рядовых специалистов по ИБ и
программистов, не зависящих, как - то:
безопасность Интернет - протоколов,
безопасность программного обеспечения
сторонних разработчиков, степень
защищённости которых по мере сил
необходимо повышать, и обсудим методы,
помогающие это сделать.
Всё это мы рассмотрим с разных точек
зрения: то с точки зрения системного
администратора, то с позиции главы фирмы (работодателя).
Таким образом, статья является
своеобразной антологией наиболее ценных
наработок в этой области, а также попыткой
связать их в единое целое. Приступим.
Корпоративная сеть.
Процесс обеспечения безопасности
корпоративной сети существенно отличается
от такового для персональной рабочей
станции. Это объясняется уже хотя бы тем,
что ценность её данных как правило
неизмеримо выше, чем на пользовательском
компьютере. Соответственно и методы нужны
другие.
Процесс обеспечения ИБ должен проходить
поэтапно. Во-первых, необходимо разделить
процесс на две части, одна из которых
обеспечивается системным администратором
и его действиями, а другая находится на
стороне пользователей корпоративной сети.
Рассматривать их нужно отдельно и ни в коем
случае не смешивать.
Начнём со стороны системного
администратора. Здесь процесс обеспечения
ИБ также делится надвое: внешняя
безопасность (защищённость от атак извне) и
внутренняя (локальная). Оправданность
такого подхода очевидна - достаточно
вспомнить взлом хостинга ipowerweb.com. Снаружи
машина была защищена прекрасно (хотя
уязвимый phpBB также должен был быть удалён с
сервера), взломщик не смог проникнуть на
сервер обычными сетевыми методами, но он
воспользовался социальной инженерией и
получил тестовый доступ. И что же? Оказалось,
что локальная настройка сервера была
выполнена чрезвычайно безалаберно и не
обеспечивала минимального уровня
безопасности. Итог: взломщик нашёл лазейку
в системе и приобрёл в ней наивысшие
привилегии. Можно также привести в пример
технологию взлома Reverse IP Lookup, когда
посредством взлома сайта, физически
находящегося на том же сервере, что и цель
взломщика, можно получить шелл - доступ и
"ощупать" сервер изнутри. Понятно, что
грамотно настроенная локальная политика
безопасности может существенно снизить
степень риска для сервера при такой атаке.
Особенно заботиться о противостоянии
технологии Reverse IP Lookup должны хостеры.
Не будем говорить о том, что "важно не то,
какой сервер, важно то, кто им управляет".
Всё - таки лучше не полагаться целиком на
человека, а обеспечить безопасность
сервера более надёжными методами. Шаг за
шагом пройдём этапы установки и поддержки
безопасного сервера.
Не будем говорить о выборе аппаратной
платформы. Допустим, что сервер построен на
платформе x86.
Выбор ОС. Моё мнение таково: для создания
защищённого сервера *nix - системы подходят
куда больше, нежели Windows. Вспомним об
изначальном предназначении обоих типов
систем: если *nix (xBSD и т.д.) - системы с момента
своего создания применялись на таких
стратегически важных площадках как
разведывательные структуры, министерства
обороны различных стран (с помощью
встраиваемых Linux - систем проводится
разминирование в Афганистане) и проч., то
Windows проектировалась с расчётом на
пользовательский сегмент рынка, поэтому её
установка на сервер представляется
нецелесообразной. Кроме того, если
посмотреть историю взломов, окажется, что
Windows уже долгое время занимает в ней
лидирующую позицию. Можно сравнить степень
опасности найденных уязвимостей в обоих
типах систем (вспомним RPC DCOM); не стоит
забывать и о том, что мы зависим от
производителей системы, ведь при
обнаружении очередной критической
уязвимости приходится ждать от них
заплатки, а последует ли она - вопрос (новый
сервис MSA (Microsoft Security Advisories) ситуацию
практически не меняет), в то время как в *nix -
системах можно хотя бы попытаться решить
проблему своими силами. Да и способ
тестирования большинства *nix - систем по
принципу "базара" (за исключением
таких относительно закрытых как, например,
OpenBSD, в непосредственной разработке которой
принимает участие ограниченное число людей)
по - прежнему сильно выигрывает в сравнении
с "соборным" стилем написания кода
Windows. Можно приводить ещё массу доводов, но
статья не об этом, так что выбор за вами. Я же
предполагаю, что вы остановились на *nix -
системах.
Теперь необходимо выбрать среди
огромного количества *nix - клонов. Думаю,
оптимальным вариантом будет любая ОС из
линейки xBSD, особенно OpenBSD. Из других систем -
Sun Solaris и, конечно , великолепный QNX, который,
полноценно поддерживая стандарт POSIX, лучше
всего подходит для профессионального
системного администратора. Если же вы
хотите построить сервер на базе одной из
разновидностей Linux`а, то, благодаря своей
похожей на порты FreeBSD системе обновления
программ из Интернета (команда emerge),
прекрасно подойдёт Gentoo. Естественно,
сказанное не является аксиомой:
профессионально настроенный Mandrakelinux будет
безопаснее безграмотно настроенного OpenBSD.
Установка операционной системы. Тут можно
дать советы по разбивке винчестера на
разделы и по выбору и установке сервисов.
Винчестер можно разбить так:
/ - корневой раздел системы
/home - каталоги пользователей
/tmp - папка временных файлов системы
/var - папки для хранения логов и т.д.
/usr - исходные коды системы,
пользовательские программы и библиотеки
Такая разбивка даёт возможность
устанавливать флаги на конкретные разделы,
например: noexec - запрет на исполнение файлов,
nosuid - запрещение suid - битов на файлах и т.д.
Для просмотра полного списка доступных
флагов в вашей системе нужно набрать
команду man mount. Также не стоит забывать об
установке флагов на конкретные файлы (man
chflags, chattr, lsattr).
Лично я люблю выделять каталог /boot в
отдельный раздел, а ещё лучше - производить
загрузку системы со сменного носителя.
После запуска системы носитель с каталогом
/boot можно спокойно извлечь, что частично
защитит от подмены ядра.
Теперь об установке и запуске сервисов.
Распространённая ошибка - устанавливать
большое количество ненужных на машине
сервисов по принципу "на всякий случай"
или же из - за элементарного незнания
необходимых. Нужно свести число
установленных и запускаемых при загрузке
сервисов к минимуму. Помните: запущенный
сервис, который не используется,
автоматически становится ещё одной "открытой
дверью" в систему. А успевать
своевременно патчить огромное количество
редко/никогда не используемых сервисов -
глупая и неблагодарная работа. Понятно, что
большинство системных администраторов
средней руки будет благополучно забывать
это делать, давая в руки взломщику
дополнительное оружие.
Следует подумать о выборе конкретных
программ. Например, настраивая почтовый
сервер, задаёшься вопросом: какой вариант
предпочесть? Sendmail, qmail, postfix... Это
заслуживает отдельного разговора.
Во-первых, хотелось бы отговорить от
использования суперсервера inetd/xinetd. Этот
суперсервер используется (использовался) в
основном для запуска сервисов, не "умеющих"
работать в standalone - режиме. Стоит ли говорить,
что сейчас абсолютное большинство
нормальных сервисов спокойно может
работать в режиме standalone, а те, что не могут,
вряд ли имеет смысл оставлять на серьёзном
ответственном сервере. Если же
необходимость в использовании
суперсервера всё - таки есть, лучше
использовать его более безопасные аналоги,
например, tcpserver
Дэна Бернстайна. Недостатки inetd/xinetd
очевидны: любая Dos (DDos) атака на суперсервер
немедленно обернётся крахом всех
поддерживаемых им серверных процессов. Это
уже достаточное основание его не
использовать.
ПРИМЕЧАНИЕ: в русскоязычной литературе не
закреплено различие между Dos (Denial of service –
атака на отказ в обслуживании) и DDos (Distributed
Denial of service – распределённая атака на отказ в
обслуживании), поэтому во избежание
путаницы я везде привожу оба варианта.
Всегда нужно обращать внимание на историю
взломов и список найденных уязвимостей за
всё существование программы и уже на
основании этих данных выбирать сервер (если,
конечно, у вас нет каких - то конкретных
предпочтений в этом вопросе или вы не
администрируете сервер, установленный до
вас). Одна из ваших самых главных забот -
непрерывное слежение за всеми
появляющимися в багтраке сообщениями о
найденных уязвимостях в используемых вами
сервисах. Тут осознаёшь всю прелесть
механизма обновления Gentoo (это касается и
FreeBSD): прописываешь в crontab команду emerge sendmail и
всё! MTA (MailTransferAgent - почтовый агент) Sendmail
отныне будет обновляться самостоятельно,
без вашей помощи. Но это, конечно, не
означает, что теперь на Sendmail можно не
обращать никакого внимания. Всему нужен
постоянный контроль.
После базового конфигурирования сервера
перейдём к защите от внешних атак. Важный
этап защиты - выбор, установка и
конфигурирование брандмауэра. Брандмауэры
подразделяются на программные и аппаратные.
Рассмотрим их.
Для *nix (xBSD) - систем основные файерволлы - IPTables,
IPChains
для Linux, ipfw, IPFilter
для FreeBSD и pf для OpenBSD (страница порта под FreeBSD
- http://pf4freebsd.love2party.net/).
IPChains, предшественник IPTables, предназначается
для ядер 2.2.x, а IPTables - для 2.4.x и выше.
Естественно, нет никакого резона работать
со столь старыми и уязвимыми ядрами как 2.2.x,
поэтому IPTables - отличный вариант. Когда - то
это был не лучший файерволл (особенно в
сравнении с pf), но с выходом комплекта
патчей Patch-o-Matic
всё изменилось. Теперь IPTables умеет делать
OSFingerPrint, искать подстроку в пакете, временно
активизировать правила, оговаривать
максимальное количество подключений к
конкретному порту и проч. и проч. Так что
установка Patch-o-Matic является даже не
желательной, а обязательной. Pf может всё то
же, что и IPTables с установленным Patch-o-Matic и даже
больше. Среди возможностей этих двух
файерволлов можно также отметить
компоновку портов и ip - адресов в одном
правиле. Ну и, разумеется, NAT (не обсуждается),
которым возможности этих файерволлов не
исчерпываются. Ipfw и IPFilter ничем особенным не
отличаются.
Пример аппаратного брандмауэра -
маршрутизаторы CISCO (в частности CISCO PIX -
встроенный брандмауэр маршрутизатора CISCO).
Гибкий механизм конфигурирования через
списки доступа (access - lists) и механизмы борьбы
с перегрузками - это несомненные плюсы
данных маршрутизаторов. Минусы -
внушительная история уязвимостей (причём
довольно глупых), найденных в этом проекте.
Например, переполнение буфера при
обработке очень длинного URL - адреса HTML -
интерфейсом маршрутизатора или уязвимость
в telnetd - демоне (при обработке D - опций) и др.
Тем не менее, при грамотной настройке
использование CISCO PIX даёт неплохие
результаты. Маршрутизаторы CISCO обладают
уймой полезных для корпоративной сети
возможностей: туннелирование, policy routing (алгоритмы
маршрутизации), NAT, стратегии очередей и
многое другое, что не имеет прямого
отношения к теме статьи.
Важный аспект - фильтрация почтового
оборота компании. Необходимо "прикрутить"
к почтовой системе спам - фильтр и антивирус.
Из спам - фильтров для *nix - серверов можно
выделить SpamAssassin,
для Windows - серверов - Kaspersky AntiSpam (web - страница
всех продуктов лаборатории Касперского - http://www.kasperskylab.ru).
Из антивирусов - Dr.Web и AVP для *nix и Kaspersky Anti -
Virus для Windows - серверов (также Kaspersky Anti - Virus
Business Optimal). Фильтрация писем при приёме
корреспонденции позволяет в большой
степени снизить ущерб от неграмотных
пользователей рабочих станций
корпоративной сети. Таким образом, мы
вплотную подошли к проблеме "ликвидации
безграмотности". Отвлечёмся ненадолго от
нашего повествования и поговорим об этом.
Человеческий фактор - наиболее уязвимое
звено в системе обеспечения безопасности
любой сети или персонального компьютера.
Доверчивые пользователи, запускающие файлы
"ClickMeNow.exe", открывающие и запускающие
неизвестные им аттачи в письмах,
реагирующие на все предложения,
содержащиеся в спаме, - находка для хакера.
Грамотная разъяснительная работа с
пользователями обязательна. Собственные
меры безопасности по отношению к
пользователям - тем более. Необходимо
запрещать пользователям ставить слишком
простые пароли, контролировать их
сложность и длину, а также не забывать
периодически их менять, что справедливо и
для root`а (то бишь для Администратора). Весь
этот процесс можно облегчить и
автоматизировать с помощью специальных
утилит и их дополнительных возможностей, да
и встроенные средства Windows/*nix при должной
настройке сильно упрощают задачу.
Старайтесь фильтровать нежелательные
письма и вложения ещё до того, как они
дойдут до пользователя (разъяснительные
беседы не всегда помогают). Шифрование
проходящей по сети информации и
корреспонденции уменьшит возможный ущерб
от несанкционированной установки и запуска
вирусов, троянских коней, снифферов и т.д.
Необходимо уделять настройке безопасности
клиентских машин много внимания: настроить
антивирусы, файерволлы, своевременно
обновлять важные программы и устанавливать
на систему патчи. В настройке помогают две
вещи: Software Restriction Policy и шаблоны безопасности.
Шаблоны позволяют настроить какую - либо
одну машину, создать файл, содержащий эти
настройки, а затем применять его на любом
количестве машин. А Software Restriction Policy
подразделяет программы на те, которые можно
и которые нельзя запустить на машине.
Необходим контроль за выходами
сотрудников компании в Интернет со своих
рабочих станций. Сотрудники фирм часто
посещают сайты сомнительного содержания.
Количество "пролезающих" с этих сайтов
в систему троянов, вирусов и вредоносных
скриптов, выполняющих произвольный код на
компьютере посетителя сайта, неисчислимо.
Поэтому следует в обязательном порядке
фильтровать доступ к "развлекательным"
ресурсам. На рабочем месте сотрудники
должны заниматься делом, и не имеет смысла
подвергать опасности бизнес компании из -
за ложного демократизма.
Самое время поговорить об IDS. IDS - это Intrusion
Detection System (система обнаружения атак). IDS
делятся на сетевые (NIDS - Network Based IDS) и
локальные (HIDS - Host Based IDS), активные и
пассивные. Сетевые контролируют
несанкционированную сетевую активность, а
локальные - соответственно локальную (руткиты
и т.д.). Активные IDS способны моментально
отреагировать на попытку атаки сервера,
например, сканирование, и не только занести
событие в логи, но и заблокировать ip - адрес/подсеть
атакующего. Пассивные же могут только
залогировать событие и отправить
администратору сообщение на e - mail,
мобильный и т.д. Поэтому пассивные IDS
требуют куда больше внимания, чем активные (регулярного
просмотра логов как минимум). А теперь
рассмотрим наилучшие и самые популярные IDS.
Из сетевых IDS лучшая, несомненно, Snort.
Она отслеживает сканирование портов (в том
числе stealth), посылку shell - кода на порт, Dos (DDos)
атаки и т.д. Snort удобно конфигурируется. Но у
этой IDS есть и минусы: во - первых, с момента
создания в ней было обнаружено несколько
уязвимостей, позволяющих заполучить
удалённый контроль над системой. Логи
взломщик может стереть (впрочем, это
относится ко всем логирующим IDS). Ну и второе
- Snort, к сожалению, пассивен. А вот portsentry
- утилита, предназначенная для
детектирования сканирования портов,
хорошая и активная. Она логирует все
попытки сканирования и противостоит им. К
ней прилагается утилита logsentry для
преобразования логов IDS в удобный для
чтения формат. Но portsentry бессилен против
ручного сканирования портов, что
справедливо для большинства IDS.
Перейдём к локальным IDS. Среди утилит
этого класса стоит выделить tripwire и chkrootkit. Tripwire
- утилита для осуществления аудита доступа
к системным файлам. Обойти tripwire можно с
помощью модификации действующих конфигов.
Противоядие: переопределить пути tripwire в
системе, переименовать запускной файл IDS,
удалить файлы, описывающие действующие
политики. Chkrootkit
- утилита обнаружения установленных в
системе руткитов, бэкдоров и т.д. Способ
обхода - правка исходников. Защита -
постоянная проверка контрольной суммы
chkrootkit.
Переходим к обеспечению локальной
безопасности сервера. Аудит md5 - сумм хорош
не только для chkrootkit - такой способ контроля
полезен для любых стандартных утилит
системы (ps, ls, netstat...), которые часто
модифицируются взломщиком для своих нужд (для
сокрытия файлов, процессов, сетевых
соединений и т.д.). Программы вроде
компилятора, дизассемблера и проч. на
работающей и отлаженной машине не нужны.
Едва ли их отсутствие сильно затруднит
взломщику его работу (так как
скомпилированный эксплойт можно спокойно
закачать на уязвимый сервер и запустить), но
всё же. Совет: не оставляйте рутовых паролей
в .bash_history ! Это одна из самых
распространённых ошибок, которую нередко
допускают даже грамотные системные
администраторы. Есть простой и удобный
способ решения проблемы - прилинковать .bash_history
к /dev/null. Кроме того, необходимо организовать
немедленную пересылку логов на машину,
предназначенную специально для этого.
Неплохо было бы установить для этих целей
подходящую БД (базу данных).
Следующие два мощных механизма
обеспечения локальной безопасности
сервера - chroot и systrace. Поддерево (по отношению
к основному, "настоящему" дереву
системы, начинающемуся с корня) chroot - это
мини - копия корневой файловой системы,
находящаяся в одном каталоге. Главное
отличие в том, что в этой мини - системе
содержатся только те файлы, которые
необходимы для запуска и нормальной работы
настраиваемого сервера. Обычно все свежие
версии любых серверов полноценно
поддерживают chroot, и их настройка не создаст
особых проблем. Более старые версии
потребуют больше внимания: для того, чтобы
заставить их работать в chroot, может
потребоваться дерево chroot размером чуть ли
не с мини - дистрибутив системы. Команда
запуска сервера, поддерживающего chroot, в
только что созданном поддереве в общем
случае будет выглядеть так:
chroot имя_нового_корневого_каталога [команда[аргументы]]
Преимущества chroot: программы, находящиеся
вне конкретного chroot, могут его изменять, а
программы, находящиеся внутри него - нет.
Таким образом, взломщик, получив привилегии
на сервере, работающем в chroot, может сколько
угодно изменять находящиеся там файлы - на
реальной системе это никак не отразится.
Например, если скопировать в chroot системный
файл /etc/passwd, взломщик, добавив нового
пользователя в систему, не сможет применить
эти изменения для настоящего /etc/passwd. Так что
это ещё один серьёзный барьер на пути
хакера.
Systrace - это механизм, определяющий для
каждой программы набор разрешённых ей
системных вызовов. Область его применения
достаточно широка: можно, например,
запретить какому - либо сервису открывать
новые порты. В этом случае предназначенный
для сервиса shell - код, открывающий через его
процесс порт для шелла, останется не у дел.
Техническая реализация механизма systrace
довольно сложна и рассмотреть её во всех
подробностях в данной статье не
представляется возможным - это тема
отдельного, обстоятельного разговора. За
дальнейшей информацией советую обратиться
к http://www.citi.umich.edu/u/provos.
Существует множество патчей к ядру, в той
или иной мере позволяющих защититься от
хакерских атак, ориентированных на
переполнение буфера, стека и т.д. На первом
месте патч grsecurity,
защищающий от переполнений стека и памяти.
Далее следует патч,
блокирующий всевозможные
несанкционированные действия, в частности
переполнения стека. RSX
- патч предотвращает запуск кода в стеке или
куче после переполнения, но работает, к
сожалению, только на ядрах 2.4.x.
Вышеперечисленные патчи под *nix, пожалуй,
наилучшие из доступных. Для Windows хороший
вариант - знаменитый AntiCracker
Shield Ильи Рабиновича. Эта гибкая утилита
обеспечивает несколько уровней защиты: low,
medium, high и ultra. На уровне low разрешено
выполнение кода как в стеке, так и в куче, а
на ultra - запрещено. Уровни medium и high запрещают
выполнение кода в стеке, а кучу
контролируют. Кроме того, AntiCracker Shield
обеспечивает рандомизацию стека и кучи. И
это далеко не полный список возможностей
данного продукта ! Так что его
использование обязательно. Доступны
серверная и пользовательская версии ACSHIELD, а
также русский файл
справки к ней.
Если у вашей фирмы есть свой веб - сайт,
необходимо тщательно следить за
информацией в багтраке обо всех
уязвимостях в установленных скриптах и
самостоятельно тестировать их, ведь
сообщение об уязвимости в багтраке может и
не появиться, но это не повод снижать
контроль за web - содержимым сайта. Вы можете
не заметить ошибки на своей веб - странице (или
просто взломщик окажется умнее вас),
поэтому важные данные (например, базы
данных) НИ В КОЕМ случае НЕЛЬЗЯ размещать на
публичном web - сервере (из-за SQL-Injection в
частности). Они должны находиться за
демилитаризованной зоной (DMZ). Тем более что
сейчас очень популярен Google - Hack (взлом при
помощи поисковых запросов Google), и если вы
будете хранить важные документы на сервере,
да ещё допустите ошибку в его настройке, это
приведёт к тому, что поисковый робот Google
сможет их проиндексировать и предоставить
взломщику ссылки на них. Думаю, не надо
объяснять последствия. Кроме того, нужно
отконфигурировать файл robots.txt, который
определит, какие данные на сервере могут
проиндексировать поисковые роботы. Хорошие
результаты даёт правильная настройка cPanel (если
таковая на вашем сервере имеется).
Не забывайте про смену баннеров сервисов.
Для одних сервисов сделать это легко,
достаточно подправить строчку в исходниках,
для других может потребоваться серьёзное
вмешательство в код программы. Такое
переписывание целых кусков кода -
благодарное занятие, так как в идеале это
должно воспрепятствовать правильному
определению версии и типа сервиса
взломщиком.
Есть ещё мелочи, которые могут привести к
несанкционированному взлому вашего
сервера. Могут найтись слабые места и в
вышеперечисленных методиках. Мы не
поговорили о настройке уровней
безопасности ядра, настройке ответов на
некоторые сетевые запросы (что поможет в
случае невозможности использования IDS), о
средствах sysctl для повышения безопасности
сервера (переменные sysctl имеют огромное
число возможностей, включая реализацию
защиты от DDos (Dos) атак, сканирования nmap`ом и т.д.)
и проч. От сканирования nmap`ом защитят
специальные механизмы в файерволле pf,
использование специальных патчей (например,
IPPersonality под Linux, изменяющий поведение
сетевого стека и позволяющий замаскировать
сервер под любое сетевое устройство). Также
мы не рассмотрели такую интересную вещь как
honeypot (впрочем, она имеет косвенное
отношение к теме статьи), не поговорили о
патчах для Linux`а (RSBAC, SELinux), реализующих в
системе Role Based Access Control (RSBAC), Domen Type Enforcement (DTE)
и т.д. Отдельная тема - мандатные модели
доступа (Mandatory Access Control). Не стоит забывать и
о CSS (XSS) атаках. Но один из главных принципов
сохранности данных - бэкап. Резервное
копирование всегда поможет избежать
необратимой потери данных. А ещё бывает так,
что незначительный скачок напряжения в
сети наносит больший вред, чем все
хакерские атаки вместе взятые. Выход один -
UPS.
Таким образом, процесс обеспечения
информационной безопасности корпоративной
сети можно считать завершённым. Желаю
высоких uptime`ов и чистых от атак хакеров
логов!
(Продолжение следует)
