Стр. 1 от 8

ТЕСТВАНЕ ЗА УЯЗВИМОСТИ В КОМПЮТЪРНИТЕ

МРЕЖИ (NETWORK VULNERABILITY ASSESSMENT)

Или някои полезни похвати и безплатни инструменти, които вътрешният одитор

може да използва при тестване сигурността на компютърните мрежи.

Николай Димитров, CIA, CCSA

Старши одитор Дирекция „Вътрешен одит"

Петрол Холдинг АД

Пътят на самурая. Според целта, самураят изработва различни оръжия,

овладявайки добре особеностите и начина на използването им. В това е

същността на Пътя на самурая. Ако не успее да овладее използването на

оръжията и не разбере ползата от всяко от тях, не е ли това повърхностност в

уменията на един самурай?

Миямото Мусаши, Ръкопис на Петте пръстена

Хакерът Гордън Лайън (Gordon Lyon, aka “Fyodor”) със сигурност е останал ококорен,

когато е гледал "Матрицата: Презареждане". Авторът на Nmap1, заедно с много други хакери

и специалисти по информационна сигурност, едва ли е очаквал да види някога във филм

реалистично пресъздадено пробиване на компютърна система. За пръв път в историята на

киното това е показано не чрез някаква идиотска триизмерна анимация (справка, "Хакери" от

1995 година или "Парола: Риба-меч" от 2001 година) или чрез абсурдни изпълнения (как се

разбива комплексна парола за достъп до правителствена база данни за 60 секунди, пък било

то и с опрян в главата пистолет?! - "Парола: Риба-меч"), а чрез използването на (почти)

реални инструменти и техники.

Да си припомним набързо - във втората

"Матрица" Тринити" брутално хаква системата за

управление на градската електроцентрала.

Брутално в преносен и в буквален смисъл. След

като натръшква половин дузина охранители тя

пробива системата, изключва възлите в мрежата и

оставя половината град без ток. Как става това ли

(да оставим кунг-фу техниките настрани :))? След

сканиране с Nmap на вътрешната мрежа Тринити

намира IР адреса на управляващия хост и открива, че неговия 22-ри порт е отворен. На този

порт стандартно "слуша" SSH (Secure SHel)2 сървър, който се използва за отдалечено

управление. След това стартира несъществуващият в реалния свят експлойт3 sshnuke, който

1 Популярен мощен мултиплатформен скенер на комуникационни портове и идентификатор на операционни

системи. 2 Клиент-сървър приложение, използващо едноименния протокол за автентикиране на отдалечен компютър и

изграждане на сигурна криптирана комуникационна връзка между него и локалния компютър. 3 Приложение, определено количество данни или последователност от команди, които се възползват от

известна грешка или уязвимост за да атакуват дадена компютърна система и да получат контрол върху нея.

Стр. 2 от 8

се възползва от документирана уязвимост в SSH4, за да получи пълен (root) достъп до

управляващия хост и воала! За по-любопитните шел транскриптът на целия процес може да

бъде видян във видео файла http://images.insecure.org/nmap/images/matrix/matrix- hack.mov

(6,5 МБ).

Тези няколко секунди екранно присъствие добавиха още популярност към и без това

известния Nmap, но за него ще говорим малко по-късно. Първо да видим накратко какво

представляват уязвимостите и тестването за тях в компютърните мрежи и доколко

използваните при него техники и open source инструменти могат да бъдат полезни при

извършването на ИТ одит.

Какво е уязвимост?

Проблем или грешка в дадена система, която може да бъде злонамерено използвана за

атака срещу системата, получаване на неоторизиран достъп и нарушаване на

интегритета, поверителността и достъпността на обработваната или съхранявана от

нея информация или на приложенията, които тя поддържа.

Уязвимостите имат жизнен цикъл,

обхващащ следните четири фази (виж

графиката):

Откриване - някой потребител се натъква

на слабост в приложение или система и я

публикува в уеб сайт за обсъждане и

потвърждение.

Оповестяване - Съобщение за

новооткритата уязвимост се появява в

някой от специализираните уеб сайтове

