Анализ защищенности и мониторинг компьютерных сетей. Методы и средства : учебное пособие [Валерий Васильевич Бондарев] (pdf) читать онлайн

В.В. Бондарев

Анализ защищенности

...

и мониторинг компьютерных сетеи

Методы и средства
Учебное пособие

р)
Москва

ИЗДАТЕЛЬСТВО
МГТУ им. Н. Э. Баумана

2

О

17

УДК

ББК

681.326
32.973
Б81
Издание доступно в электронном виде на портале

по адресу:

ebooks.bmstu.m
http:j/ebooks.Ьmstu.ru/catalog/117/Ьооk1712.html

Факультет 1Информатика и системы управления~

Кафедра 1Информационная безопасность~

Рекомендовано Редакционно-издателъским советом
МПУ им. Н.Э. Баумана в качестве учебного пособия

Бондарев, В. В.
Б81

Анализ защищенности и мониторинг компьютерных сетей. Методы и

средства

: учебное

пособие

/ В. В. Бондарев. 2017. - 225, [3] с. : ил.
ISBN 978-5-7038-4757-2

Москва

: Издательство

МГТУ

им. Н. Э. Баумана,

Изложены теоретические вопросы, связанные с архитектурой и принципами

работы систем обнаружения и предотвращения атак в компьютерных сетях. При­
ведены методы, приемы и инструменты, применяемые при защите компьютерных

систем и сетей от атак. Содержание учебного пособия соответствует программе
и курсу лекций, читаемых автором в МПУ им. Н.Э. Баумана.

Для студентов, обучающихся по направлению подготовки (угроз). Конечной целью обеспе-

10

чения безопасности корпоративной сети является защита всех категорий
субъектов (как внешних, так и внутренних), прямо или косвенно участвую­
щих в процессах информационного взаимодействия, от нанесения им ощути­

мого материального, морального или иного ущерба в результате случайных
или преднамеренных нежелательных воздействий на информацию и системы

ее обработки и передачи.
Соответственно одним из возможных вариантов защиты можно считать

своевременное выявление слабостей (уязвимостей), которые могут привести

к реализации угроз и в результате

1.4.

-

нанесению ущерба.

Классификация уязвимостей

По мере накопления информации об уязвимостях возникали и различные
варианты их классификации. В настоящее время информация об обнаружен­

ных уязвимостях достаточно систематизирована, существует несколько обще­
известных источников, где эта информация представлена. Ниже приведены
примеры возможных вариантов (критериев) классификации уязвимостей.
Один из самых удачных вариантов классификации уязвимостей

-

по

источнику возникновения. Данный вариант классификации связан с этапа­
ми жизненного цикла системы и часто указывает на причину возникновения

той или иной уязвимости.

Уязвимости проектирования. Часть уязвимостей возникает на этапе
проектирования. Например, значительная часть прикладных сервисов стека
ТСР/

IP (TELNET, FTP

и др.) не предусматривает шифрования данных при

передаче по сети. В результате критичная информация (например, имя поль­
зователя и пароль) передается по сети в открытом виде (рис.

1.4).

Как правило, уязвимости, возникшие на этапе проектирования, с трудом

поддаются устранению. Например, в случае с сервисами прикладного уров­
ня для устранения уязвимостей можно либо отказаться от использования

...,..
..
Клиент
(утилита

То

T JI.Nlt

10. S02: 1 18127

ТС,

00I0707CJ4 Cf

J.1 . Z4 0 ISS1Z7
0010701СНСС T l i.NIT
11. 2:4 0 001071>?Cf 4C6 I SSl.2:7
T l t.rnt
1.1. . 4 0 4 'ISSlr?
0010707Cf4 CC те,

• rt.UU : • • •• fl"p r opon.io•
• ttHIP.111:ti IТ'rP I • О•о•оо : tir -..ocrol • I t :

.

telnet)

•

'1

r,:

10 • 0111Zl; , , ~.

1.4.

•

те,,

Cl:i.t.n~ V1U • on:. • 1030
1030

,..,.,,. , •roa ••n •

Т о C!:l.•n.t. Mtt.h
. А .... • len:
То

• • ~ • 1030
О~

....:

hrY, «уяз­

вимость~> и «атака~> . Опишите взаимосвязь между ними.

4.

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

основные достоинства и недостатки?

5. Назовите основные источники информации об уязвимостях. Какая из обще­
доступных баз данных об уязвимостях более предпочтительна?

Глава 2. МЕТОДЫ ВЫЯВЛЕНИЯ УЯЗВИМОСТЕЙ
И СИСТЕМЫ АНАЛИЗА ЗАЩИЩЕННОСТИ

2.1 .

Основные приемы выявления уязвимостей

Как отмечалось выше, причинами возникновения уязвимостей являются

