Зегжда Д.П. Информационная безопасность

Подождите немного. Документ загружается.

широковещательный ARP—запрос на Ethernet—адрес FFFFFFFFFFFFh, в котором

указывает IP — адрес маршрутизатора и просит сообщить его Ethernet — адрес (IP —

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

ручную при настройке любой сетевой ОС в сети Internet). Этот широковещательный

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

Получив данный запрос, маршрутизатор внесет запись о запросившем хосте в свою ARP

— таблицу, а затем отправит на запросивший хост ARP — ответ, в котором сообщит

свой Ethernet — адрес. Полученный в ARP — ответе Ethernet — адрес будет занесен в

ARP — таблицу, находящуюся в памяти операционной системы на запросившем хосте и

содержащую записи соответствия IP и Ethernet — адресов для хостов внутри одной

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

подсети, также используется ARP — протокол и рассмотренная выше схема полностью

повторяется.

Из п. 4.2.2.4 следует, что в случае использования в сетевой ОС алгоритмов

удаленного поиска существует возможность осуществления в такой сети типовой

удаленной атаки — ложный сервер. Из анализа ARP — протокола становится ясно, что

перехватив на атакующем хосте внутри данного сегмента сети широковещательный ARP

— запрос, возможно послать ложный ARP—ответ, в котором объявить себя искомым

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

сетевой трафик "обманутого" хоста по схеме ложный сервер.

Рассмотрим обобщенную функциональную схему ложного ARP — сервера.

— ожидание ARP — запроса;

— при получении ARP — запроса передача по сети на запросивший хост ложного

ARP — ответа, в котором необходимо указать адрес сетевого адаптера атакующей

станции (ложного ARP — сервера) или тот Ethernet — адрес, на котором будет

принимать пакеты ложный ARP — сервер (совершенно необязательно указывать в

ложном ARP — ответе свой настоящий Ethernet — адрес, так как при работе

непосредственно с сетевым адаптером его можно запрограммировать на прием пакетов

на любой Ethernet-адрес);

— прием, анализ, воздействие и передача пакетов обмена между

взаимодействующими хостами (воздействие на перехваченную информацию см п. 4.2.2.4

1 — 4.2.2.4.3). При исследовании различных сетевых ОС выяснилось, что в ОС Linux

1.2.8 при адресации к хосту, находящемуся в одной подсети с данным хостом, при

отсутствии в ARP — таблице соответствующей записи о Ethernet — адресе посылается

ARP — запрос и при последующих обращениях к данному хосту посылки ARP —

запроса не происходит. В ОС UNIX System V, установленной на компьютере SPARC,

при каждом новом обращении к хосту происходит посылка ARP

— запроса и, следовательно, ARP — таблица динамически обновляется. ОС

Windows 95 при обращении к хостам с точки зрения использования протокола ARP ведет

себя также, как и ОС Linux, за исключением того, что эта операционная система

периодически (каждую минуту) посылает ARP — запрос о Ethernet—адресе

маршрутизатора, а в результате

— в течении нескольких минут вся локальная сеть с Windows

95 с легкостью поражается с помощью ложного ARP — сервера.

4.2.4.3. Ложный DNS-сервер в сети Internet.

Как говорилось в предыдущем пункте, для обращения к хостам в сети Internet

используются 32 — разрядные IP — адреса, уникально идентифицирующие каждый

сетевой компьютер в этой глобальной сети. Однако, для пользователей использование IP

— адресов для обращения к хостам является не слишком удобным и не самым

наглядным. Поэтому, в самом начале зарождения Internet для удобства пользователей

было принято решение присвоить всем компьютерам в сети имена. Это решение

породило проблему преобразования имен в IP—адреса. Такое преобразование

необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP —

адресам. На этапе раннего развития Internet, когда в сеть было объединено небольшое

количество компьютеров, NIC (Network Information Center) для решения проблемы

преобразования имен в адреса создал специальный файл (host file), в который вносились

имена и соответствующие им IP — адреса всех хостов в сети. Данный файл регулярно

обновлялся и распространялся по всей сети. Но, по мере развития Internet, число хостов,

объединенных в сеть, увеличивалось, и данная схема становилась все менее и менее

