В феврале мировое Internet-сообщество было захвачено врасплох массированными атаками, которые привели к так называемому отказу в обслуживании (DoS — denial-of-service). Им подверглись такие именитые сайты, как eBay, E*Trade, Yahoo и CNN. Однако Дэйв Диттрих из Университета штата Вашингтон встретил это нашествие во всеоружии: к тому времени он уже имел возможность познакомиться со средствами проведения распределенных атак на отказ в обслуживании (distributed denial-of-service — DdoS), такими как trinoo, Tribe Flood Network и stacheldraht, когда находящихся в его ведении несколько компьютеров были использованы для осуществления DdoS-атаки на Университет штата Мичиган.

Этот инцидент вдохновил Диттриха на написание обзора средств DdoS, который помог бы администраторам, отвечающим за безопасность своих систем, яснее понять суть угрозы. Кроме того, Диттрих вместе с Маркусом Ранумом, главой компании Network Flight Recorder, разработал утилиту сканирования сети под названием gag, позволяющую выявлять установленные в системе средства DDoS.

Корреспондент электронного журнала SunWorld Дж. С. Келли обсудил с Диттрихом проблему противодействия крупномасштабным сетевым атакам в будущем и необходимость для компьютерного сообщества объединить силы с правоохранительными службами.

Помню, в январе вы утверждали, что защиты от DoS нет. Однако теперь некоторые эксперты говорят, что организовать такую защиту все же возможно?

Совершенно верно. Появляется множество реальных предложений; некоторые из них можно реализовать уже сегодня, другие потребуют длительных разработок. Наиболее примечательными среди них, на мой взгляд, являются те, что Илайес Леви представил на Bugtraq, включая спецификацию RFC 2267 по механизму фильтрации и средствам ограничения скорости передачи на маршрутизаторах. Есть еще ряд предложений по поводу использования динамических адаптивных программ (это компоненты Cisco IOS, позволяющие устанавливать ограничения на процентные доли различных видов трафика и типы передаваемых пакетов); с помощью таких программ можно ограничить скорость поступления пакетов ICMP (Internet Control Message Protocol) в сеть. Если вам довелось испытать на себе мощь атак типа smurf — а это наиболее разрушительная разновидность DoS-атак, вы наверняка захотите использовать протокол ICMP для ограничения объема трафика и предохранения своей сети.

Много делается для совершенствования протоколов TCP/IP и разработки средств идентификации хост-систем. Они позволят предотвращать атаки, связанные с захватом ресурсов, поскольку предлагают новый способ установления сеансов. Ведутся работы по расширению возможностей маршрутизаторов по мониторингу пакетов, чтобы системные администраторы, не пользующиеся в своих сетях механизмом фильтрации, могли тем не менее определять их источник. Эта проблема стоит сегодня весьма остро, поскольку очень многие сети не способны предупредить ситуации, делающие их уязвимыми для атак.

Обнародуются и другие предложения, например, как обязать клиентов пользоваться определенной конфигурацией и как добиться того, чтобы эти правила проводились в жизнь повсеместно и абсолютно корректно.

Недавно президент США провел Web-конференцию. Насколько, по-вашему, уместна эта идея?

Безусловно уместна. Уверен, что многие фундаментальные проблемы, в том числе те, что связаны с DdoS-атаками, это, в сущности, проблемы образования: люди не способны осознать несовершенство Internet. Предприниматели вверяют судьбу своего бизнеса базовой инфраструктуре Internet, которая довольно хрупка и может не устоять под лавиной подобных атак. Однако сейчас отношение к созданию Internet-компаний приобрело характер религиозного фанатизма, когда уже не думают о таких суетных вещах, как безопасность.

В итоге люди не вполне осведомлены о существующих проблемах и не заботятся о заделывании дыр. Поэтому так много систем оказываются взломанными. Необходимо привлечь внимание к этому предмету и внести в него организующее начало.

Например, образована президентская комиссия по защите информационной инфраструктуры, в задачи которой входит формулировка целей и обязанностей лиц, ответственных за защиту инфраструктуры. Я уверен, что без участия президента не обошлось и создание Национального центра защиты инфраструктуры, организующего обмен информации между общественным и частным секторами.

Так что на этом уровне можно сделать многое для повышения всеобщей информированности и стимулирования сотрудничества с деловыми, академическими, правительственными и правоохранительными кругами.

Какого рода сотрудничество имеется в виду?

ФБР и правительство часто подвергают критике за недостаточную техническую компетентность. Но если заставить такие организации, как правоохранительные органы и Главное бюджетно-контрольное управление, пойти на рабочие контакты с компьютерной индустрией — с теми, кто действительно в курсе всех технических деталей, они будут реагировать гораздо оперативнее. В конечном счете появятся более грамотные предложения, более содержательные инициативы и деньги будут тратиться значительно эффективнее.