ошибки проектирования, реализации и эксплуатации. Ниже приведены ме­
тоды выявления таких ошибок.
Анализ алгоритма программно-аппаратного обеспечения. Данный ме­
тод используется в основном для поиска уязвимостей проектирования. При­
мером практической реализации может служить система PVS (Prototype
Verification System), разработанная в Computers Science Laboratory института
SRI (http://pvs.csl.sri.com/ ).

На практике часто выполняется поиск ошибок реализации (кода), осу­
ществляемых с помощью следующих методов.

Динамический анализ безопасности приложения. Одним из наиболее
простых и распространенных при поиске уязвимостей реализации является

DAST (Dynamic Application Security Testing) -

динамический (т. е. требую­

щий выполнения) анализ безопасности приложения без доступа к исходному
коду и среде исполнения серверной части. Другими словами, анализ прило­
жения методом .

В этом контексте довольно часто используется термин

testing, fuzzing).

( fuzz

Данный метод предполагает изучение поведения ПО с по­

мощью подачи на вход различных значений переменных. Чаще всего это
граничные

или

маловероятные

значения,

которые

могут

создать

условия,

приводящие к переполнению буфера, выходу за границы массивов, записи

в недопустимые области памяти и т. д.

32

Имеется множество инструментов, позволяющих автоматизировать процесс поиска уязвимостей методом фаззинга, например:

• MiniFuzz (www.microsoft.com);
• FileFuzz (labs.idefense.com/software/ fuzzing.php ).
Элементы фаззинга присутствуют в популярном инструменте эксплуа­

тации уязвимостей

metasploit (рассматривается далее).

Механизмы фаззинга

в том или ином виде встроены в сетевые сканеры безопасности. Например,

в популярном сканере
приложений

XSpider имеется очень
(FTP, SMTP и т. д.) (рис. 2.1).

простой tracert 200.2.2 . 222 -d :

1.

На первом шаге посылается IСМР-запрос

(Echo)

со следующими па-

раметрами:

адрес отправителя
адрес получателя

- 200.0.0.161;
- 200.2.2.222;

TTL=1.
TTL = 1

200.0.0.161

Маршрутизатор

Исследуемый узел

(200.2.2.222)

58

2. Маршрутизатор уменьшает значение этого поля на 1 ( оно становится
равным О), что вызывает генерацию сообщения ICMP _ТIME_EXCEEDED.

Маршрутизатор

200.0.0.161

Исследуемый узел

(200.2.2.222)

TTL в отправляемых IСМР-пакетах последовательно нара­
щивается на 1, т. е. на данном шаге оно будет равно 2 и пакет пройдет через
маршрутизатор TTL=2
3.

Затем поле

TTL = 2
200.0.0.135 ~

~

200.2.2.254

Маршрутизатор

200.0.0.161

-

~.

Исследуемый узел

(200.2.2.222)

4.

Поскольку в данном случае пакет достиг требуемого узла, от него бу­

дет получен обычный IСМР-ответ (Echo-Reply).
Схема работы утилиты traceroute с использованием протокола
ведена на рис.

# traceroute edward

ТТL

UDP при­

6.1.
edward

=1
UDР-пакет (порт=

33434)

ICMP Time Exceeded
ТТL

=2

ICMP Time Exceeded
TTL = 3
ICMP Time Exceeded
ТТL

ICMP
Рис.

6.1.

Схема работы утилиты

=4

UnreachaЫe

Port

traceroute с использованием протокола UDP
59

В этом случае порт получателя растет с каждым последующим запросом
(начальное значение по умолчанию равно

33 434).

Поскольку попытка отслеживания маршрута к узлу может являться

предварительным действием перед атакой, большинство систем обнаруже­
ния атак могут обнаруживать такое событие. Обычно они реагируют на по­
явление в сети пакета

ICMP_TIME_EXCEEDED.

По содержимому пакета

можно определить цель атаки.

6.2.

Отслеживание маршрутов и фильтрация

Используя рассмотренные выше утилиты, можно проследить путь IР­

датаграммы до любого узла IР-сети. Задача отслеживания маршрутов ус­
ложняется, если на пути IР-датаграммы встречаются устройства, осущест­
вляющие фильтрацию трафика. Например, пакетный фильтр (рис.

6.2) может

иметь такую конфигурацию, что он блокирует весь трафик UDP, кроме тех
случаев, когда порт отправителя или получателя равен 53 (служба DNS).

Промежуточные устройства

Рис.

6.2.

Пакетный фильтр на МЭ

В этом случае правильным будет использование протокола

ICMP:

traceroute 200. О. О .110 - неправильно;
traceroute -I 200. О. О .110 - правильно.
Как быть, если в дополнение к этому фильтруются и пакеты

ICMP Echo?

В этом случае важно значение порта получателя в момент прохождения
UDР-датаграммы через пакетный фильтр. Значение порта получателя в лю­

бой момент зависит от следующих параметров:
• начальное значение порта получателя в момент начала работы утили­
ты traceroute start_ destination_port

•

число пакетов, посылаемых с одним и тем же значением

TTL (по умол­

чанию

3) num_of_probes
• число маршрутизаторов
цию num_ of_hopes

на пути до узла осуществляющего фильтра­

Таким образом, несложно вычислить начальное значение порта получа­
теля, требуемое для обхода фильтрации:

60

start_destination_ port = (53 - (num_ of_ hopes*num_ of_probes )) - 1
где

53 -

порт разрешенного протокола

DNS.

Однако следующий пакет будет иметь уже другое значение порта полу­
чателя и будет блокирован. Поэтому желательно, чтобы значение порта по­
лучателя было постоянным. Это может быть достигнуто установкой исправ­
ления к утилите

traceroute (к версии

1.4а5). Ее синтаксис после применения

исправления имеет вид

traceroute -S

-р53

6.3.

200 . О . О . 222
Утилита

traceproto

Делая вывод по применению утилиты

работает на сетевом уровне

(IP),

traceroute,

можно сказать, что она

однако в условиях фильтрации трафика

ее применение ограничено транспортным уровнем (тем, что разрешено из
вышележащих протоколов

ты

- UDP, ICMP, ТСР). Поэтому с помощью утили­
traceroute можно определить последний шлюз, от которого пришел ответ.

С точки зрения отслеживания маршрутов важным является значение поля

TTL из заголовка IP, но не более того.

Протоколы

UDP и ICMP лишь транс­

портируют данные, поэтому без ущерба могут быть заменены любым другим
протоколом транспортного уровня, в частности ТСР.

Эта идея реализована в утилите

net/ index.php).
Утилита traceproto

