Очень часто сайты взламывают из-за ошибок не в Web-страницах или обслуживающих их программах, а в серверном программном обеспечении. С завидной регулярностью появляются сообщения о найденных в Internet Information Server, Apache и т.д. "дырах", которые позволяют хакерам проникать на сервер, модифицировать на нем страницы и даже запускать собственные исполняемые файлы. В связи с этим администраторы вынуждены постоянно следить за выходом "заплаток" к серверному ПО и обновлять его. Однако эта практика не гарантирует успешной защиты, поскольку "заплатки" выходят после обнаружения ошибок, а хакеры могут успеть взломать сервер раньше.
Один из методов, который поможет защитить сервер от взлома и при этом не требует активной работы администратора, - это маскировка серверного ПО, т.е. настройка сервера и размещенных на нем программ таким образом, чтобы взломщик не смог определить, какое программное обеспечение используется в качестве серверного. Конечно, этот метод не отменяет необходимости установки "заплаток", но существенно уменьшает риск осуществления успешного взлома с использованием "дыр".
В каких случаях стоит маскировать сервер?
Обязательно маскировать сервер стоит в нескольких случаях. Во-первых, если вы используете такое распространенное серверное ПО, как IIS или Apache, поскольку хакеры обычно отыскивают "дыры" именно в популярных продуктах. Во-вторых, существенно повышают риск взлома запускаемые на сайте скрипты. В-третьих, к маскировке может обязывать направленность сайта, размещенного на сервере. Например, если сайт предоставляет бесплатные услуги электронной почты и/или обладает большой аудиторией, то вероятность взлома соответствующего сервера существенно выше, чем в случае размещения на нем сайта небольшой компании, который посещают ее немногочисленные клиенты и партнеры. Само собой разумеется, что чем выше уровень безопасности вашего сервера, тем лучше, поэтому маскировка не помешает и во всех остальных случаях.
Принципы маскировки сервера
Чтобы понять принципы маскировки сервера, нужно знать, какие методы применяются для определения ПО, установленного на сервере. Каждый из них требует от взломщика квалификации разного уровня и может применяться отдельно или в комплексе с другими методами.
Первый и самый простой метод заключается в определении серверного программного обеспечения по расширениям исполняемых на нем скриптов. Например, расширение ASP соответствует IIS, PHP - Apache, JSP - Tomcat и т.д. Естественно, такой метод определения типа сервера имеет не самую высокую точность, но и не требует от хакера специальных знаний.
Чуть более сложный способ заключается в вызове ошибки сервера или скрипта с последующим анализом сообщения о ней. Из этого сообщения очень часто можно определить тип не только сервера и компилятора скриптов, но и используемой базы данных. В этом случае от хакера требуются умение вызвать ошибку на сервере и некоторые дополнительные знания. Например, иногда название сервера указывается непосредственно на странице об ошибке, а иногда его можно понять только из ее исходного кода. Этот способ также не дает 100-процентной гарантии определения типа сервера, особенно в случае использования администратором собственной страницы с сообщением об ошибках.
Наконец, самый сложный и одновременно самый эффективный способ определения типа серверного ПО - по HTTP-заголовку. При передаче любых данных сервер подставляет в HTTP-заголовок свои название и версию. Просмотрев его, можно определить тип используемого сервера. Естественно, что такой способ требует от хакера знаний и навыков работы со специальными программами.
В соответствии с методами определения серверного ПО прибегают к трем приемам для его маскировки: изменение расширений исполняемых файлов, изменение или запрещение выдачи сообщений сервера об ошибках и модификация HTTP-заголовков, выдаваемых сервером. Рассмотрим каждый из этих приемов подробнее.
Расширения исполняемых файлов
Серверное программное обеспечение использует расширения файлов для связи их с определенным интерпретатором. Например, если пользователь запрашивает файл с расширением ASP, то сервер, перед тем как "отдать" его пользователю, должен "пропустить" его через интерпретатор IIS API (модули IISAPI.DLL, ASP.DLL). Если же пользователь запрашивает файл с расширением TXT или HTM, которые не связаны с интерпретатором, то они передаются ему напрямую.
Связь расширения с интерпретатором (или удаление такой связи) устанавливается при конфигурировании сервера. Для маскировки расширения скриптов, которые исполняются на сервере, нужно просто указать расширение, которое будут иметь ваши скрипты (например, PHP вместо ASP) и затем связать в настройках сервера это расширение с нужным интерпретатором. Рассмотрим на практике маскировку расширений скриптов на примере Microsoft Internet Information Server 2000.
Маскируем расширения скриптов
Запустим административную консоль управления сайтом и создадим в нем тестовую папку с названием PHP. Затем зайдем в свойства папки на вкладку Virtual Directory. На ней есть поле Execute Permissions, в котором из списка следует выбрать пункт Scripts and Executables. Это позволит запускать в новой папке скрипты.
Для конфигурации расширений скриптов нужно щелкнуть по кнопке Configuration, которая находится рядом с полем выбора Execute Permissions. Щелчок открывает окно Application Configuration, в котором нам нужна первая вкладка: App Mappings. Здесь размещена табличка, в которой и устанавливается связь между расширениями файлов и приложениями-интерпретаторами. Если какое-то расширение в этой таблице не указано, значит, файлы этого типа "отдаются" сервером пользователю напрямую.
Для того чтобы узнать, каким приложением интерпретируются ASP-скрипты, нужно найти в таблице строчку с этим расширением и щелкнуть по ней дважды. В открывшемся окне будут указаны параметры интерпретации скриптов, в том числе адрес, по которому находится интерпретирующая программа. Его нужно скопировать, затем закрыть окно и вернуться на закладку App Mappings. Теперь добавьте новый тип интерпретируемых файлов, для чего в диалоге укажите тип PHP и в качестве интерпретирующего приложения введите скопированный ранее адрес. Теперь скрипты с расширением PHP будут обрабатываться сервером как ASP.
Теперь можно закрыть окно Application Configuration и вернуться в окно свойств виртуальной директории. На вкладке Documents этого окна задаются документы по умолчанию. Как правило, там указаны значения default.asp, default.htm и index.htm. Эти записи можно удалить, а вместо них добавить default.php. Естественно, опция Enable Default Document должна быть включена.
На этом настройка сервера закончена, и можно перейти в каталог, где должны располагаться файлы виртуальной директории PHP. Здесь создадим файл DEFAULT.PHP с тестовым кодом на Visual Basic:
Теперь можно открыть файл в броузере (например, по адресу http://localhost/PHP). Загруженная страница с расширением PHP никак не "выдает" IIS, и это уже первый успех в маскировке сервера.
Сообщения об ошибках
Но не стоит обольщаться - одним расширением страницы хакера не обмануть. Достаточно набрать в адресной строке Web-броузера путь к несуществующей странице на сайте, например, http://localhost/PHP/ default1.php, и вы увидите страницу, на которой будет указано название вашего сервера. Кроме того, при любой другой ошибке запроса к серверу или к программе на сервере он будет отображать страницы с соответствующими сообщениями, из которых очень легко определить, какое серверное ПО установлено.
Дело в том, что большинство серверов использует для выдачи сообщений об ошибках стандартные странички, которые входят в дистрибутив. Естественно, что специалисты знают внешний вид этих страниц и, даже если на них не указано название сервера, всегда смогут определить его. К счастью, обычно сервер можно настроить, установив связь между ошибкой и любым файлом, размещенным на сайте. В таком случае при возникновении ошибки сервер будет отображать не стандартные страницы, а указанные в настройках.
Замена стандартных страниц вывода сообщений об ошибках на собственные выгодна не только с точки зрения маскировки серверного ПО. Можно использовать скрипт, который будет сообщать пользователю о случившейся ошибке и высылать соответствующее письмо администратору сайта. Конфигурирование сообщений об ошибках сервера рассмотрим на примере Microsoft IIS.
Маскировка сообщений об ошибках сервера на примере Microsoft IIS Сначала нужно создать страничку, которая будет отображаться в случае ошибки. Для примера настроим сервер для отображения одной и той же страницы вне зависимости от того, какая ошибка произошла. Назовем эту страницу error.php и поместим ее в папку PHP. Страница будет содержать следующий код:
Для того чтобы установить связь между ошибками и созданной страницей, нужно открыть уже знакомый диалог редактирования свойств папки PHP. На этот раз нас интересует последняя вкладка в нем - Custom Errors. Здесь находится табличка из трех колонок, в первой из которых указан номер ошибки, во второй - тип отображаемой при ошибке информации (Default - системное сообщение сервера, File - файл с диска, URL - страничка с Web-сайта), а в третьей - что именно отображается (текст сообщения, имя файла, адрес странички).
Для установки связи между ошибкой и файлом с сообщением о ней нужно щелкнуть по строке в таблице и в открывшемся диалоге выбрать из списка тип File или URL, а затем указать либо адрес файла на диске (например, C:\WWWroot\Inetpub\PHP\error.php), либо относительный путь на сервере (например, /PHP/error.php). Второй способ удобнее, т.к. серверная структура меняется реже файловой, правда, при сообщениях о некоторых ошибках его использовать нельзя.
При настройке сообщений об ошибках следует уделить особое внимание внутренней ошибке сервера с кодом 500. Она возникает при любой ошибке скрипта на сайте, и ее обязательно нужно связать с маскирующей страничкой. При этом для данной ошибки стоит создать отдельную страничку (возможно, чуть более сложную), которая будет отсылать владельцу сайта информацию о произошедшей ошибке.
После установки связи между страничкой и ошибками попробуем протестировать, как она работает. Для этого обратимся в броузере к несуществующей странице, например http://localhost/default1.php. Вместо стандартной страницы об ошибке мы увидим нашу "специальную" страницу, из которой никак нельзя определить тип используемого сервера.
Переменные в HTTP-заголовках
Вместе с каждым документом, который загружает клиент, сервер передает HTTP-заголовок, содержащий переменную с информацией о типе серверного ПО. Ее значение определено непосредственно в коде программы-сервера, поэтому замаскировать его очень сложно. С другой стороны, сделать это необходимо, поскольку иначе тип ПО сайта всегда можно достоверно определить.
Проще всего в этом случае приходится администраторам серверов с открытым исходным кодом. Для маскировки Apache, например, достаточно изменить несколько строк в файлах src/os/unix/os.h и src/include/httpd.h. Для маскировки же серверов с закрытыми исходниками (или если у администратора нет желания программировать) можно воспользоваться внешними средствами.
Так, довольно надежной защитой может послужить правильно сконфигурированный Web proxy cache, например, Novell BorderManager FastCache, Inktomi Traffic Server или сервер, работающий на клоне Squid. В таком случае клиент присоединяется к прокси-серверу, а не к Web-серверу, и соответственно в HTTP-заголовке передается информация о ПО, установленном на прокси-сервере, а не на Web-сервере.
Другой вариант защиты - установка брандмауэра, работающего на уровне TCP, например, TIS Gauntlet, BorderWare, Raptor, CyberGuard или IBM SecureWay. В этом случае HTTP-заголовок тоже не будет содержать информации о Web-сервере.
Заключение
Маскировка сервера - один из наиболее эффективных способов защиты. Каждый из упомянутых методов может использоваться по отдельности, но оптимальным решением будет их совместное применение.
Для проверки того, как работает ваша маскировка, можно обратиться на www.netcraft.com и попробовать определить тип серверного ПО и операционную систему, установленную на вашем сервере.
Кроме того, при маскировке стоит учитывать особенности того или иного продукта. Например, Microsoft IIS можно "опознать" по характерным сессионным параметрам Cookies, поэтому для лучшей маскировки IIS нужно отключить использование сессий. Кроме того, стоит помнить, что для IIS типичными являются страницы с именами default, а для UNIX-серверов - index. Поэтому использование страницы default.php может вызвать у хакера подозрения.
Как бы то ни было, использование методов маскировки не освобождает администратора сервера от обязанности следить за появлением "заплаток" и новых версий программного обеспечения.
Запустим административную консоль управления сайтом и создадим в нем тестовую папку с названием PHP. Затем зайдем в свойства папки на вкладку Virtual Directory. На ней есть поле Execute Permissions, в котором из списка следует выбрать пункт Scripts and Executables. Это позволит запускать в новой папке скрипты. 
Для того чтобы узнать, каким приложением интерпретируются ASP-скрипты, нужно найти в таблице строчку с этим расширением и щелкнуть по ней дважды. В открывшемся окне будут указаны параметры интерпретации скриптов, в том числе адрес, по которому находится интерпретирующая программа. Его нужно скопировать, затем закрыть окно и вернуться на закладку App Mappings. Теперь добавьте новый тип интерпретируемых файлов, для чего в диалоге укажите тип PHP и в качестве интерпретирующего приложения введите скопированный ранее адрес. Теперь скрипты с расширением PHP будут обрабатываться сервером как ASP. 
Теперь можно закрыть окно Application Configuration и вернуться в окно свойств виртуальной директории. На вкладке Documents этого окна задаются документы по умолчанию. Как правило, там указаны значения default.asp, default.htm и index.htm. Эти записи можно удалить, а вместо них добавить default.php. Естественно, опция Enable Default Document должна быть включена. 
На этом настройка сервера закончена, и можно перейти в каталог, где должны располагаться файлы виртуальной директории PHP. Здесь создадим файл DEFAULT.PHP с тестовым кодом на Visual Basic: 
Но не стоит обольщаться - одним расширением страницы хакера не обмануть. Достаточно набрать в адресной строке Web-броузера путь к несуществующей странице на сайте, например, http://localhost/PHP/ default1.php, и вы увидите страницу, на которой будет указано название вашего сервера. Кроме того, при любой другой ошибке запроса к серверу или к программе на сервере он будет отображать страницы с соответствующими сообщениями, из которых очень легко определить, какое серверное ПО установлено. 
Для того чтобы установить связь между ошибками и созданной страницей, нужно открыть уже знакомый диалог редактирования свойств папки PHP. На этот раз нас интересует последняя вкладка в нем - Custom Errors. Здесь находится табличка из трех колонок, в первой из которых указан номер ошибки, во второй - тип отображаемой при ошибке информации (Default - системное сообщение сервера, File - файл с диска, URL - страничка с Web-сайта), а в третьей - что именно отображается (текст сообщения, имя файла, адрес странички). 
При настройке сообщений об ошибках следует уделить особое внимание внутренней ошибке сервера с кодом 500. Она возникает при любой ошибке скрипта на сайте, и ее обязательно нужно связать с маскирующей страничкой. При этом для данной ошибки стоит создать отдельную страничку (возможно, чуть более сложную), которая будет отсылать владельцу сайта информацию о произошедшей ошибке. 
После установки связи между страничкой и ошибками попробуем протестировать, как она работает. Для этого обратимся в броузере к несуществующей странице, например http://localhost/default1.php. Вместо стандартной страницы об ошибке мы увидим нашу "специальную" страницу, из которой никак нельзя определить тип используемого сервера. 
