Эта запись опубликована
01.07.2009 в 0:39. Рубрики: безопасность. Вы можете следить
за ответами к этой записи через RSS 2.0.
Вы можете оставить отзыв или трекбек со своего сайта.
Защита от ARP spoofing при помощи статических записей.
Где-то в середине 2004 года компанией Microsoft были выпущены обновления для всех актуальных на тот момент операционных систем собственного производства. Обновления предотвращали одну конкретную забавную ошибку логики поведения кэша ARP. Дело в том, что на уровне операционной системы не было различия в алгоритме обновления кэша между статической и динамической ARP записями. Значение обновлялось всегда, если из сети приходило уведомление о том, что у некого хоста теперь другой MAC адрес. Причем, это относилось как к случаю получения широковещательного пакета arp request, так и к простому icmp пакету, пришедшему с новым arp адресом в заголовке. Неплохой был простор для разнообразного творчества… Был… Был?..
На данный момент можно провести простейший тест, чтобы убедиться: если на удаленной рабочей станции в сети есть статическая ARP запись, на инородные пакеты ответа от нее не приходит и статическая запись остается неизменной. Казалось бы, все хорошо.
Но я все же предлагаю проверить чуть более тщательно. Для этого мы возьмем любой сетевой анализатор (сниффер) и посмотрим, как выглядит процесс на более низких уровнях сетевой модели, то есть, задолго до того, как мы удовлетворенно видим неуспешное соединение.
А выглядит все достаточно интересным образом. Предположим, у нас есть три физических компьютера:
1. Под управлением Server 2003 Sp2 R2, ip=192.168.10.10 mac=AA-AA-AA-AA-AA-AA
2. Под управлением Server 2008 Sp2, ip=192.168.10.20 mac=AA-AA-AA-AA-AA-BB
3. Под управлением Windows XP Sp3, ip=192.168.10.30 mac=AA-AA-AA-AA-AA-СС
Введем на первом и на втором серверах команду:
arp -s 192.168.10.30 AA-AA-AA-AA-AA-DD
Теперь включим на рабочей станции сниффер и попробуем, например, установить RDP подключение к серверу под управлением Windows 2003. Разумеется, у нас ничего не получилось. А теперь взглянем на результат работы сетевого анализатора:
Вот здесь мы видим первый пакет данных, ушедший на удаленную систему. Это пакет, отсылаемый для предложения установки TCP сессии. Об этом нам говорит флаг SYN.
А вот и ответный пакет трехстороннего рукопожатия. Мы видим флаги SYN и ACK.
Так, момент! Стоп! Какой еще ответный? Как же так?
Как выясняется, очень просто. Удаленная система сгенерировала ответный TCP пакет на IP адрес нашей рабочей станции, считала из своей arp таблицы значение mac адреса и отослала пакет с ним. Поскольку наша рабочая станция не является специально настроенным инстументом злоумышленника, она проигнорировала пакет с чужим mac адресом. Соответственно, процедура рукопожатия закончилась ничем.
Ну ладно, это всего лишь, Server 2003, хоть и со всеми последними обновлениями безопасности. Попробуем провести тест с использованием более современной и совершенной серверной операционной системы.
Как несложно убедиться, при повторении теста с использованием Server 2008, результат будет ровно таким же.