traceproto (http://traceproto.sourceforge.

аналогична утилите

traceroute,

но позволяет исполь-

зовать также и протокол ТСР для отслеживания маршрутов.
Синтаксис утилиты

traceproto:

traceproto [ - cCfhv]
[ -р
protocol ]
[ - d dst_ port]
[- D
max_dst_port ] [-s src_port ] [-S max_ src_ port] [-m min_ttl]
[ -М max_tt l ]
[-w response_ timout ] [-W send_ del ay ]
[-а
account_ level] [ - Р payl oad_ size] [-k ski ps ] [ - Н packets
per_hop] [ - i incr_ pattern] [-о output styl e]
Видно, что протокол выбирается с помощью опции -р (по умолчанию
ТСР) , порт получателя задается опцией - d (по умолчанию 80), разумеется,
можно задать и порт источника. О назначении остальных опций можно уз­
нать из руководства к утилите .

Контрольные вопросы

1.

Опишите прием «отслеживание маршрутов » при определении топологии

2.

В чем заключается специфика задачи отслеживания маршрутов при наличии

сети.

устройств , осуществляющих фильтрацию трафика?

3.

Каково назначение утилиты

traceproto?

61

Глава

7.

ИДЕНТИФИКАЦИЯ СТАТУСА ПОРТА

7 .1.

Сканирование портов

Взаимодействие узлов по протоколам ТСР и

UDP предполагает исполь­

зование портов для идентификации приложений. Следовательно, определив
номера открытых портов на удаленном узле, можно в дальнейшем узнать

о работающих на нем приложениях, сделать вывод о роли этого узла в кор­
поративной сети, узнать версию ОС. Определить состояние портов на уда­

ленном узле можно, например, последовательным перебором. Этот процесс

обычно называют сканированием портов (рис.

7.1).
о

65 535
Рис.

7.1.

Процесс сканирования портов

Фактически порт на удаленном узле может находиться в одном из двух
состояний: открыт, закрыт.

Но при удаленном подключении вследствие влияния межсетевых экра­

нов не всегда можно точно узнать статус порта. В этом случае обычно указы­
вается, что порт фильтруется (рис.

7.2).

Задачу идентификации статуса порта можно решать несколькими спосо­

бами. Рассмотрим некоторые из них.

_п_о_р_т_о_т_кр_ь_1т_ _ _ _ _ _~•-~

•

_п_о_р_т_з_а_кр_ь_1т_ _ _ _ _ _~..- ~

.

Порт фильтруется

'!!lo
:;..i!,.";:I

;!i;....'1=

--...-:::

Рис.

7.2.

Определение статуса порта при удаленном
подключении

62

~.

Сканирование портов ТСР

7 .2.

Сканирование с установлением соединения. Чтобы убедиться в том,
что порт ТСР открыт, достаточно попытаться установить с ним соединение.

Обычно для этой цели используются возможности ОС. В ОС реализация
ТСР, как правило, представляет собой отдельный драйвер, а интерфейс меж­
ду прикладным процессом и ТСР - набор системных вызовов, с помощью
которых можно

открыть

или закрыть

соединение,

отправить

или

принять

данные.

В частности, для установления ТСР-соединения может быть использован
интерфейс сокетов ( функция

connect() ). После установления соединения его

можно тут же разорвать штатной процедурой. Обмен пакетами в этом случае
представлен на рис.

7.3.

Сканирующий

Сканируемый

узел (А)

узел (В)
ТСР

ТСР

Flags=Syn

Flags=Syn+Ack

Соединение
установлено

ТСР Flags=Ack+Fin

Рис.

7 .3.

Использование интерфейса сокетов для установле­

ния ТСР-соединения

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

соединения

используют

терфейс, приведенный на рис.

7.4.

Для ускорения процесса сканирования
вместо штатной процедуры завершения со­

единения можно использовать его аварий­

ное завершение. В этом случае обмен паке­
тами имеет вид, представленный на рис.
SУN-сканирование.
установлением

7.5.

Сканирование

соединения

ТСР

имеет

Flags=Syn

ин­

с

ТСР

Flags-RST+Ack

Рис.

7 .4.

Использование интер­

фейса сокетов для установления
ТСР-соединения

при

закрытом

порте

следу-

ющие достоинства: позволяет использовать штатные возможности ОС и от­
личается высокой достоверностью.

К недостаткам этого метода обычно относят: недостаточную производи­
тельность и невозможность определения фильтрации порта.

63

Сканирующий
узел (А)

Сканируемый
узел (В)
ТСР
ТСР

Flags=Syn

Flags=Syn+Ack

Соединение
установлено

Рис.

7.5.

••

Аварийное завершение соединения

В отличие от сканирования с установлением соединения SУN-скани­
рование обладает несколько большей производительностью, посколькус те­
стируемым портом не устанавливается полноценное ТСР-соединение. Ска­

нирующий узел (А) отправляет SУN-пакет, как бы намереваясь установить
соединение, и ожидает ответа. Наличие флагов SYNIACK в ответе, пришед­
шем от узла В, указывает на то, что порт открыт, а флаги RSTjACK в ответе
означают обратное (рис. 7.6).
Сканирующий

Сканируемый

узел (А)

узел (В)
ТСР
ТСР

Flags=Syn

Flags=Ack+Syn

Рис.

7.6.

••

SУN-сканирование

Если же ответ не пришел (но при этом известно, что узел включен), это
означает, что порт фильтруется (рис.

7.7).

Сканирующий

Сканируемый

узел (А)

Рис.

ТСР

7.7.

узел (В)

Flags=Syn

SУN-сканирование при фильтрации порта

Разумеется, для проведения такого сканирования необходимо исполь­
зовать

механизм

генерации

сетевых

пакетов

и

анализа приходящих

тов. Этим можно объяснить тот факт, что после получения пакета

отве­

SYN!ACK

в ответ отправляется RSТ-пакет для сброса еще не установленного соедине­
ния (эту операцию выполняет ОС).

64

Фильтрация на прикладном уровне . Представленная выше методика
определения факта фильтрации ТСР-трафика работает при предположении,

что блокировка ТСР-пакетов осуществляется на основе критериев транс­
портного уровня, в данном случае это номер порта.

Однако в ряде случаев фильтрация работает на прикладном уровне, т. е.
после того, как ТСР-соединение будет установлено. Обмен пакетами в этом
случае представлен на рис.

7.8.

Сканирующий

Сканируемы й

узел (А)

узел (В)

ТСР

ТСР

Flags=Syn+Ack

ТСР

Flags=Ack+Fin

Flags=Syn

Соединение
установлено

ТСР

Рис.

7 .8.

Flags=Ack+Fin

Обмен пакетами при фильтрации на прикладном уровне

Таким образом, приложение разрешает установление соединения ТСР, но
тут же завершает его штатной операцией. В некоторых приложениях имеется

встроенный функционал, ограничивающий сетевое взаимодействии с ними
путем задания перечня «разрешенных>> IР-адресов. В качестве примера мож­

но привести

Microsoft IIS, настройки

которого позволяют разграничить до­

ступ к нему на основе IР-адресов (рис.

General Access

7.9).

IMessages l Delivery I LDAP Routing I Security J

Access control

l
l

l::onnection

1

Select whrch computers may access this virtual server.

1

Qnly the 11st below

!О AII e]:;cept the list below