(www.cert.org, www.securityfocus.com,

secunia.com и др.).

Популяризиране - Уязвимостта бързо

става известна на широк кръг хора и се появяват първите експлойти.

Издаване на "пач" за нея - Производителят на съответното приложение, система или

устройство пуска актуализация, която отстранява уязвимостта и следва да предотврати

възможността за външна атака чрез нея.

Има два вида уязвимости: твърди и меки. За твърди уязвимости говорим, когато имаме

грешки в програмния код на дадено приложение, които отварят дупки за потенциален

експлойт. Известни са като "бъг"-ове и се отстраняват чрез прилагането на пуснати за целта

актуализации ("пач"-ове) или сервизни пакети. Вероятността да съществуват бъгове в

дадено приложение обикновено е правопропорционална на неговата сложност. За меките

уязвимости не можем да виним производителите - те са свързани с неправилно

конфигурирани от администраторите приложения или устройства от гледна точка на

сигурността. Някои от причините за това могат да са:

В организацията липсват политики и стандарти за сигурност или ако такива

съществуват, то не следват най-добрите практики в областта;

4 SSH CRC-32 Compensation Attack Detector Vulnerability (http://www.securityfocus.com/bid/2347)

Стр. 3 от 8

Липсват практики за управление на конфигурациите и промените в приложенията и

устройствата;

Неактивирани механизми за документиране на събития и липса на практика за

мониторинг, анализ и съхранение на лог-файловете от приложенията и устройствата;

Неподходяща квалификация на администраторите като резултат от слабо познаване на

поддържаните от тях системи и липсата на обучение и професионално развитие.

Какво е тестване за уязвимости в компютърните мрежи?

Процес на оценка на съществуващите политики, бизнес практики, компютърни мрежи и

устройства, приложения, персонал и програми за професионално развитие за да се определи

съществуват ли слабости в компютърните системи и мрежи или пропуски при начините за

тяхното конфигуриране и използване. Експлоатирането на подобни уязвимости би

застрашило интегритета, поверителността и достъпността на информацията и

инфраструктурата на организацията.

Какви познания са необходими за извършването на тестове за уязвимости?

Тестването за уязвимости рядко се прави от един човек. Причината е проста - трудно може

да се намери специалист по сигурност или одитор, който да притежава достатъчно

задълбочени познания едновременно за корпоративното управление, принципите и

стандартите за управление на риска и дизайн на контролни механизми, одит техниките,

управлението на проекти, мрежовите архитектури, протоколи и устройства, операционните

системи, уеб сървърите, базите данни и др. Затова е честа практика подобни тестове да се

извършват от екип от специалисти, всеки от които е експерт в някоя от изброените области

(да, точно така - звучи като спазване на стандарта "1210 - Компетентност" на Института на

Вътрешните Одитори). Самото тестване обикновено се води като проект с определена рамка,

методология, продължителност, необходими ресурси и очакван резултат. Затова и един от

ключовите фактори за неговия успех е умението да се управляват проекти, което често

липсва в по- технически ориентираните специалисти.

Следваната методология

при извършването на тестовете за уязвимости обхваща два подхода5: "отгоре-надолу "

(организационен) и "отдолу-нагоре" (технически).

При първия подход усилията се концентрират върху определяне до каква степен политиките

и процедурите в организацията изграждат и поддържат сигурна среда и условия за работа.

Оценката доколко организационната рамка е адекватно изградена, разбрана и

последователно прилагана помага да се идентифицират повечето от уязвимостите от "мек"

характер (липсващи или неадекватни политики, неизпълнявани дейности по администриране

и т.н.) и служи за основа на тестовете "отдолу-нагоре". При тях обект на оценка вече са

самите компютърни мрежи и системи от гледна точка на проектиране, изграждане,

конфигуриране, използване и наблюдение. Като референтен модел при оценката за

адекватност на мерките за сигурност тук специалистите използват два източника на

информация: (1) резултатите от тестовете "отгоре-надолу" и (2) общоприетите практики за

сигурност, приложими за тестваните компоненти от мрежата на организацията (например

препоръките за сигурно проектиране на мрежи и конфигуриране на устройства на Cisco

Systems, Inc.).

5 'Managing a Network Vulnerability Assessment' by Thomas R. Peltier, Justin Peltier and John A.

Blackley, ISBN:0849312701, Auerbach Publications © 2003, Chapter 4.

Стр. 4 от 8

Приемам, че всички знаем как се прави организационен преглед и затова няма да се спирам

на него (а и ровенето из политики и процедури си е досадна работа, знам :)). Затова да видим

