Компания Microsoft представила новое решение из области информационной безопасности на базе Azureдля защиты устройств класса умного дома IoT Azure Defender. Система реализована по принципу бесклиентного межсетевого экрана, который контролирует внешние подключения и запросы к IoT-устройствам в домашней сети. Azure Defender интегрируется с уже существующим ИБ-продуктом Azure под названием Sentinel. Именно в панель Sentinel защитник IoT-устройств выводит всю базовую информацию. Кроме этого, Defender интегрируется и со сторонними решениями, такими как SIEM, CMDB и SOAR, что позволяет настроить по вкусу непрерывный мониторинг за подконтрольной инфраструктурой.


Схема контура безопасности на базе связки Azure Defender и панели мониторинга Azure Sentinel

Azure Defender ориентирован на обеспечение мониторинга безопасности для специализированных типов устройств, приложений и контроля на уровне межмашинного взаимодействия (Machine-to-Machine), то есть в случаях, когда ваша кофеварка решает пообщаться с пылесосом или микроволновкой. Решение поддерживает специализированные промышленные протоколы Modbus, DNP3, BACnet и ряд других, которые активно используются в создании сред IoT-устройств и замкнутых систем умного дома.

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

Интересно и использование Azure в связке с Microsoft Sentinel. В стандартно предлагаемой разработчиками конфигурации, для мониторинга предлагается использовать именно панель Azure Sentinel, которая будет получать все оповещения от экрана Defender. В основе алертов лежат механизмы обнаружения и аналитики нарушения периметра безопасности, нарушения политики безопасности, обнаружения промышленных вредоносных программ, обнаружения аномалий и обнаружения инцидентов, в том числе на уровне датчиков. Все это работает через сбор и анализ сетевого ICS-трафика.

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

• неавторизованное устройство подключено к сети;
• несанкционированное подключение устройства к Интернету;
• несанкционированный удаленный доступ;
• обнаружена операция сетевого сканирования;
• несанкционированное программирование ПЛК (программируемый логический контроллер);
• изменение версии прошивки;
• PLC Stop и другие потенциально вредоносные команды;
• устройство подозревается в намеренном отключении;
• ошибка запроса службы Ethernet / IP CIP;
• ошибка операции BACnet;
• несанкционированная операция DNP3;
• ошибка аутентификации Master-Slave;
• обнаружено известное вредоносное ПО (например криптовымогатель WannaCry, EternalBlue и пр);
• несанкционированный вход по SMB.

Перечень угроз, который контролирует Defender, достаточно широк. При этом решение не является стандартизированным антивирусом или межсетевым экраном, который ловит все подряд, а именно решение для IoT. Тут реализован и мониторинг атак на прошивки, и мониторинг попытки захвата контроля/отключения устройства извне. Последнее крайне актуально для контуров IP-камер на предприятиях, которые злоумышленники как раз будут стремиться скорее отключить, чем взять под собственный контроль.

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



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

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

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

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

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

Мы уже сталкивались с ботнетами, построенными на базе IoT-устройств. Один только ботнет Mirai, который появился в 2016 году, атаковал миллионы устройств по всему миру, а потом принимал активное участие в массированных DDoS-атаках. Кстати говоря, его проблема никуда не делась: активно ботнет и его обновленные версии упоминались вплоть до 2019 года, а в апреле 2020 мы столкнулись уже с потомком ботнета Mirai и банкера Qbot ботнетом Dark Nexus, который массированно атаковал роутеры и умные устройства с использованием как заводских данных, так и эксполитов.


Схема атаки Dark Nexus

Microsoft Defender не является панацеей в решении всех проблем с безопасностью умных устройств и роутеров на местах, однако это одно из ряда решений, которое может значительно облегчить жизнь администраторам и владельцам систем умного дома. Как и говорилось выше, одно из преимуществ Azure Defender отсутствие клиента и работа по принципу межсетевого экрана. При этом любой желающий может опробовать предварительную версию системы абсолютно бесплатно. Также можно подключить 30-дневный триал Azure Sentinel и поработать с полной предлагаемой разработчиками связкой из экрана и панели мониторинга от одного производителя.

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