!;;omputers:
Access

IP Address Mask / Domain Name

iJ Denied

17216 8.0 (255 255.255.0)

Рис.

7.9.

Фильтр IР-адресов

Microsoft 11S

65

'l+'

System

~

""'

" Ll&W

ПОJ,

2:S / tcp- FTP

ri

а

. [21/ tср] -ервис/ ПС [заблокирован]

80 / tcp - НТТР
135 / t cp - Microsoft RPC
139 / tcp • NetBIOS

Информация
Врем~ скан11рован1,~ порта :

Макс11мальны11 уровень уязв11мост11:

Рис.

7.10. Обнаружение XSpider факта фильтрации на прикладном уровне

Некоторые сканеры умеют определять факт фильтрации на прикладном

уровне, например
ван») (рис.

XSpider

(при этом статус порта обозначается «заблокиро­

7.10).

7 .3.

Сканирование портов

UDP

Этот метод используется для определения, какие UDР-порты на скани­
руемом узле являются открытыми. На требуемый порт сканируемой маши­

ны отправляется UDР-пакет (обычно пустой). Если в ответ было получено
IСМР-сообщение «Destination UnreachaЬle», это означает, что порт закрыт
(рис.

7.11).
Сканирующий

Сканируемый

узел (А)

Пустой UDР-пакет

ICMP (Destination

узел (В)

UnreachaЫe)

Рис.

7.11.

Определение открытых UDР-портов на сканиру­
емом узле

В противном случае (нет ответа) считается, что сканируемый порт от­
крыт.

При UDР-сканировании возникают следующие проблемы:

•

возможная потеря UDР-пакетов. В этом случае ответ также не будет

получен, и порту может быть ошибочно присвоен статус «открыт»;

66

•

высокая степень вероятности фильтрации

ка. Результат тот же, что и в предыдущем случае

UDP- или (и) IСМР-трафи­
- порт может быть ошибоч­

но считаться открытым.

Это приводит к тому, что в случае неполучения ответа от узла нельзя
быть уверенным в том, что порт открыт. Первая проблема решается введени­
ем двух параметров, которыми можно регулировать достоверность UDР-ска­
нирования:

•
•

число посылаемых UDР-пакетов;
время ожидания ответа.

Вторая проблема гораздо сложнее. Для ее решения разработчики ска­
неров используют различные усовершенствования, в частности одно из них

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

Internet Scanner.
Перед сканированием заданных пользователем портов UDP Internet
Scanner проводит UDР-сканирование портов из начала диапазона 1-65535
(230-240), из середины диапазона (2050-2060) и из конца диапазона
(45270-45280) (рис. 7.12). Тогда выбранные порты с большой долей вероят­

ности окажутся закрытыми.

Рис.

7.12.

UDР-сканирование портов сканером

Internet Scanner
Следовательно, IСМР-сообщение ~Destination UшeachaЬle>.'> должно быть
получено с большой долей вероятности. Если не будет получено ни одного
такого сообщения, Internet Scanner не предпринимает попыток UDР-скани­
рования и идентификации уязвимостей, основанных на

UDP.

Одним из способов повышения достоверности сканирования портов

UDP

является использование ~осмысленных>.'> запросов к сервисам вместо

пустых UDР-пакетов. В этом случае ответ от сервиса означает, что порт от­
крыт (рис.

7.13).

Такой способ сканирования UDР-портов используется, например, в ска­

нерах

XSpider, MaxPatrol, Nessus.
67

DNS-зaпpoc

---------@
ICMP

Destiпatioп UпгеасhаЫе

,л, соо,м,=ующ,й m,,,

,

••

SNМР-запрос

'Q

-------------8
ICMP

Destiпatioп UпгеасhаЫе

или соответствующий ответ

Рис.

7.13.

«Осмысленные~ запросы к сервисам
Контрольные вопро сы

1.
2.
3.

В чем заключается задача идентификации статуса порта?

Опишите особенности сканирования ТСР-портов.
В чем отличие ТСР-сканирования от сканирования UDР-портов?

Глава

8.

ИДЕНТИФИКАЦИЯ СЕРВИСОВ

И ПРИЛОЖЕНИЙ

8.1.

Идентификация ТСР-служб

Задача идентификации служб (приложений)

-

самая важная в кон­

тексте анализа защищенности. Значительная часть уязвимостей относится

к уровню приложений. На основе информации, собранной на данном этапе,
строятся методы выявления уязвимостей по косвенным признакам.

Использование баннеров. «Классический>> метод сбора информации
о запущенной на сканируемом узле службе - анализ баннеров. Этот метод
заключается в анализе приветствий, выводимых службами при подключении
на заданный порт. Часто баннеры содержат информацию об используемой

службе, вплоть до номера версии. Поскольку не все службы являются абсо­
лютно переносимыми, это дает возможность делать предположения об ис­
пользуемой О С, например:

te l net ftp.dmnl.ru 21
220 te l netftp.dmnl.ruFTPserver (Versionwu-2.4(37) MonFeb
15 16:48:38 MSK 1999) ready.
telnet smtp. dmnl. ru 25
220 smtp. dmnl. ru ESMTP Sendmail 8 .11. 2/8 .11. 2;
Jun 2001 18: 34: 19 +0400

Thu ,

21

При этом следует отметить следующие недостатки:
• многие службы позволяют администратору произвольно редактиро­
вать свои приветствия, т. е. существует вероятность (хотя и довольно малая),

что служба не та, за кого себя выдает;

68

•

есть риск, что ОС сканируемого узла работает в какой-нибудь среде

эмуляции (например,

VMWare).

Это может оказать влияние на проверки,

основанные на особенностях реализации стека ТСР/IP.
Эти недостатки не позволяют использовать такой метод как единствен­
ный для идентификации служб.

Учет особенностей работы протоколов. Более достоверными являют­
ся методы, основанные на анализе особенностей работы служб. Суть этих
методов состоит в посылке запросов, которые незначительно отличаются от

стандарта, в использовании редких (малоизвестных) команд или опций.
SМТР-сервер. Несколько стандартов

- RFC 821, RFC 1425, RFC 1985 -

определяют поведение SМТР-сервера: команды, которые SМТР-клиент мо­
жет выполнить, подключившись к серверу, обязательные возможности серве­

ра, допустимые аргументы и данные. Однако, как обычно, не все реализации
SМТР-серверов удовлетворяют этим требованиям. Кроме того, анализу под­
лежат и сообщения об ошибках, выдаваемые сервером, хотя эти сообщения
могут быть изменены администратором сервера, что снижает достоверность

данного метода. Как правило, достаточно кода ошибки. Ниже приведено
несколько приемов, позволяющих отличить один SМТР-сервер от другого:

•

корректно заданная команда

данной команды

HELO.

MAILFROM

без предварительно пере­

Некоторые серверы это позволяют (возвращая код

ошибки 220), другие - запрещают (501 или 503);
• команда HELO без указания имени домена. Стандарт этого не разре­

шает, но некоторые серверы позволяют выполнить команду таким образом;

•
«:~

использование команды MAILFROM без указания символа

после

FROM.

Некоторые серверы, например,

qmail,

это позволяют, хотя

стандарт явно запрещает;

•

использование команды

MAILFROM:

с пустым адресом отправи­

теля. Все серверы должны это разрешать, но возможны исключения;

•

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

MAILFROM.

Некоторые серверы это запрещают, т. е. проверяют существование указанно­
го домена.

Одним из распространенных методов идентификации SМТР-сервера
является проверка поддержки некоторых команд:

TURN; SOML; SAML; NOOP; EHLO.
Следует отметить технику mail-bouncing,

HELP; VRFY; EXPN;

которая недостаточно распро­

странена из-за большой сложности и малой скорости работы. Смысл техники
заключается в анализе заголовков электронных писем, специально состав­

ленных и посланных в исследуемую сеть. Так, интерес представляют письма
для несуществующих пользователей, поскольку они возвращают уведомле­

ния о невозможности доставки (не всегда). В этих уведомлениях содержится
некоторая информация о почтовых серверах, участвующих в процессе достав­

ки письма. На основе нескольких таких «писем-бумерангов~ можно узнать
некоторое число узлов внутренней сети (не имея к ней непосредственного
доступа) и топологию почтовых пересылок. Кроме того, почтовый протокол

69

позволяет отправлять письма с явным указанием нескольких промежуточ­

ных пунктов пересылки. Это дает возможность создать письмо, которое, про­

делав заданный маршрут внутри исследуемой сети, вернется к отправителю
(все это, конечно, существенно зависит от настроек почтовых серверов).

WеЬ-сервер. Важная служба прикладного уровня
НТТР версии

1.1 описан

в стандарте

RFC 2068.

-

НТТР. Протокол

В нем предусмотрен метод

согласно которому НТТР-сервер возвращает развернутую ин­

OPTIONS,

формацию о себе, например:

OPTIONS *

НТТР\ 1. 1
200 ОК
Date Wed 20 Jun 2001 17: 41: 42 GMT
Server : Apache/1.3.19 (Unix) РНР/4.0.5 mod_jk
Content-Length: О
Al low: GET , HEAD, OPTIONS , TRACE
Connection: close
НТТР/1.1

rus/PLЗ0.4

Это лишь один из способов. Для получения дополнительной информа­
ции можно использовать характеристики стандартных конфигураций раз­
личных www-cepвepoв под различные платформы.

Инструменты сканирования. Известная утилита

nmap наряду с возмож­

ностями по сканированию портов и идентификации ОС имеет возможность

идентификации служб.

Сканер приложений

amap (http;//packetstormsecurity.org/groups/thc/

amap-2.5.tar.gz) позволяет идентифицировать приложения, работающие
на нестандартных портах (в том числе и так называемые non-ascii based
applications). Утилита использует простой метод: посылку на выбранный
порт специальным образом построенного пакета и анализ ответа. БД запро­
сов представляет собой текстовый файл appdefs.trig Полученный от узла от­
вет сравнивается с типовыми ответами из файла appdefs.resp
Простейший вариант использования утилиты:

amap



Сканер

amap

может использовать результаты утилиты

nmap,

в этом слу­

чае формат запуска следующий:

amap -i resul ts . nmap
Имеются

также

например, программа

-о

resul ts. amap -m

специализированные

инструменты

анализа

служб,

SMTP Scan.

Тесты, выполняемые программой в отношении SМТР-сервера, опреде­

лены в файле / usr/ local/share/smtpscan/tests Почти все тесты представляют
собой запросы, ответы на которые точно не определены в соответствующих
документах

RFC.

В ответ на каждый запрос SМТР-сервер возвращает код

ошибки, на основе которого и делается вывод о версии и модели сервера.

70

8.2.

Идентификация UDР-служб

Сканирование на прикладном уровне. Работающий без установления
соединения протокол

UDP

затрудняет не только сканирование UDР-портов

(об этом уже говорилось выше), но и идентификацию служб, использующих
эти порты.

Большинство прикладных служб сети Интернет используют протокол
ТСР в качестве транспорта, только некоторые из них пользуются протоко­

лом UD Р. В большинстве случаев используются стандартные номера портов.
Эти два факта лежат в основе метода, используемого в программе XSpider:
сканирование UDР-портов сразу на прикладном уровне. Идея очень простая:
вместо пустого UDР-пакета посылать запрос, содержащий данные приклад­

ного уровня, характерные для этой службы. Например, на порт
ется DNS-зaпpoc, на порт

161 -

53

посыла­

SNМР-запрос и т. д. Это уменьшает число

ложных срабатываний, но сужает диапазон сканирования, делая его состоя­
щим только из ~хорошо известных~ портов.

Анализ параметров повторной передачи. Поскольку

протокол, обеспечение надежности

-

UDP

ненадежный

задача приложения. Обычно для обе­

спечения надежности используется метод повторной передачи. Если ответ
от узла н е пришел в течение определенного времени, проводится повторная

передача пакета. При этом используются следующие параметры:

•
•

время ожидания перед повторной передачей пакета;

изменение времени ожидания с каждой последующей передачей па­

кета;

•

число передаваемых пакетов.

Как правило, стратегия повторной передачи не определена стандар­

том, и разработчик ПО выбирает ее сам. Следовательно, можно идентифи­

цировать базирующуюся на

UDP

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

повторной передачи, которая варьируется от приложения к приложению.
Например, этот метод реализован в программе

8.3.

IKEScan.

Сканирование протоколов

Выше были рассмотрены методы сканирования портов и идентификации
служб. Но вся эта информация относилась к транспортному и прикладному
уровням. Однако на сетевом уровне иногда возникает задача определения
используемых в сети IР-протоколов. Например, на рис.

8.1

приведен модуль

слежения системы обнаружения атак, установленный между маршрутизато­
ром и межсетевым экраном.

Обычная ситуация в этом случае

Unknown

-

регулярно появляющиеся события

pгotocol. Для настройки системы обнаружения атак потребуется

определить используемые в сети протоколы. Иногда в такой ситуации ис­
пользуют сканирование протоколов, т. е. сканирование сетевых устройств

71

-------------------------------~1

~- !

омz-

~
~

Рис.

------

-т-

---------------,

....,.r,a!
1

~

К внутренней сети

- - -- t i , ~ ~- - - - - --1:r...
.,r-:......-!!l!!!;lr--- - - - - - -

~ \Ь ~~~-

8.1. Модуль слежения IDS между маршрутизатором и меж­
сетевым экраном

с целью определения поддерживаемых ими типов

IP.

Полученная информа­

ция может быть использована для предварительной настройки модуля сле­

жения системы обнаружения атак.
Принцип сканирования заключается в следующем (рис.

8.2).

IР-пакет

ICMP Protocol
Рис.

8.2.

UnreachaЫe

Сканирование протоколов

На узел посылается IР-пакет с требуемым значением поля «тип прото­
кола» в заголовке.

Если в ответ пришло сообщение

ICMP Protocol

UnreachaЬle, протокол

не поддерживается. Если ответ не пришел, протокол поддерживается. Этот
тип сканирования очень напоминает UDР-сканирование, поэтому ему при­

сущи те же проблемы. Например, при сканировании межсетевых экранов па­
кет ICMP Protocol UnreachaЬle может быть заблокирован, и тогда возможно
большое число ложных срабатываний.
Для проведения сканирования можно использовать сканер

nmap.

Синтаксис:

nmap - s0



Контрольные вопросы

1.
2.

В чем заключается суть метода анализа баннеров?
Перечислите методы, основанные на анализе особенностей работы служб.

Каковы их преимущества по сравнению с методом анализа баннеров?
3. Дайте характеристику и приведите особенности работы утилиты

4.
5.
72

Как проводится идентификация UDР-служб?

В чем заключается метод сканирования протоколов?

nmap.

Глава

9.

ИДЕНТИФИКАЦИЯ ОПЕРАЦИОННЫХ СИСТЕМ

Один из этапов сбора информации о сетевых ресурсах

-

определение

типа и версии ОС удаленного узла.

Все известные методы определения ОС можно сгруппировать следую-

щим образом:

•
•
•
•

простейшие методы;

ТСР/

IP Fingerprinting;

основанные на использовании протокола

ICMP;

малоизвестные, редко используемые.

Рассмотрим более подробно приведенные методы.

9.1.

Простейшие методы определения ОС

К данной группе относятся:

•
•
•
•
•

анализ наборов открытых портов;
использование сервисов прикладного уровня;

анализ баннеров сервисов прикладного уровня;
использование команд протоколов прикладного уровня;

анализ результатов идентификации сервисов и приложений.

Анализ наборов открытых портов. Наиболее простой метод основан
на очевидном факте, что ряд сервисов прикладного уровня жестко «связан>,)

