Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: Пред. 1 2 3 След.
RSS
Борьба с arp-спуфингом, Используя управляемый коммутатор
 
:)arpwatch - не так скучно - как очень трудоемкое занятие , скорее даже не скучно, а через чур весело ;)
 
Таки ознакомлюсь с приведёнными ссылками. По поводу описанного вида атаки (пока тоже не смотрел - сил нет) - дык VID знать надо. :) Обычный пользователь этой информацией не обладает. Признак VID, у нас, например, ставится на порту DSLAM (порту коммутатора в случае не АДСЛ). Я знаю номер пользовательского вилана, а вот пользователь - увы. Да и, например, выставишь ты на своей карте (если она поддерживает 802.1Q) VID - а толку? При попадании пакета в коммутатор - он всё равно выставит свой VID, который прописан в настройках порта. Сдаётся мне - не получится такой финт. Впрочем, может я и неправ-посмотрю, чего там написано.
 
Цитата
SOLDIER пишет:
Предотвратить помену МАКа? я тебе указал самый верный путь, проверенный на практике. Вообще тема помены связки МАК-ИП неоднократно обсуждалась на форуме сетевиков. Ещё одну ссылку на НАГ дать?
Спасибо за попытки объяснить мне. Давненько я не чувствовал себя нубом, но после твоих объяснений, это чувство-таки вернулось ;)
На самом деле, пойду уж почитаю ссылки рекурсивно (а то одного раза, наверное, мало будет) и уж потом буду здесь что-то спрашивать. А то как-то не хорошо получается... Всё-таки, думаю, отвлекаю спецов элементарными вопросами, на которые есть ответы в придевённых ссылках.
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Да перестань. Тоже мне специалиста нашёл. :) Вполне нормальный вопрос, который размещён в соответствующей его тематике ветке форума.
 
Цитата
SOLDIER пишет:
дык VID знать надо
Я тоже об этом подумал:)
ЗЫ
Похоже я не совсем правильно понял, ща читаю док Blackhat report, кажись та атака возможна только из коренного влана. Что по дефолту - VID=1
 
Дефолтный вилан (VID=1) имеет место прогоняться по умолчанию, как управляющий. :) Вот тут - правильно.
 
Итак, кое-чего я почитал, поэтому снова возникла пачка вопросов :)

Цитата
SOLDIER пишет:
статейку прочитай на наге - не на 100% то, что ты ищещь - но путь к защите от ARP-флуда там указан - http://www.nag.ru/2007/0617/0617.shtml
А у неуправляемых свитчей тоже есть память на МАСи для портов? Т.е. описанная атака актуальна и для них?

Цитата
SOLDIER пишет:
Если нет бабла на сиськи - есть админ- который отслеживает по логам работу arpwatch.
Вот что вычитал:
Цитата
Arpwatch - программа позволяющая отследить пользователей, самовольно присвоивших себе IP адрес, путем мониторинга изменений в таблице ARP.
Т.е. в сети должен существовать комп с arpwatch, который анализирует пакеты сети. Соответствия IP/MAC придётся обновлять по мере введения новых компов, изменения МАС у некоторых компов в силу перехода на другую сетевуху и т.д. Верно?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Ну, в общем случае - да. Если меняется сетевуха - ты получишь в логах флип-флопы. Насколько я помню. Просто больше года уже не разлевался с этой приблудой. А там уже - по ситуации. Смотришь в логах - на каком ИП ещё этот адрес светился. Разумеется, если у "пионэра" не хватит ума сменить и ИП и МАК.
 
А как насчёт неуправляемых свитчей и arp-флуда? Такой свитч тоже можно перевести в режим хаба описанной атакой?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Ну, подумай, чем управляемый отличается от управляемого - и сам ответишь на своё вопрос. :) Просто в случае неуправляемого всё намного печальнее. В силу "неуправляемости".
 
Ну, у неуправляемого всё равно есть таблица соответствий МАСов портам. Значит, ситуация аналогична. А если учесть, что никаких port-security у него нет, то и защиты никакой нет, верно?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
port-security не защищает от ARP спуфинга, НО он помогает найти того человека, который спуфит!
почему? потому что port-security не дает ему заюзать больше одного MAC адреса.

