ARP-spoofing: старая песня на новый лад
Об arp-спуфинге известно уже давно. С момента публикации первых материалов по этой проблеме прошло много лет. Было написано много программ как реализующих данный тип атак, так и призванных защитить от этих самых атак. А с недавних пор такую защиту стали внедрять и в персональные межсетевые экраны. Казалось бы: тема исчерпала себя. Однако полигон для работы мозгов всё же остаётся…
Суть вопроса
В этой статье мы рассмотрим атаку типа arp-spoofing как со стороны атакующего, так и со стороны жертвы (того пользователя, против которого направлена атака).
Итак, исходные данные:
Локальная сеть типа Ethernet, построенная на неуправляемых коммутаторах
Отсутствие статических arp-таблиц у жертвы
Наличие персонального брэндмауэра у жертвы
Атакующий должен создать фиктивную запись в arp-таблице жертвы в обход персонального брэндмауэра
Анализ работы персонального брэндмауэра
В последнее время внедрение защиты от arp-спуфинга стало популярной идеей среди разработчиков персональных межсетевых экранов. Я точно не знаю какой производитель первым реализовал данный механизм. Однако, первый продукт попавший мне на глаза с такой функцией был Agnitum Outpost Firewall. Потом компания Агава объявила о выходе своего Agava Firewall с поддержкой аналогичной защиты. И, на сколько мне известно, лаборатория Касперского тоже вдохновилась идеей реализации подобной функции в будущую версию Kaspersky Internet Security 8.0
Как же работают перечисленные брэндмауэры? На самом деле, не смотря на то, что продукты разные, защита у них построена по схожему принципу: если приходит arp-ответ, а система не посылала arp-запрос - делается вывод, что была попытка фиктивной записи в arp-таблицу. Это логично, ведь вероятность того, что придёт достоверный arp-ответ притом, что запрос не посылался, равна нулю.
Рис №1: параметры Agnitum Outpost Firewall 2008 по пресечению arp-poisoning
Некоторые персональные брэндмауэры (к примеру Outpost, см. рис №1) принимают только самый первый ответ на arp-запрос, считая остальные запросы фиктивными. Выходит, если атакующему удастся ответить на запрос раньше, чем придёт легитимный ответ – брэндмауэр примет его ответ, а легитимный ответ будет отброшен. То есть произойдёт подмена записи в arp-таблице жертвы. Но этот путь очень тернист: послать свой ответ раньше, чем придёт легитимный ответ не так-то просто. Есть более лёгкий способ провести атаку. Действительно: существует же возможность модифицирования ARP-таблицы путём посылки фиктивных ARP-запросов. Такие ответы брэндмауэры с лёгкостью пропускают.
Кроме того, внесение компьютера в список атакующих в том случае, если от него пришёл arp-ответ, когда система не посылала запроса не всегда является правильным решением. Пример (см. рис №2): компьютер А посылает arp-запрос компьютеру В от имени компьютера С. В итоге компьютер В пошлёт arp-ответ компьютеру С. Но компьютер С запроса не посылал. Соответственно брэндмауэр, находящийся на компьютере С, сочтёт компьютер В атакующей системой. Какой практический толк от такой атаки? Если брэндмауэр сконфигурирован на внесение в «чёрный список» системы, которая, по его мнению, производила попытку атаки получим DoS-атаку. Ведь в итоге связь легитимного компьютера с жертвой нарушится.
Рис №2: ложная тревога файерволла
Вывод: современные персональные межсетевые экраны не могут эффективно предотвращать атаки, направленные на изменение записей ARP-таблицы.
Анализ работы программ, реализующих атаку типа arp-poisoning
Современные программы такого типа предоставляют два вида атаки:
Атака arp-request пакетами
Атака arp-reply пакетами
Особенностью arp-reply пакетов является их направленность: заранее известно на какие физические и IP адреса нужно отправлять ответ. У arp-request пакетов заранее неизвестно какой именно станции их отправлять. Поэтому поля получателя (в Ethernet-кадре) заполняются как Broadcast. Такой пакет получат все станции подсети, которой принадлежит компьютер, отправляющий arp-запрос. В случае, если физический адрес компьютера принимающего запрос совпадает с адресом, указанном в поле ARP-протокола arp-request пакета – компьютер отвечает на такой запрос arp-reply пакетом. В противном случае такой пакет отбрасывается.
Рассмотрим реализации этих двух типов атак на примере утилиты Cain&Able.
Атака arp-reply пакетами обычно выглядит так: сначала жертве единожды посылается arp-request пакет, а потом уже посылаются arp-reply пакеты через заданный промежуток времени. Это делается для того, чтобы у жертвы в arp-таблице наверняка появилась запись об адресах подменяемого узла. Если в данный момент времени такой записи не будет, то жертва, принимая пакет arp-reply, никаких данных в свою таблицу не внесёт. Значит, никакой подмены не произойдёт.
Атака arp-request пакетами имеет следующий вид: посылаются пакеты arp-request через заданный промежуток времени. При чём обычно адреса получателя указываются не как Broadcast, а как истинный адрес получателя. То есть такой пакет будет послан только жертве. Другие станции подсети такой пакет не получат. Это разумно: исключается особенность arp-request пакета и атака становится направленной. Зачем другим станциям получать такой пакет? Их таблицу он не отравит. А вот если на какой-то станции стоит ПО для поиска аномалий в сети – это раскроет сам факт атаки. А аномалия здесь налицо: пойман пакет, в котором физический адрес не соответствует легитимному IP-адресу.
Некоторые снифферы (например, ettercap) отравляют arp-таблицу только arp-reply пакетами. Атака выглядит так (см. рис №3): компьютеру B сначала посылается какой-нибудь фиктивный пакет от компьютера A. Ettercap создаёт ICMP-echo пакет от IP-адреса компьютера C. После этого посылаются arp-reply пакеты с IP-адресом компьютера C, но МАС-адресом компьютера атакующего. В том случае, если у компьютера B в arp-таблице нет данных о компьютере C – он отправит arp-request пакет, на что получит фиктивный arp-reply. А если в arp-таблице компьютера B присутствует запись о компьютере C, то приходящие фиктивные пакеты arp-reply также отравят таблицу.
Рис№3: схема работы ettercap
В случае с ettercap, такая атака будет полностью пресечена, например, Аутпостом: по-умолчанию, этот брэндмауэр сконфигурирован на запрет приёма ICMP-echo пакетов. Значит, никакого arp-request компьютер жертвы не отправит. Следовательно, ни один arp-reply не пройдёт через Аутпост и не отравит arp-таблицу.
После того, как в arp-таблицах появятся фиктивные записи, трафик от атакованных компьютеров будет проходить через компьютер атакующего. Такой тип атак называется «Man in the Middle» (Человек посередине, MitM). Чтоб связь не разрывалась между компьютерами, компьютер атакующего должен модифицировать проходящий трафик. Модификация заключается в изменении физических (MAC) адресов в полях Ethernet-пакетов: меняется адрес отправителя с легитимного адреса на адрес атакующего.
ARP-poisoning и port-security
Теперь представим ту же ситуацию, но теперь сеть построена на управляемых коммутаторах, на которых настроена привязка физических адресов к портам коммутатора. Обсуждение создания VLAN-ов и других мер противодействия выходит за рамки данной статьи.
Очень часто на форумах по сетевой безопасности можно встретить суждения вроде: «Привязка MAC-адреса компьютера к порту управляемого коммутатора не пресекает саму атаку MitM, но она поможет найти физическое расположение нарушителя». Это действительно так. Но зачастую люди, высказывающиеся таким образом, забывают, один серьёзный факт. Даже при привязке физического адреса компьютера к порту коммутатора можно отравить arp-таблицу фиктивной записью от имени третьего лица. То есть (см. рис №5): компьютер С может создать запись в arp-таблице компьютера А от имени компьютера В. Конечно, атаки MitM здесь не получится, но зато возможна DoS-атака. И неопытный администратор может долго пытаться найти ответ на вопрос: каким образом в arp-таблице появилась запись с MAC-адресом 00:11:22:33:44:55, если он не принадлежит ни одному компьютеру в сети? Ведь port-security должен пресекать посылки пакетов с фиктивными MAC-адресами! На самом деле, всё очень просто: при привязке физического адреса к порту коммутатора, коммутатор проверяет приходящие на этот порт пакеты по заголовкам Ethernet. Arp-пакеты имеют 4 поля с физическими адресами: два принадлежат уровню Ethernet (адрес отправителя и адрес получателя) и два – собственно ARP-протоколу (так же: адрес отправителя и адрес получателя). Значит, достаточно задать верными поля Ethernet, а поле ARP-протокола с физическим адресом отправителя любым и такой пакет спокойно пройдёт через коммутатор и создаст фиктивную запись в таблице жертвы.
Рис №5: arp-poisining через коммутатор с включенной опцией port-security
Методы борьбы
Из описанных выше пунктов можно сделать несколько выводов о том, как более эффективно бороться с arp-poisoning атаками как на уровне персональных брэндмауэров, так и силами сетевого оборудования:
Фильтровать arp-пакеты, в которых физический адрес отправителя в полях Ethernet и arp протоколов различны
Фильтровать пакеты arp-request, где физический адрес отправителя в заголовке Ethernet-кадра не является broadcast.
Конечно, эти меры полностью не искоренят проблему атаки arp-poisoning: ведь остаётся возможность отправить arp-request с фиктивным физическим адресом отправителя на broadcast. Или ждать arp-request от жертвы и попытаться отправить arp-reply до того, как то же самое сделает легитимный компьютер, которому предназначался arp-request. Однако поле действия злоумышленника значительно сузится.
Кроме того, существует один универсальный метод борьбы с атакой MitM, основанной на атаке arp-poisoning. Суть этого метода (см. рис №6): периодически посылать пакеты, в которых будет передаваться информация о MAC-адресе отправителя не только в поле Ethernet, но и в теле самого пакета. Когда такой пакет пройдёт через атакующего, его компьютер подменит MAC-адрес отправителя, а данные пакета останутся как есть. На принимающей стороне компьютер увидит, что адреса отправителя различаются в поле Ethernet и в данных, в которые отправитель вставил свой адрес.
Конечно, в этом способе есть свои минусы: требуется дополнительное ПО на всех компьютерах подсети. Кроме того, если есть необходимость совместной работы с компьютерами, в которых нет такого ПО, надо выбрать какой-то протокол, куда можно вставлять свои данные. Например, можно выбрать пакет ICMP-echo. А вот выбор arp-request/arp-reply будет плохой идеей: сниффер атакующ
Рис №6: обнаружение атаки MitM
Несмотря на то, что описанный мною метод не встречался мне лично нигде – приписывать себе его авторство не стану: наверняка кто-то до меня додумался о том же самом. Просто мне не попадалась эта публикация :) Если кто-то из читателей сталкивался с описанием подобного метода ранее – буду благодарен, если поделитесь ссылкой на него.
ARP Builder
Для проведения тестов с arp-пакетами мне потребовалась утилита, которая может конструировать такие пакеты с разными параметрами. К сожалению, все найденные мною утилиты либо не работали под Windows XP, либо не предлагали визуально простого создания пакетов. Поэтому пришлось создать свою. Выкладываю её на обозрение читателей. Утилита будет полезна для проверки настроек персональных файерволлов и сетевого оборудования. А сомневающиеся могут воспользоваться ею для проверки фактов, изложенных мною в этой статье :)
Рис №7: внешний вид программы ARP Builder
Заключение:
В данной статье были рассмотрены методы реализации атаки типа arp-poisining и методы противодействия. Надеюсь, в ближайшем будущем производители персональных сетевых экранов внесут соответствующие корректировки в следующие выпуски своих продуктов, а администраторы локальных сетей ещё раз подумают о том, насколько правильно настроено сетевое оборудование.
|
| Категория: Общие Статьи | Добавил: aka_kludge (26.02.2008)
|
| Просмотров: 2205
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] |