с платформой. Например, открытый порт
висом

на

SSH) почти однозначно
ОС Windows (рис. 9.1).

Рис.

9.1.

22 ( обычно
UNIX,

указывает на ОС

используемый сер­
а порты

135, 139 -

Анализ наборов открытых портов

Использование сервисов прикладного уровня. Один из самых простых
методов определения ОС удаленного узла

-

подключение на открытые пор­

ты и анализ отклика работающих на них служб (рис.

9.2).
73

. ....,,"',

Red M•t
......1

login:

Рис.

9.2.

,щ, 1 1 1.' 1

linuм ~•l••s• 6.2 (Zoot)
2.2.,-- ,., .1 0.11 М 1616

1

Подключение на открытые порты и анализ отклика рабо­
тающих на них служб

Часто приветствия (баннеры) прикладных сервисов содержат также ин­
формацию об ОС.

Отметим еще один метод
уровня, например команда

- использование команд служб
SYST протокола FTP (рис. 9.3).

прикладного

telnet edu-maln2k 21
220 edu-maln2k М lcrosoft FТР Service (Verslon 5.0).
userftp
331 Anonymous access allowed, send identity (e-mal
name) as password.
pass f@f
230Anonymous user logged in.

Рис.

9.3.

Использование команд служб прикладного уровня

Возможно также использование протокола

SMB

(рис.

9.4).

Наконец, вывод о типе ОС может быть сделан на основе результатов
идентификации сервисов и приложений (рис. 9.5) .

-

•

. '"--·
,.,_

1n.1,.a.s1

••

..

.,,,...,,,__
1]11/1,ф•-RК

