Максимальная Безопасность:

Руководство Хакера по Защите Вашего Internet Сайта и Сети

Предыдущая главаСледующая главаСодержание

25

Удалённое Нападение

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

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

Что Такое Удалённое Нападение?

Удалённое нападение это любое нападение, которое инициализировано против машины, над которой нападающий в настоящее время не имеет контроль. То есть это нападение против любой машины, кроме машины нападающего (находится ли она в подсети нападающего или на расстоянии 10,000 миль). Лучший способ определить удалённую машину следующий:

Удалённая машина это любая машина, кроме Вашей собственной, которая может быть достигнута через некоторый протокол по Internet или любой другой сети или среде.

Первые Шаги

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

Методы, упомянутые в этом списке, могут показаться лишними, пока Вы не поймёте их значение. Конечно, Farmer и Venema договорились бы о следующем:

Что Вы должны делать? Сначала попытайтесь собрать информацию о вашем (целевом) узле. Есть масса сетевых служб для просмотра: finger, showmount и rpcinfo хорошая отправная точка. Но не останавливайтесь на этом, Вы должны также использовать DNS, whois, sendmail (smtp), ftp, uucp, и так много других служб как Вы сможете найти.
Ссылка: Предыдущий параграф это выдержка из Improving the Security of Your Site by Breaking Into It ("Улучшение Безопасности Вашего Сайта Вторжением В Него") от Dan Farmer и Wietse Venema. Это может быть найдено в онлайне на
http://www.craftwork.com/papers/security.html.

Сбор информации о системном администраторе первостепенен. Системный администратор обычно ответствен за поддержание безопасности сайта. Есть случаи, когда системный администратор сталкивается с проблемами, и многие из их не могут сопротивляться желанию послать сообщение в Usenet или списки рассылки, чтобы получить ответы на свои проблемы. Через некоторое время, когда Вы получите адрес администратора (и любую его вариацию, как я буду объяснять в следующем разделе), то сможете получить большее понимание его сети, его безопасность и его личности. Администраторы, которые делают такие послания, обычно определяют свою архитектуру, немного о сетевой топологии и заявленную проблему.

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

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

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

Обратите внимание, что я упомянул "любая вариация" адреса системного администратора. Вариация в этом контексте означает любые возможные альтернативные адреса. Есть два вида альтернативных адресов. Первый вид это персональный адрес человека. То есть многие системные администраторы могут также иметь адреса в других сетях, не их собственной. (Некоторые администраторы настолько глупы, что включают эти адреса в поля, предусмотренные для записи адресов InterNIC.) Так что, в то время как они не могут использовать свой рабочий адрес, чтобы обсудить (или узнать о) безопасность, весьма возможно, что они могут использовать свой домашний адрес.

Для демонстрации, я когда-то взломал сеть, расположенную в Калифорнии. Администратор сайта имел учётную запись в AOL. Учётная запись в AOL использовалась в Usenet, чтобы обсуждать различные проблемы безопасности. По следующим сообщениям этого человека в Usenet, я смог определить весьма немного. Фактически (и это истинно экстраординарно), его пароль, как я узнал, был именем его дочери, сопровождаемым числом 1.

Другой пример вариации адреса следующий: идентичный адрес или адрес, назначенный на то же самое имя человека на любой машине в пределах его сети. Теперь давайте скажем это немного более ясно. Во-первых, в сети, которая умело управляется, никакое имя не связано с корнем. Это так, потому что корень должен использоваться так мало, насколько это возможно, и рассматриваться как системный ID, который не вызывается пока не станет абсолютно необходимым. (Другими словами, так как существует su и возможно другие команды или устройства, которые позволяют администратору делать свою работу, корень не должен вызываться непосредственно, кроме ограниченного числа случаев.)

ПРИМЕЧАНИЕ: Нападение на сеть, выполняющую Windows NT, другой вопрос. В этом случае Вы заботитесь о корне (или скорее, Администраторе) на каждой машине. Дизайн NT делает это необходимостью, и Администратор в NT значительно отличается от корня на машине UNIX.

Поскольку корень вероятно не вызывается непосредственно, ID системного администратора может быть все что угодно. Давайте предположим здесь, что Вы знаете этот ID. Допустим, что это walrus. Позвольте предположить далее, что запрос host, который Вы провели, дал около 150 машин. Каждая из этих машин имеет различные имена. Например, может быть mail.victim.net, news.victim.net, shell.victim.net, cgi.victim.net и т.д. (Хотя, на практике, они будут более вероятно иметь тематические имена, которые делают неясным то, что фактически делает машина, подобно sabertooth.victim.net, bengal.victim.net и lynx.victim.net.)

