Господа, несколько дней назад на этом сайте была опубликована написанная по материалам Фернандо Гонта статья Атаки на соединения TCP с помощью пакетов ICMP. В связи с приведенной в статье информацией возникает интересный вопрос о возможной уязвимости для такого рода атак приложений, использующих транспорт UDP. Хотелось бы узнать ваше мнение на сей счет.
По опыту использования flex response в снорт, где для обрыва udp "соединения" исполльзуется как раз ICMP Dest unre, могу сказать, что специфично для приложения. Некоторые отрабатывают, некоторые нет. Например TFTP клиент windows вполне выдувал файлы с Dlink, не смотря на штурм со стороны снорта. А вот с линуксового TFTP сервера - уже не получалось. ИМХО, на ошибки здесь реагирует само приложение а не стек, соответсвенно - все на совести кодера. Я думаю для эксперементов snort вполне подойдет.
В голову приходят kerberos и snmp, но они state-less. Можно попробовать просто подолбить службы Windows (135,137-139,445, RPC 1024 и выше) и т.д., которые могут работать и по UDP и по TCP. Вполне возможно, что у них обработчки ошибок поинтересней. Мало ли что разработчкам MS пришло в голову. tip. Что бы заставить windows соединется по CIFS с использованием UDP можно на клиентской машине (или сервере) отфильтровать TCP варианты этого порта (например закрыть 445й и 137-139 TCP).
Сергей Гордейчик пишет: Можно попробовать просто подолбить службы Windows (135,137-139,445, RPC 1024 и выше)
С первой попытки мне этого не удалось, а для более серьезных не хватает знаний в части нутра Windows.
есть еще один привлекательный объект - приложения, использующие SIP. К сожаления у меня в настоящий момент нет под рукой достаточного количества железа, чтобы сделать стенд.. Некотрые другие системы, которые используют транспорт UDP для для connection-based служб я уже попробовал, и результаты меня откровенно опечалили.
Я вчера довольно много времени потратил и обнаружил странную вещь. Поскольку обработка сообщений об ошибках происходит выше транспортного уровня, в случае использования разнотипных клиентов влияние потока ICMP вполне может быть анизотропным, т. е. результаты будут зависеть от того, кому будет передаваться поток сообщений об ошибках - клиенту или серверу. У меня же обнаружилась странная вешь при попытке блокировать организацию соединений TFTP. В качестве клиента всякий раз использовалась станция Windows XP, а серверами были Linux и D-Link на платформе Win2K. Получилось, что для пары XP-Linux блокировка соединений удавалась при передаче потока ICMP любому из хостов (хоть клиенту, хоть серверу), а для пары D-Link-XP блокировать попытки организации соединения не удавалось, но эффект также не зависел от направления. Это мне представляется странным, но объяснения я пока не вижу.