Протоколы ARPANET, как и современные Интернет-протоколы, были упорядочены в слои. Протоколы верхних слоёв работали поверх протоколов нижних слоёв. Сегодня стек TCP/IP имеет пять слоёв (физический, канальный, сетевой, транспортный и прикладной), но у ARPANET было всего три слоя (или четыре, смотря как считать).

Ниже я расскажу, как работал каждый из этих слоёв, но для начала сделаем краткое отступление, чтобы рассказать, кто создавал ARPANET и чем конкретно занималась каждая из сторон. Это поможет вам понять, почему слои были разделены именно так.

Краткая историческая справка

ARPANET финансировался федеральным правительством США, и в частности Управлением перспективных исследовательских проектов (Advanced Research Projects Agency, ARPA), подчинённым Министерству обороны (отсюда и название ARPANET). Правительство США не создавало сеть самостоятельно; вместо этого оно отдало работу на аутсорс бостонской консалтинговой фирме Bolt, Beranek and Newman, более известной как BBN.

BBN, в свою очередь, взяла на себя бОльшую часть задач по реализации сети, но не весь проект целиком. BBN занималась проектированием и поддержкой машины, называемой Interface Message Processor (IMP). IMP представлял собой модернизированный микрокомпьютер Honeywell, каждый из таких компьютеров отправлялся в те учреждения по всей стране, которые должны были подключаться к ARPANET. IMP использовался в качестве шлюза в ARPANET для четырёх хостов в каждой из точек. BBN контролировала выполняемое на компьютерах IMP ПО, передающее пакеты от одного IMP к другому IMP, однако фирма не имела непосредственного контроля над машинами, подключавшимися к IMP и становившимися истинными хостами ARPANET.

Машины-хосты контролировались учёными-компьютерщиками, которые были конечными пользователями сети. Эти учёные в местах использования хостов по всей стране отвечали за написание программного обеспечения, которое бы позволило хостам общаться друг с другом. IMP предоставляли хостам возможность передавать сообщения друг другу, но это не было особо полезно, если бы хосты не согласовали используемый для сообщений формат. Для решения этой проблемы была собрана разношёрстная команда, в основном состоящая из аспирантов различных учебных заведений, где находились хосты. Эта команда самостоятельно организовала Network Working Group, занимавшуюся созданием спецификаций протоколов для использования компьютерами-хостами.

То есть если представить единичное успешное сетевое взаимодействие через ARPANET (допустим, отправку электронного письма), то за некоторые части её реализации, обеспечивающие успешное взаимодействие, отвечал один коллектив людей (BBN), а за другие части отвечал другой коллектив (Network Working Group и инженеры в каждой из точек размещения хостов). Такое организационное и логистическое стечение обстоятельств, вероятно, сыграло важную роль в выборе слоистой архитектуры протоколов ARPANET, что, в свою очередь, повлияло на реализацию TCP/IP в виде слоёв.

Итак, вернёмся к протоколам

Иерархия протокола ARPANET.

Слои протокола были упорядочены в иерархию. В самом низу находился уровень 0 (level 0). Это слой, который в каком-то смысле не считается, потому что в ARPANET его целиком контролировала фирма BBN, а значит, нужда в стандартном протоколе отсутствовала. Level 0 управлял тем, как данные передаются между IMP. У BBN были внутренние правила о том, как IMP должны это делать; для всех, кто не работал в BBN, подсеть IMP оставалась чёрным ящиком, просто передающим любые отправленные ему данные. То есть level 0 был слоем без настоящего протокола, не являлся публично открытым и общепринятым перечнем правил и его существование могло полностью игнорироваться программами, работающими на хостах ARPANET. Грубо говоря, он обрабатывал всё, что сегодня относится к физическому, канальному и сетевому слоям стека TCP/IP, и даже выполнял довольно большую часть функций транспортного слоя, но к этому мы вернёмся в конце поста.

Слой level 1 устанавливал интерфейс между хостами ARPANET и IMP, к которым они были подключены. Можно сказать, что это был API для чёрного ящика level 0, созданного BBN. В то время его также называли IMP-Host Protocol. Этот протокол нужно было написать и опубликовать, потому что при первоначальной подготовке ARPANET каждое учреждение с хостами должно было писать собственное ПО, обеспечивающее интерфейс с IMP. Они бы не знали, как это сделать, без помощи BBN.