Взломщик должен пробовать адрес администратора на каждой машине. Таким образом, он будет пробовать walrus@shell.victim.net, walrus@sabertooth.victim.net и т.д. (Это то, к чему я ссылаюсь как вариация адреса администратора цели.) Другими словами, испытание его на каждой машине в сети то же, что и выполнение всего общего диагностического материала на каждой из этих машин. Возможно walrus имеет конкретную машину, которую он опекает, и именно с этой машины он посылает свои сообщения.

Есть интересное примечание: Если адресат поставщик (или другая система, к которой можно сначала получить законный доступ), Вы можете также получить огромное количество информации о системном администраторе просто наблюдая где он входит. Это, до некоторой степени, может быть также сделано с внешней стороны, комбинацией finger и rusers. Другими словами, Вы идентифицируете внешние сети (то есть сети отличные от адресата) в которых системный администратор имеет учётные записи. Очевидно, если его последний вход в систему был с Netcom, он имеет учётную запись в Netcom. Следуйте за этим ID в течение дня, или около того, и смотрите что происходит.

О Finger Запросах

В предварительно упомянутом документе от Farmer и Venema (феноменальный и революционный документ с точки зрения понимания темы), пропущен один момент: использование утилиты finger может быть опасным раскрытием ваших действий. Что если системный администратор выполняет MasterPlan?

СОВЕТ: MasterPlan это утилита, описанная мной в Главе 13, "Техника Сокрытия Личности". Её функция состоит в перехвате и регистрации всех finger запросов, направленных пользователю. То есть MasterPlan определяет IP стороны, делающей finger апрос, время, в которое такой запрос имел место, частоту запроса и т.д. Она в основном пытается собрать так много информации о человеке, посылающем finger запрос к Вам, насколько это возможно. Также, не обязательно, что системный администратор использует MasterPlan. Он мог бы легко написать собственный демон finger, который возможно даже отслеживает маршрут к стороне, выдавшей запрос, или ещё хуже, выдает к ней finger запрос.

Чтобы избежать возможности таких finger запросов большинство взломщиков используют finger шлюзы. Finger шлюзы это Web страницы, которые обычно содержат единственное поле ввода, которое указывает на CGI программу на диске удалённого сервера, который выполняет функции finger поиска. На Рисунке 25.1 я показал пример одного такого finger шлюза. (Он расположен в Университете Медицинского Центра в Мичиган.)

Рисунок 25.1. Пример finger шлюза в Университете Мичигана.

Используя finger шлюз взломщик может скрыть свой исходный адрес. То есть finger запрос инициируется удалённой системой, которая является finger шлюзом. (Другими словами, не собственной машиной взломщика, а некоторой другой.) Правда, чрезвычайно параноидальный системный администратор мог бы проследить исходный адрес этого finger шлюза. Он мог бы даже связаться с администратором сайта finger шлюза, чтобы взглянуть на log-файл доступа к нему. Таким образом, он мог бы определить сторону, выдавшую finger запрос. Но такой поворот событий мало вероятен, особенно, если взломщик ломает свои шлюзы. Другими словами, если взломщик намеревается проделать свою работу "вручную", он действительно должен сделать каждый finger запрос с различного шлюза. Поскольку в настоящее в Web имеется более 3,000 finger шлюзов, его чрезвычайно трудно обнаружить. Кроме того, если бы я делал запросы, то выдавал бы их обособленно через несколько минут (или в идеале, несколько часов).

ПРИМЕЧАНИЕ: Одна методика включает переназначение finger запроса. Это когда взломщик выдает необработанный finger запрос к одному finger серверу, требуя информацию от другого. Это упоминается как перенаправление finger запроса. Синтаксис такой команды следующий: finger пользователь@реальный_ адресат.com@некоторый_другой_узел.com. Например, если Вы хотите выдать finger запрос для пользователя в primenet.com, то чтобы перенаправить запрос можно использовать службу finger deltanet.com. Однако, на сегодняшний день, большинство системных администраторов выключают перенаправление finger.

Операционная Система

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

