Максим Степин
Широкое распространение сетей, построенных на основе протокола TCP/IP (как локальных, так и Интернет), привело к разработке методов преодоления защиты и появлению множества программ, предназначенных для совершения неправомерных действий в таких сетях. У неспециалиста в области компьютерной безопасности, читающего в прессе о все новых и новых случаях взлома защитных систем, ошибках в программном обеспечении и того подобного, складывается впечатление об абсолютном беспределе, царящем в киберпространстве, и уязвимости подключенного к сети компьютера. Сейчас, когда 16-битные платформы практически отошли в прошлое, самыми распространенными операционными системами являются различные версии Windows, и в настоящее время подавляющее большинство компьютеров работает под управлением одной из следующих систем: Windows NT, Windows ХР, Windows Vista, Windows 7, Windows 8. Поэтому рассмотрение некоторых аспектов безопасности этих систем будет интересно большинству пользователей. А поскольку Windows NT позиционируется как серверная платформа, то лекция может представлять интерес и для начинающих системных администраторов. Неправомерные действия по отношению к компьютерам и сетям можно разделить на несколько групп: взлом с целью получения привилегированного доступа, взлом с целью похищения конфиденциальной информации и так далее Особняком стоят действия, не преследующие личной выгоды и состоящие просто во вредительстве, выведении систем из строя. Как пример можно привести написание вирусов. Атаки, использующие ошибки в стандартах и их реализациях, называются Denial of Service (“отказ в обслуживании”), или DoS-атаки. В этой статье мы дадим краткий обзор DoS-атак для Windows-систем.
Нередко различные DoS-атаки называют общим термином nuke. Одна из самых известных атак как раз и называется WinNuke (о ней чуть ниже). Восстановим историческую справедливость в этом вопросе. Существует метод атаки, называемый просто nuke. Собственно, классический nuke не является DoS-атакой. Идея целиком основана на документированных стандартах, а не на ошибках в конкретной реализации TCP/IP. Суть классического nuke заключается в следующем. Для служебных целей в IP сетях используется протокол ICMP (Internet Control Message Protocol; его описание см., например, в RFC 1122). В частности, с этим протоколом мы встречаемся, когда используем программы ping и traceroute. Одной из возможностей ICMP является проверка наличия определенного адреса в сети. В случае ошибки соединения проводится диагностика ситуации и выдается сообщение: “сеть недоступна”, “адрес недоступен”, “ошибка маршрутизации” и другие. Стандартные реализации TCP/IP стека по приходу ICMP-пакета с извещением об ошибке производят определенные действия, в частности, перестройку таблицы маршрутизации. Но как побочный эффект происходит разрыв всех установленных соединений с машиной, имеющей адрес, о котором стало известно, что он недостижим. На основе этого эффекта и строятся диверсии. Действительно, если знать, что компьютер с адресом X установил соединение с компьютером Y, и послать ICMP-сообщение об ошибке на компьютер X с исходящим адресом компьютера Y, то безусловной реакцией будет разрыв этого соединения. Для осуществления подобной атаки необходимо работать с IP на более низком уровне, нежели стандартные функции. Чтобы подставить в пакет фальшивый адрес отправителя, нужно взаимодействовать непосредственно с IP, “вручную” заполняя все структуры, необходимые протоколам более высокого уровня. Подмена адресов IP пакетов называется спуфингом (от англ. spoofing - мистификация, обман). Практический эффект такого рода атак невелик. Для их осуществления необходимо знать, что два компьютера установили между собой соединение. В отношении пользователя, бесцельно бродящего по WWW, сделать это практически невозможно. Более уязвимы к такого рода “диверсии” пользователи, которые долго поддерживают соединение с определенным компьютером: любители разговаривать на IRC (или в Web-чатах) и играть в различные онлайновые игры (от MUD до новейших 3D-стрелялок). Классический nuke является одним из излюбленных инструментов ведения “военных действий” на IRC. Хотя простого способа противодействия ему не существует, утешает то, что среднестатистическому пользователю ничего не угрожает. А теперь перейдем непосредственно к описанию DoS-атак.
Начнем, конечно же, с классического и широко известного WinNuke, появившегося 7 мая 1997 года. Автор метода поместил его описание и исходный текст программы в несколько news-конференций. Ввиду крайней простоты метода практически каждый мог вооружиться новейшим оружием и пойти крушить направо и налево. Первой жертвой стал сервер microsoft.com. Он прекратил откликаться в пятницу вечером (9 мая) и только к обеду понедельника вновь обрел устойчивость. Остается лишь пожалеть его администраторов, которые весь уик-энд регулярно нажимали волшебную комбинацию трех клавиш, после чего реанимированный сервер падал вновь. А может быть, после первых нескольких попыток сервер и прекратили оживлять, кто знает… Конечно же, наряду с жертвой номер раз в мае 97-го пали многие серверы, на которых красовалась гордая надпись “Windows NT Powered”, а также серверы и без оной, но работающие под Windows NT. К чести Microsoft следует заметить, что заплатки появились довольно быстро. Итак, что же такое WinNuke? Наряду с обычными данными стандарт предусматривает пересылку по TCP-соединению и срочных (Out Of Band, OOB) служебных данных. На уровне форматов пакетов TCP это выражается в ненулевом значении соответствующего поля (urgent pointer). Большинство компьютеров, работающих под Windows, используют сетевой протокол NetBIOS, нуждающийся в трех IP портах: 137, 138, 139. Как выяснилось, если соединиться с Windows-машиной через 139-й порт и послать туда несколько байт OOB-данных, то NetBIOS, не зная, что делать с этими данными, попросту подвешивает или перезагружает машину. В Windows 95 это обычно выглядит как синий текстовый экран с сообщением об ошибке в драйвере TCP/IP, и работа с сетью становится невозможной до перезагрузки ОС. NT 4.0 без service pack'ов перезагружается. NT 4.0 лишь со вторым service pack'ом выпадает в синий экран, сообщая о необработанном исключении в коде ядра (эту картинку нередко называют blue screen of death). Судя по информации в Сети, такой атаке подвержены и Windows NT 3.51, и Windows 3.11 for Workgroups, и WinFrame, в основе которого лежит Windows NT 3.51.
Тут к месту упомянуть довольно забавную историю. Как выяснилось вскоре после выпуска SP3 (service pack 3 для Windows NT 4.0), WinNuke, запущенный с компьютеров Macintosh, легко “пробивал” защиту service pack'а. Причиной послужило существование двух разных стандартов на IP пакеты, содержащие OOB-данные, - стандарта от Berkley и стандарта, описанного в RFC. Они по-разному вычисляют UrgentPointer, и результат вычислений отличается ровно на единицу. Третий service pack, защищающий от “своих” OOB-пакетов, оказался беззащитен против пакетов другого стандарта. Поэтому почти сразу после SP3 вышел дополнительный OOB-fix. Его можно найти на ftp://ftp.microsoft.com
Следует заметить, что если для написания оригинального WinNuke достаточно самых тривиальных функций работы с TCP/IP (программа на PERL занимает семь строк), то, чтобы “пробить” SP3, потребуется работать с TCP на низком уровне либо запускать стандартный WinNuke с платформы, поддерживающей другую реализацию OOB. Само существование OOB-данных, безотносительно WinNuke, вызывает немало проблем именно из-за существования двух стандартов, или, вернее, отсутствия стандарта. Поэтому гарантировать корректную работу программы, использующей OOB, не может никто (правильнее сказать, легко можно гарантировать ее некорректную работу). Умные люди рекомендуют вообще не использовать OOB-данные в своих программах, и многие так и поступают. Таким образом, OOB сегодня - это наличие потенциальных дырок, позволяющих злоумышленникам изобретать все новые и новые методы атак. Попросту “постреляв” OOB-данными по открытым TCP-портам, можно попытаться найти новую дырку в какой-либо программе. Некоторым, говорят, удается…
Еще одна ошибка обнаружилась буквально через месяц после нашумевшего дебюта WinNuke. Объектом атаки на сей раз стал протокол ICMP, точнее, его реализация. Этот протокол издавна привлекал любителей сетевых диверсий. Поскольку ICMP представляет собой внутренний механизм поддержки работоспособности IP сетей, то с точки зрения злоумышленника он является очевидным объектом атаки. Как пример можно упомянуть ping с большим размером пакета. Поскольку ICMP-пакеты имеют определенные привилегии в обработке, то ping большого размера может парализовать работу компьютера или даже целой сети, IP каналы которых будут передавать только ICMP-пакеты. Такой способ часто используется людьми, имеющими достаточно мощные каналы связи, против тех, кто адекватных каналов не имеет. Сей метод, основанный на грубой силе, очевидно, не требует большого ума (точнее сказать, не требует никакого ума и, видимо, поэтому так любим молодыми сотрудниками провайдерских организаций). Защиты от него в общем случае не существует, самый адекватный метод реакции - установив адрес злоумышленника, написать жалобы куда только можно. Но мы опять отвлеклись от основной темы. Объектом нашего исследования является известная ошибка, называемая SPing (Jolt, SSPing, IceNuke, IcePing, IceNuke, Ping Of Death…). Множество названий вовсе не означает множества различных модификаций. Просто разные люди называют одну идею по-разному, и встретить программу можно под всеми вышеперечисленными именами. Как выяснилось, Windows-системы неадекватно реагируют на получение сильно фрагментированного ICMP-пакета (кусочками до одного килобайта) большого размера (чуть больше 64 килобайт). Реакция заключается в безоговорочном повисании, включая мышь и клавиатуру. В конце июня 1997 года жертвой SPing пал сервер Microsoft, после чего его закрыли каким-то хитрым брандмауэром (думается, информация о типе и настройках этого брандмауэра относится к важнейшим секретам Microsoft). В отличие от WinNuke, жертвами SPing могут стать не только Windows-системы, но и Mac OS и некоторые версии Unix (заплатки для них, к счастью, уже имеются). Официальная заплатка от Microsoft для NT 4.0 с установленным SP3 (далее везде по тексту будет подразумеваться, что NT 4.0 имеет установленный SP3) лежит на ftp://ftp.microsoft.com
Заметим, что SPing намного серьезнее, нежели WinNuke, поскольку использует ICMP-пакеты, которые чаще всего не фильтруются брандмауэром, а если и фильтруются, то подобного рода защиту можно попытаться преодолеть, используя приемы спуфинга.
Следующий метод атаки, называемый land, замечателен в первую очередь огромным числом поражаемых систем. Кроме Windows NT, этой напасти подвержены и Mac OS, и множество вариантов Unix (от бесплатных до коммерческих), и такие экзотические системы, как QNX и BeOS, и даже многие аппаратные маршрутизаторы (в том числе от Cisco и 3Com). Практически для всех систем уже имеются исправления, хотя, конечно же, установили их далеко не все владельцы компьютеров. Что же такое land? При инициации TCP-соединения посылается пакет с установленным флагом SYN. Нормальной реакцией на получение SYN-пакета является подготовка ресурсов для нового соединения, посылка SYN-ACK-пакета (пакета подтверждения) и ожидание реакции с другой стороны. Если в течение определенного времени ответа не последует, SYN-ACK-пакет передается повторно несколько раз, как правило, со все большей задержкой. Очевидным методом атаки, использующим вышеописанный механизм, является классический SYN-Flood, заключающийся в следующем: на компьютер-жертву посылается множество SYN-пакетов с искаженными адресами отправителя. Компьютер-жертва тратит массу вычислительных ресурсов, пытаясь подтвердить соединения с абсолютно ничего не подозревающими или даже с несуществующими компьютерами. При достаточно большом количестве фальшивых запросов ресурсы компьютера-жертвы могут исчерпаться, и все другие процессы будут остановлены либо аварийно завершены (другой вариант: будут сброшены все имеющиеся соединения). Но это очень старый метод, основанный на грубой силе. Механизм работы land хитрее. Посылается SYN-пакет с адресом отправителя, совпадающим с адресом получателя, жертвы. Пакет посылается на любой открытый порт. Для Windows-систем это почти всегда может быть порт 139 (наш старый знакомый по WinNuke). Для других систем это может быть любой известный порт (21, 80 и другие). Реакцией Windows-компьютера на land является абсолютное повисание. Заплатку для Windows NT 4.0 можно скачать с ftp://ftp.microsoft.com. Для остальных подверженных атаке систем заплатки могут быть найдены на сайтах компаний-производителей.
Найденный в том же несчастливом 1997 году метод атаки Teardrop основан на ошибках в реализации TCP/IP стека. Атаке подвержены Windows-системы, а также компьютеры с Linux. Заплатка от Microsoft для Windows NT лежит по адресу ftp://ftp.microsoft.com. Строго говоря, эта заплатка, появившаяся довольно быстро, предназначалась для отражения другой атаки (которая заключается в посылке большого количества UDP-пакетов с искаженным адресом отправителя на 19-й порт, что приводит к повышенному UDP-трафику). Фурора, подобного тому, который вызвал WinNuke, на сей раз не было. Возможно, пользователи уже свыклись с тем, что новые методы DoS-атак появляются регулярно. Тем не менее, Teardrop замечателен тем, что стал первым из семейства подобных (об этом будет рассказано ниже). Он прекрасно иллюстрирует тот факт, что любые программы, даже насчитывающие несколько строк, содержат ошибки. (Если вы уверены, что программа безошибочна, значит, вы просто не заметили ошибки, которая после обнаружения будет казаться очевидной.) Совершим небольшой экскурс в тайны реализации TCP/IP стека. Передача данных в TCP/IP сетях осуществляется не с помощью неких идеальных носителей информации, а по вполне реальным каналам (часто отвратительного качества), и в сам стандарте заложено, что передаваемый пакет может разбиваться на несколько меньших пакетов, а принимающая сторона возвращает ему первоначальный вид. Точнее, более высокоуровневые, чем IP, протоколы TCP и UDP могут передаваться фрагментированно на уровне IP. Каждый фрагмент характеризуется смещением от начала исходного пакета и своей длиной. Драйвер TCP/IP стека собирает фрагменты на принимающей стороне до тех пор, пока не получит их все (или, во всяком случае, пока не решит, что принял все). Безусловно, при передаче возможны различные ситуации, которые умная реализация TCP/IP должна распознавать. В частности, может быть, что несколько полученных фрагментов будут пересекаться. Нас интересует ситуация, когда новый фрагмент имеет смещение, лежащее внутри уже полученного фрагмента. Что же делает TCP/IP стек в этом случае? Во-первых, вычисляется размер пересечения: смещение старого фрагмента плюс длина старого фрагмента есть смещение нового фрагмента. А затем в буфер копируется только та часть нового фрагмента, которая “выступает за границу” старого фрагмента. Все просто и очевидно. Однако возможна ситуация, когда новый фрагмент не только начинается внутри старого, но и заканчивается в нем же. По идее, такой фрагмент должен быть просто пропущен, но как раз этого программисты, писавшие Windows NT и Linux, и не предусмотрели. Что же происходит в этом случае? Пусть у нас есть уже полученный фрагмент A, со смещением A_offs и длиной A_len. Пришел новый фрагмент B, со смещением B_offs и длиной B_len. Причем A_offs < B_offs < B_offs + B_len < A_offs + A_len, то есть фрагмент B лежит внутри фрагмента A. Проследим действия принимающей стороны по шагам. Начало нового фрагмента лежит внутри имеющегося. Пересекающаяся часть имеет смещение A_offs + A_len - B_offs. А тот кусочек, что нужно добавить в буфер, начинается с A_offs + A_len и имеет длину (B_offs + B_len) - (A_offs + A_len). О-ля-ля! Длина-то меньше нуля или (если вспомнить о машинной зацикленной арифметике) является очень большим числом. И вот такого большого размера блок памяти будет копироваться, уничтожая при этом все встречающееся на пути (обычно под “горячую руку” попадает операционная система). Собственно, вышеописанное и есть Teardrop. Приведенное объяснение абсолютно верно для Linux (поскольку ее исходный код открыт), но, вероятно, аналогичный механизм делает потенциальной жертвой Teardrop-атаки и Windows NT. Вслед за появлением метода Teardrop возникло несколько его модификаций, которые были способны пробивать Windows NT с установленной против обычного Teardrop заплаткой. Известность получили Bonk (Boink), NewTear, SynDrop. Все эти атаки закрываются еще одной заплаткой: ftp://ftp.microsoft.com
Наиболее оригинальным среди них является SynDrop. По сути, он представляет собой оригинальный Teardrop с тем отличием, что в посылаемых фрагментах устанавливается флаг SYN (снова этот излюбленный флаг). После Teardrop-клонов не появлялось широко известных DoS-атак на Windows-платформы. Возможно, злоумышленники просто не предают огласке свои новейшие методы. Кто знает…
Процедура установки всех заплаток для Windows NT 4.0 с SP3 уже давно превратилась в нетривиальное занятие, поскольку заплатки исчисляются несколькими десятками и порядок установки нередко играет определенную роль (грубо говоря, можно установить заплатки в такой последовательности, что система будет неработоспособной). Однако с заплатками от DoS-атак на TCP/IP стек дело обстоит проще, поскольку они выпускались кумулятивными, то есть последняя заплатка содержит в себе все предыдущие. Windows 95 также имеет кумулятивные исправления. Их можно найти на: ftp://ftp.microsoft.com
Windows 98 пока выглядит “неприступной” для DoS-атак. Впрочем, время покажет… Последнее замечание по технической стороне вопроса: программы для осуществления перечисленных атак, по иронии судьбы, как правило, не реализованы для Windows-платформ. Причина кроется в том, что Windows-реализация интерфейса сокетов не в полной мере соответствует общепринятому стандарту. Только для WinNuke достаточно простейших процедур реализации сокета. Остальные методы требуют непосредственной работы с заголовками IP пакетов, для чего необходимо использовать не потоковый или датаграммный сокет, а так называемый “сырой” (SOCK_RAW - если в терминах констант). WinSock 1.1 попросту не поддерживает такой возможности. Она имеется в WinSock 2.0, но и тут потенциальных нарушителей ждет разочарование: сырые-то они сырые, но возможности менять заголовок так и не появилось. Соответствующая процедура просто не была реализована. И все же есть способ использовать Windows в качестве платформы для атаки. Нужно написать NDIS-драйвер, который бы, перехватывая все IP пакеты, открывал доступ к их внутренней структуре. Но, по счастью, люди, обладающие необходимой квалификацией, находят себе более интересные занятия. Для тех, кто заинтересовался поднятыми в лекции вопросами, привожу небольшой список полезных URL:
www.microsoft.com - Здесь можно найти заплатки и небольшие комментарии к ним для различных операционных систем производства Microsoft;
www.cert.org - им положено знать все;
BUGTRAQ - это не сайт, а список рассылки, в котором оперативно появляется информация о найденных ошибках. Подписаться на него можно на сайте www.netspace.org ;
www.rootshell.com - один из самых больших сайтов хакерской направленности. Внимание, использование программ, находящихся на этом сайте, может преследоваться по закону!
www.ntsecurity.net - Этот сайт посвящен вопросам безопасности Windows NT;
www.nmrc.org/files/nt - еще один сайт про NT.
Приведем статью УК РФ, соответствующую тематике
Статья 273
: “Создание программ для ЭВМ или внесение изменений в существующие программы, заведомо приводящих к несанкционированному уничтожению, блокированию, модификации либо копированию информации, нарушению работы ЭВМ, системы ЭВМ или их сети, а равно использование либо распространение таких программ или машинных носителей с такими программами - наказываются лишением свободы на срок до трех лет со штрафом в размере от двухсот до пятисот минимальных размеров оплаты труда или в размере заработной платы или иного дохода осужденного за период от двух до пяти месяцев. Те же деяния, повлекшие по неосторожности тяжкие последствия, наказываются лишением свободы на срок от трех до семи лет. ”Дмитрий Докучаев
Методы защиты от масштабных нападений в массовых изданиях тема DDoS освещена со всех сторон. Многие авторы пишут о DDoS-атаках, об их реализациях и о последствиях. Но мало кто задумывается по поводу вопроса защиты от подобных нападений. Когда конечный пользователь сам сталкивается с такой атакой, то, по понятным причинам, он не знает, что делать, и куда бежать. На самом деле, никуда бежать не надо - достаточно прочитать эту лекцию.
Однажды, имея достаточно крупный ресурс на попечении, я столкнулся с серьезной проблемой. Кто-то заказал масштабную DDoS-атаку на мой проект. Симптомы нападения были налицо: при обращении к web сайту Apache дико тормозил и возвращал контент лишь через десять минут. При заходе в консоль демон sshd вообще не отвечал на мои запросы. Сперва я подумал, что произошла какая-то фигня на сервере, и попросил мой датацентр перезагрузить машину (сайт проекта располагался на выделенном сервере в USA). После внеплановой перезагрузки с горем пополам мне все-таки удалось войти в консоль. Что я там увидел - не описать словами. Процессор был загружен на 100 процентов, а показатель Load Overage достигал 160. Стоило мне убить процесс httpd, как машинка ожила, и загрузка мигом снизилась до нуля. Стало ясно, что боты бомбят запросами web сервис. Проблему нужно было как-то решать, и только тогда я понял, что рациональных методов защиты от DDoS не существует.
Многие авторы в своих статьях рекомендуют обратиться к провайдеру и попросить администрацию зафаерволить IP адреса на вышестоящем брандмауэре. Эта идея хороша тем, что юзеру вообще не нужно париться насчет нападений, однако прием работает не всегда. Когда я написал администрации датацентра об атаке, те просто пожали плечами и ответили, что ничего делать не собираются. Мол, у тебя есть свой файрвол, вот и обороняйся сам. Кстати сказать, подобную политику ведут многие хостинги и центры. С виду, ситуация выглядела неизбежной, но нужно было что-то предпринять, ведь оставаться без денег я тоже не хотел.
С головой окунувшись в инет, я пытался найти средство защиты от DDoS. Казалось бы, под потоком левых запросов находился всего один сервис, значит, решение проблемы должно быть где-то на поверхности. На одном из ресурсов, я обнаружил ссылку на модуль для Apache под названием mod_dos
evasive. По словам разработчика, данный плагин позволяет защититься от крупномасштабной атаки, если последняя нацелена на Apache. Мне предстояло это проверить. Я скачал сам модуль и достаточно быстро поставил его на сервер. Оставалось лишь отконфигурировать httpd.conf и забыть о проблемах. По крайней мере, так писалось в README к модулю.В конфиг Апача [httpd.conf] мною было добавлено несколько строк:
DOSHashTableSize 3097 DOSPageCount 2 DOSSiteCount 50 DOSPageInterval 1 DOSSiteInterval 1 DOSSystemCommand echo %s >> /var/log/niggerz
Для большего понимания давайте рассмотрим подробнее вышеописанные строки. В первой строке инициализируется размер так называемой хэш-таблицы, которая обрабатывает запросы к WWW-серверу. Затем располагаются счетчики запросов к одной странице и ко всему сайту. Интервал обращения по умолчанию равен одной секунде - это видно из последующих директив. Таким образом, если кто-то обратился к одной странице трижды за одну секунду, IP адрес неприятеля будет заблокирован. Тот же самый результат произойдет в случае многократного обращения (50 попыток в секунду) к любой странице сайта.
Однако по умолчанию модуль просто возвращает ошибку 403 после блокировки. Даже в этом случае при масштабной атаке нагрузка на сервер может быть очень большой. Чтобы избежать подобного, я настроил модуль на простое добавление адреса в блэк-лист /var/log/niggerz с последующей обработкой этого файла специальным скриптом. Следовало учитывать, что операция записи происходит с правами nobody, поэтому необходимо установить атрибут 666 на файл.
Итак, система была настроена, и оставалось лишь запустить httpd. Как и ожидалось, после старта в списке злобных ниггеров стали появляться первые IP адреса. Но почему-то там их было не так много, как я предполагал. Каждую минуту через crontab запускался специальный скрипт, который загонял в бан все адреса, накопившиеся в листе, а затем обнулял этот список. Все вроде бы работало, но особого эффекта не давало. Система также тормозила, а httpd вообще перестал инициализировать новые соединения.
Не знаешь сам - спроси товарища. Поиски каких-либо решений в Сети оказались тщетными. На форумах проблема DDoS практически не обсуждалась, а если о ней и говорили, то готовых решений никто не предлагал. Ничего не оставалось, как спросить знакомых админов по ICQ. Один из них поделился со мной замечательным скриптом, который впоследствии и натолкнул меня на разработку собственных методов защиты от коварных атак.
Сценарий был написан на языке Perl и не отличался особой сложностью. Каждую минуту он вызывался по крону и при запуске смотрел результат выполнения команды “netstat -ant|grep ESTABLISHED”. Затем устанавливался какой-то предел соединений. Если данный лимит был превышен, IP адрес заносился в черный список фаервола. Таким образом, мой товарищ не раз защищался от масштабной атаки.
Поблагодарив админа, я решил установить этот сценарий в мою систему. После небольшой переделки, скрипт был готов к использованию и выглядел примерно так:
#!/usr/bin/perl @output=`netstat -ant|grep ESTABLISHED|awk '{print($4,$5)}'`; $arg=$ARGV[0]; foreach $line (@output) { chomp($line); $line=~/(.*..*..*..*)..* (.*..*..*..*)..*/; $devs{'63.33.33.33'}='sis0'; $src{$2}=$devs{$1}; $ips{$2}=$ips{$2}+1; } foreach $ip (sort keys %ips) { if ($src{$ip}) { if ($arg eq '0') { print "($src{$ip}) $ip => $ips{$ip}"; } if ($ips{$ip} > 7) { chomp($date=`date +'%d.%m.%y %H:%M:%S'`); open(f,'>>/var/log/attack.log'); print f "$date -> attack/scan from $ip [$ips{$ip}]"; close f; system("/sbin/ipfw -q add 13 deny ip from $ip to me"); } } }
Думаю, в этом коде студенты могут разобраться и без дополнительных комментариев. Тем более что работу сценария я уже описал. Лимит соединений в моем случае был равным семерке. Помимо основной функции, скрипт выводит статистику соединений, чтобы администратор знал, кто в данный момент его атакует.
Но и этот прием не дал стопроцентной защиты от атаки. Через пару часов показатель нагрузки реально снизился на 40%, апач перестал тормозить, но все равно чувствовалось, что атака продолжается. Причем, надо отметить, что стандартный файрвол успешно справлялся с натиском неприятеля, просто существовали какие-то специальные боты, которым удавалось обходить хитроумный скрипт
.И я обнаружил этих ботов всего за несколько минут. Для этого мне пришлось включить опцию verbose в моем фаерволе ipfw. Это делается простой командой sysctl -w net.inet.ip.fw.verbose=1. Затем я создал небольшое правило, обрабатывающее все пакеты. Данное правило должно опережать по номеру правило, которое запрещает весь трафик на машину. Я выбрал в качестве идентификатора число 50000. Сама команда добавления выглядела следующим образом:
ipfw add 50000 count log logamount 0 ip from any to me 80
Теперь можно было приступить к анализу файла /var/log/security. Туда, по умолчанию, стали записываться все обращения к серверу на 80 порт. Немного переделав вышеописанный сценарий, я стал перечитывать фиксированный фрагмент лога (командой tail -1000 /var/log/security) и брать оттуда число обращений. результат не заставил себя долго ждать - всего после 2-3 запусков нагрузка на сервер вновь упала.
Но подобным методом нельзя было защититься на все 100 процентов, потому как за время своей работы скрипт уже успел забанить 20-30 легальных посетителей ресурса. Это объясняется тем, что обычный пользователь при определенных условиях вполне может превысить мой лимит обращений (при обновлении страницы или при слабом канале).
Вышеописанной защитой я пользовался три дня. За это время, как я уже говорил, в бане файрвола накопилось порядка сотни добропорядочных пользователей. Запускать сценарий приходилось три-четыре раза в день. Подобная защита, несомненно, действовала, но доверять ей на все сто процентов было нельзя. Поэтому я решил разработать новый вариант защиты против DDoS-атаки. В этом мне очень помогла система журналирования Apache.
Мне захотелось посмотреть на запросы, которые боты посылают WWW-серверу. Как оказалось практически все реквесты были одинаковыми и неотличимыми от пользовательских. На первый взгляд в запросе фигурировал Referer, правильно оформленное обращение на рандомную, но существующую страницу и реальный UserAgent. Однако последнее поле заставило меня усомниться в правильности запроса. В большинстве залогированных строк UserAgent имел префикс Win 98.x. Видимо это и была единственная отличительная черта обычных реквестов от вражеских. В моей голове уже родился план новой защиты сервера от ботов. И уже через 15 минут я его реализовал в виде компактного Perl-сценария
. Грех не привести его исходный код, потому как многим администраторам он пригодится.#!/usr/bin/perl $num='cat /var/log/rule';# В этом файле хранится номер правила chomp $num; $cmd='tail -1000 /usr/local/apache/logs/access.log|grep "Win 9x 4."|cut -f1 -d" "|sort -u'; # Выгребаем последние 1000 записей с шаблоном, вырезаем из нее IP адрес и убиваем дубликаты @cmd='$cmd'; chomp @cmd; foreach $each (@cmd) { chomp $each; $rule=0; chomp $rule; open(DB,'/var/log/niggerz'); while() { if (/$each/) { $rule=1; break } # Если адрес уже используется - завершаем работу } close(DB); unless ($rule) { # В противном случае - заносим IP в блэк-лист system('/sbin/ipfw add '.$num.' deny ip from '.$each.' to me 80'); open(LOG,'>>/var/log/dos.log'); print LOG 'banned ip '.$each.' as rules '.$num; close(LOG); open(DB,'>>/var/log/niggerz'); print DB $each;# И добавляем запись в лог и в базу ниггеров. close(DB); $num++; }} echo $num > /var/log/rule;# Обновляем номер правила
Этот сценарий парсит журнал на предмет отличительных запросов, выделяет из них ip-адрес, а затем ищет аналогичный айпишник в специальной базе. Если адрес не найден, значит его нет в правилах ipfw, следовательно, он там незамедлительно появляется. В противном случае, ip бота уже был забанен, поэтому сценарий не засоряет файрвол повторным правилом.
Скрипт antiDDoS.pl запускается через crontab каждую минуту. Этого вполне хватает, чтобы отразить атаку 2-3 тысяч ботов, как было в моем случае. Единственный минус в работе сценария заключается в том, что он не может быстро восстановить работоспособность сервера. Иными словами, при излишне активной атаке (20-30 запросов в один момент времени), сервер все равно уходит в анабиозное состояние, но возвращается из него через 3-4 минуты.
Если вы думаете, что я поставил сценарий и забыл о ботах, то ошибаетесь. Несмотря на то, что за трафик я не платил (а боты нагоняли в день около 500 мегабайт мусора), я захотел справедливости. Поэтому моей задачей было отписать в abuse всем network-администраторам тех сетей, на которых крутились боты, тем самым разрушив ботнет. В течение часа с помощью команды whois и bash-евых средств автоматизации я собрал почтовые адреса на 90% ботов. Моя задача упрощалась тем, что в большинстве случаях атака велась из одной подсети. Таким образом, мне понадобилось написать всего 400 жалоб, чтобы сообщить обо всех уязвимых машинах. Задача была выполнена всего за три часа, и уже через день я получил добрую половину ответов от админов, которые обещали обезвредить заразную машину. Всего через неделю поток флуда на мой сервер полностью прекратился. Видимо, ботмастер понял, что со мной опасно иметь дело, или заказчик флуда перестал платить деньги за атаку. В любом случае я одержал победу над злодеями, чему до сих пор очень рад.
Мораль басни такова: даже если тебя атакуют несколько тысяч ботов, а вышестоящий провайдер отказывается помогать, действуй самостоятельно. В статье я привел несколько готовых решений по защите от самых опасных атак, твоя задача - выбрать оптимальный вариант. Если ты платишь за трафик и не один вариант тебя не устраивает, попробуй сменить датацентр на более дружелюбный, где заботятся о каждом клиенте, или хотя бы не берут деньги за трафик.
Если вы счастливый обладатель Linux, то переделать скрипты в firewall не составит особого труда. Следует лишь вместо
ipfw использовать фаервол iptables. Однако нужно помнить, что слово setup, которое отвечает за тип ESTABLISHED-соединения, должно быть заменено на конструкцию “-m state --state ESTABLISHED”.Следует также внедрить механизм сохранения правил после перезагрузки. Здесь существует два варианта - либо пользоваться сервисными командами (наподобие, /sbin/service iptables save), либо заносить правило в список вручную. При последнем приеме не забывай, что список правил iptables обычно хранится в /etc/sysconfig/iptables.
Большинство DDoS-атак базируется на особенностях работы протокола TCP/IP, в частности, на способе обработки входящих пакетов с флагом SYN. Эти атаки достаточно сложно предотвратить, особенно, если система подразумевает общедоступные входящие соединения. Тем более, что для проведения таких атак не требуется высокая квалификация атакующего и средства для их проведения легкодоступны. Также осложняет борьбу с такими атаками тот факт, что они, как правило, проводятся со множества адресов, зачастую находящихся в разных сегментах Сети и принадлежащих разным операторам связи. Поэтому какого-то стопроцентного способа борьбы с нападениями попросту не существует
.На данный момент самое действенное средство борьбы с этим типом атак - это контроль со стороны оператора связи, который должен обеспечивать их быстрое обнаружение и блокирование этого трафика на входе в свой сегмент сети. Операторы связи пытаются предотвращать подобные атаки путем установки фильтров, которые отсекают такой трафик в автоматическом режиме. Особенно эта практика распространена у зарубежных операторов связи. Причем зачастую от действия таких фильтров страдают обычные пользователи, так как достаточно сложно отличить трафик DDoS-атаки от некоего приложения, устанавливающего одновременно несколько соединений с каким-либо узлом.
|
![]() |