работоспособной. Поэтому была создана новая система преобразования имен, названная

доменной системой имен — DNS (Domain Name System).

Для реализации системы DNS был создан специальный сетевой протокол DNS, а

также, в сети Internet создавались специальные выделенные DNS — серверы. Поясним

основную проблему, решаемую службой DNS. В современной сети Internet хост при

обращении к удаленному хосту может иметь информацию только о его имени и не знать

его IP — адреса, который и необходим для непосредственной адресации. Следовательно,

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

его IP — адрес. Решением этой проблемы и занимается служба DNS на базе протокола

DNS.

Рассмотрим DNS — алгоритм поиска IP — адреса по имени в сети Internet:

— хост посылает на IP — адрес ближайшего DNS — сервера (он устанавливается

при инсталляции сетевой ОС) DNS — запрос, в котором указывает имя сервера, IP —

адрес которого необходимо найти;

— DNS — сервер, получив DNS — запрос, просматривает свой host file на предмет

наличия в нем указанного в запросе имени. В -случае, если имя найдено, а,

следовательно, найден и соответствующий ему IP — адрес, то на запросивший хост DNS

— сервер отправляет DNS — ответ, в котором указывает искомый IP — адрес. В случае,

если указанное в запросе имя DNS — сервер не смог обнаружить в своей базе имен (host

file), то DNS — запрос отсылается DNS — сервером на следующий ближайший к нему

DNS — сервер и описанная в этом пункте процедура повторяется пока имя не будет

найдено (или не найдено).

Анализируя уязвимость с точки зрения безопасности этой схемы удаленного

поиска с помощью протокола DNS, а также исходя из п. 4.2.2.4, можно сделать вывод о

возможности осуществления в сети, использующий протокол DNS, типовой удаленной

атаки — ложный сервер. Для ее реализации на атакующей станции достаточно

перехватить DNS — запрос и послать ложный DNS — ответ, в котором указать в

качестве искомого IP — адреса настоящий IP — адрес ложного DNS — сервера. Это

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

ложный сервер на трафик между "обманутым" хостом и сервером. Важно отметить, что в

случае нахождения атакующего в одном сегменте с настоящим DNS — сервером

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

сеть Internet.

Рассмотрим обобщенную схему работы ложного DNS — сервера

— ожидание DNS — запроса,

— получив DNS — запрос, передача по сети на запросивший хост ложного DNS —

ответа, в котором указывается IP — адрес ложного DNS — сервера;

— в случае получения пакета от хоста, изменение в IP — заголовке пакета его IP —

адреса на IP — адрес ложного DNS — сервера и передача пакета на сервер (то есть,

ложный DNS — сервер ведет работу с сервером от своего имени);

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

— адреса на IP — адрес ложного DNS — сервера и передача пакета на хост (для хоста

ложный DNS — сервер и есть настоящий сервер).

Практическая реализация данной удаленной атаки выявила ряд интереснейших

особенностей в работе протокола FTP и в механизме идентификации TCP — пакетов

(подробнее, см. 4.2.4.5.). В случае, если FTP — клиент на хосте подключился к

удаленному FTP — серверу через ложный DNS — сервер, то оказывалось, что каждый

раз после выдачи пользователем прикладной команды FTP (например, Is, get, put и т.д.)

FTP— клиент вырабатывал команду представительного уровня PORT, которая состояла

в передаче на FTP — сервер в поле данных TCP — пакета номера порта и IP — адреса

клиентского хоста. Это приводило к тому, что если на ложном DNS — сервере не

изменить передаваемый IP — адрес в поле данных TCP — пакета и передать этот пакет

на FTP — сервер по обыкновенной схеме, то следующий пакет будет передан FTP —

сервером на хост FTP — клиента, минуя ложный DNS — сервер и, что самое

удивительное, этот пакет будет воспринят как нормальный пакет (см п. 4.2.4.5.), и ,в

дальнейшем, ложный DNS — сервер потеряет контроль над графиком между FTP —

сервером и FTP — клиентом!

4.2.4.4. Навязывание хосту ложного маршрута с помощью протокола ICMP

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