Чем более разнообразны ваши сетевые узлы (с точки зрения операционной системы и архитектуры), тем более вероятно, что дыра в безопасности существует. Для этого есть причины, и хотя я не намереваюсь объяснять их полностью, но все же скажу следующее: Любая операционная система имеет собственный набор ошибок. Некоторые из этих ошибок известны, а некоторые могут быть обнаружены через какое-то время. В относительно большой сети, где могут иметься много различных типов машин и программного обеспечения, Вы имеете больший шанс обнаружить дыру. Системный администратор, в конце концов, всего лишь человек. Он не может постоянно просматривать консультации по безопасности для каждой платформы. Существует большая вероятность, что его знания безопасности той или иной системы слабы.

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

ПРИМЕЧАНИЕ: Некоторые аналитики могут сказать, что утилиты подобные ISS и SATAN идентифицируют все такие дыры автоматически и, следовательно, потребность в исследовании отсутствует. Это ошибочно, по нескольким причинам. Во-первых, такие утилиты не могут провести полную оценку. Вот почему: Хотя обе из упомянутых утилит весьма исчерпывающие, они не совершенны. Дыры появляются каждый день для широкого разнообразия платформ. Правда, обе утилиты расширяемы и можно, поэтому, добавлять новые модули сканирования, но утилиты сканирования, которые Вы имеете, ограничены знанием дыр программистом, которые существовали во время написания приложения.

Поэтому, чтобы сделать новый модуль сканирования, который будет добавлен к этим расширяемый и гибким приложениям, Вы должны сначала знать, что такие новые дыры существуют. Во вторых, и возможно более важно, просто знание, что дыра существует, не обязательно подразумевает, что Вы можете эксплуатировать ее. Вы должны сначала понять ее. (Если, конечно, дыра не очевидна и не требует объяснений, типа проблемы rlogin -froot в некоторых версиях операционной системы AIX. Инициализируя сессию rlogin с флагом -froot, Вы можете получить мгновенный привилегированный доступ на многие старые основанные на AIX машины.) По этим соображениям выполнение объёмного сканирования является преждевременным.

Чтобы собрать эту информацию, Вам необходимо посетить несколько ключевых сайтов. Первый такой сайт, который Вы должны посетить, страница архива списка рассылки по брандмауэрам.

Ссылка: Страница архива списка рассылки по брандмауэрам может быть найдена в онлайне на
http://www.netsys.com/firewalls/ascii-index.html.

Вы можете первоначально задаться вопросом, почему этот список так ценен? Потому что обсуждаемая тема связана с брандмауэром. (Помните, мы начали эту главу с предположения, что адресат не выполняет брандмауэр.) Архив списка по брандмауэрам ценен, потому что он часто используется, что осуждают многие члены списка, чтобы обсудить другие связанные с защитой проблемы. Другой неоценимый источник таких данных BUGTRAQ, который является доступным для поиска архивом известных уязвимостей в различных операционных системах (хотя в значительной степени в UNIX.)

Ссылка: BUGTRAQ расположен в онлайне на
http://www.geek-girl.com/bugtraq/search.html.

Эти доступные для поиска базы данных имеют первостепенную важность. На этом этапе нам может помочь практический пример. Предположим, что ваш адресат это машина, выполняющая AIX. Сначала, Вы должны направиться в ARC Searchable WAIS Gateway для консультаций CERT и DDN.

Ссылка: ARC Searchable WAIS Gateway для консультаций DDN и CERT может быть найден в онлайне на
http://info.arc.com/sec_bull/sec_bullsearch.html.

Рисунок 25.2 показывает, как на этом сайте сконфигурирован шлюз WAIS.

Рисунок 25.2. Шлюз WAIS на ARC.COM для поиска консультаций по безопасности.

Снизу этой страницы есть поле ввода. В него я ввёл искомый термин AIX. Результатом этого поиска был черновой список уязвимостей AIX. (Смотрите Рисунок 25.3.)

Рисунок 25.3. Черновой список уязвимостей AIX от шлюза WAIS.

На этом этапе Вы можете начинать проводить некоторое исследование. После прочтения начальной консультации, если нет больше информации, чем простое описание уязвимости, не отчаивайтесь. Вы всего лишь должны перейти к следующему уровню. Следующая фаза немного более сложная. После идентификации самой последней слабости (и прочтения консультации), Вы должны извлечь из этой консультации (и все что следует из неё) обычно используемое, часто сокращённое, или "жаргонное" название дыры. Например, после того, как дыра обнаружена, она часто упоминается людьми безопасности с названием, которое может не отражать всю проблему. (Примером может служить "проблема telnetd в Linux" или "дыра froot в AIX" или некоторый другой, краткий термин, которым универсально определяется дыра.) Процесс извлечения делается быстро, беря идентификационный номер консультации и пропуская его через один из вышеупомянутых архивов, подобно BUGTRAQ или Firewalls. Вот почему:

