А почему маршрутизация между Влан-ами на пограничном роутере? А не на Л3 свиче 3850, который как бы для таких задач и предназначен. 4331 - софтверная шляпа (хорошая на своем месте - опорный роутер, периметр WAN), умеющая там гигабит или пару от силы на маршрутизацию (при выключенных всех остальных фичах типа НАТ, ацл и проч.), а 3850 - десятки гигабит может маршрутизировать, на то и Л3 свич.
Ну ок, прицепились к второстепенному, что и было мной отмечено, как спорное. Еще 31й или 239й приказ фстэк вспомните, мало ли есть каких ведомственных ограничений.
Статья сырая по факту и слабая. Мнение. Имею право. Не готовы к критике, в т.ч жесткой - не публикуйтесь, делов-то. Встречный совет, в ответ на предложение свою написать.
Тяжело читать статью. Все время уговариваешь себя, что человек, не осиливший азы пунктуации не обязательно так же плохо разбирается в вопросах сегментации.
Местами вспоминается один персонаж, что-то в духе: "Мы стали более лучше одеваться".
Ну что это такое, коллега? Вы отчеты руководству или служебные письма так же пишите, как статьи? Пожалейте их глаза и нервы.
"Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему". Больше понять... Рифма напрашивается нецензурная в духе министра Лаврова.
Базы данных - то сегмент, то зона третьего уровня, то сегмент в милитаризованной зоне.
Ну ввели терминологию и подход к классификации - следуйте ему хотя бы приличия ради.
Если ДМЗ все же зона, то это ОНА, а не он. Ну и так далее и тому подобное, от начала и до конца кровь из глаз.
По существу, не про запятые. Для новичка статья так себе. Не то, что бы мысли в целом какие-то особо неверные, но с ясностью мышления и акцентами именно для новичка, явные проблемы.
"..балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости".
Новичок сидит и думает. Ага, они (ну или он, веб сервер) имеют доступ к серверу приложений, в котором тоже наверняка будут найдены уязвимости, а у того есть доступ к базе, а в ней тоже наверняка уязвимости... В чем же фишка, сквозной пробой всего и вся от гланд до заднего прохода. Фишка несомненно есть и крайне простая и даже вскользь упомянута в статье, но крайне мутно.
ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.
На счет терминации HTTPS замечание другие комментаторы сделали верное. При чем тут обязательно комплайнс законодательный и ПД? А инфраструктура сетевая только из ФВ одних состоит? А она не может быть порутана? А не может так оказаться, что дальше самого внешнего ФВ злоумышленнику и не понадобится, он трафик ваш расшифрованный будет слушать и свой профит иметь (а ваша организация ущерб, отличный от последствий несоблюдения законодательства о ПД).
А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2? А уже с этого поимели и прямой профит и возможности продвинутся дальше по инфраструктуре?
На счет того, что к сегментации не имеют отношения разные там Zero Trust и вякие модные технологии в духе цисковских оверлеев и их механизмов безопасности.
Коллега! Еще как имеют. Потому что сегментация в классических сетях - это способ изоляции на базе топологии. Она (сегментация) не самоцель, у нее есть задачи, о которых вы написали крайне мало и сумбурно. Так вот, эти задачи могут решаться и несколько иначе. Или гибридно. Отчасти топологией построения, отчасти другими средствами.
И применение конкретных технологических погремух влияет на сегментацию, вопреки вашему комментарию.
15 или 20 лет назад, например, хочешь сегментации и тем более микросегментации (с контролируемым уровнем изоляции, а не просто так!) - нет вариантов особых, плоди Vlan, L3 сегменты, разделенные файрволами. Сейчас можно сделать одну большую плоскую сеть и эту самую микросегментацию получить + гибкая фильтрация + глубокий анализ и еще хз что.
Все, что у вас на ваших веселых картинках - это про нее. Изоляция за счет структуры сети, способа соединения ее частей. И даже без модных оверлеев, чисто появление какой-то хитрой железки для хитрой инспекции, на способ сегментации может повлиять. Вот не умеет она иначе работать, включи ее именно так и никак по-другому.
А сейчас, выскажу возможно спорный для кого-то момент. Ваша картинка напоминает классические той же циски. На самой границе внешних сетей - роутер, потом файрвол. Так-то да. Тру роутер как роутер всегда обойдет роутер, сделанный из файрвола по функциям маршрутизации. Но всегда ли это нужно? Учитывая, что статья для новичков? В серьезной корп. сети, где всякие BGP с провайдерами, разветвленная филиальная сеть, миллион туннелей через Инет и хитрости динамической маршрутизации, наверное такая схема оправдана. А в обычной сети, где рулит новичок, этого всего не будет.
И пусть он или совместит внешний роутер с файрволом вопреки классической картинке или помнит, что если у него есть филиалы, подключенные не через Инет, а через выделенные каналы, какие-то другие части сети, свой, приватный WAN - ему нужен ЕЩЕ один роутер, назовем его опорный, который к данному, нарисованному, отношения не имеет и должен быть отдельный, спрятанный в т.ч. за какой-то ФВ. И когда он это поймет, то ну его нафик. На границу сети он поставить ФВ, который у вас на рисунке идет вторым и пусть этот ФВ выполняет простейшую маршрутизацию, обеспечивает дефолт через провайдера. А роутер спрячет за него и будет строить на нем внутренние коммуникации.
Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.
Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не делать.
Возраст обсуждаемого подхода гораздо больше возраста fail2ban. Софт этот аж в 2006 появился, вроде по его хистори.
Кстати, самый главный вопрос — а в чем тут honeypot-ость? Все же это вполне устоявшийся термин, который подразумевает несколько более широкий функционал и несколько даже иной.
Ничего не эмулируется, самое главное — никакой содержательной информации о методах взлома и тактике злоумышленника не соберешь. Это простейшая IPS с простейшими правилами. Типа снорта, только с тремя-четырьмя правилами :) Но снорт ни разу ни хонипот.
Вроде в статье этого нет. Но пусть будет. Вы столкнетесь с необходимостью компромисса между защитой control plane, что бы ЦПУ чрезмерно не поплохело и потерями записей в журнале. И так это костыль, а с этими оговорками совсем ставится под вопрос целесообразность таких танцев. А еще, если это вдруг железо, где АЦЛ работают не на ЦПУ общего назначения, а аппаратно, благодаря TCAM-ресурсу, можно нашлепать этих правил, что TCAM исчерпается. Да, можно постараться везде подстраховаться и все предусмотреть, но выглядит это для продакшна не айс.
Вся ценность статьи в примере парсинга, за это спасибо. А сам подход из мира линукса и микротиков. Так еще лет двадцать назад делали с логами иптаблеса, парсили перлом, наполняли цепочки… Старые песни о главном, короче.
Для некоторых роутеров логи дневные составляют десятки и сотни мегабайт чистого текста, а строк блокировок может быть десятки и сотни тысяч. Хороший вырисовывается сценарий для DOSа на железку с подобной педалью.
И кстати, про те же l3 свичи. Если брать за аналогию ssh, telnet, https и проч., что можно заюзать для удаленного администрирования — по умолчанию, по крайней мере, это доступно с ип любого l3 интерфейса. Ну, на тех свичах, что я сталкивался, может это не универсально.
С 4786 портом, думаю, аналогично. И тогда уже несколько понятней, откуда именно в инете оказывается столько уязвимых устройств, вовсе не от того, что в инет выставляют голой ж… vlan1 или лупбэк, используемый для администрирования.
Кстати, по поводу заголовка статьи. А точно ли это касается только интерфейсов управления? На l2 устройствах — понятно, это vlan1 и в нормальной ситуации ни пользователям ни кому-то еще он доступен быть не должен (как минимум — напрямую, т.е. в сегменте vlan1 не должно быть клиентов, каналов и т.п.)
А вот так слушается искомый порт на l3 свиче, например. Сдается мне, что с любого пользовательского влан-а это доступно, если не закрыто ацл-ем. И если это так и почему-то не отключается, то ацл надо вешать на все интерфейсы, причем так формировать ацл, что бы не навредить лигитимному трафику, где порт 4786 — это, допустим, порт источника, т.е. порт, с которого происходит тсп-коннект, а не порт конечного сервиса, к которому происходит подключение.
sh tcp brief all
TCB Local Address Foreign Address (state)
0443E2DC *.4786 *.* LISTEN
0552D460 *.443 *.* LISTEN
Вот пристали вы со своим синдромом вахтера. Улыбаюсь. Не в тему, ну не в тему этот образ в данном случае.
Я не вполне понимаю вашу специфику, поэтому категоричен не буду, в отличие от ваших арбузов, выкатываемых на мое поле. Но даже не вполне понимая, интуитивно догадываюсь и в целом, мне так кажется, ситуацию оценить могу. Подобного много, приходится сталкиваться. Ваш подход мне представляется непрофессиональным, мальчишество какое-то. Что значит надо? Когда это надо стало понятно и известно? Выясняли ли вы заранее эту возможность, давали ли запрос? Ну хотя бы искали выходов на спецов и устно обсуждали это? На лицо наскок, порыв, полет мысли, как, например, в вашей единственной публикации на хабре. Интересной, замечу, но вот этот подход быстро сделать, на коленке, зато ловко придумано — за версту виден. Мой жизненный опыт подсказывает, что все эти ловкачества, даже если работают какое-то время, как временное решение, дорого потом обходятся. Я вас могу понять только в том случае, если вы руководитель, гешефт которого напрямую зависит от того — сдадим, не сдадим, успеем — нет. Тогда понятно. Если вы просто спец по найму — я бы на вашем месте доложил по вертикали власти что препятствует реализации проекта, на кого надо выходить и как правильно формулировать вопрос. А дальше… Дальше пусть искомую находчивость и ловкость проявляют те, кто должен в данном случае. И это правильно. Если они поднапрягутся, найдут прямые контакты и все решат и более того, застолбят это решение, есть хотя бы какая-то надежда, что ваш костыль завтра не сломается от того, что политика оператора в очередной раз изменилась. Вы ткнете в него пальцем и скажете — он все сломал. А он скажет — друзья, а кто вам мешал сделать ПРАВИЛЬНО? Поднимет «архивы» и заявки от вас не найдет. Скажет — да они и заявку не давали. А вы ответите — а нам надо было сразу, а не через… Поверьте, из этих двух сторон вы будете выглядеть бледней. Думаете у меня подобного не возникает, только в других сферах? Опыт показывает, все решаемо или почти все. А иногда надо, ради будущего нормального и правильного функционирования систем где-то чем-то и пожертвовать, а не гнаться за победой любой ценой, типа — не даете прямо, сделаем операцию на глазу через задний проход. Хотя, на вкус и цвет. Если вы жить не можете без того, что бы не устроить везде, где работаете пионернет — это ваше право и ваш выбор. Может от того и карма у вас такая в итоге — работать с заказчиками, где вам приходится оптику подпольно кидать?
Я начинал с эникея давно, когда инет у нас был по >=4 р. за мб (а мобильного не было вовсе да и мобильники были далеко не у всех). Все, что только можно увидеть — я видел и все, что можно знать про ухищрения пользователей — я знаю. Ну или почти все, а чего не знаю — догадываюсь. Подо мной сейчас команда эникеев, которые тоже неплохо осведомлены как в результате «прямого контакта» так и благодаря всяким автоматизированным средствам. Вышестоящая над нами условная «пирамида» власти постоянно трясет нас на предмет отчетов в самых разных разрезах как по серверам, так и по раб. станциям. Они нам снятся уже. Смешно читать конец вашего поста, про админов, для которых львиная доля сети не существует.
1. Локальные шары не нужны. По факту. Большинству пользователей. Для большинства пользователей раб. станция — это тонкий клиент для доступа к удаленным сервисам, провод до ЦОДа и только. Многие тети за 50, поверьте, даже не знают и не поймут вас, что это такое — шара. Зато они виртуозно барабанят в SAPе или 1С. Для снятия стресса можно и в инет. Поискать тур для отпуска. Но есть и действительно нужные задачи. Закупки. Торги. Конкурсы всякие. Отчетность. Соц. сети не приветствуются, но люди пользуются. В итоге все нарушают и все под колпаком, любого можно притянуть. Все это понимают и никто не борзеет в целом. Компромисс и разумное сосуществование. Эксцессы редки.
Про разработчиков я уже писал. Будут у вас в вашей песочнице и шары и RPC и проч. Все, что вы заявите для вашей работы.
ТеамВьювера у офисного планктона не будет. Зарезано как по сетке так и мерами уровня хоста. Разными способоами. Обойти можно все теоретически, но это не тот случай. Слишком накладно становится, нет смысла. Можно получить вполне лигитимный удаленный доступ, если это обоснованно и нужно для работы. Никому руки целовать за это не надо будет.
Устроить шару на внешке можно. И даже некоторые сервисы будут работать. Но мало кто в здравом уме это будет делать. А попадется — лишиться работы, а может и получит юр. преследование. Это никому не надо, поверьте. За работу сейчас держатся. К тому же, если кто-то имеет доступ к чему-то действительно важному, всегда есть способ «унести». Ну, сфоткать в конце-концов экран. Особо важная инфа обычно не весит гигабайты, она компактна. Так что это совсем другой вопрос, он не решается исключительно техническими мерами никогда.
Неделями ответ от админа ждать не надо. Есть сервис деск. Админу и любому другому ит-специалисту там считается время реакции, время выполнения, есть крайние сроки, уставки временные с предупреждениями, начальники получают по почте варнинги и имеют этих самых ит-спецов за проволынивание работ. Просроченная заявка — это вообще ЧП. Собирать много подписей на заявку, включая подписи СБ нужно только на базовые, основополагающие вещи, типа завести учетку в АД при приеме на работу, обеспечить физически раб. место и т.п.
Описанные вами вопросы (типа порт открыть, что-то подкрутить) решаются посредством хелпдеска без волокиты, в рабочем порядке, по результатам экспертной оценки ит-специалиста. Как правило в течении дня, максимум двух, если это действительно надо.
ИТ службе периодически ставится оценка, независимый аудит опрашивает юзеров, анонимно. За плохую оценку итшников имеют. Ну… журят хотя бы :)
2. Ну плохо, что сказать? Только не надо экстраполировать этот опыт на всех. Хотя, если это элементы критичной инфраструктуры (ваши 5 хостов), пусть даже строго юридически это никак не оформлено, но все понимают, что по факту это оно, возможно, что будет задержка. Как минимум на то, что даже 5 компов надо нанести на схему, продумать подключение со всеми политиками так, что бы потом раз и навсегда и минимально вмешиваться. Если же речь о стенде, временном размещения «на показать» — нет проблем, мешать вам там ничего не будет.
На счет 700 метров оптики… Блин. Я фигею, дорогая редакция. Да вас там винтить надо было за самоуправство. Видно, тот еще бардак на предприятии. По пром. объекту ходить надо строго по разрешенным маршрутам-дорожкам, посторонним, которые в силу каких-то обстоятельств на объекте оказались — в сопровождении. Как можно что-то кидать куда-то вот просто так… нет слов. Наверняка и ТБ нарушали, на стремянку поди лазали, может работа на высоте была. В общем — полный сюр. Случись какая травма во время этих работ — подсудное дело для ответсвенных лиц.
Или вы плохо объяснили ваш статус на этом объекте, как вариант.
Итого, вывод — нормальных сетей корпоративных вы не видели или видели, но не рассмотрели толком. Ну, знакомьтесь, мотайте на ус, т.с. Хотя, например, все что я описал — это норма, в целом постоянно муссируется, что вот незрелые мы, не все в порядке в королевстве. Но читая вас, я начинаю т.с. другими глазами смотреть на свою работу. Прямо аж себе завидовать.
Ну и конечно, не в каждой сети и не у каждого эти исключения есть, иногда более опасные сценарии и решения можно заменить на менее опасные и т.д.
Когда червь «работает» на основе 0-дай и ему вообще плевать на любые права и прочие формальности, сетевые меры становятся одними из главных и весьма эффективны. Не раз наблюдал, как их вынужденны были временно вводить на лету, разрушая процессы и работу, выбора не было. Уж лучше сеть сразу так построить, что бы большая часть этих мер сразу была заложена, а стиль работы — на эти меры рассчитан. И да, я еще раз скажу — это свойство промсетей, это свойство «корпоратов». Это не домовые сети начала нулевых и пионернеты. Это нормально и это практикуется. И вовсе не синдром вахтера. А как раз «колхозы» и лажатся по поводам, описанным в топике.
Конечно, это часть мер и я тоже это упоминал. С контроллерами бывает все плохо, когда они не в твоем подчинении. Про срвера-исключения тоже упоминал. Например это SCCM. Ему надо коннектиться к клиентам, да (оппонент же приводил примеры, которые реально не есть проблема, типа политик и скриптов). Но отсюда никак не следует, что на другие условные 100 серверов можно и нужно забиить, раз один или два мы не можем подвести под эту схему. Для таких серверов должен быть усиленный контроль и усиленные меры другого рода.
Спасибо за ликбез.
Иногда выгодней на подсети не делить, а в рамках больших сетей задавать правила взаимодействия, отсекая ЗАВЕДОМО ненужное, решая попутно массу потенциальных проблем ИБ. Но видно у вас мысленный эксперимент не вытанцовывается никак. Ну да ладно, я вроде уже попрощался. Еще раз всех благ.
Хех, не читая этого коммента я вам уже ответил, как оказывается.
«Вы разработчик? Вы не сидите с этими 1000+ пользователями в одном сегменте и не испытываете проблем в своих тестах, вам обеспечена нужная свобода для маневра. Вот что тут можно не понять?»
Перевоспитывать меня не надо. Я для этого староват да и на самовоспитание потратил много времени. Мой результат мне дорого.
Всех благ.
Читайте выше. Не охватывается как-то у вас решения, присущие корпоративным сетям, в т.ч. промышленным. И кстати, сужу не по одной своей. Все же просто. ~1000 юзеров офисной направленности? Все, что написал IGHOR верно. Доступ в ЦОДы, серверные сегменты, возможно — в инет. Полная изоляция между собой. АСУТП у вас есть? Через файрволы, шлюзы-посредники и проч. средства стык с ЛВС, допустим, внутри АСУТП несколько иные подходы, это нормально. Вы разработчик? Вы не сидите с этими 1000+ пользователями в одном сегменте и не испытываете проблем в своих тестах, вам обеспечена нужная свобода для маневра. Вот что тут можно не понять? Я недоумеваю. Или у вас завод на десять машин? Тогда да, там можно попроще все, наверное. И сервер к ним в сегмент. На неуправляемый свич.
Да, вы видно просто не админ. Сегменты большие, есть такие, где много разрешено. RPC ходит в НУЖНЫХ направлениях. В сегментах на сотни машин взаимодействие между ними полностью запрещено (PACL, IPACL). Большие серверные сегменты. Между большинством серверов, кроме тех случаев, где это необходимо (обеспечивают единый сервис, кластеры и т.д.) — общение запрещено.
Мы как на разных языках разговариваем. Да, я постоянно получаю заявки на отркытие чего либо. Где? На ван каналах. К сосденим площадкам. В инет. Это нормально. В ЛВС заявок нет. Почти нет. Потому что все более-менее продумано и подходы к работе не подразумевают таких вещей, например, как шара на пользовательских машинах, пер-ту-пир между юзерами и т.д.
И ничему это не мешает. Файлы люьтся через файлообменники, пир-ту-пир бегает между воип телефонами в спец. сегментах и т.д. ЭТО ПРОЗРАЧНО. А то, что с файлового сервера невозможен коннект в пользовательские сегменты? Вот знаете, кроме меня и нескольких тех. спецов об этом никто и не знает. Это никому не мешает, кроме вирусов, конечно. Это я про описанную вами схему заражения не за секунду, а за две. Не работает она, так-то.
Не совсем так. Достаточно большие сети, в т.ч. офисного назначения, можно сделать существенно безопасней, если логически, в какой-то мере приблизить их к описанной выше системе контуров, сегментации и т.д.
Вы, возразив против межпользовательской сегментации, не утверждали ведь сперва, что это неудобно, что это мешает. Вы сказали — это не решает проблемы, это бесполезно. Я показываю — это во многом решает проблему, это так же полезно, как контуры в АСУТП.
Тогда вы заявили, что это неудобно, что это сплошное запинание, а не работа. Могу предположить, что вы просто не пробовали. Ведь контуры АСУТП — не запинание? А почему? Потому что они продуманны. И не возникает задач залезать через телеком разрыв из одного контура в другой, ну не нужно это, т.к. все задачи без этого решаются.
Так же и с тем, что я описал, например с контроллером АД и запретом от него исходящих тсп к клиентам. Вы это оцениваете «в уме», на вскидку и ужасаетесь. А я юзаю и доволен как слон. Ни кидо, ни ванна, ни петя меня не задели вот ничуть, хотя вокруг — да, бушевали. И кстати, серверные админы не то что не замечают этих, по вашему диких костылей и преград, даже не догадываются о них. Вот такие жуткие неудобства. И кстати, это в других регионах нашей организации был типичный сценарий. Админ с правами лезет на контроллер по WAN копр. каналам, этакий старший брат. Заражает, далее с контроллера зараза ломится в сети регионального предприятия. У всех площадок — кроме меня. Контроллер заразили, в ЛВС — ноль вирусного трафика, этакая ДМЗ в «сердце» ЛВС, а не на периметре, как обычно. С т.з. дизайна сети это отнюдь не влан на юзера, как у провайдеров. Все средней «крупности». Но описанные фичи — сильно выручают. Уже не один год. Так что не спешите оценивать на вскидку, не распробовав. И да, инфраструктурники, кто серверами рулят, даже не замечают этого. Один или два раза пытались для теста сделать «телнет на порт» с консоли сервера к клиентам, для теста, удивились, что не прошло. Вот и все жуткие потери от подхода. Надо их еще раз оценить, может действительно так жить нельзя?
Это у вас домыслы какие-то. В строго техническом смысле сегменты у меня — от десятка до сотни машин в сегменте, если мы говорим о 802.1q вланах. Иногда, когда это необходимо и удобно — используются Port ACL, иногда IP ACL в точках L3-терминации. Мужики-то в циске и не знают правильных подходов, утверждая, что в классическом дизайне ядро-распределение-доступ секьюрити фичи должны делаться на доступе, край — на агрегации, а на доступе — это PACL в том числе. Подумайте — для чего.
Жуткая «сегментация» получается. Прям до уровня порта. На счет докладных и мучительного ожидания. Я не знаю, что вы там в сетях у себя технологических крутите, для этого есть стенды и выделенное под это оборудование. А в нормальном продакшне все работает без особых сбоев годами, а некоторое оборудование — и без перезагрузок годами. Откуда там взяться этим докладным постоянным на какое-то нездокументированное сетевое взаимодейтсвие — не понятно. Вы тут намекали, что мол у некоторых галимый офис, а у нас тут завод, у нас тут все серьезно. Но не вяжется эта серьезность с остальными утверждениями. Где действительно все серьезно — не жалеют потратить время на то, что бы все продумать, задокументировать, нормально реализовать с этапом тестирования и юзать уже потом до следующей модернизации или замены решения. А вообще, советую вернуться к исходному тезису, что изоляция пользователей друг от друга — вещь бесполезная и еще раз прочитать аргументацию. Ответами на которую были рассуждения в духе «а вот если табуретку подставить и на шкаф еще залезть». Если не убеждает… ну, даже уж и не знаю. Наверное, тогда лучше дискуссию прекратить.
Да, может быть. Поэтому ИБ — вещь комплексная. Все самые шустрые в смысле скорости распространения черви, что были на моей памяти, начиная с мсбласт-а работали по принципу сетевой скан+уязвимость, никак указанные вами механизмы не задействуя. Но это к слову. Тут был выдвинут тезис — изоляция клиентов друг от друга — вещь бестолковая. Я не раз убеждался, что весьма толковая. Была высказана мысль — все равно заражение произойдет в два хода (а не в один), через цепочку пользователь -> заражение сервера -> заражение пользователей. Я показал, что этого в случае классических сетевых червей ВО МНОГИХ случаях (в смысле разных серверов) легко можно избежать. Только и всего.
А почему маршрутизация между Влан-ами на пограничном роутере? А не на Л3 свиче 3850, который как бы для таких задач и предназначен. 4331 - софтверная шляпа (хорошая на своем месте - опорный роутер, периметр WAN), умеющая там гигабит или пару от силы на маршрутизацию (при выключенных всех остальных фичах типа НАТ, ацл и проч.), а 3850 - десятки гигабит может маршрутизировать, на то и Л3 свич.
Ну ок, прицепились к второстепенному, что и было мной отмечено, как спорное. Еще 31й или 239й приказ фстэк вспомните, мало ли есть каких ведомственных ограничений.
Статья сырая по факту и слабая. Мнение. Имею право. Не готовы к критике, в т.ч жесткой - не публикуйтесь, делов-то. Встречный совет, в ответ на предложение свою написать.
Тяжело читать статью. Все время уговариваешь себя, что человек, не осиливший азы пунктуации не обязательно так же плохо разбирается в вопросах сегментации.
Местами вспоминается один персонаж, что-то в духе: "Мы стали более лучше одеваться".
Ну что это такое, коллега? Вы отчеты руководству или служебные письма так же пишите, как статьи? Пожалейте их глаза и нервы.
"DMZ - сегмент сети"
"Чтобы больше понять что же такое сегмент, а что такое зона, усложним схему". Больше понять... Рифма напрашивается нецензурная в духе министра Лаврова.
Базы данных - то сегмент, то зона третьего уровня, то сегмент в милитаризованной зоне.
Ну ввели терминологию и подход к классификации - следуйте ему хотя бы приличия ради.
Если ДМЗ все же зона, то это ОНА, а не он. Ну и так далее и тому подобное, от начала и до конца кровь из глаз.
По существу, не про запятые. Для новичка статья так себе. Не то, что бы мысли в целом какие-то особо неверные, но с ясностью мышления и акцентами именно для новичка, явные проблемы.
"..балансировщик нагрузки и веб сервер - это те сетевые устройства, в которых наверняка почти сразу будут найдены уязвимости".
Новичок сидит и думает. Ага, они (ну или он, веб сервер) имеют доступ к серверу приложений, в котором тоже наверняка будут найдены уязвимости, а у того есть доступ к базе, а в ней тоже наверняка уязвимости... В чем же фишка, сквозной пробой всего и вся от гланд до заднего прохода. Фишка несомненно есть и крайне простая и даже вскользь упомянута в статье, но крайне мутно.
ДОС на пограничный ФВ не самая большая беда. И если учесть, что ДМЗ делаются далеко не всегда на стыке публичных сетей с частными, а в т. ч. в пределах одной, допустим, корпоративной сети, заради разделения и безопасного инф. обмена частей сети с разным уровнем доверия/критичности, где ДОС маловероятен или вообще невозможен, все же два независимых ФВ делают и логика там ближе к чистой ИБ, чем к нагрузочным моментам.
На счет терминации HTTPS замечание другие комментаторы сделали верное. При чем тут обязательно комплайнс законодательный и ПД? А инфраструктура сетевая только из ФВ одних состоит? А она не может быть порутана? А не может так оказаться, что дальше самого внешнего ФВ злоумышленнику и не понадобится, он трафик ваш расшифрованный будет слушать и свой профит иметь (а ваша организация ущерб, отличный от последствий несоблюдения законодательства о ПД).
А если в ДМЗ не один веб сервер? И его порутать не смогли, а порутали соседний в той же зоне и ваш расшифрованный трафик перехватили атакой уровня L2? А уже с этого поимели и прямой профит и возможности продвинутся дальше по инфраструктуре?
На счет того, что к сегментации не имеют отношения разные там Zero Trust и вякие модные технологии в духе цисковских оверлеев и их механизмов безопасности.
Коллега! Еще как имеют. Потому что сегментация в классических сетях - это способ изоляции на базе топологии. Она (сегментация) не самоцель, у нее есть задачи, о которых вы написали крайне мало и сумбурно. Так вот, эти задачи могут решаться и несколько иначе. Или гибридно. Отчасти топологией построения, отчасти другими средствами.
И применение конкретных технологических погремух влияет на сегментацию, вопреки вашему комментарию.
15 или 20 лет назад, например, хочешь сегментации и тем более микросегментации (с контролируемым уровнем изоляции, а не просто так!) - нет вариантов особых, плоди Vlan, L3 сегменты, разделенные файрволами. Сейчас можно сделать одну большую плоскую сеть и эту самую микросегментацию получить + гибкая фильтрация + глубокий анализ и еще хз что.
Все, что у вас на ваших веселых картинках - это про нее. Изоляция за счет структуры сети, способа соединения ее частей. И даже без модных оверлеев, чисто появление какой-то хитрой железки для хитрой инспекции, на способ сегментации может повлиять. Вот не умеет она иначе работать, включи ее именно так и никак по-другому.
А сейчас, выскажу возможно спорный для кого-то момент. Ваша картинка напоминает классические той же циски. На самой границе внешних сетей - роутер, потом файрвол. Так-то да. Тру роутер как роутер всегда обойдет роутер, сделанный из файрвола по функциям маршрутизации. Но всегда ли это нужно? Учитывая, что статья для новичков? В серьезной корп. сети, где всякие BGP с провайдерами, разветвленная филиальная сеть, миллион туннелей через Инет и хитрости динамической маршрутизации, наверное такая схема оправдана. А в обычной сети, где рулит новичок, этого всего не будет.
И пусть он или совместит внешний роутер с файрволом вопреки классической картинке или помнит, что если у него есть филиалы, подключенные не через Инет, а через выделенные каналы, какие-то другие части сети, свой, приватный WAN - ему нужен ЕЩЕ один роутер, назовем его опорный, который к данному, нарисованному, отношения не имеет и должен быть отдельный, спрятанный в т.ч. за какой-то ФВ. И когда он это поймет, то ну его нафик. На границу сети он поставить ФВ, который у вас на рисунке идет вторым и пусть этот ФВ выполняет простейшую маршрутизацию, обеспечивает дефолт через провайдера. А роутер спрячет за него и будет строить на нем внутренние коммуникации.
Возможно мелко плаваю как тех. специалист, но в достаточно большом Холдинге с филиальной структурой по стране, почти нигде не сделано по данной картинке. Везде на самой границе что-то специфически ИБшное, а не просто роутер с грубой предфильтрацией АЦЛ.
Но это ладно, может они/мы лохи. Но вот новичку я бы точно советовал как у вас нарисовано - не делать.
Кстати, самый главный вопрос — а в чем тут honeypot-ость? Все же это вполне устоявшийся термин, который подразумевает несколько более широкий функционал и несколько даже иной.
Ничего не эмулируется, самое главное — никакой содержательной информации о методах взлома и тактике злоумышленника не соберешь. Это простейшая IPS с простейшими правилами. Типа снорта, только с тремя-четырьмя правилами :) Но снорт ни разу ни хонипот.
Вся ценность статьи в примере парсинга, за это спасибо. А сам подход из мира линукса и микротиков. Так еще лет двадцать назад делали с логами иптаблеса, парсили перлом, наполняли цепочки… Старые песни о главном, короче.
С 4786 портом, думаю, аналогично. И тогда уже несколько понятней, откуда именно в инете оказывается столько уязвимых устройств, вовсе не от того, что в инет выставляют голой ж… vlan1 или лупбэк, используемый для администрирования.
А вот так слушается искомый порт на l3 свиче, например. Сдается мне, что с любого пользовательского влан-а это доступно, если не закрыто ацл-ем. И если это так и почему-то не отключается, то ацл надо вешать на все интерфейсы, причем так формировать ацл, что бы не навредить лигитимному трафику, где порт 4786 — это, допустим, порт источника, т.е. порт, с которого происходит тсп-коннект, а не порт конечного сервиса, к которому происходит подключение.
sh tcp brief all
TCB Local Address Foreign Address (state)
0443E2DC *.4786 *.* LISTEN
0552D460 *.443 *.* LISTEN
Я не вполне понимаю вашу специфику, поэтому категоричен не буду, в отличие от ваших арбузов, выкатываемых на мое поле. Но даже не вполне понимая, интуитивно догадываюсь и в целом, мне так кажется, ситуацию оценить могу. Подобного много, приходится сталкиваться. Ваш подход мне представляется непрофессиональным, мальчишество какое-то. Что значит надо? Когда это надо стало понятно и известно? Выясняли ли вы заранее эту возможность, давали ли запрос? Ну хотя бы искали выходов на спецов и устно обсуждали это? На лицо наскок, порыв, полет мысли, как, например, в вашей единственной публикации на хабре. Интересной, замечу, но вот этот подход быстро сделать, на коленке, зато ловко придумано — за версту виден. Мой жизненный опыт подсказывает, что все эти ловкачества, даже если работают какое-то время, как временное решение, дорого потом обходятся. Я вас могу понять только в том случае, если вы руководитель, гешефт которого напрямую зависит от того — сдадим, не сдадим, успеем — нет. Тогда понятно. Если вы просто спец по найму — я бы на вашем месте доложил по вертикали власти что препятствует реализации проекта, на кого надо выходить и как правильно формулировать вопрос. А дальше… Дальше пусть искомую находчивость и ловкость проявляют те, кто должен в данном случае. И это правильно. Если они поднапрягутся, найдут прямые контакты и все решат и более того, застолбят это решение, есть хотя бы какая-то надежда, что ваш костыль завтра не сломается от того, что политика оператора в очередной раз изменилась. Вы ткнете в него пальцем и скажете — он все сломал. А он скажет — друзья, а кто вам мешал сделать ПРАВИЛЬНО? Поднимет «архивы» и заявки от вас не найдет. Скажет — да они и заявку не давали. А вы ответите — а нам надо было сразу, а не через… Поверьте, из этих двух сторон вы будете выглядеть бледней. Думаете у меня подобного не возникает, только в других сферах? Опыт показывает, все решаемо или почти все. А иногда надо, ради будущего нормального и правильного функционирования систем где-то чем-то и пожертвовать, а не гнаться за победой любой ценой, типа — не даете прямо, сделаем операцию на глазу через задний проход. Хотя, на вкус и цвет. Если вы жить не можете без того, что бы не устроить везде, где работаете пионернет — это ваше право и ваш выбор. Может от того и карма у вас такая в итоге — работать с заказчиками, где вам приходится оптику подпольно кидать?
Я начинал с эникея давно, когда инет у нас был по >=4 р. за мб (а мобильного не было вовсе да и мобильники были далеко не у всех). Все, что только можно увидеть — я видел и все, что можно знать про ухищрения пользователей — я знаю. Ну или почти все, а чего не знаю — догадываюсь. Подо мной сейчас команда эникеев, которые тоже неплохо осведомлены как в результате «прямого контакта» так и благодаря всяким автоматизированным средствам. Вышестоящая над нами условная «пирамида» власти постоянно трясет нас на предмет отчетов в самых разных разрезах как по серверам, так и по раб. станциям. Они нам снятся уже. Смешно читать конец вашего поста, про админов, для которых львиная доля сети не существует.
1. Локальные шары не нужны. По факту. Большинству пользователей. Для большинства пользователей раб. станция — это тонкий клиент для доступа к удаленным сервисам, провод до ЦОДа и только. Многие тети за 50, поверьте, даже не знают и не поймут вас, что это такое — шара. Зато они виртуозно барабанят в SAPе или 1С. Для снятия стресса можно и в инет. Поискать тур для отпуска. Но есть и действительно нужные задачи. Закупки. Торги. Конкурсы всякие. Отчетность. Соц. сети не приветствуются, но люди пользуются. В итоге все нарушают и все под колпаком, любого можно притянуть. Все это понимают и никто не борзеет в целом. Компромисс и разумное сосуществование. Эксцессы редки.
Про разработчиков я уже писал. Будут у вас в вашей песочнице и шары и RPC и проч. Все, что вы заявите для вашей работы.
ТеамВьювера у офисного планктона не будет. Зарезано как по сетке так и мерами уровня хоста. Разными способоами. Обойти можно все теоретически, но это не тот случай. Слишком накладно становится, нет смысла. Можно получить вполне лигитимный удаленный доступ, если это обоснованно и нужно для работы. Никому руки целовать за это не надо будет.
Устроить шару на внешке можно. И даже некоторые сервисы будут работать. Но мало кто в здравом уме это будет делать. А попадется — лишиться работы, а может и получит юр. преследование. Это никому не надо, поверьте. За работу сейчас держатся. К тому же, если кто-то имеет доступ к чему-то действительно важному, всегда есть способ «унести». Ну, сфоткать в конце-концов экран. Особо важная инфа обычно не весит гигабайты, она компактна. Так что это совсем другой вопрос, он не решается исключительно техническими мерами никогда.
Неделями ответ от админа ждать не надо. Есть сервис деск. Админу и любому другому ит-специалисту там считается время реакции, время выполнения, есть крайние сроки, уставки временные с предупреждениями, начальники получают по почте варнинги и имеют этих самых ит-спецов за проволынивание работ. Просроченная заявка — это вообще ЧП. Собирать много подписей на заявку, включая подписи СБ нужно только на базовые, основополагающие вещи, типа завести учетку в АД при приеме на работу, обеспечить физически раб. место и т.п.
Описанные вами вопросы (типа порт открыть, что-то подкрутить) решаются посредством хелпдеска без волокиты, в рабочем порядке, по результатам экспертной оценки ит-специалиста. Как правило в течении дня, максимум двух, если это действительно надо.
ИТ службе периодически ставится оценка, независимый аудит опрашивает юзеров, анонимно. За плохую оценку итшников имеют. Ну… журят хотя бы :)
2. Ну плохо, что сказать? Только не надо экстраполировать этот опыт на всех. Хотя, если это элементы критичной инфраструктуры (ваши 5 хостов), пусть даже строго юридически это никак не оформлено, но все понимают, что по факту это оно, возможно, что будет задержка. Как минимум на то, что даже 5 компов надо нанести на схему, продумать подключение со всеми политиками так, что бы потом раз и навсегда и минимально вмешиваться. Если же речь о стенде, временном размещения «на показать» — нет проблем, мешать вам там ничего не будет.
На счет 700 метров оптики… Блин. Я фигею, дорогая редакция. Да вас там винтить надо было за самоуправство. Видно, тот еще бардак на предприятии. По пром. объекту ходить надо строго по разрешенным маршрутам-дорожкам, посторонним, которые в силу каких-то обстоятельств на объекте оказались — в сопровождении. Как можно что-то кидать куда-то вот просто так… нет слов. Наверняка и ТБ нарушали, на стремянку поди лазали, может работа на высоте была. В общем — полный сюр. Случись какая травма во время этих работ — подсудное дело для ответсвенных лиц.
Или вы плохо объяснили ваш статус на этом объекте, как вариант.
Итого, вывод — нормальных сетей корпоративных вы не видели или видели, но не рассмотрели толком. Ну, знакомьтесь, мотайте на ус, т.с. Хотя, например, все что я описал — это норма, в целом постоянно муссируется, что вот незрелые мы, не все в порядке в королевстве. Но читая вас, я начинаю т.с. другими глазами смотреть на свою работу. Прямо аж себе завидовать.
Когда червь «работает» на основе 0-дай и ему вообще плевать на любые права и прочие формальности, сетевые меры становятся одними из главных и весьма эффективны. Не раз наблюдал, как их вынужденны были временно вводить на лету, разрушая процессы и работу, выбора не было. Уж лучше сеть сразу так построить, что бы большая часть этих мер сразу была заложена, а стиль работы — на эти меры рассчитан. И да, я еще раз скажу — это свойство промсетей, это свойство «корпоратов». Это не домовые сети начала нулевых и пионернеты. Это нормально и это практикуется. И вовсе не синдром вахтера. А как раз «колхозы» и лажатся по поводам, описанным в топике.
Иногда выгодней на подсети не делить, а в рамках больших сетей задавать правила взаимодействия, отсекая ЗАВЕДОМО ненужное, решая попутно массу потенциальных проблем ИБ. Но видно у вас мысленный эксперимент не вытанцовывается никак. Ну да ладно, я вроде уже попрощался. Еще раз всех благ.
«Вы разработчик? Вы не сидите с этими 1000+ пользователями в одном сегменте и не испытываете проблем в своих тестах, вам обеспечена нужная свобода для маневра. Вот что тут можно не понять?»
Перевоспитывать меня не надо. Я для этого староват да и на самовоспитание потратил много времени. Мой результат мне дорого.
Всех благ.
Мы как на разных языках разговариваем. Да, я постоянно получаю заявки на отркытие чего либо. Где? На ван каналах. К сосденим площадкам. В инет. Это нормально. В ЛВС заявок нет. Почти нет. Потому что все более-менее продумано и подходы к работе не подразумевают таких вещей, например, как шара на пользовательских машинах, пер-ту-пир между юзерами и т.д.
И ничему это не мешает. Файлы люьтся через файлообменники, пир-ту-пир бегает между воип телефонами в спец. сегментах и т.д. ЭТО ПРОЗРАЧНО. А то, что с файлового сервера невозможен коннект в пользовательские сегменты? Вот знаете, кроме меня и нескольких тех. спецов об этом никто и не знает. Это никому не мешает, кроме вирусов, конечно. Это я про описанную вами схему заражения не за секунду, а за две. Не работает она, так-то.
Вы, возразив против межпользовательской сегментации, не утверждали ведь сперва, что это неудобно, что это мешает. Вы сказали — это не решает проблемы, это бесполезно. Я показываю — это во многом решает проблему, это так же полезно, как контуры в АСУТП.
Тогда вы заявили, что это неудобно, что это сплошное запинание, а не работа. Могу предположить, что вы просто не пробовали. Ведь контуры АСУТП — не запинание? А почему? Потому что они продуманны. И не возникает задач залезать через телеком разрыв из одного контура в другой, ну не нужно это, т.к. все задачи без этого решаются.
Так же и с тем, что я описал, например с контроллером АД и запретом от него исходящих тсп к клиентам. Вы это оцениваете «в уме», на вскидку и ужасаетесь. А я юзаю и доволен как слон. Ни кидо, ни ванна, ни петя меня не задели вот ничуть, хотя вокруг — да, бушевали. И кстати, серверные админы не то что не замечают этих, по вашему диких костылей и преград, даже не догадываются о них. Вот такие жуткие неудобства. И кстати, это в других регионах нашей организации был типичный сценарий. Админ с правами лезет на контроллер по WAN копр. каналам, этакий старший брат. Заражает, далее с контроллера зараза ломится в сети регионального предприятия. У всех площадок — кроме меня. Контроллер заразили, в ЛВС — ноль вирусного трафика, этакая ДМЗ в «сердце» ЛВС, а не на периметре, как обычно. С т.з. дизайна сети это отнюдь не влан на юзера, как у провайдеров. Все средней «крупности». Но описанные фичи — сильно выручают. Уже не один год. Так что не спешите оценивать на вскидку, не распробовав. И да, инфраструктурники, кто серверами рулят, даже не замечают этого. Один или два раза пытались для теста сделать «телнет на порт» с консоли сервера к клиентам, для теста, удивились, что не прошло. Вот и все жуткие потери от подхода. Надо их еще раз оценить, может действительно так жить нельзя?
Жуткая «сегментация» получается. Прям до уровня порта. На счет докладных и мучительного ожидания. Я не знаю, что вы там в сетях у себя технологических крутите, для этого есть стенды и выделенное под это оборудование. А в нормальном продакшне все работает без особых сбоев годами, а некоторое оборудование — и без перезагрузок годами. Откуда там взяться этим докладным постоянным на какое-то нездокументированное сетевое взаимодейтсвие — не понятно. Вы тут намекали, что мол у некоторых галимый офис, а у нас тут завод, у нас тут все серьезно. Но не вяжется эта серьезность с остальными утверждениями. Где действительно все серьезно — не жалеют потратить время на то, что бы все продумать, задокументировать, нормально реализовать с этапом тестирования и юзать уже потом до следующей модернизации или замены решения. А вообще, советую вернуться к исходному тезису, что изоляция пользователей друг от друга — вещь бесполезная и еще раз прочитать аргументацию. Ответами на которую были рассуждения в духе «а вот если табуретку подставить и на шкаф еще залезть». Если не убеждает… ну, даже уж и не знаю. Наверное, тогда лучше дискуссию прекратить.