кое му е интересното на

Техническия подход.

При него се следват последователно шест стъпки:

Проучване и събиране на информация за тествания обект.

Изготвяне на план за тестване и определяне на обхвата (кое ще тестваме?).

Избиране на инструменти за тестване (с какво ще тестваме?).

Тестване на мрежите и системите за уязвимости (как ще тестваме).

Анализ и потвърждаване коректността на резултатите.

Документиране на извършената работа.

Дотук нищо, което съществено да се различава от типичен одит на ИТ инфраструктурата.

След първоначалното събиране на информация за мрежите и системите на клиента (IP

адресен план, топологична карта на мрежата, инвентарен списък с устройствата в мрежата и

др.) екипът пристъпва към изготвянето на план за тестове и формулиране на техния обхват.

Самият обхват силно зависи от инфраструктурата на клиента, оценката на риска (ако е

извършен организационен преглед преди това) и конкретните притеснения и очаквания на

спонсора на проекта. За разлика от тестовете за пробив на системите (penetration testing) при

тестването за уязвимости е силно намален рискът от сриване или влошаване

производителността на системите на клиента, макар такъв все пак съществува - някои от

тестовете са свързани с генерирането на сериозен трафик през мрежата и ангажирането на

сериозни изчислителни ресурси на сървъри при изпълнение на по-обемни запитвания. Този

риск също трябва да бъде отчетен при определянето на обхвата, тъй като има значение кои

инструменти за тестване ще бъдат избрани, как ще бъдат конфигурирани и срещу кои

системи и хост машини ще бъдат използвани.

Така стигаме и до интересната част - инструментите. Третата и четвърта стъпка от подхода

са тясно свързани и ще бъдат паралелно разгледани в следващите редове. Добре е да се има

предвид, че по-важно е добре да се знаят техниките за тестване (кое?, защо? и как?), а не

инструментите (с какво?). Инструментите се сменят - някои остаряват и стават частично

неприложими, други престават да бъдат поддържани от производителите им, като в същото

време се появяват все нови и нови инструменти. По-надолу в текста съм изброил само малка

част от популярните сред специалистите по сигурност безплатни инструменти, имащи

версии за повече от една операционна система и, по възможност, с удобен графичен

интерфейс за бързо и интуитивно боравене с тях. Повечето инструменти изискват локални

администраторски права за да работят коректно и валидни потребителски профили в

тестваните домейни. Съвсем разбираемо, най-пълни резултати се получават, ако

инструментите се ползват с права на домейн или ентърпрайз администратори.

Стр. 5 от 8

На съседната графика е

показана последователността

от действия при четвъртата

стъпка - тестването за

уязвимости. Отгоре е началото

на тестовете, където е

най-голям потенциалния брой

на сканираните хост машини.

На този етап събираме

информация за обекта на

тестове с помощта на т.нар.

Zero-Information-Based (ZIB) инструменти. Такива са

интернет браузърите за

преглед на публично достъпна

в интернет информация за

организацията-клиент -

официалният й сайт, данни за

регистрацията на фирмения

домейн във www.register.bg6

,

показващи IР адреса на уеб сървъра и "сървърите за имена", допълнителна 'whois'

информация във www.ripe.net за регистрирани IР адреси и блокове на името на

организацията.

Полезен инструмент е и SamSpade7, предлагащ удобен 'point-and-click' достъп до някои от

често използваните мрежови техники за "разузнаване". Всяка от тях може да бъде изпълнена

с определена команда от конзола в Linux/Windows среда:

DNS lookup - чрез 'nslookup' командата се показва съответствие между IР адреси и