Как правило, когда профессионал безопасности посылает сообщение со сценарием эксплуатации, сценарием тестирования (проверяющим, существует ли дыра) или комментарием, они будут почти всегда включать полную ссылку на первоначальную консультацию. Таким образом, в их сообщении Вы увидите что-то подобное: Есть сценарий проверки, уязвимы ли Вы для проблеме talkd, обсуждаемую в CA-97.04.

Это сообщение ссылается на Консультации CERT под номером 97.04, которая первоначально была выпущен 27 января, 1997. Используя этот номер как выражение поиска, Вы найдёте все ссылки на него. После прочтения 10 или 12 результатов такого поиска, Вы будете знать то, что толпа безопасности называет этой дырой. После того, как Вы сделаете это, можно провести поиск всеми средствами во всех легальных и нелегальных источниках баз данных, чтобы получить любой клочок информации о дыре. You are not looking for initial postings in particular, but subsequent, trailing ones. (Некоторые архивы имеют опцию, которой Вы можете определить отображение по потокам, что предпочтительно. Это позволяет Вам видеть начальное сообщение и все последующие сообщения относительно первоначального сообщения, то есть все "re:" продолжения.) Однако, некоторые механизмы поиска не предусматривают вывод в связанной форме, поэтому Вы будете просто должны продираться через них вручную.

Причина, по которой Вам необходимы эти продолжения, заключается в том, что они обычно содержат сценарии эксплуатации или проверки (программы, которые автоматически проверяют или моделируют дыру). Они также обычно содержат другую техническую информацию, связанную с дырой. Например, должностное лицо безопасности могло бы найти новый способ реализации уязвимости, или могло бы обнаружить, что связанная программа (или файл для включения или другая зависимость) может быть реальной проблемой или даже большим вкладом в дыру. Мысли и размышления этих личностей чистое золото, особенно, если дыра новая. Эти личности фактически делают всю работу за Вас: анализируя и тестируя дыры, усовершенствуя нападения против них и т.д.

СОВЕТ: Многие сценарии эксплуатирования и проверки пишутся на языках стандартных оболочек или C и, поэтому, легки в реконфигурации для вашей собственной системы или компиляции для вашей архитектуры. В большинстве случаев должна быть произведена только минимальная работа, чтобы сделать их работоспособными на вашей платформе.

И так, к этому моменту Вы определили часть (или возможно все) из следующих основных пунктов:

Теперь Вы можете перейти к следующему шагу.

Один момент, представляющий интерес: Чрезвычайно ценно, если Вы можете также идентифицировать машины, которые могут быть со-расположены. Это, конечно, строго в случаях, когда адресат поставщик услуг Internet (ISP). ISP часто предлагают клиентам расположить машину на их проводе. В этом для клиента есть некоторые преимущества. Одно из них стоимость. Если поставщик предлагает расположить машину в его T3 за, скажем, $600 в месяц, это существенно менее дорого, чем содержание машины в вашем собственном офисе, которая подключена к T1. T1 стоит приблизительно $900-$1,200 ежемесячно. Вы можете видеть, почему со-расположение популярно: Вы получаете гораздо большую скорость за намного меньшие деньги и головную боль. Для ISP, это не более чем подключение машины к его Ethernet системе. Поэтому, даже затраты на установку и администрирование более низкие. И, возможно наиболее важно для всех, не требуется местной телефонной компании. Таким образом, Вы сохраняете ещё больше денег, и можете установить сервер немедленно вместо того, чтобы ожидать шесть недель.

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

ПРИМЕЧАНИЕ: Это может быть определено, до некоторой степени, используя службы traceroute или whois. В случае с traceroute Вы можете идентифицировать позицию машины на проводе, исследуя путь прослеженного маршрута. В запросе whois Вы можете видеть имеет ли машина собственный доменный сервер или использует какой-то другой (ISP).

Выполнение Тестирования

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

Этот шаг включает установку отдельной машины с таким же дистрибутивом, как и у адресата. Таким образом, если бы адресатом была SPARCstation 2, выполняющая Solaris 2.4, Вы бы установили идентичную машину и подключили ее к Сети любым подходящим методом (через модем, ISDN, Frame Relay, T1, или через что-то другое, доступное Вам). После того, как Вы установили машину, выполните ряд нападений против неё. Есть две вещи, которые Вам необходимо получить:

