Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1 2 3 След.
RSS
Борьба с arp-спуфингом, Используя управляемый коммутатор
 
Вообще, этот вопрос уже поднимался на форумах секлаба, но ничего конкретного тогда я изъять не смог из сообщений...

Суть: есть управляемый коммутатор CiscoCatalyst 2940. Как с помощью него можно бороться с arp-спуфингом? Как я понял, port-security не катит. Но можно привязывать к порту и МАС и IP (кажись, это IP-MAC Binding). В этом суть борьбы?
Если я на верном пути - какие ещё есть именно средствами управляемых коммутаторов
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Всё наверно зависит от того хотите вы обезопасить комутатор от того чтобы он н сходил сума и не менял постоянно свою ARP таблицу, либо от того же пользователей подключённых к этому комутатору.
port-security эта технология если я не ошибаюсь всего лишь навсего разрешает проходить через указанный порт коммутатора ограниченное количество заранее указанных пар ИП/МАК.
ip-mac binding это уже более широкое понятие, опять же если не ошибаюсь это просто статическая арп таблица на свитче.
Можно боротся как с помощью одного так и с помощью другого насколько я понимаю. Эти статически таблицы так же в свою очередь запретят прохождение других арп ответов не таких как зарегестрированны в АРП таблице свитча, этим клиенты "обезопасиваются"
 
Цитата
Pchol пишет:
Можно боротся как с помощью одного так и с помощью другого насколько я понимаю
И каким же образом port-security будет защищать от arp-спуфинга?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Хм... А почему нет ? Доступ к порту получают же только те пары ип/мак которые указаны, тоесть доверенные ip.  Если кто то и начал спуфить из этих доверенных это уже другое...
 
:?: А как на счет вланов то? Конечно внутри каждого сегмента остается возможность спуфить, но сведена до минимума и определение атакующего решится в раз :)
определение IP-MAC Binding наверно на разных коммутаторах разное означает. В нашей сети коммутаторы Д-линк
вот от туда-
----------------------
Функция IP-MAC-Port Binding в коммутаторах D-Link позволяет контролировать
 доступ компьютеров в сеть на основе их IP и MAC-адресов, а также порта
 подключения. Если какая-нибудь составляющая в этой записи меняется, то
 коммутатор блокирует данный MAC-адрес с занесением его в блок-лист.
----------------------------

Как уже замечал в одной из тем - ИМХО: самая тупая функция какую можно было придумать.
 
Цитата
tmp пишет:
Как уже замечал в одной из тем - ИМХО: самая тупая функция какую можно было придумать.
Почему? Чем плохо контролировать связку MAC/IP и лочить порт если обнаружено нарушение?

Цитата
Pchol пишет:
Доступ к порту получают же только те пары ип/мак которые указаны, тоесть доверенные ip
Как я понял, port-security следит только за МАС на поределённом порту, но не за МАС/IP одновременно. За одновременным следит IP-MAC Binding.
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Почему? Чем плохо контролировать связку MAC/IP и лочить порт если обнаружено нарушение?
Тем что юзер может не знать о настройках коммутаторов, принести ноут для необходимой транзакции, втыкает (абсолютно имея на это право, так как у Вас договор о предоставлении канала по этому кабелю этому юзеру, да и на основании простых человеческих понятиях))) и.... он уже блокирован. Или же есть еще куча вариантов развития подобных событий. Да думаю можно и червей написать или вирей чтоб они отправляли пакет с рендом мамком и бедный юзер уже блокирован... не серьезно.
 
А tmp озвучил очень правильную мысль. Я про "насчёт виланов". На каждый порт свича назначается свой УНИКАЛЬНЫЙ VLAN. А на кошке аксес-листами разрешается хождение пакетов только в связке VLAN+IP. Всё! Проблема будет решена без всяких МАК-адресов, которые можно подделать.
 
Про VLAN'ы я понял, приму к сведению (уже открыл страницу в википедии по этому поводу и загружаю от туда знания в свою голову :) )