Спецификация IMP-Host Protocol была записана BBN в длинном документе под названием BBN
Report 1822. В процессе эволюции ARPANET было выпущено много новых версий документа; в посте я приблизительно опишу то, как работала изначальная версия IMP-Host Protocol. Согласно правилам BBN, хосты могли передавать компьютерам IMP сообщения длиной не более 8095 бит, и каждое сообщение содержало leader (заголовок), в котором указывался номер хоста-получателя, а также нечто под названием link number (номер канала). IMP считывал номер хоста-получателя и послушно переправлял сообщение в сеть. При получении сообщений от удалённого хоста принимающий IMP заменял номер хоста-получателя на номер хоста-отправителя, а потом передавал его на локальный хост. Между самими IMP передавались не сами сообщения IMP разбивали сообщения на мелкие пакеты для передачи по сети, однако эта особенность была сокрыта от хостов.


Формат заголовка сообщений, передаваемых между хостом и IMP, каким он был в 1969 году. Схема из BBN Report 1763.

Номер канала, который мог быть любым числом от 0 до 255, выполнял две задачи. Он использовался протоколами более высокого уровня для установки нескольких каналов связи между любыми двумя хостами в сети, потому что в текущий момент времени с хостом-получателем вполне могло общаться несколько локальных пользователей. (Другими словами, номера каналов позволяли мультиплексировать связь между хостами.) Однако также он использовался в слое level 1 для управления объёмом трафика, который можно передавать между хостами, это было необходимо для того, чтобы быстрые компьютеры не перегружали сообщениями медленные. В изначальном проекте IMP-Host Protocol ограничивал каждый хост, позволяя одновременно передавать по одному каналу всего одно сообщение. После того, как хост передал сообщение по каналу удалённому хосту, ему нужно было ждать от удалённого IMP специальное сообщение под названием RFNM (Request for Next Message), прежде чем отправлять следующее сообщение по тому же каналу. Следующие версии этой системы, созданные для повышения пропускной способности, позволяли хосту одновременно передавать другому хосту по одному каналу до восьми сообщений.

Самое интересное начинается в слое level 2, потому что этот и последующий слои BBN и Министерство обороны отдали на откуп учёными и Network Working Group, позволив изобретать их самостоятельно. Слой level 2 представлял собой Host-Host Protocol, черновик которого изначально был выпущен в RFC 9, а первая его официальная спецификация появилась в RFC 54. Более удобочитаемое объяснение Host-Host Protocol представлено в ARPANET Protocol Handbook.

Host-Host Protocol управлял тем, как хосты создавали соединения друг с другом и управляли ими. Соединение это односторонняя линия передачи данных между сокетом записи одного хоста и сокетом считывания другого. Концепция сокетов (socket) была добавлена поверх имевшей ограничения системы каналов level 1 (не забывайте, что номер канала иметь только 256 значений), чтобы предоставить программам возможность адресации определённого процесса, работающего на удалённом хосте. Сокеты считывания имели нечётные номера; функция сокета (считывание или запись) назывались его гендером. В протоколе не было номеров портов, как в TCP. Соединения можно было открывать, манипулировать ими и закрывать их при помощи специально отформатированных контрольных сообщений Host-Host, передаваемых между хостами по каналу 0, зарезервированному для этой цели. После того, как был произведён обмен сообщениями по каналу 0 для установки соединения, дальнейшие сообщения с данными можно было передавать по каналу с другим номером, выбранным получателем.

Контрольные сообщения Host-Host идентифицировались трёхбуквенной мнемоникой. Соединение устанавливалось, когда два хоста обменивались сообщением STR (sender-to-receiver) и соответствующим сообщением RTS (receiver-to-sender) эти контрольные сообщения назывались сообщениями Request for Connection (запроса на подключение). Соединения можно было закрывать контрольным сообщением CLS (close). Существовали и другие контрольные сообщения, менявшие частоту передачи сообщений с данными от отправителя к получателю, что опять-таки нужно было для того, чтобы быстрые хосты не перегружали медленные. Управление потоками, реализованное в протоколе level 1, очевидно, было недостаточным для level 2; я подозреваю, что так получилось из-за того, что получение RFNM от удалённого IMP гарантировало только то, что удалённый IMP передал сообщение на хост-получатель, а не то, что хост полностью его обработал. Также существовали контрольные сообщения INR (interrupt-by-receiver) и INS (interrupt-by-sender), которые в основном использовались протоколами более высокого уровня.

