Comments 89
Согласно rfc2734 (IPv4 over IEEE 1394)?
Нет, конечно. Сетевого взаимодействия нет. Написан драйвер, по которому как по каналу (pipe) передаются данные.
устанавливает соединение с внешним ресурсом
Более того, если мы хотим получить доступ к Web-ресурсам Интернет, то в качестве внешнего ресурса, как правило, используется SQUID
… что-то мне этот "безопасный интернет" все больше напоминает безопасный секс. По телефону, обернутому в два презерватива.
А здесь реально человек получает требуемую информацию, не боясь что получит венерическое заболевание.
Ключевой вопрос (а) получает ли и (б) чем гарантируется отсутствие заражения.
Зато есть контакт с информацией. А в мире информационных технологий информация вполне работает как переносчик заражения.
Нет никакого "естественно", вот в чем дело. Чтобы информация приходила "не с забора" и с ней "обращались осторожно", нужно применять комплекс защитных мер, который вашим решением не обеспечивается. Следовательно — как уже заметили ниже — ваше утверждение "гарантируется отсутствие заражения" ложно.
В ЦБ РБ эта технология используется более 10 лет. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать. И количество устройств каждыц год растет.
Да, чуть не забыл. Первым, кто использовал эту технологию, было Федеральное Собрание для безопасного использования электронной почты.
ваше утверждение «гарантируется отсутствие заражения» ложно
Нет проблем, значит у вас есть доказательство (как у теоремы Пифагора — Пифагоровы штаны не все стороны равны).
Выложте это доказательство.
Все подтверждает эксперимент и опыт. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать.
Вам вашу же цитату из Дийкстры напомнить?
Первым, кто использовал эту технологию, было Федеральное Собрание для безопасного использования электронной почты.
И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?
Нет проблем, значит у вас есть доказательство
Отнюдь. Гарантия ваша, вам и доказывать.
(нет, серьезно, вам надо привести один тривиальный пример с фишинговым письмом?)
И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?
Конечно можно. Как говорят «бумага все стерпит». Проверка достоверность данных (как в разведке), их незараженность (как при сексе) — лежит на получателе. И другого быть ничего не может. Поэтому получаемые данные с внешнего сервера (он же принадлежит Интернет) должны быть проверены и перепроверены как на внешнем, так и на внутреннем серверах.
Проверка может включать проверку на вирусы, проверку на контент и т.д.
«Более серьезной угрозой является проникновение в вычислительные сети органов государственного управления и организаций РФ через точки подключения к публичной сети, когда появляется возможность не только доступа к конфиденциальной информации, но и возможность ее разрушение, когда никакая криптозащита не спасет от причиненного ущерба»
насколько я понял речь идет о серверах с публичным доступом. Но вроде бы есть стандартная практика размещения веб-серверов в DMZ зоне.
Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.
И все же я не понял, зачем нам использовать странную прослойку в виде FireWire вместо нормального DMZ?
В чем плюсы?
И окажется, что это сетевые протоколы, это межсетевые экраны и т.д. Но чтобы защитить межсетевой экран, надо поставить еще один и т.д.
Какой протокол вы используете поверх FireWire? Вы считаете, что он реализован безопаснее, чем IP?
И этот некий канал вроде оптопары — «гальваническая», так сказать, развязка
Если гальваническая развязка — это оптика, но с сохранением IP-взаимодействия, то это не развязка.
Внешний сервер, как и любой другой компьютер, подключенный к Интернет — может быть взломан.
Веревка IEE1394 и драйвер устроены так, что любое злоумышленное действие с веревкой не внешнем сервере, становится известным на внутреннем сервере. И он просто разрывает связь до выяснения причин или переходит на резерв.
alexkunun: точно так. описанная реализация — типичный случай security by obscurity.
для борьбы с возможными уязвимостями реализации ip вместо него используется некий самодельный протокол туннелирования. с собственноручно изобретенными механизмами обнаружения и предотвращения вторжений.
подход при всей спорности имеет право на жизнь, но подразумевает, что квалификация людей, разработавших этот костыль, выше квалификации тех, кто писал реализацию ip и механизмов контроля вторжений для него. ))
подход при всей спорности имеет право на жизнь, но подразумевает, что квалификация людей, разработавших этот костыль, выше квалификации тех, кто писал реализацию ip и механизмов контроля вторжений для него.
… ну либо они сильно ограничили функциональность, тем самым ограничив атакуемую область, что упрощает их задачу.
ну тут остаётся только гадать ) информации в статье недостаточно для подобных выводов.
Даже если так, у них осталась общая функциональность HTTP
Если осталась. Я как-то имел дело с одним "защищенным соединением", так там никакие практически полезные действия были невозможны.
А значит утверждение «безопасный Интернет — это реальность» — неверно.
Ну в общем, да. То, что описано в статье, выглядит как типичный рекламный b/s (собственно, он местами почти дословно совпадает с рекламной информацией одного из продуктов, упомянутых в комментариях), ориентированный на громкие утверждения с яркими метафорами.
При этом, несомненно, насколько-то повысить защищенность сети таким образом можно — точно так же, как ее повышает еще один защищающий сервер, добавленный в цепочку "клиент-поставщик", предпочтительно, с минимально собственной функциональностью.
Вероятность проникновения будет уменьшаться экспоненциально относительно числа слоев )
Например: два компьютера (КОМП1 и КОМП2) из внутренней сети обращаются на два разных адреса URL3 и URL4, после чего сервер Se, асинхронно отправляет пакеты с данными (D5 и D6) серверу Si.
И к какому компьютеру он их направит, к КОМП1 или КОМП2?
Таким образом, точка подключения Shield обеспечивает:
«Отсутствие взаимодействия на сетевом уровне между внутренним Si и внешним Se серверами и как следствие сохранение независимости защищенной и публичной вычислительных сетей, вплоть до того, что они могут иметь одинаковую IP-адресацию;»
Если есть таблица аналогичная NAT, то если злоумышленник захватит сначала внешний сервер и соответственно получит доступ к этой таблице, то тогда возникает вопрос «Отчего в этом случае защищает внутренний сервер?», ведь он (злоумышленник) сможет направлять IP пакеты во внутреннюю сеть просто подменив адрес получателя взяв его из этой таблицы.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
Вы утверждаете что в отличии от NAT, в вашей системе, если злоумышленник захватит управление внешним сервером, то он не сможет получить доступ (отправлять пакеты во внутреннюю), но здесь логическая ошибка. Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
Конечно получить доступ во внутреннюю сеть при наличии такой защиты немного сложнее, но только чуточку сложнее. Надо всего лишь дождаться пока какой либо пользователь из внутренней сети обратится в интернет.
Вы же утверждаете что ваш продукт является очень надёжной защитой и создаёте этим у пользователей чувство ложной безопасности. А значит пользователи будут более беспечными и например установят пароль «1234».
Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
Он отправляет не пакете IP, а данные. И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
Что мешает делать такую же проверку на NAT?
… а если она там есть, то она и является достаточной защитой.
Ваш способ чисто теоретически(и то не факт) защищает от взлома сервера Si. Взломщику нужен доступ к машинам в локальной сети
Т.Е. защищает машины локальной сети. Вы ответили.
Просто сделайте NAT на внутреннем роутере (сервере) к внешнему, который подключен к Интернет. Ничего не изменится с точки зрения безопасности, костыли в виде FireWire не нужны.
Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.
Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.
А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?
Ведь мы из утверждения Дейкстры предполагаем что Se взломан злоумышленниками и имитирует работу вэб-портала и внешнего сервера. И на запрос вэб-страницы от пользователя, присылает ему в ответ, свою страницу с javascript. А javascript обходит песочницу и взламывает внутренний сервер Si по протоколам интернета.
Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.
Защищается все как написано
А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?
Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.
Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Вы это серьезно? "Следуя Дейкстре дыры могут обнаружиться" в том коде, который отвечает за общение между Se и Si, отсюда возможность попасть на Si, далее аналогично.
Используя дыры в Si/Se.
Как же нету-то? Канал, по которому вы данные передаете — есть, вот вам и связь.
(слушайте, люди умудряются передавать данные через air gap, а у вас две железки проводом соединены)
Данные. Точно так же, как и по ethernet, и любому другому каналу данных.
А данные мы уже с вами проверили на отсутсвие вредогосности. Т.е. они безопасны
Не безопасны.
Во-первых, возможность такой проверки противоречит вашему же тезису о том, что в любой программе защиты есть уязвимости.
Во-вторых, если предположить, что такая проверка возможна, то что мешает проверять ей сразу IP-пакеты?
… следовательно, ваше утверждение о том, что "имея неограниченное время доступа к точке подключения к сети Интернет, злоумышленник может, используя стандартные сетевые протоколы, стандартное программное обеспечение и найденные в нем ошибки или ошибки в его настройках осуществить несанкционированный доступ через точку подключения внутрь корпоративной сети со всеми вытекающими последствиями" — либо ложно, либо точно так же применимо и к вашему решению.
У вас как у свободного человека есть право выбора ставить не только МЭ, NAT, Shield в конце концов, но и отразных производителей.
Точно также как у вас выбор покупать Мерседес или Вец, колбасу вареную или копченую. Используйте свое право. Экспериментируйте и т.д
Так в чем противоречие?
В том, что ваша статья утверждает, что ваше решение не подвержено этой уязвимости. Или я вас неправильно понял, и вы согласны, что ваш "безопасный" узел уязвим в той же самой мере, что и любой другой?
Как же защищаемая сеть уязвима, напрмер, по IP-стеку
А никто не утверждает, что защищаемая сеть уязвима "по IP-стеку". Она уязвима как сеть, в том смысле, что возможно проникновение в ее границы. Дальше, когда атакующий находится в этих границах, он уже может использовать те уязвимости, которые он может/хочет для дальнейшей атаки на устройства в этой сети.
FireWire это всего лишь еще один физический уровень.
В него все равно нужно инкапсулировать тот же TCP
В физический уровень FireWire TCP не инапсулируется. Но вы уловили главное.
Хоть немного, но надо говорить о реализации.
На внутреннем сервере Si с IP-адресом IPi работает программный модуль client_sms, принимающий запросы от пользователей/браузеров защищенной ЛВС, например, на tcp порт 312. Полученные запросы изымаются из TCP-пакета и передаются модулю server_sms на Se. Модуль server-sms инкапсулирует полученные двнные в TCP и передвет дальше в squid.
Адрес программного модуля (IP_порт) client_sms прописываются в браузерах как прокси.
При этом можно устанавливать различные ограничения, например, по времени доступа и т.д.
На внешнем сервере Se работает программный модуль server_sms, который обращается к прокси-серверу squid, установленному также на внешнем сервере и принимающему соединения по умолчанию на tcp порт 3128. Прокси-сервер squid уже в свою очередь перенаправляет запрос на удаленный сервис в публичной сети (сети Интернет). Отметим, что для корректной работы прокси-сервера squid на внешнем сервере, естественно, должен быть прописан DNS-сервер.
При получении ответа из публичной сети прокси-сервер на внешнем сервере отправляет полученные данные модулю server_sms, который передает их на внутренний сервер через драйвер шины IEEE1394. На внутреннем сервере данные (ответ на запрос) принимаются модулем client_sms, он их упаковывает в TCP/IP и передаются клиенту/браузеру в защищенной сети.
Поправьте меня, если я ошибаюсь: вы описали типичный http-прокси (не важно, со сколькими уровнями развязки внутри), так?
если бы эту картинку вставили в изначальный пост, вопросов в комментариях было бы на порядок меньше.
кстати, стало интересно, каким образом в этой схеме они сгружают в squid информацию о том, с какого клиента пришёл запрос. предполагаю, что никак, и с точки зрения сквида все запросы идут c адреса Se. То есть вдобавок к обрезанию понятия "интернет" только до http через прокси, они ещё и потеряли часть возможностей настройки сквида.
В него все равно нужно инкапсулировать тот же TCP, что бы, например, получить доступ к локальному SQL.
И в чем новизна? Вы придумали всего лишь еще один физический уровень, которых и без того огромное кол-во. Как только у вас станет необходимость гонять по нему tcp/ip (а она встанет рано или поздно), вы тут же придете к существующей ныне простой схеме NAT-a.
Грубо говоря, у вас реализация DMZ с неким специфическим физическим уровнем.
Или я чего-то недопонимаю? Читал, признаюсь, несколько по-диагонали…
А здесь речь идет именно о независимости сетей.
… иии что? От какого процента потенциальных атак вас это гарантированно защищает?
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,
Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.
Я стесняюсь спросить, вы про NAT слышали вообще? У компьютера, за которым я сижу сейчас, IP-адрес 192.168.1.4 — вы можете получить к нему доступ по IP-адресу, этому, или любому другому, с компьютера, находящегося в публичной сети?
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,
Окей, переформулируем вопрос: как вы оцениваете эффективность предлагаемого вами способа защиты?
защита сети — это некий комплекс мер, каждая из которых предположительно отсекает некий процент потенциальных атак.
именно по этому проценту имеет смысл оценивать эффективность (и целесообразность применения) той или иной конкретной меры. абсолютной защиты не существует, нашивать на фрагменты забора титановые пластины при наличии в других местах дыр, завешенных тряпочкой — не очень целесообразно.
уровень протокола ip, на защиту которого направлено ваше решение, и без того является одним из самых защищённых — реализации протестированы десятилетиями и миллионами установок.
на порядки более уязвимы протоколы более высокого уровня, работающие например поверх http, которые никак описанной защитой не контролируются. для их эксплуатации не нужно инициировать соединение со стороны злоумышленника, на невозможности чего вы так акцентируете внимание.
то есть, на поверку декларируемый "безопасный интернет" закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне "ну firewire это же не ethernet, его взломать гораздо труднее".
Давайте, кстати, все-таки уточним одну вещь. Предлагаемое вами решение является транспортом для любого TCP/IP потока (т.е., я могу просто открыть соединение на произвольный интересующий меня адрес и работать с ним), или только для конкретных поддерживаемых протоколов прикладного уровня (например, HTTP)? Если для прикладных протоколов, то возможно ли пропускать шифрованные данные без их анализа (например, проксирование HTTPS без MITM)? Позволяет ли оно выставлять ресурсы изнутри сети наружу (публикация веб-сервера или машины для удаленного доступа)?
Дайте мне точку опоры или безопасный Интернет — это реальность