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

практической реализации может служить система 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 (по --">