Есть множество причин для этого, и некоторые не настоль очевидны. Изучая log-файлы на стороне нападения взломщик может извлечь пользу обнаружив, на что должно быть похоже нападение, если его цель в основном незащищена, другими словами, если цель не выполняет заказных демонов. Это обеспечивает взломщика небольшой дорожной картой. Конечно, если его окончательное сканирование и нападение на цель не выглядят не похоже, это причина для беспокойства. Все должно быть идентичным. Идентично сконфигурированные машины (или, Я должен сказать, очевидно идентично конфигурированные машины) должны отвечать идентично. Если этого не происходит, люди в адресате имеют что-то в рукаве. В этом случае взломщик был бы мудр, если бы все тщательно обдумал.

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

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

Этот шаг не столь дорог, как Вы могли бы подумать. Есть группы новостей (особенно misc.forsale.computers.workstation) где можно получить идентичную машину (или близкую копию) за разумную цену. Обычно продавец такой машины загружает полную версию операционной системы "только для целей тестирования". Они говорят так: "Я дам Вам операционную систему, которая не имеет лицензии и поэтому нарушает лицензионное соглашение. Если Вы сохраните ее и позже вызовите резкую критику от поставщика, это ваши проблемы".

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

Другие возможности включают друзей, имеющих такую машину на их рабочем месте или даже в университете. Все, в чем Вы действительно нуждаетесь, это log-файлы. Я всегда думал, что было бы хорошей практикой изучения поддержание базы данных таких log-файлов по операционным системам, по нападениям и по сканерам, другими словами, иметь библиотеку того, что напоминают такие нападения, учитывая вышеупомянутые переменные. Это, я думаю, был бы хороший ресурс для обучения новых системных администраторов. Кое-что вроде "Вот что напоминает SS4, когда атакована с использованием ISS. Вот log файлы, которые Вы должны искать, и вот как они будут появляться".

Конечно, может быть создан сценарий (возможно автоматизированный), который выполнит сравнительный анализ файлов на вашей рабочей станции. Этот процесс может проводится один раз в день как cron задание. Мне кажется, что, по крайней мере, минимальные системы обнаружения атак могут быть разработаны таким способом. Такие утилиты существуют, но критиковались многими личностями, потому что они могут быть слишком легко "введены в заблуждение". Есть превосходный документ, который рассматривает эту тему, по крайней мере относительно SunOS. Он озаглавлен USTAT: A Real Time Intrusion Detection System for UNIX (USTAT: Система Обнаружения Атак Реального Времени Для UNIX). (Этот документ был, фактически, диссертацией для получения магистра по информатике в Университете Santa Barbara, Калифорния. Он очень хорош.) В реферате автора написал:

В этом документе описана разработка первого прототипа USTAT для SunOS 4.1.1. USTAT использует контрольные следы, которые собираются C2, Основным Модулем Безопасности SunOS, и она следит только за теми критическими действиями, которые должны произойти для успешного завершения проникновения. Этот подход отличается от других основанных на правилах утилит идентификации проникновения, которые создают последовательности соответствия контрольных записей.
Ссылка: Предыдущий параграф это выдержка из USTAT: A Real Time Intrusion Detection System for UNIX от Koral Ilgun. Документ может быть найден в онлайне на
ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/ustat.ps.gz.

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

Другой интересный документ перечисляет несколько из этих утилит и делает краткий анализ каждой из них. Он обсуждает как

Должностные лица компьютерной безопасности на системном уровне всегда имели сложную задачу, когда проводили ежедневную ревизию мэинфрейма. Обычно опции/возможности ревизии ограничены операционной системой мэинфрейма и другим системным программным обеспечением, установленным поставщиком аппаратного обеспечения. Также, так как ревизия безопасности это логическое подмножество ревизии управления, некоторые из доступных опций/возможностей ревизии могут иметь небольшое значение для должностных лиц компьютерной безопасности. Наконец, необходимая информация ревизии вероятно слишком пространна для обработки вручную и очень ограниченно пригодна для автоматизированных утилит анализа/уплотнения данных. Как правило, 95% контрольных данных не имеет никакого значения для безопасности. Нужно схитрить, чтобы определить, что из 95% игнорировать.
Ссылка: Предыдущий параграф это выдержка из Summary of the Trusted Information Systems (TIS) Report on Intrusion Detection Systems (Резюме Отчёта Доверенных Информационных Систем (TIS - Trusted Information Systems) в Системах Обнаружения Атак), подготовленный Victor H. Marshall, Руководителем Группы Systems Assurance, Booz, Allen & Hamilton Inc. Этот документ может быть найден в онлайне на
ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/auditool.txt.Z

