Мы планируем перевести нашу производственную сеть из конфигурации без VLAN в конфигурацию с теговой VLAN (802.1q). Эта диаграмма суммирует запланированную конфигурацию:
Одна важная деталь заключается в том, что большая часть этих хостов фактически будет виртуальными машинами на одном компьютере с «голым железом». Фактически, единственными физическими машинами будут DB01, DB02, межсетевые экраны и коммутаторы. Все остальные машины будут виртуализированы на одном хосте.
Одна из проблем заключается в том, что этот подход является сложным ( подразумевается чрезмерно сложным ), и что VLAN предоставляют только иллюзию безопасности, потому что «переключение VLAN легко».
Это действительная проблема, учитывая, что несколько виртуальных локальных сетей будут использоваться для одного физического порта коммутатора из-за виртуализации? Как правильно настроить VLAN, чтобы предотвратить этот риск?
Кроме того, я слышал, что в VMWare ESX есть нечто, называемое «виртуальные коммутаторы». Это уникально для гипервизора VMWare? Если нет, доступно ли это с KVM (мой запланированный гипервизор)? Как это входит в игру?
источник
Ответы:
В дополнение к информации о том, почему люди говорят мне не использовать VLAN для безопасности? Вот некоторые более конкретные и общие биты для рассмотрения:
Общие соображения о безопасности
Наиболее защищенная система - это система, в которой хосты каждой подсети подключены к коммутатору, имеющему ровно столько портов, которые будут использоваться подключенными устройствами. В такой конфигурации вы не можете подключить случайные машины к вашим защищенным сетям, поскольку для этого потребуется что-то отключить (и теоретически ваша система мониторинга заметит это).
Сети VLAN дают вам нечто похожее с точки зрения безопасности, разделяя ваш коммутатор на более мелкие виртуальные коммутаторы (виртуальные локальные сети: VLAN), которые логически изолированы друг от друга, и при правильной конфигурации могут отображаться для всех подключенных к ним систем, как если бы они были физически. изолированы.
Общие соображения относительно относительно безопасных настроек VLAN
Моя практика для коммутаторов с поддержкой VLAN заключается в том, что весь трафик должен быть назначен VLAN со следующей базовой конфигурацией:
Назначьте все неиспользуемые порты «неиспользуемой» VLAN.
Все порты, подключающиеся к определенному компьютеру, должны быть изначально назначены той VLAN, в которой должен находиться компьютер. Эти порты должны быть в одной и только одной VLAN (за исключением определенных исключений, которые мы пока проигнорируем).
На этих портах все входящие пакеты (к коммутатору) помечены с помощью собственной VLAN, а исходящие пакеты (с коммутатора) будут (а) исходить только из назначенного vlan и (b) не иметь тегов и выглядеть так же, как любой обычный Ethernet пакет.
Единственными портами, которые должны быть «магистралями VLAN» (портами в более чем одной VLAN), являются магистральные порты - те, которые передают трафик между коммутаторами или подключаются к брандмауэру, который разделит трафик VLAN самостоятельно.
На магистральных портах теги vlan, поступающие на коммутатор, будут учитываться, а теги vlan не будут удаляться из пакетов, покидающих коммутатор.
Описанная выше конфигурация означает, что единственное место, где вы можете легко внедрить трафик «VLAN hopping», находится на транковом порту (исключая проблему с программным обеспечением в реализации VLAN ваших коммутаторов), и очень похоже на «наиболее безопасный» сценарий, это означает отключение чего-либо важно и вызывает тревогу мониторинга. Точно так же, если вы отключите хост для подключения к VLAN, он живет в вашей системе мониторинга, вы должны заметить таинственное исчезновение этого хоста и предупредить вас.
В обоих этих случаях мы говорим об атаке, включающей физический доступ к серверам. Несмотря на то, что сломать изоляцию VLAN может быть совершенно невозможным, это как минимум очень сложно в среде, настроенной, как описано выше.
Особые мысли о безопасности VMWare и VLAN
Виртуальные коммутаторы VMWare могут быть назначены виртуальной локальной сети. Когда эти виртуальные коммутаторы подключены к физическому интерфейсу на хосте VMWare, любой отправляемый трафик будет иметь соответствующую метку VLAN.
Физический интерфейс вашей машины VMWare должен быть подключен к транковому порту VLAN (с переносом VLAN, к которым ему потребуется доступ).
В подобных случаях вдвойне важно обратить внимание на рекомендации VMWare для отделения NIC управления от NIC виртуальной машины: ваша NIC управления должна быть подключена к собственному порту в соответствующей VLAN, а ваша NIC виртуальной машины должна быть подключена к транк, в котором есть виртуальные локальные сети, необходимые виртуальным машинам (которые в идеале не должны содержать виртуальную локальную сеть управления VMWare).
На практике соблюдение этого разделения в сочетании с упомянутыми мною пунктами и тем, что, я уверен, придут другие, создаст достаточно безопасную среду.
источник
Перескочить VLan легко, если и только если мошенническим устройствам разрешено передавать пакеты по транкам без тегов VLAN.
Это наиболее часто встречается в следующей ситуации. Ваш «нормальный» трафик не помечен; у вас есть «безопасный» ВЛВС, будет помечен. Так как машины в «нормальной» сети могут передавать пакеты, которые не проверяются на наличие тегов (чаще всего это могут быть коммутаторы доступа), пакет может иметь ложный тег vlan и, таким образом, переключаться на vlan.
Простой способ предотвратить это: весь трафик помечается переключателями доступа (брандмауэры / маршрутизаторы могут быть исключением в зависимости от конфигурации сети). Если «нормальный» трафик помечается коммутатором доступа, то любой тег, который подделывает клиент-мошенник, будет сброшен коммутатором доступа (поскольку этот порт не будет иметь доступа к тегу).
Короче говоря, если вы используете vlan tagging, то все должно быть помечено в стволах, чтобы обеспечить его безопасность.
источник
После проведения значительного количества тестов на проникновение в виртуальных средах я бы добавил следующие два элемента:
Спланируйте свою виртуальную среду точно так же, как и в реальной среде - поскольку любые структурные или архитектурные уязвимости, которые вы привносите в реальный мир, хорошо отразятся на виртуальном мире.
Правильно настройте виртуальную конфигурацию - 99% всех успешных проникновений в виртуальные машины или логические разделы, которыми я управлял, были связаны с неправильной настройкой или повторным использованием учетных данных.
И на менее технической ноте также подумайте о разделении обязанностей . То, что могло быть обработано сетевыми командами, серверными командами и т. Д., Теперь может быть одной командой. Ваш аудитор может найти это важным!
источник