Автор: 'Unknown' Источник: Неизвестен Эксплуатируя особенности, свойственные TCP протоколу, удаленные нападающие могут инициировать DoS на широкий массив операционных систем. Нападение наиболее эффективно против HTTP серверов. Прилагаемый cценарий Perl демонстрирует эту проблему. При TCP связи, каждая TCP распределяет некоторые ресурсы каждомуподключению. Неоднократно устанавливая TCP подключения и затем, отказываясь от них, злонамеренный хост может связывать существенные ресурсы на сервере. Сервер Unix может выделять некоторый номер mbufs или даже процесс на каждое из таких подключений. Пройдет некоторое время прежде, чем часть ресурсов будет возвращена к системе. Если создать много невыполненных оставленных подключений такого вида, система может разрушаться или просто прекращать обслуживать специфический порт. Любая система, которая выполняет TCP службу, может быть атакована этим путем. Эффективность такого нападения зависит от очень большого количества факторов. Web серверы особенно уязвимы к такому нападению из-за природы протокола (короткий запрос генерирует произвольно длинный ответ). Уязвимость может быть использована против различных сервисов. Здесь будет обсуждено, как ее использовать против HTTP серверов. Механизм весьма прост: После инструктирования нашего ядра, чтобы не отвечать на любые пакеты от целевой машины (наиболее легко сделать с использованием систем защиты сетей, поле: с ipfw, " deny any from TARGET to any "), неоднократно инициализируем новое подключение от случайного порта, посылая SYN пакет, ожидая SYN+ACK ответ, и затем посылая наш запрос (можно было бы более традиционно сначала подтверждать SYN+ACK и только затем посылать запрос, но это путь, который экономит пакеты. Нападение является более эффективным, когда этим путем выбран статический файл, а не динамическое содержание. Природа файла не имеет значения (графика, текстовый или просто HTML) но размер обладает большой важностью. Что начнет делать сервер, когда он получает эти поддельные запросы? Прежде всего, ядро обрабатывает установление TCPсвязи; поскольку мы посылаем наш второй пакет, и установление связи таким образом закончено, пользовательское приложение уведомлено о запросе (возвращения системного вызова ввода, подключение теперь установлено). В то время, ядро имеет данные запроса в получении очереди. Процесс читает запрос (который является HTTP/1.0 без какой либо действующей опции), интерпретирует его, и затем записывает некоторые данные в дескриптор файла и закрывает его (подключение входит в состояние FIN_WAIT_1). Процесс тогда использует некоторый съеденный mbufs, если мы достигаем этого пункта. Это нападение содержит две разновидности: mbufs истощение и насыщенностьпроцесса. При выполнении mbufs истощения ,каждрое подключение использует процесс пользовательского уровня на другом конце, для записи данных без блокировки и закрытия дескриптора. Ядро должно иметь дело со всеми данными, и процесс пользовательского уровня будет освобожден, так, чтобы мы могли посылать большее количество запросов этим путем и в конечном счете потреблять весь mbufs или всю физическую память, если mbufs распределен динамически. При выполнении насыщенности процесса, каждый хочет, чтобы процесс пользовательского уровня блокировался при попытке записать данные. Архитектура многих HTTP серверов позволяет обслуживать много подключений одновременно. Когда мы достигаем этого числа подключений, сервер прекратит отвечать законным пользователям. Если сервер не помещает связи на числе подключений, мы все еще связываем ресурсы и, в конечном счете, система приходит к краху. Mbufs истощение обычно не имеет никакого видимого эффекта пока мы не достигаем жесткого предела номера кластеров mbuf или mbufs. В этой точке, формируется дамп kernel core, перезагрузка, проверка файловой системы, восстановление дампа ядра - все это отнимающие много времени операции. Все это прекрасно работает с FreeBSD и других BSD основанных платформах. Некоторые другие системы, типа Linux, кажется, распределяют произвольный объем памяти для кластеров mbuf. Как только мы приближаемся к физическому размеру памяти, машина становится полностью непригодной. Если у вас произошел сбой сервиса, следующие признаки помогут идентифицировать этот инструмент: Ваши HTTP серверы имеют сотни или тысячи подключений с 80 портом в состоянии FIN_WAIT_1. коэффициент (число уходящих пакетов/номера входящих пакетов) необычно высокий. есть большое количество подключений с 80 портом в УСТАНОВЛЕННОМ состоянии, и большинство их имеет одинаковую длину. (Или, есть большие группы подключений, совместно использующих то же самое ненулевое значение длины)