Как уже подчеркивалось в п. 4.2.2.2 маршрутизация в сети Internet играет

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

Маршрутизация в сети Internet осуществляется на сетевом уровне (IP — уровень) Для ее

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

содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к

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

ЭВМ в этом сегменте и маршрутизатор должны физически находится в одном сегменте

Поэтому, все пакеты, адресованные в другие сегменты сети, направляются на

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

пакете IP — адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети

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

маршрутизации: RIP, OSPF. Рассмотрим, что представляет из себя таблица

маршрутизации хоста. В каждой строке этой таблицы содержится описание

соответствующего маршрута. Это описание включает IP — адрес конечной точки

маршрута (Destination), IP — адрес соответствующего маршрутизатора (Gateway), а

также ряд других параметров, характеризующих этот маршрут. Обычно в системе

существует так называемый маршрут по умолчанию (поле Destination содержит значение

0.0.0 0 а поле Gateway — IP — адрес маршрутизатора). Этот маршрут означает, что все

пакеты, адресуемые на IP — адрес вне пределов данной подсети, будут направляться по

указанному по умолчанию маршруту, то есть, на маршрутизатор (это реализуется

установкой в поле адреса назначения в Ethernet — пакете аппаратного адреса

маршрутизатора).

Как говорилось ранее, в сети Internet существует управляющий протокол IСМР,

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

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

по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией

реализовано в виде передачи с маршрутизатора на хост управляющего IСМР —

сообщения Redirect Message. Изучение протокола IСМР показало, что сообщение

Redirect бывает двух типов. Первый тип сообщения носит название Redirect Net и

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

маршрута. Второй тип — Redirect Host информирует хост о необходимости создания

нового маршрута к указанному в сообщении хосту и внесения его в таблицу

маршрутизации. Для этого в этом сообщении указывается IP — адрес хоста, для

которого необходима смена маршрута (адрес будет занесен в поле Destination), и IP —

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

данному хосту (этот адрес заносится в поле Gateway).

Анализ исходных текстов ОС Linux 1.2.8 показал, что, во-первых, ICMP —

сообщение Redirect Net игнорируется данной ОС (это представляется логичным,

следовательно, можно сделать вывод, что его игнорируют и другие сетевые ОС), а, во-

вторых, единственный параметр, идентифицирующий сообщение ICMP Redirect Host —

это IP — адрес отправителя, который должен совпадать с IP — адресом маршрутизатора,

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

выше факты позволяют осуществить типовую удаленную атаку, которая носит название:

"Навязывание хосту ложного маршрута" (см. п 4.2.2.2).

Для осуществления этой удаленной атаки необходимо подготовить ложное ICMP-

сообщение Redirect Host, в котором указать конечный IP—адрес маршрута (Distination) и

— адрес ложного маршрутизатора. Далее, это сообщение посылается на атакуемый

хост от имени маршрутизатора. Для этого в IP — заголовке в поле адреса отправителя

указывается IP — адрес маршрутизатора. После этого весь трафик между атакуемым

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

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

передачей пакетов, получаемых от обманутых хостов. Данная стадия атаки полностью

совпадает со второй стадией типовой атаки ложный сервер (см. п. 4.2.2.4). Рассмотрим

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

ложном маршрутизаторе:

— если пришел ARP — запрос от атакуемого хоста, то посылается ARP — ответ;

— если пришел пакет от атакуемого хоста, то он переправляется на настоящий

маршрутизатор;

— если пришел пакет от маршрутизатора, то он переправляется на атакуемый хост;

— при приеме пакета возможно воздействие на информацию по схеме ложный

сервер (см. п. 4.2.2.4.1 —4.2.2.4.3)

Данная удаленная атака была осуществлена на практике на примере ОС Linux 1.2.8

и ОС Windows 95 и показала своя работоспособность.

4.2.4.5. Подмена одного из участников сетевого обмена в сети Internet при

использовании протокола TCP.

Протокол TCP (Transmission Control Protocol) является одним из базовых

протоколов транспортного уровня сети Internet. Этот протокол имеет возможность

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

протоколом с установлением логического соединения — виртуального канала. По этому

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

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

