Top 10 ошибок администрирования Windows Server 2003/2008
Крис Касперски
Легкость установки и управления серверными версиями Windows создает обманчивую иллюзию, что администрировать подобные системы проще простого. Почему же тогда виндовые серваки так часто ломают?! Составив Top 10 ошибок управления Win2k3/Win2k8 и подробно прокомментировав каждую из них, мы надеемся помочь как начинающим, так и матерым администраторам.
Содержание:
- #1 – Заплатки и обновления
- #2 – Баги в процессорах
- #3 – Излишняя сложность
- #4 – Режем «в живую» без наркоза
- #5 – Пакеты обновления и дистрибутивы
- #6 – Он слишком много доверял…
- #7 – DEP и ASLR
- #8 – Предсказуемость конфигурации системы
- #9 – Бортовой журнал капитана Немо
- #10 – Расплата за бездумность
- Боковые выносы
Достаточно многие администраторы вообще не устанавливают никаких заплаток, считая, что никто их атаковать не будет, но это всего лишь распространенное заблуждение. Основная угроза исходит от червей, сканирующих IP-адреса и выявляющих незалатанные машины, даже если это домашний сервер, на котором нет никакой конфиденциальной информации.
Обновляться все-таки надо, причем следует обновлять не только операционную систему, но и все используемые приложения, где также обнаруживаются критические ошибки, естественно, не устраняемые обновлениями от Microsoft. Следовательно, нужно составить список используемого программного обеспечения и регулярно посещать сайты производителей на предмет поиска обновлений.
Кстати говоря, заплатки от Microsoft содержат одну очень неприятную особенность, граничащую с ошибкой, а именно они не проверяют номера версий замещаемых исполняемых файлов/динамических библиотек. Допустим, у нас есть две заплатки A и B, исправляющие ошибки в kernel32.dll. Поскольку установщик не отслеживает последовательность обновлений, то, установив заплатки в обратном порядке (инсталлятор при этом даже не пикнет!), мы закроем дырку A, но откроем дырку B, поскольку kernel32.dll (как и любая другая динамическая библиотека) всегда замещается целиком, а не частями!
При автоматическом обновлении никаких проблем не возникает, т.к. заплатки ставятся в том порядке, в котором они выпускаются, но вот если мы качаем их вручную, то необходимо в свойствах каждого файла найти внутреннюю версию и дату его создания, а затем составить «план» последовательности установки заплаток. Впрочем, тут не обходится без подводных камней. Иногда Microsoft выпускает одни и те же заплатки по несколько раз. Допустим, сначала выходит A, исправляющая ошибки E1, E2, E3, после чего выходит B, исправляющая E4, E5, E6, а затем… выходит обновленная заплатка A’, исправляющая все те же E1, E2, E3, а обновленной заплатки B — нет. Установка A’ поверх уже установленной B открывает дыры E4, E5, E6. Так что с заплатками нужно быть очень внимательными и всегда читать бюллетени безопасности, чего практически никто делать не собирается.
В целях экономии трафика ряд интернет-провайдеров устанавливает свои собственные сервера обновлений, предлагая клиентам прописать в настройках Windows Update их адреса. Соблазн на самом деле очень велик, но угроза быть атакованным еще выше! Microsoft прилагает огромные усилия для защиты своих серверов, вкладывая в безопасность немалые деньги. Что же касается провайдеров, то… атаковать их порядка на три проще (и ведь их взламывают, а затем подсовывают троянизированные обновления).
Выход: скачивай заплатки только у самих поставщиков, при этом, чтобы избежать вероятности «подмятия» доменного имени с перенаправлением на другой узел, не используй DNS-сервер провайдера. Установи свой собственный DNS, напрямую обращающийся к корневым доменным серверам по TCP-протоколу, и заблокируй порт 53/UDP на брандмауэре для отсечения подложных DNS-ответов.
Рис. 1. Ветки реестра, ответственные за установку адреса сервера автоматических обновлений
Ругая Windows (и отчасти Linux) за то, что программное обеспечение наших дней дыряво, как ведро без дна, мы почему-то забываем об аппаратной оснастке, считая «железо» совершенно непогрешимым. Увы, процессоры не лишены недостатков. Самый громкий баг в Pentium был обнаружен в 1995 году и продемонстрирован на следующем примере: x - (x/y)*y, результат которого (если только y != 0) должен быть равен нулю, однако при определенных значениях x и y (x = 4195835, y = 3145727) процессор выдавал… 256! Потрясающая точность, не правда ли?!
Журналисты подхватили сенсацию, вынудив Intel пойти на замену процессоров, чего она изначально делать не хотела, доказывая, что людям, далеким от математики, точные вычисления не нужны, а вероятность проявления ошибки на произвольном (а не умышленно подготовленном) наборе данных близка к нулю.
С тех пор сообщений об ошибках в ЦП как будто бы не отмечалось. И потому заявление Theo de Raadt’а (ведущего разработчика OpenBSD), что Core2Duo содержит огромное количество ошибок, многие из которых допускают удаленный захват управления, стало очередной сенсацией года ().
Часть ошибок может быть исправлена программным путем (и разработчики OpenBSD сделали это, чего нельзя сказать о лагере NT-подобных систем), часть — обновлением микрокода процессора (для чего, в свою очередь, необходимо обновить версию BIOS, если только разработчики прошивки включили в нее обновленный микрокод), но все эти меры лишь уменьшают вероятность атаки, а оставшиеся ошибки исправляются исключительно заменой процессора на более новый (кстати говоря, так же содержащий ошибки, перечисленные в секции Errata обновленной спецификации от Intel, распространяемой на свободной основе).
Выход: почаще обновлять прошивку BIOS, в критических случаях использовать OpenBSD, разработчики которой прилагают все усилия для исправления ошибок ЦП, а еще лучше не использовать Core2Duo, поскольку это все-таки «бытовой» процессор, не отвечающий жестким требованиям серверной индустрии.
Рис. 2. Core2Duo – процессор, в котором обнаружено рекордное число критических ошибок
Чем сложнее система, тем выше вероятность внезапных отказов, и тем проще ее атаковать, найдя слабейшее звено в линии обороны. Если администратор не пользуется удаленным доступом к реестру, зачем оставлять эту службу включенной?
IIS, бесспорно, могучая вещь, однако так ли он необходим небольшой организации, обслуживающей сотни (ну, пускай даже тысячи) подключений в день? Сайт с движком на PHP – отличная штука, это современно и круто! А ошибки в скриптах (или самом PHP-интерпретаторе?). Почему бы не попробовать установить что-нибудь наподобие SMALL HTTP сервера? Бесплатный, поддерживает практически все функции, которые только могут быть нужны, обладает приятным интерфейсом, не требователен к системным ресурсам…
А ситуация, когда начинающий администратор для 30-ти манагеров вместо простой одноранговой сети развертывает доменную структуру, работающую по принципу «сейчас опять все развалится», — вообще живая классика.
Вывод: система должна быть предельно простой и не содержать ничего лишнего (тем не менее, стоит помнить, что иная простота хуже воровства).
Рис. 3. Экспериментальный Win2k3, воздвигнутый под VM Ware
#4 – Режем «в живую» без наркоза
Практически все администраторы устанавливают заплатки непосредственно на «продакшен» сервере (а в случае активной службы Windows Update это происходит автоматически), даже не задумываясь, какому риску они себя подвергают, не говоря уже про обновление прошивки BIOS.
В лучшем случае после установки очередной порции заплаток возникают мелкие неприятные конфликты. Гораздо хуже, если система вообще откажется грузиться, или «забастуют» критические приложения сторонних разработчиков, что, кстати говоря, более чем вероятно, и очень часто после выпуска заплатки следом за ней Microsoft выпускает кучу инструкций по устранению конфликтов. Естественно, это относится только к популярным программным комплексам, хорошо известным на Западе. А как быть, если приложение складского учета, упакованное разработчиками неимоверно крутым протектором (чтобы злые хакеры не взломали), скручивает дулю и выдает голубой экран смерти или «всего лишь» аварийно завершает свою работу сразу же после запуска?
Выход: создать точную копию основного сервера, устанавливая заплатки/обновления сначала на ней, и, если после более или менее полного цикла тестирования никаких побочных эффектов не выявится, переносить заплатки на основной сервер. Конечно, это требует дополнительных расходов, и при «тугом» бюджете сервер-клон можно организовать и на виртуальной машине, не забывая, что она работает с виртуальным железом и потому потенциально не способна выявить ряд конфликтов. Однако это все же лучше, чем совсем ничего.
#5 – Пакеты обновления и дистрибутивы
Популярный способ «поднятия» упавшего сервера — установка операционной системы поверх уже имеющейся. Прием не то чтобы хороший или красивый, однако в жестких временных рамках и отсутствии резервной копии — это единственно возможное решение.
Проблема в том, что после установки Service Pack’ов «родной» дистрибутив системы отказывается устанавливаться поверх более новой версии, предлагая либо вообще отказаться от инсталляции, либо удалить старую систему и поставить новую с нуля, переустанавливая все остальные программы, на что может уйти несколько рабочих дней (и бессонных ночей).
К счастью, пакеты обновлений могут быть интегрированы непосредственно в сам дистрибутив (чему посвящено огромное количество статей, так что не будем повторяться, тем более что описать процесс интеграции в двух словах все равно не получится). Желательно обновлять дистрибутивный диск при каждой установке Service Pack’а, чтобы потом лихорадочно не интегрировать его впопыхах, рискуя окончательно завалить систему, которой только полная переустановка и поможет.
Как вариант, можно заблаговременно создать образ системы с помощью Norton Ghost, Acronis True Image или штатной утилиты ntbackup.exe. Однако следует помнить, программы, установленные после создания образа, при этом перестанут работать, а изменения настроек системы также окажутся утерянными. Так что резервируйся почаще.
Рис. 4. Сохранение состояния системы при помощи штатной утилиты ntbackup.exe
#6 – Он слишком много доверял…
Практически все WEB/FTP/MAIL сервера по умолчанию устанавливают себя с привилегиями администратора, а то и системы (system), получая доступ ко всем файлам, которые только есть. Как следствие — любая ошибка конфигурации сервера, любой дефект PHP/Perl-скрипта, любая дыра самого сервера позволяет атакующему получить доступ к секретной информации или уничтожить данные.
Как защититься от этого? Очень просто! Достаточно запускать сервер из-под ограниченного аккаунта, имеющего доступ к тем и только тем файлам, которые ему необходимы. Что это за файлы?! Во-первых, файлы самого сервера, во-вторых, публичные файлы, раздаваемые пользователям. Конечно, если в сервере или скриптах имеется дыра, то злоумышленник по-прежнему сможет изменять конфигурацию сервера, а также получать несанкционированный доступ к файлам других пользователей, не предназначенных для всяких «левых» лиц.
Тем не менее, разделение привилегий на уровне файловой системы существенно ограничивает потенциальный ущерб, наносимый злоумышленником. Кстати говоря, не следует забывать, что многие файлы по умолчанию доступы всем, и потому администратору следует тщательно проверить атрибуты секретности, явно обозначив круг лиц, имеющих право на чтение/запись каждого более или менее значимого файла.
Может ли злоумышленник обойти ограничения доступа, налагаемые файловой системой? Безусловно. Но для этого ему придется найти дыру, предоставляющую привилегии ядра или позволяющую повышать права до уровня администратора. Такие дыры действительно есть, но их сравнительно немного, и Microsoft их быстро затыкает.
В Win2k3 SP1 появилась поддержка неисполняемого стека и кучи, известная под аббревиатурой DEP (Data Execution Prevention), которая по умолчанию распространяется на все процессы (в XP же по умолчанию DEP включен только для системных компонентов).
Насколько эффективна такая защита?! Во-первых, она требует обязательной поддержки со стороны процессора, позволяющего выставлять биты NX/XD не только для целых селекторов, как это было ранее, но и на уровне отдельных страниц. Без аппаратной поддержки DEP вообще никак не работает. Во-вторых, DEP представляет собой довольно конфликтную штуку, препятствующую функционированию многих честных программ. В-третьих, вся эта защита элементарно обходится атакой типа return2libc, позволяющей атакующему вызывать API-функций, присваивающие стеку атрибуты исполняемого. Активный DEP отсекает лишь «пионерские» exploit’ы, протестированные на XP, но ни разу не нюхавшие Win2k3 SP1 и выше.
Для предотвращения атаки необходимо задействовать рандомизацию адресного пространства (Address Space Layout Randomization или, сокращенно, ASLR), реализованную в Win2k8, а также в защитных пакетах независимых производителей, работающих хоть на Win2k и не требующих аппаратной поддержки NX/XD битов. Одним из таких пакетов является BufferShield, представляющий собой коммерческий порт известного проекта PaX, реализованного на Linux-системах.
Рис. 5. Активный DEP на Win2k3 - это дикая головная боль на почве (не)совместимости и… никакой реальной защиты
#8 – Предсказуемость конфигурации системы
Успешность большинства атак объясняется высокой предсказуемостью конфигурации системы в установке по умолчанию. Это в мире открытых исходных текстов администратор может (и должен!) перекомпилировать все и вся, чтобы никакой хакер ни за что не догадался, по каким адресам лежат интересующие его функции.
С Windows в этом плане ситуация намного сложнее, но не полностью безнадежна. Переименование ядра — эффективный способ борьбы с rootkit’ами, определяющими адреса функций путем вызова функции LoadLibrary("ntoskrnl.exe") без проверки реального имени ядра, задаваемого через ключ «/kernel=» файла boot.ini. Рекомендуется переименовать ядро, например, в souriz.exe, а вместо ntoskrnl.exe положить ядро от другой версии системы, чтобы адреса экспортируемых функций отличались.
Те rootkit’ы, что правят файл непосредственно на диске, уйдут лесом, не достигнув желаемой цели (ведь ntoskrnl.exe уже никак не используется), те же rootkit’ы, что осуществляют перехват в оперативной памяти, залезут совсем не в ту степь и вызовут BSOD, что хоть и неприятно, но успешное внедрение rootkit’а было бы еще хуже.
Естественно, после переименования ядра его необходимо обновить в кэше утилиты sfc.exe (иначе она немедленно его восстановит), а также перед установкой пакетов обновлений выполнить откат назад, поскольку пакеты обновлений (как и rootkit’ы) не проверяют реального имени ядра.
Установка системы на диск, отличный от С:, также уменьшает вероятность успешной атаки — большинство зловредных программ слишком бестолковы, а их создатели слишком ленивы, чтобы проверить переменные окружения, вот они и используют фиксированные абсолютные пути.
#9 – Бортовой журнал капитана Немо
Реестр — крайне вредное изобретение, порождающее множество трудноразрешимых проблем. Текстовые конфигурационные файлы (традиционные для UNIX-систем) удобны тем, что в них можно оставлять ремарки и в процессе внесения изменений блокировать старые параметры символом комментария, существенно упрощая откат в случае неудачи.
А реестр?! Хорошо, если систему обслуживает всего один администратор, худо-бедно помнящий, какие параметры он менял и зачем. Когда же администраторов несколько, и все они вносят изменения в реестр, работа превращается в сплошной разбор полетов «кто трогал реестр и весь его вытрогал?»
Чтобы этого не происходило, необходимо вести журнал (предпочтительнее всего на бумаге), описывающий каждое изменение конфигурации системы с указанием причин и сохранением предыдущих значений, заверенных подписью администратора. Тогда, если система начнет вести себя нестабильно, или же на ней обнаружатся черви, ломанувшиеся в широко открытые двери, всегда можно установить, кто именно их открыл, и чем он руководствовался при этом.
Кстати, в нормальных фирмах у администратора есть инструкция, внятно объясняющая, какие действия он вправе выполнять, а какие — нет. Эксперименты с системой на продакшен машинах (без предварительного согласования с руководством) в общем случае строго запрещены. И это правильно!
Никакие защитные комплексы не дают 100% гарантии, и от риска быть атакованным никуда не деться, увы. А потому необходимо заранее выработать четкий, хорошо продуманный и отлаженный план действий выхода из ситуации. Обнаружив на компьютере постороннюю зловредную программу, мало удалить ее из системы. Необходимо как минимум определить, что она успела натворить за время своей жизнедеятельности.
Помимо традиционных охранных комплексов, сервер должен быть оснащен снифферами и прочими шпионами всех мастей, протоколирующими максимум возможных действий и сохраняющими результат своей деятельности на носители однократной записи (CD/DVD-R), уничтожить которые никакой хакер не в состоянии, и которые позволяют полностью реконструировать последовательность событий, прямо или косвенно связанных с атакой.
Отсутствие подобных средств существенно ослабляет безопасность системы, поскольку, вспоминая слова Жеглова, можно сказать, что степень защиты определяется не стойкостью сервера к атакам, а скоростью и успешностью раскрытия различных несанкционированных действий.
Рис. 6. Бумага — великая вещь!
INFO
-
Утилита (System File Checker) входит в состав Win2k3/Win2k8 и осуществляет проверку всех защищенных системных файлов и замену неправильных версий правильными. Ее можно использовать после сбоя системы, вредоносного действия вирусов и для настройки размера файлового кэша.
-
DEP элементарно обходится атакой типа return2libc, позволяющей атакующему вызывать API-функций, присваивающие стеку атрибуты исполняемого.
-
PaX — это патч к ядру Linux, который предоставляет возможность настроить минимальные права доступа приложений к страницам памяти.
-
Благодаря ASLR при каждой загрузке операционной системы критически важные данные записываются в разные участки памяти. Это усложняет проведение атак, поскольку системный код оказывается в случайном месте.
WWW
-
Официальный сайт пакета BufferShield: .
-
Процессоры Core2Duo содержат огромное количество ошибок, многие из которых допускают удаленный захват управления, см. .
Статья опубликована в июньском номере журнала «Xakep» за 2008 год.