Comments 18
А я то думал… а тут :-(
А вы метки читали? И шапку. Так чем я вас разочаровал? Я же дал вам повод написать… а я то думал. Правда, еще повеселить обещал, видно не получилось :)
Двойное тегирование и VLAN hopping? :)
Именно, что нет. Эти все угрозы известны и понятны. Для меня сюрпризом было именно тэгированный трафик (одиночно теэгированный) на нетэгированный порт (аксесс-порт в терминологии циско) — и оно работает (по крайней мере для АТ), и это реально по спецификации, а не глюк. Какое это имеет отношение к безопасности? Есть возможность, когда это фишка не выключена, т. е. не включена ингресс фильтрация, поднять у себя нужные влан-ы, хоть 1-й, и не смотря на то, что твой пользовательский порт как бы аксесс в юзерском влане — слать трафик в соотв. чужие вланы без всяких там двойных тэгирований (опять же повторюсь, циско такой пакет отбросит, АТ без указанной в топике команды — нет).
Но. Если вы попробуете попинговать таким образом в чужом влан-е что-нибудь — просто так не получится. ARP запросы туда уйдут, ARP ответы — не вернутся. Если вы знаете IP и MAC — в нужный влан уйдут уже IP пакеты, хотя обратный трафик будет по прежнему невозможен. Но это и не нужно. Есть атаки, которые этого не требуют. Банальный UDP-флуд у меня валит почти все старые AT-свичи (даже с последними для них прошивками). Поддельный широковещательный незапрошенный ARP ответ может подменить в ARP-кэшах устройств mac шлюза или любого другого хоста в влане (полноценный ARP-спуфинг не получится, будет простой DoS).
Но. Если вы попробуете попинговать таким образом в чужом влан-е что-нибудь — просто так не получится. ARP запросы туда уйдут, ARP ответы — не вернутся. Если вы знаете IP и MAC — в нужный влан уйдут уже IP пакеты, хотя обратный трафик будет по прежнему невозможен. Но это и не нужно. Есть атаки, которые этого не требуют. Банальный UDP-флуд у меня валит почти все старые AT-свичи (даже с последними для них прошивками). Поддельный широковещательный незапрошенный ARP ответ может подменить в ARP-кэшах устройств mac шлюза или любого другого хоста в влане (полноценный ARP-спуфинг не получится, будет простой DoS).
Мораль сей басни очень проста: пользуйтесь либо консолью, либо нормальными системами управления, если у вас большая и сложная сеть. Веб-гуи нужны админам у которых 3 свича в сети, и один роутер+дсл+вай-фай в однйо коробке.
Да, лучше консолью. Но не всегда от этого легче. В мануале весьма пухлом эта команда, мягко говоря, не на виду, а человеку, который не читая академических трудов начал свой админский путь с сети, построенной на циско, этим не болеющих, трудно найти черную кошку в черной комнате, особенно когда неизвестно, есть ли она там и что вообще нужно искать. Интереса ради я подкидывал этот вопрос (в неразжеванном, конечено виде), админам вышестоящих инстанций в нашей весьма большой, я бы даже сказал очень большой конторе, и мало кто сходу говорил что-нибудь в духе — ясен пень, семен-семёныч.
В свое время, читая nag.ru сильно удивлялся той разнице, что в академических Олиферах пишут и как реально работают реальные железки, китайские и не очень.
В свое время, читая nag.ru сильно удивлялся той разнице, что в академических Олиферах пишут и как реально работают реальные железки, китайские и не очень.
Ну проблема ведь не в знании команд. Я сам никогда не видел работающего switch infiltering. Единственное что мне приходило в голову пока читал ваш текст так это грабли с default vlan. Но нюанс в том, что когда встречаешь непонятное поведение чего то, то в консоли проблему гораздо легче найти, просто потому, что там есть всё (хотя иногда и нужно делать detail вывод, это кстати часто делают на олимпиадах и CCIE лабах). А вот в GUI обычно только то, что показалось нужным.
А про Олиферов это вообще отдельная песня. Книга хорошая, но нужная пожалуй только студентам в вузах. Это так, на ночь почитать про неизвестную тему, чтоб приблизительно понять что-куда.
Вообще отлично, что разобрались.
А про Олиферов это вообще отдельная песня. Книга хорошая, но нужная пожалуй только студентам в вузах. Это так, на ночь почитать про неизвестную тему, чтоб приблизительно понять что-куда.
Вообще отлично, что разобрались.
В свое время пригодились ваши публикации
habrahabr.ru/post/117099/
habrahabr.ru/post/117110/
Спасибо.
habrahabr.ru/post/117099/
habrahabr.ru/post/117110/
Спасибо.
Если не ошибаюсь, у D-Link такое тоже имеется и включается (выключается) командой:
config gvrp ingress_checking enable
config gvrp ingress_checking enable
Помоему Best Practice считается отключение untagged vlan (если быть точнее — соотв. порта) при использовании тегированного варианта.
Я правильно понимаю, что в таком случае эта фича (а imho это именно фича) не «прокатит»?
Я правильно понимаю, что в таком случае эта фича (а imho это именно фича) не «прокатит»?
Не совсем понял, о чем речь. Рассматриваемый порт на свиче пользовательский. Поэтому он untagged, каким же ему еще быть. Пользователь же может несанкционированно поднять у себя на сетевухе тегированные вланы. Если пользовательский порт будет на циско в режиме access без всяких там DTP — ему это не поможет, его теэгированные фреймы будут отбрасываться. В АТ же (и по дефолту стандарта 802.1q) они будут приняты. Что бы они были отброшены (что логично, нам этот эффект и нужен), надо включать ингресс фильтрацию.
спасибо, интересно! всегда думал, что свич будет вести себя чуть по другому.
Все немного по-разному, как оказалось. Я тут сейчас дома сижу, в пользовательском влане на группу (доступ в инет через впн) и без всяких активных атак а-ля переполнение fdb у свича или арп-спуффинга и вижу трафик одного из соседей (ему с мак-адресом не повезло). Достаточно редкий случай, что бы видеть вживую, а не в результате синтетического теста. Коллизия хеш-функции. Можете погуглить, на nag.ru году в 2010 активно обсуждалось на примере длинк-ов.
Почему это попало мне в ленту?
Sign up to leave a comment.
Побег из Vlan. Баг? Хак?! Фича… Или о пользе чтения документации