Блог

Регламенты и формальности в ИБ

• Цветков Максим
• 12.10.2021

Регламенты и стандарты

Существует великое множество ассоциаций и стандартизирующих организаций: IEEE, IEC, ISO, ITU-T, ANSI, IETF, Broadband Forum, Metro Ethernet Forum. Они все пишут стандарты для индустрии ИБ. Но эти стандарты не всегда дополняют друг друга, так, IETF не соблюдает требования стандарта ISO OSI.

Одним из самых популярных стандартов является ISO 27001. Полное руководство по успешному внедрению ISO 27001 читать долго, хоть и полезно, но необходимо знать базовые 7 шагов по первичному внедрению ИБ в организации:

• Определите методологию оценки рисков.
• Составьте список ваших информационных активов.
• Определите угрозы и уязвимости.
• Оценить риски.
• Смягчить/делегировать риски.
• Составлять отчеты о рисках.
• Проводить обзор, мониторинг и аудит.

Требованием стандарта ISO 27001 является обеспечение адекватного уровня ресурсов для создания, внедрения, поддержания и постоянного улучшения системы управления информационной безопасностью. Какова основная роль стандарта ISO/IEC 27002, он же ISO IEC 17799? Он предоставляет каталог лучших практик контроля, каждую из которых необходимо учитывать по стандарту ISO/IEC 27001 при разработке СУИБ (ISMS). Также, в ISO/IEC 27001 прописано требование о приверженности высшего руководства к обеспечению безопасности в компании. Общая идея: департаменты работают сообща, внедрена система оценок, налажено общение с контрагентами и партнерами, сотрудники уделяют внимание вопросам безопасности. Вам нужны процессы, их поддержка сверху и, самое главное, понимание того, зачем компания это делает.

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

• Политика — это высокоуровневое изложение ценностей, целей и задач организации в конкретной области, а также общего подхода к их достижению. Несмотря на то, что политика должна регулярно пересматриваться, она должна действовать в течение некоторого времени, поскольку не предназначена для предоставления подробного или конкретного руководства по достижению этих целей. Например, в политике может быть указано, что каждый пользователь отвечает за создание и поддержание своих системных паролей — хотя в ней не говорится, как именно это делать. Политики являются обязательными.
• Стандарт является более предписывающим документом, чем политика. Он определяет количественные параметры того, что должно быть сделано, и обеспечивает последовательность в контроле, который можно измерить. Например, пароли должны содержать минимум восемь символов, состоять из цифр, букв и специальных знаков и меняться в случае взлома или по другим подобным причинам. Соблюдение стандартов также является обязательным. Они должны поддерживать политику и определять, что «должно» быть сделано и как это должно быть достигнуто. Стандарты могут быть как общими (например, работа с конфиденциальной информацией), так и техническими (например, шифрование данных), но они всегда должны относиться к конкретной теме.
• Процедура — это набор подробных рабочих инструкций, описывающих, что, когда, как и кем должно быть сделано. Опять же, они являются обязательными и должны поддерживать политику и стандарты предприятия.
• Гайдлайны не являются обязательными, но могут служить советом, руководством и лучшей практикой в тех случаях, когда зачастую трудно регламентировать, как что-либо должно быть сделано (например, практика работы вне офиса).

Также, существует документ Statement of Applicability (SoA), который в рамках ISO 27001:2013 формулирует рекомендации по оценке и обработке рисков, а значит, полезен при подготовке ISMS (Information Security Management). ISMS не требует установки какого-то конкретного софта, но требует поддержку инициатив от менеджмента в реализации ИБ-политик.

Но что такое риск? Есть множество вариантов ответа, но скажем, что риск = вероятность * влияние. Риск не может быть просто убран, но его можно избегать, сокращать вероятность наступления, передавать/делить ответственность с контрагентами. Например, всем специалистам известно, что сертификаты X.509 обладают уязвимостями, пусть и не фундаментальными, основные проблемы связаны с методом использования. По ISO/IEC 27000 это потенциальная угроза. То, что потенциально может произойти. А уязвимость это слабое место в защите, которое можно эксплуатировать один или несколько раз. Комбинация этих двух факторов формируют риск = слабое место в защите.