Только потому, что наладится общение?

Да, потому что учреждения, подобные ФБР, будут быстрее вырабатывать для себя политику в отношении компьютерного сообщества. Они постоянно учатся у нас. И одновременно учатся фирмы, выпускающие оборудование, например, маршрутизаторы. Им становится понятнее, что нужно сделать для того, чтобы их продукты становились совершеннее, а средства защиты инфраструктуры — надежнее. Вся суть в том, чтобы привлечь внимание к ключевым факторам, от которых зависит решение проблемы.

Недавние атаки породили беспокойство по поводу права на неприкосновенность частной жизни. Как вы думаете, эти страхи оправданны?

Абсолютно. Значительные деньги вкладываются в разработку средств мониторинга каналов связи, заметная часть бюджетных средств отводится на прослушивание, вполне, кстати, легальное. Однако деньги тратятся также и на обучение, юридическую поддержку и другие действительно важные направления.

Если будет принят стандарт прослушивания коммуникаций, даже не получивший правительственной поддержки, будет ли это означать, что нам по-прежнему придется тревожиться о возможном нарушении «прайвеси»?

В определенном смысле — да, поскольку тогда появится возможность отследить любое соединение из конца в конец. Однако важно понять, что Internet все равно позволит сохранять анонимность. Например, такие компании, как Zero-Knowledge (производитель средств защиты конфиденциальности. — Прим. ред.), могли бы разработать механизм установления анонимной связи, потребность в котором вполне обоснована. Впрочем, атака DoS — это вовсе не проявление свободы слова, а факт захвата и злонамеренного использования ресурсов, и администраторы должны иметь возможность проследить, откуда ведется нападение. Нынешнее состояние протоколов Internet делает эту проблему трудноразрешимой.

Что, помимо технических мероприятий, может предпринять компания, чтобы обезопасить себя? Что еще она может сделать, чтобы предотвратить подобные атаки?

Прежде всего необходимо усвоить, что отказ в обслуживании — это далеко не вся проблема. Все концентрируются исключительно на перебоях в работе сети и игнорируют более существенную часть проблемы, которая заключаются в недостаточной квалификации системных администраторов: компании обычно недооценивают их роль и «мирятся» с ними как с неизбежным злом, а не рассматривают их как основные ресурсы. Ход рассуждений примерно таков: «Зачем платить всем этим занудам — давайте оставим только одного из них, и пусть он работает 50 или 60 часов в неделю и обслуживает все 200 компьютеров». Стоит ли удивляться, что сети взламываются! У ИТ-персонала слишком много работы, ему мало платят, его не ценят.

Так не могли бы мы, воспользовавшись случаем, каким-то образом просветить публику в этом вопросе?

Я думаю, мы должны очень четко разъяснить, что эти расходы связаны с тем, что наша экономика глубоко укоренена в Internet, и чем скорее люди поймут это, тем лучше. Не исключена вероятность, что эта Internet-экономика будет расти слишком быстро и в итоге рухнет под собственной тяжестью — лишь потому, что мы не предусмотрели для нее достаточно крепкий фундамент.

Нам следует относиться к высокоскоростному компьютеру, работающему на быстром соединении, как к дорогому автомобилю, для которого нужен квалифицированный мастер автосервиса. Вы сами уже не можете его обслуживать: он слишком сложен, и вы только испортите его, если сами возьметесь за дело. К тому же, если вы, скажем, бросили машину, оставив ключи на виду на приборной доске, кто-нибудь наверняка влезет в нее и воспользуется вашим «подарком».

Этим системам нужны специалисты, которые умеют делать резервные копии, вовремя ставить заплаты, отключать ненужные службы и которые понимают, как работает операционная система, как разобрать ее на части и как собрать снова.

Вы полагаете, что таким образом мы в конце концов добьемся того, что корпоративные сети станут по-настоящему защищенными?

В конечном итоге — да. Вернемся к аналогии с автомобилями: первое время, когда их начали выпускать, на них не было ремней безопасности. Как, впрочем, и нормальных дверей. Много народу погибло из-за несовершенства конструкции автомобилей, равно как и из-за плохих дорог. Но со временем, ценой многих жертв, люди добились введения государственного регулирования, включая требования безопасности. Что касается Internet и программного обеспечения в целом, в эту область идеи безопасности еще не проникли, но я уверен — рано или поздно власти, страховые компании, другие организации займутся регулированием данной области и внедрением стандартов и практических рекомендаций.

Что может дать уверенность в том, что защита организована грамотно?

Кто-то (хотел бы я знать, кто именно) сказал: «В каждом совете директоров должен быть свой хакер».

Как я понимаю, вы говорите «хакер» в хорошем смысле этого слова.

