Глава 3. Протоколы безопасности и их реализация

Американский национальный институт стандартов и технологии (NIST, National Institute of Standards and Technology) разработал инфраструктуру для кибербезопасности, которая должна реализовываться во всех сторонах сетевых сред и приложений. Эта инфраструктура носит название тирады CIA (confidentiality integrity и availability - конфиденциальности, целостности и доступности). Сама инфраструктура CIA суммирует свои определяемые NIST требования для сетевой безопасности следующим образом:

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

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

Шифрование требует некого алгоритма и ключа. Такой алгоритм это математическая процедура, составленная из последовательности вычислений, в то время как ключ это строка или биты. Чем изощрённее алгоритм и чем длиннее ключ, тем более сложно будет его взломать.

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

На предыдущем снимке экрана можно наблюдать образец видимой и скрытой информации. Здесь мы наблюдаем IP адрес получателя, а также имя сервера в заголовке TLS (Transport Layer Security, Протокола защиты транспортного уровня). В отправляемом позднее в ходе данного сеанса сообщении, как мы видим позднее в данной главе в разделе асимметричных протоколов, мы обнаружим используемые для данного сеанса набор применяемых шифров.

Существует два способа шифрования данных при транспортировке. Как показано на приводимой ниже схеме, это потоковые шифры и блочные шифры:

Шифрование выполняется с применением ключа и алгоритма. Существует два типа шифрования:

Шифрование может быть реализовано для находящихся в состоянии покоя данных, то есть данных, которые хранятся где- то на ПК, смартфоне, центральном сервере и т.п. Также шифрование может реализовываться для передаваемых данных, то есть тех сведений, которые перемещаются по сетевой среде из одного места в другое. В данной книге мы сосредоточимся на сетевой безопасности, а потому в основном будем обсуждать передаваемые данные.

 

Протоколы симметричного шифрования

Первым рассматриваемым нами типом протокола является протокол симметричного шифрования, при котором обе стороны соединения пользуются одним и тем же ключом. Этот ключ может быть неизменным либо может меняться каждую секунду, но всё ещё обе стороны совместно применяют один и тот же ключ. Как отображено на следующем снимке экрана, обычный текст шифруется кодирующей функцией f_E при помощи ключа K^', а затем открывается посредством f_D, а при том что f_E и f_D равны, а потому то же касается ключа K^':

На протяжении лет было разработано много симметричных протоколов. Имеется множество симметричных протоколов, включая RC5 и RC6. Наиболее распространёнными алгоритмами, которые применялись ранее и всё ещё применяются в наши дни для сетевых данных это DES, Triple-DES, который стал распространённым несколько лет назад и AES, который является наиболее безопасным и популярным на протяжении последних лет. Давайте кратко обсудим каждый из них. Они будут пояснены в общем плане с минимальным объёмом необходимых для понимания их механизмов сведений.

 

DES и 3DES

DES (Data Encryption Standard, Стандарт кодирования данных), который был стандартизован в 1979 году это блочный шифр, который представляет собой строки фиксированной длины битов открытого текста, а при помощи ключа и алгоритма преобразует каждую из них в иной битовый поток зашифрованного текста той же длины. Данный алгоритм основан на 16 витках шифрования, причём размеры блока 64 бита, а размеры ключа 56 бит.

Сам алгоритм, имеющий название алгоритма Фейстеля, основан на отражаемом в приводимой ниже схеме принципе:

Данный алгоритм работает следующим образом:

Будучи разработанным в 1970- х годах протоколом, DES представляет собой запросто взламываемый механизм шифрования и в последние годы он практически не применяется.

Triple-DES, или 3DES, это алгоритм, который был разработан в середине 1990- х и опубликован IETF как RFC 1851. 3DES пользуется тем же самым алгоритмом DES, но с тремя ключами. Ключи могут быть независимыми, K₁, K₂ и K₃ (вариант ключей 1), K₂ и K₁ = K₃ (вариант ключей 2) и идентичными ключами K₁ = K₂ = K₃ (вариант ключей 3).

Хотя 3DES работает с ключами из 112 или 168 бит (56*2 или 56*3 бит, в зависимости от варианта выбора ключей), применение 3DES также подвержено лёгкому взлому. По этой причине был принят новый алгоритм: AES.

 

AES