Все высокоуровневые протоколы находились на level 3, то есть на прикладном слое ARPANET. Вероятно, самым важным из этих протоколов был Telnet, обеспечивавший виртуальное телетайпное подключение к другому хосту, но на этом уровне было и много других протоколов, например, FTP для передачи файлов и различные эксперименты с протоколами для отправки электронной почты.

Один протокол с этого уровня не походил на остальные, это Initial Connection Protocol (ICP). ICP считался протоколом level 3, но на самом деле был протоколом level 2.5, поскольку от него зависели другие протоколы level 3. ICP был необходим потому, что соединения, обеспечиваемые Host-Host Protocol на level 2, были только односторонними, однако большинству приложений для выполнения каких-то интересных задач требовалось двустороннее (т.е. полнодуплексное) соединение. ICP задавал двухэтапный процесс, при котором запущенный на одном хосте клиент подключался к долговременно работающим процессом-сервером на другом хосте. Первый этап заключался в установке одностороннего подключения от сервера к клиенту при помощи известного номера сокета процесса-сервера. После установки соединения сервер отправлял по нему клиенту новый номер сокета. Затем установленное соединение прекращалось и открывалось два новых соединения, одно для считывания, использующее переданный номер сокета, другое для записи, использующее тот же переданный номер плюс один. Этот небольшой танец был необходимой прелюдией для большинства действий, например, он был первым этапом установки соединения Telnet.

На этом наш подъём по иерархии протоколов ARPANET завершён. Вы могли ожидать, что рано или поздно я упомяну Network Control Protocol. Прежде чем я приступил к исследованиям для подготовки к этому посту, я считал, что ARPANET управлялся протоколом под названием NCP. Этой аббревиатурой иногда обозначали протоколы ARPANET в целом. Вероятно, именно поэтому у меня появилась такая мысль. Например, в RFC 801 говорится о переходе ARPANET с NCP на TCP, и это заставляет думать, что NCP это протокол ARPANET, эквивалентный TCP. Но Network Control Protocol для ARPANET никогда не существовало (хоть так и считает Encyclopedia Britannica), и я подозреваю, что люди ошибочно расшифровывали NCP как Network Control Protocol, но на самом деле это означало Network Control Program. Программа Network Control Program была программой уровня ядра, работающей на каждом хосте, отвечающем за управление сетевыми коммуникациями. Она была эквивалентом стека TCP/IP в современных операционных системах. Аббревиатура NCP, используемая в RFC 801, это псевдоним, а не протокол.

Сравнение с TCP/IP

Позже все протоколы ARPANET были вытеснены протоколами TCP/IP (за исключением Telnet и FTP, которые легко адаптировали для работы поверх TCP). Все протоколы ARPANET основывались на предположении о том, что сеть создавалась и управлялась одной организацией (BBN), а стек протоколов TCP/IP проектировался под Интер-нет, сеть сетей, где всё будет более гибким и ненадёжным. Это привело к появлению одних из наиболее очевидных отличий между современными протоколами и протоколами ARPANET, а именно к тому, как сегодня мы разделяем сетевой и транспортный слои. В ARPANET функции транспортного протокола частично выполняли IMP, а позже за них стали отвечать исключительно хосты в конечных точках сети.

Однако самым интересным в протоколах ARPANET мне кажется то, что большой объём функций транспортного слоя, присутствующий сегодня TCP, прошёл этап незрелой юности ARPANET. Я не специалист по сетям, поэтому мне пришлось достать свой учебник по сетям из колледжа (Куросе и Росс, на помощь!), и в нём нашлось достаточно неплохое краткое описание того, за что в целом отвечает транспортный слой. Протокол транспортного слоя минимально должен выполнять следующие задачи. Сегмент здесь, по сути, является термином, аналогичным сообщению в ARPANET:

