При условии, что выбор IP-адреса заражаемой жертвы происходит по более или менее случайному закону (а большинство червей распространяются именно так), по мере насыщения сети червем скорость его распространения будет неуклонно снижаться и вовсе не потому, что магистральные каналы окажутся перегруженными! Попробуйте сгенерировать последовательность случайных байт и подсчитайте количество шагов, требующихся для полного покрытия всей области от 00h до FFh. Очевидно, что за 100h шагов осуществить задуманное нам ни за что не удастся. Если только вы не будете жульничать, одни и те же байты будут выпадать многократно, в то время как другие останутся не выпавшими ни разу! И чем больше байт будет покрыто, тем чаще станут встречаться повторные выпадения! Аналогичным образом дело обстоит и с размножением вируса. На финальной стадии размножения полчища червей все чаще будут стучаться в уже захваченные компьютеры, и гигабайты сгенерированного ими трафика окажутся сгенерированными впустую.

Для решения этой проблемы Червь Морриса использовал несколько независимых механизмов.

Во-первых, из каждой зараженной машины он извлекал список доверенных узлов, содержащихся в файлах /etc/hosts.equiv и /.rhosts, а также файлы .forward, содержащие адреса электронной почты. То есть целевые адреса уже не были случайными – это раз. Отпадало большое количество несуществующих узлов – это два. Количество попыток повторного инфицирования сводилось к разумному минимуму – и это три. Подобную тактику используют многие почтовые черви, обращающиеся к адресной книге Outlook Express. И эта тактика очень неплохо работает!

На сайте корпорации Symantec имеется любопытная утилита – VBSim (Virus and Worm Simulation System), выполняющая сравнительный анализ эффективности червей различных типов.

Во-вторых, различные экземпляры Червя Морриса периодически обменивались друг с другом списком уже зараженных узлов, ходить на которые не нужно.

Конечно, наличие каких бы то ни было средств межвирусной синхронизации существенно увеличивает сетевой трафик, однако если к этому вопросу подойти с умом, то перегрузку сети можно легко предотвратить. Заразив все уязвимые узлы, червь впадет в глубокую спячку, уменьшая свою активность до минимума. Можно пойти и дальше, выделив каждому из червей определенное пространство IP-адресов для заражения, автоматически наследуемое новорожденным потомством. Тогда процесс заражения сети займет рекордно короткое время, и при этом ни один из IP-адресов не будет проверен дважды. Исчерпав запас IP-адресов, червь обратит свои внутренние счетчики в исходное положение, вызывая вторую волну заражения. Часть ранее инфицированных узлов к этому моменту уже будет исцелена (но не залатана), а часть может быть инфицирована повторно.

Как бы там ни было, грамотно спроектированный червь вызывать перегрузку сети не должен, и лишь досадные программистские ошибки мешают привести этот план в исполнение. Внешне такой червь может показаться вполне безопасным, и подавляющее большинство администраторов скорее всего проигнорируют сообщения об угрозе (ибо негласное правило предписывает не трогать систему, пока она работает). Дыры останутся незалатанными и… в один прекрасный момент всемирная сеть рухнет.

В этом свете весьма показателен процесс распространения вируса Code Red, в пике своей эпидемии заразившего свыше 359 000 узлов в течении 24 часов. Как были получены эти цифры? Программа-монитор, установленная в локальной сети Лаборатории Беркли, перехватывала все проходящие через нее IP-пакеты и анализировала их заголовки. Пакеты, адресованные несуществующим узлам и направляющиеся на 80-й порт, были, очевидно, отправлены зараженным узлом (Code Red распространялся через уязвимость в MS IIS-сервере). Подсчет уникальных IP-адресов узлов-отправителей позволил надежно установить нижнюю границу численности популяции вируса. При желании процесс расползания вируса по всемирной сети можно увидеть и в динамике – www.caida.org/analysis/security/code-red/newframes-small-log.mov. Там же, на странице http://www.caida.org/analysis/security/code-red/coderedv2_analysis.xml, содержится текст, комментирующий происходящее зрелище. А зрелище и впрямь получилось впечатляющим и… поучительным. Всем, особенно разработчикам вирусов, настоятельно рекомендую посмотреть. Быть может это научит кое-кого не ронять сеть своим очередным… ммм… творением.