Содержание статьи
Вступление
Недавно Роберт Ли и Джек Луис объявили об обнаружении ими новой
разрушительной DoS-уязвимости в стеке протокола TCP/IP, являющегося основой
практически любого интернет-соединения. До момента
своего
выступления, которое пройдет на конференции по безопасности T2 17-го октября
этого года, они отказались от публикации каких-либо дополнительных комментариев,
но успели, тем не менее, раздать множество леденящих душу интервью. Таким
образом, у прессы появился повод для того, чтобы начать сеять панику в массовом
сознании. Соответствующие статьи вышли на The Register ("DoS
attack reveals (yet another) crack in net's core"), Slashdot ("New
Denial-of-Service Attack is a Killer"), Search Security ("TCP
is fundamentally borked") и ряде других ресурсов.
В интервью Register, например, Роберт Ли заявил, что им "не удалось
обнаружить никого, кто использовал бы в своей работе сервисы на основе TCP и не
был бы при этом подвержен риску этой атаки" и что "машины как бы уничтожают сами
себя, и единственный выход после четырехминутной атаки – это перезагрузка".
А статья на SearchSecurity вообще заканчивается чем-то ужасным:
"Лучший совет, который есть у меня на данный момент, это запрет анонимных
соединений. Создайте "белый список" адресов для того, чтобы только входящие в
него IP-адреса могли получать доступ к сервису", - сказал Ли, осознавая при этом
практически полную неприменимость своего совета для большинства служб на основе
протокола TCP. "На данный момент попросту не существует метода решения этой
проблемы", - резюмировал он.
Также эти эксперты дали
интернет-интервью в котором высказали еще более мрачные прогнозы по поводу
будущего Интернет:
Вопрос: "... я правильно полагаю, что теперь мы можем сделать вывод о том,
что TCP/IP, в том виде, каким мы его знаем, неизлечимо болен?"
Ответ: "Безусловно, для тех его реализаций, с которыми мы имели дело"
Вопрос: "И речь идет о Linux, BSD, Windows, и всех работающих ныне роутерах?"
Ответ: "Да"
Несмотря на то, что я знаю и уважаю этих специалистов, я могу сказать, что
мне уже приходилось сталкиваться со случаями, когда люди заявляли о
(предположительно) обнаруженных ими серьезных уязвимостях и отказывались при
этом описывать их в деталях до момента своего выступления на каком-либо
мероприятии, которое должно было проходить неделями или даже месяцами спустя
сделанных ими заявлений. Очевидно, что начало такой практике положил Дэн
Камински со своей историей об обнаруженной им дыре в DNS.
И, хотя многие из них на полном серьезе заявляют о "научном открытии",
зачастую от таких заявлений попахивает обычным пиаром. Когда вы заявляете прессе
о том, что вам удалось обнаружить столь ужасную уязвимость в основном протоколе
Интернет, что вы даже не можете придать огласке все её детали из опасения, что
весь Интернет окажется под угрозой краха, журналисты просто "хавают" это, и в
средствах массовой информации начинается настоящий цирк. Если вы на самом деле
думаете, что обнаруженный вами баг настолько серьезен, что до тех пор пока он не
будет пропатчен о нем нельзя говорить, то зачем тогда поднимать такую шумиху?
Это же просто нагоняет на всех страху. И что самое главное, подходящий момент
для окончательной публикации всех подробностей обычно наступает во время участия
авторов таких сенсационных заявлений в каких-нибудь масштабных презентациях, за
участие в которых им заплатили.
Поэтому мое мнение по поводу всех этих вещей довольно категорично: выкладывай
или заткнись! Если ты пойдешь по пути полного раскрытия информации и представишь
исчерпывающую информацию об обнаруженном тобой баге уже в момент объявления о
его наличии, это будет просто прекрасно. И если ты захочешь сначала
посоветоваться с производителями и прочими заинтересованными лицами и
предварительно выпустить совместными усилиями соответствующий патч, это тоже
будет прекрасно. Но если ты действительно хочешь сначала предпринять
скоординированные действия (то, что бизнес называет "ответственным подходом"),
то ты не станешь на каждом углу кричать о найденной тобой проблеме хотя бы до
того момента, когда причина ее возникновения не будет устранена. Я не пытаюсь
никого научить как делать заявления – они всегда были в индустрии безопасности
делом сугубо личным и политическим. Поэтому, конечно же, пусть решают сами. Но
если люди принимают решение о запугивании общественности основываясь лишь на
частичном разглашении информации, я оставляю за собой право выражать по поводу
таких методов работы некоторые свои мысли, что я и делаю сейчас. Сразу хочу
заявить, что я понимаю о чем они хотят сказать, поскольку я в свое время написал
и использовал схожую утилиту для DoS-атак. Хотя в этом и не было ничего особенно
нового.
Разъяснения
Больше всего меня знают,
наверное, как автора бесплатной утилиты Nmap Security Scanner, низкоуровневого
инструментария для аудита сети. В 2002 году я написал к ней дополнение под
названием Ndos ("Network Denial of Service"), при помощи которого становилось
возможным проведение DoS-атак против сервисов на основе TCP.
Осуществлялось все это путем истощением ресурсов приложений, которые
находились в режиме прослушивания портов, или ядра операционной системы, под
которой они работали. Существует множество ресурсов, резервы которых можно
расходовать при таком подходе, но основными считаются ограничение на количество
открытых сокетов для режима прослушивания и стек TCP, send буферы TCP в ядре
системы, вместе с сопутствующими ограничениями процессов, заданными операционной
системой или самим приложением. Я создавал эту утилиту для того, чтобы
использовать ее против своих клиентов. Не тех, конечно, кто задерживал выплаты
:), а тех, кто хотел проверить свои сети на устойчивость к DoS-атакам. И, как
Роберт и Джек, я был когда-то просто поражен, насколько эффективными могут
оказаться эти методики и насколько быстро им удается прекращать работу различных
сервисов. Самая обычная атака могла затруднить обработку сервером клиентских
запросов, а более сложные ее варианты и вовсе были в состоянии "уронить"
удаленную ОС.
Основная идея при атаке состоит в том, чтобы сначала оградить свой исходный
адрес (адреса) при помощи таких утилит как, например, iptables, чтобы
избежать вовлечения в нее своей собственной операционной системы. Следующее, что
нужно предпринять, это создать сотни или тысячи соединений на тот TCP-порт,
который выбран мишенью для атаки (например, порт 80 веб-сервера). Для этого
нужно сделать следующее:
- Организатор атаки посылает TCP SYN пакет на необходимый ему порт со
своего собственного IP-адреса (или с тех адресов, которые он контролирует)
для того, чтобы создать соединение. - Нужный порт открывается и теперь он отсылает хакеру пакет SYN/ACK –
второй шаг в в трехступенчатой
схеме "рукопожатия" TCP. При этом необходимо помнить, что для установки
соединения хакер отсылает SYN как raw-пакет, а не через connect() из API
операционной системы. Ведь когда операционная система хакера в стеке TCP
видит не ожидаемый SYN/ACK пакет, система обычно убивает устанавливаемое
соединение отсылкой RST пакета. Вот почему в самом начале я упомянул о
создании специального правила – оно необходимо для того, чтобы предотвратить
такое вмешательство со стороны собственной ОС. В нашем случае управление
всеми пакетами возьмет на себя DoS-клиент хакера, достигается это перехватом
пакетов (в основном, при помощи libpcap) и созданием/рассылкой ответных
raw-пакетов. - Используя последовательность, полученную из SYN/ACK, хакер отсылает
подтверждающий пакет (последний шаг в трехступенчатой схеме приветствия) и
устанавливает соединение.
Во многих случаях уже только этого достаточно для того, чтобы сделать сервис
неработоспособным. Каждое открытое TCP-соединение использует значительное число
системных ресурсов на машине жертвы (записи различных состояний TCP стеке ядра,
память, выделяемая приложению, дескрипторы сокетов и т.д.). Большое число
веб-серверов и прочих подобных приложений создают (или, по крайней мере,
занимают) свою ветку процессов для каждого сопутствующего соединения. В то же
время, в ОС хакера ресурсов задействуется совсем немного. Поэтому можно просто
повторять описанные выше шаги сотни или тысячи раз, до тех пор, пока на стороне
жертвы не произойдет истощения одного из критических ресурсов или какого-нибудь
другого сбоя. Для проведения атаки хакеру необходимо использовать уникальный
порт для каждого из соединений на атакуемый удаленный порт жертвы. Поэтому число
соединений с одного IP-адреса ограничивается цифрой 65 535. Некоторые крупные
веб-сайты настроены настолько удачно, что могут с успехом обрабатывать такое
количество одновременных соединений, и поэтому вам, как хакеру, для успешной
реализации задуманного необходимо иметь под рукой как можно больше
подконтрольных IP. На Linux я обычно при помощи iptables настраивал IP алиасы
для того, чтобы помешать TCP-стеку системы взаимодействовать с raw-пакетами.
Получив тысячи установленных соединений можно пойти еще дальше, начав
рассылку некой вредоносной нагрузки, разработанной под конкретный сервис.
Например, каждое соединение может запросить загрузку с сервера какого-нибудь
большого файла. Сервер загрузит первую часть этого файла в стек TCP для
отправки, используя при этом буферы в памяти ядра системы. Вернуть эти буферы
система не сможет пока вы (как нападающий) не подтвердите, что данные вами
получены. Но делать этого вы, конечно же, не станете, и объем доступной памяти
на подвергающейся атаке системе будет сокращаться с каждым новым разрушительным
запросом. Я сталкивался со многими операционными системами (в частности, с
различными вариантами BSD, такими, как FreeBSD), которые попросту
перезагружались после того, как такие буферы в памяти (mbufs) переполнялись.
Своим клиентам я советовал увеличивать переменную maxusers ядра системы с тем,
чтобы сделать их серверы чуть более гибкими. Злоумышленники могут еще больше
увеличить эффективность своих действий начав манипуляции с размером окна TCP в
отсылаемых ими пакетах. Большой размер окна, однако, может создать проблемы тем
хакерам, канал связи с Интернет у которых не очень широк, поскольку они сами
могут быть с головой завалены большими и часто повторяющимися пакетами,
отсылаемыми им атакуемой системой. Низкий (или даже нулевой) размер окна поможет
этого избежать.
Среди других способов усиления эффекта можно назвать фрагментацию IP и
сегментацию TCP. Например, можно понапрасну тратить память отсылая
множество пакетов больших размеров, в каждом из которых содержится один
пропущенный фрагмент, или можно создать дыру в TCP потоке, отсылая данные из
конца текущего окна, в середине которого ничего не содержится. Система
зарезервирует эти данные до тех пор, пока вы не решите переслать недостающие
пакеты.
Вы всегда сможете разнообразить свои атаки, выбирая их жертвой различные
ресурсы одновременно. Так, можно запросить создание динамической страницы,
генерация которой требует серьезных затрат ресурсов процессора. Все эти варианты
– лишь разновидности одной фундаментальной операции, которая использует
неконтролируемую посылку TCP-пакетов для создания огромного числа соединений и
(возможно) запроса зависящей от приложения нагрузки (дополнительно нагружающей
каждое из этих соединений) с различными дополнениями для более разрушительного
поражения.
FAQ
Здесь я отвечу на вопросы, которые получил или ожидаю получить.
Эти люди действительно открыли что-то новое?
Сам метод атаки, описание которого я привел, конечно же не нов. Я использую
его в работе уже много лет, но даже я не являюсь его изобретателем. Фактически,
суть его очевидна всем, кто хоть сколько-нибудь серьезно занимается сетями на
основе TCP/IP. Исчерпывающее описание этой атаки с примерами создания исходного
кода было
опубликовано на Bugtraq Станиславом Шалуновым в апреле 2000 года. Затем, в
декабре этого же года, Bindview дополнил эту работу, опубликовав более
систематизированный
"Naptha" project.
Я уверен в том, что Роберту и Джеку удалось найти нечто такое, что еще больше
расширило применение этого метода. Отталкиваясь от изложенной выше основной
схемы, разработать различные оптимизации проводимых атак для знающего человека
не составит труда. Как признал в одном из своих интервью Роберт: "Сейчас у нас
есть пять задокументированных видов атак. Но, безусловно, придумать новые будет
нетрудно". Всегда можно что-то изменить, будь то различные переменные,
содержимое пакетов, IP-адреса, или что-то еще.
То, чего Роберту и Джеку действительно удалось достичь, так это привлечь
повышенное внимание к этой серьезной и укоренившейся проблеме. И хотя она не
представляет угрозы для Интернет в целом, я считаю, что она требует того, чтобы
на ее устранение были направлены серьезные усилия. К сожалению, такое внимание
может помочь только тогда, когда изложены все детали. Вот поэтому я и написал
эту статью.
Откуда вы знаете, что Роберт и Джек обнаружили этот же баг?
Я и не знаю, поскольку пока нет никаких деталей. Но выглядит все так, как
будто это он и есть. Роберт и Джек – смышленые парни, поэтому, повторюсь, я
уверен, что они нашли способ дополнить существующую атаку и сделать ее более
эффективной, но даже самый простой подход, описанный выше, работает достаточно
хорошо. Не нужно придумывать ничего экстраординарного, поскольку самой типичной
модели может оказаться достаточно.
Но Роберт заявил на своем
блоге, что это – другая атака!
Что ж, давайте взглянем на слайды с их презентации на SecT (PDF, Powerpoint).
Например, на слайде 17 мы видим:
"Почему Full Connection Flooding не так популярен?
—Потому что он требует много ресурсов для отслеживания состояния"
Вышеописанная мной атака позволяет проводить засорение соединений без
отслеживания состояния запросов. Может быть они об этом просто не знали. И на
данный момент я склонен считать, что они лишь дополнили то, что и до них было
всем прекрасно известно. Поймите, я возражаю не против самого открытия, а против
назойливой рекламы таких вещей в прессе без публикации полных сведений. И я не
думаю, что их публикация может действительно взорвать Интернет, поскольку на
данный момент и так уже существует достаточное количество эффективных методик
проведения DoS-атак против TCP сервисов. Многие из техник, используемых для
защиты от всех других TCP DoS атак, будут работать и в новом случае.
Насколько серьезна эта проблема? Если она настолько хорошо известна,
почему же тогда злоумышленники ею не пользуются?
Отчасти потому, что те люди, которые этим занимаются, достаточно ленивы и
зачастую неопытны. Но, в основном, так получается из-за того, что прямолинейное
засорение пакетами имеет по сравнению с таким более утонченным способом ряд
преимуществ. Одно из них заключается в том, что такую атаку проще замаскировать
и, соответственно, затруднить противодействие. Для атаки, нацеленной на
истощение ресурсов, требуется наличие реальных IP-адресов, что облегчает
вычисление источника атаки и его последующую блокировку. Здесь нужно иметь в
виду, что эти адреса могут оказаться IP-адресами машин обычных пользователей,
которые поневоле стали участниками ботнетов и могут вообще никак не указывать на
самих хакеров.
Правда ли то, что на настоящий момент действенного решения этой проблемы
не существует? Роберт Ли заявил, что это именно так.
Когда атака уже началась, выявить и блокировать ее источник сравнительно
легко. Роберт и Джек подтвердили, что описанный ими метод не подходит для
IP-спуфинга. Поэтому, как и в других подобных случаях DoS атак, для прекращения
атаки нужно будет всего лишь установить и заблокировать IP-адрес источника.
Конечно, атакующий может найти новые адреса для атаки. И может причинить
достаточный вред до того как вы поймете что происходит. IDS/IPS программы могут
детектировать такие атаки на основе шаблонов и автоматически блокировать их.
Даже такой простой файрвол как iptables имеет модель connlimit для
предотвращения создания множества одновременных соединений с сервером. Конечно в
таком случае может пострадать и легитимный трафик, так что надо быть осторожным.
Можно так же более тонко настроить операционную систему и само приложение для
того, что бы они потребляли меньше ресурсов для каждого соединения.
Роберт и Джек представили свои наработки в CERT-FI, и там пришли к
заключению, что "вредоносные последствия от использования данной уязвимости
могут быть минимизированы при помощи фильтрации исходного адреса".
Где можно взять вашу утилиту Ndos?
Я не выкладывал ее, поскольку это был лишь быстрый набросок, не обладающий
качествами конечного продукта, и я переживал по поводу того, что он может
использоваться во вред. В 2004 году я стал соавтором книги "Stealing
the Network: How to Own a Continent", где я описал Ndos и продемонстрировал
скриншот справочного раздела этой утилиты. Главу, которую написал я, можно
бесплатно прочитать здесь.
И что же нужно делать со всеми этими SYN-cookies и SYN-флудом?
Замусоривание при помощи SYN – очень простая и хорошо изученная TCP-атака.
Она не создает полноценных TCP-соединений как эта более новая атака. SYN-cookies
были разработаны более десяти лет назад для того, чтобы бороться с проблемой
SYN-флуда, но против такой атаки они бессильны, поскольку в нашем случае
создаются полноценные соединения и не подделывает адрес источника. В своем
подкасте, который, похоже, и вызвал всю эту бурю публикаций, Роберт
использует SYN-cookies как один из аспектов примененного им метода. Он называет
их "клиентские SYN-cookies" и они мало связаны с описанием самого метода атаки.
На самом деле, для ее проведения они вообще не нужны. Но некоторые средства
массовой информации неправильно его поняли и даже порекомендовали отключить
SYN-cookies на серверах (как в этом
примере). Такие действия не помогут предотвратить новый вид угрозы, а только
сделают сервер уязвимым к старому и простому SYN флуду.
Где я могу прочесть дополнительную информацию по этому вопросу?
Вот несколько ресурсов и публикаций, связанных с этой проблемой (я за них не
отвечаю, а просто привожу для сведения):
- Часто обновляемый блог Роберта
blog.robertlee.name; - Слайды с презентации Джека и Роберта на SEC-T (в форматах
PDF и
Powerpoint);
Интернет-интервью с Бренно де Винтером (англоязычная часть);- Описание предстоящего обсуждения на
T2:
Sockstress - The Saga Continues; - Статья
и подкаст
Стива Гибсона по этой проблеме; - Рассуждения
на эту тему Дэна Камински.
Оригинал:
http://insecure.org/stf/tcp-dos-attack-explained.html