наименования на хост машини в даден домейн; освен това по DNS записите за

ресурсите може да се ориентирате за функцията, която изпълнява даден хост

(например, ако има запис 'MX' за машина с име smtp.<име-на-домейн>.bg, то

най-вероятно това е мейл сървър, както и smtp префикса подсказва).

Whois - показва регистрационна информация за даден домейн, намираща се на сървъра

на регистриращия орган. Полезно е поне за две неща: 1) разбирате кои са

административните лица, отговарящи за домейна (телефони, e-mail-и, адреси), която

може да използвате за социален инженеринг по-късно и 2) разбирате кои са name

сървърите, обслужващи домейна. Последното е важно, ако искате да проверите дали е

възможен "зонов трансфер".

Zone Transfer - DNS сървърите периодично обменят информация помежду си за да

поддържат актуални своите бази данни. Зоновият трансфер е отговор на DNS запитване

към сървъра за извеждане на всички записи, които той има за даден домейн - сървъри за

имена, наименования на хост машини, записи за тяхната функция в мрежата и т.н.. В

неподходящи ръце това е, кажи-речи, списък с възможни мишени за атака. Повечето

администратори забраняват зоновия трансфер между DNS сървъра и "външна" за

мрежата машина, но го оставят възможен между сървъра и "вътрешна" (доверена)

машина. Добрите практики препоръчват зонов трансфер да се позволява единствено

между сървърите, за които това е изрично необходимо.

6 Регистър.БГ ООД е новосъздадено дружество чрез отделяне от "Цифрови Системи" ООД през 2001г. с

основен предмет на дейност регистриране и поддържане на имена в подобластта BG. 7 http ://www.samspade.org/ssw/

Стр. 6 от 8

Dig - Алтернатива на зоновия трансфер по отношение на извличаната от DNS сървъра

информация. С нейна помощ може да потвърдите коректността на диаграмите на

мрежовата топология и IP адресния план на организацията.

Traceroute - показва устройствата, през които IP пакетите минават за да стигнат до

указаната машина. Това е един от лесните начини да се открие граничният

маршрутизатор (понякога също и шлюза и/или опорната защитна стена) в тестваната

мрежа.

Инструментите за Откриване на мрежови устройства ще ви помогнат да разберете

какъв е обхватът на мрежата, колко подмрежи има и зад кои IP адреси, разкрити в

предходната стъпка, към момента на теста ви има работещи устройства (маршрутизатори,

защитни стени и др.). Така ще получите по-ясна представа за евентуалната структура на

мрежата и ще може допълнително да ограничите обхвата на сканираните устройства при

последващите тестове. В помощ могат да ви бъдат SNScan8 (за откриване на SNMP

9

управляеми устройства от Windows работна станция) и ICMPEnum10

(за разкриване на

устройства посредством ICMP Echo, ICMP Timestamp и ICMP Information пакети от

Unix/Linux машини). За SNMP сканирането ще ви е необходимо да знаете community

стринговете (еквивалент на пароли) за 'read-only' достъп до конфигурационна информация

на мрежовите устройства (по подразбиране е 'public') - тях може да получите от мрежовите

администратори. За разкриване на включените в мрежата устройства могат да се използват и

Nmap11

и SuperScan12

.

Това са популярни скенери на комуникационни портове, които добре се справят и с

Разпознаването на операционни системи (ОС) и Разпознаването на приложения. За

целта скенерите използват IP пакети (TCP, UDP или ICMP) за да определят:

достъпността на определени хост машини;

с каква операционна система са те;

кои техни портове са отворени, филтрирани (напр. от хост базирани защитни стени)

или затворени;

името и версията на приложенията, използващи отворените портове.

Споменатият в началото Nmap съвсем оправдано е считан от специалистите за най-добрият

портов скенер на пазара и е достъпен както за Unix/Linux системи, така и за Windows. Мощта

му се крие в разнообразието от техники за сканиране и в иновативния начин за определянето

на приложенията, използващи дадени портове. Например, Nmap не приема, че щом 80-и