NIST (National Institute of Standards and Technology) выбрал алгоритм Rijndael (Райндейл, разработанный Джоаном Дейманом и Винсентом Райменом) в качестве последователя DES и 3DES в ноябре 2001. AES обладал фиксированным размером блока в 128 бит с размерами ключа в 128б 192 и 256 бит и пользуется алгоритмом, который намного более сложен чем алгоритм Фейстеля:

Как вы можете видеть, имеющийся в AES алгоритм работает следующим образом:

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

 

Протоколы не обладающего симметрией шифрования

В не обладающих симметрией протоколах у нас имеются два ключа: один применяется для шифрования собственно данных, в то время как другой ключ используется для их дешифрации. Тот ключ, который применяется для шифрования данных носит название общедоступного ключа (public key), в то время как используемый для дешифрации этих данных ключ именуется частным ключом (private key). Это также известно как криптография с общедоступным ключом (public key cryptography).

Как это отражено на идущей далее схеме, криптография с общедоступным ключом применяется двумя способами:

 

Шифрование данных

Данный шифруются так:

Давайте рассмотрим это подробнее:

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

 

Цифровые подписи

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

В нашем примере Алиса отправляет удостоверенный документ Бобу:

При помощи цифровых подписей мы выполняем следующее:

 

Протоколы не обладающего симметрией шифрования и RSA

Применяется множество не обладающих симметрией алгоритмов: RSA (Rivest-Shamir-Adleman), ECC (El Elliptic Curve Cryptography), El Gamal, DSA (Digital Signature Algorithm) и прочие. В данном разделе мы обсудим алгоритм RSA, который до сих пор применяется коммерческими алгоритмами.

Данный алгоритм RSA основывается на том математическом принципе, согласно которому легко умножать большие числа, но гораздо сложнее делить их на множители. Это в особенности верно когда мы умножаем два простых числа. Умножить их просто, но получить множители результата практически невозможно и требует огромных вычислительных мощностей.

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

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

PKI (Public key infrastructure, инфраструктура шифрования с открытыми ключами) определяет необходимую архитектуру для безопасного взаимодействия между пользователями. PKI определяет CA (certificate authority, центр сертификации), который содержит некоторые атрибуты, которые будут применяться между устанавливающими соединение пользователями.

PKI предоставляет несколько услуг:

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

PKI в основном применяется для соединения с веб серверами при помощи Secure Socket Layer/ Transport Layer Security (SSL/ TLS). В данном разделе мы опишем данный процесс, а затем в этой главе, в разделе SSL/ TLS и посредники мы перейдём к битам и байтам.

Для начала давайте рассмотрим как клиент подключается к веб серверу при помощи сертификатов. Это иллюстрирует следующая схема:

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

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

Удостоверение подлинности (аутентификация) это процесс идентификации персоны, устройства или программного обеспечения для получения ими доступа к сведениям. Получение разрешения (авторизация) это процесс обеспечения прав для выполнения действий над данными или сведениями.

Существует три типа механизмов удостоверения подлинности. А именно, то, что вы знаете, то, чем вы обладаете и кем вы являетесь:

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

Существует несколько уровней аутентификации; в этом разделе мы рассмотрим каждый из них, причём совместно с их уязвимостями.

В данном разделе мы обсудим типы аутентификации от базовых до усовершенствованных методов.

 

Идентификация имя пользователя/ пароль и проблема

Самым базовым типом установления подлинности являются имя пользователя и пароль. Данный метод является предметом для целого ряда видов атак. PAP (Password Authentication Protocol, протокол аутентификации по паролю) это пример протокола, который реализует такой метод, когда инициализирующее устройство отправляет запрос на удостоверение подлинности с именем пользователя и паролем, а аутентификатор (отвечающее устройство) просматривает их и отправляет сообщение подтверждения аутентификации или отказа в ней.

Другим протоколом в этой категории выступает CHAP (Challenge Handshake Authentication Protocol, протокол аутентификации с предварительным квитированием соединения), применяющий рукопожатие в три этапа. Здесь, по завершению фазы установления соединения, устройство аутентификации (то есть то одноранговое устройство, которое разрешает или блокирует доступ) отправляет инициатору сообщение Challenge (запроса квитирования). Этот инициатор откликается строкой, которая содержит значение, вычисляемое при помощи хэш- функции. Аутентификатор проверяет равен ли этот отклик его вычислению такой строки. Когда значения совпадают, данная аутентификация принимается; в противном случае нет.

