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

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

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

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

telnet www.example.com 80

HEAD / HTTP/1.0

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: close

Создается впечатление, что последней системой является 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 –sS –v –v –O –P0 –oN results.out 192.168.0.1-5