порт е отворен, то значи на хост машината има инсталиран и пуснат уеб сървър (честа

практика е да се променят стандартните портове на приложенията като допълнителна мярка

за сигурност). Скенерът извършва 'banner grabbing & matching' - сравнява получените

отговори със стандартни отговори в своята база данни nmap-service- probes за да определи по

съвпаденията вида и версията на "слушащите" на съответните портове услуги (services). Чрез

получените отговори от отворените портове може да се определи с приблизителна точност и

с каква ОС е сканираната машина. Например, порт 445 се използва от директорийната услуга

на Майкрософт13

, която след Windows NT замести NetBIOS триото от портове 137, 138 и 139

при предоставяне на услуги като споделянето на файлове (file sharing). Ако порт 445 е

8 http://www.foundstone.com/resources/proddesc/snscan.htm

9 Simple Network Management Protocol (SNMP) - популярен TCP/IP протокол за отдалечено наблюдение и

управляване на мрежови устройства. Използва принципа на "запитване - отговор" за обмен на

информация между управляващият (мениджър) и управляваният (агент) хост. 10

http://www.bindview.com/Services/RAZOR/Utilities/Unix Linux/icmpenum readme.cfm 11

http ://insecure.org/nmap/ 12

http://www.foundstone.com/resources/proddesc/superscan4.htm 13

http ://www. iana. org/assignments/port-numbers

Стр. 7 от 8

отворен и на него Nmap разпознае 'microsoft-ds' услугата е почти сигурно, че става дума за

Windows ОС. Има и изключения - т.нар. 'false positives', но за тях след малко.

Определянето на вида и версиите на ОС и приложенията е ключов момент при тестването за

уязвимости. С негова помощ можете да определите кои от съществуващите уязвимости са

приложими към тях и какъв е рискът за тестваните системи. Сещате се, че би ви отнело доста

време, ако решите да правите това "на ръка". Тук на сцената се появяват инструментите за

Сканиране на уязвимости, като Nessus14

(най-известният скенер за уязвимости), Microsoft

Baseline Security Analyzer15

(за откриване на машини, на които не са приложени

актуализации и сервизни пакети на продуктите на Microsoft, както и слабости в

конфигурацията на ОС) или Nikto16

(скенер за уязвимости в уеб приложения). Те поемат

тежката задача да отговорят до голяма степен на въпроса "Какви слабости съществуват в

нашите системи?". За тази цел, например, разработчиците на Nessus и подкрепящата го

общност следят известните хранилища за уязвимости17

и периодично пускат плъгини за

тестване на новооткрити слабости. Към момента Nessus разполага с над 11 хиляди такива

помощни скрипта. Важно е те да бъдат актуализирани преди началото на тестовете, за да се

обезпечи коректността на резултатите.

Откриването на уязвимости става чрез

понякога продължителен процес на

сканиране на хост машини, донякъде

повтаряйки извършената работа на

предходните етапи. След това скенерът

съпоставя получената информация за

разкритите приложения с данните, които има

за съществуващите уязвимости. В доста от

случаите следваният и тук подход 'banner

grabbing & matching' не дава вярна

информация за наличието на уязвимости.

Често пъти производителите на приложения

отстраняват с пач даден бъг в свой продукт,

но забравят да актуализират версията в

неговия банер (идентифициращ стринг) и

скенерът невярно отчита наличие на по-стара

и уязвима версия. В такива случаи говорим за

'False positives' (неверен резултат от

тестване) – малък кошмар за всеки

специалист по сигурност.

Тук тестовите скриптове некоректно отчитат,

че са открили това, което са търсили. Тази

слабост е присъща на всички откриващи

алгоритми, като в контекста на уязвимостите

причина за нея могат да бъдат:

Грешки в тестовите скриптове;

Неактуализирани идентифициращи банери на услугите/приложенията;

14

http ://www. nessus.org/about/ 15

http ://www. microsoft. com/technet/security/tools/mbsa2/default.mspx 16

http://www.cirt.net/code/nikto.shtml 17

http://www.kb.cert.org/vuls/, http://www.securityfocus.com/vulnerabilities

