На главную | Содержание | Назад | Вперёд
Наши друзья

 

 

Сбор идентификационных маркеров

 


Популярность

9

Простота

5

Опасность

2

Степень риска

5

Как видно из представленного выше обзора средств для сканирования портов, при под­ключении к службе во время сканирования можно получить информацию идентификацион­ного маркера. Предоставляемые идентификационные маркеры зависят от типа используе­мого программного обеспечения (например, если в качестве Web-сервера используется I IS) и, возможно, от операционной системы. Хотя это и не очень важная информация, ее можно ис­пользовать для существенного повышения эффективности атаки, поскольку злоумышленник может выбрать атаку, наиболее эффективную против конкретной программы.
Сбор идентификационных маркеров можно проводить и для отдельных портов, пользуясь простой программой, например telnet или netcat. Ниже приведен простой пример полу­чения идентификационных маркеров с помощью программы netcat и команды HEAD про­токола HTTP (строка CLRFобозначает возврат каретки).
C:\>nc -TV victim.сои ВО
mgragrand [192 .16В.234.34]  80 (http) open ВЕЛО / НТТР/1.0 [CRLF1. ICRLP]
HTTP/1.1 200 OK Content-Length: 1433 Content-Type:   text/html
Content-Location: http://192.168.234.244/iisstart.htm
Last-Modified:   Sat,   22 Feb 2003  01:48:30 GMT
Accept-Ranges: bytes
ETag:   "06be97£14dac21:2da"
Server:  Microsoft-IIS/6.0
Date:   Sat,   24 May 2003 22:14:15 GMT
Connection: close
sent 19,   revd 300: NQTSOCK
Вместо того чтобы запоминать сложный Синтаксис для каждой службы, можно написать соответствующий текстовый файл и отправить его в сокет программы netcat. Например, возьмем команду HEAD / HTTP/1.0 [.CLEF] [CLEF] и запишем ее в текстовый файл head. txt. Теперь просто перенаправим данные из файла head, txt в открытый сокет про­граммы netcat.
С:\>пс -шг vietim.coM 80 < head.txt
Результат будет тем же, что и для введенных вручную команд.

О Меры противодействия получению идентификационных


маркеров

Бюллетень

Нет

BID

Нет

Исправлено в SP

Нет

Фиксируется

Нет

По возможности измените идентификационные маркеры, предоставляемые сетевыми служ­бами. Иногда это вызывает затруднения. Например, идентификационный маркер Web-службы 1IS жестко запрограммирован в файле %sysCemrooC%\system32\inetsrv\w3svc.dll, ко­торый нужно аккуратно отредактировать в текстовом редакторе (для этого потребуется отклю­чить и защиту системных файлов Windows, см. главу 16, "Возможности и средства защиты в сис­темах Windows").
Другой способ подмены идентификационного маркера службы IIS— установить фильтр ISAPI, который перехватывает исходящие ответы по протоколу HTTP и перезаписывает идентификационный маркер. Простой фильтр ISAPI, который перехватывает НТТР-заголовки до передачи их клиенту и заменяет заголовок сервера на строку, записанную в па­раметре реестра, описан в статье базы знаний Microsoft Q294735. Там же приводится пример программного кода. Хотя этот пример и заменяет заголовок в ответах на команду HEAD про­токола HTTP, при любой ошибке будет выведен стандартный идентификационный маркер IIS-сервера (например, в ответах HTTP 404 NOT FOUND будет указан настоящий идентифи­кационный маркер IIS). После внесения небольших изменений в предложенный в статье код, подложный заголовок будет выдаваться во всех случаях.
Используя параметр AlternateServerName= бесплатного фильтра ISAPI от компании Mi­crosoft под названием URLScan, можно изменить содержимое предоставляемых HTTP-заголовков сервера I IS. По умолчанию этот параметр не содержит никакого значения. Кроме того, необходи­мо проверить, что значение параметра RemoveServerHeader задано равным 0. Например, для обмана хакеров можно установить значение параметра AlternateServerName= равным Apache/2.0.26 (Linux) или Apache/1.3.20 (UNIX).
Кто-то может счесть ненужной установку фильтра ISAPT, который может снизить производи­тельность или стабильность системы, с единственной целью скрыть факт работы сервера IIS (который обычно легко выявляется по типу страниц на сервере — например, использование служ­бы Active Server Pages почти всегда говорит о наличии IIS). Но многие хакеры и неквалифициро­ванные злоумышленники (script kiddies) часто сканируют Internet с помощью автоматизированных средств, находят серверы под управлением IIS и пробуют использовать свежие программы для взлома IIS (см. главу 10, "Хакинг сервера IIS"). Часто подобные сценарии действуют в зависимости от содержимого идентификационного маркера сервера. Если же идентификационные маркеры вашего сервера отличаются от стандартных, то есть вероятность, что он не будет обнаружен при та­ком сканировании.
В идентификационны?! маркерах других Wcb-служб также можно разместить предупреж­дающие сообщения об уголовной ответственности пользователей, которые пытаются полу­чить несанкционированный доступ, а любое использование означает согласие с проведением мониторинга и ведением журнала действий пользователя.
Определение типа операционной системы
Если на интересующей хакера машине в результате сканирования портов была обнаруже­на запущенная TCP-служба, то можно определить тип операционной системы. Для этого ха­керы отправляют наборы специальных TCP-пакетов и затем анализируют полученные отве­ты. Поскольку в реализациях протокола TCP/IP для разных операционных систем есть неко­торые незначительные отличия, такая простая методика позволяет с достаточной степенью достоверности определить операционную систему удаленного хоста. К сожалению, в некото­рых вариантах этого метода используются нестандартные пакеты, которые могут привести к получению на удаленной системе самых неожиданных результатов (вплоть до выхода из строя операционной системы), но самые последние разработки достаточно безопасны. В на­бор функций популярного средства сканирования для системы UNIX, программы гштар, вхо­дит и функция определения типа операционной системы (OS Fingerprinting). Подробное опи­сание процесса определения типа операционной системы выходит за рамки этой книги (которая посвящена одной операционной системе), но некоторые ссылки на информацию по этой теме мы включили в раздел "Дополнительная литература и ссылки".

Значение предварительного сбора данных и сканирования
В завершение главы о сборе данных и сканировании, выскажем еще несколько соображений.
Так как программы наподобие ScanLine очень просты в использовании, то некоторые чи­татели при проверке собственных систем в' соответствии с изложенной в книге методикой могут не осознать должным образом всю важность предварительного сбора данных и скани­рования. Не делайте этой ошибки — вся проверка системы защиты строится на информации, полученной на двух первых этапах, и допущенные просчеты сделают бесполезным весь про­цесс. Кроме того, единственная пропущенная система или служба может свести на нет всю проделанную работу.
Как уже было сказано, стремитесь делать все тщательно. По своей природе сети представ­ляют собой постоянно меняющиеся системы, и, скорее всего, произойдут какие-нибудь из­менения в течение нескольких часов после первого сканирования. Поэтому важно регулярно проводить сканирование и сбор даиных о сети, аккуратно отслеживая изменения. Если же для вашей организации сложно обеспечить периодические скрупулезные проверки, рассмот­рите возможность работы со службой оценки безопасности, такой как фирма Foundstone.

 

На главную | Содержание | Назад | Вперёд
 
Яндекс.Метрика