Защита от хакеров корпоративных сетей

Рис. 17.4. Выбор режимов сканирования сканера Internet Scanner

Начиная с этого момента, от читателя требуется просто подождать окончания работы программы: сканирования, анализа его результатов и выдачи отчета. После этого последующие шаги могут различаться. К сожалению, большое число консультантов и консультирующих организаций думают, что следующим логическим шагом является передача своему клиенту отчета вместе со счетом за проведенную работу. Вместо того чтобы просто передать отчет, следовало бы проанализировать его результаты и при необходимости вручную проверить их. Большая заслуга коммерческого инструментария заключается в определении основного направления реальных работ. Например, допустим, что после сканирования коммерческий сканер утверждает, что все пять хостов не защищены от уязвимости showcode.asp информационного сервера Интернет IIS, работающего под управлением Windows NT. Было бы мудрым решением вручную проверить каждый хост и определить, действительно ли они уязвимы так, как это утверждает программа. Сначала читатель должен проверить, что на каждом из хостов установлена операционная система Windows NT и информационный сервер Интернет IIS. Это можно сделать несколькими различными способами (вероятно, их много). Одним из них является использование команды Telnet следующим образом:

telnet www.example.com 80

HEAD / HTTP/1.0<enter><enter>

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.0

Date: Mon, 04 Feb 2002 21:41:17 GMT

Connection: Keep-Alive

Content-Length: 19398

Content-Type: text/htmlCache-control: private

...

Инструментарий

и ловушки

Изменение баннера HTTP

Простой захват данных заголовка протокола HTTP не всегда эффективен, потому что на большинстве вариантов операционной системы *NIX очень просто изменить текст баннера. При работе под управлением операционных систем компании Microsoft для изменения баннера следует при помощи шестнадцатеричного редактора отредактировать файл W3SCV.DLL и заменить баннер на то же самое число символов. Кроме того, есть множество приложений независимых производителей, которые пытаются скрыть информацию баннера.

Удачей для тех, кто занимается тестированием на проникновение, является наличие многочисленных способов идентифицировать удаленные операционные системы. Такие вещи, как генерируемые Web-сервером ошибочные страницы или даже специфический состав пакетов протокола TCP, могут стать ключом к разгадке типа удаленной операционной системы.

Как читатель может видеть, возвращенная инструментальным средством информация идентифицировала систему как информационный сервер Интернет-компании Microsoft IIS 4.0. Другой способ идентификации выполняющейся на хосте операционной системы заключается в том, чтобы просто обратиться к Netcraft по адресуи ввести IP-адрес или URL-сайта, о котором идет речь. На рисунке 17.5 показаны результаты работы Netcraft. Как можно видеть, Netcraft идентифицирует удаленную операционную систему и предоставляет другую потенциально ценную информацию о периоде работоспособного состояния машины.

Рис. 17.5. Отчет Netcraft

Путь читатель сделает вид, что он решил использовать метод Telnet на всех пяти хостах. На последнем тестируемом хосте он получит следующую информацию:

telnet www.example.com 80

HEAD / HTTP/1.0<enter><enter>

HTTP/1.1 200 OK

Date: Mon, 04 Feb 2002 21:48:31 GMT

Server: Apache/1.3.19 (Unix) mod_ssl/2.8.4 OpenSSL/0.9.6b

Last-Modified: Tue, 29 Jan 2002 15:13:47 GMT

ETag: “21-1a7a-3c56bc2b”

Accept-Ranges: bytes

Content-Length: 6778

Connection: closeContent-Type: text/html

Создается впечатление, что последней системой является Apache, которая выполняется под управлением одного из вариантов системы UNIX. Сейчас читатель знает, что информация об уязвимости информационного сервера Интернет IIS на пятом хосте неверна. Поэтому нет необходимости тестировать хост дальше. Возможно, что этот хост подвержен уязвимости систем Apache или UNIX и в дальнейшем должен быть исследован более подробно. В этом кроется ключ к разгадке возможной тайны четырех оставшихся хостов. Кажется, что на них установлена операционная система Windows NT с информационным сервером Интернет-версии 4.0. Оставшиеся хосты в дальнейшем должны быть протестированы, чтобы гарантировать фактическое существование уязвимости.