Топ 20 уязвими области според SANS Institute18

Услуги на Windows

Internet Explorer

Библиотеки на Windows

Microsoft Office и Outlook Express

Слабости в конфигурацията на Windows

Софтуер за бекъп

Антивирусен софтуер

РНР-базирани приложения

Софтуер за бази данни

Приложения за споделяне на файлове

DNS софтуер

Медиа плеъри

Приложения за съобщения в реално време

Браузърите Mozilla и Firefox

Други междуплатформени приложения

Слабости в конфигурирането на Unix

Слабости в MacOS X

IOS и не-IOS продукти на Cisco

Продукти на Juniper, Checkpoint и Symantec

Слабости в конфигурирането на Cisco устройства

Стр. 8 от 8

Проверката е коректна в резултат на нестандартно поведение на тестваните услуги -

например, тестов скрипт се логва в FTP сървър и изпраща стринг, който предизвиква

препълване на буфера. След това изпраща HELP запитване и чака за отговор. Ако и на

второто запитване не получи отговор от FTP сървъра скриптът приема, че е сринат и

го отчита като уязвим. Ами ако сървърът само временно не отговаря за периода

между двете запитвания?

Проверката е коректна, но рискът е несъществен - какво ви интересува, че уеб

сървърът на дадена машина е уязвим, ако тази машина не е включена в мрежата ви и

на нея работи някакво не особено важно локално ползвано приложение?

Проверката е коректна, но резултатът е нерелевантен - ако можете да извършвате

зонов трансфер от Интернет е критична уязвимост, но ако можете да го направите

"отвътре" сигурно е оправдано за конкретната мрежа. В случая скенерът няма как да

знае от къде е пуснат ;).

Начин за справяне с 'false positives' е "ръчна" проверка и анализ и потвърждаване

коректността на резултатите (пета стъпка от техническия подход), за да се елиминират тези

от тях, които не отговарят на действителността. На практика това се прави след края на

сканирането, когато вече разполагаме с данните от извършените тестове. Тогава могат да се

използват и последните четири типа инструменти - специалните инструменти (за разбиване

на пароли, например Cain & Abel18

), инструментите за тестване или документиране на

конкретни приложения (като Ecora AuditorLite for Oracle19

), на отделни хост машини (за

сканиране и премахване на 'rootkits', троянски коне и друг зловреден код) и други

инструменти (мрежови снифъри и анализатори на мрежови протоколи, като Wireshark20

(бивш Ethereal) или OmniPeek21

) - в зависимост от откритите уязвимости и необходимостта

от по-детайлното им изследване. На последната, шеста стъпка, тестовите процедури и

резултатите от тях надлежно се документират и се пристъпва към изготвяне на доклад за

извършената работа. Неговата форма и съдържание трябва да спомогнат да се представи на

разбираем език оценката за степента на уязвимост на тестваните мрежи и системи и нивото

на риск, пред което е изправена организацията. Това би улеснило спонсора на проекта и

съответните ръководители при взимането на ценово-ефективни решения за справяне с

рисковите уязвимости.

Разбира се, тези няколко страници съвсем не изчерпват темата за техниките за тестване за

уязвимости, нито пък възможните за използване инструменти. Тези от вас, които проявяват

интерес към тази материя могат да намерят допълнителна и полезна информация в някои от

следните интернет сайтове:

■ http://sectools.org/ - Top 100 Network Security Tools (класация на потребителите от

nmap-hackers мейлинг листа за най-добрите инструменти за сигурност през 2006-а

година).

■ http://www.securityfocus.com/tools - източник на всякаква информация, касаеща

компютърната сигурност и, в частност, използваните от специалистите по сигурност

инструменти.

■ http://www.vulnerabilityassessment.co.uk/index.htm - сайт, посветен на тестването за уяз-

вимости и пробиви на системи.

18

http ://www. oxid. it/cain.html 19

http://www.ecora.com/ecora/products/auditor lite.asp 20

http ://www. wireshark. org/about.html 21

http://www.omnipeek.com/omnipeek_personal.php