SOLDIER, tmp, ловите по голосу :)


Но вернёмся к IP-MAC-Port Binding и port-security. Отбросив их минусы (описанные tmp'ом). Эти функции могут решить проблему arp-спуфигна?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:

Но вернёмся к IP-MAC-Port Binding и port-security. Отбросив их минусы (описанные tmp'ом). Эти функции могут решить проблему arp-спуфигна?
Частично.
Наиболее радикально - protected port.
 
KIRIFAN,
Почему частично?

С port-security понятно. Но с IP-MAC-Port Binding...
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Shanker, статейку прочитай на наге - не на 100% то, что ты ищещь - но путь к защите от ARP-флуда там указан - http://www.nag.ru/2007/0617/0617.shtml
 
SOLDIER,
Флуд и спуфинг - вещи несколько разные. За статейку спасибо, почитаю

Прочитал про VLAN. Правильно ли я понял, допустим сделаю я VLAN на каждый порт. С порта №1 атакующий сканит сеть. Оказывается, что МАС-и у всех просканенных одни и те же (который является адресом свитча). Т.е. фактически это эквивалетно разбиванию на подсети. А в подсети 1 комп. Получается, на arp-запросы будет отвечать сам свитч в этом случае, до целевого компа не дойдёт arp-пакет, верно?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
VLAN - тема тонкая. ARP-протокол воде как никак не привязан (в части сканирования) к VLAN. На уровне свича второго уровня строится некая матрица коммутации. MAC-MAC. Или я устал уже и ни бельмеса не понимаю? Shanker, задача какая в итоге? Предотвратить помену МАКа? я тебе указал самый верный путь, проверенный на практике. Вообще тема помены связки МАК-ИП неоднократно обсуждалась на форуме сетевиков. Ещё одну ссылку на НАГ дать? :)
 
Вот немного хорошей инфы (но к сожалению очень коротко)
ССылка
 
О!!! А вот нашел отличную ссылу, комментируют возможность VLAN spoof сами монстры этого спуфинга ;) ALoR & NaGA!!!!! СУПЕР!!!!!!! Ща сам буду читать! Случайно наткнулся :)

http://www.askapache.com/security/bypassing-vlan.html
 
tmp, расскажешь? А то ща лень смотреть. Мне в принципе неинтресно после варианта VLAN.
 
А вообще,если угодно расскажу как я боролся в одной пионерсети в силу технологии (бабла не было на сиськи) с подменой. Но не неинтириснаааа. Ий Богу.
 
Впрочем. Всё просто. Если нет бабла на сиськи - есть админ- который отслеживает по логам работу arpwatch. скучно и смешно. :)
 
Цитата
SOLDIER пишет:
tmp, расскажешь?
:) Ок! Насколько я понял там чел описывает проникновение на свич другого ВЛАН с последующей его настройкой под себя. то есть как такового нового вида арп-спуфинга не происходит))) Просто описана уязвимость коммутаторов посредством поднятия у себя влан маршрутизатора и отправкой от себя пакетов с вланID тарджет-а, дальше коммутатор пропускает такие пакеты и еще дальше они  проходят с нужным нам вланID, интересно что коммутатор тарджет отвечает на эти пакеты). (это насколько я понял, хотя сам бегло прочел, вечером попробую по подробней разобрать детали))Говорят что не все коммутаторы этому подвержены, но списка какие уязвимы а какие нет - нету. Надо наверно все проверять на практике:) Хотя в нашей сети и без ВЛАН нельзя на левый коммутатор законнектиться.... надо будет что то тоже придумать ;)
Еще очень хороший (надеюсь, пока еще не читал) док на эту тему закачал http://www.sans.org/rr/papers/38/1090.pdf
---------------------
Based on Blackhat report [11], we decided to investigate some possibilities to attack VLANs
-------------------------
Прийдется и это почитать.
Страницы: 1 2 3 След.
Читают тему