Алгоритм:
Вы говорите: "на этой розетке в стене должен быть только один MAC адрес".
Человек садится с ноутом, подключается к розетке - получает доступ.
Он пытается заспуфить IP адрес маршрутизатора на поддельный MAC - не получается.
Он пытается заспуфить IP адрес маршрутизатора на свой MAC - получается,
Но тут приходим мы, говорим
show mac-address-table
Там мы видим на какой розетке висит MAC адрес этого человека и приходим к этой розетке и находим этого человека и говорим ему "нехорошо заниматься ARP спуфингом".

Вообще если вы статически прописали на компьютере MAC адрес маршрутизатора командой
arp -s
то заспуфить лично Вас нет никакой возможности, только если у вас не операционная система, которая не поддерживает статические записи (например Windows 2000 не поддерживает)
 
Хм...вроде Win 2000 поддерживает статические записи. Не поддерживают предыдущие операционки.

Несколько неясна фраза:
Цитата
ksiva пишет:
Он пытается заспуфить IP адрес маршрутизатора на свой MAC
Это как? Тысячу раз в секунду посылать пакеты от одного МАС-а? Разве это будет какой-то спуфинг? Ну, маршрутизатор смотрит по IP пакеты. Но для свитча-то всё равно какие там IP в пакетах будут указаны. Значит, это не заставит его таблицу обновить.
И потом: спуфинг реализованный посредством ложных arp запросов/ответов - это же вроде как не сетевой уровень. А значит, и эти пакеты не будут обновлять таблицу маршрутизатора.

а port-security на свитче как раз не даст заполнить память новыми записями, т.к. они уже жёстко прописаны
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
1. Команда arp -s на ОС Windows 2000 не дает возможность зафиксировать соответсвие MAC-IP. Как только пройдет ложный ARP ответ, то система перепишет это "статическое" (казалось бы) соответсвие. Статичность записи стала поддерживаться только в Windows XP и Windows 2003.

2. Чтобы реализовать атаку ARP спуфинг, атакующий пошлет один или несколько ложных ARP ответов на жертву, в которых скажет что IP адрес маршрутизатора по умолчанию соотвествует MAC адресу атакующего. Так, например, работает программа Cain&Abel. В результате жертва переписывает у себя таблицу соответсвия IP и MAC адреса и шлет пакеты не маршрутизатору а атакующему. Так выполняется атака человек посередине в среде где есть свитчи.
Поскольку port-security не дает возможности атакующему использовать ложный MAC адрес, то он будет использовать свой. Поскольку у жертвы прописан этот MAC адрес после атаки, то мы можем всегда посмотреть на какой розетке висит этот MAC адрес и найти атакующего. Мы говорим о свитчах. При чем тут маршрутизатор?
 
Теперь всё стало на свои места. Я просто подумал, что речь идёт о маршрутизаторе как об устройстве, защищающем от спуфигна (заместо свитча). А не как об объекте, которым хочет "прикинуться" атакующий.

Насчёт статических записей всё понятно. Но меня интересуют именно методы защиты средствами настраемого свитча.

IP-MAC binding не будет резать подставные пакеты arp, которыми атакующий травит жертву? Я имею ввиду пакеты с реальным MAC но с IP шлюза.

Кто-нибудь подтвердит или опровергнет мои догадки насчёт возможности перевода неуправляемого свитча в режим хаба путём зафлуживания его arp-пакетами?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Shanker, издеваешься :) столько вопросов в одном посте :)

Вообще маршрутизатор мешает ARP спуфингу между разными сегментами, поскольку он меняет MAC адреса пакетов на адреса своих интерфейсов. Есть правда такая штука как arp-proxy, но это отдельная тема. :) В случае с маршрутизатором уже можно начать разговор об IP спуфинге.

Кроме port-security ничего нет. Остальные технологии типа 802.1x или VLAN и PVLAN не от этого.

Не совсем понял вопрос про то как связан IP-MAC binding и блокирование пакетов. Операционка может их только игнорировать.

Действительно свитч работает в режиме хаба при
- своем включении, поскольку еще не знает на каком интерфейсе висит какой MAC
- переполнении таблицы MAC адресов. переполнение делается посылкой кучи запросов с поддельными MAC адресами.
 
Ну, тема для меня нова, поэтому решил не создавать кучи тем, а всё в одной теме спросить.

Цитата
ksiva пишет:
Остальные технологии типа 802.1x или VLAN и PVLAN не от этого.
Как так? Меня в этой теме убеждали, что эти настройки способствуют защите, т.к. ограничивает действие бродкаста созданными подсетями.