В любом случае, эта "живая" методика тестирования должна прежде всего использоваться, когда есть единственная точка нападения. Типичные ситуации заключаются в том, когда Вы подозреваете, что одна из рабочих станций наиболее интересная цель (когда возможно другие отказываются от всех подключений извне подсети и т.д.). Очевидно, я не предполагаю, чтобы Вы установили точную модель целевой сети. Это может быть невозможным по стоимости и времени. Я предлагаю, что в координации удалённого нападения Вы должны иметь (как минимум), некоторую идею того, что может случиться. Моделирование такого нападения на узел отличный от адресата, мудрая вещь. Иначе, нет никакой гарантии, что данные, которые Вы получите назад, будут иметь некоторую целостность. Документ Bellovin на Berferd должен быть предупреждением любому взломщику о том, что моделирование уязвимой сети не выходит за рамки вопроса. Фактически, я задавался вопросом много раз, почему технологии безопасности не сосредоточились полностью на этом типе методики, тем более, что сканеры стали настолько популярными.

На сколько трудно системному администратору создать такую систему на лету? Насколько трудно ему написать заказные демоны (в системе, где целевые службы фактически даже не выполняются), которые обеспечили бы взломщика поддельными ответами? Не лучше ли это, чем объявление того, что Вы имеете брандмауэр (или TCP_WRAPPER), следовательно, подготавливая нападающего к потенциальным проблемам? Не берите в голову пассивные утилиты сканирования портов, давайте перейдём к практически важным вопросам: Как захватить взломщика системой, разработанной исключительно с целью создания log-файлов, которые демонстрируют намерение? Это, по моему мнению, место, где должны быть сделаны некоторые новые усовершенствования. Такие типы систем предлагают автоматизацию процесса сбора доказательств.

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

В течение 20 дней в начале весны 1994, киберсыщики Воздушных Сил преследовали цифрового преступника, совершающего набеги на неопределённые компьютерные системы в Griffiss AFB, Нью Йорк. Исследователи наблюдали сцену преступления в маленькой 12 на 12 футов компьютерной комнате в Центре Авиа Разработок Лаборатории в Риме в течение недель, живя на коле, полуфабрикатах и спя под столами. Чтобы захватить бандита в действии Информационным Военным Центром Воздушных Сил были установлены западни, и "тихие" тревоги звучали каждый раз, как их человек ускользал назад, чтобы просмотреть свою работу. Подозреваемый, который дублировал для себя "Поток Данных", был невидим для наблюдения, но несмотря на его нескольких раз преследовали на скорости, которая не намного быстрее, скорость света. Бандит был компьютерным хакером, проносящимся по эфирным маршрутам Internet, и хвостом его был информационный патруль супермагистрали - Офис Воздушных Сил Специальных Исследований подразделения исследования компьютерных преступлений.
Ссылка: Предыдущий параграф это выдержка из "Hacker Trackers: OSI Computer Cops Fight Crime On-Line" ("Охотники на Хакеров: Компьютерные Полицейские OSI Борются с Преступностью в Онлайне") от Pat McKenna. Документ может быть найден в онлайне на
http://www.af.mil/pa/airman/0496/hacker.htm.

Документ не даёт много технической информации, как хотелось бы, но он все равно весьма интересен. Вероятно более практический документ с легальной информацией по исследованию вторжений озаглавлен "Investigating and Prosecuting Network Intrusions" ("Исследование и Преследование По Суду Сетевых Вторжений"). Он был написан John C. Smith, Старшим Исследователем в Подразделении Компьютерных Преступлений Офиса Окружного Прокурора Округа Santa Clara.

Ссылка: "Investigating and Prosecuting Network Intrusions" может быть найден в онлайне
http://www.eff.org/pub/Legal/scda_cracking_investigation.paper.

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

Утилиты: О Дырах и Других Важных Свойствах

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

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

Чтобы определить точный результат того, как все эти утилиты будут работать совмество, лучше провести тест по крайней мере на некоторой машине (даже если она не идентична цели). Это потому что здесь мы обеспокоены тем, будет ли сканирование так или иначе прервано или разрушено, как результат выполнения двух или более модулей, не входящих в проект. Помните, что нападение сканированием в реальном масштабе времени должно быть сделано только однажды. Если Вы испортите его, то не сможете получить второй шанс.

