Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 56
28-о декабря закидывал в ChatGPT на эту тему:
не скажешь ли ты, что в мире сете-строения vlan'ы изрядно переоценены?
— причём это даже без режима thinking. Впрочем, это всё и так было понятно.
Требование "полного доступа для легаси" от бизнеса очень хорошо купируется понятным и легко проверяемым процессом согласования, в соответствии с которым при разборе инцидента следствие за пять минут выходит на виновника торжества - обычно того самого овнера, требующего сделать всё нараспашку. А чаще - такие заявки просто заворачиваются на стадии согласования ИБ, которые, если им платить не палку, очень даже заинтересованы и в правильной архитектуре, и в мониторинге, и в аудите.
В итоге, сегментация LAN ... ломается из-за неправильной модели
...
Чтобы она реально работала, нужно:
...
Правильная архитектура
Точно, и как мы сразу не догадались сразу сделать правильно.
Итак, сегментация — это не разовая задача, а постоянный процесс.
Действительно, если сразу не догадались, да ещё и требования меняются со временем, то это превращается... в процесс догадывания!
Вроде бы проблемы подсветили, а под конец воды налили и ссылку на канал не забыли. Зачем вы так?
Вы упустили еще один функционал фаервола - IPS/IDS. В идеале волл должен просеивать весь критичный трафик через сенсоры. В отраслях где требуется повышенный уровень безопасности трафик проходит чрез устройства от разных вендоров для концентрации компетенций от разных производителей оборудования.
Кроме того любая фиговина в IT это процесс, потому что в мире красноглазок многое быстро меняется и все что не включено в поток быстро отсыхает, заклинивает и начинает пахать землю пока не отвалится.
Как обычно, причина в человеческом факторе. Мало специалистов, способных внедрить и поддерживать сегментацию сети:
1) используем принцип "нулевого доверия" конечных точек
2) внедряем host-base firewall, включая уровень контейнеризации
3) используем сегментацию на гипервизоре (NSX или аналоги)
4) сегментируем сеть аппаратными МСЭ по зонам безопасности
5) покрываем это всё единой системой управления, которая автоматически раскатывает правила сразу после согласования доступа
В совокупности с базовыми процедурами харденинга инфраструктуры это дает очень большую фору команде SOCa при кибератаке.
Подскажите по пункту 5, какие есть единые системы управления? А есть работающие с отечественными межсетевыми экранами?
Вам поможет инженер NetOps, лучше 2 инженера.
Большинство отечественных МСЭ поддерживают REST API, дальше всё понятно.
Ничего не понятно и далеко не все его поддерживают. А если и поддерживают, то без слёз не взглянешь на это. Есть такое как Natex -- пойди у них админку с кнопочками попроси.
Там хотя бы терминал есть? Тогда инженер NetOps с помощью ansible или аналога может решить задачу.
Важно понять, что нет готового мультивендорного ПО, который "из коробки" одной кнопкой закроет все задачи по автоматизации. Есть наборы инструментов, которые напоминают фреймоврки, конструктор. Некоторые из них коммерческие, некоторые опенсорсные. Выбор инструмента делается в первую очередь исходя из ИТ-ландшафта предприятия и опыта сотрудников, которые этим инструментом будут пользоваться. А если точнее, сначала нанимаются люди под задачу, а затем они выбирают практичный инструмент, а не наоборот.
IT-сфера далека от производства, где на первом месте станки с приложенными к ним операторами. В IT на первом месте люди, а остальное вторично.
Там хотя бы терминал есть?
Конечно есть. CLI было есть и будет
инженер NetOps с помощью ansible или аналога
я вообще не вижу проблем, лично я презираю декларативно-алиас фреймворки типа ansible или netmiko/paramiko/napalm, но приходится использовать.
Потому что русский продакт тащит это в свои инфраструктуры не понимая сути.
Моя личная боль это NetBox.
А если точнее, сначала нанимаются люди под задачу, а затем они выбирают практичный инструмент, а не наоборот.
Удачи вам на поприще очередного мертворождённого проекта. Я прям сейчас могу назвать десяток брендов с момента "импортозамещения", которые думали также и искали людей (прям на HH были обязанности типа: реверс-инжиниринг реализации протокола MPLS/MED Huawei Cloud и далее версия прошивки). Я даже на собеседование к таким попал.
IT-сфера далека от производства
Нет. ИТ это и есть станки, протоколы, транспорт.
В IT на первом месте люди, а остальное вторично.
посадите 10 фигма-девочек и 40 бренд-аналитиков/менеджеров в докер-контейнер, пускай запускают продукт. Дайте им всем кофе и печеньки, не забудьте про ДМС.
Потому что русский продакт тащит это в свои инфраструктуры не понимая сути.
Именно про это речь: инструмент не должен являться самоцелью. Если хотите построить деревянный дом, наймите квалифицированную команду плотников и хорошего бригадира. Вам должно быть абсолютно всё-равно, какой инструмент они будут использовать для достижения цели. Если будете навязывать свой инструмент, скорее всего получится только хуже.
Я прям сейчас могу назвать десяток брендов с момента "импортозамещения", которые думали также и искали людей
Много крупного энтерпрайза в России успешно перешло на whitebox. Это реально работает: надежно, стабильно, функционально. Но только при некоторой квалификации персонала, не с дефолтными настройками.
посадите 10 фигма-девочек и 40 бренд-аналитиков/менеджеров в докер-контейнер
Зачем? Перечитайте мой первый комментарий в треде, где говорится о проблеме квалифицированных кадров. 50 выпускников онлайн курсов или самозванцев (проще говоря "пассажиров") не заменят даже одного грамотного IT-инженера уровня lead.
На мой взгляд, главная проблема у большинства русского энтерпрайза - ярко выраженный эффект Данинга-Крюгера. В компаниях, где карьерный трек строится по форме меритрократии, очень редко поднимается вопрос о покупке "волшебной пилюли" для решения задач бизнеса. Собственно, весь этот пост выглядит как попытка оправдать некомпетентность какими-то внешними факторами или непреодолимой силой.
У любого нормального железа, выпущенного в последние лет 10-15, есть провайдер Terraform. Правила описываются как код, после согласования создаётся PR с изменениями, ревьюится, при мёрже CI автоматически применяет новую версию правил.
она обычно у вендоров IPS/IDS есть. У IDECO точно должен быть. У Элтекса вроде в процессе.
"единая система управления" = "единая точка отказа" = "единая цель для взлома".
и для @AVikont чтобы два раза не писать.
если у вас все хосты настроены по Zero Trust, то
никакая сегментация не нужна, у вас уже есть микросегменты.
если некоторые хосты технически невозможно настроить по Zero Trust,
вот тогда придется думать про сегментацию.
С подходом согласен, он рабочий. Проблема лишь в том, что такая архитектура требует зрелой команды, процессов и бюджета. В статье как раз про то, что в большинстве инфраструктур до этого уровня просто не доходят, и сегментация остаётся упрощённой и формальной
такая архитектура требует зрелой команды, процессов и бюджета
Согласен частично: формально правы, по существу нет.
Такой подход требует наличие сотрудников с компетенциями. Самоучки после 2 недельных курсов точно не потянут, т.е. снова всю упирается в человеческий фактор. Процессы создают кадры, команду формируют лидеры, а бюджет влияет очень опосредованно.
В маленькой конторе всё вышеописанное может сделать 1 человек (примеры знаю лично), среднем бизнесе нужен отдел, в крупном - департамент с налаженными кроскомандными взаимодействиями. В каждом из сценариев требуются кадры, обладающие нужными компетенциями, иначе любой, даже самый раздутый бюджет, будет "не в коня корм".
Но в реальной инфраструктуре сегментация почти никогда не работает так, как задумано. Исключения множатся, легаси-системы требуют полного доступа, бизнес настаивает на удобстве, а контроль за правилами постепенно исчезает.
Всё отлично работает в реальной инфраструктуре. Нужен доступ - пилишь заявку на него с указание откуда и куда и по каким портам. Потом после апрува безопасников эту заявку исполняют сетевики.
легаси-системы требуют полного доступа
Любое приложение общается по сети по конкретным протоколам и конкретным порта. Никакой полный доступ не нужен. Узнать порты можно через Wireshark или tcpdump.
Это работает на бумаге. В жизни заявки делают с запасом, временные доступы не закрывают, а легаси проще "открыть шире", чем разбирать tcpdump неделями
Если нужно внедрить новый сервис/софт - в документации должен быть четкий список портов и описание всех потоков данных. Если нет такого - не стоит это внедрять.
Возможно, в малом и среднем бизнесе так и делают (полный доступ, временный доступ без указания срока, внедрение ПО без сопровождения и без документации), но в корпоративном сегменте "с запасом" не прокатит, надо ещë и обосновать каждый открытый порт и список адресов.
Конечно, если без такого легаси софта (разработчика уже нет, доков нет, и нет людей, кто бы знал что-то ценное) работа встанет или компания понесет убытки - тут уже на страх и риск руководства, перевешивают ли эти убытки потенциальные риски компрометации всей сети и возможной остановки бизнеса (потери на восстановление могут оказаться сильно больше).
Это работает на бумаге
Не берусь спорить, галеры разные бывают, и фигма-девочки теперь тоже IT. Но по своему опыту в федеральных провайдерах и крупных холдингах могу сказать, что от заявки "сделать пошире" пошире становится только у такого заявителя. Потому что никто. Повторяю и подчеркиваю НИКТО не будет заниматься самодеятельностью, брать инфраструктурные риски и делать пошире, потому что так линейному сотруднику "быстрее" или "удобнее".
чем разбирать tcpdump неделями
Я так понимаю, что вы не разбираетесь как это работает, но имеете своё мнение. Что конкретно вы разбираете в tcpdump неделями, если порты и адреса dst-src указаны в заголовках пакета?
Статья человека далекого от сетей... Возьмите книжку, а не чатгпт, Таненбаум для острастки подойдет, там про широковещательный домен, и разные типы vlan будет, да много интересного будет
Осталось посчитать ущерб от сегментации.
Что реально пугает - когда читаешь такой лютый бред по теме, в которой хорошо разбираешься, начинаешь с сомнением относиться к материалам по менее изученным темам.
Понял, беру на заметку))
Пугает ещë и то, что всем пофиг. Этим ведь и ценны комментарии, что тут знающие люди разложат по полочкам, что где не так написано. Хотя, часто я сам что-то прочитаю по хорошо известной мне теме, и первая мысль - да вот я сейчас в комментах распишу что не так. Но вторая мысль - блин, да тут это я по сути всю статью перепишу заново, ну его нафиг. (Не относится к этой статье, я не сетевик)
Так что если есть ценные замечания - я бы почитал, тема-то интересная.
Начну с заголовка. Если автор не видел нормальных имплементаций VLANов - значит он не видел или мало видел, а не "они не работают". Выше @AVXвполне объяснил как надо работать с вланами и правилами файерволов. Если нет никакого плана и процессов управления и регулярных пересмотров - то да, конечно смысла в сегментации становится сильно меньше. Но то же самое можно сказать и про резервирование адресов на DHCP адресов.
Или, вообще довести до абсурда, приводя негативные примеры применения любого инструмента и экстраполируя их на всю отрасль или весь мир
Кроме того, в дисциплине, которая называется business continuity planning (простите, не могу адекватно перевести на русский) есть термин blast radius (этот уже не хочу переводить, уж очень нравится). Так вот, вланы позволяют значительно сократить этот самый blast radius, в случае если в сети что-то идет не так. Если закончились адреса, кто-то устроил широковещательный шторм, малварь начала себя рассылать по локалке или другой аномалии, ее проще локализовать и изолировать, когда в сети есть сегментация.
В своем опыте скажу - мы выделяем не только департаменты, но и отдельные службы и отделы в отдельные вланы исходя из используемых сервисов, после этого проковыриваем нужные дырки в файерволе, навешиваем IPS/IDS, любое изменение надо обосновать, и не просто "производственной необходимостью", а полноценным разбором какие протоколы на каких портах на каких хостах работают с регулярным аудитом и закрытием неиспользуемых портов.
И это все при том, что я не безопасник, а сетевик.
Согласен, именно так. VLANы реально работают, когда есть процессы, аудит и контроль изменений. В статье я просто показываю, что в большинстве инфраструктур этих процессов нет, и сегментация превращается в формальность
Слабо разбираюсь в теме, но почему не строить сразу на исключениях? Не просто «пускать всё такого типа, оттуда и сюда», а «пусти от него ему только вот это» × N (для каждой пары адресов и портов отправителя и получателя, каждого типа и т.п.). Можно даже уточнять более жёстко, фильтровать, мониторить, отслеживать подозрительную активность и так далее. Или сегментация действительно чем-то лучше? Либо просто слишком муторно?
Кажется, что я как раз и говорю об исключениях. Но исключения применяются не к индивидуальным устройствам, а к вланам. Можно и индивидуально на каждое устройство навешивать исключения, но это плохо масштабируется. Представим кейс, у вас сеть на 2500 устройств, это легко может превратиться в 10тыс+ правил на файерволе. В отдел X наняли два новых человека - значит нужно создать профили для их давайсов и назначить им нужные исключения, из отдела Y уволили два человека - снова работа с профилями устройств. В то время как с вланами работа упрощается, уменьшается количество правил за счет их группировки.
Это только аспект управления исключениями. Еще есть уровень L2 стека TCP/IP и все с ним связаннные риски, которые не разделить/митигировать если не делать полной изоляции клиентов на том же уровне L2 посредством фич на коммутаторах, роутерах и файерволах.
А еще вопрос адресации, когда проблема на машине с адресом W.X.Y.Z и ты знаешь что Х - это офис в Твери, Y - бухгалтерский влан, то трабл шутить получается чуточку быстрее.
Представим кейс, у вас сеть на 2500 устройств, это легко может превратиться в 10тыс+ правил на файерволе.
Что за дичЪ? VLANы предназначены транспортом управлять. Как фаерфол к ним относится? Например, по ACL MAC (или Port Security) можно сделать так, что даже в правильном влане трафик выше access порта не уйдёт.
профили для их давайсов
снова работа с профилями устройств
В то время как с вланами работа упрощается, уменьшается количество правил за счет их группировки
Ничего не понятно, но очень интересно. С какими профилями устройств помогает группировка по влан. И какое отношение это всё имеет к фаерволу, который работает на L3+
Возможно, мы по-разному понимаем исключения. Для меня исключение - это разрешить кому-то доступ по определенному порту к определенному хосту. Базовый коммутатор (даже L3) не различает порты и TCP/UDP, следовательно такие исключения нужно разруливать на файерволе. Их можно навешивать глобально, можно на диапазоны адресов, а можно на индивидуальные хосты.
Один крайний случай, глобальный, если вы что-то разрешаете одному пользователю, то разрешаете всем. Не хочу объяснять почему это плохо.
Другой крайний случай - на каждый хост мы вешаем свои индивидуальные правила, без группировки. Каждому открываем 80, 443 через TCP и UDP - уже 4 правила, если хостов 2500, получаем 10000 правил. Понятно, что никто так не делает, и есть набор базовых правил, которые мы применяем ко всем. Но представим, что из 2500 хостов, у нас 500 разработчиков, которым нужен доступ к железу через SSH, десятку устройств - это 5000 правил, к базам MySQL на порту 3306, тоже к десятке баз каждому, еще 5000 правил.
Это дичь и поэтому никто так не делает, все группируют хосты и навешивают правила на хосты.
Профили - это группы правил на файерволе, группа разработчиков баз получает один профиль, с открытыми mysql портами, группа сетевых инженеров получает профиль с набором открытых SSH портов на нужные хосты. Кажется, оптимальный подход.
Остается только решить, как же все-таки группировать хосты? Назначать фиксированные IP адреса и вести их реестр? Можно, но каждый новый девайс - ручная работа, мне такое не нравится. Вот тут помогают вланы, влан это не только L2 сегментация, ее можно расширить на L3, когда в каждом влане живет свой инстанс DHCP сервера, который выдает адреса только из своего скоупа, получается что влан А эквивалентен диапазону 10.10.A.0/24 (маска - условная), влан B - диапазону 10.10.B.0/22 (снова маска - условная). И на эти диапазоны навешиваются правила.
Как вы эту схему можете реализовать с помощью ACLей на порту - не знаю.
Более детально объяснять не хочу, извините.
Самый простой пример Сбер. 200 сегментов сети где сегменты разделены фаерволом и на которых прописаны правила общения где то сеть ту сеть где то хост ту хост но есть проблемы
1) в рамках сегмента все видят друг друга без ограничений а значит весь прод видит весь прод
2) железные фаерволы которые могут переваривать миллионы правил утопают в мусоре, От которого сложно избавиться в продакшене
Вы или в терминологии плаваете, или это не ваша работа, и вы рассказываете по слухам.
Назначать фиксированные IP адреса и вести их реестр?
Да. IPAM называется. К порту привязывается MAC устройства и прибивается IP адрес. Сетей всего 2: 10.0.0.0/8 и 172.16.0.0/16 (если на предприятии вы используете 192.168.0.0/16 мои вам соболезнования. Значит вы ещё ни разу не ловили "партизанский DHCP-сервер в виде домашнего роутера или noname-коммутатора", а все остальные access порты имеют VLAN ID 1) и вам этих двух сетей хватит на что угодно. Если не хватит o_O, то делаете ещё разбивку по VRF.
все группируют хосты и навешивают правила на хосты
впервые слышу. В нормальных конторах создаются профили с подсетями. Подсеть соответствует рабочей задаче. Далее к хосту при выдаче адреса применяются групповые (профильные) правила.
Профили - это группы правил на файерволе, группа разработчиков баз получает один профиль, с открытыми mysql портами, группа сетевых инженеров получает профиль с набором открытых SSH портов на нужные хосты. Кажется, оптимальный подход.
Верно
как же все-таки группировать хосты? Назначать фиксированные IP адреса и вести их реестр?
Да. Именно так. Я вам больше скажу, ещё по сети ходит несколько ботов, которые сверяют соответствие выданных адресов, адресов онлайн, и формируется отчёт раз в сутки: всего в IPAM - 1524, онлайн - 1527, unknown - 46. И инженер идёт разбираться почему так происходит. Не потом, когда пресс-служба оправдалочки в соцсети пишет, а сразу, как заметили аномалию.
влан это не только L2 сегментация
потому что VLAN это не сегментация. Это ограничение широковещательного домена. Ещё в сетях бывает мультикаст и управление трафиком: когда у вас несколько роутеров с разными протоколами. Ну это скорее нюансы.
ручная работа, мне такое не нравится
Перефразирую классику: если вы не контролируете свою сеть, то её контролирует кто-то другой. Я когда такие тейки слышу, то всегда напоминаю про этот случай: https://habr.com/ru/articles/536750/
Там тоже утверждали, что проблем с безопасностью сети нет, это просто user-fail.
получается что влан А эквивалентен диапазону 10.10.A.0/24
нет, не получается. А если 10.10.A.0/24 закончился и надо во VLAN добавить ещё 10 подсетей? Типа 10.10.B-L.0/24. А завтра вы уволитесь и вся ваша богодельня перейдёт под управление другому инженеру? Что он будет с ней делать? Сидеть NMAPом подсети сканировать?
И на эти диапазоны навешиваются правила
И как вы это делаете? Суммаризуете или у вас каждая подсеть = своё правило?
Без обид, но я такое понимание сетей часто встречаю у условных "win-admin", которые прослушали CCNA. Какие-то общие и очень смутные представления о работе технологий, к тому же неправильное их использование.
Как вы эту схему можете реализовать с помощью ACLей на порту - не знаю.
Очень просто. Хост без моего разрешения и чёткого понимания что именно это за хост работать не будет.
Переписка в джире будет выглядеть именно так:
XXX: Включите интернет и дайте доступ к dev-zone. У нас новый сотрудник.
YYY: Админы выдали рабочий ПК?
ХХХ: Ещё нет. Сотрудник пока со своим посидит.
YYY to ZZZ+UUU: Товарищ, техлид и devsec, берёте на себя ответственность?
ZZZ to XXX: Ждите
UUU to XXX: Почему через голову прыгаете и нарушаете регламент? Объяснительную напишите.
На этом всё заканчивается.
Вы спросили, то что вам было непонятно, я постарался объяснить, говорить что вы делаете неправильно - не буду, нет подхода который на все случаи жизни подходит. В моих сетях, где куча BYOD, в день может выйти 50 новых человек и еще параллельно есть гостевая сеть, не вижу никакого смысла резервировать адреса за устройством, вместо этого по сертификату если устройство корпоративное или аутентификации в веб-морде если byod, пользователь попадает в свой влан, где получает соответствующие правила. Какой у него адрес в подсети 10й или 110й, мне мало интересно, правила применяются на влан, который эквивалентен подсети, потому что влан теги до файервола не доходят.
все группируют хосты и навешивают правила на хосты
Здесь - опечатка. Хотел написать, "все группируют хосты и навешивают правила на группы хостов"
Обычно BYOD в типовом сценарии имеет доступ только в Интернет через гостевую сеть. На устройстве после прохождения комплаенса поднимается VPN канал с доступом к терминальному серверу через брокер. Терминальный сервер в DMZ, ограничение доступа на сетевом уровне по учетной записи, которая входит в одну из групп/профилей МСЭ.
Этим сетевая сегментация обычно ограничивается, дальше ограничения уже на уровне приложения через IDM.
В строгих корпоративных сетях -да. Но у нас byod - это среднее между корпоративным и гостевым. Так или иначе, byod нужно отличить от корпоративного девайса и от гостя и выдать ему соответствующие правила. И еще byod у нас бывают разных цветов. Все это вести руками в IPAM - сложно, поэтому у нас селф-сервис, пользователь либо заранее регистрирует свои byod девайсы, либо непосредственно при входе через captive portal привязывается MAC девайса к учетке.
Но мы начинали с сегментации сети вланами
у нас 500 разработчиков, которым нужен доступ к железу через SSH,
поэтому мы гоним их на кластер из 2 (3? 4?) ssh jump servers,
которые сами пробросят их по ключам и юзернэймам куда кому положено.
к базам MySQL на порту 3306, тоже к десятке баз каждому
поэтому мы гоним их на кластер из 2 (3? 4?) ssh jump servers,
которые сами дадут им туннели по ключам и юзернэймам с 127.0.0.1:xxxxxx на 127.0.0.1:3306/tcp
куда кому положено.
Более детально объяснять не хочу, извините.
объясню более подробно и даже с обучением, если мой интерес будет подогрет.
Тем что влан это разделение на броадкастные домены где в рамках влан живут сети л3, дальше общение между вланами это чистый л3
Я считаю, что статья - фуфло.
Проблема ясна и понятна, тем более ей столько же, сколько существуют vlan-ы: бизнес хочет быстро и чтобы работало, а it - чтобы работало, но «секьюрно». В итоге или комфорт или безопасность! Кстати принцип быстро, качественно и недорого - тут так же действует, как и в любых других вопросах, вот и думайте
Для решения таких задач надо использовать host based firewall решения которые закрывают такие проблемы
https://h-bf.prorobotech.ru/tech-docs/components
Это продукт который мы пишем для решения такой задачи
Нормальное централизованное решение это 802.1x + SGT. Но внедрение долгое и дорогое
Вцелом диагноз поставлен более менее верно. В теории надо делать по-другому но на практике получается часто так как описано (плюс-минус). Для организаций разной степени запущенности и размера нужен индивидуальный подход, но есть некакая минимальная гигиена
Из своего опыт скажу:
Стараться не использовать или сильно минимизировать подход нарезания доступа под персональные ИП-адреса. Страться писать влан-бэйзед правила. Чем больше индивидуальных правил тем сложнее это поддерживать со временем и тем больше нагрузка на CPU фаервола. Фаерволить внуурисерверный трафик может быть дорогой затеей по железу, так что надо смотреть а потянет ли оборудование хотелки безопасности.
Отделить клиентскую зону от серверной. В каждой из этих зон надо выделять специализированные подзоны. Например подсеть ПС обычных юзеров, подсеть сисадминов, подсеть девелоперов, подсеть ВПН. Сервера тоже поделить на несколько вланов, либо по системам, либо по типам сервисов, однозначного рецепта нет. Но если брать минимум, то привелегированные юзеры, которые админят сеть должны быть отделены от обычных бизнес-юзеров. Сервера можно делить на фронт, мидл, СУБД.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сегментация LAN: почему она почти никогда работает