Если риск наступил, то становится ли это событие инцидентом? Что такое инцидент? Инцидентом может являться попытка получить несанкционированный доступ к системе и/или к данным, несанкционированное использование систем для обработки или хранения данных, изменения в микропрограмме, программном или аппаратном обеспечении системы без согласия ее владельца, злонамеренное нарушение работы и/или отказ в обслуживании. Для нас результат один: необходимо собрать доказательства для суда. Этим занимается Incident Response Team (IRT) — эта команда должна обладать поддержкой руководства, и получить все нужные ресурсы для быстрой работы с инцидентом. Если заранее разработаны правила для детектирования TTPs (tactics, techniques, procedures) различными технологиями — отлично.

Стандарты предписывают правила. Такие правила могут существовать в организации де-факто, другими словами, они уже работают в организации, но не одобрены юридически. Либо De jure — прилетело требование закона о соответствии определенному стандарту. В этот момент начинается процесс сертификации, который включает 3 шага: предварительный, то есть отправка базовой информации, далее сама проверка на соответствие ISO/IEC 27001, и получение сертификации. ISO/IEC 27001 описывает, какие шаги необходимо предпринять для соответствия ISMS. Описание весьма поверхностное, детали мы всегда ищем в ISO/IEC 27000. Верхнеуровневые шаги: контекст организации -> лидерство -> планирование -> поддержка -> оперирование -> оценка производительности -> улучшение. Вопреки ожиданиям, стандарты ISO/IEC 27002 и ISO/IEC 27001 имеют весьма разные цели. Первый только про лучшие советы. Это неплохие инструкции, и более того, IEC считает, что противостоять DDoS можно с помощью сертификации бизнес-процессов по ISO/IEC 27001/27002. В целом, если вы придерживаетесь подходов leading tech компаний, то с высокой вероятностью вы соответствуете стандартам de-facto.

Помимо описанных, существуют и другие стандарты:

• такие как ITF, чьи подходы сильно отличаются от IEC и ISO. Последние не публикуют черновики, что не удивительно, ведь доступ к IEC и ISO платный. Это позволяет защитить источник дохода для национальных органов-членов IEC и самой ISO.
• 3GPP создает стандарты для мобильных телефонов, от 2G до 5G.
• GPRS и GPS также стандарты, изначально были европейскими стандартами.
• NIST SP 800-53 без сертификации, под федеральные системы штатов. Много хороших практик для индустриалки.
• PCI DSS был изначально сделан только под штаты, но все понимают, что законодательство штатов влияет на весь мир. Влияет на условия хранения данных банковской карты и безопасность платежей.
• HIPAA и HITRUST — для медицины.
• Также ISO 31000 гайдлайны по риск-менеджменту. Включает правила risk assessment — идентификация риска, умение понять, что защищать и от чего, насколько этот риск может произойти. И стоит ли защищать.
• Стандарт ISO/IEC JTC 1/SC 27 и его подраздел ISO/IEC 27000, их можно разделить на категории, особенно SO/IEC 27001.
• ITU-T X.509 который был опубликован как ISO/IEC 9594-8, полезен для сертификации публичных ключей.

Для разработки стандартов формируются рабочие группы, они обозначаются как WG и работают над конкретным доменом:

• WG1 — сетевые услуги
• WG2 — криптография
• WG3 — оценка и тестирование безопасности
• WG4 — безопасность сети
• WG5 — приватность
  

Перекладываем стандарты на сеть

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

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

Базово, интернет работает на принципу пересылки пакетов, и приложения работают на конечных хостах. Но в современном интернете приложения уже сами могут решать, как и куда пересылать пакеты. Название этому гибриду — оверлейные сети. Это своего рода туннелинг из привычного нам VPN. Хост физически у нас один провод, но виртуально устройство соединено с множеством других устройств через тунелирование. Что само по себе сложно регламентировать стандартами.

Существует иерархия Расмуссена: позволяет взглянуть на безопасность под разными углами, и абстрактно, и с прикладной точки зрения. Если вы больше про прикладной уровень, то это component-driven risk management. Может включать в себя аппаратное обеспечение (компьютеры, серверы и т.д.), программное обеспечение, наборы данных, личная информация, критически важная информация, персонал. Поверх нужно накладывать слой знаний про ZTN, ZTNA, ZTA — концепции реализации нулевого доверия. На прикладном уровне стандарты весьма неоднозначны по понятным причинам. Взять Presentation Layer, в котором данные из удобочитаемого вида превращаются в нечто, что можно передать по сети. Разумеется, можно встретить разные стандарты или отсутствие стандартов.

В рамках технической реализации, все упирается в LAN (Local Area Network). Сеть в минимальном виде это ваши два компьютера, которые соединены проводом. Это весьма надежное соединение, информацию в проводе проще защитить. Самая простая атака на такую сеть — обрезать провод, или украсть роутер. Или вмешаться в трафик, подключив личное устройство, перехватывать трафик, подделывать и модифицировать сообщения. Проводом можно соединить два компьютера у себя дома, но если речь о длинных расстояниях, то SONET долгое время был стандартом для передачи данных на длинные расстояния. Вроде все просто, пока не добавляются протоколы, и даже простой HTTP состоит из:

• HTTP предоставляет глобальные идентификаторы объектов (URI) и простой интерфейс GET/PUT.  
• TLS обеспечивает сквозную безопасность связи.
• TCP обеспечивает управление соединениями, надежную передачу и контроль перегрузки.
•  IP обеспечивает глобальные адреса хостов и уровень абстракции сети.

Начнем с TCP, это самый популярный протокол передачи данных, и весьма надежный. В сердце протокола живет sliding window, в котором участвуют Acknowledgment, SequenceNum и AdvertisedWindow. Рекомендуемый MSL = 120мс. Пакетики могут немного перетосоваться, но в итоге они встают в нужный порядок. Можете поиграться на своей компьютере командой netstat -nap, посмотреть статистику по протоколу. Либо использовать Nginx для реализации TCP/UDP прокси-сервера общего.

Указано ли все это в стандартах? Так как протоколы OSI никогда не были популярны, да и полного стека не было, то в итоге победил мир TCP/IP. Эталонную OSI модель создала ISO, а протокольный стек TCP/IP был создан IETF. TCP и UDP это протоколы созданные IETF, и к ISO/OSI они отношения не имеют. Если критиковать OSI, то в реальном мире не существует канального уровня, есть только MAC и LLC. Сетевой уровень есть, но он отличается от описания OSI. HTTP является протоколом прикладного уровня по OSI. Также, по документации Cisco, Base64 является механизмом представления. Если мы передаем PNG файл по HTTP, то он кодируется в Base64 выше HTTP, в то время как по модели OSI должен быть ниже. Поэтому TCP/UDP это протоколы по умолчанию. Предшественником TCP был SSL.

Модель OSI	Модель	Протокол
Прикладной	Прикладной	http, ftp
Уровень представления	Прикладной	http, ftp
Сеансовый уровень	Прикладной	http, ftp
Транспортный уровень	Транспортный	TCP, UDP, SCTP
Сетевой уровень	Межсетевой	IPv4, IPv6
Канальный уровень	Канальный	Ethernet, WiFi
Физический уровень	Канальный	Ethernet, WiFi

UPD позволяет доставлять сообщение от хоста к хосту. UPD отправляет данные и надеется, что все дойдет до получаетя. Никакого пожатия рук, просто отдает данные. Что делает его полезным при работе DNS, SNMP, HTTP/3.

Помимо протоколов, существуют и физические ограничения. Сотрудникам нужна хорошая скорость интернета. Давайте рассчитаем задержку передачи данных в сети для 1 Гб/сек с одним свитчем store-and-forward, и размеры пакетиков по 5 000 бит. Пусть каждое соединение вносит задержку 10 μs. Так, для каждого канала связи 1 Гб / 5 кб = 5 μs задержка пакета, и 10 μs для последнего бита. Общая задержка будет 30 μs. Усложним задачу и теперь у нас три свитча, а значит 4 канала. Это 4 задержки передачи и 4 задержки распространения, это будет 60 μs.

Другая задачка по передаче данных в сети. Предположим, у нас расстояние 50 км между устройствами, и нужно найти задержку в пропускной способности для 100-байтовых пакетов, если скорость = 2 x 10⁸ м/сек. Задержка будет 50 x 10³м / (2 x 10⁸ м/сек) = 250. 800 бит / 250 = 3.2 Мбит/сек. Напомню, что маленькая b это биты и большая B это байты. Мега это 2**20 или 10**6. А кило это 2**10 или 10**3. Гига это 2**30 или 10**9. Криптография применятся поверх сетевого стека, что позволяет практически не влиять на качество сети.

Ограничения на файловые хранилища: 1 килобайт это 1024 байт, то есть 1024 ячейки памяти. И ASCII, и UTF-8 показывают базовые символы с помощью 8 бит, так, 00101110 это символ точки. Но UTF-8 может показать более редкие символы с помощью 16 бит. В RAM одна ячейка это 8 бит = 1 байт.

При пересылке пакетов формируются заголовки. Существует понятие maximum transmission unit (MTU), который отвечает за максимальный размер заголовков. Так, VLANs это виртуализация на уровне L2, и его продвинутая версия VXLAN. Ниже представлен заголовок VXLAN:

Outer Ethernet Header

Outer IP Header

Outer UDP Header

VXLAN Header

Inner Ethernet Header

Body

А ниже представлен типичный заголовок для IPv4:

Version	HLen	TOS	Length
Ident			Flag	Offset
TTL		Protocol	Checksum
SourceAddr
DestinationAddr
Options				Pad
Data

Все это дело сколько-то весит и постоянно пересылается по сети. Максиммальный размер IP-датаграммы составляет 65 535 байт для поля Length. TTL (time to live) это скорее легаси, на данный момент не особо используется. А вот в поле протокол должно быть UPD или TCP, а могут быть и другие протоколы. Checksum считается по всему заголовку. Эти детали редко входят в стандартные документы, и особенности реализации всегда на усмотрение специалиста в рамках выполнения рабочих задач.

Датаграмма UDP-пакетика:

Пароли:

Пароль легко регламентировать. Пароль должен быть длинным и сложным. И вот почему: если у нас пароль из одного символа, мы можем взять английсий алфавит (26 символов) = 26¹. Простым перебором за пару часов такой пароль будет взломан. Если в пароле шесть символов, то 26⁶ = 308 915 776 комбинаций пароля. 26² для нас это 26 символов английского алфавита в пароле из двух символов, что равно 26*26 = 676. Если нам доступно всего символов 10¹⁶, то есть длина пароя 16, то речь о 10000000000000000 (квадраллионах) потенциальных паролей. Длинные пароли лучше коротких, но сложных.

Для генерации пароля можно использовать генератор псевдо-случайных чисел (PRNG). Ручной перебор мы так обойдем, но современные компьютеры могут генерировать и проверять 100 000 хешей паролей каждую секунду. Полагаться только на надежность пароля = уязвимость и риск.

Если пароль 8 символов и только из цифр, то 10 в 8 = 100 000 000 вариантов. Если использовать только буквы в верхнем и нижнем регистре, то это 200 миллиардов вариантов. Вроде как много, но компьютер способен перебирать 100 000 000 в секунду, то есть пароль будет взломан за 30 минут. Если поверх добавить цифры и спец. символы, то это 7.2 квадраллионов, на взлом такого пароля уйдет 2 года. Мы получим 477,404,928,000 паролей , если у нас 10 символов в пароле. Если пароль из пяти символов, где 2 цифры и 3 строчные буквы, то это 36⁵= 60,466,176, такой пароль взломают за доли секунды.

Отслеживаем две метрики:

• Коэффициент ложного принятия (FAR) — процент времени, когда система сравнивает учетные данные с базой данных и сопоставляет их не с тем человеком.
• Коэффициент ложных отказов (FRR) — процент времени, когда система сравнивает учетные данные с базой данных и не сопоставляет их с пользователем, который их предоставил.

MAC и IP

L2 устройства ориентируются в сети по MAС, он у каждого устройства уникален. Устройства под брендом AMD имеют префикс в 24 бита 080020 (или 8:0:20). MAC-адрес состоит из 48 бит, пример MAC адреса 8:0:2b:e4:b1:2, который на языке машины 00001000 00000000 00101011 11100100 10110001 00000010. Напомню, что весь фрейм состоит из 1500 байт, но в современном мире уже 9 000 байт.

• 48-битные адреса, идентифицирующие чипсет компьютера и, следовательно, компьютерную систему; формат установлен IEEE, и каждая компьютерная система имеет один такой адрес.
• 48-битные широковещательные адреса (для передачи кадра всем получателям в локальной сети).
• Управляющая информация, включая контрольную сумму. Самый базовый формат ethernet — это поле длины и контрольная сумма, но Wi-Fi имеет гораздо более сложный набор управляющих данных для управления передачей по воздуху, которые обсуждаются далее в статье.
• Протоколы управления доступом к среде (MAC) — они используют управляющие данные и электрические сигналы (на проводе или в воздухе), чтобы определить, что делать и когда передавать и принимать кадры.
• Поле данных, в котором передаются данные, которые имеют переменную длину (до некоторого заданного максимального значения).

Беспроводные сети

И обычный интернет, и WI-FI работают по стандартам IEEE. Беспроводные сети идентифицируются по SSID. Именно по SSID делается запрос к сети, которая не видна в списке Wi-Fi. Также, раньше был WEP, но он очень уязвим и сложен. Современная защита Wi-Fi полагается на WPA, WPA2, WPA3. WPA3 в первую очередь используется для публичных сетей, в нем труднее украсть секретный ключ. WPA2 использует AES с CCM, что обеспечивает шифрование и целостность. CCM в свою очередь, использует счетчик, комбинируется из 6-и байтного номера пакета, приоритета, MAC-адреса, что гарантирует уникальность каждого рассчета.

	WPA2	IPSec Gateway	IPSec laptop	SSL	PGP S/MIME
Сетевой трафик из вне	Да	Нет	Да	Да	Да
Другие пользователи нашей сети	Нет	Нет	Да	Да	Да
Други пользователи Интернета	Нет	Да	Да	Да	Да

Многие современные устройства поддерживают все 5 стандартов беспроводной связи 802.11 (a, b, g, n, ac). Что позволяет работать с битрейтом 6, 9, 12, 18, 24, 36, 48, 54 Mbps.

И в IPsec, и в 802.11 сессия между двумя хостами называется SA. Хост это не обязательно клиент или сервер, это может быть роутер. Для 802.11 должно быть 4 шага:

1. Два устройства должны найти друг друга с помощью тестового сообщения.
2. Аутентификация.
3. Ассоциирование. Установка связи между базовой станцией и мобильным клиентом.
4. Ключи передаются по SSL, обе стороны генерируют идентичный блок ключа и создают их собственные ключи для траффика. В небезопасных сетях отсутствует последний шаг.

Чтобы вы могли легко включить раздачу Wi-Fi на смартфоне, используется DHCP. Но если вы ведете видео-трансляцию и передвигаетесь от одной точки тоступа к другой, то возможностей DHCP вам не хватит. Ведь при каждом переключении сети подрубается новый IP-адрес, и если это так легко сделать, значит и злоумышленник может этим воспользоваться. Очевидно, что запретить соседу видеть ваш Wi-Fi куда труднее, ровно как и понять, куда данные ушли и как много людей данные получили. Bluetooth работает на 10 метров в диапазоне 2.45 GHz, Wi-Fi на 100 метров и 4G на десятки километров. Хотите уменьшить область — уменьшите силу трансмиттера, но это не спасет от большинства угроз. Расширение спектра возможно с помощью прямой последовательности, где каждый бит представлен в виде нескольких бит.

Wi-Fi работает на роутерах, обычно в районе 20-150 метров. Он раздает SSID, и пользователь коннектится по SSID. Устройство запоминает SSID. Если мы не хотим, чтобы WIFI был виден, то мы прячем SSID. IEEE 802 покрывает собой несколько уровней, самый нижний это физический, который про работу с битами и декодирование сигнала, характеристики антенн. Беспроводные сети требуют повышенного внимания к безопасности, поэтому существует RSN (Robust Security Network), которая описывает аутентификацию, контроль доступа и приватность. Но трафик 802.11 требует серьезных усилий для перехвата. Как минимум, требуется оборудование для прослушки 2.4GHz.

TCP всегда считает, что IP-адрес неизменный на все время сессии, т.е. при перемещении с мобильным устройством, последнее должно обладать постоянным IP-адресом, у которого сетевой префикс эквивалентен домашней сети. В IPv6 мобильное устройство одновременно работает с двумя IP-адресами. Основной/домашний и вторичный care-of, который меняется в зависимости от смены местоположения устройства. Вторичный адрес меняется в зависимости от положения, и валиден только когда мобильное устройство в гостевой сети.

На более низком уровне, для передачи данных используется ACK. Это небольшой control-frame, который сообщает отправителю, что сообщение было доставлено получателю. Если такое сообщение не было доставлено/получено, то ACK переотправляет оригинальное сообщение. Это называется ARQ, существует в разных имплементациях, таких как stop-and-wait. Логика простая: мы не отправляет новый фрейм, пока не убедились, что предыдущий был доставлен. Мы не отправляет новый кадр видео, пока предыдущий не был доставлен. Звучит надежно, но ACK-сообщение может и само потеряться, или прийти с задержкой. С таким подходом мы не сможем использовать всю пропускую способность сети, а она нам ой как нужна. Мы запустили zoom и перемещаемся, транслируем видео без сжатия, это будет 1920×1080, 24 бита, 30 кадров/сек. то это 1920×1080 * 24 * 30 = 1.5Gb. Если же мы транслируем аудио с телефона GSM, 260 бит и 50 Hz, то ширина канала 260 x 50 = 13 килобит в секунду (битрейт). Поэтому используется Sliding Window, про который мы говорили выше. Он умеет отправлять сразу несколько фреймов за раз, у каждого фрейма есть SeqNum, т.е. кадры видео выстроятся в нужный порядок автоматически.

ATM пакетик может быть только 53 байта. С таким размером было проще работать на уровне железок где-то в 80-х, и был также адаптирован под передачу аудио. Для аудио нужны маленькие пакетики, и принцип маленьких пакетиков нерушим для сотовых операторов. Но ATM успешно влился в IP.

Для ускорения используются различные протоколы. Протокол для передачи данных в реальном времени называется RTP, который в основном работает поверх UPD. То есть, транспортный протокол поверх транспортного протокола. Для ускорения используется CDN — это набор серверов, которые находятся в разных странах, и могут отдать одинаковый контент. WebRTC для передачи аудио- видео- данных, и он не использует RTP, но SRTP.

CSMA/CD также протокол. Представим, что есть связь по сети, по которой одновременно несколько устройств могут получать и отправлять пакеты, и нам нужно мультиплексирование. Похоже на 802.11 или Wi-Fi, но CSMA/CD не умеет работать в Wi-Fi.

Token Ring — устаревший протокол передачи данных по сети с топологией кольца.

DVMRP — протокол для мультикаст-роутинга. Мультикаст это раздача обновлений, радио, новостей. Есть набор различных доменов, алгоритм просто дает наиболее короткий путь от источников к месту назначения. Связь один к одному это юникаст, а мультикаст это многие ко многим. У IP есть специальный диапазон для мультикаста под классом D.

RPC это не совсем протокол, это скорее паттерн структурирования распределенных систем. Сервер принимает запросы, и отдает ответы. Стандратом считаются SunRPC, gRPC.

BGP предотвращает закцикленность трафика, работает поверх TCP. BGP делит сеть на обрасти, и у каждой области есть пограничные роутеры (gateways).

Найти принтер в сети позволит broadcast-протокол. Также, торренты это p2p, где клиент может стать сервером, а сервер — клиентом.

PPTP — протокол умеет соединять Windows с интернетом и обеспечивает крипто-защиту. Имеет схожие уязвимости с SSL, но проблемы SSL были компенсирвоаны, а проблемы PPTP — нет. Выбирая в выпадашке вариант, всегда выбираем IPSec вместо PPTP. IPSec это, практически, VPN.

TLS — супер важный протокол в современном Интернете. Обратите внимание, что TLS является прикладным протоколом, реализованным в браузере. TLS использует TCP-соединение, установленное между клиентом и сервером, для надежной доставки контента в правильном порядке. Именно в TLS происходит сквозное шифрование данных на прикладном уровне. TLS 1 живет на SSL 3.0, но существует TLS 1.3 для HTTPS. Apple использует end-to-end шифрование (сквозное) для всех видеозвонков, Meta — для мессенджеров. End-to-end шифрование отличается от остальных типов шифрования. Конечное шифрование обычно происходит между двумя людьми (или процессами), в то время как сетевое шифрование происходят между программными/аппаратными компонентами сети. При шифровании сети заголовок канала и сети остаются в открытом виде.

Не все из этих протоколов лаконично укладываются в концепцию сетевых слоев. Так, DNS: мы даем сайту название google.com вместо адреса 8.8.8.8, потому что люди плохо запоминают числа. Для безопасности используется расширение DNS SEC. OpenID от 2007 года небезопасен.

Но более интересный и современный протокол, который мы уже несколько раз успели похвалить, это IPSec. IPsec это протокол с компонентами, который невозможно описать в рамках OSI. IPSec нужен для защиты IP-пакетов, и работает на уровне ниже, чем TLS. Настраивая IKEv1 для IPSec, вы удивитесь насколько все будет работать медленно и тяжело из-за протокола Диффи — Хеллмана, такой способ нужен для безопасного обмена ключами. Зато IKEv2 быстрый. В современном мире порой требуется ассимитричное шифрование и уметь передавать огромные объемы трафика одновременно. Нужны ключи шифрования для проверки целостности, и это точно не MD5, а SHA512, аутентификация. SHA-3 очень гибкий алгоритм шифрования, имеет аж 4 спецификации 224/256/384/512. Мы по прежнему держим в уме, что квантовые компьютер может взломать хеш функции и фрагменты ассиметричной криптографии. Git до сих пор использует SHA-1. Из алгоритмов для РФ принято выбирать 3DES, так как он похож на ГОСТовский алгоритм шифрования. Да, он не самый безопасный, поэтому можно посмотреть на AES. Если мы используем секретный ключ, то мы держим в уме, что этот ключ заранее устанавливается в систему. SSL позволяет не заморачиваться конечному пользователю с установкой ключей, и работает поверх TCP. Рукопожатие SSL полагается на RSA для установки ключа, и на AES как алгоритм шифрования.

IPsec был изначально разработан для IPv6. Позволяет аутентифицировать и шифровать весь трафик на IP-уровне, что очень нужно для VPN. Ведь что самое важное в VPN? Обеспечение целостности данных и конфиденциальности через ESP. Итого, заблокированные сайты можно посмотреть через туннельные протоколы, такие как VPN, и скорее всего никто про это не узнает. Если IPsec настроен на роутере или фаерволе, то мы защищаем весь трафик, который пересекает периметр. Конечные пользователи и их софт не замечают наличия IPsec, при этом получают аутентификацию, конфиденциальность, менеджмент ключей.

Если нужно предоставить удаленный доступ к корпоративным ресурсам, тогда remote-access VPN работает по принципу хост — сеть. Позволяет подключиться с компьютера в локальную сеть. Другой вариант это интранет side-to-side VPN, соединяет две внутренние сети внутри одной закрытой сети, например, офис компании в Малайзие и Дубае. И последний вариант это экстранет side-to-side VPN, когда две разные компании подключились к сетям друг друга. Но бывают и другие типы, это лишь самые популярные.

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

	Транспортный режим SA	Туннельный режим SA
ESP с аутентификацией	Шифрует полезную нагрузку IP и любые заголовки расширения IPv6, следующие за заголовком ESP. Аутентифицирует полезную нагрузку IP, но не заголовок IP.	Шифрует весь внутренний IP-пакет. Аутентификация внутреннего IP-пакета.
ESP	Шифрует полезную нагрузку IP и любые заголовки расширения IPv6, следующие за заголовком ESP.	Шифрует весь внутренний IP-пакет.
AH	Аутентифицирует полезную нагрузку IP и отдельные части заголовка IP и заголовков расширения IPv6.	Аутентифицирует весь внутренний IP-пакет (внутренний заголовок плюс полезная нагрузка IP плюс выбранные части внешнего IP-заголовка и внешних заголовков расширения IPv6.

Из таблицы выше видно, что ESP может дать нам конфиденциальность, целостность связи, и может работать с большим количеством алгоритмов аутентификации и шифрования. Для IPv6, ESP работает в формате полезной нагрузки end-to-end. В туннельном режиме шифруется весь IP-пакет. Транспортный режим применяет шифрование выше уровня IP, поскольку оставляет IP-заголовок в открытом виде. Туннельный режим применяет шифрование ниже уровня IP, поскольку сам заголовок IP зашифрован, в этом вся разница.

Настало время поработать руками. Попробуем настроить туннелинг между двумя устройствами VyOS. У нас есть два устройства, мы авторизируемся и попадаем в командную строку VYOS. Делаем пинг второго устройства ping 192.168.110.110. Разумеется, хост будет “unreachable”, ведь туннелинг пока не настроен. Зайдем в Kali и поставим на мониторинг порт br0.

Теперь займемся настройкой инкапсуляции IP-in-IP. Этот протокол добавляет еще один уровень IP поверх существующего сетевого уровня IP. Команды для первого роутера:

configure
show
set interfaces tunnel tun0 encapsulation ipip
set interfaces tunnel tun0 source-address 192.168.1.10

set interfaces tunnel tun0 remote 192.168.1.11
set interfaces tunnel tun0 address 192.168.200.10/24 

show
commit

Вышеприведенными командами мы назначим имя виртуального сетевого протокола как tun0, которое идентифицирует туннель, и сообщим системе, что это должен быть туннель IP-in-IP. Также, мы сообщаем системе, какой из локальных IP-адресов использовать и каков IP-адрес удаленного устройства. И на последнем шаге задаем IP-подсеть и IP-адрес для использования в туннеле. В примере, мы используем IP-подсеть 192.168.200.0/24 и назначаем 192.168.200.10 маршрутизатору. Для второго роутера команды аналогичные, но IP-адрес будет 192.168.200.11. После проведения вышеперечисленных операций, вы можете вбить команду ping 192.168.200.11 и удостовериться, что все работает.

Да и Wireshark подтверждает:

Но, так как упражнение было простое, не трудно догадаться: такая инкапсуляция IP-in-IP не обеспечивает ни конфиденциальности, ни целостности. Злоумышленник на пути следования трафика может легко подслушать обмен сообщениями и изменить их. Более того, даже злоумышленник из вне может внедрить сообщения в такой туннель. Для очистки предыдущих изменений нам подойдут команды:

delete interfaces tunnel tun0
delete protocols static route 192.168.110.0/24
commit

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

В такой схеме все хорошо, кроме нюансов. Протокол PPTP (Point-to-Point Tunneling) очень популярен для VPN, прост в настройке на Windows Server. Но у него 128-битное шифрование, что не безопасно. Лучше посмотреть в сторону L2TP, IPSec.

Шпаргалка:

• Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
• Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
• А кто знает отличную шутку про ARP?
• А вы слышали шутку про ICMP?
• Вам еще кто-то рассказывал шутку про STP?
• Я подожду Антона и расскажу классную шутку про QoS.
• XML
• А про FSMO роли шутить могут не более пяти человек.
• Подождите все, я расскажу шутку о сети типа «шина».
• Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
• Стой-стой, послушай сначала шутку о прерываниях.
• Помню времена, когда шутка про модем пшшшшшшш…..
• Только что, специально для сообщества пришла шутка про мультикаст.
• Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
• Настало время рассказать шутку про NTP.
• Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
• К шутке про SCTP вначале должны все подготовиться.
• Из-за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point-to-multipoint.
• А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
• Про DWDM шутят сразу несколькими голосами.
• Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме. 
• Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
• идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
• Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
• IGMP шутка; пожалуйста, передай дальше.
• Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
• PPP шутки всегда рассказываются только между двумя людьми.
• Шутки про RAID почти всегда избыточны.
• Фрагментированные шутки…
  • … всегда рассказываются…
  • … по кусочкам.
• Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
• Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
• Проблема с IPv6 состоит в том, что их трудно вспомнить.
• DHCP шутки смешны, только если их рассказывает один человек.
• Жаль никто не помнит шутки про IPX.
• У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485.
• Я сейчас всем расскажу шутку про бродкаст.
• У меня есть примерно 450 000 шуток про BGP.
• У кого есть пароли, приходите за шутками про RADIUS.
• Шутку про 127.0.0.1 каждым может пошутить себе сам.
• А что, шутки про IPv4 уже закончились?
• Шутки про RFC1918 можно рассказывать только своим.
• Шутки про SSH–1 и SSH–2 несовместимы между собой.
• Про Schema Master шутит только один в этом лесу.
• Шутки про MAC–адрес могут не дойти до тёзок.
• DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду.
• В шутках про IPSec надо говорить, кому их рассказываешь.
• И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток.
• Министерство обороны США понимает только четыре уровня шуток.
• Шутки про шутки про шутки часто звучат в туннелях.
• Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100.