О да, конечно. Я недавно сам стал называть себя хакером в интервью, чтобы внушить людям: хакерство не есть по определению злое намерение.

В СМИ сообщалось, что средства, использованные в известных атаках, представляли собой программы с открытым кодом. Как вы оцениваете этот факт?

Трудно сказать однозначно. Судя по всему, исходный код в самом деле был доступен этим людям. Они активно дополняли его собственными доработками; возможно, они общались по этому поводу с авторами кода, а может быть, и нет, я не знаю. Но, по правде говоря, мне не хотелось бы употреблять термин «открытый код» в данном случае; здесь та же ситуация, что и с использованием слова «хакер». Она дискредитирует концепцию открытого исходного кода. Дело в том, что в ряде случаев использовался термин «открытая модель разработки программ» в том смысле, что исходный код был доступен тем, кто использовал и разрабатывал данные средства. Следовательно, люди, не имеющие ничего общего с автором кода, могли модифицировать эти средства для своих собственных целей, добавляя в них новые возможности.

В свое время я занимался в университете проблемами несанкционированного доступа. Так вот, сидим мы как-то втроем — я, мой руководитель, еще один студент — и обсуждаем, как происходят взломы и что можно сделать, чтобы закрыть брешь. Через пару недель становится ясно, что именно этот студент вместе со своим однокашником и занимался хакерством. Получается, что во время наших бесед мы фактически научили парня взламывать нашу защиту. Когда мы прямо спросили его об этом, он ответил, что не стал говорить о том, что он хакер, потому что хотел понаблюдать нашу реакцию, и что его единственной целью было «способствовать укреплению безопасности». Что ж, безопасность мы укрепили, но на это ушла масса времени, которое мы могли бы потратить на что-то другое. В общем, с одной стороны, мы потеряли деньги, но с другой — была и определенная польза.

Но и держать эти вещи в тайне, на мой взгляд, не всегда разумно. Рассмотрим такую крайнюю ситуацию: допустим, некая группа людей конфиденциальным образом разрабатывает программные средства, активно их отлаживает, повышает эффективность. Затем к этим средствам каким-то образом получает доступ постороннее лицо из другой, тайной группы, которая имеет преступные намерения. Итак, инструменты существуют, но о них никто не знает и никто не готов им противостоять. И вот группа злоумышленников решает с их помощью вызвать обвал фондовой биржи, нарушить работу авиадиспетчерской службы или что-нибудь в этом роде. Если все сохранять в тайне, не приведет ли это к еще более тяжелым последствиям?

Давайте вернемся к идее введения хакеров в советы директоров.

Не такое уж и безумное предложение. Корни наших проблем лежат в недостатке информации и недостатке понимания. Допустим, у вас в совете только люди, занимающиеся бизнес-планами и перспективными оценками прибылей, допустим, они провернули некий проект и получили ту прибыль, на какую и рассчитывали, и биржевые аналитики рукоплещут им.

Но если они совершенно не думают о том, что подобный ход вещей может нарушиться и надо бы позаботиться о том, чтобы никаких нарушений не было, тогда-то и происходит катастрофа: к примеру, кто-то проникает в сеть и крадет номера кредитных карточек всех клиентов. И что теперь?

Компании традиционно старались преуменьшить значение проблем безопасности и не афишировать подобные инциденты, беспокоясь за свою репутацию. Однако если все скрывать, то никто не будет знать о серьезных недочетах. Если же кто-нибудь в совете директоров скажет: «Нет, такая конструкция крайне уязвима, мы слишком рискуем, и наши акции могут резко упасть», — тогда, может, разработчики предложат другой, более защищенный вариант.

Возвращаясь к росту индустрии компьютерной безопасности, хочу добавить, что, на мой взгляд, весьма перспективным направлением в этой области станет консалтинг. Люди, вторгающиеся в чужие системы, прекрасно осведомлены о всех тонкостях своей задачи, и консультационные компании — по крайней мере хорошие компании — обладают такой же базой знаний. Если вы сможете с их помощью применить эти знания при конструировании систем электронной коммерции, построении сетевых инфраструктур, при разработке программ, это было бы весьма кстати.


Как защитить свою сеть?