119 / 1,ф • llot8IOS
щ

---$,l

.__

Рис.

74

9.4.

Использование протокола

SMB

SSH

UNIX
Рис.

9.5.

Идентификация сервисов и приложений

Например, если на удаленном узле открыт порт
тификации сервисов указывают на
но утверждать, что это ОС

SSH,

220,

а результаты иден­

с большой долей вероятности мож­

UNIX.

9.2.

Опрос стека ТСР /

IP

Различать ОС можно на основе различий в реализации стека ТСР/

(рис.

IP

9.6).

Из-за этих различий реакция ОС на определенные сетевые пакеты бу­
дет разной. Метод, основанный на данном наблюдении, называется ТСР/

IP

Stack Fingerprinting.
FTP. TELNET.
SMTP. РОРЗ
и др .

TCP,UDP
IP

Ethernet. FDDI
Х.25
и др .

Рис .

9.6.

Различия в реализации стека ТСР /

Исследование значения

ISN.

IP

Запрос на установление ТСР-соединения

содержит флаг

SYN в заголовке пакета и начальное значение в поле Sequence
9.7). Это значение называется ISN (Init ial Sequence Number).
Узел, получив запрос на соединение, увеличивает значение ISN на еди­
ницу и записывает полученное значение в поле Acknowledgement Number.
При этом в поле Sequence Number записывается значение ISN сканируемого