Эти два протокола впервые были стандартизованы в RFC1334 (IETF, октябрь 1992) для PPP (Point-To-Point Protocol, протокола канала связи с непосредственным соединением) Уровня 2, который в основном применялся для установления соединения между маршрутизаторами.

Имеющийся уровень безопасности данного протокола очень низок. PAP является предметом взлома пользователя/ пароля, в то время как CHAP это предмет для простой атаки со злоумышленником в промежутке. Эти протоколы в основном применялись для непосредственного соединения маршрутизаторов и почти не используются.

Удостоверение подлинности по имени пользователя и пароля можно продвинуть на шаг вперёд, применяя имя пользователя и пароль совместно с ограничениями на исходный IP адрес с которого может поступать запрос на регистрацию. Хотя этот метод и обладает слегка более высоким уровнем безопасности, вам следует применять его с осторожностью.

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

Настройка вашей "огненной стены" для разрешения доступа из Интернета на основании имени пользователя/ пароля и IP- адреса это всё равно как сунуть свою руку в огонь в надежде что тот потухнет. Если кто- то пожелает взломать систему, подделка IP адреса со взломом имени пользователя/ пароля запросто справится с этой задачей. Далее в этой книге мы подробно опишем атаки с подменой IP адреса.

Это наиболее распространённый способ доступа организаций или общедоступный серверов (банков, социальных сетей и тому подобного) и на один шаг ниже чем OTP (one-time passwords, одноразовые пароли) или биометрия.

Здесь для соединения клиента с площадкой мы пользуемся таким протоколом как IPSec, что происходит когда ваш компьютер становится клиентом вашей организации, либо соединения SSL/TLS, что происходит при подключении к приложению - например, HTTPS для доступа к веб серверу, Secure FTP при доступе к серверу FTP, SIPS для безопасного доступа к серверам SIP (Session Initiation Protocol, протокола инициации сеанса) и так далее.

Следующим уровнем безопасности выступает применение OTP. Существуют две версии OTP, которые основаны на одном и том же принципе:

 

HOTP

Первый метод, именуемый HOTP (HMAC-based OTP), впервые был стандартизован в RFC4226 (IETF, December 2005). Этот метод применяет маркеры, которые синхронизируются с имеющимся сервером для предоставления под предоставление пользователю доступа в сетевую среду одноразового пароля. Такой пароль может применяться однократно, а потому он прекращает возможность атак отклика. HOTP вычисляется следующим образом:

HOTP(key,counter)=Truncate(HMAC-SHA-1(key,counter))
 	   

Вот значения параметров из этой формулы:

Функция отсечения (truncate) применяется для отсечения полученных 160 бит HMAC-SHA-1 в читаемый пользователем формат из некоторого числа цифр.

При использовании HOTP существует ряд проблем. Данный протокол подсчитывает значение числа успешных попыток аутентификации, а что относительно варианта с неудачными попытками? Эти вопросы рассматриваются имеющимся стандартом и для каждого из них предлагаются решения.

 

TOTP

Второй метод носит название TOTP (time-based one-time password, основанных на времени одноразовых паролей), и впервые он был стандартизирован RFC6238 (IETF, May 2011) как расширение HOTM. Он пользуется для вычисления значения OTP тем же алгоритмом что и HOTP, однако вместо применения некого счётчика он применяет таймер. Итак, TOTP вычисляется так:

TOTP(key,time)=Truncate(HMAC(key,time))
 	   

В TOTP применяемым алгоритмом хэширования может выступать HMAC-SHA-1, HMAC-SHA-256 или HMAC-SHA-512. Значение времени исчисляется 30- секундными приращениями в результате значения времени эпохи (числа секунд, прошедших с полуночи UTC - всемирно скоординированного времени - 1 января 1970 года).

TOTP устраняет проблемы со счётчиком, которые имелись у HOTP, но к нему также имеется ряд вопросов. В случае аппаратных маркеров TOTP (в отличие от программных маркеров, которые пользуются часами смартфона) нам необходимы возможности исчисления времени, для чего требуется внутренний точный осциллятор, причём могут происходить смещения по времени и тому подобное. Эти проблемы рассматриваются в самом стандарте и для каждой предлагается решение.

 