искаженных пакетов, а в конце сеанса — канал разрывается [2]. При этом протокол TCP

является единственным базовым протоколом из семейства TCP/IP, имеющим надежную

систему идентификации пакетов. Именно поэтому протоколы прикладного уровня FTP и

TELNET, предоставляющие пользователям удаленный доступ на хосты Internet,

реализованы на базе протокола TCP.

Для идентификации пакета в TCP—заголовке существуют два 32 — разрядных

идентификатора, которые еще играют и роль счетчика пакетов. Первый идентификатор

носит название Sequence Number, а второй — Acknowledgment Number. Также, нас будет

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

следующие командные биты (слева направо):

URG: Urgent Pointer field significant

АСК: Acknowledgment field significant

PSH: Push Function

RST: Reset the connection

SYN: Synchronize sequence numbers

FIN: No more data from sender

Рассмотрим схему создания TCP — соединения (виртуального TCP — канала).

Предположим, что хосту А необходимо создать TCP — соединение с хостом В. Тогда А

посылает на В следующий пакет:

1.А→В: SYN, ISSa

Это означает, что в посланном пакете установлен бит SYN (synchronize sequence

number), а в поле Sequence Number установлено начальное 32 — битное значение ISSa

(Initial Sequence Number).

В отвечает:

2. В → А: SYN, АСК, ISSb, ACK(ISSa+1)

В ответ на полученный от А запрос В отвечает сообщением, в котором установлен

бит SYN и установлен бит АСК;

в поле Sequence Number хостом В устанавливается свое начальное значение

счетчика — ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в

первом пакете от хоста А и увеличенное на единицу.

А, завершая handshake, посылает:

3. А → В: АСК, ISSa+1, ACK(ISSb+1)

В этом пакете установлен бит АСК; поле Sequence Number содержит ISSa +1; поле

Acknowledgment Number содержит значение ISSb+1. Посылкой этого пакета на хост. В

заканчивается трехступенчатый handshake и TCP — соединение между хостами А и В

установлено.

Далее, хост А может посылать пакеты с данными на хост В по только что

созданному виртуальному TCP — каналу:

4. А → В: АСК, ISSa+1, ACK(ISSb+1); DATA

Из рассмотренной выше схемы создания TCP — соединения становится ясно, что

для формирования ложного TCP— пакета необходимо знание текущих для данного

соединения 32 — битных параметров: Sequence Number и Acknowledgment Number.

Возможная подмена TCP — пакета становится еще более важной, так как изучение

протоколов FTP и TELNET, использующих TCP, показало, что проблема идентификации

FTP- и TELNET-пакетов целиком возлагается данными протоколами на транспортный

уровень, то есть, на TCP. Это означает, что атакующему достаточно, подобрав

соответствующие текущие значения идентификаторов TCP

— пакета для данного TCP — соединения (например, данное соединение может

представлять собой FTP или TELNET подключение с доверенного хоста на сервер),

послать пакет с любого хоста в сети Internet от имени одного из участников данного

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

Но это еще не все. Так как, FTP и TELNET не проверяют IP — адреса отправителей, от

которых им приходят пакеты, то, в ответ на полученный ложный пакет, FTP или ТЕШЕТ

сервер отправит ответ на указанный в ложном пакете настоящий IP — адрес атакующего

и в результате, атакующий начнет работу с FTP или TELNET сервером со своего IP —

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

потеряет связь с сервером из-за рассогласования счетчиков!

Итак, для осуществления описанной выше атаки необходимым и достаточным

условием является знание двух текущих параметров SYN и АСК (не путать с

контрольными битами!), идентифицирующих TCP — соединение. Рассмотрим

возможные способы их получения. Во-первых, если атакующий находится в одном

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

задача получения значений SYN и АСК является тривиальной и решается путем анализа

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

когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача

получения значений SYN и АСК является не тривиальной.

Первый вопрос, который необходимо решить в этом случае, как операционная

система формирует начальное значение SYN, называемое Initial Sequence Number? В

описание протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32 —

битного счетчика на 1 каждые 4 микросекунды. Однако, это является только

рекомендацией, поэтому в Berkeley — совместимых ядрах ОС UNIX значениесчетчика

увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ

исходных текстов ядра ОС Linux показал, что значение SYN вычисляется данной ОС по

следующей формуле:

(1) SYN = Msec +sec* 1000000, где

Msec — текущее время в микросекундах

sec — текущее время в секундах, причем отсчет его идет

от 1970 года.

Следовательно, можно сделать общий вывод, что обычно в ОС значение Initial

Sequence Number вычисляется по следующей обобщенной формуле:

(2) SYN = a*Msec + b*sec, где а и b — некоторые коэффициенты, специфичные для

данной ОС.

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

труда. Для этого достаточно послать запрос на создание TCP — соединения и в ответ ОС

вернет нужное число. Далее, зная формулу, по которой вычисляется SYN, можно с той

или иной степенью точности вычислить текущие временные параметры операционной

системы, с помощью которых и получается значение SYN. В качестве примера, возьмем

ОС Linux 1.2.8. Для этой ОС справедлива обобщенная формула (2), при а=1 и b=1000000.

Тогда, получив в ответ на запрос значение SYN можно по формуле (1) вычислить

значение Msec, приближенно равное SYN — sec* 1000000 + time/2, где time — это время,

через которое пришел ответ на запрос. Узнать текущее значение sec на удаленной ОС не

составляет труда. Сложнее обстоит дело с параметром time/2, так как время прохождения

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

значений time можно определить степень точности вычисленного значения Msec

(например, с точностью до 1000 мкс или до 100мкс). Соответственно, чем ближе цель

атаки, тем выше степень точности определения значения Msec.

Теперь, определив параметры, необходимые для вычисления SYN, на

операционных системах на сервере и предполагаемом клиенте, атакующий начинает

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

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

диапазон значений SYN, которыми обменялись при создании TCP — канала данные

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

не избежать подбора нужных значений. Однако, если не проводить описанный выше

анализ, то для перебора всех возможных значений SYN и АСК понадобилось бы послать

2 в 64 степени пакетов, что не реально. В случае использования описанного выше

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

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

на операционных системах с точностью до 10ООмкс, то достаточно послать всего

1000*1000 пакетов.

В заключение, рассмотрим ставшую уже классической удаленную атаку на r—

службы, осуществление которой связано с описанными выше особенностями

идентификации TCP — пакетов.

4.2.4.6. Использование недостатков идентификации ТСР-пакетов для атаки на

rsh-сервер.

В ОС UNIX существует понятие: доверенный хост. Доверенным по отношению к

данному хосту называется хост, доступ на который пользователю с данного хоста

возможен без его аутентификации и идентификации с помощью r — службы. Обычно, в

ОС UNIX существует файл rhost, в котором находится список имен и IP — адресов

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

воспользоваться программами, входящими в r — службу (например, rlogin, rsh и.т.д.) В

этом случае при использовании r — программ пользователю для получения удаленного

доступа не требуется проходить стандартную процедуру идентификации и

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

Аутентифицирующей информацией для r — службы является IP — адрес хоста, с

которого пользователь осуществляет r — доступ. Отметим, что все программы из r —

службы реализованы на базе протокола TCP. Одной из программ, входящих в r —

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

Программа rsh (remote shell) позволяет отдавать команды shell удаленному хосту. При

этом, что является чрезвычайно важным в данном случае, для того, чтобы отдать

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

на r — службывся сложность для атакующего заключается в том, что ему необходимо

послать пакет от имени доверенного хоста, то есть, в качестве адреса отправителя

необходимо указать IP — адрес доверенного хоста. Следовательно, ответный пакет будет

отправлен именно на доверенный хост, а не хост атакующего.

Схема удаленной атаки на rsh — сервер была впервые описана небезызвестным Р.Т

Моррисом в Bell Labs Computer Science Technical Report #117, February 25, 1985. Она

заключается в следующем

Пусть хост А доверяет хосту В. Хост Х — это станция атакующего

Вначале атакующий Х открывает настоящее TCP — соединение с хостом В на

любой TCP — порт (mail, echo и т.д.). В результате Х получит текущее значение на

данный момент времени ISSb Далее, Х от имени А посылает на В TCP — запрос на

открытие соединения

1. Х → В: SYN, ISSx

Получив этот запрос, В анализирует IP — адрес отправителя и решает, что пакет

пришел с хоста А. Следовательно, В в ответ посылает на А новое значение ISSb'

2. В → А: SYN, ACK, ISSb', ACK(ISSx+1)

Х никогда не получит это сообщение от В, но, используя

предыдущее значение ISSb и схему для получения ISSb' из

п 2.4.5, может послать на В:

3. Х → В: ACK, ISSx+1, ACK(ISSb'+1)

Отметим, что для того, чтобы послать этот пакет потребуется перебрать некотрое

количество возможных значений ACK(ISSb' + 1), но не потребуется подбор ISSx + 1, так

как этот параметр TCP — соединения был послан с Х на В в первом пакете.

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

доверенного хоста А, а на самом деле это атакующий с хоста Х. И хотя Х никогда не

увидит пакеты с хоста В, но он сможет выполнять на нем команды.

4.2.5. Заключение.

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

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

позволяет на практике осуществить анализ информационной безопасности любой

сетевой операционной системы и сделать вывод ее защищенности. Используя

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

методики исследования безопасности компьютерных сетей. Применение данной

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

авторами при анализе безопасности сетевой ОС Novell NetWare и сети Internet.

Следующая глава будет посвящена Firewall — методике, которая позволяет

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

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

сетях.

Глава 5.

Использование систем Firewall.

Зарубежные специалисты считают, что многие проблемы, связанные с

безопасностью Internet, можно откорректировать или сделать менее серьезными с

помощью широко известных методов и средств контроля безопасности хостов. Firewall

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

к необходимым службам сети Internet [8]. Пример firewall, включающего маршрутизатор

с фильтрацией пакетов и прикладной шлюз, приведен на рис.5.1.

Сеть

Рисунок 5.1. Пример firewall с маршрутизатором и шлюзом.

Необходимо отметить, что firewall — это не просто маршрутизатор, система хостов

или совокупность систем, обеспечивающих безопасность сети. Firewall — это метод

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

ЭВМ

Шлюз

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

обеспечения безопасности, определяющую, какие службы и какой доступ должны быть

разрешены. Основная цель состоит в том, чтобы контролировать поток информации в/из

защищаемой сети. Эта система реализует такой порядок доступа к сети, при котором

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

Firewall-системой может быть маршрутизатор, ЭВМ хост или совокупность хостов,

установленных специально для защиты сети или подсети, протоколов и служб, которые

могут быть использованы злоумышленниками с хостов вне сети. Firewall обычно

располагают на шлюзе, например, на месте соединения сети с Internet, однако эти

системы могутразмещаться и на шлюзах более низких уровней для защиты меньшей

совокупности хостов или подсетей.

Главный довод в пользу firewall состоит в том, что без них системы подвергаются

опасности со стороны таких заведомо незащищенных служб, как NFS и NIS, а также

зондированию и атакам с каких-либо других хостов внутренней сети[11]. В среде, не

имеющей firewall, безопасность сети целиком зависит от безопасности хоста,

подключенного к Internet, в свою очередь все хосты должны быть объединены для

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

поддерживать во всех хостах одинаковый уровень безопасности. Поскольку ошибки и

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

в результате сложных атак, а из-за ошибок в конфигурации и ненадежности паролей.

Подход с использованием firewall предоставляет многочисленные преимущества,

позволяя повысить общий уровень безопасности.

5.1. Достоинства применения

Firewall.

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

хостов подсети, фильтруя заведомо незащищенные службы. В результате, сетевая среда

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

протоколы.

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

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

типа NFS. Это позволяет предотвратить использование таких служб внешними

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

Firewall могут также обеспечить защиту от таких атак, как маршрутизация

источника или попытки направить маршруты к скомпрометированным объектам через

переназначения ICMP. Firewall может отвергать все пакеты с маршрутизацией источника

или переназначенные ICMP, a затем информировать администраторов об инцидентах.

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

Например, одни хосты можно сделать достижимыми из внешних сетей, а другие,

наоборот, надежно защитить от нежелательного доступа. Сеть может запретить внешний

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

почтовые или информационные серверы.