Обсуждение: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".