Дайте мне точку опоры или безопасный Интернет — это реальность

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

В рамках обсуждаемой проблемы можно выделить два наиболее вероятных способа нарушения конфиденциальности информации:

  • Прослушивание и реконструкция трафика передаваемых данных между корпоративными сетями в некоторой точке публичной сети;

    image
  • Проникновение в корпоративную сеть в точке подключения к публичной сети и/или нарушение ее нормального функционирования.

imageПерефразируя Архимеда, который говорил «дайте мне точку опоры и я переверну Землю», можно сказать «дайте мне точку подключения вашей сети к сети Интернет и я взломаю вашу сеть».

Поскольку публичная сеть (в данном случае Интернет) находится вне сферы контроля администраторов безопасности автоматизированных систем органов государственного управления и организаций РФ, то единственным способом управления риском прослушивания трафика при прохождении его через публичную сеть является применение криптографических средств. В качестве таких средств могут выступать VPN, шифрованные туннели, а при доступе на порталы применяться протокол tls/https.

Более серьезной угрозой является проникновение в вычислительные сети органов государственного управления и организаций РФ через точки подключения к публичной сети, когда появляется возможность не только доступа к конфиденциальной информации, но и возможность ее разрушение, когда никакая криптозащита не спасет от причиненного ущерба.

Управление риском проникновения в ЛВС через точку подключения к публичной сети включает решение двух основных технических вопросов:

— сокрытие структуры внутренней корпоративной сети;
— защита точки подключения к корпоративной сети от НСД.

Вместе с тем, если рассматривать сеть Интернет (или любую другую публичную сеть) не как IP-сеть, а как некоторую субстанцию, предоставляющую набор услуг (электронная почта, транспортная среда, ftp-сервера, Web-сервера, портал Госуслуг и т.д.), то оказывается, что можно найти технические решения, которую позволяют использовать эти услуги, не предоставляя точки доступа злоумышленнику.

И так, чтобы предотвратить несанкционированный доступ из сети Интернет на компьютер пользователя или в корпоративную сеть, следуя постулату Архимеда, надо лишить злоумышленника доступа к точки входа в ЛВС или защищаемого компьютера. Как это сделать?

image Сегодня, наверное, каждый знает, что в атомных бомбах используют два полушария . И до тех пор, пока они не соединились в один смертоносный шар, эта бомба в виде двух полушарий не предоставляет угрозы.
По аналогии с атомной бомбой точку подключения к сети Интернет, также можно сделать состоящей из двух «полушарий» — двух серверов, обменивающихся между собой данными по высокоскоростному интерфейсу, например, IEE1394:

image

Как видно из рисунка, разделяет локальные и публичную сети и не приводит к появлению каких-либо возможностей для доступа по любым сетевым протоколам из сети Интернет ЛВС, а также не допускает доступ пользователей ЛВС в Интернет.

Для простоты в дальнейшем реализацию такого подключения будем называть бинарной точкой подключения к Интернет или точкой Shield – безопасной/защищенной точкой подключения:

image

На внутреннем сервере Si нет никакой информации о публичной сети. Так же и на внешнем сервере Se нет никакой информации о внутренней ЛВС. Это является одной из причин невозможности прорыва из Интернета во внутреннюю ЛВС, и, наоборот, из внутренней ЛВС в публичную сеть. Даже в случае, если злоумышленнику в открытой сети станет известен какой-либо адрес во внутренней сети, то, используя его, он может попасть куда угодно, только не во внутреннюю сеть.

Таким образом, точка подключения Shield обеспечивает:

  • Отсутствие взаимодействия на сетевом уровне между внутренним Si и внешним Se серверами и как следствие сохранение независимости защищенной и публичной вычислительных сетей, вплоть до того, что они могут иметь одинаковую IP-адресацию;
  • Прозрачность как для стандартных протоколов (http, https, ftp, ssl, pop3 и т.п.), так и возможность написания собственных протоколов для систем «клиент-сервер»;
  • Доступ пользователей защищенных вычислительных сетей к различным услугам публичных сетей при отсутствии сетевого взаимодействия между защищенной и публичной сетями;
  • Возможность раздельного администрирования внешнего и внутреннего шлюзов: администратор внешнего шлюза не имеет доступа (не знает пароля) к внутреннему шлюзу и наоборот.

Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.