И так, Вы будете выбирать утилиты (по крайней мере для сканирования) основываясь на том, что можете найти на другом конце. В некоторых случаях это простое задание. Например, возможно Вы уже знаете, что кто-то на машине выполняет приложения Системы X Window по Сети. (Невероятно, но не неслыханно.) В этом случае, Вы будете также сканировать на проблемы xhost, и все, что из них вытекает.

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

СОВЕТ: Есть некоторые меры, которые Вы можете предпринять, чтобы избежать объявления, но они решительны: Вы можете фактически установить те же самые процедуры безопасности, какие есть в других сетях, включая установку программного обеспечения (иногда брандмауэра, а иногда нет), которое откажется сообщать сведения о вашей машине адресату. Есть серьёзные проблемы с таким типом методики, поскольку она требует высокого уровня навыков. (Также, многие утилиты будут бесполезны с таким методом. Некоторые утилиты разработаны так, что одна или более функций требуют способности выйти из вашей сети через маршрутизатор, и снова зайти назад.)

Снова, мы предполагаем здесь, что цель не бронирована. Это только средний сайт, что означает, что мы не должны говорить слишком много о сканировании. Кроме того, как недавний предлагает обзор Dan Farmer'а, сканирование не может быть существенной проблемой. Согласно Farmer (и я верю его словам, зная из персонального опыта, что он человек чести), большинство сетей даже не обращают внимание на трафик:

... не было сделано никаких попыток, чтобы скрыть обзор, но только три сайта из более чем двух тысяч вошли со мной в контакт, чтобы спросить, что происходило, когда я выполнял неавторизованный обзор (примерно один из тысячи спросил меня о моей деятельности). Два были из обычного списка обзора, и один был из случайной группы.
Ссылка: Предыдущий параграф это выдержка из введения Shall We Dust Moscow? (Мы Будем Чистить Москву?) от Dan Farmer. Этот документ может быть найден в онлайне на
http://www.trouble.org/survey/introduction.html

Это сканирование вовлекло более 2,000 узлов, большинство из которых были довольно чувствительными сайтами (например, банками). Вы ожидали, что эти сайты будут ультра-параноидальны, фильтруя каждый пакет и немедленно переходя на даже самую маленькую подсказку о сканировании.

Разработка Стратегии Нападения

Дни, когда взломщики передвигались по Internet, взламывая тот или иной сервер, в основном прошли. Годы назад, компрометация безопасности системы рассматривались как незначительное нарушение, пока не было сделано никакого ущерба. Сегодня ситуация совершенно другая. Сегодня значение данных становится все более и более значимой проблемой. Поэтому, современный взломщик был бы мудр, если бы не взламывал без причины. Точно так же он был бы мудрым, чтобы взламывать сервера только с конкретным планом.

Единственный случай, к которому это не применяется, когда взломщик расположен в иностранном государстве, которое не имеет определённого закона против компьютерного вторжения (снова Berferd) или в государстве, которое не поддерживает процедуру выдачи для этого конкретного нарушения (например, случай с NASA, вовлекающий студента из Аргентины). Все другие взломщики были бы мудры, если бы шагали очень осторожно.

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

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

ПРИМЕЧАНИЕ: Конечно, если эти машины (по любым причинам) единственные доступные, во что бы то ни стало нападите на них (если они хотя бы что-то стоящи). Например, общая процедура это размещения Web сервер вне сетевого брандмауэра или определение машины единственной доступной из пустоты. Если цель упражнения не состоит в том, чтобы взломать Web сервер (и вызвать некоторое ограниченное, общественное затруднение для владельцев Web машины), чему беспокоиться? Эти машины типичные "жертвенные" узлы, то есть системный администратор ожидает потерять всю машину от удалённого нападения, так что машина ничего не импортирует на свои диски. Ничего кроме Web страниц.

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

Слово о Синхронизации Сканирований

Когда Вы должны осуществлять сканирование? Ответ на это вопрос "никогда". Однако, если бы я собирался сделать сканирование, то сделал бы его поздно вечером относительно цели. Поскольку оно, так или иначе, собирается выполнять запросы на подключение (и так как требует намного больше времени, если осуществляется в течение периодов с высоким трафиком), я думаю, что Вы могли бы также воспользоваться преимуществом ночной смены. Чем короче период времени, тем лучше для Вас.

После Сканирования

