А. Н. Андрончик, В. В. Богданов, Н. А. Домуховский, А. С. Коллеров, Н. И. Синадский, Д. А. Хорьков
 Скачать 9.2 Mb.
|
|
arping –i eth1 –c 1 192.168.10.1 ARPING 192.168.10.1 60 bytes from 00:40:05:05:a4:0b (192.168.10.1): index=0 time=66.996 usec --- 192.168.10.1 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered Из результата работы приведенной команды можно сделать вывод, что узел с IP-адресом 192.168.10.1 доступен и MAC-адрес соответствующего ин- терфейса имеет вид 00:40:05:05:a4:0b. С использованием утилиты tethereal, которая предназначена для пере- хвата сетевого трафика (здесь термин перехват сетевого трафика понимается как отображение или копирование трафика, проходящего через сетевой ин- 211 терфейс), можно отследить соответствующую сетевую активность. В примере используется ключ -i для указания сетевого интерфейса, с которого будет происходить перехват трафика. Ключевое слово arp указывает на то, что будут сниматься только данные протокола ARP. v-3:/home/bvv# tethereal -ieth1 arp 2>/dev/null 0.000000 192.168.10.3-> Broadcast ARP Who has 192.168.10.1? Tell 10.0.0.4 0.000249 server.alpha.local -> 192.168.10.3 ARP 192.168.10.1 is at 00:40:05:05:a4:0b Из приведенного примера видно, что с интерфейса с IP-адресом 192.168.10.3 было послано широковещательное ARP-сообщение с целью оп- ределения MAC-адреса узла 192.168.10.1 и был получен ответ от узла server.alpha.local. Данный метод можно использовать не только при нахождении в одном сегменте с обследуемыми сетевыми узлами, но и при включенной на гранич- ном маршрутизаторе сетевого сегмента функции proxy-arp. TCP- и UDP-разведка представляют собой методы, при которых дос- тупность сетевого узла определяется на основании доступности соответст- вующих TCP- либо UDP-портов. Заметим, что данный метод отличается от сканирования портов, так как достаточно получить любой ответ от любой службы обследуемого сетевого узла. Для реализации этого метода обнаружения можно воспользоваться ути- литой hping3. Указанная утилита представляет собой многофункциональный сетевой отладчик, и, в частности, может использоваться для реализации опи- санного метода. Для запуска утилиты воспользуемся командой hping3 -p 81 192.168.10.1 -c 3, ключ -p указывает на номер порта, на который будет послан запрос (по умолчанию используется TCP-порт), ключ -с опреде- ляет количество отправляемых пакетов. # hping3 -p 81 192.168.10.1 -c 3 HPING 192.168.10.1 (eth0 192.168.10.1): NO FLAGS are set, 40 headers + 0 data bytes len=46 ip=192.168.10.1 ttl=128 id=17590 sport=81 flags=RA seq=0 win=0 rtt=0.8 ms len=46 ip=192.168.10.1 ttl=128 id=17591 sport=81 flags=RA seq=1 win=0 rtt=0.5 ms len=46 ip=192.168.10.1 ttl=128 id=17592 sport=81 flags=RA seq=2 win=0 rtt=0.6 ms --- 192.168.10.1 hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.5/0.6/0.8 ms В приведенном примере в результате выполнения команды hping3 путем посылки TCP-пакета на порт 81 (без установленных флагов) и анализа ответ- ного пакета (установлены флаги RST и ACK) получены сведения о том, что 212 сетевой узел 192.168.10.1 присутствует в сети. После завершения работы ути- лита hping3 выводит статистику — количество отосланных и полученных па- кетов, а также минимальное, среднее и максимальное время доставки пакетов. С помощью этой же утилиты можно реализовать описанный метод с ис- пользованием протокола UDP. Для этого можно использовать команду hping3 -2 –n -p 81 192.168.10.1 -c 3, ключ -2 указывает на ис- пользование протокола UDP, -n отключает разрешение DNS-имени. # hping3 -2 -n -p 81 192.168.10.1 -c 3 HPING 192.168.10.1 (eth0 192.168.10.1): udp mode set, 28 headers + 0 data bytes ICMP Port Unreachable from ip=192.168.10.1 ICMP Port Unreachable from ip=192.168.10.1 ICMP Port Unreachable from ip=192.168.10.1 --- 192.168.10.1 hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms В приведенном примере в результате выполнения команды hping3 полу- чены сведения о том, что сетевой узел 192.168.10.1 присутствует в сети. Дан- ная информация была получена путем отсылки UDP-пакета на 81 порт и ана- лиза ответного пакета (было получено ICMP-сообщение «порт не доступен»). Обратите внимание, что если соответствующий UDP-порт будет открыт, то метод функционировать не будет. Аудитор может получить информацию об имеющихся в сети устройст- вах из ARP-кэшей серверов и активного сетевого оборудования. Получение этой информации возможно, если аудитор находится в рамках модели «белого ящика». Обычно для этого необходимо выполнить команды arp –aна сер- вере и show arp в консоли активного сетевого устройства (на примере обо- рудования Cisco). CDP-разведка. Данный метод позволяет обнаружить и получить инфор- мацию об устройствах, работающих по протоколу CDP (Cisco Discovery Proto- col — протокол обнаружения Cisco) и находящихся в одном сетевом сегменте. Информацию о CDP-узлах можно получать, непосредственно подключаясь к консоли активного сетевого устройства производства фирмы Сisco Systems либо перехватывая CDP-объявления (например, с использованием утилиты cdpr от MonkeyMental.com). Прослушивание сети. Данный метод заключается в перехвате сетевых пакетов из некоторого сетевого сегмента и в последующем анализе исполь- зуемых IP-адресов. Для реализации данного метода можно использовать ути- литу Ethereal. ВЫПОЛНИТЬ! 3. Выявите сетевые узлы в локальном сетевом сегменте с использованием: 213 − утилиты fping; − утилиты ping и широковещательной ICMP-посылки; − утилиты icmpush (тип ICMP-пакетов13 и 17); − утилиты ping и многоадресной рассылки; − утилиты arping; − утилиты hping3 и методов TCP- и UDP-разведки; − утилиты arp и метода ARP-кэша; − утилиты Ethereal и метода прослушивания сети. Напишите сценарий, выводящий список IP-адресов сетевых узлов, извлеченных из перехваченных с сетевого интерфейса пакетов (рекомендуется воспользоваться консольным вариантом утилиты Ethereal – tethereal). 4. По результатам сделайте вывод о возможности идентификации сетевых узлов в исследуемой сети различными методами, заполните строку 3 таб- лицы 8.2. 8.5. Сканирование портов и идентификация ОС Для сканирования портов и для идентификации версий ОС и сервисов можно использовать утилиту nmap, которая реализует большое количество методов и техник сканирования портов и идентификации ресурсов. Утилита nmap позволяет формировать результаты сканирования в формате XML для просмотра web-обозревателем с использованием XSL-преобразования. Для решения задачи обнаружения открытых TCP- и UDP-портов, а так- же ОС, сервисов и их версий на удаленном сетевом узле 192.168.10.1 можно воспользоваться командой nmap –sS –sU –sV –O --osscan-guess 192.168.10.1, выполняемой на станции сканирования Linux. Ключ -sS ука- зывает на сканирование TCP-портов, ключ -sU — на сканирование UDP- портов, ключ -sV указывает на идентификацию сетевых сервисов, ключ -O — на идентификацию ОС, использование ключа -ossccan-guess предполагает «агрессивную» идентификацию ОС. По умолчанию применяется техника случайного сканирования, то есть тестирование портов происходит в случайном порядке. # nmap -sS -sU -sV -O --osscan-guess 192.168.10.1 Starting Nmap 4.20RC1 ( http://insecure.org ) at 2006-12-01 22:16 YEKT Interesting ports on 192.168.10.1: Not shown: 3144 closed ports PORT STATE SERVICE VERSION 21/tcp open tcpwrapped 25/tcp open smtp Microsoft ESMTP 6.0.3790.1830 53/tcp open domain Microsoft DNS 80/tcp open http Microsoft IIS webserver 6.0 88/tcp open kerberos-sec Microsoft Windows kerberos-sec 110/tcp open pop3 Microsoft Windows 2003 POP3 Service 1.0 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn 389/tcp open ldap Microsoft LDAP server 443/tcp open ssl/http Microsoft IIS webserver 6.0 214 445/tcp open microsoft-ds Microsoft Windows 2003 microsoft-ds 464/tcp open kpasswd5? 593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 636/tcp open ssl/ldap Microsoft LDAP server 1026/tcp open msrpc Microsoft Windows RPC 1027/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 1248/tcp open msrpc Microsoft Windows RPC 1723/tcp open pptp? 3268/tcp open ldap Microsoft LDAP server 3269/tcp open ssl/ldap Microsoft LDAP server 53/udp open domain? 67/udp open|filtered dhcps 68/udp open|filtered dhcpc 88/udp open|filtered kerberos-sec 123/udp open ntp NTP v3 137/udp open netbios-ns Microsoft Windows NT netbios-ssn (workgroup:ALPHA) 138/udp open|filtered netbios-dgm 389/udp open|filtered ldap 445/udp open|filtered microsoft-ds 464/udp open|filtered kpasswd5 500/udp open|filtered isakmp 1701/udp open|filtered L2TP 3456/udp open|filtered IISrpc-or-vat 4500/udp open|filtered sae-urn 1 service unrecognized despite returning data. If you know the ser- vice/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port53-UDP:V=4.20 … (часть вывода вырезана) MAC Address: 00:0C:29:37:7B:86 (VMware) Device type: general purpose Running (JUST GUESSING) : Microsoft Windows 2003|XP|2000 (94%) Aggressive OS guesses: Microsoft Windows 2003 Server SP1 (94%), Microsoft Windows XP SP2 (92%), Microsoft Windows XP SP2 (firewall disabled) (91%), Microsoft Windows 2000 Server SP4 (90%), Microsoft Windows 2000 SP3 (90%), Microsoft Windows 2000, SP0, SP1, or SP2 (89%), Microsoft Windows 2000 SP4 (88%), Microsoft Windows Server 2003 Enterprise Edition 64-Bit SP1 (87%) No exact OS matches for host (If you know what OS is running on it, see http://insecure.org/nmap/submit/). TCP/IP fingerprint: OS:SCAN(V=4.20RC1%D=12/1%OT=21%CT=1%CU=1%PV=Y%DS=1%G=Y%M=000C29%...%DLI=S) (часть вывода удалена) Network Distance: 1 hop Service Info: Host: server.alpha.local; OSs: Windows, Windows 2000 OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ . Nmap finished: 1 IP address (1 host up) scanned in 151.541 seconds Из приведенных результатов работы утилиты nmap можно сделать вы- вод, что на узле 192.168.10.1 открыты TCP-порты 21, 25, 53, 80, 88, 110 и т.д., причём были идентифицированы следующие сервисы, использующие эти порты: − порт 25 — почтовый сервер ESMTP, производитель Microsoft; − порт 53 — DNS-сервер, производитель Microsoft; − порт 80 — web-сервер IIS, версия 6.0, производитель Microsoft; − порт 88 — сервер Kerberos для Microsoft Windows, производитель Microsoft; 215 − порт 110 — почтовый сервер POP3 для Microsoft Windows 2003, произ- водитель Microsoft − … UDP-порты 53, 67, 68 и др. открыты, причем если указано состояние «open», то порт явно открыт. Если состояние «open|filtered», то порт может быть открыт, а может быть отфильтрован межсетевым экраном. Различить эти состояния не представляется возможным вследствие особенностей реализо- ванного метода UDP-сканирования (при тестировании порта не было получе- но ICMP-сообщение «порт недоступен»). Была идентифицирована большая часть сервисов, использующих пере- численные UDP-порты. Однако идентификация сервиса, функционирующего на UDP-порту 53, не прошла корректно вследствие большого количества за- просов к серверу. Тем не менее, если провести повторное сканирование с по- мощью команды nmap -sU -p U:53 -sV 192.168.10.1 , где опция -p U:53 указывает, что обследоваться должен только один UDP-порт 53, то мож- но идентифицировать версию сервиса. # nmap -sU -p U:53 -sV 192.168.10.1 … Interesting ports on 192.168.10.1: PORT STATE SERVICE VERSION 53/udp open domain Microsoft DNS … После перечня открытых портов nmap возвращает следующую инфор- мацию: − MAC-адрес производителя сетевого адаптера (в соответствии с префик- сом MAC-адреса). Обратите внимание, что если бы станция сканирования Linux и сетевой узел 192.168.10.3 находились в различных IP-сетях (были свя- заны через маршрутизатор), то этот адрес был бы неизвестен, так как для его определения используется протокол ARP: MAC Address: 00:0C:29:37:7B:86 (VMware) − выявленный тип обследуемого устройства, в данном случае указано, что это устройство общего назначения (другие возможные значения router – мар- шрутизатор, switch – коммутатор, game console – игровая консоль и др.): Device type: general purpose Утилита nmap в примере не смогла точно идентифицировать тип и вер- сию ОС. Тем не менее указано, что вероятней всего (с уровнем доверия 94 %) это версия Microsoft Windows 2003, XP либо 2000. Проанализировав тип поч- тового сервиса POP3, можно сделать вывод, что на обследуемой системе за- пущена ОС Windows Server 2003. В выводе также указываются степени дове- рия относительно других ОС, полученные путём «агрессивной» идентифика- ции ОС. 216 Далее в выводе указывается «сетевое расстояние» (network distance), то есть количество промежуточных IP-сетей. В приведённом примере этот пара- метр равен единице, так как станция сканирования Linux и сетевой узел 192.168.10.1 находятся в одной IP-подсети: Network Distance: 1 hop Service Info: Host: server.alpha.local; OSs: Windows, Windows 2000 Параметр «Service Info» содержит краткую информацию об имени узла, а также предполагаемый тип и версию ОС. В конце вывода команды приводится информация о количестве проска- нированных IP-адресов и о суммарном времени сканирования. С использованием ключа -oX <имя xml-файла> результаты сканирова- ния можно сохранить в формате XML для дальнейшего удобного изучения с помощью web-обозревателя или для дальнейшей автоматической обработки. ВЫПОЛНИТЬ! 5. С помощью утилиты nmap проведите сканирование портов сетевых узлов, найденных на предыдущем шаге. Сформируйте списки открытых TCP- и UDP-портов, идентифицируйте версии ОС и запущенных сервисов. По ре- зультатам сделайте вывод о возможности обнаружения открытых портов и идентификации типа и версии ОС, а также сетевых сервисов на сетевых узлах исследуемой сети, заполните строку 4 табл. 8.2. 8.6. Использование DNS для обнаружения и выяснения назначения сетевых узлов Использование DNS-серверов позволяет аудитору (в рамках модели «черного ящика») получить информацию о назначении сетевых узлов иссле- дуемых сегментов ЛВС и внешних сетевых узлов организации. Например, на- личие в базе DNS записи типа MX для узла «smtp.example.ru» дает аудитору информацию о том, что указанный узел является почтовым сервером. Обрат- ный DNS (записи типа PTR) позволяет получить одно из имен сетевого узла по IP-адресу. Для взаимодействия с DNS-сервером могут быть использованы стан- дартные системные утилиты nslookup (ОС Windows и UNIX), host или dig (ОС UNIX). Непрерывный набор пространства имен DNS называется зоной DNS. Для получения зоны DNS можно использовать протокол переноса зоны DNS (DNS zone transfer известен так же, как AXFR). Рассмотрим пример переноса зоны DNS с использованием утилиты dig. Для этого необходимо указать тип запроса – axfr и параметр «@имя_сервера», указывающий на сервер, с которого будет произведен перенос зоны DNS. 217 $ dig axfr examp1.si.ru @ns.examp1.si.ru ; <<>> DiG 9.2.4 <<>> axfr examp1.si.ru @ns.examp1.si.ru ;; global options: printcmd examp1.si.ru. 86400 IN SOA examp1.si.ru. n.examp1.si.ru. 2006102601 86400 7200 2419200 604800 examp1.si.ru. 86400 IN NS ex1.pp.ru. examp1.si.ru. 86400 IN NS ns.secondary.net.ua. examp1.si.ru. 86400 IN A 145.23.211.2 examp1.si.ru. 86400 IN MX 10 ex.miti.ru. icq.examp1.si.ru. 86400 IN CNAME examp1.si.ru. deltaplan.examp1.si.ru. 86400 IN A 232.44.22.77 deltaplan.examp1.si.ru. 86400 IN MX 10 mail1.delta-plan.ru. webcam.examp1.si.ru. 86400 IN A 195.64.22.33 home.examp1.si.ru. 86400 IN A 83.44.44.44 ex1.examp1.si.ru. 86400 IN A 34.12.34.22 conference.examp1.si.ru. 86400 IN CNAME examp1.si.ru. squish.examp1.si.ru. 86400 IN MX 10 squish.examp1.si.ru. squish.examp1.si.ru. 86400 IN A 230.252.141.7 vjud.examp1.si.ru. 86400 IN CNAME examp1.si.ru. examp1.si.ru. 86400 IN SOA examp1.si.ru. n.examp1.si.ru. 2006102601 86400 7200 2419200 604800 ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(localhost) ;; WHEN: Thu Nov 2 13:01:11 2006 ;; XFR size: 19 records В приведенном примере c помощью утилиты dig был произведен пере- нос зоны DNS с DNS-сервера «ns.examp1.si.ru». Вывод команды представляется в табличной форме, которая повторяет структуру базы DNS. Первая строка таблицы является записью типа SOA (Start of Authority) которая, в частности, идентифицирует имя домена или зо- ны DNS: «examp1.si.ru.n.examp1.si.ru». Все имена, которые не заканчиваются точкой, дополняются именем домена для зоны DNS. Например, если бы в примере встретилось имя «example.ru» (без заключительной точки), то оно бы трансформировалось в имя «example.ru.example1.si.ru». Затем указан серий- ный номер, интервал времени, через который происходит обновление первич- ного DNS-сервера, и интервал, через который необходимо проводить обнов- ление, если первая попытка обновления была неудачной. Две последующие строки указывают на имена DNS-серверов «ex1.pp.ru» и «ns.secondary.net.ua», которые являются авторитетными для данного домена (то есть такими DNS-серверами, которые содержат информацию об этой зо- не). Следующая запись типа A отображает имя сетевого узла examp1.si.ru на его IP-адрес 145.23.211.2. Запись типа MX идентифицирует почтовый сервер. Основываясь на проведенном листинге можно сделать вывод, что для домена «examp1.si.ru» почтовым сервером является «ex.miti.ru» с числом предпочтения 10 (исполь- зуемым для выбора того либо иного сервера при маршрутизации почты). Дру- 218 гими словами, если адрес получателя письма будет иметь вид «user@exam1.si.ru», то оно будет передано на почтовый сервер «ex.miti.ru». Запись типа CNAME отображает псевдоним сетевого узла на его кано- ническое имя. Основываясь на листинге, можно сделать вывод, что «icq.examp1.si.ru» является псевдонимом для «examp1.si.ru» и, следовательно, соответствует серверу с IP-адресом 145.23.211.2. Последней записью в таблице является запись типа SOA, что соответст- вует строгому определению зоны DNS: зона DNS — это серия записей DNS, начинающаяся с записи типа SOA для запрашиваемого имени, продолжаю- щаяся любым количеством записей, отличных от SOA, заканчивающаяся по- вторным вхождением записи SOA. Приведенная команда возвращает также время выполнения запроса, ад- рес DNS-сервера, к которому был произведен запрос, время, когда был произ- веден запрос, и количество записей, которые были возвращены. Ключевое слово «IN» в строках вывода указывает на то, что используется адресация и схема именования, применяемая в Интернет. Одной из возможных записей в таблице DNS может быть запись типа SRV. Записи типа SRV предназначены для идентификации сетевых узлов, на которых присутствует заданный сервис. Эта запись позволяет пользователям, зная имя домена и имя нужного сервиса, получать имя узла и порт, на котором этот сервис запущен. Например, наличие записи «_http._tcp.example.com. IN SRV 0 5 80 www.example.com.» указывает на то, что сервис HTTP использует порт 80 сервера «www.example.com». Элемент «_http» указывает на тип сервиса – HTTP. Элементы «_ftp» и «_ldap» — другие часто встречающиеся значения, указывающие соответственно на FTP- и LDAP-сервисы. Элемент «_tcp» ука- зывает, что в качестве транспортного протокола для этого сервиса использу- ется TCP. Значения 0, 5 и 80 указывают соответственно на приоритет, вес и номер порта, который используется сервисом. Таким образом, осуществляя анализ информации, полученной путем пе- реноса зоны DNS, можно получить подробную информацию о системном ландшафте (т.е. о составе и назначении серверов) организации. В целях затруднения инвентаризации ресурсов системного ландшафта злоумышленником возможность переноса зоны DNS на недоверенные узлы должна быть запрещена. ВЫПОЛНИТЬ! 6. Убедитесь, что настройки DNS-сервера, функционирующего на узле «Сервер», разрешают передачу зоны DNS. Для проверки и включения это- го параметра выполните команду dnsmgmt.msc /s (можно через меню Пуск ⇒ Администрирование ⇒ DNS), в левой панели появившегося окна раскройте список «Forward Lookup Zones», из контекстного меню зоны alpha.local выберите пункт Свойства (Properties), перейдите в закладку 219 «Передача зоны» (Zone Transfers), убедитесь что пункт «Разрешить пере- дачу зоны» (Allow zone transfers) включен. В случае, если параметр вы- ключен, его необходимо включить (рис. 8.3). 7. С помощью утилиты dig, установленной на станции сканирования Linux, получите описание зоны DNS. Проанализируйте полученные данные. Сделайте выводы о том, какую информацию о сети можно получить с ис- пользованием передачи зоны DNS. Дополните строку 3 таблицы 8.2. Рис. 8.3. Разрешение передачи зоны DNS 8.7. Создание карт сети Карта сети позволяет получить представление об архитектуре и струк- туре сети. Обычно карта сети представляет изображение сетевой топологии в рамках физического (физическое расположение сетевых узлов и каналов, рис. 8.4), канального (способ коммутации сетевых узлов, рис. 8.5) и сетевого (схе- ма взаимодействия между IP-подсетями, рис. 8.6) уровней модели OSI. Существуют способы автоматического получения карты сети. Напри- мер, программы LAN MapShot и NetCrunch позволяют построить карты сети канального и сетевого уровней. 220 Рис. 8.4. Карта сети на физическом уровне Рис. 8.5. Карта сети на канальном уровне 221 Рис. 8.6. Карта сети на сетевом уровне Рассмотрим пример карты сети, построенной с использованием утилиты NetCrunch (рис. 8.7). Все найденные сетевые узлы соединены линией, обозна- чающей, что они находятся в одном сетевом сегменте. Для построения карты сети на сетевом уровне можно воспользоваться утилитой traceroute (tracert в ОС Windows). Указанная утилита позволяет оп- ределить путь, пройденный пакетом от отправителя к получателю. Комбини- руя эту информацию, можно создать карту сети. Утилиты NetCrunch и Visual Route используют указанный метод для автоматического построения карт сети на сетевом уровне. ВЫПОЛНИТЬ! 8. С помощью демонстрационной версии программы NetCrunch, установлен- ной на станции сканирования «Windows», постройте карту моделируемой сети. Для построения карты сети воспользуйтесь мастером построения карты «Create New Atlas», которого можно запустить при старте утилиты NetCrunch. Выберите «Yes» в окне подтверждения автоматического поис- ка устройств. В качестве адреса сети и маски укажите 192.168.10.0 и 255.255.255.0 соответственно. Выберите автоматический способ обнару- жения сетевых узлов. Нажмите кнопку «next», выберите пункт «Все сете- вые узлы» (All nodes). После обнаружения сетевых узлов карту сети мож- но просмотреть, выбрав адрес сети в пункте IP Networks ⇒ Local левой панели. С помощью команды File ⇒ Export ⇒ Export Map карту сети можно сохранить в графическом файле. 222 Рис. 8.7. Пример карты, построенной с помощью утилиты NetCrunch 8.8. Использование сканера безопасности Nessus Сканер безопасности — это программное или программно-аппаратное средство, предназначенное для автоматизации процедуры выявления уязвимо- стей компьютерных систем. Его главной функцией является выяснение версий установленного программного обеспечения и ошибок конфигурации, в том числе в парольной политике. Для этого сканер безопасности обнаруживает доступные на узле сетевые службы, пытается подключиться к ним, а после этого — произвести соответствующий набор тестов. Алгоритм работы сканера безопасности заключается в следующем: опе- ратор задает некоторый набор IP-адресов или DNS-имен узлов, которые необ- ходимо просканировать. После этого сканер производит проверку доступно- сти данного узла, затем идентифицирует открытые порты и определяет запу- щенные сетевые сервисы. Основным компонентом сканера безопасности является база уязвимо- стей. Используя ее, сканер пытается проверить уязвимости сетевых сервисов, поочередно применяя тесты, подходящие для данного выбранного сервиса. Сканеры безопасности могут проводить обнаружение уязвимостей не только в сетевых сервисах, но и в ОС, в локальных сервисах и приложениях. После за- вершения сканирования все собранные данные объединяются в отчеты раз- личной формы. Аудитор может включать данные отчеты в документы, описы- вающие результаты инструментальной проверки. 223 При использовании сканеров безопасности аудитор должен соблюдать повышенную осторожность, так как при тестировании они могут реализовы- вать атаки на уязвимые системы, что может спровоцировать нарушение нор- мальной работоспособности системы. Сканер безопасности не пытается «взломать» обследуемый узел, тем не менее производимые тесты могут быть опасными в том плане, что способны вызвать отказ в обслуживании. Кроме того, некоторые сканеры, такие как LANguard Network Security Scanner, позволяют выполнять атаку «удаленный подбор пароля» для доступа к общим файлам и папкам (в ОС семейства Windows NT это эквивалентно атаке на учетную запись пользователя). В качестве иллюстрации рассмотрим широко известный и популярный сканер Nessus. Программная часть Nessus версии 3.0 является свободно рас- пространяемой, но для пользователей, которые не приобрели лицензию, об- новление баз данных уязвимостей производится только через неделю с мо- мента их выпуска. Кроме того, свободно распространяемая версия может применяться лишь для сканирования узлов в подсетях класса C. Структурно Nessus состоит из серверной части, клиентской части и на- бора подключаемых модулей (plug-ins). Серверная часть обеспечивает взаи- модействие с сетевой средой, запуск выбранных тестов, а также получение и первичную обработку их результатов. Подключаемые модули — это сценарии тестов, написанные на специально разработанном для этого интерпретируе- мом языке NASL (Nessus Attack Scripting Language). Клиентская часть обеспе- чивает взаимодействие пользователя с сервером, выбор и настройку тестов, а также генерацию отчетов о сканировании. Обмен между клиентской и сервер- ной частями ведется по прикладному протоколу NTP (Nessus Transport Protocol) и может быть как открытым (без шифрования передаваемого трафи- ка), так и закрытым (с шифрованием по одному из протоколов SSL или TLS). По умолчанию сервер использует порт 1241. Главной особенностью сканера безопасности Nessus является откры- тость сценариев тестирования и возможность написания пользователем своих собственных сценариев или доработки существующих. Этим Nessus карди- нально отличается от подавляющего большинства коммерческих сканеров, программный код которых является на 100 % закрытым. Рассмотрим применение сканера безопасности Nessus на примере вер- сии 3.0.3 для ОС семейства Microsoft Windows. Установка данного сканера производится стандартным образом. Обязательным условием его нормальной работы является наличие функционирующей службы Tenable Nessus (рис. 8.8), которая устанавливается вместе со сканером. Чтобы начать сканирование, необходимо нажать кнопку «Start Scan Task» в меню программы. Исходными данными для сканирования узла явля- ются его IP-адрес (рис. 8.9), а также совокупность тестов, которые необходи- мо выполнить (рис. 8.10). 224 Рис. 8.8. Служба Tenable Nessus в перечне служб Чтобы выбрать все тесты, за исключением «опасных» (тех, что могут вывести узел из работоспособного состояния), и использовать при этом на- стройки «по умолчанию», необходимо выбрать пункт «Enable all but dangerous plugins with default settings». При наличии уверенности в том, что временный выход узла из строя не нанесет никакого ущерба, можно выбрать пункт «En- able all plugins with default settings». При необходимости определить конкрет- ный список проводимых тестов, а также потребности изменить настройки программы нужно выбирать пункт «Define my policy». Следует заметить, что в этом случае сделанные настройки и выбранный список тестов будут действо- вать лишь в ходе одной операции сканирования. Поэтому более разумным яв- ляется предварительное создание собственной политики сканирования с ис- пользованием диалогового окна «Manage Policies» (рис. 8.11), которое откры- вается из меню программы. Под политикой понимается набор тестов и на- строек программы. Чтобы создать новую политику, необходимо нажать кнопку «Add a new policy», а затем ввести ее имя. Для изменения настроек необходимо нажать «Edit Settings», а для выбора списка тестов — «Edit Plugins». Диалоговое окно с настройками программы показано на рис. 8.12. 225 Рис. 8.9. Указание IP-адреса сканируемого узла Рис. 8.10. Отключение опасных тестов 226 Рис. 8.11. Создание политики сканирования Рис. 8.12. Изменение настроек политики сканирования 227 Все настройки снабжены пояснениями, поэтому детально рассматри- ваться не будут. Чтобы вызвать соответствующее пояснение, необходимо щелкнуть на названии настройки (курсор при этом примет форму стрелки с вопросительным знаком). Тем не менее следует отдельно остановиться на на- стройке «Safe Check». Включение данной опции отменяет использование тес- тов, которые могут вызвать отказ узла, подвергающегося сканированию. В не- зарегистрированной версии Nessus 3.0.3 для Windows эта опция не действует, и «опасные» тесты вообще не проводятся. Диалоговое окно, в котором осуществляется выбор тестов безопасности (подключаемых модулей), представлено на рис. 8.13. В левой части экрана отображаются группы, на которые поделены все тесты, а в правой, при выборе соответствующей группы, — собственно список тестов. Подключаемые моду- ли сгруппированы по типам уязвимостей и используемому на сканируемом узле программному обеспечению (тип операционной системы, наличие web- сервера, FTP-сервера и пр.). Если известно, какая операционная система установлена на сканируе- мом узле, то можно ускорить процедуру сканирования выбором только акту- альных для этой системы тестов. В остальных случаях рекомендуется выпол- нять максимальное число тестов. Если создана политика сканирования с необ- ходимыми настройками, то при запуске сканирования можно выбрать пункт «Use a predefined policy» и далее — требуемую политику. Рис. 8.13. Выбор подключаемых модулей 228 Диалоговое окно Nessus в процессе сканирования показано на рис. 8.14. Сценарий теста для каждой уязвимости в общем случае уникален. Иногда это лишь подключение к соответствующему порту и получение первичной ин- формации о программном обеспечении сервера, в других случаях дополни- тельно выполняется ряд запросов, чтобы установить, доступны ли функции, в реализациях которых существуют уязвимости. Существует отдельная катего- рия «опасных» тестов, которые представляют собой реализации атак на отказ в обслуживании (классическим примером является WinNuke). В версии Nessus для Windows сканирование портов и обнаружение узлов в сети — это тесты группы «Port scanners», которые можно включить или выключить. Результаты работы сканера представляются пользователю в виде отчета, который можно экспортировать в документы формата PDF, HTML или в тек- стовые файлы. Пример окна Internet Explorer с фрагментом отчета о сканиро- вании показан на рис. 8.15. В качестве сканируемого узла использовалась ра- бочая станция с установленной операционной системой Windows 2000 Profes- sional Service Pack 4. Рис. 8.14. Диалоговое окно Nessus в процессе сканирования Рассмотрим, как следует интерпретировать результаты сканирования. Для каждого узла в отчете присутствует запись с обобщенными результатами сканирования (рис. 8.16), в которой приведено количество открытых портов (8 Open Ports), примечаний с дополнительной информацией (27 Notes), преду- преждений (2 Warnings) и серьезных уязвимостей (10 Holes). 229 Для каждой обнаруженной уязвимости и для каждого успешного теста в отчете присутствует запись со следующими элементами (рис. 8.17): «Synopsis» — краткий обзор уязвимости, «Description» — ее описание, «Solu- tion» — ссылка на web-страницу с детальным описанием уязвимости и мер, которые необходимо предпринять для ее устранения, «Risk Factor» — инфор- мация о степени опасности данной уязвимости и ссылки на эту уязвимость в различных базах данных уязвимостей. Фактор риска вычисляется в соответствии со стандартом CVSS (Com- mon Vulnerability Scoping System) и представляет собой числовую величину от 0 до 10, где 10 – максимальный уровень опасности, соответствующий крити- ческой уязвимости. CVSS – открытый стандарт для подсчета «базового уров- ня», который количественно представляет величину угрозы от уязвимости. «Базовый уровень» не учитывает количество инцидентов и потерь, связанных с уязвимостью. Этот стандарт также предусматривает возможность подсчета таких уровней, как «временный уровень» (связан со степенью известности и количеством использования уязвимости) и «уровень, зависящий от окруже- ния» (вычисляется на базе информации о системе, на которой находится уяз- вимость). Рис. 8.15. Фрагмент отчета о сканировании Рис. 8.16. Пример обобщенных результатов сканирования 230 Рис. 8.17. Пример описания уязвимости Расчет «базового уровня» выполняется по следующей формуле: BS = 10 * AV* AC* Au * ((C1 * C2) + (I1 * I2) + (A1 * A2)), где результат округляется до ближайшего целого числа; BS (Base Score) – величина «базового уровня»; AV (Access Vector – вектор доступа): 0,7 — в случае необходимости локально- го доступа для использования уязвимости; 1 — в случае возможности удален- ного использования уязвимости; AC (Access Complexity — сложность доступа и реализации атаки): 0,8 — вы- сокая, 1 — низкая; Au (Authentication — аутентификация): 0,6 — требуется, 1 — не требуется; С1 (Confidentiality Impact – влияние на конфиденциальность): 0 — отсутству- ет, 0,7 — частично присутствует, 1 — полностью может нарушить конфиден- циальность; I1 (Integrity Impact — влияние на целостность): 0 — отсутствует, 0,7 — час- тично присутствует, 1 — полностью может нарушить целостность; A1 (Availability Impact — влияние на доступность): 0 — отсутствует, 0,7 — частично присутствует, 1 — полностью может нарушить доступность; C2, I2, A2 — коэффициенты воздействия угрозы (Impact Bias) на конфиденци- альность, целостность и доступность. Коэффициенты могут принимать значе- 231 ния: (1/3;1/3;1/3) — уязвимость в равной степени распространяется на все свойства; (0,5; 0,25; 0,25) — уязвимость в большей степени затрагивает кон- фиденциальность; (0,25; 0,5; 0,25) – уязвимость в большей степени затрагива- ет целостность; (0,25; 0,25; 0,5) — уязвимость в большей степени затрагивает доступность. Коэффициенты воздействия угрозы дают возможность назначения при- оритетов того или иного свойства информационной системы с точки зрения выполняемых системой функций. Например, если уязвимость в шифрующей файловой системе в равной степени затрагивает (полностью нарушает) и кон- фиденциальность, и доступность данных, то конфиденциальности должен быть отдан приоритет. Проведем расчет «базового уровня» на примере найденной уязвимости: BS = 10*1*1*1*(1*1/3+1*1/3+1*1/3) = 10. Данный расчет соответствует стро- ке в описании уязвимости: AV:R/AC:L/Au:NR/C:C/A:C/I:C/B:N. Таблица 8.3 Образец оформления перечня найденных уязвимостей IP-адрес: 192.168.10.1 Порт: 445/tcp Степень опасности: критическая Идентификация уязвимости: CVE: CVE-2003-0715, CVE-2003-0528, CVE-2003-0605 BID: 8458, 8460 IAVA: 2003-A-0012 Краткий обзор: Существует возможность удаленного выполнения произвольного программ- ного кода на данном сетевом узле Описание: На узле установлена операционная система Windows, имеющая уязвимость в реализации одного из программных модулей. При наличии доступа зло- умышленника к данному узлу по сети существует возможность запуска на нем произвольного программного кода с максимальными полномочиями (полный контроль над узлом) Меры по устранению: Требуется перенастройка операционной системы и/или установка обновле- ний безопасности. Подробная информация может быть получена с официального web-сайта Mi- crosoft: http://www.microsoft.com/technet/security/bulletin/MS03-039.msps. Строка с заголовком CVE содержит номер уязвимости в базе данных CVE (Common Vulnerabilities and Exposures — общеизвестные уязвимости и воздействия). CVE представляет собой тезаурус известных уязвимостей, дос- 232 туп к которому может быть получен по адресу «http://cve.mitre.org». CVE представляет собой не базу уязвимостей, а способ их именования. Например, для уязвимости с именем «CVE-2005-1206» элемент «CVE» указывает на то, что уязвимость уже получила имя «CVE», иначе использовался бы элемент «CAN» — кандидат на имя, 2005 — год, в котором произошло утверждение. Информацию об уязвимости можно найти, используя имя CVE. Уязвимости из примера будет соответствовать ссылка «http://cve.mitre.org/cgi- bin/cvename.cgi?name=CVE-2005-1206». BID (Bugtraq ID) — номер уязвимости в базе данных BugTraq (адрес в сети Интернет: «http://www.securityfocus.com»). Раздел «Other references» со- держит ссылки на другие базы данных, в которых зарегистрирована данная уязвимость, например IAVA (Information Assurance Vulnerability Alert) — ме- тод идентификации уязвимостей, используемый Министерством обороны США. В последней строке (Plugin ID) содержится уникальный номер подклю- чаемого модуля Nessus, который использовался при тестировании данной уяз- вимости. В качестве практического задания предлагается протестировать наличие уязвимостей на узлах исследуемой подсети, обнаруженных на предыдущем этапе проведения аудита. Для получения представления о том, какая инфор- мация циркулирует в сети в процессе сканирования, используется анализатор сетевого трафика Ethereal. Факт сканирования предлагается обнаружить при помощи системы обнаружения атак Snort. По результатам сканирования необ- ходимо заполнить отчет по образцу, приведенному в табл. 8.3. ВЫПОЛНИТЬ! 9. Установить на локальном компьютере IP-адрес таким образом, чтобы он оказался внутри исследуемой подсети (192.168.10.0/24). Можно выбрать любой свободный IP-адрес. 10. Запустить серверную часть (службу) Nessus при помощи оснастки «Служ- бы» (Пуск ⇒ Настройка ⇒ Администрирование ⇒ Службы). Запустить клиентскую часть Nessus. 11. Очистить log-файлы СОА Snort (удалить содержимое каталога «\snort\log»). Запустить СОА Snort с полным набором правил (из команд- ной строки каталога snort\bin): snort -i <интерфейс> -c ../etc/snort.conf -l ../log, где <интерфейс> — номер интерфейса сетевой платы, полученный при помощи команды: snort –W. 12. Записать в адресную книгу Nessus IP-адреса узлов сканируемой подсети, которые были обнаружены на предыдущем этапе. 13. Запустить анализатор трафика Ethereal. Включить захват трафика на сете- вом интерфейсе, находящемся в одном сегменте со сканируемым узлом. 233 14. Запустить сканирование узла обнаруженной ранее рабочей станции, ис- пользуя все тесты за исключением «опасных». Для этого указать пункт «Enable all but dangerous plugins with default settings» в диалоговом окне выбора тестов. 15. Дождаться завершения тестов, выключить захват трафика, прервать рабо- ту СОА Snort ( 16. Проанализировать результаты отчета, ответить на следующие вопросы: a. Какие порты открыты на рабочей станции? b. Какие критические уязвимости обнаружены? Что может стать резуль- татом их использования? c. Какие конкретные действия следует предпринять для устранения об- наруженных уязвимостей? d. Каким образом факт сканирования отражается в файле журнала СОА Snort (\snort\log\alert.ids)? e. Сколько пакетов было передано по сети в ходе процедуры сканирова- ния? Каков суммарный объем переданной информации? 17. Заполнить отчет о результатах сканирования (образец см. в табл. 8.3). 18. Запустить сканирование узла обнаруженного ранее сервера, используя все тесты за исключением «опасных». 19. Проанализировать результаты теста и заполнить табл. 8.3 по результатам сканирования сервера со стороны внутренней сети. 20. Установить на локальном компьютере IP-адрес таким образом, чтобы он оказался во внешней по отношению к исследуемому компьютеру сети (192.168.200.0/24). Можно выбрать любой свободный IP-адрес. 21. Запустить сканирование сервера, используя все тесты за исключением «опасных». 22. Заполнить отчет о результатах сканирования сервера со стороны внешней сети (образец см. в табл. 8.3). Сравнить результаты с полученными ранее в пункте 19. 23. Провести расчет величины «базового уровня» угрозы для любой критиче- ской уязвимости. 8.9. Анализ защищенности web-серверов Как уже было замечено, аудитор может проводить инструментальные проверки, охватывающие различные элементы ПИБ. Для примера того, как могут проходить такие проверки, рассмотрим возможный набор средств и ме- тодов проведения инструментальной проверки подсистемы защиты web- сервера. Как известно, web-сервер представляет собой клиент-серверное прило- жение, использующее для передачи данных протокол HTTP и стандартный порт 80/tcp. web-сервер ожидает HTTP-запрос от клиента. При получении HTTP-запроса web-сервер отвечает HTTP-ответом, который может содержать 234 HTML-, XML-документ либо иной тип данных (изображение, текстовый до- кумент, мультимедийный файл и др.). Если HTTP-запрос от клиента не может быть обработан (ошибка в запросе или неосуществимый запрос), то web- сервер должен послать ответ, содержащий код и описание ошибки. Поскольку протокол HTTP является протоколом уровня приложений, использующим текстовые команды, посмотреть передаваемые web-сервером данные можно с использованием утилиты NetCat (nc). В примере ниже осуще- ствляется стандартное TCP-подключение с использованием этой утилиты с перенаправлением потока вводимых с клавиатуры данных на сервер: nc <имя или адрес узла> <номер порта>. nc 192.168.10.3 80 GET / HTTP/1.0 Серверу передается команда GET, запраши- вающая корневой документ сервера, с указани- ем версии HTTP 1.0. После ввода этой коман- ды необходимо дважды нажать Enter. HTTP/1.0 200 OK Сервер отвечает кодом 200, означающим, что запрос клиента обработан успешно и ответ сервера содержит затребованные данные. Server: Apache/1.3.37 (Unix) PHP/4.4.4 Строка идентифицирует имя и версию web- сервера. Date: Wed, 29 Nov 2006 18:19:11 GMT Текущее время и дата системных часов серве- ра. Last-Modified: Sun, 15 Jun 2003 17:34:53 GMT Время последней модификации передаваемого документа. Content-Type: text/html Тип передаваемых данных (HTML). Content-Length: 620 Длина передаваемых данных. |