Цитата
ksiva пишет:
Не совсем понял вопрос про то как связан IP-MAC binding и блокирование пакетов. Операционка может их только игнорировать.
Я про вот что: атакующий создаёт ложный arp-пакет, в котором сообщается, что IP шлюза есть МАС атакующего. В случае настройки на порту атакующего IP-MAC binding (позволяющий атакующему посылать пакеты только с его реальным МАС и IP адресами) такой поддельный arp-пакет пройдёт, т.к. IP-MAC binding не разруливает содержимое arp-пакетов или я заблуждаюсь?

Цитата
ksiva пишет:
переполнении таблицы MAC адресов. переполнение делается посылкой кучи запросов с поддельными MAC адресами.
А где можно физику этого процесса почитать? Всё никак не могу понять почему так происходит...
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
В случае настройки на порту атакующего IP-MAC binding (позволяющий атакующему посылать пакеты только с его реальным МАС и IP адресами) такой поддельный arp-пакет пройдёт, т.к. IP-MAC binding не разруливает содержимое arp-пакетов или я заблуждаюсь?
Стоп - стоп... не знаю как на других свичах, но на д-линк - именно если арп-ответ пойдет с маком и не соответствующем записи в таблице свича айпи - то ВАш мак заносится в черный список - то есть блокируется. Это знаю на практике:) Спецом проверил - зашел на свич - смотрю а меня как раз забиндили, мне обидно стало - на моем свиче активно еще 6 юзеров ,  а забиндили только мой порт:) Я естесно - врубаю арп-спуф - и все.... ))) что интересно - даже свич не отвечает потом... я конечно звоню прову (в обход Админу , а сразу простым работникам) и говорю что у меня не работает сеть.) Подозреваю что перезагрузили свич - таблица биндинга обнулена... терь знаю как если че обнулить ;) По поводу айпи-спуфинга - знаю на теории - оч геморное занятие хотя кажись ща появились новые технологии - надо будет на досуге почитать:)
ЗЫ
Надеюсь не сообщат админы секлаба моему прову, я ни каких зловредных действий не предпринимаю. хотя я даже предупреждал их о том что следует сеть настроить по полной программе... но они только мой порт забиндили... придурки да и только.
 
Цитата
tmp пишет:
Спецом проверил - зашел на свич - смотрю а меня как раз забиндили, мне обидно стало - на моем свиче активно еще 6 юзеров , а забиндили только мой порт:) Я естесно - врубаю арп-спуф - и все.... )))
Так ты arp-спуфингом "отвязался" от IP-MAC binding или arp-флудом?

Цитата
tmp пишет:
Стоп - стоп... не знаю как на других свичах, но на д-линк - именно если арп-ответ пойдет с маком и не соответствующем записи в таблице свича айпи - то ВАш мак заносится в черный список - то есть блокируется. Это знаю на практике:)
Это в случае IP-MAC binding?

Цитата
tmp пишет:
По поводу айпи-спуфинга - знаю на теории - оч геморное занятие хотя кажись ща появились новые технологии - надо будет на досуге почитать:)
А в чём гемор? Что сложного в рассылании пакетов от своего МАС но другого IP?
"Красота - как специи, которые хорошую еду делают ещё вкуснее, а без еды есть невозможно."
 
Цитата
Shanker пишет:
Так ты arp-спуфингом "отвязался" от IP-MAC binding или arp-флудом?
Нет- нет, я имел ввиду что когда забиндили мой порт - я проверил последствие - врубил арп-спуф и мой мак был заблокирован сразуже :) ОТвязался я, предполагаю, тем что работник пришел и перегрузил на крыше свич, но я с ним не поднимался - поэтому на 100% не знаю что он сделал, но предположения основаны на наблюдении за работой нашей тех поддержки и сопоставлении того что он мог сделать на крыше))) Блин... сори если я опять чето не так сказал, просто сонный шо труба, толком еще не выспался после вчерашнего концерта Chemical Brothers:) в голове каша....
Цитата
Shanker пишет:
Это в случае IP-MAC binding?
Да.
Цитата
Shanker пишет:
А в чём гемор? Что сложного в рассылании пакетов от своего МАС но другого IP?
Если тарджет в другом сегменте сети - строение пакета tcp предусматривает проверку контрольной метки. Как то год назад был разговор где то в соседней теме на этот счет, ща хотел найти но видать удалили, но там кажись как раз r00t давал хорошие ссылы на эту тему) надо будет у себя поискать, я кажись сохрянял эти доки... завтра поищу, может еще r00t Подскажет? ;)
Страницы: Пред. 1 2 3 След.
Читают тему