Слабым звеном остается внешний сервер Se точки доступа Shield, который непосредственно подключен к сети Интернет. Злоумышленник может получить контроль над этим сервером, однако он не сможет достичь своей цели — проникнуть в ЛВС и нанести ей ущерб. Но поскольку об этом сразу же станет известно администратору ЛВС (например, пропадет связь с внешним миром), то всегда можно перейти на резервный канал и восстановить связь с внешним миром.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 174

    +3
    Так и не понял что помешает злоумышленника попасть в локалку завладела внешним сервером
      0
      Какую роль выполняет FireWare? Почему не Ethernet? Полагается, что использование FireWare будет более безопасным? За счет чего?
        0
        Блин, из андроид клиента нельзя редактировать. злоумышленнику и завладев естественно.
          0
          А где-нибудь что-нибудь по этой технологии сделано и реально стоит?
            0
            Кроме всего прочего, атомные бомбы из «двух полушарий» не делают примерно со времен Хиросимы.
            • UFO just landed and posted this here
                0
                Согласно rfc2734 (IPv4 over IEEE 1394)?

                Нет, конечно. Сетевого взаимодействия нет. Написан драйвер, по которому как по каналу (pipe) передаются данные.
                • UFO just landed and posted this here
                    0
                    Обсолютно правильно.
                    устанавливает соединение с внешним ресурсом

                    Более того, если мы хотим получить доступ к Web-ресурсам Интернет, то в качестве внешнего ресурса, как правило, используется SQUID
                      –1

                      … что-то мне этот "безопасный интернет" все больше напоминает безопасный секс. По телефону, обернутому в два презерватива.

                        0
                        Только в вашем сексе кто-нибудь получает удовольствие (уж не операционистка ли?)?
                        А здесь реально человек получает требуемую информацию, не боясь что получит венерическое заболевание.
                          0

                          Ключевой вопрос (а) получает ли и (б) чем гарантируется отсутствие заражения.

                            0
                            Отсутствием контакта с операционистой или как правильно называть гетеру на другом конце телефона.
                              +2
                              Уже не первый раз намекаем — смена открытого, общеизвестного протокола на закрытый самописный сама по себе ничего не гарантирует. И общение локальной сети с интернетом как было так и осталось. То, что внутренний и внешний шлюз общаются не по ethernet протоколу, а по какому-то другому не значит, что через этот другой протокол не может быть проведена атака.
                                0

                                Зато есть контакт с информацией. А в мире информационных технологий информация вполне работает как переносчик заражения.

                                  0
                                  Информация — это прежде всего источник знаний. И с ней надо обращаться осторожно. И, естественно, это информация, полученная не с забора.
                                    0

                                    Нет никакого "естественно", вот в чем дело. Чтобы информация приходила "не с забора" и с ней "обращались осторожно", нужно применять комплекс защитных мер, который вашим решением не обеспечивается. Следовательно — как уже заметили ниже — ваше утверждение "гарантируется отсутствие заражения" ложно.

                                      –1
                                      Все подтверждает эксперимент и опыт.
                                      В ЦБ РБ эта технология используется более 10 лет. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать. И количество устройств каждыц год растет.
                                      Да, чуть не забыл. Первым, кто использовал эту технологию, было Федеральное Собрание для безопасного использования электронной почты.
                                      ваше утверждение «гарантируется отсутствие заражения» ложно

                                      Нет проблем, значит у вас есть доказательство (как у теоремы Пифагора — Пифагоровы штаны не все стороны равны).
                                      Выложте это доказательство.

                                        –1
                                        Все подтверждает эксперимент и опыт. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать.

                                        Вам вашу же цитату из Дийкстры напомнить?


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

                                        И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?


                                        Нет проблем, значит у вас есть доказательство

                                        Отнюдь. Гарантия ваша, вам и доказывать.


                                        (нет, серьезно, вам надо привести один тривиальный пример с фишинговым письмом?)

                                          0
                                          И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?

                                          Конечно можно. Как говорят «бумага все стерпит». Проверка достоверность данных (как в разведке), их незараженность (как при сексе) — лежит на получателе. И другого быть ничего не может. Поэтому получаемые данные с внешнего сервера (он же принадлежит Интернет) должны быть проверены и перепроверены как на внешнем, так и на внутреннем серверах.
                                          Проверка может включать проверку на вирусы, проверку на контент и т.д.

                                            0
                                            Конечно можно.

                                            Значит, заражение возможно. Что и требовалось доказать.


                                            (То же применимо к любому другому прикладному каналу.)

                        • UFO just landed and posted this here
                            0
                            Еще какое!
                    +2
                    «Более серьезной угрозой является проникновение в вычислительные сети органов государственного управления и организаций РФ через точки подключения к публичной сети, когда появляется возможность не только доступа к конфиденциальной информации, но и возможность ее разрушение, когда никакая криптозащита не спасет от причиненного ущерба»


                    насколько я понял речь идет о серверах с публичным доступом. Но вроде бы есть стандартная практика размещения веб-серверов в DMZ зоне.

                    Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.


                    И все же я не понял, зачем нам использовать странную прослойку в виде FireWire вместо нормального DMZ?
                    В чем плюсы?
                      –3
                      А как подключена ваша DMZ к внешнему миру?
                      И окажется, что это сетевые протоколы, это межсетевые экраны и т.д. Но чтобы защитить межсетевой экран, надо поставить еще один и т.д.
                        0
                        Сервер, к которому есть доступ из интернета, находится в DMZ и отгорожен от корпоративной сети фаерволом, ядро которого находится в корпоративной сети. Для взломщика, получившего доступ к этому серверу в DMZ с помощью эксплуатации какой-либо уязвимости, фаервол, отгораживающий его от корпоративной сети, будет выглядеть как монолитная железобетонная стена. Зачем этот фаервол ещё защищать?
                      +2
                      При отсутствии общедоступных из внешней сети сервисов на сервере-маршрутизаторе единственная возможность «получить над ним контроль» — уязвимость в реализации TCP/IP.

                      Какой протокол вы используете поверх FireWire? Вы считаете, что он реализован безопаснее, чем IP?
                      • UFO just landed and posted this here
                          0
                          И этот некий канал вроде оптопары — «гальваническая», так сказать, развязка

                          Если гальваническая развязка — это оптика, но с сохранением IP-взаимодействия, то это не развязка.
                          Внешний сервер, как и любой другой компьютер, подключенный к Интернет — может быть взломан.
                          Веревка IEE1394 и драйвер устроены так, что любое злоумышленное действие с веревкой не внешнем сервере, становится известным на внутреннем сервере. И он просто разрывает связь до выяснения причин или переходит на резерв.
                          • UFO just landed and posted this here
                          +3

                          alexkunun: точно так. описанная реализация — типичный случай security by obscurity.


                          для борьбы с возможными уязвимостями реализации ip вместо него используется некий самодельный протокол туннелирования. с собственноручно изобретенными механизмами обнаружения и предотвращения вторжений.


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

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

                            … ну либо они сильно ограничили функциональность, тем самым ограничив атакуемую область, что упрощает их задачу.

                              0

                              ну тут остаётся только гадать ) информации в статье недостаточно для подобных выводов.

                              • UFO just landed and posted this here
                                  0
                                  Даже если так, у них осталась общая функциональность HTTP

                                  Если осталась. Я как-то имел дело с одним "защищенным соединением", так там никакие практически полезные действия были невозможны.


                                  А значит утверждение «безопасный Интернет — это реальность» — неверно.

                                  Ну в общем, да. То, что описано в статье, выглядит как типичный рекламный b/s (собственно, он местами почти дословно совпадает с рекламной информацией одного из продуктов, упомянутых в комментариях), ориентированный на громкие утверждения с яркими метафорами.


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

                                    0

                                    это да. для статьи на техническом ресурсе лучше бы поменьше аналогий с ядерной бомбой, и побольше подробностей реализации )

                              +1
                              В вашем случае ещё можно продавать (разумеется, с ценником в 3-5 раз выше) систему, состоящую не из двух, а трех (четырех, пяти ?) машин, каждая с отличной от других (это важно!) ОС (типа linux+freebsd+solaris), сопряженные между собой системами, разработанными разными! (это тоже важно) командами программистов.
                              Вероятность проникновения будет уменьшаться экспоненциально относительно числа слоев )
                                +1

                                ну да. а ещё можно подрядить электронщиков разработать собственное коммуникационное железо со своими драйверами.

                                0
                                Схема на картинке ошибочная.
                                Например: два компьютера (КОМП1 и КОМП2) из внутренней сети обращаются на два разных адреса URL3 и URL4, после чего сервер Se, асинхронно отправляет пакеты с данными (D5 и D6) серверу Si.
                                И к какому компьютеру он их направит, к КОМП1 или КОМП2?
                                  0
                                  Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов и ставит соответствие пришедших ответов отосланным запросам.
                                    0
                                    Автором статьи утверждается что компьютеры во внутренней сети могут иметь сетевые адреса совпадающие с компьютерами в интернете так как между серверами Si и Se передаются только данные без сетевых адресов.
                                    Таким образом, точка подключения Shield обеспечивает:

                                    «Отсутствие взаимодействия на сетевом уровне между внутренним Si и внешним Se серверами и как следствие сохранение независимости защищенной и публичной вычислительных сетей, вплоть до того, что они могут иметь одинаковую IP-адресацию;»

                                    Если есть таблица аналогичная NAT, то если злоумышленник захватит сначала внешний сервер и соответственно получит доступ к этой таблице, то тогда возникает вопрос «Отчего в этом случае защищает внутренний сервер?», ведь он (злоумышленник) сможет направлять IP пакеты во внутреннюю сеть просто подменив адрес получателя взяв его из этой таблицы.
                                      0
                                      Понятное дело, что этот велосипед ничем не лучше NAT.
                                        –1
                                        Да, именно так насчет таблицы. А вот есть принципиальная разница.
                                        NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
                                        Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.

                                        приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
                                        Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
                                        Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!

                                          0
                                          В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.

                                          Вы утверждаете что в отличии от NAT, в вашей системе, если злоумышленник захватит управление внешним сервером, то он не сможет получить доступ (отправлять пакеты во внутреннюю), но здесь логическая ошибка. Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
                                          Конечно получить доступ во внутреннюю сеть при наличии такой защиты немного сложнее, но только чуточку сложнее. Надо всего лишь дождаться пока какой либо пользователь из внутренней сети обратится в интернет.
                                          Вы же утверждаете что ваш продукт является очень надёжной защитой и создаёте этим у пользователей чувство ложной безопасности. А значит пользователи будут более беспечными и например установят пароль «1234».
                                            0
                                            Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.

                                            Он отправляет не пакете IP, а данные. И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
                                              0
                                              И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!

                                              Что мешает делать такую же проверку на NAT?

                                                0
                                                Так она должна быть там!
                                                  0

                                                  … а если она там есть, то она и является достаточной защитой.

                                                    0
                                                    Нет не является! Речь идет только про данные. А IP-стек и NAT осталися!!!
                                                      0

                                                      Проверяйте данные до попадания в "уязвимый" IP-стек.


                                                      BTW, на Se тоже есть IP-стек, на который точно так же можно совершить атаку.

                                                    0
                                                    В таком случае возвращаемся к первичному вопросу — чем это лучше стандартного и проверенного NAT/HTTP-Proxy? Ваш способ чисто теоретически(и то не факт) защищает от взлома сервера Si, который, в общем-то, взломщику и не нужен. Взломщику нужен доступ к машинам в локальной сети, с которыми Se общается, пусть и не напрямую. И совершенно не важно с помощью какого протокола происходит общение — оно есть. А раз оно есть — есть и возможность подменить данные идущие к машине в локальной сети.
                                                      0
                                                      И то ошибся, даже от взлома Si ваш способ не защищает т.к. Si обрабатывает данные, пришедшие от Se для определения кому их дальше переслать, а соответственно может быть взломан или выведен из строя.
                                                        0
                                                        Ваш способ чисто теоретически(и то не факт) защищает от взлома сервера Si. Взломщику нужен доступ к машинам в локальной сети

                                                        Т.Е. защищает машины локальной сети. Вы ответили.
                                                          0
                                                          NAT точно так же защищает, ведь снаружи запросы не проходят внутрь, кроме разрешённых правилами. Вы просто утверждаете, что ваш самописный севис безопаснее десятилениями вылизаного iptables.
                                                          Просто сделайте NAT на внутреннем роутере (сервере) к внешнему, который подключен к Интернет. Ничего не изменится с точки зрения безопасности, костыли в виде FireWire не нужны.
                                                    0
                                                    Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.

                                                    Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.

                                                    А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?

                                                    Ведь мы из утверждения Дейкстры предполагаем что Se взломан злоумышленниками и имитирует работу вэб-портала и внешнего сервера. И на запрос вэб-страницы от пользователя, присылает ему в ответ, свою страницу с javascript. А javascript обходит песочницу и взламывает внутренний сервер Si по протоколам интернета.
                                                      0
                                                      Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.

                                                      Защищается все как написано
                                                      А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?

                                                      Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.
                                                        0
                                                        Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.

                                                        Так всё-таки Si получает от Sе IP-пакеты, а не только «данные»?
                                            –1
                                            Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов

                                            Да, именно так насчет таблицы. А вот есть принципиальная разница.
                                            NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
                                            Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
                                            Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!

                                              0
                                              Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!

                                              Вы это серьезно? "Следуя Дейкстре дыры могут обнаружиться" в том коде, который отвечает за общение между Se и Si, отсюда возможность попасть на Si, далее аналогично.

                                                0
                                                Попадите! Как?
                                                  0

                                                  Используя дыры в Si/Se.

                                                    0
                                                    Дыры есть, я связи между ними нету
                                                      0

                                                      Как же нету-то? Канал, по которому вы данные передаете — есть, вот вам и связь.


                                                      (слушайте, люди умудряются передавать данные через air gap, а у вас две железки проводом соединены)

                                                        –2
                                                        А что по проводу-то передается?
                                                          0

                                                          Данные. Точно так же, как и по ethernet, и любому другому каналу данных.

                                                            0
                                                            Именно данные, а не IP-пакет. А данные мы уже с вами проверили на отсутсвие вредогосности. Т.е. они безопасны, что и требовалось доказать.
                                                              0
                                                              А данные мы уже с вами проверили на отсутсвие вредогосности. Т.е. они безопасны

                                                              Не безопасны.


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


                                                              Во-вторых, если предположить, что такая проверка возможна, то что мешает проверять ей сразу IP-пакеты?

                                                                –1
                                                                Проверяйте
                                                                  0

                                                                  … следовательно, ваше утверждение о том, что "имея неограниченное время доступа к точке подключения к сети Интернет, злоумышленник может, используя стандартные сетевые протоколы, стандартное программное обеспечение и найденные в нем ошибки или ошибки в его настройках осуществить несанкционированный доступ через точку подключения внутрь корпоративной сети со всеми вытекающими последствиями" — либо ложно, либо точно так же применимо и к вашему решению.

                                                                    0
                                                                    Так в чем противоречие?
                                                                    У вас как у свободного человека есть право выбора ставить не только МЭ, NAT, Shield в конце концов, но и отразных производителей.
                                                                    Точно также как у вас выбор покупать Мерседес или Вец, колбасу вареную или копченую. Используйте свое право. Экспериментируйте и т.д
                                                                      0
                                                                      Так в чем противоречие?

                                                                      В том, что ваша статья утверждает, что ваше решение не подвержено этой уязвимости. Или я вас неправильно понял, и вы согласны, что ваш "безопасный" узел уязвим в той же самой мере, что и любой другой?

                                                                        0
                                                                        Как же защищаемая сеть уязвима, напрмер, по IP-стеку, если нет никакой связи по IP,,
                                                                          0
                                                                          Как же защищаемая сеть уязвима, напрмер, по IP-стеку

                                                                          А никто не утверждает, что защищаемая сеть уязвима "по IP-стеку". Она уязвима как сеть, в том смысле, что возможно проникновение в ее границы. Дальше, когда атакующий находится в этих границах, он уже может использовать те уязвимости, которые он может/хочет для дальнейшей атаки на устройства в этой сети.

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

                                          В физический уровень FireWire TCP не инапсулируется. Но вы уловили главное.
                                          image
                                          Хоть немного, но надо говорить о реализации.
                                          На внутреннем сервере 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 и передаются клиенту/браузеру в защищенной сети.
                                            0

                                            Поправьте меня, если я ошибаюсь: вы описали типичный http-прокси (не важно, со сколькими уровнями развязки внутри), так?

                                              0

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


                                              кстати, стало интересно, каким образом в этой схеме они сгружают в squid информацию о том, с какого клиента пришёл запрос. предполагаю, что никак, и с точки зрения сквида все запросы идут c адреса Se. То есть вдобавок к обрезанию понятия "интернет" только до http через прокси, они ещё и потеряли часть возможностей настройки сквида.

                                                –1
                                                С точки зрения конечного пользователя браузера — да!
                                                  0

                                                  А с чьей точки зрения нет?

                                                0
                                                Так и не понятно, каким образом внутренний сервер Si при получении данных от внешнего сервера, определяет какому клиенту (IP-адрес во внутренней сети) перенаправить эти данные?
                                                +2
                                                FireWire это всего лишь еще один физический уровень.
                                                В него все равно нужно инкапсулировать тот же TCP, что бы, например, получить доступ к локальному SQL.
                                                И в чем новизна? Вы придумали всего лишь еще один физический уровень, которых и без того огромное кол-во. Как только у вас станет необходимость гонять по нему tcp/ip (а она встанет рано или поздно), вы тут же придете к существующей ныне простой схеме NAT-a.
                                                Грубо говоря, у вас реализация DMZ с неким специфическим физическим уровнем.
                                                Или я чего-то недопонимаю? Читал, признаюсь, несколько по-диагонали…
                                                  –2
                                                  Что касается NAT. NAT не делает сети физически независимыми. А здесь речь идет именно о независимости сетей.
                                                    0
                                                    А здесь речь идет именно о независимости сетей.

                                                    … иии что? От какого процента потенциальных атак вас это гарантированно защищает?

                                                      –1
                                                      Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.

                                                      А чтотакое 100% потенциальных атак?
                                                      А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
                                                      Межсетевой экран — это сколько %,
                                                        0
                                                        Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.

                                                        Я стесняюсь спросить, вы про NAT слышали вообще? У компьютера, за которым я сижу сейчас, IP-адрес 192.168.1.4 — вы можете получить к нему доступ по IP-адресу, этому, или любому другому, с компьютера, находящегося в публичной сети?


                                                        А чтотакое 100% потенциальных атак?
                                                        А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
                                                        Межсетевой экран — это сколько %,

                                                        Окей, переформулируем вопрос: как вы оцениваете эффективность предлагаемого вами способа защиты?

                                                          +3

                                                          защита сети — это некий комплекс мер, каждая из которых предположительно отсекает некий процент потенциальных атак.


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


                                                          уровень протокола ip, на защиту которого направлено ваше решение, и без того является одним из самых защищённых — реализации протестированы десятилетиями и миллионами установок.


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


                                                          то есть, на поверку декларируемый "безопасный интернет" закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне "ну firewire это же не ethernet, его взломать гораздо труднее".

                                                      +1

                                                      Вы слышали про DMA attack?
                                                      Очень странно выбирать FireWire (IEEE 1394) в качестве безопасного транспорта/соединения.

                                                        0

                                                        Давайте, кстати, все-таки уточним одну вещь. Предлагаемое вами решение является транспортом для любого TCP/IP потока (т.е., я могу просто открыть соединение на произвольный интересующий меня адрес и работать с ним), или только для конкретных поддерживаемых протоколов прикладного уровня (например, HTTP)? Если для прикладных протоколов, то возможно ли пропускать шифрованные данные без их анализа (например, проксирование HTTPS без MITM)? Позволяет ли оно выставлять ресурсы изнутри сети наружу (публикация веб-сервера или машины для удаленного доступа)?

                                                        Only users with full accounts can post comments. Log in, please.