• Обеспечивать службу доставки между процессами, а не просто хостами (мультиплексирование и демультиплексирование транспортного слоя)
• Обеспечивать проверку целостности каждого сегмента (то есть проверять, что при передаче не произошла порча данных)

Кроме того, транспортный слой, как и TCP, может обеспечивать надёжную передачу данных, то есть:

• Сегменты доставляются по порядку
• Потерянные сегменты отсутствуют
• Сегменты не доставляются так быстро, что отбрасываются получателем (управление потоками)

Похоже, в ARPANET существовала некоторая запутанность в способе реализации мультиплексирования и демультиплексирования для обмена данными процессов BBN реализовала для этого номер канала на уровне IMP-Host, но оказалось, что всё равно поверх него требуются номера сокетов на уровне Host-Host. Поэтому номер канала использовался только для управления потоками на уровне IMP-Host, но BBN, похоже в дальнейшем отказалась от этой схемы в пользу управления потоками между уникальными парами хостов, то есть изначально номер канала был перегруженным элементом, а позже, по сути, стал рудиментарным. Сегодня TCP использует вместо них номера портов, выполняя управление потоками отдельно для каждого TCP-соединения. Мультиплексирование и демультиплексирование уровня процесс-процесс происходит целиком внутри TCP и не утекает на нижний слой, как это было в ARPANET.

К тому же, в свете того, как Куросе и Росс развивают идеи, лежащие в основе TCP, любопытно было увидеть, что ARPANET начинались с того, что авторы учебника назвали бы реализацией надёжной передачи данных на уровне IMP-Host при помощи строгого подхода остановиться и ждать. Принцип остановиться и ждать заключается в том, что после передачи сегмента узел отказывается передавать любые другие сегменты, пока не получит подтверждение получения последнего переданного сегмента. Это простое решение, но оно означает, что в любой момент времени по сети передаётся только один сегмент, из-за чего протокол оказывается очень медленным. Именно поэтому Куросе и Росс назвали подход остановиться и ждать просто переходным этапом на пути к полнофункциональному протоколу транспортного слоя. В ARPANET какое-то время использовался подход остановиться и ждать, поскольку на уровне IMP-Host перед отправкой дальнейших сообщений нужно было получить Request for Next Message в ответ на каждое исходящее сообщение. Но надо отдать должное BBN, поначалу она считала, что это будет необходимо для обеспечения управления потоками между хостами, поэтому замедление было намеренным. Как я говорил выше, требование RFNM позже было смягчено ради повышения скорости, а IMP начали прикреплять к сообщениям порядковые номера и отслеживать окна передаваемых сообщений примерно так же, как сегодня это делается в реализациях TCP.

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

Разработка своей криптографии в чём-то сравнима с созданием собственного авиадвигателя, говорит эксперт по безопасности Руна Сандвик. Фото: Виталий Кузьмин

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

Казалось бы, почему не использовать открытые стандарты типа WebSocket и JSON, зачем собственный закрытый протокол? На это обычно приводят ряд причин. Во-первых, для безопасности, чтобы его было сложнее отреверсить и никто не понял, какие данные вы передаёте. Во-вторых, для эффективности. У нас ведь уникальный случай использования, поэтому стандартные решения не самые оптимальные. Наш собственный протокол будет работать с меньшими задержками, потреблять меньше трафика и меньше расходовать батарею (на мобильных устройствах). И третья причина функции. В своём протоколе специально для нашего приложения мы реализуем уникальные возможности, каких нет ни в открытом стандарте, ни у конкурентов.

Это распространённые причины, из-за которых разрабатывают проприетарные протоколы.

Безопасность

Поговорим о безопасности.

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

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

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

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

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

Но жизнь иногда показывает обратное. А именно:

1. Принцип безопасность через неясность не работает. Любой протокол можно отреверсить.
   
2. Проприетарная реализация шифрования это очень рискованно.
   
3. Никто не поможет закрыть критические дыры в закрытом софте.

Принцип безопасность через неясность не работает в криптографии

Принцип безопасность через неясность (security through obscurity) заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.

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

