Windows 2000 поддерживает несколько протоколов, которые позволяют убедиться в том, что входящий в систему пользователь действительно имеет здесь свою учетную запись. Среди них – протоколы аутентификации удаленных подключений и протоколы аутентификации пользователей, входящих в сеть через Интернет. Однако внутри доменов Windows 2000 для проверки пользовательских данных предусмотрено два метода:
· Kerberos версия 5. Протокол Kerberos 5 является стандартным средством аутентификации сетевых пользователей в домене Active Directory на всех компьютерах с операционной системой Windows 2000.
· Windows NT LAN Manager (NTLM). Устаревший протокол аутентификации. Протокол NTLM применялся в качестве стандартного средства сетевой аутентификации в операционной системе Windows NT® 4.0. В среде Windows 2000 он используется для аутентификации серверов и доменов Windows NT 4.0, а также компьютеров под управлением Windows 3.11, Windows 95, Windows 98. Кроме того, NTLM применяется для локальной аутентификации на автономных компьютерах, работающих под управлением Windows 2000.
· Более эффективная (однократная) аутентификация на серверах. При аутентификации по протоколу NTLM серверу приложений приходится подключаться к контроллеру домена при проверке каждого клиента. С Kerberos такая необходимость отпадает – здесь аутентификация производится за счет проверки удостоверения, представленного клиентом. Индивидуальное удостоверение клиент получает от контроллера единожды, после чего может неоднократно использовать его на протяжении всего сеанса работы в сети.
· Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицировать своих клиентов, однако не предусматривает верификации сервера ни клиентами, ни другими серверами. Этот протокол разрабатывался для сетей, в которых все серверы считаются легитимными. В отличие от него, Kerberos такого допущения не делает, поэтому проверяет обоих участников сетевого подключения, каждый из которых в результате может точно узнать, с кем поддерживает связь.
· Делегированная аутентификация. Когда клиент сети Windows обращается к ресурсам, службы операционной системы, прежде всего, производят его идентификацию. Во многих случаях для выполнения этой операции службе достаточно информации на локальном компьютере. Как NTLM, так и Kerberos обеспечивают все данные, необходимые для идентификации пользователя на месте, однако иногда их бывает недостаточно. Некоторые распределенные приложения требуют, чтобы при подключении к серверным службам на других компьютерах идентификация клиента производилась локально службой самого этого клиента. Решить проблему помогает Kerberos, где предусмотрен специальный механизм представительских билетов, который позволяет на месте идентифицировать клиента при его подключении к другим системам. В протоколе NTLM такая возможность отсутствует.
· Упрощенное управление доверительными отношениями. Одно из важных достоинств взаимной аутентификации по протоколу Kerberos состоит в том, что доверительные отношения между доменами Windows 2000 по умолчанию являются двусторонними и транзитивными. Благодаря этому в сетях с множеством доменов не придется устанавливать много явных доверительных отношений. Вместо этого все домены большой сети можно свести в дерево транзитивных отношений взаимного доверия. Удостоверение, выданное системой безопасности для любого домена, может приниматься во всех ветвях дерева. Если же сеть содержит несколько деревьев, то удостоверение любого из них будет приниматься по всему «лесу».
· Совместимость. В основу своей реализации протокола Kerberos корпорация Microsoft положила стандартные спецификации, рекомендованные группой IETF. Благодаря такому подходу удалось обеспечить аутентификацию клиентов Windows 2000 во всех сетях, которые поддерживают Kerberos 5. Следует заметить, что протокол Kerberos был создан в Массачусетском технологическом институте в рамках проекта Athena. Однако общедоступным этот протокол стал лишь после появления версии 4. После того, как специалисты отрасли изучили новый протокол, его авторы разработали и предложили пользователям очередную версию – Kerberos 5, которая и была принята в качестве стандарта IETF, описанного в RFC 1964.
Протокол аутентификации Kerberos основывается на протоколе Нидхэма-Шредера.
В Windows 2000 нашли применение расширения протокола Kerberos, упрощающие начальную аутентификацию клиентов. Обычно для этой цели используются секретные ключи, которыми должны заранее обменяться между собой участники сеанса, но теперь такую процедуру можно провести с помощью открытых ключей. Благодаря этому появилась возможность интерактивной регистрации пользователя с помощью микропроцессорных карточек. В основу расширений, обеспечивающих аутентификацию с открытым ключом, положена спецификация PKINIT.
Роль посредника в Kerberos здесь играет так называемый центр распределения ключей Key Distribution Center (KDC). KDC представляет собой службу, работающую на физически защищенном сервере. Она ведет базу данных с информацией об учетных записях всех главных абонентов безопасности (security principal) своей области (области Kerberos в сетях Windows 2000 соответствует домен). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Данный ключ, который называют долговременным, используется для инициирования связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.
Прежде всего, Алиса входит в сеть, для чего вводит свое пользовательское имя и пароль. Клиент Kerberos, установленный на ее рабочей станции, преобразует пароль в криптографический ключ (пропускает указанный пользователем пароль через функцию хеширования, все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5) и сохраняет полученный результат в кэш-памяти удостоверений.
После этого клиент посылает в службу аутентификации центра KDC запрос KRB_AS_REQ (Kerberos Authentication Service Request – запрос к службе аутентификации Kerberos). Первая часть его сообщения содержит идентификатор пользователя, то есть Алисы, а также имя службы, для которой ей нужно удостоверение, то есть службы выдачи билетов. Во второй же части указываются данные предварительной аутентификации (pre-authentication data), которые подтверждают, что Алиса знает пароль. Обычно в качестве таких данных используется метка времени, зашифрованная с долговременным ключом Алисы, хотя Kerberos допускает и другие виды предаутентификационных данных.
Таким образом, на клиенте и сервере Kerberos должен получиться один и тот же ключ. Этот ключ не передается по сети!
Получив запрос KRB_AS_REQ, служба KDC обращается в свою базу данных и находит в ней долговременный ключ Алисы, после чего расшифровывает данные предварительной аутентификации и оценивает метку времени, содержащуюся в них. Если проверка прошла успешно, служба KDC делает вывод, что данные предварительной аутентификации были зашифрованы с долговременным ключом Алисы и, следовательно, поступили от клиента, имя которого содержится в первой части сообщения.
После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи билетов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в билет TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует билет TGT с собственным долговременным ключом и, наконец, включает зашифрованный сеансовый ключ регистрации вместе с билетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply – ответ службы аутентификации Kerberos), который направляет клиенту.
Получив такое сообщение, клиент расшифровывает сеансовый ключ регистрации и сохраняет его в кэш-памяти удостоверений. После этого из сообщения извлекается билет TGT, который также помещается в эту кэш-память.
Получив ответ службы KDC на свой первоначальный запрос, клиент расшифровывает свою копию сеансового ключа, используя для этого рассчитанное значение ключа. После этого долговременный ключ, полученный из пользовательского пароля, удаляется из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия билета TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key).
С точки зрения клиента, билет TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент, прежде всего, обращается в кэш-память удостоверений и достает оттуда сеансовый билет для этой службы. Если его нет, он начинает искать в этой же кэш-памяти билет TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор (некоторую информацию о себе), который вместе с TGT высылает в KDC. Одновременно туда направляется запрос на сеансовый билет для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена – она требует сеансового ключа, аутентификатора и билета (в данном случае TGT).
С точки же зрения службы KDC, билеты TGT позволяют ускорить обработку запросов на получение билетов, сэкономив несколько наносекунд на обработке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя (то есть ищет в базе данных) только один раз, когда предоставляет клиенту первоначальный билет TGT. Во всех последующих транзакциях с этим клиентом центр KDC расшифровывает билеты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации. Этот процесс происходит быстрее, так как никогда не требуется обращений ко внешним носителям, кроме того расшифровывание происходит быстрее поиска в достаточно большой базе.
Функции службы KDC ограничиваются выдачей билета. Получив ответ KDC, клиент извлекает из него сеансовый билет и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти, в резидентном, то есть не выгружаемом пуле). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из билета, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот билет в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента.
Сервер, получив «удостоверение личности» клиента, с помощью своего секретного ключа расшифровывает сеансовый билет и извлекает из него сеансовый ключ, который затем использует для расшифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.
Функции центра KDC можно разделить на две категории: службу аутентификации (AS), в задачу которой входит генерация билетов TGT, и службу выдачи билетов, создающую сеансовые билеты. Такое разделение труда позволяет применять протокол Kerberos и за пределами его «родного» домена. Клиент, получивший билет TGT из службы аутентификации одного домена, может воспользоваться им для получения сеансовых билетов в службах выдачи билетов других доменов.
Наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе. В Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения. Как только ключ создан, служба выдачи билетов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи билетов каждого из доменов начинает рассматривать службу выдачи билетов второго домена, как еще одну свою службу.
А теперь рассмотрим, что происходит, когда пользователь пытается получить доступ к серверу, расположенному в другом домене. Прежде всего, клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи билетов своего домена, в котором просит выдать сеансовый билет для доступа на нужный сервер. Служба выдачи билетов проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый билет переадресации (referral ticket), который представляет собой TGT, зашифрованный с помощью междоменного ключа, общего для служб KDC соседних доменов. Получив билет переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи билетов того домена, где находится учетная запись нужного сервера. Его служба выдачи билетов пытается расшифровать билет переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый билет на доступ к соответствующему серверу своего домена.
Процесс переадресации запроса несколько усложняется в сетях, где развернуто более двух доменов. Теоретически служба KDC каждого домена может установить непосредственную связь с аналогичными службами всех доменов сети, договорившись с каждой из них об индивидуальном междоменном ключе. Однако на практике количество и сложность подобных взаимосвязей очень быстро возрастают до такой степени, что становятся просто неуправляемыми, особенно в сложных сетях. Протокол Kerberos решает эту проблему, делая ненужными прямые связи между доменами. Клиент одного домена может получить билет на доступ к серверу другого домена через один или несколько промежуточных серверов, каждый из которых выдаст ему билет переадресации. Для того, чтобы можно было добраться до произвольного домена, рекомендуется построить дерево серверов КДС.
Клиент, таким образом, при попытке добраться до определенного сервера может получить несколько билетов переадресации, обращаясь последовательно к нескольким КДС.
Такой протокол был реализован, по-видимому, потому, что, во-первых, пользователям не так часто требуется обращаться к удаленным серверам.
Сеансовые билеты можно использовать многократно. На случай же их хищения устанавливается срок годности билета, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретного домена. Обычно срок годности билетов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется, и все сеансовые билеты вместе с сеансовыми ключами уничтожаются.
Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и билета TGT. Он называется Authentication Service Exchange (обмен со службой аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен со службой выдачи билетов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового билета доступа к службам.
Чтобы лучше разобраться в том, как эти подпротоколы взаимодействуют между собой, давайте посмотрим, что происходит, когда Алиса, пользователь рабочей станции, обращается к Бобу, сетевой службе.
Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request – запрос к службе выдачи билетов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, билет TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен билет.
Рис. 6. Подпротокол TGS Exchange
Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа расшифровывает билет TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из билета TGT регистрационные данные Алисы и генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в билет, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply – ответ службы выдачи билетов Kerberos) и направляется на ее рабочую станцию.
Получив такое сообщение, клиент с помощью сеансового ключа регистрации Алисы расшифровывает сеансовый ключ доступа к службе и помещает его в кэш-память удостоверений. После этого клиент извлекает билет на доступ к службе и сохраняет его в той же кэш-памяти.
Клиент Kerberos, установленный на рабочей станции Алисы, обращается к службе Боб, для чего посылает на нее запрос KRB_AP_REQ (Kerberos Application Request – запрос приложения Kerberos). Это сообщение содержит аутентификатор Алисы, зашифрованный посредством сеансового ключа для службы Боб, билет, полученный с помощью протокола TGS Exchange, а также флаг, указывающий о желании клиента провести взаимную аутентификацию (наличие или отсутствие этого флага определяется конфигурацией Kerberos; он устанавливается автоматически без запроса пользователя).
Рис. 7. Подпротокол CS Exchange
Получив сообщение KRB_AP_REQ, служба Боб расшифровывает билет, извлекает из него данные авторизации Алисы и сеансовый ключ, с помощью которого сразу же расшифровывает аутентификатор Алисы. Если метка времени, заложенная в него, выдерживает проверку, Боб ищет в запросе флаг взаимной аутентификации. Найдя его, Боб шифрует метку времени из аутентификатора Алисы сеансовым ключом, включает полученный результат в пакет KRB_AP_REP (Kerberos Application Reply – ответ приложения Kerberos) и возвращает его на рабочую станцию Алисы.
После получения пакета клиент рабочей станции Алисы расшифровывает аутентификатор Боба, используя для этого сеансовый ключ, и сравнивает полученную метку времени с исходной. Если они совпадают, делается вывод, что связь установлена с нужной службой, и можно приступать к обмену информацией.
Выше мы говорили о билетах лишь в общих чертах. Теперь пришло время более подробно рассмотреть, что же это такое, как рассчитывается срок годности билета, и какая его часть становится известной клиенту. Все эти детали важны для разработки политики Kerberos, поэтому к ним нужно присмотреться как можно ближе.
Перечислим поля билета, опишем содержащуюся в них информацию. Более подробно структура билета и различных сообщений Kerberos описана в документе RFC 1510.
Таблица 1. Поля билета
Название поля |
Описание |
|
Первые три поля билета не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления билетами, хранящимися в кэш-памяти. |
||
tkt-vno |
Номер версии формата билета. Для Kerberos 5 здесь указывается цифра 5. |
|
Realm |
Имя области (домена), где генерирован билет. Служба KDC может создавать билеты только для серверов собственной области, поэтому здесь, по существу, указывается имя области, где расположен сервер. |
|
Sname |
Имя сервера. |
|
Остальные поля шифруются с помощью секретного ключа сервера. |
||
Flags |
Флаги билета. |
|
Key |
Сеансовый ключ. |
|
Crealm |
Имя области (домена) клиента. |
|
Cname |
Имя клиента. |
|
Transited |
Список областей Kerberos, принимавших участие в аутентификации клиента, которому выдан данный билет. |
|
Authtime |
Время первоначальной аутентификации клиента. Служба KDC заполняет это поле в момент генерации билета TGT. При генерации билетов на основе билета TGT временная метка из поля authtime билета TGT копируется в поле authtime генерируемого билета. |
|
Starttime |
Время вступления билета в силу. |
|
Endtime |
Время истечения срока действия билета. |
|
renew-till |
Наибольшее значение поля endtime, которое может быть задано с помощью флага RENEWABLE (поле необязательное). |
|
Caddr |
Один или несколько адресов, из которых может использоваться данный билет. Поле необязательное. Если оно не заполнено, билетом можно воспользоваться из любого адреса. |
|
Authorization-data |
Атрибуты привилегий клиента. Поле необязательное. Его содержимое Kerberos не обрабатывает – оно интерпретируется службой. |
|
Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Длина поля – 32 разряда, однако для администратора Kerberos интерес представляют только 9 флагов билета.
Таблица 2. Флаги билета
Флаг |
Описание |
FORWARDABLE |
Указывает, что на основании данного билета TGT служба выдачи билетов может генерировать новый билет TGT с другим сетевым адресом (поле имеется только в билетах TGT). |
FORWARDED |
Указывает на то, что данный билет TGT был переадресован или генерирован на основе другого билета TGT, прошедшего переадресацию. |
PROXIABLE |
Указывает, что служба выдачи билетов может генерировать билеты, сетевой адрес которых будет отличаться от приведенного в данном билете TGT (поле имеется только в билетах TGT). |
PROXY |
Указывает на то, что сетевой адрес в данном билете отличается от адреса, приведенного в билете TGT, на основании которого он выдан. |
RENEWABLE |
Используется в сочетании с полями endtime и renew-till, разрешая периодическое обновление службой KDC билетов с повышенным сроком действия. |
INITIAL |
Указывает, что данный билет является билетом выдачи билетов (поле имеется только в билетах TGT). |
Клиенту необходимо знать часть информации, содержащейся как в обычных билетах, так и в билетах TGT, чтобы управлять своей кэш-памятью удостоверений. Возвращая билет и сеансовый ключ в рамках подпротоколов AS Exchange или TGS Exchange, служба KDC упаковывает клиентскую копию сеансового ключа в структуру данных, где уже могут быть заполнены поля flags, authtime, starttime, endtime и renew-till. Вся эта структура шифруется с помощью ключа клиента, включается в пакет KRB_AS_REP или KRB_TGS_REP и возвращается на рабочую станцию клиента.
В билете указывается время начала и конца его действия. В течение этого промежутка клиент, которому выдан данный билет, может неограниченное количество раз представить его для получения доступа к службе. Чтобы уменьшить риск компрометации билета или соответствующего сеансового ключа, администратор вправе ограничить максимальный срок действия билета. Этот срок является одним из элементов политики Kerberos.
Запрашивая в центре KDC билет для доступа к службе, клиент может указать конкретное время начала его действия. Если этого не сделано или заданное время уже минуло, центр KDC указывает в поле starttime текущее время.
Но независимо от того, указал клиент время начала действия билета или нет, запрос обязательно должен содержать время прекращения срока его действия. Получив такой запрос, служба KDC рассчитывает значение поля endtime. Для этого она суммирует наибольший срок действия билета, предусмотренный политикой Kerberos, со значением поля starttime, а затем сравнивает полученный результат со временем прекращения действия билета, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.
О скором истечении срока действия сеансового билета или билета TGT служба KDC не уведомляет клиента. Не следит она и за транзакциями с клиентом, если не считать краткосрочных записей, главная цель которых – предотвратить повторное использование перехваченных пакетов.
Если клиент, пытаясь подключиться к серверу, передаст просроченный сеансовый билет, то в ответ он получит сообщение об ошибке. В этом случае клиенту придется вновь обращаться в службу KDC и заказывать новый сеансовый билет. Однако после аутентификации подключения срок действия сеансового билета перестает играть какую-либо роль, поскольку он нужен только для подключения к серверу. Даже если срок действия сеансового билета прекратится во время проведения сеанса, это никак не скажется на ходе текущих операций.
Может случиться и так, что клиент включит просроченный билет TGT в свой запрос на сеансовый билет, который направит в службу KDC. В этом случае центр выдачи билетов перешлет клиенту сообщение об ошибке, после чего клиенту придется запросить новый билет TGT, а для этого ему понадобится долговременный ключ пользователя. Если в процессе начальной регистрации такой ключ не был занесен в кэш-память, система может попросить пользователя еще раз ввести свой пароль, на основании которого будет вновь рассчитан долговременный ключ.
Один из методов защиты сеансовых ключей состоит в частой их смене. С этой целью в политике Kerberos можно предусмотреть относительно небольшой максимальный срок действия билетов. Но есть и другой способ – использовать обновляемые билеты. При этом обеспечивается периодическое обновление сеансовых ключей без необходимости запрашивать новый билет. Если политика Kerberos разрешает применение обновляемых билетов, служба KDC включает в каждый генерируемый билет флаг RENEWABLE и указывает два срока истечения его действия. Первый из них ограничивает жизнь текущего экземпляра билета, а второй определяет общее время, в течение которого может использоваться билет с учетом его обновлений.
Поле endtime указывает, когда истекает срок действия текущего экземпляра билета. Как и в случае с необновляемыми билетами, значение этого поля равно сумме значения из поля starttime и наибольшего срока действия билетов, определенного политикой Kerberos. Клиент, использующий обновляемый билет, должен представить его в службу KDC для обновления до времени, указанного в поле endtime. Одновременно с билетом в центр распределения ключей направляется и новый аутентификатор. Получив билет, который нужно обновить, служба KDC, прежде всего, проверяет общий срок его действия, указанный в поле renew-till. Это время задается при первичной генерации билета. Оно определяется путем суммирования значения из поля starttime с максимально допустимым политикой Kerberos сроком действия билета с учетом всех обновлений. Если указанное в поле renew-till время еще не наступило, служба KDC генерирует новый экземпляр билета, где указывает более позднее время endtime и заменяет сеансовый ключ.
Это дает администратору возможность предусмотреть в политике Kerberos сравнительно частое обновление билетов, например, ежедневно. Смена сеансовых ключей при обновлении билета намного снижает риск их компрометации. В то же время администратор может задать довольно длительное общее время использования билета – неделю, месяц, а то и больше. По истечении этого срока билет становится полностью непригодным для дальнейшего использования и обновлению не подлежит.
Определенную сложность для протокола Kerberos создают многоуровневые клиент-серверные приложения. Здесь клиент может подключаться к серверу, который, в свою очередь, должен будет подключиться к другому серверу более высокого уровня. Для этого первому серверу понадобится билет на подключение ко второму. В идеале такой билет должен ограничивать доступ первого сервера ко второму лишь теми функциями, на которые клиент имеет права.
Для решения этой проблемы в протоколе Kerberos имеется специальный механизм – так называемое делегирование аутентификации. По существу, в такой ситуации клиент поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный сервер имеет право представлять клиента. Такой подход напоминает концепцию имперсонации (concept of impersonation) Windows 2000.
Делегирование аутентификации возможно двумя способами. Во-первых, клиент может получить билет на подключение к серверу высшего уровня, а затем передать его ближайшему серверу. Билеты, полученные таким способом – клиентом для ближайшего сервера – называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная трудность: чтобы получить представительский билет, клиенту нужно знать имя сервера высшего уровня. Решить проблему помогает второй способ делегирования аутентификации. Здесь клиент передает на ближайший к нему сервер свой билет TGT, который тот по мере необходимости использует для запроса собственных билетов. Билеты TGT, полученные таким образом, то есть, по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC, зависит от политики Kerberos.
Когда служба KDC приступает к формированию билета TGT, она, прежде всего, обращается к политике Kerberos и проверяет, допускается ли применение представительских билетов. Если да, центр управления билетами выставляет в билете TGT, который он готовит клиенту, флаг PROXIABLE.
Чтобы получить представительский билет, клиент пересылает свой билет TGT в службу выдачи билетов и запрашивает у нее билет на подключение к серверу высшего уровня. В запросе выставляется специальный флаг, свидетельствующий о том, что нужен представительский билет, а также указывается имя сервера, который будет являться представителем клиента. Получив такой запрос, служба KDC создает билет на доступ к серверу высшего уровня, выставляет в нем флаг PROXY и отсылает в таком виде клиенту. Клиент затем направляет полученный билет на сервер, который будет его представлять, а тот, в свою очередь, использует этот билет для доступа к серверу высшего уровня.
Клиент, который намерен делегировать свои права на получение билета для доступа к серверу высшего уровня, должен запросить у службы KDC передаваемый билет TGT. Это делается с помощью подпротокола AS Exchange. В запрос обязательно включается имя сервера, который будет представлять клиента. Если политика Kerberos допускает использование передаваемых билетов, служба KDC генерирует билет TGT на доступ данного клиента к серверу высшего уровня, выставляет в нем флаг FORWARDABLE и в таком виде направляет клиенту. Клиент, в свою очередь, пересылает полученный билет TGT тому серверу, с которым работает непосредственно.
Этот сервер, направляя билет на сервер высшего уровня, представляет в службу KDC билет TGT, полученный от клиента. Обнаружив в нем флаг FORWARDABLE, центр управления билетами выставляет в новом билете флаг FORWARDED и возвращает его первому серверу.
Система шифрования с одноразовым блокнотом не только является абсолютно криптостойкой, но и позволяет организовать стегоканал, описание которого звучит фантастично.
Пусть А и Б хотят обмениваться сообщениями так, чтобы никто не смог прочитать эти сообщения. Но передавать их А и Б могут только через С, причем С потребовал, чтобы он (и только он) мог расшифровать сообщения.
В этой ситуации А и Б могут поступить следующим образом. Заранее они договариваются об одноразовом блокноте. Когда А передает сообщение Б, А шифрует сообщение очередным ключом, взятым из одноразового блокнота: КАБ(сообщение). Затем А подбирает другое, безобидное сообщение так, чтобы его длина совпадала с исходным (можно исходное сообщение слегка урезать или дополнить пустым шумом). После чего формирует ключ Кс, переводящий безобидное сообщение в КАБ(сообщение). Этот ключ Кс А вместе с зашифрованным сообщением КАБ(сообщение) передает С. С расшифровывает сообщение полученным ключом: Кс (КАБ(сообщение)) и получает безобидное сообщение, после чего соглашается передать зашифрованное сообщение Б. Б же будет расшифровывать полученное сообщение по-другому: КАБ (КАБ(сообщение)) и получает действительное сообщение.
Остается добавить, что ключ Кс А вычисляет очень просто:
Кс = КАБ(сообщение) xor (безобидное сообщение)
В предыдущем протоколе необходимо, чтобы А и Б заранее договорились об одноразовом блокноте. Это не всегда возможно, тогда можно предложить протокол, требующий от А и Б знания одной ключевой фразы. Ключевая фраза может быть взята из книги. Цель — передать ключ.
А, передает следующую конструкцию: КАБ(ключевая фраза), КАБ(сообщение). Б, зная ключевую фразу, вычисляет ключ, а затем полученным ключом дешифрует сообщение. Скрытие сообщения от С производится тем же способом, что и ранее.
Здесь предполагается, что ключевая фраза не короче сообщения. В противном случае при шифровании сообщения потребуется текущую гамму дублировать, хотя последнее тоже возможно.
А и В хотят обмениваться секретными сообщениями (передачи в обе стороны), С – активный злоумышленник, пытающийся контролировать трафик при помощи атаки «человек посередине».
Рассмотрим сначала обычную схему взаимодействия А и В.
1. А -> В : КАО
2. В -> А : КВО
3. А -> В : КВО (сообщениеА)
4. В -> А : КАО (сообщениеВ)
5. А и В расшифровывают полученные сообщения своими закрытыми ключами.
Активный злоумышленник С может вмешаться в этот протокол на шаге 1 и шаге 2, предложив А и В свой открытый ключ, вместо пересылаемых, а пересылаемые ключи запомнить. В дальнейшем он сможет расшифровывать все проходящие сообщения своим закрытым ключом и зашифровывать их ключами А и В так, что А и В не догадаются об атаке. Единственное, что может их насторожить, это, возможно, великоватое время передачи. Такие действия злоумышленника называются атака «человек посередине».
А и В могут защититься от этой атаки. То есть сделать так, что они смогут распознать вмешательство и начать протокол заново. Обратите внимание на то, что атака «отказ в обслуживании» злоумышленнику удается, так как он может снова и снова вмешиваться, не давая тем самым А и В связаться.
Итак, протокол взаимоблокировки. Первые два этапа остаются прежними, а дальнейшая передача сообщений идет половинными порциями, причем половины берутся таким образом, чтобы невозможно было их дешифрование. Например, первая половина сообщения состоит из левых половин всех блоков шифрования, а вторая – из правых. Таким образом, перехватив первую часть сообщения, злоумышленник не может ее обработать алгоритмом шифрования.
1. А -> В : КАО
2. В -> А : КВО
3. А -> В : КВО (1 половина сообщения А)
4. В -> А : КАО (1 половина сообщения В)
5. А -> В : КВО (2 половина сообщения А)
6. В -> А : КАО (2 половина сообщения В)
7. А и В расшифровывают полученные сообщения своими закрытыми ключами.
Если злоумышленник подменит ключи на этапах 1 и 2, то на шаге 3 он не сможет отправить В разумную половину, так как полученная им половина без второй части не расшифровывается. Злоумышленник может предположить, что содержится в передаваемом документе и предложить свой вариант текста, но это - не очень удачная идея. Если обмен сообщениями между А и В на этом завершился, то у злоумышленника нет возможности передать истинные сообщения и тем самым скрыть свое вмешательство.
Цель алгоритма – составить секретный ключ.
Идея алгоритма – А передает В некоторую случайную последовательность бит, В пытается угадать эту последовательность. Из верно угаданных битов составляется ключ.
Метод – А и В сначала договариваются об используемых обозначениях бит, то есть об алфавитах. Алфавиты А и В разные, но связанные некоторым законом. То есть стороны договариваются о том, какими фотонами каждая из сторон будет обозначать 0 и 1. Инициатор отправляет фотоны, получатель, установив свои приемные фильтры, пытается зарегистрировать пришедшие фотоны. На основании полученной информации получатель приходит к мнению о том, где он угадал, и отправляет инициатору сообщение об этом.
Теперь подробнее.
Дано. Инициатор, то есть А выбирает две не ортогональные поляризации для фотонов. Получателю В требуется выбрать поляризацию, перпендикулярную выбранным А, причем поляризация фотона, обозначающего 0, у А и у В должны отличаться на 45 градусов. Аналогично для 1. То есть получается, что фотоны с 0 отправителя и с 1 получателя ортогональны. То есть перепутать 0 и 1 невозможно.
Например, алфавит А следующий: 0=á, а 1=ä. Алфавит В: 0=æ, 1=à. Здесь стрелками обозначены поляризации фотонов. Поскольку фотоны ä и фотоны æ образуют угол в 90 градусов, фотоны á и à тоже, то если получатель выставит фильтр в положение æ, фотон с поляризацией ä не пройдет через этот фильтр. Аналогично для второй пары фотонов.
Рассмотрим пример. Пусть А сгенерировал случайную последовательность бит, сформировал последовательность фотонов в соответствии со своим алфавитом и отправил ее В:
1 0 1 0 0 0 1 1 1
ä á ä á á á ä ä ä
В, не зная последовательность А, сгенерировал свою случайную последовательность бит и выставил свои поляризаторы согласно своей последовательности:
0 1 1 0 0 1 1 0 0
æ à à æ æ à à æ æ
Выставив таким образом фильтры-поляризаторы, В пытается увидеть фотоны, отправленные А.
ä á ä á á á ä ä äполяр. фотонов А
æ à à æ æ à à æ æ фильтры В
Если поляризации фотона и фильтра ортогональны, то фотон не пройдет через фильтр. Если же поляризации отличаются на 45 градусов, то фотон проходит с вероятностью 0,5. Отметим те позиции, в которых В мог увидеть фотон:
- - + + + - + - -
Теперь заменим примерно половину + на -, так как сказано выше, что фотон проходит через фильтр с вероятностью 0,5. Получим:
- - - + + - + - -
Затем В отправляет А список + и -, сообщая инициатору о том, какие фотоны он наблюдал. Эти наблюдаемые фотоны будут в дальнейшем составлять секретный ключ.
1 0 1 0 0 0 1 1 1 биты А
0 1 1 0 0 1 1 0 0 биты В
- - - + + - + - -
0 0 1 ключ
Из картинки видно, что и А и В составят один и тот же ключ 001.
Так как всего возможных вариантов сочетаний битов А и В четыре, из которых в двух вариантах биты отправителя и получателя совпадают, то примерно половина бит является кандидатами на ключ. Но так как вероятность приема бит равна 0,5, то только примерно четвертая часть бит от сгенерированного сообщения будет составлять ключ.
Если злоумышленник прослушивает линию связи, то возникают дополнительные потери бит. Если превышен порог допустимых случайных отклонений, то А и В решают, что канал не надежен.
А необходимо аутентифицироваться перед В. Можно, конечно, на компьютере В хранить базу паролей всех пользователей, а затем так или иначе проверять, что А знает этот пароль. Но этот способ плох тем, что, во-первых, необходимо решить задачу передачи пароля от пользователя А компьютеру В, а, во-вторых, необходимо обеспечить защиту базы В, так как ее взлом приводит к дискредитации всех паролей, в-третьих, клиент при каждом входе пользуется одним и тем же паролем, что может дать злоумышленнику достаточный объем данных для криптоанализа.
Протокол SKEY предлагает решение этих проблем. Клиент А генерирует некоторое случайное число r0. Затем сто раз преобразовывает это число, пользуясь хэш-функцией и сохраняя промежуточные значения. То есть, получает числа r1=H(r0), r2=H(r1), ..., r101=H(r100). Затем клиент сохраняет все числа на своем компьютере, кроме r101, которое отправляет В. В сохраняет это число в своей базе. Теперь, когда А желает связаться с В, он отправляет число r100. В, получив это число, вычисляет H(r100) и сравнивает полученный результат с хранимым. Если они совпадают, аутентификация считается удачной. После этого В изменяет свое хранимое число на только что полученное r100. А клиент, в свою очередь, вычеркивает из своего списка r100, намереваясь в следующий раз воспользоваться r99. И так далее, пока не закончатся числа, после чего протокол можно снова инициализировать.
Обратите внимание на то, что у злоумышленника ничего не получается, даже если он перехватывает промежуточные пакеты клиента, так как по результату хэш-функции невозможно восстановить исходное число. Слабое место этого протокола - база клиента. Злоумышленник может попробовать взломать её. Отрадно то, что в случае удачного взлома пострадает только один клиент, а не все.
А и В хотят убедиться в том, что они оба принадлежат одной группе. Причем они могут остаться и не известными друг для друга, важна только принадлежность одной группе. В процессе аутентификации не должно участвовать третье лицо.
Конечно, раздавать всем членам группы список с паролями было бы безумием, кроме того, при этом не удалось бы организовать анонимность собеседников. Необходимо чтобы А предоставил нечто, с помощью этого «нечто» В должен произвести некоторые вычисления и убедиться в том, что А – член группы. Аналогично, В предоставляет некоторую информацию А, по которой А убеждается в принадлежности В к группе.
Такой протокол можно реализовать, если использовать при подготовке данных некоторое доверенное лицо Д. Д готовит n=p*q, 1<a<n и для каждого члена группы выбирает (случайно) yi, где i=1,2,…k. Затем i-тому члену группы передается n, yi и некоторая частичная «сумма» Si, то есть выражение, вычисленное по нижеприведенной формуле, но без одного возведения в степень, то есть без возведения в yi:
(…(((ay1 mod n)y2 mod n)y3 mod n) …)yk mod n
При встрече А предъявляет В свой ya и свою частичную «сумму» Sa. В аналогично предъявляет А свой yb и Sb. Каждый из них, зная n (но не сообщая его второй стороне!), может посчитать, совпадают ли Saya mod n и Sbyb mod n. Если совпадают, аутентификация считается успешной.
Здесь важно то, что производимые вычисления коммутативны и вычислительно необратимы. Если С, не являющийся членом группы, попытается произвести аутентификацию, например, с В, то он получит yb и Sb, но не зная n, он не сможет даже вычислить полную сумму S. Впрочем, если n ему известно, то перед ним встает сложная вычислительная задача по расчету xy mod n = S. Правда, при попытке аутентифицироваться с В, С узнаёт верные yb и Sb, которые С может использовать в дальнейшем, пытаясь аутентифицироваться (от имени В) с предположительным членом этой же группы, например, с А. Последнее удается. Чтобы защититься от такой атаки, на стадии аутентификации с В, когда В понимает, что перед ним не член группы, В фактически узнаёт о дискредитации своего аутентификатора (yb и Sb). В этом случае следует сообщить об инциденте Д, для того чтобы он выработал для всей группы новые аутентификаторы.
Пусть у А есть несколько секретов, например, ключей. В, С и другие хотят получить по одному ключу, причем так, чтобы каждому стал известен только один ключ, чтобы А не узнал, да и никто другой не узнал, кому, какой ключ передан.
Задача состоит в том, чтобы создать протокол, удовлетворяющий описанным ниже характеристикам. Для того, чтобы разрешить субъекту А выполнить то или иное действие Д, субъекту В необходимо определить принадлежность А некоторой группе, при этом необходимо обеспечить анонимность члена группа, то есть имя А должно остаться неизвестным для В. В то же время специальный контролёр С при необходимости может установить, что действие Д выполнил именно А.
Например, в организации несколько принтеров. Для каждого принтера определена группа людей, которые могут им пользоваться. Пользование принтеров анонимно, но если замечено, что некто слишком долго занимал принтер, то директор имеет возможность выяснить, кто это, и предъявить ему счет.
Доверенное лицо (посредник) создает большое множество пар ключей (открытый и закрытый) - n пар. Далее разбивает это множество случайным образом на m подмножеств, где m - количество клиентов. Посредник распределяет подмножества ключей клиентам. Затем собирает все открытые ключи, соответствующие закрытым ключам клиентов из одной группы, и публикует их. Так он проделывает для каждой группы.
Клиент формирует запрос, подписывая его одним из своих закрытых ключей (ключ выбирается произвольно). Некоторый сервер В может удостовериться в том, что запрос принадлежит одному из членов группы, применив открытые ключи членов группы и получив осмысленное сообщение. В то же время сервер не может определить, какой из пользователей к нему обратился. В случае необходимости директор обращается к посреднику, у которого в тайне хранится список соответствия открытых ключей пользователям.
Недостаток данного протокола в том, что посреднику известны все ключи.
А знает некоторый секрет (сообщение S) и не хочет сообщать его никому, но даже для в этом случае имеет смысл устроить хранение этого секрета таким образом, чтобы его могли восстановить только несколько человек, собравшись вместе.
Рассматриваемый протокол использует посредника. Посредник генерирует m случайных строк, где (m+1) - количество лиц, между которыми разбивается секрет. Затем посредник вычисляет SR = R1 xor R2 xor ... RM xor S. После этого посредник передает R1 - первому лицу, R2 - второму и так далее, наконец, SR - последнему из лиц, между которыми разбивается секрет. Теперь никто из них и никакое их неполное подмножество не могут восстановить секрет. Но, собравшись вместе, они в состоянии восстановить S. Злоумышленнику, чтобы воспользоваться их знаниями, придется подкупить или шантажировать всех.
Универсальная система электронных платежей UEPS – это банковское приложение. Используются смарт-карты. Приложение было создано в ЮАР. В 1995 году там уже использовалось 2 миллиона карточек.
Банк выпускает смарт-карты продавцов и покупателей. Это дебитовые карточки, достаточно защищенные аппаратно. Считается, что обычные люди не смогут их взломать.
Цель данного алгоритма – защита от мошенничества покупателей и продавцов. Анонимность покупателя и сделки не обеспечивается.
Покупатель переводит на свою карту некоторую сумму денег. На его карточке также расположена некоторая секретная информация, которую не видят ни покупатель, ни продавец. Эта информация: два ключа К1, К2 и два МАС-кода (хэш с ключевой инициализирующей последовательностью). Кроме того, на карточке хранится полный журнал обо всех выполненных транзакциях.
На карточке продавца также содержится некоторая секретная информация, секретный алгоритм и также полный журнал транзакций. Алгоритм может по открытому имени покупателя вычислить его секретные ключи К1, К2.
Процесс криптографического закрытия данных может осуществляться как программно, так и аппаратно. Аппаратная реализация отличается существенно большей стоимостью, однако ей присущи и преимущества: высокая производительность, простота, защищенность и т.д. Программная реализация более практична, допускает известную гибкость в использовании.
Для современных криптографических систем защиты информации сформулированы следующие общепринятые требования:
· зашифрованное сообщение должно поддаваться чтению только при наличии ключа;
· знание алгоритма шифрования не должно влиять на надежность защиты;
· длина шифрованного текста не должна превышать длину исходного текста;
· между исходным текстом и зашифрованным не должно быть легко устанавливаемых зависимостей (или, другими словами, знание фрагмента исходного текста не уменьшает количества операций, необходимых для определения ключа шифрования по сравнению с общим числом возможных ключей);
· незначительное изменение ключа должно приводить к существенному изменению вида зашифрованного сообщения;
· дополнительные биты, вводимые в сообщение в процессе шифрования, должен быть полностью и надежно скрыты в шифрованном тексте;
· число операций, необходимых для расшифровывания информации путем перебора всевозможных ключей должно иметь строгую нижнюю оценку и выходить за пределы возможностей современных компьютеров (с учетом возможности использования сетевых вычислений);
· структурные элементы алгоритма шифрования должны быть неизменными (то есть алгоритм известен и не изменяется, так как от него ничего не зависит);
· не должно быть простых и легко устанавливаемых зависимостей между ключами, последовательно используемыми в процессе шифрования;
· любой ключ из множества возможных должен обеспечивать надежную защиту информации (то есть, должны быть известны слабые ключи, желательно, чтобы их было немного);
· алгоритм должен допускать как программную, так и аппаратную реализацию, при этом изменение длины ключа не должно вести к качественному ухудшению алгоритма шифрования.
Криптоанализ - это наука о дешифровке закодированных сообщений не зная ключей. Имеется много криптоаналитических подходов. Некоторые из наиболее важных для разработчиков приведены ниже.
Статистический анализ текста. Моноалфавитные с небольшим ключом алгоритмы замены приводят к текстам, которые достаточно легко можно подвергнуть статистическому анализу: посчитать частоту встречаемости символов, а затем сделать предположения о соответствующих буквах. Так в том примере, который приведен при описании алгоритмов замены, очевидно, что в зашифрованном тексте очень часто встречается буква «в». Для каждого языка известны вероятности, с которой встречается та или иная буква. Так, для русского наиболее часто встречается буква «о», немного уступает ей буква «а». Криптоаналитик может, сделав предположение, что «в» - это исходная «о», восстановить шаг и построить исходное слово. Если ничего интересно не получилось, то можно попробовать предположить, что это – буква «а». Как видите, чем больше текст, тем увереннее можно делать предположения. Если ключ состоит из более одного символа, ситуация несколько запутывается, но все еще можно опираться на статистический анализ, построенный отдельно по каждой четной и нечетной букве.
Атака со знанием лишь шифрованного текста (ciphertext-only attack): Это ситуация, когда атакующий не знает ничего о содержании сообщения, и ему приходится работать лишь с самим шифрованным текстом. На практике, часто можно сделать правдоподобные предположения о структуре текста, поскольку многие сообщения имеют стандартные заголовки. Даже обычные письма и документы начинаются с легко предсказумой информации. Также часто можно предположить, что некоторый блок информации содержит заданное слово.
Атака со знанием содержимого шифровки (known-plaintext attack): Атакующий знает или может угадать содержимое всего или части зашифрованного текста. Задача заключается в расшифровке остального сообщения. Это можно сделать либо путем вычисления ключа шифровки, либо минуя это.
Атака с заданным текстом (chosen-plaintext attack): Атакующий имеет возможность получить шифрованный документ для любого нужного ему текста, но не знает ключа. Задачей является нахождение ключа. Некоторые методы шифрования и, в частности, RSA, весьма уязвимы для атак этого типа. При использовании таких алгоритмов надо тщательно следить, чтобы атакующий не мог зашифровать заданный им текст.
Атака с подставкой (Man-in-the-middle attack): Атака направлена на обмен шифрованными сообщениями и, в особенности, на протокол обмена ключами. Идея заключается в том, что когда две стороны обмениваются ключами для секретной коммуникации (например, используя шифр Диффи-Хелмана, Diffie-Hellman), противник внедряется между ними на линии обмена сообщениями. Далее противник выдает каждой стороне свои ключи. В результате, каждая из сторон будет иметь разные ключи, каждый из которых известен противнику. Теперь противник будет расшифровывать каждое сообщение своим ключом и затем зашифровывать его с помощью другого ключа перед отправкой адресату. Стороны будут иметь иллюзию секретной переписки, в то время как на самом деле противник читает все сообщения.
Одним из способов предотвратить такой тип атак заключается в том, что стороны при обмене ключами вычисляют криптографическую хэш-функцию значения протокола обмена (или по меньшей мере значения ключей), подписывают ее алгоритмом цифровой подписи и посылают подпись другой стороне. Получатель проверит подпись и то, что значение хэш-функции совпадает с вычисленным значением. Такой метод используется, в частности, в системе Фотурис (Photuris).
Атака с помощью таймера (timing attack): Этот новый тип атак основан на последовательном измерении времен, затрачиваемых на выполнение операции возведения в стенень по модулю целого числа. Ей подвержены по крайней мере следующие шифры: RSA, Диффи-Хеллман и метод эллиптических кривых. В статье Пола Кочера подробно рассмотрен этот метод.
Имеется множество других криптографических атак и криптоаналитических подходов. Однако приведенные выше являются, по-видимому, наиболее важными для практической разработки систем. Если кто-либо собирается создавать свой алгоритм шифрования, ему необходимо понимать данные вопросы значительно глубже. Одно из мест, где можно начать систематическое изучение информации --- это замечательная книга Брюса Шнейера "Прикладная криптография" (Bruce Schneier, Applied Cryptography).
Тип атаки - «Атака с заданным текстом».
Злоумышленник перехватывает сообщение, адресованное А, зашифрованное открытым ключом А. Для того чтобы расшифровать его, злоумышленник составляет другое сообщение, зависящее от перехваченного, и передает составленное сообщение на подпись А (то есть А применяет свой закрытый ключ для этого сообщения!). Затем, произведя несложные вычисления, получает расшифрованный текст.
Рассмотрим следующий пример. Все расчеты будем вести с небольшими числами для наглядности. А открытым способом распространяет криптографическую пару: открытый ключ и модуль – (e=7, n=33). Пусть В передает А число, например 2, зашифрованное открытым ключом А, то есть передает ss = 2^7 mod 33 = 29. С перехватывает это число (29), кроме того, С, как и всем остальным известна криптографическая пара (7, 33). Цель C – расшифровать перехваченное сообщение 29.
С сначала подбирает два числа t и r, меньшие n, такие что t = (1/r) mod n. В нашем примере n = 33, поэтому возьмем r = 17, t = 2 (17*2 Mod 33 =1).
А затем вычисляет x = r^e mod n = 17^7 mod 33 = 8. Теперь берет перехваченное число ss и вычисляет y = ss*x mod n = 29*8 mod 33 = 1.
Настал важный момент. Если С имеет возможность попросить А зашифровать произвольный текст своим закрытым ключом, то есть фактически подписать какой-то документ, то полученный y передается А на подпись. А подписывает y и передает С, то есть С получает u = y ^ d mod n. В нашем примере А вычисляет u = 1 ^ 3 mod 33 = 1 (d=3 – закрытый ключ А) и отдает C.
Теперь С, наконец, расшифровывает ранее перехваченное сообщение следующим образом: s = t*u mod n = 2*1 mod 33 = 2. Как видите, это и отправлял В.
t*u mod n = u/r mod n = y^d/r mod n = (x^d * ss^d)/r mod n =
= ss^d mod n = s
Преобразуем t*u mod n, заменив t на 1/r, получим u/r mod n. Подставим выражение для y, получим (x^d * ss^d)/r mod n. А так как x = r^e mod n, то r = x^d mod n по основному соотношению между открытым и закрытым ключом. Сокращаем одинаковые выражения в числителе и знаменателе, получаем ss^d mod n. А это по основному соотношению между открытым и закрытым ключом равно исходному сообщению.
Замечание 1. В нашем примере можно было А и не передавать y на подпись, так как 1 в любой степени останется 1. Но это – счастливая случайность, практически невероятная.
Замечание 2. Важно, что передается сообщение, а не его хэш. Так как расшифровка хэш ничего не дает узнать о сообщении (если оно закрыто) и не дает возможности подделать документ, даже если он открыт, в случае если нет возможности полностью модифицировать трафик.
Пусть А – нотариус. Если В хочет заверить документ, он отправляет его А, тот подписывает весь документ своим закрытым ключом. Но нотариус может отказаться подписать некоторый документ, так как он с его точки зрения не является законным. С хочет заставить нотариуса подписать этот документ.
Делает он это следующим образом: он передает нотариусу на подпись другой документ, зависящий от того, который хочет подписать и от некоторого подобранного документа, а затем «убирает» подобранный.
Для того чтобы сократить вычисления, возьмем те же n=33, закрытый ключ d=3, открытый ключ e=7. Нам также понадобится некоторое t, такое что, существует t^-1 mod n, то есть возьмем t =2, обратное по модулю 33 к которому равно 17.
Итак, С хочет подписать сообщение s = 5, но нотариус этого делать не будет. Тогда С вычисляет y = t^e mod n = 2^7 mod 33 = 29. Затем С рассчитывает m = y*s mod n = 29*5 mod 33 = 13 и посылает это m на подпись нотариусу. Понятно, что нотариусу число 13 нравится гораздо больше, чем число 5, и он с радостью подписывает его, то есть возвращает p = m^d mod n = 13^3 mod 33 = 19.
Теперь С вычисляет значение p*t^-1 mod n = 19*17 mod 33 = 26. Интересно то, что это – нужный нам подписанный документ.
p*t^-1 mod n = (m^d * t^-1) mod n = (y^d *s^d * t^-1) mod n. А так как y = t^e mod n, то y^d mod n = t^-1, сокращаем эти два выражения и получаем s^d mod n, то есть подписанное интересующее нас s.
Проверим результат в числах s^d mod n = 5^3 mod 33 = 26.
Пусть С хочет получить подпись на документе m3, но А не подпишет этот документ. Тогда С может подобрать такие m1 и m2, что m3 = m1*m2 mod n. Теперь если уговорить А подписать m1 и m2, то по ним можно вычислить подпись для m3: m3^d = (m1^d mod n)*(m2^d mod n).
Покажем работу этого метода в числах. Пусть m3=9, тогда можно взять m1=15 m2=27, так как 15*27 mod 33 = 9. Подпишем у А m1, получим m1^d mod n = 15^3 mod 33 = 9. Подпишем m2^d mod n = 27^3 mod 33 =15. Искомое равно 9*15 mod 33 = 3, с другой стороны m3^3 mod 33 = 9^3 mod 33 = 3.
Возможно применение протокола на основе RSA, который предполагает, что всем пользователям раздается одинаковый модуль (n), но каждому передается своя пара ключей (di, ei).
В жизни может быть две ситуации. Первая: злоумышленнику известно, одно и то же сообщение передавалось дважды, зашифрованное открытыми ключами разных пользователей, но само сообщение злоумышленнику неизвестно. Тогда злоумышленник перехватывает c1 = m^e1 mod n и c2 = m^e2 mod n. Здесь ключи e1, e2 – открытые ключи каких-то пользователей, то есть они известны злоумышленнику. И злоумышленник пытается расшифровать сообщение.
Вторая: злоумышленник предполагает, какое сообщение послано другим пользователем и пытается убедиться в этом. Здесь злоумышленнику также известен открытый ключ другого пользователя и, конечно же, свой тоже.
Итак, если ключи e1, e2 взаимно простые (что бывает почти всегда!), то можно найти такие r и s, что r*e1+s*e2 = 1. В этой формуле или r или s должно быть отрицательное, пусть отрицательно r. Тогда (с1^-1)^-r * c2^s = m mod n.
Никогда не используйте алгоритм RSA для подписи случайных документов, переданных вам посторонними. По крайней мере, всегда следует сначала получить хэш по документу.
В протоколах связи не пользуйтесь общим множителем.
Вирусы можно разделить на классы по следующим основным признакам: среда обитания; операционная система (OC); особенности алгоритма работы; деструктивные возможности.
По среде обитания
Вирусы можно разделить на файловые; загрузочные; макро; сетевые.
Файловые вирусы либо различными способами внедряются в выполняемые файлы (наиболее распространенный тип вирусов), либо создают файлы-двойники (компаньон-вирусы), либо используют особенности организации файловой системы (link-вирусы). Загрузочные вирусы записывают себя либо в загрузочный сектор диска (boot-сектор), либо в сектор, содержащий системный загрузчик винчестера (Master Boot Record), либо меняют указатель на активный boot-сектор. Макро-вирусы заражают файлы-документы и электронные таблицы нескольких популярных редакторов. Сетевые вирусы используют для своего распространения протоколы или команды компьютерных сетей и электронной почты.
Существует большое количество сочетаний - например, файлово-загрузочные вирусы, заражающие как файлы, так и загрузочные сектора дисков. Такие вирусы, как правило, имеют довольно сложный алгоритм работы, часто применяют оригинальные методы проникновения в систему, используют стелс и полиморфик-технологии. Другой пример такого сочетания - сетевой макро-вирус, который не только заражает редактируемые документы, но и рассылает свои копии по электронной почте.
Заражаемая ОПЕРАЦИОННАЯ СИСТЕМА
Каждый файловый или сетевой вирус заражает файлы какой-либо одной или нескольких OS - DOS, Windows, Win95/NT, OS/2 и т.д. Макро-вирусы заражают файлы форматов Word, Excel, Office97.
Загрузочные вирусы также ориентированы на конкретные форматы расположения системных данных в загрузочных секторах дисков.
Особенности АЛГОРИТМА РАБОТЫ вирусов
Особенности: резидентность; использование стелс-алгоритмов; самошифрование и полиморфичность; использование нестандартных приемов.
РЕЗИДЕНТНЫЙ вирус при инфицировании компьютера оставляет в оперативной памяти свою резидентную часть, которая затем перехватывает обращения операционной системы к объектам заражения и внедряется в них. Резидентные вирусы находятся в памяти и являются активными вплоть до выключения компьютера или перезагрузки операционной системы. Нерезидентные вирусы не заражают память компьютера и сохраняют активность ограниченное время. Некоторые вирусы оставляют в оперативной памяти небольшие резидентные программы, которые не распространяют вирус. Такие вирусы считаются нерезидентными. Резидентными можно считать макро-вирусы, посколько они постоянно присутствуют в памяти компьютера на все время работы зараженного редактора. При этом роль операционной системы берет на себя редактор, а понятие «перезагрузка операционной системы» трактуется как выход из редактора. В многозадачных операционных системах время «жизни» резидентного DOS-вируса также может быть ограничено моментом закрытия зараженного DOS-окна, а активность загрузочных вирусов в некоторых операционных cистемах ограничивается моментом инсталляции дисковых драйверов OC.
Использование СТЕЛС-алгоритмов позволяет вирусам полностью или частично скрыть себя в системе. Наиболее распространенным стелс-алгоритмом является перехват запросов OC на чтение/запись зараженных объектов. Стелс-вирусы при этом либо временно лечат их, либо «подставляют» вместо себя незараженные участки информации. В случае макро-вирусов наиболее популярный способ — запрет вызовов меню просмотра макросов. Один из первых файловых стелс-вирусов — вирус «Frodo», первый загрузочный стелс-вирус — «Brain».
САМОШИФРОВАНИЕ и ПОЛИМОРФИЧНОСТЬ используются практически всеми типами вирусов для того, чтобы максимально усложнить процедуру детектирования вируса. Полиморфик-вирусы (polymorphic) - это достаточно труднообнаружимые вирусы, не имеющие сигнатур, т.е. не содержащие ни одного постоянного участка кода. В большинстве случаев два образца одного и того же полиморфик-вируса не будут иметь ни одного совпадения. Это достигается шифрованием основного тела вируса и модификациями программы-расшифровщика. Различные НЕСТАНДАРТНЫЕ ПРИЕМЫ часто используются в вирусах для того, чтобы как можно глубже спрятать себя в ядре OC (как это делает вирус «3APA3A»), защитить от обнаружения свою резидентную копию (вирусы «TPVO», «Trout2»), затруднить лечение от вируса (например, поместив свою копию в Flash-BIOS) и т.д.
Деструктивные возможности
Вирусы можно разделить на:
безвредные, т.е. никак не влияющие на работу компьютера (кроме уменьшения свободной памяти на диске в результате своего распространения);
неопасные, влияние которых ограничивается уменьшением свободной памяти на диске и графическими, звуковыми и пр. эффектами;
опасные вирусы, которые могут привести к серьезным сбоям в работе компьютера;
очень опасные, в алгоритм работы которых заведомо заложены процедуры, которые могут привести к потере программ, уничтожить данные, стереть необходимую для работы компьютера информацию, записанную в системных областях памяти, и даже, как гласит одна из непроверенных компьютерных легенд, способствовать быстрому износу движущихся частей механизмов - вводить в резонанс и разрушать головки некоторых типов винчестеров.
Но даже если в алгоритме вируса не найдено ветвей, наносящих ущерб системе, этот вирус нельзя с полной уверенностью назвать безвредным, так как проникновение его в компьютер может вызвать непредсказуемые и порой катастрофические последствия. Ведь вирус, как и всякая программа, имеет ошибки, в результате которых могут быть испорчены как файлы, так и сектора дисков. До сих пор попадаются вирусы, определяющие «COM или EXE» не по внутреннему формату файла, а по его расширению. Естественно, что при несовпадении формата и расширения имени файл после заражения оказывается неработоспособным. Возможно также «заклинивание» резидентного вируса и системы при использовании новых версий DOS, при работе в Windows или с другими мощными программными системами. И так далее.
Загрузочные вирусы заражают загрузочный (boot) сектор флоппи-диска и boot-сектор или Master Boot Record (MBR) винчестера. Принцип действия загрузочных вирусов основан на алгоритмах запуска операционной системы при включении или перезагрузке компьютера - после необходимых тестов установленного оборудования (памяти, дисков и т.д.) программа системной загрузки считывает первый физический сектор загрузочного диска (A:, C: или CD-ROM в зависимости от параметров, установленных в BIOS Setup) и передает на него управление.
В случае дискеты или компакт-диска управление получает boot-сектор, который анализирует таблицу параметров диска (BPB - BIOS Parameter Block) высчитывает адреса системных файлов операционной системы, считывает их в память и запускает на выполнение. В случае винчестера управление получает программа, расположенная в MBR винчестера. Эта программа анализирует таблицу разбиения диска (Disk Partition Table), вычисляет адрес активного boot-сектора (обычно этим сектором является boot-сектор диска C:), загружает его в память и передает на него управление. Получив управление, активный boot-сектор винчестера проделывает те же действия, что и boot-сектор дискеты.
При заражении дисков загрузочные вирусы «подставляют» свой код вместо какой-либо программы, получающей управление при загрузке системы, заставляя систему при ее перезапуске считать в память и отдать управление не оригинальному коду загрузчика, а коду вируса.
Заражение дискет производится единственным известным способом — вирус записывает свой код вместо оригинального кода boot-сектора дискеты. Винчестер заражается тремя возможными способами - вирус записывается либо вместо кода MBR, либо вместо кода boot-сектора загрузочного диска (обычно диска C:), либо модифицирует адрес активного boot-сектора в Disk Partition Table, расположенной в MBR винчестера.
При инфицировании диска вирус в большинстве случаев переносит оригинальный boot-сектор (или MBR) в какой-либо другой сектор диска например, в неиспользуемый или редко используемый сектор — в один из секторов винчестера, если такие есть, расположенных между MBR и первым boot-сектором. На дискете запись производится в один из последних секторов корневого каталога, или в сектора свободных кластеров логического диска, или в неиспользуемые или редко используемые системные сектора, в сектора, расположенные за пределами диска. Если длина вируса больше длины сектора, то в заражаемый сектор помещается первая часть вируса, остальные части размещаются в других секторах (например, в первых свободных секторах, в последних секторах или в секторах, которые принадлежат свободным кластерам диска, помечает в FAT эти кластеры как сбойные).
Реже используется метод сохранения продолжения вируса за пределами диска. Он достигается либо уменьшением размеров логических дисков: вирус вычитает необходимые значения из соответствующих полей boot-сектора и Disk Partition Table винчестера (если заражается винчестер), уменьшает таким образом размер логического диска и записывает свой код в «отрезанные» от него сектора, либо производится запись данных за пределами физического разбиения диска. В случае флоппи-дисков вирусу для этого приходится форматировать на диске дополнительный трек (метод нестандартного форматирования). Существуют вирусы («Azusa»), которые содержат в своем теле стандартный загрузчик MBR и при заражении записываются поверх оригинального MBR без его сохранения.
При заражении большинство вирусов копирует в код своего загрузчика системную информацию, хранящуюся в первоначальном загрузчике (для MBR этой информацией является Disk Partition Table, для Boot-сектора дискет - BIOS Parameter Block). В противном случае система окажется неспособной загрузить себя, поскольку дисковые адреса компонент системы высчитываются на основе этой информации. Такие вирусы довольно легко удаляются переписыванием заново кода системного загрузчика в boot-секторе и MBR — для этого необходимо загрузиться с незараженной системной дискеты и использовать команды SYS для обезвреживания дискет и логических дисков винчестера или FDISK/MBR для лечения зараженного MBR-сектора. В случае стелс-вируса диск может быть «оживлен» либо переформатированием с потерей всей информации, либо восстановлением Disk Partition Table «вручную». Следует также отметить тот факт, что загрузочные вирусы очень редко «уживаются» вместе на одном диске — часто они используют одни и те же дисковые сектора для размещения своего кода/данных. В результате код/данные первого вируса оказываются испорченными при заражении вторым вирусом, и система либо зависает при загрузке, либо зацикливается (что также приводит к ее зависанию).
К данной группе относятся вирусы, которые при своем размножении тем или иным способом используют файловую систему какой-либо (или каких-либо) ОС. Файловые вирусы внедряются в: командные файлы (BAT), загружаемые драйверы (SYS, в том числе специальные файлы IO.SYS и MSDOS.SYS) и выполняемые двоичные файлы (EXE, COM), исполняемые файлы ОС (Windows 3.x, Windows95/NT, OS/2, Macintosh, UNIX, включая VxD-драйвера Windows 3.x и Windows95), исходные тексты программ, библиотечные или объектные модули. Возможна запись вируса и в файлы данных, но это случается либо в результате ошибки вируса, либо при проявлении его агрессивных свойств.
По способу заражения файлов вирусы делятся на «overwriting», паразитические («parasitic»), компаньон-вирусы («companion»), «link»-вирусы, вирусы-черви и вирусы, заражающие объектные модули (OBJ), библиотеки компиляторов (LIB) и исходные тексты программ.
Overwriting. Данный метод заражения является наиболее простым: вирус записывает свой код вместо кода заражаемого файла, уничтожая его содержимое. При этом файл перестает работать и не восстанавливается. Такие вирусы очень быстро обнаруживают себя, так как операционная система и приложения довольно быстро перестают работать. К разновидности overwriting-вирусов относятся вирусы, которые записываются вместо DOS-заголовка NewEXE-файлов. Основная часть файла при этом остается без изменений и продолжает нормально работать в соответствующей операционной системе, однако DOS-заголовок оказывается испорченным.
Эти файловые вирусы при распространении своих копий обязательно изменяют содержимое файлов, оставляя сами файлы при этом полностью или частично работоспособными. Основными типами таких вирусов являются вирусы, записывающиеся в начало файлов («prepending»), в конец файлов («appending») и в середину файлов («inserting»). В свою очередь, внедрение вирусов в середину файлов происходит различными методами - путем переноса части файла в его конец или копирования своего кода в заведомо неиспользуемые данные файла («cavity»-вирусы).
Внедрение вируса в начало файла
Известны два способа внедрения паразитического файлового вируса в начало файла.
1) вирус переписывает начало заражаемого файла в его конец, а сам копируется в освободившееся место. 2) вирус создает в оперативной памяти свою копию, дописывает к ней заражаемый файл и сохраняет полученную конкатенацию на диск. Некоторые вирусы при этом дописывают в конец файла блок дополнительной информации (например, вирус «Jerusalem» по этому блоку отличает зараженные файлы от не зараженных).
Внедрение вируса в начало файла применяется в подавляющем большинстве случаев при заражении BAT- и COM-файлов, а иногда и EXE-файлов. При этом вирусы, чтобы сохранить работоспособность программы, либо лечат зараженный файл, повторно запускают его, ждут окончания его работы и снова записываются в его начало (иногда для этого используется временный файл, в который записывается обезвреженный файл), либо восстанавливают код программы в памяти компьютера и настраивают необходимые адреса в ее теле (т.е. дублируют работу ОС).
Внедрение вируса в конец файла
При этом вирус изменяет начало файла таким образом, что первыми выполняемыми командами программы, содержащейся в файле, являются команды вируса.
В DOS COM-файле в большинстве случаев это достигается изменением его первых трех (или более) байтов на коды инструкции JMP Loc_Virus (или в более общем случае - на коды программы, передающей управление на тело вируса). DOS EXE-файл переводится в формат COM-файла и затем заражается, как COM-файл, либо модифицируется заголовок файла.
Внедрение вируса в середину файла
Существует несколько методов внедрения вируса в середину файла. В наиболее простом из них вирус переносит часть файла в его конец или «раздвигает» файл и записывает свой код в освободившееся пространство. Этот cпособ во многом аналогичен методам, перечисленным выше. Некоторые вирусы при этом компрессируют переносимый блок файла так, что длина файла при заражении не изменяется («Mutant»). Вторым является метод «cavity», при котором вирус записывается в заведомо неиспользуемые области файла. Вирус может быть скопирован в незадействованные области таблицы настройки адресов DOS EXE-файла («BootExe») или заголовок NewEXE-файла («Win95.Murkry»), в область стека файла COMMAND.COM («Lehigh») или в область текстовых сообщений популярных компиляторов («NMSG»). Кроме того, копирование вируса в середину файла может произойти в результате ошибки вируса, в этом случае файл может быть необратимо испорчен.
Отдельно следует отметить довольно незначительную группу вирусов, не имеющих «точки входа» (EPO-вирусы - Entry Point Obscuring viruses). К ним относятся вирусы, не записывающие команд передачи управления в заголовок COM-файлов (JMP) и не изменяющие адрес точки старта в заголовке EXE-файлов. Такие вирусы записывают команду перехода на свой код в какое-либо место в середину файла и получают управление не непосредственно при запуске зараженного файла, а при вызове процедуры, содержащей код передачи управления на тело вируса. Причем выполняться эта процедура может крайне редко (например, при выводе сообщения о какой-либо специфической ошибке). В результате вирус может долгие годы «спать» внутри файла и выскочить на свободу только при некоторых ограниченных условиях.(«Lucretia», «Zhengxi»,«CNTV», «MidInfector», «NexivDer», «Avatar.Positron», «Markiz»)
К категории «компаньон» относятся вирусы, не изменяющие заражаемых файлов. Алгоритм работы этих вирусов состоит в том, что для заражаемого файла создается файл-двойник, причем при запуске зараженного файла управление получает именно этот двойник, т.е. вирус. Наиболее распространены компаньон-вирусы, использующие особенность DOS первым выполнять .COM-файл, если в одном каталоге присутствуют два файла с одним и тем же именем, но различными расширениями имени - .COM и .EXE. Такие вирусы создают для EXE-файлов файлы-спутники, имеющие то же самое имя, но с расширением .COM. Вирус записывается в COM-файл и никак не изменяет EXE-файл. При запуске такого файла DOS первым обнаружит и выполнит COM-файл, т.е. вирус, который затем запустит и EXE-файл. Некоторые вирусы используют не только вариант COM-EXE, но также и BAT-COM-EXE. Вторую группу составляют вирусы, которые при заражении переименовывают файл в какое-либо другое имя, запоминают его (для последующего запуска файла-хозяина) и записывают свой код на диск под именем заражаемого файла. При запуске управление получает код вируса, который затем запускает оригинальный файл.
Файловые черви (worms) при размножении они копируют свой код в какие-либо каталоги дисков в надежде, что эти новые копии будут когда-либо запущены пользователем. Иногда эти вирусы дают своим копиям «специальные» имена, чтобы подтолкнуть пользователя на запуск своей копии - например, INSTALL.EXE или WINSTART.BAT. Существуют вирусы-черви, использующие довольно необычные приемы, например, записывающие свои копии в архивы (ARJ, ZIP и прочие). К таким вирусам относятся «ArjVirus» и «Winstart». Некоторые вирусы записывают команду запуска зараженного файла в BAT-файлы (см. например, «Worm.Info»).
Link-вирусы, как и компаньон-вирусы не изменяют физического содержимого файлов, однако при запуске зараженного файла «заставляют» ОС выполнить свой код. Этой цели они достигают модификацией необходимых полей файловой системы. Примером Link-вирусов являются вирусы семейства «Dir_II». При заражении системы они записывают свое тело в последний кластер логического диска. При заражении файла вирусы корректируют лишь номер первого кластера файла, расположенный в соответствующем секторе каталога. Новый начальный кластер файла будет указывать на кластер, содержащий тело вируса. Таким образом, при заражении файлов их длины и содержимое кластеров диска, содержащих эти файлы, не изменяется, а на все зараженные файлы на одном логическом диске будет приходиться только одна копия вируса.
Вирусы, заражающие OBJ- и LIB-файлы, записывают в них свой код в формате объектного модуля или библиотеки. Носителем «живого» вируса становится COM- или EXE-файл, получаемый в процессе линковки зараженного OBJ/LIB-файла с другими объектными модулями и библиотеками. Таким образом, вирус распространяется в два этапа: на первом заражаются OBJ/LIB-файлы, на втором этапе (линковка) получается работоспособный вирус.
Заражение исходных текстов программ является логическим продолжением предыдущего метода размножения. При этом вирус добавляет к исходным текстам свой исходный код (в этом случае вирус должен содержать его в своем теле) или свой шестнадцатеричный дамп (что технически легче). Зараженный файл способен на дальнейшее распространение вируса только после компиляции и линковки (например, вирусы «SrcVir», «Urphin»).
Получив управление, вирус совершает следующие действия:
· резидентный вирус проверяет оперативную память на наличие своей копии и инфицирует память компьютера, если копия вируса не найдена. Нерезидентный вирус ищет незараженные файлы в текущем и (или) корневом оглавлении, в оглавлениях, отмеченных командой PATH, сканирует дерево каталогов логических дисков, а затем заражает обнаруженные файлы;
· возвращает управление основной программе (если она есть). Паразитические вирусы при этом либо a) лечат файл, выполняют его, а затем снова заражают, либо б) восстанавливает программу (но не файл) в исходном виде (например, у COM-программы восстанавливается несколько первых байт, у EXE-программы вычисляется истинный стартовый адрес, у драйвера восстанавливаются значения адресов программ стратегии и прерывания). Компаньон-вирусы запускают на выполнение своего «хозяина», вирусы-черви и overwriting-вирусы возвращают управление DOS.
Макро-вирусы (macro viruses) являются программами на языках (макро-языках), встроенных в некоторые системы обработки данных (текстовые редакторы, электронные таблицы и т.д.). Для своего размножения такие вирусы используют возможности макро-языков и при их помощи переносят себя из одного зараженного файла (документа или таблицы) в другие. Наибольшее распространение получили макро-вирусы для Microsoft Word, Excel и Office97. Существуют также макро-вирусы, заражающие документы Ami Pro и базы данных Microsoft Access. Все перечисленные программы имеют встроенный макро-язык Visual Basic for Applications с возможностями:
1.привязки программы на макро-языке к конкретному файлу;
2.копирования макро-программ из одного файла в другой;
3.возможность получения управления макро-программой без вмешательства пользователя (автоматические или стандартные макросы).
Данная особенность макро-языков позволяют вирусу переносить свой код в другие файлы, и таким образом заражать их. Макро-вирусы получают управление при открытии или закрытии зараженного файла, перехватывают стандартные файловые функции и затем заражают файлы, к которым каким-либо образом идет обращение. По аналогии с MS-DOS можно сказать, что большинство макро-вирусов являются резидентными: они активны не только в момент открытия/закрытия файла, но до тех пор, пока активен сам редактор.
Макро-вирусы, поражающие файлы Word, Excel или Office97 как правило пользуются одним из трех перечисленных выше приемов — в вирусе либо присутствует авто-макрос (авто-функция), либо переопределен один из стандартных системных макросов (ассоциированный с каким-либо пунктом меню), либо макрос вируса вызывается автоматически при нажатии на какую-либо клавишу или комбинацию клавиш. Существуют также полу-вирусы, которые не используют всех этих приемов и размножаются, только когда пользователь сомостоятельно запускает их на выполнение. Если документ заражен, при открытии документа Word вызывает зараженный автоматический макрос AutoOpen (или AutoClose при закрытии документа) и, таким образом, запускает код вируса, если это не запрещено системной переменной DisableAutoMacros. Если вирус содержит макросы со стандартными именами, они получают управление при вызове соответствующего пункта меню (File/Open, File/Close, File/SaveAs). Если же переопределен какой-либо символ клавиатуры, то вирус активизируется только после нажатия на соответствующую клавишу.
Большинство макро-вирусов содержат все свои функции в виде стандартных макросов Word/Excel/Office97. Существуют, однако, вирусы, использующие приемы скрытия своего кода и хранящие свой код в виде не-макросов. Известно три подобных приема, все они используют возможность макросов создавать, редактировать и исполнять другие макросы. Как правило подобные вирусы имеют небольшой (иногда — полиморфный) макрос-загрузчик вируса, который вызывает встроенный редактор макросов, создает новый макрос, заполняет его основным кодом вируса, выполняет и затем, как правило, уничтожает (чтобы скрыть следы присутствия вируса). Основной код таких вирусов присутствует либо в самом макросе вируса в виде текстовых строк (иногда — зашифрованных), либо хранится в области переменных документа или в области Auto-text.
Характерными проявлениями макро-вирусов являются:
• Word: невозможность конвертирования зараженного документа Word в другой формат.
• Word: зараженные файлы имеют формат Template (шаблон), поскольку при заражении Word-вирусы конвертируют файлы из формата Word Document в Template.
• только Word 6: невозможность записи документа в другой каталог/на другой диск по команде «Save As».
• Excel/Word: в STARTUP-каталоге присутствуют «чужие» файлы.
• Excel версий 5 и 7: наличие в Книге (Book) лишних и скрытых Листов (Sheets).
Большинство известных Word-вирусов (версий 6, 7 и Word97) при запуске переносят свой код (макросы) в область глобальных макросов документа («общие» макросы). Для этого они используют команды копирования макросов MacroCopy, Organizer.Copy либо при помощи редактора макросов — вирус вызывает его, создает новый макрос, вставляет в него свой код, который и сохраняет в документе.
При выходе из Word глобальные макросы (включая макросы вируса) автоматически записываются в DOT-файл глобальных макросов (обычно таким файлом является NORMAL.DOT). Таким образом, при следующем запуске редактора MS-Word вирус активизируется в тот момент, когда WinWord грузит глобальные макросы, т.е. сразу.
Затем вирус переопределяет (или уже содержит в себе) один или несколько стандартных макросов (например, FileOpen, FileSave, FileSaveAs, FilePrint) и перехватывает, таким образом, команды работы с файлами. При вызове этих команд вирус заражает файл, к которому идет обращение. Для этого вирус конвертирует файл в формат Template (что делает невозможной дальнейшие изменения формата файла, т.е. конвертирование в какой-либо не-Template формат) и записывает в файл свои макросы, включая Auto-макрос.
Таким образом, если вирус перехватывает макрос FileSaveAs, то заражается каждый DOC-файл, сохраняемый через перехваченный вирусом макрос. Если перехвачен макрос FileOpen, то вирус записывается в файл при его считывании с диска. Второй способ внедрения вируса в систему используется значительно реже — он базируется на так называемых «Add-in» файлах, т.е. файлах, являющихся служебными дополнениями к Word. В этом случае NORMAL.DOT не изменяется, а Word при запуске загружает макросы вируса из файла (или файлов), определенного как «Add-in». Этот способ практически полностью повторяет заражение глобальных макросов за тем исключением, что макросы вируса храняться не в NORMAL.DOT, а в каком-либо другом файле.
Рассмотренные выше способы внедрения в систему представляют собой некоторый аналог резидентных DOS-вирусов. Аналогом нерезидентности являются макро-вирусы, которые для заражения других файлов-документов либо ищут их при помощи встроенных в Word функций работы с файлами, либо обращаются к списку последних редактированных файлов (Recently used file list). Затем такие вирусы открывают документ, заражают его и закрывают.
К полиморфик-вирусам относятся те из них, детектирование которых невозможно (или крайне затруднительно) осуществить при помощи так называемых вирусных масок - участков постоянного кода, специфичных для конкретного вируса. Достигается это двумя основными способами - шифрованием основного кода вируса с непостоянным ключем и случаным набором команд расшифровщика или изменением самого выполняемого кода вируса.
Существуют также другие, достаточно экзотические примеры полиморфизва - DOS-вирус "Bomber", например, не зашифрован, однако последовательность команд, которая передает управление коду вируса, является полностью полиморфной. Полиморфизм различной степени сложности встречается в вирусах всех типов - от загрузочных и файловых DOS-вирусов до Windows-вирусов и даже макро-вирусов.
Полноценные полиморфик-вирусы используют сложные алгоритмы, в результате работы которых в расшифровщике вируса могут встретиться практически все инструкции процессора (Intel ADD, SUB, TEST, XOR, OR, SHR, SHL, ROR, MOV, XCHG, JNZ, PUSH, POP ...) со всеми возможными режимами адресации. В результате в начале файла, зараженного подобным вирусом, идет набор бессмысленных на первый взгляд инструкций, причем некоторые комбинации, которые вполне работоспособны, не берутся фирменными дизассемблерами (например, сочетание CS:CS: или CS:NOP). И среди этой "каши" из команд и данных изредка проскальзывают MOV, XOR, LOOP, JMP - инструкции, которые действительно являются "рабочими".
Существует деление полиморфик-вирусов на уровни в зависимости от сложности кода, который встречается в расшифровщиках этих вирусов. Такое деление впервые предложил д-р. Алан Соломон, через некоторое время Весселин Бончев расширил его.
1: вирусы, которые имеют некоторый набор расшифровщиков с постоянным кодом и при заражении выбирают один из них. Такие вирусы являются "полу-полиморфиками" и носят также название "олигоморфик". Примеры: "Cheeba", "Slovakia", "Whale".
2: расшифровщик вируса содержит одну или несколько постоянных инструкций, основная же его часть непостоянна.
3: расшифровщик содержит неиспользуемые инструкции - "мусор" типа NOP, CLI, STI.
4: в расшифровщике используются взаимозаменяемые инструкции и изменение порядка следование (перемешивание) инструкций. Алгоритм расшифрования при этом не изменяется.
5: используются все перечисленные выше приемы, алгоритм расшифрования непостоянен, возможно повторное шифрование кода вируса и даже частичное шифрование самого кода расшифровщика.
6: permutating-вирусы. Изменению подлежит основной код вируса - он делится на блоки, которые при заражении переставляются в произвольном порядке. Вирус при этом остается работоспособным. Подобные вирусы могут быть незашифрованы.
Это деление имеет ряд недостатков, т.к. производится по единственному критерию - возможность детектировать вирус по коду расшифровщика при помощи стандартного приема вирусных масок:
1: для детектирования вируса достаточно иметь несколько масок
2: детектирование по маске с использованием "wildcards"
3: детектирование по маске после удаления инструкций-"мусора"
4: маска содержит несколько вариантов возможного кода, т.е. становится алгоритми-ческой
5: невозможность детектирования вируса по маске
Недостаточность такого деления продемонстрирована в вирусе 3-го уровня полиморфичности, который так и называется - "Level3". Этот вирус, являясь одним из наиболее сложных полиморфик-вирусов, по приведенному выше делению попадает в Уровень 3, поскольку имеет постоянный алгоритм расшифровки, перед которым стоит большое количество команд-"мусора". Однако в этом вирусе алгоритм генерирования "мусора" доведен до совершенства: в коде расшифровщика могут встретиться практически все инструкции процессора i8086.
Можно произвести более объективное деление, в котором помимо критерия вирусных масок участвуют и другие параметры.
1.Степень сложности полиморфик-кода (процент от всех инструкций процессора, которые могут встретиться в коде расшифровщика)
2.Использование анти-эмуляторных приемов
3.Постоянство алгоритма расшифровщика
4.Постоянство длины расшифровщика
Наиболее часто подобный способ полиморфизма используется макро-вирусами, которые при создании своих новых копий случайным образом меняют имена своих переменных, вставляют пустые строки или меняют свой код каким-либо иным способом. Таким образом, алгоритм работы вируса остается без изменений, но код вируса практически полностью меняется от заражения к заражению.
Реже этот способ применяется сложными загрузочными вирусами. Такие вирусы внедряют в загрузочные сектора лишь достаточно короткую процедуру, которая считывает с диска основной код вируса и передает на него управление. Код этой процедуры выбирается из нескольких различных вариантов (которые также могут быть разбавлены "пустыми" командами), команды переставляются между собой и т.д.
Среди файловых вирусов, применяющих полиморфизм, существуют такие, как "Ply", ”ТМС”. "Ply" случайным образом перемещает свои команды по своему телу и заменяет их на команды JMP или CALL. "TMC" использует более сложный способ - каждый раз при заражении вирус меняет местами блоки своего кода и данных, вставляет "мусор", в своих ассемблерных инструкциях устанавлявает новые значения оффсетов на данные, меняет константы и т.д. В результате, хотя вирус и не шифрует свой код, он является полиморфик-вирусом - в коде не присутствует постоянного набора команд. Более того, при создании своих новых копий вирус меняет свою длину.
Стелс-вирусы теми или иными способами скрывают факт своего присутствия в системе. Известны стелс-вирусы всех типов.
Загрузочные стелс-вирусы для скрытия своего кода используют два основных способа. Первый из них заключается в том, что вирус перехватывает команды чтения зараженного сектора (INT 13h) и подставляет вместо него незараженный оригинал. Этот способ делает вирус невидимым для любой DOS-программы, включая антивирусы, неспособные "лечить" оперативную память компьютера. Возможен перехват команд чтения секторов на уровне более низком, чем INT 13h.
Второй способ направлен против антивирусов, поддерживающих команды прямого чтения секторов через порты контроллера диска. Такие вирусы при запуске любой программы (включая антивирус) восстанавливают зараженные сектора, а после окончания ее работы снова заражают диск. Поскольку для этого вирусу приходится перехватывать запуск и окончание работы программ, то он должен перехватывать также DOS-прерывание INT 21h.
С некоторыми оговорками стелс-вирусами можно назвать вирусы, которые вносят минимальные изменения в заражаемый сектор (например, при заражении MBR правят только активный адрес загрузочного сектора - изменению подлежат только 3 байта), либо маскируются под код стандартного загрузчика.
Большинcтво файловых стелс вирусов использует те же приемы, что приведены выше: они либо перехватывают DOS-вызовы обращения к файлам (INT 21h) либо временно лечат файл при его открытии и заражают при закрытии. Также как и для загрузочных вирусов, существуют файловые вирусы, использующие для своих стелс-функций перехват прерываний более низкого уровня - вызовы драйверов DOS, INT 25h и даже INT 13h.
Полноценные файловые стелс-вирусы, использующие первый способ скрытия своего кода, в большинстве своем достаточно громоздки, поскольку им приходиться перехватывать большое количество DOS-функций работы с файлами: открытие/закрытие, чтение/запись, поиск, запуск, переименование и т.д., причем необходимо поддерживать оба варианта некоторых вызовов (FCB/ASCII), а после появления Windows95/NT им стало необходимо также обрабатывать третий вариант - функции работы с длинными именами файлов.
Некоторые вирусы используют часть функций полноценного стелс-вируса. Чаще всего они перехватывают функции DOS FindFirst и FindNext (INT 21h, AH=11h, 12h, 4Eh, 4Fh) и "уменьшают" размер зараженных файлов. Такой вирус невозможно определить по изменению размеров файлов, если он резидентно находится в памяти. Программы, которые не используют указанные функции DOS (например, "Нортоновские утилиты"), а напрямую используют содержимое секторов, хранящих каталог, показывают правильную длину зараженных файлов.
Реализация стелс-алгоритмов в макро-вирусах является, наверное, наиболее простой задачей - достаточно всего лишь запретить вызов меню File/Templates или Tools/Macro. Достигается это либо удалением этих пунктов меню из списка, либо их подменой на макросы FileTemplates и ToolsMacro. Частично стелс-вирусами можно назвать небольшую группу макро-вирусов, которые хранят свой основной код не в самом макросе, а в других областях документа - в его переменных или в Auto-text.
Под термином "резидентность" (DOS'овский термин TSR - Terminate and Stay Resident) понимается способность вирусов оставлять свои копии в системной памяти, перехватывать некоторые события (например, обращения к файлам или дискам) и вызывать при этом процедуры заражения обнаруженных объектов (файлов и секторов).
Таким образом, резидентные вирусы активны не только в момент работы зараженной программы, но и после того, как программа закончила свою работу. Резидентные копии таких вирусов остаются жизнеспособными вплоть до очередной перезагрузки, даже если на диске уничтожены все зараженные файлы. Часто от таких вирусов невозможно избавиться восстановлением всек копий файлов с дистрибутивных дисков или backup-копий. Резидентная копия вируса остается активной и заражает вновь создаваемые файлы. То же верно и для загрузочных вирусов — форматирование диска при наличии в памяти резидентного вируса не всегда вылечивает диск, поскольку многие резидентные вирусы заражает диск повторно после того, как он отформатирован.
Для того чтобы оставить выполняемый код в памяти Windows, существует три способа. Самый простой способ - зарегистрировать программу как одно из приложений, работающих в данный момент. Для этого программа регистрирует свою задачу, окно которой может быть скрытым, регистрирует свой обработчик системных событий и т.д. Второй способ - выделить блок системной памяти при помощи DPMI-вызовов и скопировать в него свой код (вирус Ph33r). Третий способ — остаться резидентно как VxD-драйвер (Wnidows 3.xx и Windows95) или как драйвер Windows NT.
Перехват обращений к файлам производится одним из двух способов - либо перехватываются вызовы INT 21h (Hook_V86_Int_Chain, Get/Set_V86_Int_Vector, Get/Set_PM_Int_Vector), либо перехватывается системный вызов API. Затем резидентные Windows-вирусы действуют примерно также, как и DOS-вирусы: перехватывают обращения к файлам и заражают их.
Для обнаружения уже присутствующей в памяти резидентной копии используются примерно те же способы, что описаны выше, за исключением VxD-вирусов. Известные VxD-вирусы загружаются в память при загрузке Windows. Для этого они записывают команду запуска в файл конфигурации Windows SYSTEM.INI. Если в этом файле уже есть команда запуска вирусного VxD-файла, то вирус не производит повторной регистрации своего VxD-файла.
Большинство макро-вирусов можно считать резидентными, поскольку они присутствуют в области системных макросов в течение всего времени работы редактора. Они так же как резидентные загрузочные и файловые вирусы перехватывают системные события и используют их для своего размножения. К подобным событиям относятся различные системные вызовы, возникающие при работе с документами Word и таблицами Excel (открытие, закрытие, создание, печать и т.д.), вызов пункта меню, нажатие на какую-либо клавишу или достижение какого-либо момента времени. Для перехвата событий макро-вирусы переопределяют один или несколько системных макросов или функций.
При заражении некоторые макро-вирусы проверяют наличие своей копии в заражаемом объекте и повторно себя не копируют. Другие макро-вирусы не делают этого и переписывают свой код при каждом заражении. Если при этом в заражаемом файле или области системных макросов уже определен макрос, имя которого совпадает с макросом вируса, то такой макрос оказывается уничтоженным.
К "вредным программам", помимо вирусов, относятся также троянские кони (логические бомбы), хакерские утилиты скрытого администрирования удаленных компьютеров ("backdoor"), программы, "ворующие" пароли доступа к ресурсам Интернет и прочую конфиденциальную информацию; а также "intended" -вирусы, конструкторы вирусов и полиморфик-генераторы.
К троянским коням относятся программы, наносящие какие-либо разрушительные действия, т.е. в зависимости от каких-либо условий или при каждом запуске уничтожающая информацию на дисках, "завешивающая" систему и т.п.
Большинство троянских коней являются программами, которые "подделываются" под какие-либо полезные программы, новые версии популярных утилит или дополнения к ним. Очень часто они рассылаются по BBS-станциям или электронным конференциям. К "троянским коням" также можно отнести "дропперы" вирусов - зараженные файлы, код которых подправлен таким образом, что известные версии антивирусов не определяют вируса в файле. Например, файл шифруется каким-либо специальным образом или упаковывается редкоиспользуемым архиватором, что не позволяет антивирусу "увидеть" заражение.
Следует отметить также "злые шутки" (hoax). К ним относятся программы, которые не причиняют компьютеру какого-либо прямого вреда, однако выводят сообщения о том, что такой вред уже причинен, либо будет причинен при каких-либо условиях, либо предупреждают пользователя о несуществующей опасности. К "злым шуткам" отностяся, например, программы, которые "пугают" пользователя сообщениями о форматировании диска (хотя никакого форматирования на самом деле не происходит), детектируют вирусы в незараженных файлах (как это делает широко известная программа ANTITIME), выводят странные вирусоподобные сообщения (драйвер диска CMD640X от какого-то коммерческого пакета) и т.д. - в зависимости от чувства юмора автора такой программы. К такой же категории "злых шуток" можно отнести также заведомо ложные сообщения о новых супер-вирусах. Такие сообщения периодически появляются в электронных конференциях и обычно вызывают панику среди пользователей.
По своей функциональности они во многом напоминают различные системы администрирования, разрабатываемые и распространяемые различными фирмами-производителями программных продуктов. Единственная особенность этих программ заставляет классифицировать их как вредные троянские программы: отсутствие предупреждения об инсталляции и запуске. При запуске троянец устанавливает себя в системе и затем следит за ней, при этом пользователю не выдается никаких сообщений о действиях троянца в системе. Более того, ссылка на троянца может отсутствовать в списке активных приложений.
В результате "пользователь" этой троянской программы может и не знать о ее присутствии в системе, в то время как его компьютер открыт для удаленного управления.
Будучи установленными на компьютер, утилиты скрытого управления позволяют делать с компьютером все, что в них заложил их автор: принимать/отсылать файлы, запускать и уничтожать их, выводить сообщения, стирать информацию, перезагружать компьютер и т.д. В результате эти троянцы могут быть использованы для обнаружения и передачи конфиденциальной информации, для запуска вирусов, уничтожения данных и т.п. - пораженные компьютеры оказываются открытыми для злоумышленных действий хакеров.
К таким вирусам относятся программы, которые на первый взгляд являются стопроцентными вирусами, но не способны размножаться по причине ошибок. Например, вирус, который при заражении "забывает" поместить в начало файлов команду передачи управления на код вируса, либо записывает в нее неверный адрес своего кода, либо неправильно устанавливает адрес перехватываемого прерывания (что в подавляющем большинстве случаев завешивает компьютер) и т.д. К категории "intended" также относятся вирусы, которые по приведенным выше причинам размножаются только один раз - из "авторской" копии. Заразив какой-либо файл, они теряют способность к дальнейшему размножению.Появляются intended-вирусы чаще всего при неумелой перекомпиляции какого-либо уже существующего вируса, либо по причине недостаточного знания языка программирования, либо по причине незнания технических тонкостей операционной системы.
Конструктор вирусов - это утилита, предназначенная для изготовления новых компьютерных вирусов. Известны конструкторы вирусов для DOS, Windows и макро-вирусов. Они позволяют генерировать исходные тексты вирусов (ASM-файлы), объектные модули, и/или непосредственно зараженные файлы.
Некоторые конструктороы (VLC, NRLG) снабжены стандартным оконным интерфейсом, где при помощи системы меню можно выбрать тип вируса, поражаемые объекты (COM и/или EXE), наличие или отсутствие самошифровки, противодействие отладчику, внутренние текстовые строки, выбрать эффекты, сопровождающие работу вируса и т.п. Прочие конструкторы (PS-MPC, G2) не имеют интерфейса и считывают информацию о типе вируса из конфигурационного файла.
Полиморфик-генераторы, как и конструкторы вирусов, не являются вирусами в прямом смысле этого слова, поскольку в их алгоритм не закладываются функции размножения, т.е. открытия, закрытия и записи в файлы, чтения и записи секторов и т.д.
Главной функцией подобного рода программ является шифрование тела вируса и генерация соответствующего расшифровщика. Обычно полиморфные генераторы распространяются их авторами без ограничений в виде файла-архива. Основным файлом в архиве любого генератора является объектный модуль, содержащий этот генератор. Во всех встречавшихся генераторах этот модуль содержит внешнюю (external) функцию - вызов программы генератора.
Таким образом, автору вируса, если он желает создать настоящий полиморфик-вирус, не приходится корпеть над кодами собственного за/расшифровщика. При желании он может подключить к своему вирусу любой известный полиморфик-генератор и вызывать его из кодов вируса. Физически это достигается следующим образом: объектный файл вируса линкуется с объектным файлом генератора, а в исходный текст вируса перед командами его записи в файл вставляется вызов полиморфик-генератора, который создает коды расшифровщика и шифрует тело вируса.
IRC (Internet Relay Chat) — это специальный протокол, разработанный для коммуникации пользователей Интернет в реальном времени. Этот протокол предоставлят возможность Итрернет-"разговора" при помощи специально разработанного программного обеспечения. Для поддержки IRC-конференций созданы различные IRC-сервера, к которым подключаются участники IRC-"разговоров". Для подключения к IRC-серверу и ведения IRC-"разговоров" разработаны специальные программы - IRC-клиенты. Среди прочих возможностей IRC-клиенты сущетсвует возможность передавать и принимать файлы - именно на этой возможности и базируются IRC-черви.
На компьютерах с MS Windows самыми распространенными клиентами являются mIRC и PIRCH. Эти программные продукты имеют массу возможностей, среди которых сценарии работы (скрипты) и задание автоматической реакции на различные события. На основе скриптов можно создавать компьютерные вирусы, передающие свой код на компьютеры пользователей сетей IRC, так называемые "IRC-черви". Первый инцидент с IRC-червем зафиксирован в конце 1997 года: пользователями mIRC-клиента был обнаружен скрипт (файл SCRIPT.INI), переносивший свой код через каналы IRC и заражавший mIRC-клиентов на компьютерах пользователей, подключавшихся к зараженным каналам. Принцип действия IRC-червей таков: при помощи IRC-команд файл сценария работы (скрипт) или реакции на IRC-события автоматически посылается с зараженного компьютера каждому вновь присоединившемуся к каналу пользователю. Присланный файл-сценарий замещает стандартный и при следующем сеансе работы уже вновь зараженный клиент будет рассылать червя. Черви при этом используют особенности конфигурации клиента (всех версий mIRC младше 5.31 и всех версий PIRCH до PIRCH98), благодаря которой принимаемые файлы всех типов помещаются в корневой каталог клиента. Этот каталог также содержит и основные скрипты клиента, включая авто-загружаемые mIRC-скрипты SCRIPT.INI, MIRC.INI и PIRCH-скрипт EVENTS.INI. Данные скрипты автоматически исполняются клиентом при старте и в дальнейшем используются как основной сценарий его работы.
Некоторые IRC-черви также содержат троянский компонент: по заданным ключевым словам производят разрушительные действия на пораженных компьютерах. Например, червь "pIRCH.Events" по определенной команде стирает все файлы на диске пользователя. В скрипт-языках клиентов mIRC и PIRCH также существуют операторы для запуска обычных команд операционной системы и исполняемых модулей (программ) DOS и Windows. Эта возможность IRC-скриптов послужила основой для появления скрипт-червей нового поколения, которые помимо скриптов заражали компьютеры пользователей EXE-вирусами, устанавливали "троянских коней", и т.п. Скрипт-черви работоспособны только в том случае, если пользователь разрешает копирование файлов из сети на свой компьютер. Следует отметить, что фирма-изготовитель клиента mIRC отреагировала достаточно оперативно и буквально через несколько дней после появления первого червя выпустила новую версию своего клиента, в которой были закрыты пробелы в защите.
К сетевым относятся вирусы, которые для своего распространения активно используют протоколы и возможности локальных и глобальных сетей. Основным принципом работы сетевого вируса является возможность самостоятельно передать свой код на удаленный сервер или рабочую станцию. «Полноценные» сетевые вирусы при этом обладают еще и возможностью запустить на выполнение свой код на удаленном компьютере или, по крайней мере, «подтолкнуть» пользователя к запуску зараженного файла.
Наибольшую известность приобрели сетевые вирусы конца 1980-х, их также называют сетевыми червями (worms). К ним относятся вирус Морриса, вирусы «Cristmas Tree» и «Wank Worms». Для своего распространения они использовали ошибки и недокументированные функции глобальных сетей того времени - вирусы передавали свои копии с сервера на сервер и запускали их на выполнение. В случае с вирусов Морриса эпидемия захватила аж несколько глобальных сетей в США.
Сетевые вирусы распространяясь в компьютерной сети, проникают в память компьютера из компьютерной сети, обращаются к адресной книге и используя храняшиеся в ней адреса, рассылают по ним свои копии. Эти вирусы иногда могут создавать рабочие файлы на дисках системы. Современные сетевые вирусы пользуются объединеными возможностями встроенного в Word/Excel языка Basic, протоколами и особенностями электронной почты и функциями авто-запуска, необходимые для распространения вируса.
Например,«Macro.Word.ShareFun» создает новое письмо, содержащее зараженный файл-документ («ShareFun» является макро-вирусом), затем выбирает из списка адресов MS-Mail три случайных адреса и рассылает по ним зараженное письмо. Поскольку многие пользователи устанавливают параметры MS-Mail таким образом, что при получении письма автоматически запускается MS Word, то вирус «автоматически» внедряется в компьютер адресата зараженного письма.
Некороые вирусы используют для своего распространения протокол FTP и передает свою копию на удаленный ftp-сервер в каталог Incoming «Win.Homer».
Самыми популярными и эффективными антивирусными программами являются антивирусные сканеры (другие названия: фаги, полифаги). Следом за ними по эффективности и популярности следуют CRC-сканеры (также: ревизор, checksumer, integrity checker). Часто оба приведенных метода объединяются в одну универсальную антивирусную программу, что значительно повышает ее мощность. Применяются также различного типа блокировщики и иммунизаторы.
Принцип работы антивирусных сканеров основан на проверке файлов, секторов и системной памяти и поиске в них известных и новых (неизвестных сканеру) вирусов. Для поиска известных вирусов используются так называемые «маски», т.е постоянные последовательности кода, специфичные для конкретного вируса. Также используются алгоритмический язык, описывающий все возможные варианты кода, которые могут встретиться при заражении подобного типа вирусом. Во многих сканерах используются также алгоритмы «эвристического сканирования», т.е. анализ последовательности команд в проверяемом объекте, набор некоторой статистики и принятие решения («возможно, заражен» или «не заражен») для каждого проверяемого объекта.
Сканеры также можно разделить на две категории — «универсальные» и «специализированные». Универсальные сканеры рассчитаны на поиск и обезвреживание всех типов вирусов вне зависимости от операционной системы, на работу в которой рассчитан сканер. Специализированные сканеры предназначены для обезвреживания ограниченного числа вирусов или только одного их класса, например макро-вирусов. Сканеры также делятся на «резидентные» (мониторы), производящие сканирование «на-лету», и «нерезидентные», обеспечивающие проверку системы только по запросу. Как правило, «резидентные» сканеры обеспечивают более надежную защиту системы, поскольку они немедленно реагируют на появление вируса, в то время как «нерезидентный» сканер способен опознать вирус только во время своего очередного запуска.
К достоинствам сканеров всех типов относится их универсальность, к недостаткам — размеры антивирусных баз, которые сканерам приходится «таскать за собой», и относительно небольшую скорость поиска вирусов.
Принцип работы CRC-сканеров основан на подсчете CRC-сумм (контрольных сумм) для присутствующих на диске файлов/системных секторов. Эти CRC-суммы затем сохраняются в базе данных антивируса, как, впрочем, и некоторая другая информация: длины файлов, даты их последней модификации и т.д. При последующем запуске CRC-сканеры сверяют данные, содержащиеся в базе данных, с реально подсчитанными значениями. Если информация о файле, записанная в базе данных, не совпадает с реальными значениями, то CRC-сканеры сигнализируют о том, что файл был изменен или заражен вирусом.
CRC-сканеры, использующие анти-стелс алгоритмы, являются довольно сильным оружием против вирусов. Однако они имеют врожденный недостаток, состоящий в том, что CRC-сканеры не способны поймать вирус в момент его появления в системе, а делают это лишь через некоторое время, уже после того, как вирус разошелся по компьютеру. CRC-сканеры не могут определить вирус в новых файлах (в электронной почте, на дискетах, в файлах, восстанавливаемых из backup или при распаковке файлов из архива), поскольку в их базах данных отсутствует информация об этих файлах. Adinf фирмы "Диалог-Наука"
Антивирусные блокировщики — это резидентные программы, перехватывающие «вирусо-опасные» ситуации и сообщающие об этом пользователю. К «вирусо-опасным» относятся вызовы на открытие для записи в выполняемые файлы, запись в boot-сектора дисков или MBR винчестера, попытки программ остаться резидентно и т.д., то есть вызовы, которые характерны для вирусов в моменты из размножения.
К достоинствам блокировщиков относится их способность обнаруживать и останавливать вирус на самой ранней стадии его размножения. К недостаткам относятся существование путей обхода защиты блокировщиков и большое количество ложных срабатываний, что, видимо, и послужило причиной для практически полного отказа пользователей от подобного рода антивирусных программ.
Иммунизаторы делятся на два типа: иммунизаторы, сообщающие о заражении, и иммунизаторы, блокирующие заражение каким-либо типом вируса. Первые обычно записываются в конец файлов (по принципу файлового вируса) и при запуске файла каждый раз проверяют его на изменение. Недостаток у таких иммунизаторов всего один, но он летален: абсолютная неспособность сообщить о заражении стелс-вирусом. Поэтому такие иммунизаторы, как и блокировщики, практически не используются в настоящее время.
Второй тип иммунизации защищает систему от поражения вирусом какого-то определенного вида. Файлы на дисках модифицируются таким образом, что вирус принимает их за уже зараженные. Для защиты от резидентного вируса в память компьютера заносится программа, имитирующая копию вируса. При запуске вирус натыкается на нее и считает, что система уже заражена.
1)Крайне осторожно относитесь к программам и документам Word/Excel, которые получаете из глобальных сетей. Перед тем, как запустить файл на выполнение или открыть документ/таблицу, обязательно проверьте их на наличие вирусов.
2)Для уменьшения риска заразить файл на сервере администраторам сетей следует активно использовать стандартные возможности защиты сети: ограничение прав пользователей; установку атрибутов «только на чтение» или даже «только на запуск» для всех выполняемых файлов. Значительно уменьшается риск заражения компьютерной сети при использовании бездисковых рабочих станций. Желательно также перед тем, как запустить новое программное обеспечение, попробовать его на тестовом компьютере, не подключенном к общей сети.
3)Лучше покупать дистрибутивные копии программного обеспечения у официальных продавцов, чем бесплатно или почти бесплатно копировать их из других источников или покупать пиратские копии. дистрибутивных копий программного обеспечения (в том числе копий операционной системы), причем копии желательно хранить на защищенных от записи дискетах. Надежными с точки зрения защиты от вирусов являются BBS/ftp/WWW антивирусных фирм-разработчиков.
4)Старайтесь не запускать непроверенные файлы, в том числе полученные из компьютерной сети. Желательно использовать только программы, полученные из надежных источников. Перед запуском новых программ обязательно проверьте их одним или несколькими антивирусами. Если даже ни один антивирус не среагировал на файл, который был снят с BBS или электронной конференции — не торопитесь его запускать. Подождите неделю, если этот файл вдруг окажется заражен новым неизвестным вирусом, то скорее всего кто-либо «наступит на грабли» раньше вас и своевременно сообщит об этом.
5) Пользуйтесь утилитами проверки целостности информации. Такие утилиты сохраняют в специальных базах данных информацию о системных областях дисков (или целиком системные области) и информацию о файлах (контрольные суммы, размеры, атрибуты, даты последней модификации файлов и т.д.). Периодически сравнивайте информацию, хранящуюся в подобной базе данных, с реальным содержимым винчестера, так как практически любое несоответствие может служить сигналом о появлении вируса или «троянской» программы.
6)Периодически сохраняйте на внешнем носителе файлы, с которыми ведется работа. Такие резервные копии носят название backup-копий. Затраты на копирование файлов, содержащих исходные тексты программ, базы данных, документацию, значительно меньше затрат на восстановление этих файлов при проявлении вирусом агрессивных свойств или при сбое компьютера.
При данном типе атак злоумышленники никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводится к наблюдению за доступными данными или сессиями связи.
Для осуществления подслушивания злоумышленнику необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать, например, к маршрутизатору или PPP-серверу на базе UNIX. Если злоумышленнику удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения он сможет просматривать весь трафик, проходящий через заданный интерфейс.
Второй вариант – злоумышленник получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае злоумышленнику не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях).
Поскольку TCP/IP-трафик, как правило, не шифруется, (мы рассмотрим исключения ниже), злоумышленник, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли.
Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе злоумышленника, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока, причем лучше всего использовать одноразовые пароли.
Другой вариант решения - использование коммутаторов, в результате чего каждая машина получает только тот трафик, который адресован ей.
У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Примеры net watcher, network monitor, ethereal, wareshark.
При данном типе атак злоумышленник взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соответствующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление).
Активные атаки можно разделить на две части:
1. В первом случае злоумышленник предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой.
2. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состояние.
Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows ранних версий, не имеющих системы ограничений пользователей), злоумышленник может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить, откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса, не совпадающего с текущим IP-адресом, злоумышленник никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.
Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак. Единственным средством защиты, да и то не полным, является применение «обратного вызова».
Англоязычный термин -- IP spoofing. В данном случае цель злоумышленника - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей, например, при использовании SMTP жертвы для посылки поддельных писем.
Вспомним, каким образом устанавливается TCP – соединение.
Первый пакет сеанса TCP, помеченный флагом SYN и содержащий произвольное число, например 1000. является запросом клиента на открытие сеанса. Внешний хост-компьютер, получивший этот пакет, посылает в ответ пакет, помеченный флагом АСК и содержащий число, на единицу большее, чем в принятом пакете подтверждая, тем самым прием пакета SYN от клиента.
Далее осуществляется обратная процедура: хост-компьютер посылает клиенту пакет SYN с исходным числом (например, 2000), а клиент подтверждает его получение передачей пакета АСК, содержащего число 2001. На этом процесс квитирования связи завершается.
Другими словами, установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так:
После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge(подтверждаемый) number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи.
Предположим, что злоумышленник может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD (Unix) значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, злоумышленник получит ответ и сможет (возможно, с нескольких попыток и с поправкой на скорость соединения) предсказать sequence number для следующего соединения.
Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.
Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A" и оказаться на A, не вводя пароля. Предположим, что злоумышленник расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.
Первая задача злоумышленника - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течение которых она будет неработоспособна, должно хватить. Другой вариант - использование описанных в следующих разделах методов.
После этого злоумышленник может попробовать притвориться системой B, для того, чтобы получить доступ к системе A (хотя бы кратковременный).
· злоумышленник высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
· злоумышленник высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
· Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и злоумышленник. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.
· злоумышленник подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK. Заметим, что если системы располагаются в одном сегменте, злоумышленнику для выяснения sequence number достаточно перехватить пакет, посланный системой A). После этого, если злоумышленнику повезло и sequence number сервера был угадан верно, соединение считается установленным.
Теперь злоумышленник может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh (протокол), он может содержать команды создания файла .rhosts или отправки /etc/passwd злоумышленнику по электронной почте.
Представим это в виде схемы:
Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети.
В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые находятся в недоступном состоянии. Впрочем, что мешает злоумышленнику имитировать работу системы B ответом на ICMP-пакеты?
Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки!!!). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).
Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратные адреса из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должно существовать способа напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них.
Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы).
Для того чтобы уменьшить число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.
Если в предыдущем случае злоумышленник инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing'а.
Необходимые условия - злоумышленник должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов.
Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.
Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениями клиента, и наоборот. В данном случае злоумышленник, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы.
Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку злоумышленник начинает работу уже после того, как произойдет авторизация пользователя.
Есть два способа рассинхронизировать соединение:
Соединение десинхронизируется на стадии его установки.
· злоумышленник прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.
· Дождавшись пакета S-SYN от сервера, злоумышленник высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.
· Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет.
· Клиент игнорирует S-SYN-пакет, однако злоумышленник, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.
· Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована.
Представим это в виде схемы:
Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные злоумышленником. Для корректной обработки этих ситуаций программа должна быть усложнена.
В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет можно послать клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.
Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемую ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлемый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.
Есть несколько путей определения ACK – бури и защиты от нее. Например, можно реализовать TCP/IP-стэк, который будет контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данном случае мы не застрахованы от злоумышленника, меняющего и эти значения.
Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающие ACK-бури. Это можно реализовать при помощи конкретных средств контроля сети.
Если злоумышленник не потрудится поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откроют новую сессию, не обращаясь к администратору.
Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP. Это исключает возможность модификации сетевого потока.
Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на rfc (документы, в которыох описаны сетевые протоколы, логика работы сети), который требует молчаливого закрытия сессии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.
Сканирование часто применяется злоумышленниками для того, чтобы выяснить, на каких TCP-портах работают демоны (программы – драйверы), отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта злоумышленнику.
Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерванным после установки соединением, или с помощью использования специальных программ.
Однако злоумышленник может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании злоумышленник посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответа, злоумышленник может быстро понять, на каких портах работают программы. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет.
Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения злоумышленник а) можно отслеживать:
· резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что злоумышленник не посылает в ответ RST);
· прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении злоумышленника (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение.
В качестве защиты можно лишь посоветовать закрыть «firewall» - ом все сервисы, доступ к которым не требуется извне.
Традиционный англоязычный термин -- "ping flood". Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестирования. В этом режиме запросы посылаются с максимально возможной скоростью, и программа позволяет оценить, как работает сеть при максимальной нагрузке.
Данная атака требует от злоумышленника доступа к быстрым каналам в Интернет.
Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его, ping выдает скорость прохождения пакета.
При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию.
Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, злоумышленник может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт.
Заметим, что злоумышленник может также подделывать обратный адрес подобных пакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированная работа специалистов на промежуточных маршрутизаторах, что практически нереально.
Один из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающим на жертву, на broadcast-адреса (широковещательный) крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылкой множества broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкое заполнение канала "жертвы".
Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP).
В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того чтобы убедиться, что Ваши машины не могут служить источником ping flood'а, ограничьте доступ к ping.
Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю высылается строка знакогенератора) и других (date etc).
В данном случае злоумышленник может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности.
Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов.
Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов).
В качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.
Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие заняться этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.
Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течение заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED.
Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован.
Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.
После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает злоумышленнику послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, злоумышленник может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер (одна из реализаций Unix), поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD).
Как обычно, злоумышленник может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика.
Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прореживание" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы.
Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его вну