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

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)

Из результатов сканирования видно, что хост с 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.7. Опции сканирования портов сканером Nessus

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

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

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