Обсуждение:ARP-spoofing

Материал из Xgu.ru

Вопрос:

Каким образом хулигану (атакующему узлу) удается послать arp-сообщения только конкретной машине (узлу) в сети? Ведь arp-сообщения -- это широковещательные сообщения. И их должы принимать все. В том числе и хост, который владеет IP-адресом, для которого сообщается другой MAC в данном arp-сообщении. И как-то на это реагировать. Например, послать свое arp-сообщение.

Novell NetWare еще в незапамятные времена очень болезненно реагировал на присутствие в сети двух компов с одинаковым IP (но разными MAC). Windows вроде тоже это дело отслеживает.

Если вникнуть, то arpwatch или патчи для ядра Linux-BSD эту политику и реализуют. Получается, что латаем дыры в дизайне UNIX... Я не прав?

Рассуждение:

Почитав про механизм рассылки arp-сообщений, выясняется следующее. Запрос посылается по широковещательному mac-адресу (обычно). А вот ответ можно послать как широковещательный (кто-то это запрещает?), так и конкретно данному узлу (машине). Наверно, посылка ответа конкретно данной машине -- стандартная практика, иначе бы проблемы не было.

А Windows-NetWare, получается, регулярно рассылают широковещательные arp-сообщения о своих IP-MAC адресах. Иначе бы они периодично не ругались о наличии в сети компа с таким же MAC-адресом.

Сомневаюсь, чтобы UNIX не делал такого же. Получается, что arp-снуффинг может загнуться (быть пойманым за руку), если в момент атаки подверженные ей хосты выполнят сию регулярную процедуру (оповестят соседей о своих IP-MAC). И атакующий узел должен отследивать эти оповещения и глушить их по-новой. А пачти для ядер Linux-BSD нужны для того, чтоб не принимать на веру arp-сообщения (посланные в основном конкретно данному узлу, то есть не широковещательные), а проверять их путем повторного (широковещательного) запроса. На который в случае атаки придет как минимум два ответа -- от законного владельца и от атакующего узла.

Вопрос: А как обстоят дела данной уязвимостью в актуальный версиях ядра Linux, всё ещё нужно патчить (вроде патч портировали для 2.6)? Может быть есть другие, способы самозащиты?

[править] Про unicast ARP-ответы

Вопрос:

Почему вместо проверки arp-сообщения просто не запретить принимать узконаправленные arp-сообщения? Неужели есть ОС, которые не реагируют адекватно на получение arp-сообщения с чужым MAC для своего IP?

Ответ:

ARP-запросы широковещательные. ARP-ответы направленные (unicast).

Отправляется широковещательный ARP-запрос, после чего вторая сторона отправляет ARP-ответ (направленный).

Существует такое понятие как gratuitous ARP. Это такой режим работы ARP, когда ответы принимаются и обрабатываются без ARP-запросов.

--Igor Chubin 09:20, 25 июня 2007 (EEST)

[править] Проблемы с wiki-движком

PS: и почему нет определения конфликтов редактирования в движке Wiki? Двое правят, один -- напрасно. Причем правят-то в разных местах. В биореактор такой Wiki-движок...

Разрешение конфликтов есть, но при правке могли просто не обратить внимание на конфликт и переписать страничку несмотря на него.

Используется движок mediawiki, под управлением которого работает wikipedia.

Сделанные вами изменения постараюсь найти и восстановить.

--Igor Chubin 09:20, 25 июня 2007 (EEST)

[править] Статический ARP

http://xgu.ru/wiki/ARP-spoofing#.D0.A1.D1.82.D0.B0.D1.82.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D0.B9_ARP За блок кода в куске, описывающем проход пингами подсети, вылезли строки "for i in `seq 1 255` do" и "done".