Для завершения рассматриваемого теста без знаний об уязвимости читателю не обойтись. К сожалению, коммерческие инструменты в этом вопросе особенно не помогут. Хотя некоторые из них предоставят ссылки на ресурсы Интернет, воспользовавшись которыми можно прочитать об уязвимости. К счастью, в Интернете можно найти многочисленные ресурсы, которые систематизируют информацию об уязвимости вплоть до того, что приводятся сведения о том, как протестировать интересующую уязвимость. Одним из таких ресурсов является www.securityfocus.com. Запустив поиск на сайте securityfocus.com для «showcode.asp», читатель может найти URL www.securityfocus.com/bid/167, который предоставит ему всю необходимую информацию. Для этого в окне браузера следует ввести следующий URL: www.example.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../../boot.ini.

В результате в окне браузера читатель должен увидеть содержимое файла BOOT.INI, расположенного при всех инсталляциях операционной системы Windows NT в ее корневой директории. Если файл не отображается, то следует еще раз попытаться воспользоваться той же самой программой использования уязвимости (exploit) для чтения других известных читаемых файлов. После достаточного тестирования уязвимости можно определить, действительно ли хосты уязвимы к просмотру читаемых файлов. Моментальные снимки экранных форм читаемых файлов являются хорошим дополнением к отчету, позволяющим донести до сведения читателя суть вопроса.

Как читатель может увидеть, применение коммерческих сканирующих инструментальных средств может помочь повысить эффективность тестирования хостов на уязвимости. Только представьте себе попытку тестирования хостов без автоматизированного инструментария. В настоящее время база данных CVE содержит около 1604 элементов (по данным на 13 января 2002 года). Поэтому попытка вручную проверить каждую возможную уязвимость превращается в трудновыполнимую задачу, сама мысль о решении которой отпугивает. С помощью автоматизированного инструментария исследователь просто должен проверить результаты их работы и повторно протестировать любые системы, тестирование которых выявляет слишком большое число аномалий. Чрезмерное число аномальных результатов является основанием для того, чтобы заподозрить сканер в неверной работе. Аномальные результаты тестирования и перспектива обязательной ручной перепроверки всех результатов являются причиной использования консультантами более чем одного инструментария сканирования. Обычно они используют коммерческий сканер совместно со свободно распространяемым инструментальным средством.

Тестирование свободно распространяемых инструментальных средств

Для тестирования свободно распространяемых инструментальных средств можно воспользоваться уже описанным сценарием тестирования коммерческих инструментальных средств. Вероятно, свободно распространяемые инструментальные средства более точны, поскольку их пользователь должен больше взаимодействовать с ними, вводя различные данные. Давайте опишем два различных сценария с теми же пятью хостами. Первый сценарий опишет ситуацию, когда читатель должен довериться многочисленным свободно распространяемым инструментальным средствам и собственным знаниям в области тестирования систем. Перед тем как привести пример, следует пояснить следующее. Известно, что описываемые случаи можно реализовать различными способами, возможно, даже более эффективными, чем описываемые. Автор просто использует некоторые общие примеры как вспомогательное средство для иллюстрации своей точки зрения по рассматриваемому вопросу.Во-первых, для сканирования пяти хостов можно воспользоваться утилитой Nmap и для определения открытых портов использовать следующий синтаксис:

nmap –sS –v –v –O –P0 –oN results.out 192.168.0.1-5

...

Инструментарий и ловушки

Использование Nmap: все дело в синтаксисе

Для того чтобы получить список всех опций, которые можно использовать при запуске утилиты nmap, следует в командной строке просто ввести nmap-h. Ниже приводится краткое описание синтаксиса утилиты:

• nmap – выполнимая программа;

• -sS TCP Syn – сканирование типа TCP Syn, или половинное сканирование. Этот режим работы предотвращает регистрацию сканирования на большинстве сайтов, потому что при его указании процесс процедуры установления связи до конца не завершается и таким образом нет действительных подключений к хосту;

