Как читатель может увидеть, применение коммерческих сканирующих инструментальных средств может помочь повысить эффективность тестирования хостов на уязвимости. Только представьте себе попытку тестирования хостов без автоматизированного инструментария. В настоящее время база данных 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 страниц отчета только десять были действительно полезными.
