Защита от 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.

sarptest

А вот и ответный пакет трехстороннего рукопожатия. Мы видим флаги SYN и ACK.

sarptest2

Так, момент! Стоп! Какой еще ответный? Как же так?
Как выясняется, очень просто. Удаленная система сгенерировала ответный TCP пакет на IP адрес нашей рабочей станции, считала из своей arp таблицы значение mac адреса и отослала пакет с ним. Поскольку наша рабочая станция не является специально настроенным инстументом злоумышленника, она проигнорировала пакет с чужим mac адресом. Соответственно, процедура рукопожатия закончилась ничем.

Ну ладно, это всего лишь, Server 2003, хоть и со всеми последними обновлениями безопасности. Попробуем провести тест с использованием более современной и совершенной серверной операционной системы.
Как несложно убедиться, при повторении теста с использованием Server 2008, результат будет ровно таким же.


Ваш отзыв