OTP на основе SMS

Данный метод прямолинеен. Здесь пользователь регистрируется в соответствующем вебсайте под своими именем пользователя и паролем. В случае совпадения имени пользователя и пароля, данный пользователь получает некий OTP через SMS или сообщение электронной почты. Пользователь вводит данный OTP и осуществляет регистрацию в этом вебсайте. Вместо имени пользователя и пароля это может быть идентификатор пользователя или номер паспорта, последние цифры номера кредитной карты, находящейся во владении этого пользователя и тому подобное. Именно это составляет метод двухфакторной аутентификации, которая применяет сочетание того что вы знаете с тем, чем вы владеете.

EAP (extensible authentication protocol, Расширенный протокол аутентификации) это стандарт, который предоставляет некую инфраструктуру, содержащую набор вещей, необходимых клиентам для их удостоверения с сетевыми серверами аутентификации, например, подключаемого по сети Wi-Fi ноутбука. Такая инфраструктура EAP составляется из необходимого метода и соответствующих требований, в то время как протокол аутентификации может выбираться самим выполняющим удостоверение клиентом и динамическим образом осуществляет механизм аутентификации.

EAP впервые был предложен в RFC2284 (IETF, March 1998) для протокола точка- точка для добавления безопасности поверх имевшихся (на тот момент) PAP и CHAP. Позднее он был расширен в RFC3748 (IETF, June 2004). С тех пор он был реализован в других отраслях, в основном, в беспроводных сетях и беспроводных локальных сетях с применением протоколов IEEE 802.11i и 802.1x.

 

Протоколы EAP

IETF выполнила стандартизацию на основе нескольких основанных на EAP методов:

