1). Взломщик ожидает пакет, идущий от сервера к клиенту на втором этапе установления соединения.
2). Обнаружив этот пакет, он посылает серверу пакет с флагом RST (закрытие соединения), затем пакет-запрос соединения (этап 2), аналогичный перехваченному по параметрам (порт TCP), но с другим номером последовательности.
3). Получив RST-пакет, сервер прерывает первое соединение. Получив следом от атакующего пакет-запрос, он, используя тот же самый порт, открывает новое соединение с измененным номером последовательности и пошлет клиенту пакет-подтверждение (этап 3).
4). Определив это, атакующий посылает серверу свой пакет-подтверждение (этап 4) и тем самым переводит сервер в состояние установленного соединения.
5). Настоящий клиент, получив пакет от сервера, также переходит в состояние установленного соединения.
Очевидно, что основные равенства не выполняются, и соединение оказывается изначально десинхронизированным. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP- или TELNET-подключение), начать работу с FTP- или telnet-сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь, потеряет связь с сервером из-за рассогласования счетчиков.
Для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров C-ACK и S-ACK, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.
В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений C-ACK и S-ACK является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет, в принципе, защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача получения этих значений не является тривиальной.
Известно, что в большинстве сетевых ОС начальное значение идентификатора TCP-соединения зависит от показаний системного таймера, а именно, является некоторой функцией от числа микросекунд. Но даже приближенно зная эту функцию, злоумышленнику не удается избежать подбора значений. Например, если удалось вычислить значение на операционной системе с точностью до 100, то атакующему для подмены одного из абонентов TCP-соединения достаточно послать 10000 пакетов [40].
Как было замечено выше, для служебных сообщений в ИТКС часто используется передача одиночных сообщений, не требующих подтверждения, то есть не требуется создание виртуального соединения. Атака без установленного виртуального соединения заключается в передаче служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов.
Очевидно, что в этом случае для идентификации пакетов возможно лишь использование статических ключей, определенных заранее, что довольно неудобно и требует сложной системы управления ключами. Однако при отказе от такой системы идентификация пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который легко подделать [31,40].
Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы ИТКС (например, к изменению ее конфигурации).
Возможность реализации атак данного типа обусловлены недостатками сетевого программного обеспечения, в том числе протоколов межсетевого взаимодействия.
Знание содержания возможных атак является существенным фактором при проектировании систем защиты информации в ИТКС и особенно их подсистем, предназначенных для обнаружения таких атак.
Как известно, для обращения к хостам в сети Internet используются 32-разрядные IP-адреса, уникально идентифицирующие каждый сетевой компьютер в этой глобальной сети. Однако, для пользователей применение IP-адресов при обращении к хостам является не слишком удобным и далеко не самым наглядным.
7. Внедрение в сеть ложного DNS-сервера. По мере развития Internet число объединенных в сеть хостов увеличивалось, и данная схема становилась все менее и менее работоспособной, поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название доменной системы имен — DNS (Domain Name System).
Для реализации системы DNS был создан специальный сетевой протокол DNS, для обеспечения эффективной работы которого в сети создаются специальные выделенные информационно-поисковые серверы — DNS-серверы. Поясним основную задачу, решаемую службой DNS. В современной сети Internet хост при обращении к удаленному серверу обычно имеет информацию только о его имени и не знает его IP-адреса, который и необходим для непосредственной адресации. Следовательно, перед хостом возникает стандартная проблема удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением этой проблемы и занимается служба DNS на базе протокола DNS.
Рассмотрим DNS-алгоритм удаленного поиска IP-адреса по имени в сети Internet:
1) хост посылает на IP-адрес ближайшего DNS-сервера (он устанавливается при настройке сетевой ОС) DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти.
2) DNS-сервер, получив запрос, просматривает свою базу имен на наличие в ней указанного в запросе имени. В случае, если имя найдено, а, следовательно, найден и соответствующий ему IP-адрес, то на запросивший хост DNS-сервер отправляет DNS-ответ, в котором указывает искомый IP-адрес. В случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то DNS-запрос отсылается DNS-сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек DNS-сервера, и описанная в этом пункте процедура повторяется, пока имя не будет найдено (или не найдено).
Практические изыскания и критический анализ безопасности службы DNS позволяют предложить три возможных варианта удаленной атаки на эту службу.
В данном случае это удаленная атака на базе стандартной типовой удаленной атаки, связанной с ожиданием поискового DNS-запроса. Перед тем, как рассмотреть алгоритм атаки на службу DNS, необходимо обратить внимание на следующие тонкости в работе этой службы.
Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP) что, естественно, делает ее менее защищенной, так как протокол UDP в отличие от TCP вообще не предусматривает средств идентификации сообщений. Для того, чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию. Кроме того, этот переход несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения, и, кроме того, конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP. И только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP.
Во-вторых, значение поля «порт отправителя» в UDP-пакете сначала принимает значение 1023 и увеличивается с каждым переданным DNS-запросом.
В-третьих, значение идентификатора DNS-запроса ведет себя следующим образом. В случае передачи DNS-запроса с хоста это значение зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос. В том случае, если запрос передается непосредственно DNS-сервером, то сервер увеличивает это значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса.
Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него.
Рассмотрим обобщенный алгоритм реализации атаки «Внедрение ложного DNS-сервера»:
1) ожидание злоумышленником DNS-запроса;
2) извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера;
3) в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени);
4) в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).
Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи атакующему, скорее всего, не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet.
Другой вариант осуществления удаленной атаки, направленной на службу DNS, подразумевает постоянную передачу злоумышленником на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса. Другими словами, атакующий создает в сети Internet направленный шторм ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Критериями, предъявляемыми сетевой ОС хоста к полученному от DNS-сервера ответу, являются:
1) совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера;
2) совпадение имен в DNS-ответе и в DNS-запросе;
3) совпадение номера UDP-порта в DNS-ответе и DNS-запросе (в данном случае это первая проблема для атакующего);
4) совпадение поля идентификатора в DNS-ответе и в переданном DNS-запросе (вторая проблема).
В данном случае, так как атакующий не имеет возможности перехватить DNS-запрос, то основную проблему для него представляет номер UDP-порта, с которого был послан запрос. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений, поэтому атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд, второй проблемой может быть двухбайтовый идентификатор DNS-запроса, но, как подчеркивалось ранее, в данном случае он либо равен единице, либо в случае DNS-запроса от некоторых систем имеет значение близкое к нулю (за один запрос идентификатор увеличивается на 1).
Для осуществления данной удаленной атаки злоумышленнику необходимо выбрать интересующий его хост, маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер — хост атакующего. Это достигается постоянной передачей атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста назначения IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только атакуемый хост обращается по имени к хосту назначения, от данного хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера.
Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS:
1) постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с различными идентификаторами, от имени (с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера — хоста атакующего;
2) в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени — со своего IP-адреса);
3) в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер).
Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами. Данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.
Под мерой защиты информации будем понимать действие или совокупность действий (в т.ч. применение средств) для осуществления защиты информации [3].
Под средством защиты информации будем понимать техническое, криптографическое, программное или другое средство, предназначенное для защиты информации, средства в которых они реализованы, а также средства контроля эффективности защиты информации [3].
Мероприятие по защите информации — совокупность действий по разработке и практическому применению мер и средств защиты информации. Общая классификация мер и средств защиты информации представлена на рис. 2.1.
Рис. 2.1. Общая классификация мер и средств ЗИ
Рассмотрим данную классификацию более подробно.
1. Организационные (административные) меры — это меры, регламентирующие процессы функционирования ИТКС, использование ее ресурсов, деятельность персонала, а также порядок взаимодействия пользователей с системой таким образом, чтобы в наибольшей степени затруднить или исключить возможность реализации угроз ИБ.
Система организационных и организационно-технических мер включает в себя:
— разовые (однократно проводимые и повторяемые только при полном пересмотре принятых решений) мероприятия;
— мероприятия, проводимые при осуществлении или возникновении определенных изменений в самой защищаемой ИТКС или внешней среде (проводимые по необходимости);
— многократно проводимые мероприятия (периодические или стохастические).
К организационным мерам относятся объединения методик и процедур обеспечения безопасности с действиями персонала [9].
2. Программно-технические меры защиты ИТКС соответствуют аппаратному, системному и прикладному уровням системы защиты информации. В процессе ее разработки выполняются следующие группы действий (мероприятий).
На аппаратном уровне (защита технических средств (ТС) обработки информации и ТС защиты), представленном на рис. 2.2, осуществляется:
По направлению защиты от НСД:
— разработка технологий обработки информации с использованием специализированных серверов с ограниченным набором функций и информационных ресурсов (серверы баз данных, серверы приложений, серверы доступа, web-серверы, почтовые серверы, файл-серверы и т.д.);
— планирование минимизации числа устройств копирования данных на внешние носители (сменных винчестеров, оптических дисков, магнитооптики, принтеров и т.д.) в пользовательских компьютерах);
— разработка схем применения ТС разграничения доступа к элементам КС (смарт-карты, биометрические датчики и т.п.);
— проектирование сетевой инфраструктуры с использованием специализированных устройств разделения доступа и трафика (маршрутизаторы, брандмауэры);
— планирование использования активных и пассивных средств защиты от побочных электромагнитных излучений (ПЭМИН) (заземление, экранирование, генераторы шума).
По направлению защиты целостности:
— проектирование системы бесперебойного электропитания;
— планирование установки дублирующих элементов и датчиков рабочих параметров в ключевых и наиболее уязвимых ТС (магнитные диски, источники питания в серверах, датчики температуры и т.д.);
— проектирование физических средств защиты каналов связи (стальные трубы, специальные кабели, короба и т.п.).