В рамках обсуждаемой проблемы можно выделить два наиболее вероятных способа нарушения конфиденциальности информации:
- Прослушивание и реконструкция трафика передаваемых данных между корпоративными сетями в некоторой точке публичной сети;
- Проникновение в корпоративную сеть в точке подключения к публичной сети и/или нарушение ее нормального функционирования.
Перефразируя Архимеда, который говорил «дайте мне точку опоры и я переверну Землю», можно сказать «дайте мне точку подключения вашей сети к сети Интернет и я взломаю вашу сеть». Поскольку публичная сеть (в данном случае Интернет) находится вне сферы контроля администраторов безопасности автоматизированных систем органов государственного управления и организаций РФ, то единственным способом управления риском прослушивания трафика при прохождении его через публичную сеть является применение криптографических средств. В качестве таких средств могут выступать VPN, шифрованные туннели, а при доступе на порталы применяться протокол tls/https.
Более серьезной угрозой является проникновение в вычислительные сети органов государственного управления и организаций РФ через точки подключения к публичной сети, когда появляется возможность не только доступа к конфиденциальной информации, но и возможность ее разрушение, когда никакая криптозащита не спасет от причиненного ущерба.
Управление риском проникновения в ЛВС через точку подключения к публичной сети включает решение двух основных технических вопросов:
— сокрытие структуры внутренней корпоративной сети;
— защита точки подключения к корпоративной сети от НСД.
Вместе с тем, если рассматривать сеть Интернет (или любую другую публичную сеть) не как IP-сеть, а как некоторую субстанцию, предоставляющую набор услуг (электронная почта, транспортная среда, ftp-сервера, Web-сервера, портал Госуслуг и т.д.), то оказывается, что можно найти технические решения, которую позволяют использовать эти услуги, не предоставляя точки доступа злоумышленнику.
И так, чтобы предотвратить несанкционированный доступ из сети Интернет на компьютер пользователя или в корпоративную сеть, следуя постулату Архимеда, надо лишить злоумышленника доступа к точки входа в ЛВС или защищаемого компьютера. Как это сделать?
Сегодня, наверное, каждый знает, что в атомных бомбах используют два полушария . И до тех пор, пока они не соединились в один смертоносный шар, эта бомба в виде двух полушарий не предоставляет угрозы. По аналогии с атомной бомбой точку подключения к сети Интернет, также можно сделать состоящей из двух «полушарий» — двух серверов, обменивающихся между собой данными по высокоскоростному интерфейсу, например, IEE1394:
Как видно из рисунка, разделяет локальные и публичную сети и не приводит к появлению каких-либо возможностей для доступа по любым сетевым протоколам из сети Интернет ЛВС, а также не допускает доступ пользователей ЛВС в Интернет.
Для простоты в дальнейшем реализацию такого подключения будем называть бинарной точкой подключения к Интернет или точкой Shield – безопасной/защищенной точкой подключения:
На внутреннем сервере Si нет никакой информации о публичной сети. Так же и на внешнем сервере Se нет никакой информации о внутренней ЛВС. Это является одной из причин невозможности прорыва из Интернета во внутреннюю ЛВС, и, наоборот, из внутренней ЛВС в публичную сеть. Даже в случае, если злоумышленнику в открытой сети станет известен какой-либо адрес во внутренней сети, то, используя его, он может попасть куда угодно, только не во внутреннюю сеть.
Таким образом, точка подключения Shield обеспечивает:
- Отсутствие взаимодействия на сетевом уровне между внутренним Si и внешним Se серверами и как следствие сохранение независимости защищенной и публичной вычислительных сетей, вплоть до того, что они могут иметь одинаковую IP-адресацию;
- Прозрачность как для стандартных протоколов (http, https, ftp, ssl, pop3 и т.п.), так и возможность написания собственных протоколов для систем «клиент-сервер»;
- Доступ пользователей защищенных вычислительных сетей к различным услугам публичных сетей при отсутствии сетевого взаимодействия между защищенной и публичной сетями;
- Возможность раздельного администрирования внешнего и внутреннего шлюзов: администратор внешнего шлюза не имеет доступа (не знает пароля) к внутреннему шлюзу и наоборот.
Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.
Слабым звеном остается внешний сервер Se точки доступа Shield, который непосредственно подключен к сети Интернет. Злоумышленник может получить контроль над этим сервером, однако он не сможет достичь своей цели — проникнуть в ЛВС и нанести ей ущерб. Но поскольку об этом сразу же станет известно администратору ЛВС (например, пропадет связь с внешним миром), то всегда можно перейти на резервный канал и восстановить связь с внешним миром.
Комментарии (172)
zuborg
25.01.2017 10:55Какую роль выполняет FireWare? Почему не Ethernet? Полагается, что использование FireWare будет более безопасным? За счет чего?
saipr
25.01.2017 11:34На самом деле может быть использован любой «шнурок», хоть модем. Первоначально использовалась веревку USB. Но IEE1394 оказалась, с точки зрения передачи данных, надежнее.
Почему не Ethernet?
Прежде всего психологически — связь с сетевым протоколом и не более того. По Ethernet точно также можно передавать только данные. Кстати именно Ethernet используется для передачи данных в однонапрвленных шлюзах.
Kliba
25.01.2017 10:57Блин, из андроид клиента нельзя редактировать. злоумышленнику и завладев естественно.
vip1953
25.01.2017 11:03А где-нибудь что-нибудь по этой технологии сделано и реально стоит?
saipr
25.01.2017 11:43Когда-то давно в РЖД стояли ПАК «Щит-Почта». Не знаю стоят ли сейчас.
В ЦБ РФ широко используются ПАК «SMS-FW».
А кое-где есть VPN, построенные на ПАК «Shield Channel — FW».
Stalker_RED
25.01.2017 11:40Кроме всего прочего, атомные бомбы из «двух полушарий» не делают примерно со времен Хиросимы.
NLO
25.01.2017 11:54НЛО прилетело и опубликовало эту надпись здесь
saipr
25.01.2017 11:56Согласно rfc2734 (IPv4 over IEEE 1394)?
Нет, конечно. Сетевого взаимодействия нет. Написан драйвер, по которому как по каналу (pipe) передаются данные.NLO
25.01.2017 12:35НЛО прилетело и опубликовало эту надпись здесь
saipr
25.01.2017 12:41Обсолютно правильно.
устанавливает соединение с внешним ресурсом
Более того, если мы хотим получить доступ к Web-ресурсам Интернет, то в качестве внешнего ресурса, как правило, используется SQUID
lair
25.01.2017 12:47-1… что-то мне этот "безопасный интернет" все больше напоминает безопасный секс. По телефону, обернутому в два презерватива.
saipr
25.01.2017 13:53Только в вашем сексе кто-нибудь получает удовольствие (уж не операционистка ли?)?
А здесь реально человек получает требуемую информацию, не боясь что получит венерическое заболевание.lair
25.01.2017 13:54Ключевой вопрос (а) получает ли и (б) чем гарантируется отсутствие заражения.
saipr
25.01.2017 14:00Отсутствием контакта с операционистой или как правильно называть гетеру на другом конце телефона.
Kliba
25.01.2017 14:07+2Уже не первый раз намекаем — смена открытого, общеизвестного протокола на закрытый самописный сама по себе ничего не гарантирует. И общение локальной сети с интернетом как было так и осталось. То, что внутренний и внешний шлюз общаются не по ethernet протоколу, а по какому-то другому не значит, что через этот другой протокол не может быть проведена атака.
lair
25.01.2017 14:08Зато есть контакт с информацией. А в мире информационных технологий информация вполне работает как переносчик заражения.
saipr
25.01.2017 14:39Информация — это прежде всего источник знаний. И с ней надо обращаться осторожно. И, естественно, это информация, полученная не с забора.
lair
25.01.2017 14:43Нет никакого "естественно", вот в чем дело. Чтобы информация приходила "не с забора" и с ней "обращались осторожно", нужно применять комплекс защитных мер, который вашим решением не обеспечивается. Следовательно — как уже заметили ниже — ваше утверждение "гарантируется отсутствие заражения" ложно.
saipr
25.01.2017 14:54-1Все подтверждает эксперимент и опыт.
В ЦБ РБ эта технология используется более 10 лет. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать. И количество устройств каждыц год растет.
Да, чуть не забыл. Первым, кто использовал эту технологию, было Федеральное Собрание для безопасного использования электронной почты.
ваше утверждение «гарантируется отсутствие заражения» ложно
Нет проблем, значит у вас есть доказательство (как у теоремы Пифагора — Пифагоровы штаны не все стороны равны).
Выложте это доказательство.
lair
25.01.2017 14:59-1Все подтверждает эксперимент и опыт. И уж как они проверяли с точки зрения безопасности, прежде чем начали использовать.
Вам вашу же цитату из Дийкстры напомнить?
Первым, кто использовал эту технологию, было Федеральное Собрание для безопасного использования электронной почты.
И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?
Нет проблем, значит у вас есть доказательство
Отнюдь. Гарантия ваша, вам и доказывать.
(нет, серьезно, вам надо привести один тривиальный пример с фишинговым письмом?)
saipr
25.01.2017 15:24И что, благодаря этой технологии в электронной почте Федерального Собрания больше нельзя переслать вирус?
Конечно можно. Как говорят «бумага все стерпит». Проверка достоверность данных (как в разведке), их незараженность (как при сексе) — лежит на получателе. И другого быть ничего не может. Поэтому получаемые данные с внешнего сервера (он же принадлежит Интернет) должны быть проверены и перепроверены как на внешнем, так и на внутреннем серверах.
Проверка может включать проверку на вирусы, проверку на контент и т.д.
lair
25.01.2017 15:26Конечно можно.
Значит, заражение возможно. Что и требовалось доказать.
(То же применимо к любому другому прикладному каналу.)
i_am_mry
25.01.2017 11:56+2«Более серьезной угрозой является проникновение в вычислительные сети органов государственного управления и организаций РФ через точки подключения к публичной сети, когда появляется возможность не только доступа к конфиденциальной информации, но и возможность ее разрушение, когда никакая криптозащита не спасет от причиненного ущерба»
насколько я понял речь идет о серверах с публичным доступом. Но вроде бы есть стандартная практика размещения веб-серверов в DMZ зоне.
Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.
И все же я не понял, зачем нам использовать странную прослойку в виде FireWire вместо нормального DMZ?
В чем плюсы?saipr
25.01.2017 11:58-3А как подключена ваша DMZ к внешнему миру?
И окажется, что это сетевые протоколы, это межсетевые экраны и т.д. Но чтобы защитить межсетевой экран, надо поставить еще один и т.д.jok40
27.01.2017 11:15Сервер, к которому есть доступ из интернета, находится в DMZ и отгорожен от корпоративной сети фаерволом, ядро которого находится в корпоративной сети. Для взломщика, получившего доступ к этому серверу в DMZ с помощью эксплуатации какой-либо уязвимости, фаервол, отгораживающий его от корпоративной сети, будет выглядеть как монолитная железобетонная стена. Зачем этот фаервол ещё защищать?
Zolushok
25.01.2017 12:01+2При отсутствии общедоступных из внешней сети сервисов на сервере-маршрутизаторе единственная возможность «получить над ним контроль» — уязвимость в реализации TCP/IP.
Какой протокол вы используете поверх FireWire? Вы считаете, что он реализован безопаснее, чем IP?
alexkunin
25.01.2017 12:12+2Правильно ли я понимаю, что «Точка Shield» эквивалентна любому общепринятому http-прокси (не NAT)? И этот прокси состоит из двух частей, между которыми есть некий канал — в одно сторону идут прокси-запросы («дайте мне воооон тот ресурс по этому вот урлю»), в другую — ответы на эти запросы («вот вам нате гифка анимированная»). И этот некий канал вроде оптопары — «гальваническая», так сказать, развязка, у ЛВС и Si больше нет доступа к интернету и Se.
Хорошо. А что мешает злоумышленнику сделать так: взломать внешний Se, покрутиться там, изучить протокол «оптопары», и затем послать по «оптопаре» некий специально сформированный отзыв, который приведет в отсылке с Si на компьютер в ЛВС специально сформированного пакета, который вызовет переполнение буфера и исполнение произвольного кода?saipr
25.01.2017 12:22И этот некий канал вроде оптопары — «гальваническая», так сказать, развязка
Если гальваническая развязка — это оптика, но с сохранением IP-взаимодействия, то это не развязка.
Внешний сервер, как и любой другой компьютер, подключенный к Интернет — может быть взломан.
Веревка IEE1394 и драйвер устроены так, что любое злоумышленное действие с веревкой не внешнем сервере, становится известным на внутреннем сервере. И он просто разрывает связь до выяснения причин или переходит на резерв.alexkunin
25.01.2017 12:27+4Т.е. вы заявляете, что ПО (драйверы) непробиваемы? Но ведь «Никакими методами тестирования невозможно доказать отсутствие ошибок в программном обеспечении». Стало быть, это безопасность через сокрытие — до того момента, когда этот драйвер не попадет в заинтересованные руки.
Т.е. вся система безопасности строится на непогрешимости одного самописного (ну, в смысле не обкатанного 20-30 лет — как винде и линуксе, хотя и там находят ошибки) драйвера?
И еще момент: «злоумышленное действие» — значит, есть некая система, оценивающая уровень злоумышленности. И она либо идеальна (сомнительно, по понятным причинам, смотрите постулат Дейкстры), либо недобивает (пропускает), либо перебивает (ложные срабатывания), либо откровенно лажает (просто ошибки в оценке).
Zolushok
25.01.2017 12:41+3alexkunun: точно так. описанная реализация — типичный случай security by obscurity.
для борьбы с возможными уязвимостями реализации ip вместо него используется некий самодельный протокол туннелирования. с собственноручно изобретенными механизмами обнаружения и предотвращения вторжений.
подход при всей спорности имеет право на жизнь, но подразумевает, что квалификация людей, разработавших этот костыль, выше квалификации тех, кто писал реализацию ip и механизмов контроля вторжений для него. ))
lair
25.01.2017 12:46подход при всей спорности имеет право на жизнь, но подразумевает, что квалификация людей, разработавших этот костыль, выше квалификации тех, кто писал реализацию ip и механизмов контроля вторжений для него.
… ну либо они сильно ограничили функциональность, тем самым ограничив атакуемую область, что упрощает их задачу.
Zolushok
25.01.2017 12:49ну тут остаётся только гадать ) информации в статье недостаточно для подобных выводов.
alexkunin
25.01.2017 12:50+1Даже если так, у них осталась общая функциональность HTTP, а значит, все злоумышленное, основанное на куках, сессиях, уязвимостях браузеров и т.д. — все это будет продолжать работать (справедливости ради, частично эти проблемы случаются на веб-серверах, и никаким межсетевым экраном их не решить). А значит утверждение «безопасный Интернет — это реальность» — неверно.
lair
25.01.2017 12:56Даже если так, у них осталась общая функциональность HTTP
Если осталась. Я как-то имел дело с одним "защищенным соединением", так там никакие практически полезные действия были невозможны.
А значит утверждение «безопасный Интернет — это реальность» — неверно.
Ну в общем, да. То, что описано в статье, выглядит как типичный рекламный b/s (собственно, он местами почти дословно совпадает с рекламной информацией одного из продуктов, упомянутых в комментариях), ориентированный на громкие утверждения с яркими метафорами.
При этом, несомненно, насколько-то повысить защищенность сети таким образом можно — точно так же, как ее повышает еще один защищающий сервер, добавленный в цепочку "клиент-поставщик", предпочтительно, с минимально собственной функциональностью.
Zolushok
25.01.2017 13:15это да. для статьи на техническом ресурсе лучше бы поменьше аналогий с ядерной бомбой, и побольше подробностей реализации )
zuborg
25.01.2017 15:44+1В вашем случае ещё можно продавать (разумеется, с ценником в 3-5 раз выше) систему, состоящую не из двух, а трех (четырех, пяти ?) машин, каждая с отличной от других (это важно!) ОС (типа linux+freebsd+solaris), сопряженные между собой системами, разработанными разными! (это тоже важно) командами программистов.
Вероятность проникновения будет уменьшаться экспоненциально относительно числа слоев )Zolushok
25.01.2017 16:34+1ну да. а ещё можно подрядить электронщиков разработать собственное коммуникационное железо со своими драйверами.
vasiliysenin
25.01.2017 16:40Схема на картинке ошибочная.
Например: два компьютера (КОМП1 и КОМП2) из внутренней сети обращаются на два разных адреса URL3 и URL4, после чего сервер Se, асинхронно отправляет пакеты с данными (D5 и D6) серверу Si.
И к какому компьютеру он их направит, к КОМП1 или КОМП2?
Frankenstine
27.01.2017 10:53Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов и ставит соответствие пришедших ответов отосланным запросам.
vasiliysenin
27.01.2017 13:32Автором статьи утверждается что компьютеры во внутренней сети могут иметь сетевые адреса совпадающие с компьютерами в интернете так как между серверами Si и Se передаются только данные без сетевых адресов.
Таким образом, точка подключения Shield обеспечивает:
«Отсутствие взаимодействия на сетевом уровне между внутренним Si и внешним Se серверами и как следствие сохранение независимости защищенной и публичной вычислительных сетей, вплоть до того, что они могут иметь одинаковую IP-адресацию;»
Если есть таблица аналогичная NAT, то если злоумышленник захватит сначала внешний сервер и соответственно получит доступ к этой таблице, то тогда возникает вопрос «Отчего в этом случае защищает внутренний сервер?», ведь он (злоумышленник) сможет направлять IP пакеты во внутреннюю сеть просто подменив адрес получателя взяв его из этой таблицы.Frankenstine
27.01.2017 14:02Понятное дело, что этот велосипед ничем не лучше NAT.
saipr
27.01.2017 14:52-1Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
vasiliysenin
27.01.2017 15:40В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
Вы утверждаете что в отличии от NAT, в вашей системе, если злоумышленник захватит управление внешним сервером, то он не сможет получить доступ (отправлять пакеты во внутреннюю), но здесь логическая ошибка. Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
Конечно получить доступ во внутреннюю сеть при наличии такой защиты немного сложнее, но только чуточку сложнее. Надо всего лишь дождаться пока какой либо пользователь из внутренней сети обратится в интернет.
Вы же утверждаете что ваш продукт является очень надёжной защитой и создаёте этим у пользователей чувство ложной безопасности. А значит пользователи будут более беспечными и например установят пароль «1234».saipr
27.01.2017 15:54Ведь внешний сервер может отправлять пакеты данных во внутреннюю сеть, значит и внешний сервер захваченный злоумышленниками, тоже может.
Он отправляет не пакете IP, а данные. И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!lair
27.01.2017 16:00И мы договорились (см.выше) эти данные проверять как на внешнем, так и внутреннем сервере на наличие вирусов (далее степерь доверия к этим проверкам), синтаксис и семантику прикладных протоколов, наконец контент!!!
Что мешает делать такую же проверку на NAT?
saipr
27.01.2017 16:20Так она должна быть там!
Kliba
27.01.2017 16:48В таком случае возвращаемся к первичному вопросу — чем это лучше стандартного и проверенного NAT/HTTP-Proxy? Ваш способ чисто теоретически(и то не факт) защищает от взлома сервера Si, который, в общем-то, взломщику и не нужен. Взломщику нужен доступ к машинам в локальной сети, с которыми Se общается, пусть и не напрямую. И совершенно не важно с помощью какого протокола происходит общение — оно есть. А раз оно есть — есть и возможность подменить данные идущие к машине в локальной сети.
Kliba
27.01.2017 16:57И то ошибся, даже от взлома Si ваш способ не защищает т.к. Si обрабатывает данные, пришедшие от Se для определения кому их дальше переслать, а соответственно может быть взломан или выведен из строя.
saipr
27.01.2017 19:30Ваш способ чисто теоретически(и то не факт) защищает от взлома сервера Si. Взломщику нужен доступ к машинам в локальной сети
Т.Е. защищает машины локальной сети. Вы ответили.Frankenstine
30.01.2017 13:11NAT точно так же защищает, ведь снаружи запросы не проходят внутрь, кроме разрешённых правилами. Вы просто утверждаете, что ваш самописный севис безопаснее десятилениями вылизаного iptables.
Просто сделайте NAT на внутреннем роутере (сервере) к внешнему, который подключен к Интернет. Ничего не изменится с точки зрения безопасности, костыли в виде FireWire не нужны.
vasiliysenin
28.01.2017 15:09Точку подключения Shield можно рассматривать как прокси-сервер при доступе пользователей ЛВС с использованием браузеров к Web-ресурсам сети интернет.
Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.
А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?
Ведь мы из утверждения Дейкстры предполагаем что Se взломан злоумышленниками и имитирует работу вэб-портала и внешнего сервера. И на запрос вэб-страницы от пользователя, присылает ему в ответ, свою страницу с javascript. А javascript обходит песочницу и взламывает внутренний сервер Si по протоколам интернета.saipr
28.01.2017 16:20Если Web-ресурсы предоставляют доступ по http, то тогда понятно, но в этом случае ничего и не защищается.
Защищается все как написано
А если Web-ресурсы предоставляют доступ по https, то тогда откуда сервер Si берёт данные для проверки на вирусы?
Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.vasiliysenin
30.01.2017 11:50Данные, помимо возможности нахождения в зашифрованном куске, могут находиться в IP-пакете рядом с этим куском. Отсюда и могут взяться.
Так всё-таки Si получает от Sе IP-пакеты, а не только «данные»?
saipr
27.01.2017 14:43-1Вероятно, подразумевается что Se выполняет роль, аналогичную NAT и держит таблицу, по которой ведёт маркировку и учёт отправленных пакетов
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
lair
27.01.2017 14:50Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Вы это серьезно? "Следуя Дейкстре дыры могут обнаружиться" в том коде, который отвечает за общение между Se и Si, отсюда возможность попасть на Si, далее аналогично.
saipr
27.01.2017 16:14Попадите! Как?
lair
27.01.2017 16:17Используя дыры в Si/Se.
saipr
27.01.2017 16:24Дыры есть, я связи между ними нету
lair
27.01.2017 16:33Как же нету-то? Канал, по которому вы данные передаете — есть, вот вам и связь.
(слушайте, люди умудряются передавать данные через air gap, а у вас две железки проводом соединены)
saipr
27.01.2017 16:52-2А что по проводу-то передается?
lair
27.01.2017 16:56Данные. Точно так же, как и по ethernet, и любому другому каналу данных.
saipr
27.01.2017 19:33Именно данные, а не IP-пакет. А данные мы уже с вами проверили на отсутсвие вредогосности. Т.е. они безопасны, что и требовалось доказать.
lair
27.01.2017 21:29А данные мы уже с вами проверили на отсутсвие вредогосности. Т.е. они безопасны
Не безопасны.
Во-первых, возможность такой проверки противоречит вашему же тезису о том, что в любой программе защиты есть уязвимости.
Во-вторых, если предположить, что такая проверка возможна, то что мешает проверять ей сразу IP-пакеты?
saipr
27.01.2017 22:46-1Проверяйте
lair
27.01.2017 22:50… следовательно, ваше утверждение о том, что "имея неограниченное время доступа к точке подключения к сети Интернет, злоумышленник может, используя стандартные сетевые протоколы, стандартное программное обеспечение и найденные в нем ошибки или ошибки в его настройках осуществить несанкционированный доступ через точку подключения внутрь корпоративной сети со всеми вытекающими последствиями" — либо ложно, либо точно так же применимо и к вашему решению.
saipr
28.01.2017 14:39Так в чем противоречие?
У вас как у свободного человека есть право выбора ставить не только МЭ, NAT, Shield в конце концов, но и отразных производителей.
Точно также как у вас выбор покупать Мерседес или Вец, колбасу вареную или копченую. Используйте свое право. Экспериментируйте и т.дlair
28.01.2017 14:43Так в чем противоречие?
В том, что ваша статья утверждает, что ваше решение не подвержено этой уязвимости. Или я вас неправильно понял, и вы согласны, что ваш "безопасный" узел уязвим в той же самой мере, что и любой другой?
saipr
28.01.2017 15:01Как же защищаемая сеть уязвима, напрмер, по IP-стеку, если нет никакой связи по IP,,
lair
28.01.2017 15:03Как же защищаемая сеть уязвима, напрмер, по IP-стеку
А никто не утверждает, что защищаемая сеть уязвима "по IP-стеку". Она уязвима как сеть, в том смысле, что возможно проникновение в ее границы. Дальше, когда атакующий находится в этих границах, он уже может использовать те уязвимости, которые он может/хочет для дальнейшей атаки на устройства в этой сети.
saipr
25.01.2017 16:42Да, вы правы, на картинке показан случай когда из внутренней сети идет только одно обращение. При множественных запросах картинка чуть-чуть меняется.
saipr
25.01.2017 19:03FireWire это всего лишь еще один физический уровень.
В него все равно нужно инкапсулировать тот же 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 и передаются клиенту/браузеру в защищенной сети.lair
26.01.2017 12:57Поправьте меня, если я ошибаюсь: вы описали типичный http-прокси (не важно, со сколькими уровнями развязки внутри), так?
Zolushok
27.01.2017 15:07если бы эту картинку вставили в изначальный пост, вопросов в комментариях было бы на порядок меньше.
кстати, стало интересно, каким образом в этой схеме они сгружают в squid информацию о том, с какого клиента пришёл запрос. предполагаю, что никак, и с точки зрения сквида все запросы идут c адреса Se. То есть вдобавок к обрезанию понятия "интернет" только до http через прокси, они ещё и потеряли часть возможностей настройки сквида.
vasiliysenin
26.01.2017 13:13Так и не понятно, каким образом внутренний сервер Si при получении данных от внешнего сервера, определяет какому клиенту (IP-адрес во внутренней сети) перенаправить эти данные?
r0mik
25.01.2017 19:04+2FireWire это всего лишь еще один физический уровень.
В него все равно нужно инкапсулировать тот же TCP, что бы, например, получить доступ к локальному SQL.
И в чем новизна? Вы придумали всего лишь еще один физический уровень, которых и без того огромное кол-во. Как только у вас станет необходимость гонять по нему tcp/ip (а она встанет рано или поздно), вы тут же придете к существующей ныне простой схеме NAT-a.
Грубо говоря, у вас реализация DMZ с неким специфическим физическим уровнем.
Или я чего-то недопонимаю? Читал, признаюсь, несколько по-диагонали…
saipr
25.01.2017 19:05-2Что касается NAT. NAT не делает сети физически независимыми. А здесь речь идет именно о независимости сетей.
lair
25.01.2017 21:49А здесь речь идет именно о независимости сетей.
… иии что? От какого процента потенциальных атак вас это гарантированно защищает?
saipr
25.01.2017 22:26-1Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,lair
25.01.2017 22:30Сети независимо в том смысле, что их IP-пространства никак не пересекаются. Компьютеры, находящиеся за внутренним и внешним серверами могут иметь одинаковые IP. С компьютера, находящегося в публичной сети (за внешним сервером) нельзя получить доступ по IP-адресу ни к одному компьютеру внутренней сети.
Я стесняюсь спросить, вы про NAT слышали вообще? У компьютера, за которым я сижу сейчас, IP-адрес
192.168.1.4— вы можете получить к нему доступ по IP-адресу, этому, или любому другому, с компьютера, находящегося в публичной сети?
А чтотакое 100% потенциальных атак?
А сегодня кто и как дает некий % гарантированной защиты от потенциальных атак?
Межсетевой экран — это сколько %,Окей, переформулируем вопрос: как вы оцениваете эффективность предлагаемого вами способа защиты?
Zolushok
26.01.2017 12:19+3защита сети — это некий комплекс мер, каждая из которых предположительно отсекает некий процент потенциальных атак.
именно по этому проценту имеет смысл оценивать эффективность (и целесообразность применения) той или иной конкретной меры. абсолютной защиты не существует, нашивать на фрагменты забора титановые пластины при наличии в других местах дыр, завешенных тряпочкой — не очень целесообразно.
уровень протокола ip, на защиту которого направлено ваше решение, и без того является одним из самых защищённых — реализации протестированы десятилетиями и миллионами установок.
на порядки более уязвимы протоколы более высокого уровня, работающие например поверх http, которые никак описанной защитой не контролируются. для их эксплуатации не нужно инициировать соединение со стороны злоумышленника, на невозможности чего вы так акцентируете внимание.
то есть, на поверку декларируемый "безопасный интернет" закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне "ну firewire это же не ethernet, его взломать гораздо труднее".
saipr
27.01.2017 15:14Прорлог
Задержался с ответом — был на операционном столе
Цитата
Я стесняюсь спросить, вы про NAT слышали вообще?
Network Address Translation (NAT)
Выше я уже ответил, но повторюсь:
декларируемый «безопасный интернет» закрывает весьма узкий круг проблем, и больше напоминает эксплуатацию невежества покупателей, неспособных настроить nat и сетевой экран на уровне «ну firewire это же не ethernet, его взломать гораздо труднее».
Значит все же закрывает!!! И предотвратить использованием возможных ошибок в IP-стеке и самом NAT-е — зто вр-вашему мало?
Интересно (я уже писал выше), а как вы собираетесь защищать сетевой экран),
И самое главноеб вы собираетесь зависить от вежества и невежества покупателей? И что такое настроить правильно NAT и сетевой экран. Много я видел таких спечиалистов, «вежество»
которых приводило к останову системы. Не надо обижать покупателей.
Firewire вообще не причем (см. выше) — веревка может быть любая:
На самом деле может быть использован любой «шнурок», хоть модем. Первоначально использовалась веревку USB. Но IEE1394 оказалась, с точки зрения передачи данных, надежнее.
Почему не Ethernet?
Прежде всего психологически — связь с сетевым протоколом и не более того. По Ethernet точно также можно передавать только данные. Кстати именно Ethernet используется для передачи данных в однонапрвленных шлюзах.
Да, именно так насчет таблицы. А вот есть принципиальная разница.
NAT одним концом смотрит во внутреннюю сетку, другим во внешнюю и к нему с обоих сторон
Таблицв аналогичная NAT-у только по смыслу. Вообще таблица создается для обеспечения обслуживания множества пользователей. В ней хранится два случайных числе которые связамы с потоком (клиентом) отправляющим URL (на внутреннем сервере Si) и второе это поток на server_sms. Оба этмх числп никак не связаны и IP-адресами конкретных компьютеров, с которых были запросы. Тем более время жизни этих чисел — время обслучивания URL. Да, внешний сервер всегда может быть захвачен — ог во внешней сетке. Речь идет о предотвращении захвата внутреннего сервера. В этом принципиальное отлтчте от NAT: захватив NAT я могу захватить и внутреннюю сетку.
приходят IP-пакеты и попадают в IP-стек. Ну а затем NAT строит и/или таблицы…
Слудуя Дейкстре дыры могут обнаружиться как в IP-стеке, так и в самом NAT-e. Одсюда возможность попасть во внутреннюю сетку, а далее что хочу, то и ворочу.
Se и Si приобщении между собой никак не используют IP-стек, IP-адресацию и любые дыры здесь нам не страшны: мы не можем попасть на Si и во внутреннюю сеть!!!
Эпилог
Со здоровьем все хорошо.
Zolushok
27.01.2017 15:34+1как вы собираетесь защищать сетевой экран
как уже и писал, для начала я буду выяснять степень его защищённости «из коробки» и принимать решение, нужна ли мне дополнительная защита именно на этом уровне.
вы перед тем как решить, от чего именно вы будете защищаться, поинтересовались статистикой взлома маршрутизаторов? не через оставленный по глупости открытым наружу протокол управления, а именно через уязвимости в реализации стека ip и nat в них?saipr
27.01.2017 16:01А зачем ломать маршрутизатор?
Второе, а почему упустили межсетевой экран?
Маршрутизаторы мы не трогаем — пусть маршрутизируют спокойно.
Мы защищаем рабочее место или портал.
для начала я буду выяснять степень его защищённости «из коробки» и принимать решение, нужна ли мне дополнительная защита именно на этом уровне.
И это абсолютно верно.
Именно так поступил ЦБ и РФ и ВЭБ.
Но если вы вернее ваше предприятие попадает под требования регуляторов (ФСТЭК, ФСБ), то к сожалению пока вы не поставите первое второе третье и четвертое, не пройдете так называемую аттестацию, то вам не разрешат обрабатывать персональные данные и т.д.lair
27.01.2017 16:04А зачем ломать маршрутизатор?
Чтобы получить плацдарм для дальнейшей атаки и информацию о сети.
saipr
27.01.2017 16:23Да мне, конкретный компьютер можен с его информацией и управлением технологическим процессом. А сломаю маршрутизатор и ничего не получу. Я же не диверсант, а разведчик!
lair
27.01.2017 16:35А сломаю маршрутизатор и ничего не получу.
Как раз получите — информацию о вашем "конкретном компьютере" и плацдарм для атаки на него. Либо все то же самое, но о следующем плацдарме.
Zolushok
27.01.2017 17:01имхо, как раз на этот вопрос автор уже ответил неоднократно.
он хотел разорвать сквозную связь узлов защиты именно по ip — он это сделал.
ибо при одинаковых реализациях стека ip на si и se, сломав его каким-либо образом на se, без проблем сломают и на si. и так далее по всей цепочке
насколько эта задача актуальна, и какие другие проблемы при её решении он породил — другой вопрос. но исходную задачу он решил.
lair
27.01.2017 17:03но исходную задачу он решил.
Это зависит от того, как формулировать исходную задачу. У меня из поста создалось ощущение, что задача эта — "предотвратить несанкционированный доступ из сети Интернет на компьютер пользователя или в корпоративную сеть".
saipr
27.01.2017 19:23Как раз получите — информацию о вашем «конкретном компьютере»
Откуда ее получить?
Да, еще, если говорить о конкретной реализации данной технологии, то этой реализации уже строен межсетевой экран как на Si, так на. Поэтому никаких дополнительных экранов и NAT-ов не надо.lair
27.01.2017 21:27Откуда ее получить?
Из таблицы маршрутизации, из прослушивания сети, из атаки на контроллер — ровно оттуда, откуда ее получают в тех атаках типа НСД, от которых вы, по вашим же словам в посте, и защищаетесь.
Да, еще, если говорить о конкретной реализации данной технологии, то этой реализации уже строен межсетевой экран как на Si, так на. Поэтому никаких дополнительных экранов и NAT-ов не надо.
Вы противоречите своим же словам:
чтобы защитить межсетевой экран, надо поставить еще один и т.д.
saipr
27.01.2017 22:45А здесь не надо ставить, т.к. экран работает и на Si и Se!!!
И это не мои слова — а классиковlair
27.01.2017 22:48Ну работает, ну и что? Все равно же, как вы утверждаете, "по словам классиков", чтобы защитить межсетевой экран, надо поставить еще один — значит, эта конструкция бесконечна, и не важно, где именно у вас работают экраны.
Zolushok
27.01.2017 15:40предотвратить использованием возможных ошибок в IP-стеке и самом NAT-е — зто вр-вашему мало?
я не понимаю, что в данном случае означает «мало» или «много». давайте спросим по-другому. от скольких реальных случаев взлома ip-стека клиентов спасла ваша схема?saipr
27.01.2017 15:51-1До 2014 Google использовал OpenSSL для https. Все было хорошо и вдруг плюха в OpenSSL.
И Google кардинально меняет свою политику. Случай один и какие последствия!
Так вот, чтобы такого не произошло и предлагается это схема. А потом, если есть, например, NAT экран или наоборот?
Даже если будет один случай это будет каиастрофически много!!!lair
27.01.2017 16:00Так вот, чтобы такого не произошло и предлагается это схема.
… в которой, конечно, "плюх" не бывает. Да?
Zolushok
27.01.2017 16:07ну, справедливости ради, критически ошибиться при написании мультиплексора/демультиплексора множества двунаправленных потоков данных в один довольно трудно (а именно это, насколько я понимаю по выложенной в комментариях схеме, и является значимой частью решения).
saipr
27.01.2017 16:21Пока не знаю — подскажите
lair
27.01.2017 16:36Так вот, согласно вашему же утверждению, дыры бывают везде. В том числе, и в предлагаемой вами системе.
saipr
27.01.2017 19:24В том числе и в NAT-е и IP-стеке.
Дейкста прав. Так в чем вопрос или спор?lair
27.01.2017 21:30Так в чем вопрос или спор?
В том, что нет никаких доказательств того, что ваше решение безопаснее, чем каскад защитных систем, соединенных обычными сетевыми протоколами.
saipr
27.01.2017 22:49Вы же только что написали
NAT тоже «все же закрывает».
Защищает (мне понравилось ключевое слово «тоже», значит защищают оба, это уже хорошо).lair
27.01.2017 22:51+1В лучшем (для вас) случае это "тоже" означает "защищают в равной мере" (что говорит о бессмысленности вашего предложения).
saipr
27.01.2017 22:53-2А можеть наоборот — отказаться от ваших предложений и рассуждений — ведь тоже!!!
Проведите опыт — и спорьтеlair
27.01.2017 22:58+1Бремя доказательства лежит на утверждающем. Где ваши опыты, подтверждающие, что любую public facing-систему можно взломать, и что ваша система к подобному взлому устойчива?
saipr
28.01.2017 14:4515 лет эксплуатации в ЦБ РФ, в Фелеральном собрании, ВЭБ, на различных УЦ…
lair
28.01.2017 14:47+1… произвольное количество лет эксплуатации не показывают, что система устойчива к взлому.
Более того, это тем более не показывает, что другие системы можно взломать.
saipr
28.01.2017 14:58А что показывает? Я уже писал про OpenSSL.
Что хотим доказать?lair
28.01.2017 15:00А что показывает?
Только то, что кто-то использовал эту систему столько-то лет. Ничего больше.
Что хотим доказать?
Что ваши утверждения о какой-то исключительной защищенности предлагаемой вами схемы ни на чем не основаны.
saipr
28.01.2017 16:23Что ваши утверждения о какой-то исключительной защищенности предлагаемой вами схемы ни на чем не основаны.
Во первых никто и нигде не упортеблял слово исключительности. Тем более везде говорится — следите за данными, основная угроза можеь быть в них. А если вы перечитаете ваши вопросы и главное ответы, то вы увидите, что и как защищается.lair
28.01.2017 16:24Во первых никто и нигде не упортеблял слово исключительности
То есть степень защищенности сети с применением вашей схемы ничем не отличается от степени защищенности сети с применением "традиционной" схемы?
saipr
28.01.2017 16:26-1См. выше про выбор свободного человека
lair
28.01.2017 16:27Я задал, вроде бы, прямой вопрос, предполагающий ответы "да" и "нет".
saipr
28.01.2017 20:18Я также прямо все время отвечаю вам: Нет, отличается — IP-стек.
А если даже не отличается, кто решил что не может быть альтернативного пути защиты?lair
28.01.2017 20:23Я также прямо все время отвечаю вам: Нет, отличается — IP-стек.
И что "ip-стек"? Магический "ip-стек" повышает или понижает степень защищенности сети?
А если даже не отличается, кто решил что не может быть альтернативного пути защиты?
Почему же, может быть. Только надо честно писать "альтернативный, но без доказанных преимуществ".
vasiliysenin
30.01.2017 12:14Степень информационной безопасности особо не увеличивается, зато можно продать заказчику два сервера вместо одного.
Вообще обеспечение информационной безопасности требует принятия комплексных мер для её обеспечения.
Это и аппаратные средства, и программные, и организационные.
В коммерческих организациях обычно считают стоимость затрат и сравнивают с продуктами конкурентов, поэтому компания, как мне кажется, в основном ориентированна на госсектор.
lair
30.01.2017 12:26Это-то понятно, и аргументацию "можно заработать денег, продав специфическое ПО/АО", и аргументацию "можно вписать специфические требования в конкурс под продажу специфического АПК" я могу понять (и сам видел, как это работает). Я просто надеялся, что здесь все-таки дело не только в этом.
lair
27.01.2017 15:59Значит все же закрывает
NAT тоже "все же закрывает".
И предотвратить использованием возможных ошибок в IP-стеке и самом NAT-е — зто вр-вашему мало?
… в обмен на использование возможных ошибок в вашей системе? Это не просто "мало", это "неизмеримо".
Интересно (я уже писал выше), а как вы собираетесь защищать сетевой экран
А как вы защищаете Se и Si?
И самое главноеб вы собираетесь зависить от вежества и невежества покупателей?
А вы от него не зависите?
saipr
27.01.2017 16:19Si не имеет связи с внешней сеткой и не получает оттуда сетевые пакетыЙ
NAT тоже «все же закрывает».
Защищает (мне понравилось ключевое слово «тоже», значит защищают оба, это уже хорошо).
Про Se как и любой компьютер подключаемый к внешнему миру можно и нужно защищать и/или с помощью NAT, межсетевого экрана и т.п.lair
27.01.2017 16:36Si не имеет связи с внешней сеткой и не получает оттуда сетевые пакеты
Он получает оттуда информацию, которую анализирует. Этого достаточно для атаки.
Про Se как и любой компьютер подключаемый к внешнему миру можно и нужно защищать и/или с помощью NAT, межсетевого экрана
… не вы ли в этот момент говорите "а чем защищать компьютер, который защищает Se"?
saipr
27.01.2017 19:27Я уже ответил: реализация имеет встроенные механизмы межсетевого экрана и на Si и на Se. Поэтому для защиты точки Shield ничего дополнительного не над\о.
lair
27.01.2017 21:32Вы противоречите себе прямо в двух соседних комментариях:
Se как и любой компьютер подключаемый к внешнему миру можно и нужно защищать и/или с помощью NAT, межсетевого экрана
Я уже ответил: реализация имеет встроенные механизмы межсетевого экрана и на Si и на Se. Поэтому для защиты точки Shield ничего дополнительного не надо.Ну и да, вы же утверждаете, что межсетевые экраны уязвимы, так зачем их использовать?
saipr
27.01.2017 22:51-2Читай предыдущий ответ. Уязвимый не значит, что он не может выполнять своих функций по фильтрации.
saipr
27.01.2017 22:48И не закрывает IP-стэк
lair
27.01.2017 22:52У Se тоже есть IP-стек. Чем он защищен?
saipr
28.01.2017 14:42У него просто нет IP-стека, напрвленного в Si и наоборот! И защищать не надо. А провстроеннвй МЭ я уже писал.
lair
28.01.2017 14:44У него просто нет IP-стека, напрвленного в Si и наоборот! И защищать не надо.
А IP-стек, направленный в публичную сеть, защищать не надо?
А провстроеннвй МЭ я уже писал.
"Встроенный МЭ" ничем не лучше внешнего — точно так же, если верить вам, пропускает любую угрозу, если у атакующего достаточно времени.
saipr
28.01.2017 16:24А кто сказал, что лучше внешнего. Функции МЭ более менее стандартны. Но встроенный дешевле — допкомпа не надо
lair
28.01.2017 16:26А кто сказал, что лучше внешнего.
А если не лучше, то, как уже обсуждалось, степень его защиты — в рамках ваших утверждений — ничтожна. Поэтому можно просто не упоминать его наличие уже.
saipr
28.01.2017 16:27Грубовато, но это ваш выбор
lair
28.01.2017 16:29… возвращаясь к обсуждению — так чем же защищен внешний IP-стек Se? Что мешает злоумышленнику, пользуясь уязвимостями, о которых написано в статье, захватить контроль над Se?
saipr
28.01.2017 20:21Черным по белому везде написано (перечитайте ответы и вопросы и статью):
Слабым звеном остается внешний сервер Se точки доступа Shield, который непосредственно подключен к сети Интернет. Злоумышленник может получить контроль над этим сервером, однако он не сможет достичь своей цели — проникнуть в ЛВС и нанести ей ущерб.
А защищается встроенным МЭ!!!lair
28.01.2017 20:25+1Так, по шагам.
"Встроенный МЭ", так же как и любой другой МЭ, не способен защитить Se от компроментации (поскольку вы утверждаете, что любой МЭ не способен защитить систему от компроментации). Поэтому выбрасываем.
За исключением МЭ, ничто Se не защищает. Следовательно, Se может быть скомпроментирован. Ура.
- Что теперь мешает скомпроментировать Si?
saipr
28.01.2017 20:30Ура
Ура чему, вы теперь наконец-то узнали, что все то, что напрямую через IP-стек подключено к другой сети, может быть захвачено? ЕЕсли так — то цель достигнута!
Отсутствие IP-стекаlair
28.01.2017 20:32Ура чему,
Тому, что мы (для целей дискуссии) еще раз выяснили, что (вне зависимости от наличия любых средств защиты) Se может быть захвачен извне.
вы теперь наконец-то узнали, что все то, что напрямую через IP-стек подключено к другой сети, может быть захвачено?
Это вы так утверждаете. Безосновательно.
Отсутствие IP-стека
И как же отсутствие IP-стека мешает захвату Si?
zirix
28.01.2017 15:12+1Вы слышали про DMA attack?
Очень странно выбирать FireWire (IEEE 1394) в качестве безопасного транспорта/соединения.
lair
28.01.2017 15:25Давайте, кстати, все-таки уточним одну вещь. Предлагаемое вами решение является транспортом для любого TCP/IP потока (т.е., я могу просто открыть соединение на произвольный интересующий меня адрес и работать с ним), или только для конкретных поддерживаемых протоколов прикладного уровня (например, HTTP)? Если для прикладных протоколов, то возможно ли пропускать шифрованные данные без их анализа (например, проксирование HTTPS без MITM)? Позволяет ли оно выставлять ресурсы изнутри сети наружу (публикация веб-сервера или машины для удаленного доступа)?
Kliba
Так и не понял что помешает злоумышленника попасть в локалку завладела внешним сервером
saipr
А как? На внешнем сервере из сокеты читаются данные и только данные (это не сетевой пакет) и по веревке без всякого сетевого протокола передаются на внутренний сервер. На внутреннем сервере эти данные уже упаковываются в пакет для пересылки по ЛВС.
Можно еще посмотреть призентацию.
Kliba
Во-первых, если откинуть всю сетевую часть пакета и оставить только полезные данные — как вы его собираетесь маршрутизировать дальше не имея понятия кому адресован пакет и от кого он исходит? Во-вторых, завладев внешним сервером я пока не вижу препятствий для того, чтобы завладеть и внутренним найдя уязвимости в протоколе их общения.
lair
Вы просто заменили один канал связи на другой. Если вы постулируете, что можно взломать любую точку доступа, имеющую канал связи, то этот же постулат распространяется и на внутренний сервер.
saipr
Но канала связи (да и подключиться — connect) между внешним и внутреннем сервером нет.
lair
Если между ними нет канала связи, то они не могут обмениваться информацией. Если они не могут обмениваться информацией, они не могут выполнять роль шлюза. Поскольку они выполняют роль шлюза, следовательно, они обмениваются информацией, следовательно, между ними есть канал связи.
Kliba
Продолжу — следовательно, они могут быть взломаны.
DrZlodberg
Это всё для идеального мира. Сообщение об ошибке вернувшееся из внутренней сети во внешнюю через все фильтры (вы же не собираетесь запретить обработку ошибок при работе?) вполне может случайно раскрыть внутреннюю структуру сети. Собственно довольно частая проблема на веб-серверах, когда на сайт попадает текст ошибки с данными о структуре сервера.
Ну и что мешает просто закинуть через легальный канал данные, которые, например переполнением стека рушат программу на том конце, или даже пропихавают небольшой вирус (если размер данных позволяет).
Пока есть связь — взлом возможен. Проблема будет только с получением данных обратно. Однако опыт подсказывает, что эта часть проблемы при остром желании и наличии агента (вируса например) внутри может быть решена весьма нетривиальными способами. Хоть управление колебанием питания за счёт регулирования скорости оборота кулеров (пример упоротый, однако не невозможный в принципе). Вообще способов передачи данных без прямого соединения придумано уже много, а тут у нас даже связь есть, хоть и фильтруемая.
saipr
Вирусы и все остальное. Да, есть канал, по которому передаются данные и только данные. Но в эти данные можно запихнуть вирус. Поскольку семантику данных тяжело проверить, мы можем и должны проверить данные антивирусом, при чем это можно сделать сначало во внешнем сегменте, а затем и во внутреннем. Зачем во внутреннем еще раэ? А что мешает вирусу снова подключиться на внешнем сервере? Ничто.
Более того никто и не собирается скрывать «внутреннюю структуру сети»?
Что вы с ней собираетесь делать? Как получить доступ хоть к одному компьютеру внутренней сети, зная его адрес? IP-пакеты между внутренним и внешним серверами не ходят. В итоге вы попадете либо на какой-то компьютер во внешней сети, имеющим такой же адрес, ли вам скажут, что нет такого адреса.
lair
… вас не смущает, что эта цепочка рассуждений верна для любого NAT?
DrZlodberg
Антивирус во первых не панацея совершенно. А во вторых иногда достаточно просто уронить или повредить машину на другом конце. Или нарушить работу внутренней сети. Или ещё что-нибудь по потребностям атакующих. Полноценный вирус для этого зачатую даже не нужен. Вы удивитесь, сколько всего умудряются впихивать спецы в крошечный кусочек кода.
Например точнее настроить тот же вирус, чтобы он более целенаправленно пытался пролезть к интересующей точке.
saipr
Что это за точка? Какие ее координаты?
DrZlodberg
Что — очевидно зависит от того, что конкретно нужно атакующему. Может он собирается пошарить во внутренней почте, а может — свалить контроллеры, управляющие распределением энергии на электростанции.
А вот для того, чтобы хоть частично узнать её координаты как раз и может пригодиться информация о структуре. Знаете сколько серверов погорело на том, что в сообщении об ошибке была часть структуры каталогов одного (из кучи) сайта?
saipr
А чему мне удивляться?!
Сам «впихивал» на ЭВМ М-220 с ее то оперативкой в 4К и барабанов в 28К СУБД «РПГ-М-220» и еще много чего. Да, и сейчас порох сухой. А чего стоила на ней ИС-2, с полной реализацией высшей математики. Так что написанию кода надо учиться там.
Интересно, а после проверки данных антивирусом Касперского, эти данные становятся «чистыми» и их можно пускать в защищаемую сеть/ЛВС?
DrZlodberg
А, тогда да. Просто сейчас народ привык уже к вирусам по 30Мб, так что мелкие объёмы уже не впечатляют.
Польза проверки сильно сомнительна. Эвристики до сих пор особой точностью похвастаться не могут, а уж специфичный код, который не делает шаблонных действий вообще не видят. Ну и от падения программы из-за переполнения специально испорченными данными он тоже не спасёт.