Благодаря своей гибкости EAP был приспособлен более поздними стандартами, например, интеграции LTE с Wi-Fi (RFC7458, IETF, February 2015), (EAP-TTLS, который делает для вас возможными туннели в прочих протоколах аутентификации поверх туннелей EAP (RFC5281, IETF, August 2008), а также в частных реализациях и прочих стандартах и закрытых реализациях, таких как LEAP (Lightweight EAP) и EAP-FAST (Flexible Authentication via Secure Tunneling EAP) Cisco, PEAP (Protected EAP) Microsoft, EAPoL (EAP over LAN), который применяется при управлении доступом в сетевых средах на основе портов в локальных сетях (IEEE, 802.1X) и прочих.

EAP-AKA и EAP-SIM применяют аутентификацию типа запрос- ответ (например, CHAP), а EAP-TLS, EAP-TTLS, PEAP и EAP-FAST пользуются аутентификацией TLS.

 

Архитектура EAP

Собственно архитектура EAP основывается на рёх логических элементах:

Сама процедура EAP иллюстрируется приводимой ниже схемой:

Это пример из сетевой среды Wi-Fi. Клиент (именуемый peer, одноранговым устройством) подключается к соответствующей сети. Имеющийся контроллер Wi-Fi (который, совместно со своей точкой доступа устанавливает аутентификацию EAP) определяет нового клиента и отправляет запрос на идентификацию EAP (1). Клиент отвечает откликом идентификации EAP (2), а соответствующий контроллер переправляет этот отклик своему серверу аутентификации (3). Сервер аутентификации отправляет запрос типа EAP в аутентификатор (4), который переправляет его клиенту (5). Этот запрос типа EAP является запросом от сервера, сообщающим значение типа аутентификации сервера. Если клиент его поддерживает, он отвечает откликом типа EAP, подтверждая данный тип аутентификации (6), а аутентификатор переправляет его своему серверу (7). На данном этапе клиент и сервер пришли к согласию о соответствии запрошенного метода аутентификации (TLS, TTLS и тому подобного) (8), а раз достигнуто согласие, сервер отправляет сообщение успешности EAP в аутентификатор (9), который переправляет его соответствующему клиенту (10). При этом данный клиент осуществляет регистрацию и подключается к этой сетевой среде.

Как мы видели в своём предыдущем разделе, аутентификация ответственна за проверку подлинности пользователя, подтверждения того кем он является и на самом ли деле он является тем , за кого себя выдаёт. Авторизация сочетает персональные сведения со сведениями доступа чтобы разрешать этому пользователю считывать, записывать, исполнять или удалять файлы и информацию на основе его персональных данных и полномочий.

Устройства NAC (Network access control, Сетевого контроля доступа) применяются для обеспечения соблюдения политик сотрудничества. Функции и возможности NAC будут обсуждаться в самом последнем разделе этой главы, Компоненты сетевой безопасности - RADIUS/TACACS+, FWs, IDS/IPS, NAC и WAF.

Аутентификация сообщений применяется для следующих целей:

Функция хэширования это принимающая на вход блоки произвольной длины функция и производящая на выходе хэш значение фиксированного размера. Такой результат вычисления функции хэширования носит название MAC (message authentication code, кода аутентификации сообщения).

Функции хэширования применяются для проверки целостности данных. Вот некоторые применения хэшей:

Функция хэширования обязана поддерживать два параметра:

На приводимой ниже схеме отображён простой механизм хэширования, применяемый лишь для проверок целостности соощения:

Здесь мы можем наблюдать что наш отправитель для добавления в своё сообщение свёртки сообщения пользуется функцией хэширования. Это сообщение отправляется к его получателю, который выделяет полученную свёртку из изначального сообщения и вычисляет её снова. Когда значение полученной свёртки равно вычисленному значению, данное сообщение принимается. В случае их отличия данное сообщение отбрасывается.

В случае применения значения хэша для шифрования, как это отражено на следующей схеме, при использовании шифрования это тот же самый механизм, что и при шифровании/ дешифрации:

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

Наиболее распространёнными функциями хэширования являются MD5 (Message Digest 5, 5 свёртка сообщений) и SHA1 (Secure Hash Algorithm 1, 1 алгоритм безопасного хэширования). MD5 впервые был стандартизован в RFC1321 (IETF, April 1992). MD5 вырабатывает свёртку в 128 бит. SHA1 впервые был стандартизован NIST (National Institute of Standards and Technology) США и создаёт 160- битные свёртки. Хотя после MD5 и SHA1 были разработаны более искусные и более безопасные алгоритмы, например, SHA2, SHA3 и прочие, MD5 и SHA1 всё ещё наиболее распространённые в коммерческих реализациях стандарты хэша.

IPSec это набор протоколов, разработанный для предоставления функциональных возможностей VPN (Virtual Private Network, виртуальной частной сети). Прежде чем изучать сам протокол, мы обсудим типы и возможности соединения VPN. Впервые IPSec была стандартизована в RFC 2401 (IETF, November 1998), а позднее превратилась в абсолютный стандарт в RFC 4301 (ISTF, December 2005) и обновлялась в прочих RFC.

IPSec предоставляет такие услуги:

VPN это некий способ установления виртуального соединения поверх общедоступной инфраструктуры. Обычно установление виртуального соединения достигается туннелированием, которое является очень распространённым механизмом при взаимодействии данных, когда внутренний пакет внедряется в некий внешний заголовок, переносящий его через имеющуюся общедоступную сетевую среду. Приводимая ниже схема отображает пример внедрения простого туннеля:

Здесь мы можем наблюдать два подключённых к Интернету маршрутизатора. Слева у нас имеется хост 10.33.1.18, в то время как справа у нас расположен хост 10.33.13.32. Мы создаём между своими двумя маршрутизаторами туннель и адресами этого туннеля выступают 172.32.1.1 для нашего левого маршрутизатора и 172.32.1.2 для правого.

Как это отражено на схеме ниже, которая является файлом перехвата Wireshark, первым появляющимся моментом выступает внешний заголовок. Справа, после соответствующего заголовка Ethernet, он переносится заголовком туннеля - в нашем примере заголовком туннеля GRE (Generic Routing Encapsulation) - а затем следует внутренний IP заголовок со значениями адресом туннеля.

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

В своём примере верхнего пакета (1) мы можем видеть не зашифрованный обмен с внешними IP адресами F1 и F2. Это внешние адреса наших межсетевых экранов. Значения внутренних адресов совпадают с адресами ПК с обеих сторон, то есть A и B.

В примере нижнего пакета (2) мы наблюдаем что наш внутренний заголовок и данные скрыты, как это и должно быть при обмене через Интернет, причём единственное что обнаружит перехватчик это значения адресов межсетевых экранов. Основной целью IPSec выступает создание такого туннеля.

Как это отражено на идущей следом схеме, существует три способа применения IPSec:

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

IPSec обладает тремя этапами операций:

В своём следующем разделе мы более подробно взглянем ни эти три этапа.

Прежде чем переходить к обмену поверх IPSec, два одноранговых партнёра устанавливают безопасный канал. Он предоставляется протоколом с названием IKE (Internet Key Exchange, обмена ключами через Интернет), также именуемого ISAKMP (Internet Security Association and Key Management Protocol, протоколом ассоциации безопасности Интернета и управления ключами).

Протокол IKE применяется для установления туннеля IPSec между двумя одноранговыми партнёрами и работает в три этапа.

Самым первым этапом выступает согласование (negotiation). Этот этап инициализируется тем одноранговым партнёром, который желает отправлять данные другой стороне. На этом этапе согласовываются такие параметры:

Вторым этапом выступает обмен ключами. После этапа согласования, наши два одноранговых партнёра выполнят обмен ключами. К окончанию данного этапа эти два одноранговых партнёра будут обладать совместными ключами.

Третьим этапом является аутентификация. На данном этапе два одноранговых партнёра идентифицируют друг друга при помощи того метода аутентификации, о котором договорились на этапе 1.

IPSec обладает двумя режимами действий: режимом туннеля и режимом транспортировки.

В аутентификацию и целостность вовлекаются протоколы AH и ESP:

Приведённая ниже схема показывает структуру пакета для Режима транспортировки AH и для Режима туннеля AH. При данных режимах действия IPSec реализует лишь аутентификацию для вычисления функции хэширования над всем пакетом целиком:

Заголовок AH содержит следующие поля: следующий заголовок, для указания на протокол самого верхнего уровня (например, TCP или UDP); длину для указания значения длины заголовка AH; SPI (Security Parameters Index, индекса параметров безопасности) для указания того потока, к которому относится данный пакет, Порядок, которым является порядковый номер для защиты от атак воспроизведения; и ICV (Integrity Check Value, значение проверки целостности), которым выступает значение хэша.

Следующая далее схема показывает установленную структуру в Режиме транспорта ESP и в Режиме туннеля ESP. В этих режимах работы IPSec реализует аутентификацию и шифрование для вычисления функции хэширования над всем пакетом целиком и шифрования самого пакета:

В режиме транспорта ESP мы добавляем заголовок и хвост ESP. Для IP и всего что выше (то есть для Уровня 3 и выше, включая TCP/ UDP и протокол приложения) предоставляется шифрование.

SSL (Secured Socket Layer, Протокол защиты сокетов) и его преемник TLS (Transport Layer Security, Протокол защиты транспортного уровня) это протоколы, которые применяются для шифрования более верхних уровней. Эти протоколы работают поверх порта 443 TCP или UDP для доступа к веб страницам безопасным HTTP (HTTPS) поверх порта TCP 443 и для доступа к устройству Google при помощи порта 443 UDP с применением протокола QUIC/GQUIC.

SSL был впервые предложен Netscape в 1994 и стандартизован как TLSv1 в RFC 2246 (IETF, January 1999), TLSv1.1 в RFC 4346 (IETF, April 2006), TLSv1.2 в RFC 5246 (IETF, August 2008) TLSv1.3 в RFC 8446 (IETF, August 2018).

Обычным применением для TLS является предоставление безопасного взаимодействия между клиентом и сервером (одноранговыми партнёрами) при обеспечении таких услуг:

TLS составляется операциями двух этапов:

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

Следующая схема показывает эти переговоры целиком:

Здесь мы можем наблюдать в пакетах с 1 по 3 открытие соединения TCP, установление согласия по SSL в пакетах с 4 по 12 и то, что в пакетах с номерами от 13 и выше начинается передача обмена.

Самые первые два пакета при согласовании это Client Hello и Server Hello, которые применяются для установления возможностей безопасности между этими двумя одноранговыми партнёрами. Давайте взглянем на самый первый пакет при рукопожатии TLS, которым выступает пакет 4 - Client Hello Эти клиент и сервер приходят к согласию по версии протокола, комплекту шифрования, идентификатору сеанса и методу завершения:

Эти клиент и сервер также вырабатывают два контрольных слова (nonces, в предыдущей схеме RND) и обмениваются ими.

Вслед за сообщением Client Hello сервер отвечает Server Hello. Это отражено на следующей схеме:

В сообщении Server Hello мы можем видеть, что комплектом криптографии выступает AES-256 с SHA-384 и что согласованной версией является TLSv1.2, причём без сжатия.

В нашем следующем пакете, как это показано на схеме ниже, от данного сервера к его клиенту отправляется сертификат. Этот пакет носит название Certificate, Server Key Exchange, Server Hello Done:

Здесь мы можем наблюдать, что наше сообщение TLS содержит три части: Certificate, которая содержит сертификат из 1 592 байт, Server Key Exchange, содержащую значение алгоритма подписи и соответствующий общедоступный ключ, а также Server Hello Done, который указывает конец этих сообщений сервера.

Наш следующий пакет, как это отображает приводимая ниже схема, это Client Key Exchange. В данном пакете, когда применяется RSA, клиент отправляет для выработки симметричных криптографических ключей секрет предварительного хозяина и шифрует им соответствующий общедоступный ключ сервера. Этот клиент также отправляет сообщение Change Cipher Spec и сам клиент копирует такую ожидающую рассмотрения Спецификацию шифра в свою текущую Cipher Spec:

На данном этапе согласование устанавливаемого сеанса выполнено, но могут иметься и дополнительные сообщения, в особенности в последующих версиях TLS.

В нашем примере, как показывает следующая схема, мы можем наблюдать сообщение New Session Ticket:

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

SSL/ TLS также применяется при шифровании прочих протоколов, например, S-FTP (Secure File Transfer Protocol, протокол безопасного обмена файлами), SSH (Secure Shell, безопасной оболочки) для удалённого подключения к коммуникационным устройствам, SSIP (Secure SIP, безопасного протокола инициации сеанса) и SRTP (Secure RTP, безопасного транспортного протокола реального времени) для безопасности сеансов телефонии и мультимедиа. Позднее в данной книге мы обсудим эти протоколы.

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

Межсетевые экраны предлагают следующие функциональные возможности:

Помимо этого, большинство современных межсетевых экранов способны обеспечивать дополнительные механизмы, зависящие от лицензирования:

Межсетевые экраны составляют основу защитных сетевых устройств во всякой сетевой среде и они могут применяться в различных местах:

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

RADIUS (Remote Authentication Dial In User Service, служба дистанционной аутентификации подключаемых по коммутируемым линиям пользователей) была определена в RFC 2138 (IETF, June 2000). RADIUS была проиллюстрирована ранее в этой главе на Рисунке 3.9. Сервер RADIUS реализует AAA - authentication, authorization, and accounting (аутентификацию, авторизацию и ведения учёта).

Поскольку RADIUS происходит из 2000х, существуют новые заменяющие его службы, а наиболее популярными являются TACACS+ и Diameter. Хотя RADIUS всё ещё широко применяется для предоставления услуг AAA.

WAF (Web application firewalls, межсетевые экраны веб приложения) были созданы для защиты от проистекающих от веб серверов уязвимостей, таких как внедрение SQL, межсайтовые сценарии, подделка межсайтовых запросов, DNS атаки и многое иное. Общим знаменателем таких атак выступает применение действий пользователя для внедрения вредоносного кода в его конечное устройство или применение DNS атак для перенаправления пользователей на вебсайты, которые будут внедрять такой вредоносный код.

При межсайтовых атаках, которые обычно носят название XSS (cross-site scripting), для просмотра применяется веб сервер. Затем этот веб сервер внедряет вредоносный сценарий в оконечное устройство (ПК, ноутбук и тому подобное).

SQLi (SQL injection, внедрение SQL) это атака, которая пытается внедрить в SQL приложение команды языка SQL для изменения содержимого базы данных.

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

В отличии от основной функциональной возможности межсетевого экрана, которая разрешает или блокирует обмен в зависимости от его источника, получателя и направлений, а также от IDS/IPS которая выявляет вредоносные шаблоны в простых веб- фильтрах, перенаправляющих или блокирующих обмен с определённых веб- сайтов, WAF просматривают содержимое самих веб приложений и фильтруют запускаемый ими код, а потому они применяются дополнительно к прочим механизмам защиты.

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

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

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

Для проверки знаний данной главы ответьте на следующие вопросы: