Блог

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

  • Цветков Максим
  • 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 HeaderOuter IP HeaderOuter UDP HeaderVXLAN HeaderInner Ethernet HeaderBody

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

VersionHLenTOSLength
IdentFlagOffset
TTLProtocolChecksum
SourceAddr
DestinationAddr
OptionsPad
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 строчные буквы, то это 365= 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-адреса, что гарантирует уникальность каждого рассчета.

WPA2IPSec GatewayIPSec laptopSSLPGP 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 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.

10 комментариев

  1. Соколов Дмитрий

    22.12.2022

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

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

      22.12.2022

      Chrome по умолчанию сохраняет все, что type=password. Очевидное решение, на внутренних сервисах можно использовать type=input вместо type=password. Но браузер не так хорошо защищает текстовое поле типа type=input, как type=password. Расширения могут утащить данные из input. Не исключено, что за сохранение паролей отвечают какие-то большие компании, так как браузеры зачастую игнорируют атрибут autocomplete=off.

      В мобильных устройствах, я бы выдавал корпоративный телефон и сверху установил MDM. Если придерживаться BYOD, и пользователь сохраняет все свои пароли на устройстве… то мне видится неплохим вариантов выдать каждому сотруднику по токену, пусть вставляют в USB смартфона. Но BYOD скорее привилегия, а не право. И пользователь должен согласиться с некими неудобствами или особенностями, такими как DPI/SSO MFA. Хотя бы двухфакторная аутентификация, регулярная смена паролей, не хранить долго сессионные куки.

      И базовые правила BYOD:
      -Все конфиденциальные данные не должны храниться на мобильном устройстве, либо они должны быть зашифрованы.
      -ИТ-персонал должен иметь удаленный доступ к телефону, стирания всех данных с устройства, а затем отключения устройства в случае потери или кражи.
      -Установка только одобренных приложений.
      -Строгие правила по синхронизации, бекапам, и работу с облачными хранилищами.
      -Возможно, отключение камеры и GPS.
      -Автоблокировка экрана после n-времени неиспользования устройства.
      -Пин-код на устройство и на почту.
      -Без автозаполнения форм.
      -Включить удаленное стирание данных.
      -Если можно включить защиту SSL, то включаем.
      -Весь софт и сама OS должны постоянно обновляться.
      -Наличие антивируса.

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

      18.03.2023

      Например, на Ubuntu Server 22.04. Перед настройкой fail2ban нужно настроить фаерволл UFW, который встроен в Ubuntu . Fail2ban полагается на фаерволл для блокировки IP-адресов.
      Первое, что нужно сделать, это командой sudo ufw allow ssh сконфигурировать фаерволл, чтобы он разрешал работу с SSH. Далее включаем фаерволл sudo ufw enable.

      Если теперь на сервере выполнить команду sudo less /var/log/auth.log, и попробовать ввести пароль, то доступа не будет, и событие запишется как попытка проникновения.

      На каком-нибудь VyOS настройка работает по другому:
      configure
      set firewall state-policy established action accept
      set firewall state-policy related action accept

  2. Карл

    24.02.2024

    Как через командную строку посмотреть детали сохраненных в системе вайфаев?

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

      24.02.2024

      В терминале вбейте команду netsh wlan show profiles, увидите список всех созраненных вайфаев. Вписываете сюда имя сохраненного файфая netsh wlan show profile name=wifiname key=clear и готово.

  3. Алексей Антонович

    26.05.2024

    Как найти сеть, если у нее скрыт SSID?

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

      26.05.2024

      В кали:
      1) узнать имя своего сетевого интерфейса командой ip link
      2) включить режим мониторинга командой sudo wash -i имя_интерфейса

      Есть и чуть более сложный способ: fconfig, покажут доступные сети, с IP-адресом.
      Далее sudo airmon-ng , которая покажет, что wi-fi адаптер имеет место быть.
      На всякий пожарный закидываем команду sudo airmon-ng check kill, чтобы убить сетевые менеджеры.

      И теперь sudo airmon-ng start имя_лана, начнется мониторинг сетей. Можно повторно вбить ifconfig, и вероятно, изменится имя сети.
      И далее команда sudo airmon-ng имя-сети, и вы увидите сети вокруг вас, всякие лампочки.

  4. Анатолий Гришин CyberHelp

    10.06.2024

    Добрый день!
    Если мы захотим создать систему выборов, по какому пути надо идти? Что читать, где смотреть? Как обеспечить приватность?

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

      10.06.2024

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

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

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

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

      Само электронное голосование состоит из нескольких этапов: сначала настройка, потом само голосование, и подсчет голосов. Чуть детальнее, суммарно есть 4 шага differential privacy. 1) подсчитать Privacy budget и sensitivity of function. 2) выбирает механизм для того, чтобы спрятать результат (Laplace). 3) применяем механизм на функцию добавления шума. 4) выдать данные.

      *Laplace — алгоритм, который производит независимую переменную, когда применяется к введенным данным. На человеческом, это добавление шума. Из распределения Лапласа получаем шум.

      Если вы собираете данные, то в самом начале у вас идет сбор сырых данных. Потом добавляется шум, и применяется постпроцессинг. И на любом этапе пользователь должен добровольно согласиться предоставить свои данные, и иметь возможность удалить данные. Также держим в описанном виде, что является Personally Identifiable Information (PII) и для каких целей используется. Так, возраст для голосования важен, чтобы не допустить к голосованию несовершеннолетних. Тут возникает понятие Privacy budget, т.е. максимальное количество информации, которое мы можем раскрыть. Contact tracking — собрать персональную и чувствительную информацию.

      Много хорошего написано в стандартах ISO/IEC — их много, они нужны как согласие экспертов о лучшем способе решения чего-то универсально. Стандарты дают условный гайдлайн, как добиться соответствия требованиям закона. Так, 20889 про анонимизацию данных.

      27701 — менеджмент информационной безопасности. Это самый важный стандарт и он дает соответствие GDPR, с адаптацией под конкретную индустрию. Тут добавляется и DPIA как процесс для понимания и уменьшения рисков приватности для проекта. Понимание риска это хороший риск менеджмент. Он должен улучшать принятие решений, адаптироваться к новым рискам. По DPIA проводится весь проверка всех новых систем компании, и консультируется в DPO.

      27001 — оценка риска, устанавливает соответствующие процессы в компании для принятия риска, назначает владельца риска (Legal controller), и как риск оценивать. Обязательно иметь PIMS, оно про защиту данных организации. И всякие интересные термины, типа контролер данных это организация, которая принимает решения как и почему будут обрабатываться данные. А дата процессор это тот, кто реализует работу с данными.

      29100 и 29101 — фреймворк для проработки структуры приватности для PII. Так, в PII входят имя, адрес, дата рождения, ID, номер телефона, email, IP-адрес, все, по чему можно идентифицировать человека

      Последний также затрагивает вопрос анонимизации датасета. Существует термин Quasi-identifier, это уникальные для человека параметры для идентификации. И re-identification для перевода из анонимизированному в де-анонимизированный статус. K-anonimity — как много генерализации было применено, какие атрибуты имеют более высокий вес, это очень популярно в медицинских датасетах. Как происходит анонимизация: так, Email всегда уникален, его можно просто удалить. Возраст — группировка на подгруппы (20-30). А нужен ли пол? Маловероятно. Почтовый индекс можно спрятать частично, имя можно убрать совсем. Но если мы уберем все данные из датасета, это может стать непригодно для рекомендательных систем. Тут надо искать баланс исходя из целей бизнеса. Так, Apple хочет знать, какой эмоджи самый популярный, а не какой именно у вас любимый эмоджи. И всякие l-diversity, когда для любого k-anonymity существует l вариантов, например, это не только iphone и android, а еще и другие OS. И есть определенный процент распределения.

      Для реализации задуманного нужно гомоморфное шифрование и 0-knowledge proof. Homomorphic encryption это когда данные хранятся в зашифрованном облаке, юзер зашифровал данные и на его же машине их можно расшифровать. При таком шифровании пользователь не раскрывает свои данные, т.к. данные начинают отправку уже будучи зашифрованными, и сервер никогда не получает пользовательские данные. Технически, многообещающим выглядит multiparty computation (MPC) — некое безопасное вычисление, при котором данные остаются приватными, при этом можно подтвердить легитимность результатов. Критерии MPC: приватность, корректность, независимость изначальных данных, гарантия доставки результата в нужные руки. Но алгоритмы MPC очень тяжелы в вычислениях, с точки зрения передачи данных, может достигать и гигабайты. Такое решение точно не для мобилок, и в принципе на данный момент отсутствуют хорошие готовые решения. Но теоретически, MPC идеален для приватности, а формате что никто не узнает, какие запросы я отправлял в chatGPT или в гугл.

      Чуть продвинутее, MPC + FHE HE (homogorphic encryption). FHE для шифрования введенных данных, и для вывода в паблик MPC для приватности. Для объединения этих двух технологий потребуется полностью реактивное вычисление, то есть на лету. Но для работы с данными групп людей, это было бы отличным решением. Это позволяет добиться Zero-knowledge proof (ZKPs) — доказать, что факт верен даже без демонстрации всех деталей, например ключа. Валидация идет от ZKPs, как и protection against collusion. И приватность от MPC. FHE-CPE это полное гомоморфное шифрование. Например, RSA можно считать гомоморфным лишь частично, для FHE соответствует уровень безопасности IND-CPA. Но технически невозможно на данный момент.

      Существуют готовые решения для выборов, такие как helios со способами уменьшения шанса принуждения.

Оставить комментарий

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