Сравните с опенсорсными системами, где разработчик специально открывает код, чтобы независимые сторонние эксперты помогли выявить и исправить эти недостатки.

В итоге получается, что собственный проприетарный протокол, максимально закрытый от посторонних глаз и обфусцированный, вовсе не увеличивает безопасность системы, а уменьшает её!

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

Голландский криптограф Огюст Керкгоффс изложил правила проектирования военных шифров в книге Военная криптография (1883). Основная идея была в том, что попадание системы в руки врага не должно причинять неудобств. Поэтому ничего, кроме ключа, не должно быть секретным.

Собственная криптография

Вопрос Почему не разработать собственную криптографию? чем-то похож на вопрос Почему не спроектировать авиадвигатель?, говорит Руна Сандвик, исследователь по безопасности. Конечно, теоретически мы можем это сделать. Но это чрезвычайно сложно. Гораздо более простой и надёжный вариант выбрать готовое решение, проверенные и надёжные протоколы и алгоритмы.

Поэтому в сообществе информационной безопасности вызывает большое подозрение, если какая-то компания реализует собственный проприетарный протокол. Например, проприетарный протокол MTProto в Telegram поначалу вызвал массу критических отзывов. Взлом MTProto1.0 стал одной из самых популярных статей на Хабре в 2013 году: Безопасен ли Telegram? Или как я искал закладку в MTProto (спойлер: глупые ошибки в проприетарной криптографии).

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

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

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

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

Конечно, в опенсорсе есть свои специфические риски. Например, проблемы с сотнями зависимостей, которые вы не контролируете. Например, 20% багов в проектах на GitHub явно внесены в проекты специально, со злым умыслом. То есть вредоносными контрибуторами, которые действовали умышленно. Ещё не забыта история c мейнтейнером ESLint, который 12 июля 2018 года опубликовал вредоносные версии пакетов eslint-scope и eslint-config-eslint в репозитории npm.

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

• Каково быть мейнтейнером свободного ПО
  
• Мейнтейнеры не масштабируются
  
• Трудно быть мейнтейнером проекта Open Source

Поэтому иногда соглашаются продать свой проект (такая же история с расширениями для браузеров). А этот проект уже внедрён в качестве зависимости в тысячи других.

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

Кстати, в 2013 году проприетарный софт впервые обогнал опенсорсные проекты по среднему количеству багов на 1000 строк кода.


Источник: Coverity Scan Open Source Report

В прошлом веке считалось, что проприетарный софт пишут профессионалы, а Open Source любители. Сегодня же профессиональный уровень опенсорсных программ вовсе не уступает проприетарным. Может, даже превосходит их.

Возвращаясь к примеру Telegram. 5 декабря 2020 года двое итальянских математиков Марино Микулан и Никола Витоколонна опубликовали на сайте препринтов arXiv.org исследование Автоматическая символическая проверка протокола MTProto 2.0 в Telegram (вторая версия опубликована 30 апреля 2021 года, arXiv:2012.03141v1). Оно подтверждает безопасность обновлённой версии фирменного протокола MTProto 2.0.


Набор протоколов MTProto 2.0 (в голубой рамке) и область покрытия данной научной работы (светло-зелёным цветом). Схема из научной статьи Марино Микулана и Никола Витоколонны, arXiv:2012.03141v1

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


Протокол аутентификации MTProto 2.0. Здесь означает асимметричное шифрование открытым ключом . В свою очередь, означает симметричное шифрование общим ключом с вектором инициализации . Схема из научной статьи


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

---

Эта математическая работа чуть ослабила озабоченность экспертов по поводу проприетарного протокола MTProto2.0. Редкий случай, когда собственная нестандартная криптографическая система (пока) работает надёжно. В ней ещё не нашли таких фатальных уязвимостей, как в MTProto 1.0.

Неужели разработчики Telegram всё-таки научились и смогли сделать уникальный авиадвигатель без ошибок? Можно только порадоваться за них, ведь все пользователи Telegram участвовали в этом обучении как бета-тестеры. В каком-то смысле это наш общий успех.

---

На правах рекламы

Наша компания предлагает серверы с Linux или Windows. Не экономим на железе только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!

Присоединяйтесь к нашему чату в Telegram.