Number

(рис.

узла. Это значение и является предметом исследования в данном случае. За­
помнив его, сканирующий узел повторяет запрос на установление соедине­

ния и опять получает значение

ISN. Операция повторяется до тех пор,
ISN сканируемого узла (рис. 9.8).

пока

не будет выявлен закон изменения

75

~
о

Запрос на установление соединения

4

16

10

••
31

24
Destination Port

Source Port

lnitial Sequence NumЬer
Acknowledgement Number
UA PR SF
Reserved RC
YI
GK нт NN

Data
Offset

ss

Checksum

Window

Urgent Pointer

Options

1

Padding

Data
Рис.

_

9.7.

Запрос на установление ТСР-соединения

_ ISN=_100,S_YN=1 _ _ _ _ ,

1v

Acknowledgement Number =101 , ISN=200, SYN=1,

АСК=1

1

111

ISN=100, SYN=1
Acknowledgement Number =101, ISN=ЗO0 , SYN=1, АСК=1

ISN=100, SYN=1
Acknowledgement Number =101, ISN=400, SYN=1, АСК=1

Рис.

9.8.

Выявление закона изменения

ISN

сканируемого узла

При этом возможны следующие ситуации:

•

(традиционный закон

старых версий

UNIX). Значение

«+64>,) характерен для
Sequence

ISN-cepвepa, записываемого в поле

Number ответа на запрос на установление соединения, увеличивается каж­
64);
• «случайное приращение>,) (новые версии Solaris, IRIX, FreeBSD,
DigitalUNIX, Cray): приращение ISN носит случайный характер;
•