Comments 27
UDP работает поверх ARP, который при обычных условиях выполняет двусторонний обмен пакетами Ethernet, в хвосте которых (и собственно в поле mac адреса arp ответа) можно передавать любую информацию с секретного компьютера. Так что диода у вас не получилось. Ну и собственно раз arp пакеты проходят, то и другие ethernet фреймы пройдут. Тема пакетов ICMP также не раскрыта.
Диод надо ставить на уровне Ethernet, а не UDP.
Не имеет значения, что поверх чего работает. Сертифицированное устройство однонаправленной передачи делает физически невозможным движение пакетов в обратную сторону. Принципиально. Там линий передачи просто нет в обратную сторону.
Без линий передачи в обратную сторону протокол UDP работать не будет. Даже при однонаправленной передаче пакетов.
Точнее, надо много крутить руками. Мы на этот случай писали свою собственную реализацию стека UDP.
Прекрасно работает. Я с таким устройством лично работал. Фокус в том, что на ARP и ICMP отвечает каждая сторона этого устройства независимо, будто это две реальных сетевых железки со своим айпишником и маком
Тогда это называется межсетевым экраном с функцией однонаправленного шлюза. Он сам выполняет функции маршрутизации по заданным ему правилам, и тогда непонятно, к чему весь этот код на php.
Нет, это называет диод. Он все так же пропустит через себя пакеты только в одну сторону, потому что внутри он физически не имеет обратного канала передачи. Иначе бы сертификат не выдали.
Поэтому без всех этих танцев с бубнов с делением на пакеты, подсчетом сумм, периодическим подсчетом потерь на периоды времени, переотправкой и прочим гемором не обойтись. Мы это все делали тоже.
Посмотрите, например, ПАК "Рубикон". Он сертифицирован вплоть до грифа “Сов. секретно“.
Я не оспариваю необходимость деления на пакеты и подсчёта потерь. Я говорю, что уровень OSI выбран не тот.
Знаю эту штуку, работал, использовали. Для отделения секретного контура он не подходит, ибо там нет физического разделения, это всего лишь фаервол. Без диода не пропустят. Более того, даже его одного недостаточно было. Сертификат рубикона дает право его использовать внутри секретных контуров, это да.
Я не оспариваю необходимость деления на пакеты и подсчёта потерь. Я говорю, что уровень OSI выбран не тот.
Почему? На уровне приложений наиболее удобно работать с транспортными протоколами. Раз у нас диод, то ничего кроме UDP не прокатит. Вот его и используем. Других нормальных вариантов просто и нет.
Диод же работает на L2 уровне. Принимает фреймы, подменяет маки, пуляет дальше.
Нет, это называет диод. Он все так же пропустит через себя пакеты только в одну сторону,
Межсетевому экрану тоже можно сказать пропускать пакеты только в одну сторону между сетевыми интерфейсами.
Только его в любой момент можно опять настроить иначе "на пару минуточек". Устройство передачи данных в секретную комнату предполагает, что ничего поменять нельзя даже группой лиц, например "железная реализация черной коробочки". У вас же в статье вообще PHP - даже перекомпилировать ничего не нужно, поменял пару строк и всё.
Я специально написал про физическое ограничение, а не программное. Поэтому диод это специальная железка, которая никакой не межсетевой экран. По-другому просто такое решение никто не допустит.
У вас же в статье вообще PHP - даже перекомпилировать ничего не нужно, поменял пару строк и всё.
Во-первых, статья не моя. Во-вторых, вроде в статье речь как раз о диоде как о специальной железке, через которую пропускают пакеты. PHP код в статье - это клиент, который эти пакеты сквозь нее и посылает, и сервер, который их принимает и собирает обратно. Все как надо.
Вот окажется забавно, если физического канала нет, а возможность обнаружится. Образно говоря, при подаче сигнала определённой частоты на принимающий фотоэлемент произойдёт возбуждение (изменение сопротивления) отправляющего светодиода.
Поправьте пожалуйста, UDP работает поверх IP. ARP только занимается разрешением IP-MAC. Глаз просто режет, не сдержался.
UDP работает поверх не только IP, но и ARP. Функция UDP send при первом использовании уходит внутри себя в вызов ARP для получения mac адреса приёмника, и это, в свою очередь, вызывает двусторонний обмен пакетами канального уровня, хотя на транспортном уровне взаимодействие однонаправленное.
Если в кеше уже есть соот. IP=MAC, тогда запроса не будет.
В отдельных случаях, вообще можно таблицу руками набить и выключить ARP на интерфейсе.
Иначе можно говорить и HTTP работает поверх DNS. Все таки поверх подразумевает инкапсуляцию в протокол нижнего уровня.
UDP не знает про таблицу, он обращается непосредственно к функции ARP (через ioctl SIOCGARP в BSD стеке). А ARP внутри себя уже разбирается, надо посылать запрос или не надо, и управляется с таблицей. Вызов ARP, таким образом, является частью стандартной реализации UDP.
HTTP, с другой стороны, работает с NSS при помощи функции getaddrinfo. А NSS может обращаться или не обращаться к DNS в зависимости от своей конфигурации.
Нет, не согласен. Вы говорите про детали реализации, я про сам протокол.
UDP в принципе не важен даже протокол нижележащего уровня, в вашем случае это IP. Но также может быть и другой, например IPv6.
И это именно IP использует ARP для получения связки MAC=IP, при этом он не построен поверх него.
В IPv6 нет ARP вообще и там используется другая методика маппинга, и UDP там также работает.
Все-таки на досуге гляньте модель OSI или TCP/IP + rfc 768 (UDP)
Когда мы обсуждаем вопросы защиты информации, то нас должны интересовать именно детали реализации.
Какой конкретно смысл вы вкладываете в своё высказывание “IP использует ARP”? С точки зрения спецификации, формат ARP не является частью формата IP или надстройкой над ним. С точки зрения API, стек TCP/IP представлен тремя основными интерфейсами tcp_sockets, udp_sockets и raw_sockets, являющимися равноправными и не вложенными друг в друга, и вспомогательными компонентами вроде реализации ARP. Хотя у этих компонентов есть совместно используемые функции, но никакого общего программного компонента "IP", как такового, вообще нет. IP – это просто спецификация формата пакета и набор соглашений.
Поэтому когда я говорю, что UDP использует ARP, я имею в виду последовательность вызовов в конкретном коде udp_sockets. А в отношении вашей фразы про IP такой ясности нет. Если, предположим, вы говорите про raw_sockets, то какое отношение это имеет к теме нашей беседы?
В IPv6 не используется ARP, но используется протокол NDP с пакетами формата ICMPv6, что с точки зрения возникающих вопросов принципиально не отличается.
Изучение модели OSI, конечно, полезное дело, но в понимании реализации стека TCP/IP не очень поможет, особенно в отношении протокола ARP, который многие считают вообще выходящим за рамки модели OSI и находящимся на отдельном уровне 2.5.
RFC 768 вообще касается только формата пользовательского сообщения UDP, что к нашей теме относится примерно никак.
PHP для секретного контура... ну такое... )
С чего же вдруг он там плох? Не все языки программированию сертифицированы для использования в закрытом (секретном) контуре. Тот же PHP его имеет, а вот Go, Java, NodeJS, Ruby нет, а сам процесс сертификации весьма сложен и дорогостоящий (да и занять может до нескольких лет).
Соглашусь что для такой задачи скорее всего подошел бы С++, но на вкус и цвет как говорится, да и от ТЗ все зависит.
PS: А вот по поводу реализации есть нюанс на мой взгляд. Если завершающий пакет придет в середине передачи (а мы знаем что UDP не гарантирует порядок пакетов), то сессия полагаю так же отвалится с ошибкой.
Ага. Такие вещи нужно делать с накоплением всех пакетов в памяти или во внешнем хранилище. Чтобы и дедупликацию сделать, и на порядок пакетов было пофиг. У нас редис стоял под эти цели. Что заодно позволило сделать схему отказоустойчивой и масштабируемой.
Ого, не знал такое про PHP. А можете немного подробнее рассказать про эту сертификацию? А то что-то ничего не нагуглил. Стало интересно какие языки еще.
Есть сертифицированные ОС (для ФСТЭК, ФСБ и т.д.), в рамках которых предоставляется различный набор для разработчиков. Те же Astra Linux, Alt Linux смогли сертифицировать в рамках своих поставок c++, Qt, php, python3. По всем остальным все печально - либо сертификата нет, либо оооочень древние версии (отставание местами лет на 7 от актуальных версий). Для того чтобы сертифицировать что-то свое требуется полно и подробно описать все, что предоставляет язык, как это работает, как идет взаимодействие с памятью и прочее. В общем огромный пласт работ. В дальнейшем материалы могут быть поданы на сертификацию в организацию с лабораторией, имеющей лицензию на проведение таких действий. Если все проходит отлично, то через какое-то время выдается сертификат для использования в тех или иных областях. Это если коротко :)
Я вот такое на плюсах бы предпочёл как заказчик, всёж не в бирюльки играем. По поводу реализации там отдельные вопросы, да.)
Мне показалось важным, существование проверки данных ожидаемым по ожидаемой матрице типов или же использовать блокчейн технологии. Иначе может просочится вредоносный код. Наверное это сделано в модуле сохранения данных.
Со стороны php: у вас низкоуровневая работа с сокетом и высокоуровневая отправка данных в сокет реализована в одном классе, что нарушает принцип единой ответственности. Такие вещи надо разделять по разным классам.
Технология передачи данных в секретный контур