• -v – многословный режим. При работе в этом режиме вдвое увеличивается объем выводимой

на экран информации;

• -O – удаленное определение операционной системы хоста. При установке этого режима утилита nmap предпринимает попытку идентифицировать удаленную операционную систему;

• -P0 – опция указывает утилите Nmap на то, чтобы она не пыталась прозванивать хост перед его сканированием. Этот режим работы позволяет сканировать хост, который не отвечает на запросы утилиты ping по протоколу управляющих сообщений в сети Интернет ICMP;

• -oN results.out – опция указывает утилите nmap на необходимость регистрации результатов сканирования, записывая их в файл results.out. Конечно, вместо файла results.out можно указать любой другой необходимый файл, потому что в любом случае это будет читаемый пустой файл;

• 192.168.0.1–5 – введенная строка символов указывает диапазон IP-адресов, которые утилита nmap должна просканировать. Конечно, при необходимости можно просканировать один хост или всю сеть.

После того как утилита nmap просканирует все пять систем, она возвратит результаты сканирования, которые должны быть похожи на приведенные ниже:

Interesting ports on (192.168.0.1):

(The 1522 ports scanned but not shown below are in state:

filtered)

Port State Service

80/tcp open http

443/tcp open https

TCP Sequence Prediction: Class=trivial time dependency

Difficulty=2 (Trivial joke)

Sequence numbers: 34EF1C 34EF2E 34EF40 34EF53 34EF60 34EF6E

Remote operating system guess: NT Server 4.0 SP5 running

Checkpoint Firewall-1

OS Fingerprint:

TSeq(Class=TD%gcd=1%SI=2)

T1(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)

T2(Resp=N)

T3(Resp=Y%DF=Y%W=2017%ACK=S++%Flags=AS%Ops=M)

T4(Resp=N)

T5(Resp=N)

T6(Resp=N)

T7(Resp=N)PU(Resp=N)

Из результатов сканирования видно, что хост с IP-адресом 192.168.0.1 работает под управлением операционной системы NT Server 4.0 с установленным Web-сервером, который прослушивает порты 80 (http) и 443 (http). Вероятно, в данной ситуации было бы неплохо удостовериться в том, что работающий Web-сервер является информационным сервером Интернет, который использует Netcraft или Telnet. Удостовериться в этом можно подобно тому, как это объяснено в секции «Тестирование коммерческих инструментальных средств». Как только пользователь получит подтверждение, ему станут доступны различные варианты действий. Во-первых, он может подключиться и вручную проверить каждую известную уязвимость информационного сервера Интернет IIS, но для этого, конечно, потребуется много времени. Во-вторых, он может воспользоваться сканерами whisker или VLAD для быстрой проверки некоторых из наиболее общих уязвимостей информационного сервера Интернет IIS и уязвимости showcode.asp, о которой читатель узнал во время использования коммерческих инструментальных средств.

Очевидно, что рассказанный метод использования утилиты nmap является более точным, но и он допускает ошибки или пропускает уязвимости. Как правило, этот метод использовался бы после того, как «с дерева были бы сорваны низко висящие плоды», то есть выявлены общие уязвимости. Кроме того, вместо использования VLAD или whisker для тестирования Web-сервера можно было бы написать сценарий на языке Perl, что не очень сложно. Сценарий быстро отсканировал бы Web-сервер, ища наиболее общие уязвимости информационного сервера Интернет IIS типа двойного кодирования, кодирования unicode или образцы страниц программного кода использования уязвимости, как, например, showcode.asp.

Второй вариант тестирования рассматриваемых пяти хостов заключается в использовании одного из свободно распространяемых сканеров безопасности, как, например, SAINT, SARA или Nessus. По мнению автора, SAINT и SARA не обеспечивают достаточно подробного сканирования, чтобы считаться эффективными в этом случае. Поэтому при отсутствии каких-либо ограничений рекомендуется использовать Nessus, который среди доступных, вероятно, является лучшим свободно распространяемым сканером.

