Ping-flooding атака: что осталось «за кадром» или о пользе дотошности

Собственно, открываю топик по мотивам habrahabr.ru/post/157207/
Тема интересная, но некоторые простые, но важные моменты остались за кадром. А жаль. Кому интересно, какие — прошу.

Если оставить за кадром тривиальный разбор icmp, то самой интересной частью материала будет утверждение (подтвержденное скриншотами), что некие целевые (Windows, надо полагать) системы отвечают на icmp-эхо запросы в которых ip назначения соответствует ip пингуемой системы, но mac назначения при этом широковещательный. Правда есть некое несоответствие скриншота тексту, но будем считать это опечаткой и ориентироваться на картинку.

Картинка действительно интересная, особенно, если учесть, что этого быть не должно. Когда-то, во времена баловства с подобными вещами посредством nemesis я четко усвоил, что для Win этот фокус не проходит. Тем больше было удивление — ну не подделал же автор скриншоты.

Решил повторить эксперимент. Простейший способ без использования каких-либо утилит для генерации произвольных пакетов из Nix-консоли:
arp -s ip ff:ff:ff:ff:ff:ff
ping ip

Искомый ip не отвечает. Проверяем посредством tcpdump, что пакеты нужного вида уходят с интерфейса.
Сразу возник вопрос. А может дело в системе-жертве? В моем случае это была Win XP SP3. Автор топика подтвердил, что у него тоже… Стало интересно. Нашел систему, доступную мне по RDP. Убедился, что icmp запросы с широковещательным dst mac до нее доходят. Ответа нет.
Повторил эксперимент на Win 2008 — результат положительный. В голове зашевелились какие-то теории (они озвучивались в комментариях к топику), но все оказалось гораздо проще.
Ну конечно же это ОН!

Next Generation TCP/IP Stack.
technet.microsoft.com/en-us/network/bb545475.aspx

Действительно, что не было справедливо для XP, стало реалиями для Vista,7,2008

Гугль помог найти таких же удивленных «сюрпризом» экспериментаторов.

www.packetstan.com/2010/08/windows-lan-addressing-validation-and.html
…
Much to my surprise, the Windows 7 host responds to my unicast Echo Request sent to the broadcast LAN address with an ICMP Echo Reply.

blog.taddong.com/2010/09/more-wpa2-hole-196-reflections-and.html

Josh mentioned Windows Vista and 7 accept LAN broadcast traffic sent to unicast IP addresses. I confirmed that Windows Vista SP2 under VMware Fusion 3.1.1 (LAN) in fact does accept this kind of traffic for ICMP, TCP or UDP for broadcast and multicast layer-2 addresses. The most surprising fact is that Windows Vista and 7 accept TCP broadcast traffic. New TCP/IP stack implementations can always include hidden gifts!

Windows XP SP3 (WLAN) does not accept it for any of the protocols (ICMP, TCP or UDP), no matter the layer-2 address used, broadcast or multicast. So, does this mean XP is "more secure regarding Hole 196" than Vista & 7? 😉

Что-что тут пишут? TCP с броадкастовым mac-ом назначения тоже будет работать? Проверим… Опять вручную выставляем arp связку, telnet на открытый 80 порт сервера под Win 2008 и таки да. Работает.

23:53:53.179517 00:0c:29:22:71:6c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 74: 10.xx.4.80.35261 > 10.xx.4.20.80: Flags [S], seq 759040421, win 5840, options [mss 1460,sackOK,TS val 2823711033 ecr 0,nop,wscale 7], length 0
23:53:53.180123 00:0c:29:81:23:05 > 00:0c:29:22:71:6c, ethertype IPv4 (0x0800), length 74: 10.xx.4.20.80 > 10.xx.4.80.35261: Flags [S.], seq 1483497967, ack 759040422, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 64239843 ecr 2823711033], length 0
23:53:53.180405 00:0c:29:22:71:6c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 66: 10.xx.4.80.35261 > 10.xx.4.20.80: Flags [.], ack 1, win 46, options [nop,nop,TS val 2823711033 ecr 64239843], length 0

А с другой стороны… Ну работает, ну и что? Такой же эксперимент с linux-системой имел, к слову, тот же результат 🙂

Зато белых пятен стало еще немного меньше. Кому как, а по мне это неплохо. И да, автору промотивировавшей на эксперимент темы — спасибо.