После того, как завершили сканирование, Вы будете подвергать данные анализу. Первая проблема, которая встанет перед Вами, является ли информация подлинной. (Это, до некоторой степени, устанавливается типовыми сканированиями на подобной машине с подобным дистрибутивом операционной системы.)

Анализ это следующий шаг. Он меняется в зависимости от того, что Вы нашли. Конечно, документы, включенные в дистрибутив SATAN, могут чрезвычайно помочь в этом отношении. Эти документы (справочные документы по уязвимостям) кратки, но ясны и информативны. Они обращаются к следующим уязвимостям:

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

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

Здесь будет сделано важное отступление. Говорим ли мы о личностях, подобно Kevin Mitnik, (взломщик) или людях, подобно Weitse Venema (хакер), не имеет большого значения. Их работа и их достижения обсуждались в различных журналах новостей и онлайновых форумах. Они знаменитости в безопасности Internet (и в некоторых случаях вне ее). Однако их достижения (хорошие или плохие) результат тяжёлой работы, изучения, изобретательности, мысли, воображения и самопожертвования. Таким образом, никакой брандмауэр не сохранит администратора в безопасности, который не знает что это такое, и при этом SATAN не поможет новоявленному взломщику незаконно нарушить безопасность удалённой цели. Это результат работы.

Итог

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

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

Одно интересное явление состоит в увеличении утилит для нападения на машины Windows NT. Это не только утилиты сканирования, но и перехватчики, граберы паролей и взломщики паролей. В отношении утилит удалённого нападения, лучший инструмент, доступный для NT это SAFEsuite от Систем Безопасности Internet (ISS - Internet Security Systems). Она содержит широкое разнообразие утилит, хотя большинство их было разработано для внутреннего анализа безопасности.

Например, рассмотрим Intranet Scanner, который оценивает внутреннюю безопасность сети, связанной с сервером Microsoft Windows NT. Обратите внимание, что я только написал связанной с сервером NT. Это не подразумевает, что все машины в сети должны выполнять NT, чтобы Intranet Scanner работал. Скорее, он разработан, чтобы оценивать сеть, которая содержит узлы с различными архитектурами и операционными системами. Так, Вы можете иметь машины, выполняющие Windows 95, UNIX, или потенциально другие операционные системы, выполняющие TCP/IP. Заголовок документа "Security Assessment in the Windows NT Environment: A White Paper for Network Security Professionals" ("Оценка Безопасности в Среде Windows NT: Белая Книга для Профессионалов Сетевой Безопасности"). Он обсуждает многие возможности линии продуктов и в общих чертах безопасность Windows NT.

Ссылка: Чтобы получить больше представления о том, что предлагает Intranet Scanner, проверте
http://eng.iss.net/prod/winnt.html.

Специфические пути описание определённых операционных систем (как в секции "How To" - "Как ...") выходят за рамки этой книги, не потому что я не знаю, а потому что оно может занять большой объём информации. Чтобы давать Вам точку отсчёта, рассмотрите следующее: Австралийский Контрольный Список Безопасности UNIX CERT (AUSCERT) состоит по крайней мере из шести страниц печатной информации. Информация чрезвычайно сокращена и трудна для понимания любым, кто плохо сведущ в UNIX. Если бы AUSCERT расширила его в детальное описание и справочный документ, вероятно получилась бы книга с 400 страницами, даже если формат содержал бы простые заголовки типа Демон, Дыры, Исходник, Воздействие, Платформа, Примеры, Исправление и так далее. (Такой документ, между прочим обсуждаемый в другом месте в этой книге, является окончательным списком уязвимостей безопасности UNIX. Он подробно описан в Главе 17, "UNIX: The Big Kahuna".)

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

Я знаю это, хотя это не имеет никакого отношения к деньгам. Есть взломщики, ориентирующиеся на деньги, и они профессионалы. Но взломщик любитель делает это из любопытства, так много таланта и так немного здравого смысла. Это действительно экстраординарно по одной невероятной причине: именно взломщики породили большинство утилит из этой книги. Их действия подвигли более традиционные (и более талантливые) вычислительные сообщества программировать специальные приложения безопасности. Поэтому, существование специализированных утилит действительно памятник сообществу взломщиков. Они имели существенное воздействие, и одним таким воздействием была разработка удалённого нападения. Методика не только существует из-за этих любопытных людей, но также и растёт в сущности из-за них.

Предыдущая главаСледующая главаСодержание


Macmillan Computer Publishing USA

Macmillan Computer Publishing.


Все мессаги сюда:yanich@inbox.ru
Hosted by uCoz