Вирусы последнее время совсем совесть потеряли. Эпидемия за эпидемией. Главная причина проистекает из "свободной" идеологии передачи данных. И поправить не слишком просто, косметическая правка приведет ко вполне косметическим результатам.
Относительно качества ПО, производимого монстрами рынка есть хорошая иллюстрация на эмигрантском форуме privet.com. Да и вообще, для относительно сложных программ есть принцип Д.Кнута: доказательство правильности программы - структура более сложная, поэтому более подверженная ошибкам. ("Beware of bugs in the above code; I have only proved it correct, not tried it"). Так что с этой стороны надежды на защиту нет никакой.
И следует смириться с тем, что черви неистребимы, как грипп. Хуже того - после появления в сети достаточно распространенной денежной системы они станут ещё более неистребимы и опасны, чем сейчас спам. Но об этом ниже - в статье Виктора С. Грищенко.
Долго искал место на сайте, куда поместить следующую новость. Но вот она - 30-го августа 2003 года с 12:00 до 9:00 31-го августа 2003 под Подольском состоится мега акция Moscow HomeNET Point. Сайт тусовки - тут.
Небольшие обновлениям разделов.
Abstract:
В статье вскрываются некоторые недостатки подхода Вильямсона, сильно ограничивающие его область применения. Также предлагается более пластичный подход (модель с замерзанием), сильно ограничивающий возможности червя (и не только червя) по сканированию Сети.
Модель замерзания подразумевает подавление источников, имеющих большое количество "неотвеченных" IP-потоков. Сугубый ad-hoc к технологии IP, конечно.
Главная идея [1] - это замедление сканирования Интернет через ограничение количества новых IP-адресов, к которым может обратиться владелец данного IP-адреса за определенный промежуток времени. Ориентировочно этот порог предполагается в районе 1-2Hz. В случае повсеместного внедрения ограничение сделает сверхбыстрые эпидемии (10-15 минут на тотальное заражение) технически (почти) невозможными1.
Помимо прочего в этой работе утверждается, что в случае применения на достаточно высоком уровне ограничение Вильямсона может серьезно повредить базовым интернет-сервисам, а именно DNS.
Чтобы рассуждать практически, автор взял 24-часовой лог трафика DNS-сервера средней руки (не корневого, нет). При рассмотрении абсолютного числа различных IP-адресов, к которым обращался сервер, а именно 1834 штуки, ограничение в 1-2Hz кажется применимым (см. Рис. 1):
Рис. 2: Кумулятивное число новых dstip, история ограничена ста последними адресами, тот же лог.
Но настоящая проблема даже не в этом, а в том, что 1.25Hz - это средняя температура по больнице, поскольку DNS-трафик идет всплесками. Например, для разрешения www.hpl.hp.com2 DNS сервер должен сделать три последовательных запроса к трем другим серверам[2]. На загруженном сервере под 1-герцовым ограничением Вильямсона это может привести к 3-х секундной задержке. Очевидным образом это может привести к ещё большей задержке при нескольких одновременных запросах, более длинных запросах, и прочая, и прочая.
Таким образом, DNS-сервер не имеющий совершенно никаких причин, чтобы придерживаться даже 1,25Hz в среднем в сутки, в малом масштабе времени может продемонстрировать куда большие частоты запросов новым адресатам. Уж не говоря про то, что все эти показатели зависят от таких переменных, как количество пользователей, время дня и день недели, размещенное у клиентов ПО и, опять же, прочая, прочая...
Таким образом, ограничение Вильямсона реально применимо где-то на уровне корпоративных фэйрволов, не выше, поскольку конструкция ограничиваемой сети должна быть примерно известна (как минимум, знать IP-адреса DNS-серверов).
В случае, если автор червя располагает данными о доселе неизвестной уязвимости и умеет программировать (изучил опыт предыдущих червей), на настоящий момент ничто не мешает ему отформатировать пол-интернета за 10-15 минут (в крайнем случае - пол-дня). Д.Мур и другие [5] приходят к заключению, что наиболее перспективным путем борьбы с червями является content filtering, размещенная на транзитной инфраструктуре система удаления пакетов, выпущенных червем.
Для того, чтобы эта система приобрела терапевтическую, а не патологоанатомическую ценность, предполагается создание системы автоматического обнаружения в сети аномалий и выявления сигнатур червя3 - ведь через 10 минут лечить будет поздно.
Исключительно чтобы обозначить сложности данного подхода заметим:
Итак, поразмыслив пол-часа, мы создали глобальному перлюстратору проблем в лучшем случае на много миллиардов долларов.
Предположения Предполагается, что IP-адреса отправителя не могут фальсифицироваться случайным образом (IP spoofing), что, на данный момент, в большинстве случаев неправда.
Так же предполагается, что маршруты пакетов более-менее симметричны, то есть если пакет от к проходит через наше счетное устройство то и ответный пакет через него пройдет.
DNS в среде с нагреванием/охлаждением
На первый взгляд кажется, что DNS-сервер должен иметь примерно нулевую температуру: он получает запрос клиента (+1), запрашивает корневой DNS-сервер (-1), получает ответ (+1), запрашивает и получает ответ ещё от n DNS-серверов (-1+1 n) и отвечает клиенту (-1).
Чтобы проверить эту гипотезу я набросал программу, которая по логам сетевой активности вычисляет температуру IP адреса (заметим: ни замерзание-остановка, ни потеря излишнего тепла не были реализованы за невозможностью и ненадобностью соответственно). Уже упоминавшийся DNS-сервер накопил +3148 градусов тепла за все тот же 24-х часовой период.
Причина этого явления кроется, видимо, в деталях протокола, который я поленился досконально изучить.
В нашей среде NAT - это очень интенсивный клиент, делающий запросы множества пользователей от своего "имени" (IP-адреса). Вышеупомянутой программе был дан 24-х часовой лог NAT'а, всего 74373 записей. Весьма интересно, что NAT продемонстрировал почти идеальный баланс: +2 градуса. (на Рис. 3) можно посмотреть количества потоков в секунду - что характерно, чаще они четные).
Упомянем случай бота поисковой машины (Google, например). Шарящий по сети бот может рассматриваться, как клиент очень большой интенсивности. От интенсивности зависит краткосрочная амплитуда, в то время как среднесрочный баланс примерно равен нулю. При условии, что частота попадания на "мертвые" сервера не превосходит частоты Вильямсона, бот замерзнуть не должен.
Достаточно очевидным образом сканирующий хост очень быстро зарабатывает рекордно низкую температуру. Был взят лог из 2028180 записей (24-х часовой период) трафика с IP-адреса, осуществляющего сканирование на порту netbios-ns 137. Температура в результате достигла -1,628,474 градусов (см. Рис. 4) 5.
Вопрос: можно ли использовать замерзание для косвенной DoS атаки? Например, некоторым образом вывести из строя часть DNS-серверов. Произойдет цепная реакция: другие сервера, обращаясь к "мертвым", будут в свою очередь охлаждаться и замерзать, пока не замерзнет решительно все.
Стоит отметить, что все протоколы, действующие по принципу "запрос клиента - ответ сервера", а это FTP, HTTP, POP и другие, неуязвимы для замерзания. В дальнейшем будет рассматриваться DNS, как протокол с достаточно нетривиальным поведением.
Теоретически, достаточно знать об одном неотвечающем DNS-сервере - в том случае, если атакуемый DNS-сервер достаточно загружен (что-что, а загрузку серверу обеспечить просто). "Достаточно" сервер будет загружен в том случае, если наше обращение вымывается из истории соединений достаточно быстро. Т.е. зная длину истории на считающем устройстве , можно после запроса о "мертвом" домене соответствующее количество раз запрашивать информацию о других доменах. Если такой цикл будет происходить с частотой, большей , то DNS-сервер начнет замерзать. При длине истории 100 и =1Hz сценарий вполне реальный. Другой вопрос, что как только "обстрел" прекратится, сервер возобновит работу (оттает).
Вне зависимости от Н/О модели мы видим, что злоумышленник может заставить DNS-сервер демонстрировать довольно странное поведение. Чтобы ограничить такие возможности, следует во-первых разделить клиентов DNS-сервера на своих и остальных (свои - те что находятся в "своих" сетях, для них данный сервер - сервер DNS по умолчанию). Возможности "остальных" клиентов следует ограничить запросами по зонам, поддерживаемым данным сервером (запрос-ответ). Таким образом, возможности манипулирования DNS-сервером существенно сократятся.
Общая проблема всех методов подавления червей на транзитной инфраструктуре - то, что IP - это пакетный протокол общения точка-точка6. Поэтому, вполне естественным образом, чем дальше от точек происхождения и назначения, тем меньше полезной информации мы можем извлечь из проходящего трафика. Уже в машине происхождения кусок данных разбивается на пакеты, которые затем добираются до точки назначения кто как сможет. Т.е. если нитка протянута между двумя гвоздиками, то наиболее предсказуемо её географическое положение - вблизи гвоздиков, наименее предсказуемо - в середине.
Отсюда вывод: наиболее выгодное место для борьбы с червем - сами машины-жертвы (тут в большинстве случаев достаточно своевременно пропатчить ПО), затем фэйрволы (тут хватает простеньких правил пускать/не пускать), затем edge routers (они гарантированно имеют представление о трафике и к клиенту и от клиента, т.е. условие симметрии ещё соблюдается, также в большинстве случаев есть гарантия, что данный путь к клиенту - единственный, обхода нет).
Наименее выгодно с данной точки зрения бороться с червем на транзитной инфраструктуре, поскольку с огромной скоростью мимо пролетают обрывки каких-то потоков - анализ затруднен; потоки в противоположном направлении летят где-то в другом месте - нет симметрии; данный путь практически гарантированно не является единственным путем, ведущим к любому из клиентов - т.е. чтобы обезопасить клиента, нужно перекрыть все пути, частичные меры не дают значимого эффекта [5].
С другой стороны, представление об общей обстановке в сети (распознавание эпидемии) легче всего получить, наблюдая за транзитной инфраструктурой и сложнее всего - в конечной точке (туда придёт один поток, и его вам хватит).
Таким образом, если даже Д.Муру сотоварищи улыбнется фортуна в части создания искусственного интеллекта, наиболее выгодное место для размещения фильтрующих устройств - периферия сети, но никак не ядро. Так и масштабируется лучше. С другой стороны, как координировать и защищать все это распределенное хозяйство, не очень-то ясно. В сложном протоколе много проколов, а протокол обещает быть сложным, особенно учитывая отсутствие человеческого вмешательства.
Модели с ограничением количества потоков от одного клиента решают одну проблему, растущую год от года - сети все быстрей, а средний эксплойт как не превышал нескольких килобайт последние 15 лет, так и до сих пор не превышает. Соответственно, возможности червей все выше и выше. И если червь Морриса полз от соседа к соседу часами и днями, то гипотетический червь Уорхола [7], бомбя правого и виноватого, справляется за 15 минут с количеством машин, в 100 раз большим. Sapphire так и за 10 минут управился без особых хитростей.
Легко видеть, что реализация модели Н/О verbatim, т.е. согласно правил отнюдь не обязательна. Хотя алгоритм прост и легко реализуется в некоем счетном устройстве, работающем параллельно с настоящим обработчиком пакетов, тем не менее для дешевых устройств можно пойти на упрощения. В случае ATM, наблюдаемой автором, можно, например, отказаться от истории и считать входящие/исходящие потоки на каждый АТМ интерфейс.
Такие маленькие опции к сетевому оборудованию, как упрощения модели нагревания-охлаждения, в случае локального внедрения "спасут сеть" от работающего в ней сканирующего червя, в случае же глобального распространения сделают сверхбыстрые эпидемии маловероятными - люди будут иметь шанс вмешательства.
Городить же искусственный интеллект постольку, поскольку пользователи редко пользуются естественным - занятие сомнительное, к тому же с отрицательной обратной связью. Первый же червь, перехитривший глобальную систему фильтрования, может получить море беспечных жертв, не заштопавших дыры годичной давности.
Анонс
|