Такую атаку можно было предсказать еще лет двадцать назад, когда появилось семейство протоколов TCP/IP: ее корни находятся в самой инфраструктуре сети Internet, в ее базовых протоколах - IP и TCP. Но каково же было наше удивление, когда выяснилось, что на информационном . WWW-сервере CERT (ComputerEmergencyResponeTeam) первое упоминание об удаленном воздействии такого рода датировано только 19 сентября 1996 года! Там эта атака носила название «TCPSYNFloodingandIPSpoofingAttacks» («наводнение» TCP-запросами с ложных IP-адресов). Другая разновидность атаки «отказ в обслуживании» состоит в передаче на атакуемый хост нескольких десятков (сотен) запросов TCP SYN в секунду (направленный мини-шторм TCP-запросов) на подключение к серверу, что может привести к временному (до 10 минут) переполнению очереди запросов на сервере (см. атаку К. Митника). Это происходит из-за того, что некоторые сетевые ОС обрабатывают только первые несколько запросов на подключение, а остальные игнорируют, Таким образом, получив N запросов на подключение, ОС сервера ставит их в очередь и генерирует соответственно N ответов. Затем в течение определенного промежутка времени (тайм-аут < 10 минут) сервер будет дожидаться сообщения от предполагаемого клиента, чтобы завершить handshake и подтвердить создание виртуального канала с сервером. Если атакующий пришлет такое количество запросов на подключение, которое равно максимальному числу одновременно обрабатываемых сервером сообщений, то в течение тайм-аута остальные запросы будут игнорироваться и установить связь с сервером не удастся.
Мы провели ряд экспериментов с направленным штормом и направленным миништормом запросов на различных по вычислительным мощностям компьютерах с разными операционными системами.
Тестирование направленным штормом запросов TCPSYN, проводимое на различных сетевых ОС в экспериментальных 10-мегабитных сегментах сети, дало следующие результаты: все описанные далее атаки осуществлялись по определенной методике. Подготавливался TCP-запрос, который при помощи специально разработанной собственной программы в цикле передавался в сеть с соответствующими задержками (вплоть до нулевой) между запросами. При этом циклически изменялись такие параметры запроса, как порт отправителя и значение 32-битного идентификатора SYN. IP-адрес отправителя запроса был выбран так, чтобы, во-первых, этот хост в настоящий момент не был активен в сети и, во-вторых, чтобы соответствующий маршрутизатор, в чьей зоне ответственности находится данный хост, не присылал сообщения HostUnreachable (Хост недоступен). В противном случае хост, от имени (с IP-адреса) которого посылался запрос TCP SYN, получив «неожиданный» ответ TCP АСК от атакуемого сервера, перешлет на него пакет TCPRST, закрывая таким образом соединение.
При передаче по каналу связи максимально возможного числа TCP-запросов и при нахождении кракера в одном сегменте с объектом атаки атакуемые системы вели себя следующим образом: ОС Windows 95, установленная на 486DX2-66 с 8 Мб ОЗУ, «замирала» и переставала реагировать на любые внешние воздействия (в частности, нажатия на клавиатуру); ОС Linux 2.0.0 на 486DX4-133 с 8 Мб ОЗУ также практически не функционировала, обрабатывая одно нажатие на клавиатуре примерно 30 секунд. В результате к этим хостам невозможно было получить не только удаленный, но и локальный доступ.
Не менее интересным было поведение атакуемых систем после снятия воздействия: ОС Windows 95 практически сразу же после прекращения атаки начала нормально функционировать; в ОС Linux 2.0.0 с 8 Мб ОЗУ, по-видимому, переполнился буфер, и более получаса система не функционировала ни для удаленных, ни для локальных пользователей, а занималась только передачей ответов на полученные ранее запросы. CyberGuard сразу же после снятия воздействия стал доступным для удаленного доступа.
Если кракер находился в смежных сегментах с объектом, то во время атаки ОС Windows 95 на Pentium 100 с 16 Мб ОЗУ обрабатывала каждое нажатие с клавиатуры примерно секунду, ОС Linux 2.0.0 на Pentium 100 с 16 Мб ОЗУ практически «повисала» - одно нажатие за 30 секунд, зато после снятия воздействия нормальная работа возобновлялась.
Не нужно обманываться, считая, что ОС Windows 95 показала себя с лучшей стороны. Такой результат объясняется следующим: Windows 95 - операционная система, не имеющая FTP-сервера, а следовательно, ей не нужно было сохранять в памяти параметры передаваемого TCP-запроса на подключение к этому серверу и дожидаться окончания handshake.
Таким образом, учитывая аппаратные средства сервера octopus.lstu (Olivetti 80286) можно без труда осуществить на него DoS атаку. Даже если локальная сеть будет загружена. Можно предположить, что и остальные сервера университета могут быть «обездвижены» таким способом. Например сервер кафедры прикладной математики: IBM 486DX66 16RAM. По аппаратной части серверы кафедры АСУ (здесь не имеется ввиду octopus.lstu) более устойчивы к DoS атаке.
Превышение максимально возможного размера IP-пакета, или PingDeath
В максимальный размер IP-пакета (65 535 байт) включаются длина IP-заголовка и длина ноля данных в IP-пакете. Так как минимальный размер IP-заголовка - 20 байт (максимальный - 60), то соответственно размер данных, передаваемых в одном IP-пакете, не может превышать 65 535- 20 = 65 515 байт. А что будет, если превысить это число? Тестировать свои программы на предельных критических значениях -стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека, переменной и т. д.). Но вернемся к IP. В принципе ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно в этой фразе и сформулирована основная идея данной атаки.
Итак, 18 декабря 2000 года на информационном сервере СЕКТ появились сообщения о том, что большинство сетевых операционных систем, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, в результате система «зависает» или перезагружается, то есть налицо отказ в обслуживании. Был приведен и список потенциально опасных платформ:
• Berkeley Software Design, Inc. (BSD);
• Computer Associates, Intl. (products for NCR);
• Cray Research;
• Digital Equipment Corporation;
• FreeBSD, Inc.; ' Hewlett-Packard Company;
• IBM Corporation;
• Linux Systems;
• NEC Corporation;
• Open Software Foundation (OSF);
• The Santa Cruz Operation, Inc. (SCO);
• Sun Microsystems, Inc.
Мы с удивлением прочитали этот перечень операционных систем на различных платформах, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что элементарную ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP разработчики сегодняшних систем до сих пор не замечали. Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке (http://www.sophist.demon.co.uk/ping) на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. На WWW-сервере предлагалось реализовать такое воздействие следующим образом: необходимо выполнить на рабочей станции с ОС Windows 95 или WindowsNT следующую команду: ping -l 65527 victim.destination.IP.address (по этой команде атака и получила свое название - PingDeath).
Так как обычный размер IP-заголовка составляет 20 байт, а размер 1СМР-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт: 65 527 +20+8-65 535 = 20.
Основываясь на приведенном расчете, эти «эксперты» декларировали, что обычной командой ping можно нарушить работоспособность практически любой сетевой ОС. В завершение предлагалась следующая таблица тестирования различных операционных систем
| Операционная система | Версия ПО | Симптомы |
| Solaris (x86) | 2.4, 2.5, 2.5.1 | Перезагрузка |
| Minix | 1.7.4, v2.0 и другие | Сбой |
| HP3000 MPE/iX | 4.0, 5.0, 5.5 | Сброс системы |
| Convex SPP-UX | Все версии | Сбой |
| Apple Mac | MacOs 7.x.x | Сбой |
| Windows 3.11 with Trumpet winsock | ? | Смешанные отчеты |
| Novell Netware | 3.x | Смешанные отчеты |
| Windows 95 | Все версии | Сбой |
| AIX | 3 и 4 | Сброс системы |
| Linux | 2.0.23 | Спонтанная перезагрузка или зависание (kernelpanic) |
| DEC UNIX / OSF1 | 2.0 и выше | зависание (kernel panic) |
| Open VMS for AXP | Различные | Смешанные отчеты |
| HP-UX | 9.0 по 10.20 | Сбой, перезагрузка, зависание. |
| WindowsNT | 3.5.1 | Смешанные результаты |
| Irix | 5.3 | зависание (kernel panic) |
| Windows NT | 4 | Сбой |
| SCO Openserver | 4.2, 5.0.x | Уязвима |
| DEC TOPS-20, TOPS-10 | Все | Ошибки |
| Digital Firewall | ? | Уязвима |
| AltaVista Firewall for UNIX | ? | Уязвима |
(здесь она приводится в сокращении), на которые данная удаленная атака якобы произвела необходимый эффект. Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда исследуемые ОС - IRIX, AIX, VMS, SunOs, FreeBSD, Linux, WindowsNT 4.0, даже Windows 95 и WindowsforWorkGroups 3.11- абсолютно не реагировали на подобный некорректный запрос, продолжая нормально функционировать. Тогда были предприняты специальные поиски операционной системы, которую бы действительно вывела из строя данная атака. Ей оказалась Windows 3.11 с WinQVT - эта ОС действительно «зависла».