Легкость установки и управления серверными версиями Windows создает иллюзию, что администрировать подобные системы проще простого. Почему же тогда виндовые серваки так часто ломают?! Составив ТОП-10 ошибок управления Win2k3/Win2k8 и подробно прокомментировав каждую из них, мы надеемся помочь как начинающим, так и матерым администраторам.
#1 – Заплатки и обновления
Многие администраторы вообще не устанавливают никаких заплаток, считая, что никто их атаковать не будет. Это – всего лишь распространенное заблуждение. Основная угроза исходит от червей, сканирующих 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-ответов.
#2 – Баги в процессорах
Ругая 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, поскольку это все-таки «бытовой» процессор, не отвечающий жестким требованиям серверной индустрии.
#3 – Излишняя сложность
Чем сложнее система, тем выше вероятность внезапных отказов, и тем проще ее атаковать, найдя слабейшее звено в линии обороны. Если администратор не пользуется удаленным доступом к реестру, зачем оставлять эту службу включенной?
IIS, бесспорно, могучая вещь, однако так ли он необходим небольшой организации, обслуживающей сотни (ну, пускай даже тысячи) подключений в день? Сайт с движком на PHP – отличная штука, это современно и круто! А как же ошибки в скриптах или самом PHP-интерпретаторе? Почему бы не попробовать установить что-нибудь наподобие SMALL HTTP-сервера? Бесплатный, к тому же, поддерживает практически все функции, которые только могут понадобиться, обладает приятным интерфейсом, не требователен к системным ресурсам… Или ситуация, когда начинающий администратор для тридцати манагеров вместо простой одноранговой сети развертывает доменную структуру, работающую по принципу «сейчас опять все развалится», — вообще живая классика.
Вывод: система должна быть предельно простой и не содержать ничего лишнего (тем не менее, стоит помнить, что иная простота хуже воровства).
#4 – Режем «вживую» без наркоза
Практически все администраторы устанавливают заплатки непосредственно на «продакшен» сервере (при активной службе Windows Update это происходит автоматически), – даже не задумываясь, какому риску они себя подвергают, не говоря уже про обновление прошивки BIOS.
В лучшем случае после установки очередной порции заплаток возникают мелкие неприятные конфликты. Гораздо хуже, если система вообще откажется грузиться или «забастуют» критические приложения сторонних разработчиков, что, кстати говоря, более чем вероятно (очень часто, после выпуска заплатки, следом за ней Microsoft выпускает кучу инструкций по устранению конфликтов). Естественно, это относится только к популярным программным комплексам, хорошо известным на Западе. А как быть, если приложение складского учета, упакованное разработчиками неимоверно крутым протектором (чтобы злые хакеры не взломали), скручивает дулю и выдает голубой экран смерти или «всего лишь» аварийно завершает свою работу сразу же после запуска?
Выход: создать точную копию основного сервера, устанавливая заплатки/обновления сначала на ней, и, если после более или менее полного цикла тестирования никаких побочных эффектов не выявится, переносить заплатки на основной сервер. Конечно, это требует дополнительных расходов, и при «тугом» бюджете сервер-клон можно организовать и на виртуальной машине, не забывая, что она работает с виртуальным железом и потому потенциально не способна выявить ряд конфликтов. Однако это все же лучше, чем совсем ничего.
#5 – Пакеты обновлений и дистрибутивы
Популярный способ «поднятия» упавшего сервера — установка операционной системы поверх уже имеющейся. Прием не то, чтобы хороший или красивый, однако в жестких временных рамках и при отсутствии резервной копии – это единственно возможное решение.
Проблема в том, что после установки Service Pack’ов «родной» дистрибутив системы отказывается устанавливаться поверх более новой версии, предлагая либо вообще отказаться от инсталляции, либо удалить старую систему и поставить новую с нуля, переустанавливая все остальные программы, на что может уйти несколько рабочих дней (и бессонных ночей).
К счастью, пакеты обновлений могут быть интегрированы непосредственно в сам дистрибутив (чему посвящено огромное количество статей, так что не будем повторяться, тем более что описать процесс интеграции в двух словах все равно не получится). Желательно обновлять дистрибутивный диск при каждой установке Service Pack’а, чтобы потом лихорадочно не интегрировать его впопыхах, рискуя окончательно завалить систему, которой только полная переустановка и поможет.
Как вариант, можно заблаговременно создать образ системы с помощью Norton Ghost, Acronis True Image или штатной утилиты ntbackup.exe. Однако следует помнить: программы, установленные после создания образа, при этом перестанут работать, а изменения настроек системы также окажутся утерянными. Так что, резервируйся чаще.
#6 – Он слишком много доверял…
Практически все WEB/FTP/MAIL сервера по умолчанию устанавливают себя с привилегиями администратора, а то и системы (system), получая доступ ко всем файлам, которые только есть. Как следствие – любая ошибка конфигурации сервера, любой дефект PHP/Perl-скрипта, любая дыра самого сервера позволяют атакующему получить доступ к секретной информации или уничтожить данные.
Как защититься? Очень просто! Достаточно запускать сервер из-под ограниченного аккаунта, имеющего доступ к тем и только тем файлам, которые ему необходимы. Что это за файлы? Во-первых, файлы самого сервера, во-вторых, публичные файлы, раздаваемые пользователям. Конечно, если в сервере или скриптах имеется дыра, то злоумышленник по-прежнему сможет изменять конфигурацию сервера, а также получать несанкционированный доступ к файлам других пользователей, непредназначенным для всяких «левых» лиц.
Тем не менее, разделение привилегий на уровне файловой системы существенно ограничивает потенциальный ущерб, наносимый злоумышленником. Важно не забывать, что многие файлы по умолчанию доступы всем, и потому администратору следует тщательно проверить атрибуты секретности, явно обозначив круг лиц, имеющих право на чтение/запись каждого более или менее значимого файла.
Может ли злоумышленник обойти ограничения доступа, налагаемые файловой системой? Безусловно. Но для этого ему придется найти дыру, предоставляющую привилегии ядра или позволяющую повышать права до уровня администратора. Такие дыры действительно есть, но их сравнительно немного, и Microsoft их быстро затыкает.
#7 – DEP и ASLR
В 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-системах).
#8 – Предсказуемость конфигурации системы
Успешность большинства атак объясняется высокой предсказуемостью конфигурации системы в установке по умолчанию.
В мире открытых исходных текстов администратор может (и должен!) перекомпилировать все и вся, чтобы никакой хакер ни за что не догадался, по каким адресам лежат интересующие его функции. С Windows в этом плане ситуация намного сложнее, но не полностью безнадежна. Переименование ядра – эффективный способ борьбы с rootkit’ами, определяющими адреса функций путем вызова функции LoadLibrary(«ntoskrnl.exe») без проверки реального имени ядра, задаваемого через ключ «/kernel=» файла boot.ini. Рекомендуется переименовать ядро, например, в souriz.exe, а вместо ntoskrnl.exe положить ядро от другой версии системы, чтобы адреса экспортируемых функций отличались.
Те rootkit’ы, что правят файл непосредственно на диске, уйдут лесом, не достигнув желаемой цели (ведь ntoskrnl.exe уже никак не используется). Те же rootkit’ы, что осуществляют перехват в оперативной памяти, залезут совсем не в ту степь и вызовут BSOD, что хоть и неприятно, но успешное внедрение rootkit’а было бы еще хуже.
Естественно, после переименования ядра его необходимо обновить в кэше утилиты sfc.exe (иначе она немедленно его восстановит), а перед установкой пакетов обновлений – выполнить откат назад, поскольку пакеты обновлений (как и rootkit’ы) не проверяют реального имени ядра.
Установка системы на диск, отличный от С:, также уменьшает вероятность успешной атаки – большинство зловредных программ слишком бестолковы, а их создатели слишком ленивы, чтобы проверить переменные окружения, вот они и используют фиксированные абсолютные пути.
#9 – Бортовой журнал капитана Немо
Реестр – это крайне вредное изобретение, порождающее множество трудноразрешимых проблем. Текстовые конфигурационные файлы (традиционные для UNIX-систем) удобны тем, что в них можно оставлять ремарки и в процессе внесения изменений блокировать старые параметры символом комментария, существенно упрощая откат в случае неудачи.
А реестр?! Хорошо, если систему обслуживает всего один администратор, худо-бедно помнящий, какие параметры он менял и зачем. Когда же администраторов несколько, и все они вносят изменения в реестр, работа превращается в сплошной разбор полетов: «кто трогал реестр и весь его вытрогал?»
Чтобы этого не происходило, необходимо вести журнал (предпочтительнее всего на бумаге), описывающий каждое изменение конфигурации системы с указанием причин и сохранением предыдущих значений, заверенных подписью администратора. Тогда, если система начнет вести себя нестабильно, или же на ней обнаружатся черви, ломанувшиеся в широко открытые двери, всегда можно установить, кто именно их открыл, и чем он руководствовался.
Кстати, в нормальных фирмах у администратора есть инструкция, внятно объясняющая, какие действия он вправе выполнять, а какие – нет. Эксперименты с системой на продакшен машинах (без предварительного согласования с руководством) в общем случае строго запрещены. И это правильно!
#10 – Расплата за бездумность
Никакие защитные комплексы не дают 100% гарантии, и от риска быть атакованным никуда не деться, увы. А потому необходимо заранее выработать четкий и отлаженный план выхода из ситуации. Обнаружив на компьютере зловредную программу, мало удалить ее. Необходимо, как минимум, определить, что она успела натворить.
Помимо традиционных охранных комплексов, сервер должен быть оснащен снифферами и прочими шпионами всех мастей, протоколирующими максимум возможных действий и сохраняющими результат своей деятельности на носители однократной записи (CD/DVD-R), уничтожить которые никакой хакер не в состоянии. Они должны позволять полностью реконструировать последовательность событий, прямо или косвенно связанных с атакой.
Отсутствие подобных средств существенно ослабляет безопасность системы, поскольку, вспоминая слова Жеглова, степень защиты определяется не стойкостью сервера к атакам, а скоростью и успешностью раскрытия различных несанкционированных действий.