Представители Para-Protect, портала, посвященного проблемам сетевой безопасности, утверждают, что 90% всех брешей в системе безопасности, которые им приходится устранять, выявляются в результате атак изнутри. Но самое неприятное то, что более чем в половине всех зарегистрированных случаев вторжения виновны сами сетевые администраторы. Итак, что же нужно делать для того, чтобы защитить сеть? Вот что советуют аналитики, специалисты по вопросам безопасности, руководители компаний и сотрудники секретных служб.

  • Убедитесь в том, что ни один человек не имеет доступа сразу ко всем функциям системы сверху донизу
  • Потребуйте от каждого пользователя ввода пароля при вхождении в систему
  • Предоставляйте права суперпользователя как можно меньшему числу людей
  • Резервную копию наиболее важных компонентов системы необходимо делать ежедневно
  • Раз в неделю делайте резервную копию всей системы
  • Установите строгий контроль за доступом к лентам с резервными копиями
  • Текущую резервную копию храните отдельно, в надежном удаленном месте
  • Регулярно копируйте информацию, хранящуюся на настольных и портативных компьютерах, а также на серверах
  • Меняйте пароли, по крайней мере, каждые три месяца
  • Разместите серверы в безопасном, недоступном для посторонних месте
  • Человек, обеспечивающий текущее функционирование системы, не должен отвечать за создание резервных копий
  • Регулярно обновляйте ПО
  • Установите ПО, позволяющее обнаружить попытку несанкционированного доступа и своевременно получить соответствующее предупреждение
  • Выделяйте на нужды безопасности не менее 3-5% бюджета информационной службы
  • Персонал группы информационной безопасности должен выявлять случаи проявления сотрудниками неуверенности или недовольства (особенно это касается тех служащих, которые имеют доступ к важным сведениям)
  • Уделяйте повышенное внимание вопросам безопасности в периоды массовых увольнений или слияния с другими фирмами. Сотрудники, раздраженные таким поворотом событий, могут предпринять действия, которые негативным образом отразятся на работе компании
  • Наладьте мониторинг сети. Специальные программные средства выдадут предупреждение в том случае, если пользователь проник в запрещенную для него область сети или работает в неположенное время
  • Установите контроль за электронной перепиской с целью выявления подозрительных внешних контактов. Проверяйте правильность и надежность создаваемых резервных копий. Возложите задачу резервного копирования еще на кого-нибудь, если сотрудник, постоянно занимающийся этими вопросами, попал под подозрение
  • При подписании контракта с сотрудником оговорите все условия работы и меры наказания, принимаемые в случае различных нарушений и невыполнения предъявляемых требований
  • Люди, занимающие ключевые посты в информационной службе, должны быть заинтересованы в укреплении позиций компании

Как защитить систему в случае увольнения сетевого администратора.

  • Контролируйте смену паролей, чтобы бывший администратор не мог использовать их для проникновения в систему
  • Следите за тем, чтобы ленты с резервными копиями хранились в установленном месте; убедитесь в том, что информация записана правильно и лента функционирует так, как положено
  • Регулярно обновляйте резервные копии
  • Блокируйте каждый компонент системы, к которому имел доступ пользователь, как только этот компонент станет ему не нужен
  • Всегда имейте на примете сетевого администратора, с которым в случае необходимости можно сразу же заключить контракт
  • Контролируйте состояние системы, проверяйте имена пользователей и пароли, выявляя все необычные ситуации
  • Убедитесь в том, что всем пользователям, имеющим доступ к системе, присвоен пароль
  • Обеспечьте безопасность важных внутренних подсистем: файл-серверов, серверов приложений и почтовых серверов
  • Своевременно выявляйте попытки несанкционированного проникновения в систему
  • При обнаружении уязвимых мест сразу устраняйте их (бывший администратор специально может оставить для себя лазейку, чтобы впоследствии воспользоваться ею)
  • Укрепляйте систему предотвращения несанкционированного доступа
  • Установите специальные программы-ловушки, уведомляющее о всех нестандартных ситуациях (например, об изменениях размеров файла)

Распределенные атаки типа «отказ в обслуживании»

В ходе распределенной атаки типа «отказ в обслуживании» атакующий удаленно управляет «мастер-сервером», на котором установлен специальный код. Мастер-сервер, в свою очередь, управляет действиями «подчиненных серверов», на которые установлен тот же код с ведома или без ведома владельца системы. По команде подчиненные серверы наводняют узлы назначения мусорным трафиком. Бомбардировка узла назначения трафиком с сотен подчиненных серверов приводит к перегрузке системы и зачастую к блокированию канала передачи данных. Впервые программа, реализующая подобную атаку, была обнаружена в ноябре 1999 года. Сейчас в Web можно найти как минимум четыре программы такого типа. Первые две — Trin00 и Tribal Flood Network (TFN), работающие в Unix. Третья и четвертая были обнаружены чуть позже — Stacheldraht (нем. «колючая проволока») и TFN2K. Последняя отличается от TFN тем, что имеет версии для Windows NT и Unix, а также тем, что использует при бомбардировке сети шифрование, чтобы более эффективно скрываться. Распределенные атаки типа «отказ в обслуживании» подразделяются на несколько видов. На данном рисунке приводится схема работы атак типа SYN Flood и ICMP (Ping).