Способ работы сканера Nessus очень похож на работу коммерческих продуктов сканирования. После установки соединения с сервером Nessus пользователь может подключиться и выбрать нужные ему опции сканирования подобно тому, как это показано на рис. 17.6. Кроме того, можно устанавливать желаемый тип сканирования портов сканером Nessus так, как это показано на рис. 17.7. Как можно видеть из двух приведенных экранных форм, использование Nessus позволяет исключить необходимость запуска сначала утилиты nmap, а затем скрипта пользователя со всеми встроенными в него необходимыми опциями.

Рис. 17.6. Конфигурация Nessus

Рис. 17.7. Опции сканирования портов сканером Nessus

Следует иметь в виду, что подобно коммерческим сканерам сканер Nessus может быть склонен к случайным ложным срабатываниям и неверной идентификации хоста. Точно так же, как и в случае коммерческих инструментальных средств, следует проявить мудрость, с умом проверяя отчеты и сличая информацию.

Случаи, когда инструментальных средств недостаточно

Нет сомнения в том, что инструментальные средства сканирования уязвимости изменили лицо тестирования на проникновение и заняли свою нишу. Но в то же время они не являются палочкой-выручалочкой из всех бед нарушения безопасности. Если сможете, то возразите автору. Он хочет поделиться своим опытом, который он приобрел во время работы в большой аутсорсинговой (outsourcing – привлечение внешних ресурсов для решения собственных проблем, например для разработки проекта) организации и отвечал за внутреннюю безопасность ее сети. Один из новых клиентов организации, у которого была большая распределенная сеть, состоящая из многих систем и платформ, решил воспользоваться услугами независимого консультанта для выполнения теста на проникновение в свою сеть. Описываемые события происходили в 1998 году, когда мистика хакерской культуры привлекала всеобщее внимание и тесты на проникновение только начинали приобретать популярность.

Клиент, о котором идет речь, выбрал компанию, оказывающую услуги по тестированию сети на проникновение откуда-то из Сан-Франциско, и предоставил им необходимую информацию для тестирования своих систем сети, взаимодействующих с внешним миром. По прошествии нескольких дней консультант клиента прислал курьером итоговый отчет. К отчету был приложен их счет на сумму что-то около 10 000 долл. К сожалению, будучи внешним соисполнителем, у автора не было возможности просмотреть отчет, присланный независимым консультантом. Он смог его увидеть только тогда, когда менеджер по информатизации (CIO) клиента вызвал автора в свой офис и попросил объяснить ему, почему приглашенный извне консультант, выполнивший тест на проникновение в их сеть, нашел свыше 50 различных уязвимостей в их Web-серверах. Конечно, автор был потрясен. Он думал, что хорошо выполнял свои обязанности, сохраняя в безопасности сервер на уровне всех последних найденных уязвимостей и патчей. Автор даже выполнял свой собственный мини-тест на проникновение для контроля самого себя. И ни разу не было обнаружено чего-то такого, что свидетельствовало бы о каких-либо недочетах. Автор попросил познакомить его с отчетом независимого консультанта. И как только менеджер по информатизации вручил его автору, он сразу же заметил на нем логотип одного из производителей коммерческих сканеров уязвимости. В процессе дальнейшего изучения отчета было обнаружено, что высокооплачиваемый независимый консультант просто применил коммерческий продукт (использование которого можно было легко оплатить за указанную им цену) для тестирования нужных систем, распечатал отчет и отослал его вместе со счетом. Для автора было ясно, что этот так называемый независимый консультант, выполнивший тест на проникновение, не удосужился каким-либо образом проверить результаты тестирования. В конечном счете, для того чтобы убедить менеджера по информатизации в недостоверности предоставленного ему отчета, пришлось вызвать независимого консультанта в офис для очной встречи всех заинтересованных сторон. После просмотра всего отчета стало ясно, что консультант не понял содержимое отчета и лишь прочитал его перед отправкой. Из переданных клиенту автора более 400 страниц отчета только десять были действительно полезными.