Описание
Вспомним, что установка 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 значение 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-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.).
Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing'а (при условии, что используются криптографически стойкие алгоритмы).
Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.
Предсказание TCP sequence number
Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.
Ранняя десинхронизация
Соединение десинхронизируется на стадии его установки.
Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.
Дождавшись пакета 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-пакетов.
Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов.
Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы.
Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку крэкер начинает работу уже после того, как произойдет авторизация пользователя.
Есть два способа рассинхронизировать соединение:
ACK-буря
Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.
К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает".
Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.
Детектирование и защита
Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения.
Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью.
Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору.
Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP.
Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.
Для более глубокого ознакомления с этой атакой рекомендуется обратиться к IP Hijacking (CERT).
IP Hijacking
Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing'а.
Пассивное сканирование
Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру.
Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ обладают некоторыми попытками внести элементы искуственного элемента в отслеживание попыток соединения с различными портами.
Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер).
Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать:
резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST);
прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение.
В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.
Затопление ICMP-пакетами
Традиционный англоязычный термин -- "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-пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие занятьсе этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом.
Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED.
Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован.
Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель.
В различных системах работа с очередью реализована по разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше.
После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD).
Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика.
Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы.
Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его внутрь сети.
Активные атаки на уровне TCP
При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление).
Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии.
Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.
Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.
Contents:
1. Abstract
2. Вступление
3. Пассивные атаки на уровне TCP
3.1. Подслушивание
4. Активные атаки на уровне TCP
4.1. Предсказание TCP sequence number
4.1.1. Описание
4.1.2. Детектирование и защита
4.2. IP Hijacking
4.2.1. Описание
4.2.1.1. Ранняя десинхронизация
4.2.1.2. Десинхронизация нулевыми данными
4.2.2. ACK-буря
4.2.3. Детектирование и защита
4.3. Пассивное сканирование
4.4. Затопление ICMP-пакетами
4.5. Локальная буря
4.6. Затопление SYN-пакетами
Анатомия атаки
Рассмотрим этапы осуществления атаки (рис.2.). Первый, подготовительный, этап заключается в поиске предпосылок для осуществления той или иной атаки. На этом этапе ищутся уязвимости, использование которых приводит к реализации атаки, т.е. ко второму этапу. На третьем этапе завершается атака, "заметаются" следы и т.д. При этом первый и третий этапы сами по себе могут являться атаками. Например, поиск нарушителем уязвимостей при помощи сканеров безопасности, например, nmap или SATAN считается атакой.
Рис.2. Этапы осуществления атаки
Существующие механизмы защиты, реализованные в межсетевых экранах (firewall), серверах аутентификации, системах разграничения доступа и т.д. работают только на втором этапе. Т.е. по существу они являются средствами блокирующими, а не упреждающими атаки. В абсолютном большинстве случаев они защищают от атак, которые уже находятся в процессе осуществления. И даже если они смогли предотвратить ту или иную атаку, то намного более эффективным было бы упреждение атак, т.е. устранение самих предпосылок реализации вторжений. Комплексная система обеспечения информационной безопасности должна работать на всех трех этапах осуществления атаки. И обеспечение адекватной защиты на третьем, завершающем, этапе не менее важно, чем на первых двух. Ведь только в этом случае можно реально оценить ущерб от "успешной" атаки, а также разработать меры по устранению дальнейших попыток реализовать аналогичную атаку.
Однако даже если вы наряду с традиционными механизмами защиты используете средства поиска уязвимостей, которые своевременно обнаруживают и рекомендуют меры по устранению "слабых мест" в системе защиты, то это еще не доказывает вашей защищенности. Существуют ряд факторов, которые необходимо учитывать при использовании межсетевых экранов, систем аутентификации, систем разграничения доступа и т.д. Эти факторы характеризуют не слабости этих технологий, а особенности их архитектуры. Большинство компьютерных защитных систем построено на классических моделях разграничения доступа, разработанных в 70-х, 80-х годах в военных ведомствах. Согласно этим моделям субъекту (пользователю, программе, процессу или сетевому пакету) разрешается или запрещается доступ к какому-либо объекту (например, файлу или узлу сети) при предъявлении некоторого уникального, присущего только этому субъекту, элемента. В 80% случаев этим элементом является пароль. В других случаях таким уникальным элементом является таблетка Touch Memory, Smart или Proximity Card, биометрические характеристики пользователя и т.д. Для сетевого пакета таким элементом являются адреса или флаги, находящиеся в заголовке пакета, а также некоторые другие параметры.
Можно заметить, что самым слабым звеном этой схемы является уникальный элемент. Если нарушитель каким-либо образом получил этот самый элемент и предъявил системе защиты, то она воспринимает его, как "своего" и разрешает действовать в рамках того субъекта, секретным элементом которого несанкционированно воспользовались. При современных темпах развития технологий получить доступ к такому секретному элементу не составляет большого труда. Его можно "подслушать" при передаче по сети при помощи анализаторов протоколов (sniffer). Его можно подобрать при помощи специальных программ, например, при помощи L0phtCrack или Crack. И так далее. А дальше даже самый мощный и надежный межсетевой экран не защитит от проникновения в корпоративную сеть нарушителя. Мало того, межсетевой экран даже не зафиксирует нарушения, так как для него нарушитель, укравший пароль, является авторизованным пользователем.
Другой не менее распространенный пример. В каждой организации есть пользователи, обладающие практически неограниченными правами в сети. Это сетевые администраторы. Они никому неподконтрольны и могут делать в сети практически все, что угодно. Как правило, они используют свои неограниченные права для выполнения своих функциональных обязанностей. Но представьте на минуту, что администратор чем-то обижен. Будь-то низкой зарплатой, недооценкой его возможностей, местью и т.п. Известны случаи, когда такие обиженные администраторы "портили кровь" не одной компании и приводили к очень серьезному ущербу.
Именно поэтому наряду с "традиционными" средствами защиты (межсетевыми экранами и т.д.) необходимо применять т.н. "адаптивные" средства (системы обнаружения атак и анализа защищенности).
Информационная система. Взгляд изнутри
Для любой компании (финансовой, страховой, торговой и т.п.) существует своя типовая информационная система (ИС), состоящая из компонент, решающих свои специфичные задачи, но в общем случае ИС включает в себя 4 уровня (рис.1.):
1. Уровень прикладного программного обеспечения (ПО), отвечающий за взаимодействие с пользователем. Примером элементов ИС, работающих на этом уровне, можно назвать текстовый редактор WinWord, редактор электронных таблиц Excel, почтовая программа Outlook, системы MS Query и т.д.
2. Уровень системы управления базами данных (СУБД), отвечающий за хранение и обработку данных информационной системы. Примером элементов ИС, работающих на этом уровне, можно назвать СУБД Oracle, MS SQL Server, Sybase и даже MS Access.
3. Уровень операционной системы (ОС), отвечающий за обслуживание СУБД и прикладного программного обеспечения. Примером элементов ИС, работающих на этом уровне, можно назвать ОС Microsoft Windows NT, Sun Solaris, Novell Netware.
4. Уровень сети, отвечающий за взаимодействие узлов информационной системы. Примером элементов ИС, работающих на этом уровне, можно назвать стеки протоколов TCP/IP, IPS/SPX и SMB/NetBIOS.
У злоумышленников имеется широчайший спектр возможностей по нарушению политики безопасности, которые могут быть осуществлены на всех четырех вышеназванных уровнях ИС [5]. Например, для получения несанкционированного доступа к финансовой информации в СУБД MS SQL Server злоумышленники могут попытаться реализовать одну из следующих возможностей:
1. Прочитать записи БД при помощи SQL-запросов через программу MS Query, которая позволяет получать доступ к записям СУБД (уровень прикладного ПО).
2. Прочитать нужные данные средствами самой СУБД (уровень СУБД).
3. Прочитать файлы базы данных, обращаясь непосредственно к файловой системе (уровень ОС).
4. Перехватить передаваемые по сети данные (уровень сети).
Рис.1. Уровни информационной системы
Классификация систем обнаружения атак
Обнаруживать, блокировать и предотвращать атаки можно несколькими путями. Первый, и самый распространенный, способ - это обнаружение уже реализуемых атак. Т.е. если обратиться предыдущему разделу и вспомнить этапы реализации атак, то в соответствии с этой классификацией данный способ функционирует на втором этапе осуществления атаки. Этот способ применяется в "классических" системах обнаружения атак (например, RealSecure компании Internet Security Systems), межсетевых экранах и т.п. Однако, "недостаток" средств данного класса в том, что атаки могут быть реализованы повторно. Они также повторно обнаруживаются и блокируются. И так далее, до бесконечности. Второй путь - предотвратить атаки еще до их реализации. Осуществляется это путем поиска уязвимостей, которые могут быть использованы для реализации атаки. И, наконец, третий путь - обнаружение уже совершенных атак и предотвращение их повторного осуществления. Таким образом, системы обнаружения атак могут быть классифицированы по этапам осуществления атаки (рис.3.):
Системы, функционирующие на первом этапе осуществления атак и позволяющие обнаружить уязвимости информационной системы, используемые нарушителем для реализации атаки. Иначе средства этой категории называются системами анализа защищенности (security assessment systems) или сканерами безопасности (security scanners). Обычно системы анализа защищенности не принято относить к классу средств обнаружения атак, однако, если следовать описанным выше этапам осуществления атаки, то такое отнесение вполне логично. Системы, функционирующие на втором этапе осуществления атаки и позволяющие обнаружить атаки в процессе их реализации, т.е. в режиме реального (или близкого к реальному) времени. Именно эти средства и принято считать системами обнаружения атак в классическом понимании. Помимо этого в последнее время выделяется новый класс средств обнаружения атак - обманные системы. Системы, функционирующие на третьем этапе осуществления атаки и позволяющие обнаружить уже совершенные атаки. Эти системы делятся на два класса - системы контроля целостности, обнаруживающие изменения контролируемых ресурсов, и системы анализа журналов регистрации.
Рисунок 3. Классификация систем обнаружения атак по этапу осуществления атаки
Помимо этого, существует еще одна распространенная классификация систем обнаружения нарушения политики безопасности - по принципу реализации: host-based, т.е. обнаруживающие атаки, направленные на конкретный узел сети, и network-based, направленные на всю сеть или сегмент сети. Обычно на этом дальнейшая классификация останавливается. Однако системы класса host-based можно разделить еще на три подуровня:
Application IDS, обнаруживающие атаки на конкретные приложения; OS IDS, обнаруживающие атаки на операционные системы; DBMS IDS, обнаруживающие атаки на системы управления базами данных.
Выделение обнаружения атак на системы управления базами данных (СУБД) в отдельную категорию связано с тем, что современные СУБД уже вышли из разряда обычных приложений и по многим своим характеристикам, в т.ч. и по сложности, приближаются к операционным системам. Таким образом, классификация систем обнаружения атак по уровню реализации выглядит следующим образом (рис.4.):
Можно заметить, что это деление соответствует уровням информационной системы предприятия (рис.1.).
Рисунок 4. Классификация систем обнаружения атак по принципу реализации
Мир физический и мир виртуальный
После небольшого отступления перейду к теме статьи - обнаружению и отражению угроз. Эта область известна многим специалистам в области безопасности. Она представлена такими средствами физической безопасности, как средства сигнализации и оповещения. В свою очередь эти средства делятся на два категории: постоянного и периодического действия. Первые системы, к которым можно отнести пожарную и охранную сигнализацию, охранное телевидение и т.п., непрерывно следят за объектом защиты. Системы периодического действия работают по другому принципу - они анализируют состояние объекта защиты в заданные моменты или через определенные промежутки времени. Типичным примером таких средств является периодический обход территории охранниками. К средствам отражения можно отнести ограждение территории, замки и решетки и т.п.
Однако информационная система - это тоже своего рода здание, только виртуальное, которое необходимо защищать. И использовать для этого можно те же механизмы физической безопасности, но спроецированные с учетом особенностей информационных технологий. Например, несанкционированный вход в обычное здание блокируется охранником или турникетом. В виртуальном здании для этого используется межсетевой экран или система аутентификации, которые проверяют входящий (и исходящий) в систему трафик на соответствие различным критериям.
Однако злоумышленник для несанкционированного проникновения в здание может подделать пропуск (в виртуальном мире подделать адрес) или пролезть через окно (в виртуальном мире через модем). И никакой охранник или турникет не защитит от этого. И тут на первый план выходят средства обнаружения угроз в виде различных датчиков, идентифицирующих различные угрозы.
По своему функциональному назначению датчики охранной сигнализации делятся на три типа [4]:
Контролирующие пространство помещений (объемные датчики); Контролирующие периметр объекта защиты (линейные датчики); Контролирующие отдельные предметы (точечные датчики).
Как это не странно, но и в виртуальном здании применяются те же самые датчики. Называются они сенсорами системы обнаружения атак. Единственное отличие от датчиков охранной сигнализации в наличии двух категорий вместо трех:
Контроль сетевого сегмента (аналог объемного датчика). В случае применения данного сенсора совместно с межсетевым экраном или иным средством защиты периметра сети сенсор системы обнаружения атак, функционирующий на уровне сети выполняет роль линейного датчика. Контроль отдельного узла информационной системы (аналог точечного датчика).
Аналог механизма охранной сигнализации и оповещения периодического действия тоже присутствует в виртуальном мире. Это системы анализа защищенности, которые по требованию администратора безопасности или по расписанию проводят ряд проверок заданных компонентов информационной системы. Можно провести следующую аналогию с анализом защищенности - охранник, периодически обходящий все этажи здания в поисках открытых дверей, незакрытых окон и других проблем. Также действует и система анализа защищенности. Только в качестве здания выступает информационная система, а в качестве незакрытых окон и дверей - уязвимости ("слабости") этой системы.
Новые грани обнаружения и отражения угроз
А. В. Лукацкий
Научно-инженерное предприятие "Информзащита"
Обманные системы
Обычно, когда речь заходит об обмане в области информационной безопасности, сразу вспоминаются попытки злоумышленников использовать те или иные скрытые лазейки для обхода используемых средств защиты. Будь то кража паролей и работа от имени авторизованного пользователя или несанкционированное использование модемов. Однако обман может сослужить хорошую службу не только для злоумышленников, но и для защитников корпоративных ресурсов. Сразу необходимо отметить, что обман очень редко используется в качестве защитного механизма. Обычно, когда речь заходит о средствах защиты, на ум сразу приходят современнейшие межсетевые экраны, блокирующие любые попытки проникновения хакеров. Или, если обратиться к фантастической литературе, то для защиты от проникновения используются системы с искусственным интеллектом, которые "адаптируются" к нападениям злоумышленников и противопоставляют им адекватные защитные меры. Такие системы описаны в "Лабиринте отражений" Сергея Лукьяненко или "Neuromancer" Уильяма Гибсона. Но "не межсетевым экраном единым". Приходится обращать свое внимание и на другие "нестандартные" защитные механизмы. Это частично собьет с толку злоумышленников и нарушителей, привыкших к широко известным средствам обеспечения информационной безопасности [7].
Существует множество различных вариантов использования обмана в благих целях. Вкратце перечислю некоторые механизмы обмана, основываясь на классификации Даннигана (Dunnigan) и Ноуфи (Nofi):
Сокрытие Камуфляж Дезинформация
В той или иной мере эти механизмы используются в практике работ отделов безопасности. Однако, как правило, эти механизмы используются не для информационной, а для иных областей обеспечения безопасности (физическая, экономическая и т.д.).
В области информационной безопасности наибольшее распространение получил первый метод - сокрытие. Ярким примером использования этого метода в целях обеспечения информационной безопасности можно назвать сокрытие сетевой топологии при помощи межсетевого экрана. Примером камуфляжа можно назвать использование Unix-подобного графического интерфейса в системе, функционирующей под управлением операционной системы Windows NT. Если злоумышленник случайно увидел такой интерфейс, то он будет пытаться реализовать атаки, характерные для ОС Unix, а не для ОС Windows NT. Это существенно увеличит время, необходимое для "успешной" реализации атаки.
Во многих американских фильмах о хакерах, последние, атакуя военные системы Пентагона, мгновенно определяли тип программного обеспечения военной системы лишь взглянув на приглашение ввести имя и пароль. Как правило, каждая операционная система обладает присущим только ей представлением механизма идентификации пользователя, отличающимся от своих собратьев цветом и типом шрифта, которым выдается приглашение; текстом самого приглашения, местом его расположения и т.д. Камуфляж позволяет защититься от такого рода атак.
И, наконец, в качестве примера дезинформации можно назвать использование заголовков (banner), которые бы давали понять злоумышленнику, что атакуемая им система уязвима. Например, если в сети используется почтовая программа sendmail версии 8.9.3, а возвращаемый ею заголовок утверждает обратное, то нарушитель потратит много времени и ресурсов, чтобы попытаться эксплуатировать уязвимости, присущие ранним версиям sendmail (до 8.9.3).
Рассмотрим только 2 и 3 классы обманных методов, как менее известные и наиболее интересные. Работа систем их реализующих заключается в том, что эти системы эмулируют те или иные известные уязвимости, которых в реальности не существует. Использование средств (deception systems), реализующих камуфляж и дезинформацию, приводит к следующему:
1. Увеличение числа выполняемых нарушителем операций и действий. Так как заранее определить является ли обнаруженная нарушителем уязвимость истинной или нет, злоумышленнику приходится выполнять много дополнительных действий, чтобы выяснить это. И даже дополнительные действия не всегда помогают в этом. Например, попытка запустить программу подбора паролей (например, Crack для Unix или L0phtCrack для Windows) на сфальсифицированный и несуществующий в реальности файл, приведет к бесполезной трате времени без какого-либо видимого результата. Нападающий будет думать, что он не смог подобрать пароли, в то время как на самом деле программа "взлома" была просто обманута.
2. Получение возможности отследить нападающих. За тот период времени, когда нападающие пытаются проверить все обнаруженные уязвимости, в т.ч. и фиктивные, администраторы безопасности могут проследить весь путь до нарушителя или нарушителей и предпринять соответствующие меры, например, сообщить об атаке в соответствующие "силовые" структуры.
Обычно в информационной системе используются от 5 до 10 зарезервированных портов (с номерами от 1 до 1024). К ним можно отнести порты, отвечающие за функционирование сервисов HTTP, FTP, SMTP, NNTP, NetBIOS, Echo, Telnet и т.д. Если обманные системы (например, RealSecure компании ISS) эмулируют использование еще 100 и более портов, то работа нападающего увеличивается во стократ. Теперь злоумышленник обнаружит не 5-10, а 100 открытых портов. При этом мало обнаружить открытый порт, надо еще попытаться использовать уязвимости, связанные с этим портом. И даже если нападающий автоматизирует эту работу путем использования соответствующих программных средств (Nmap, SATAN и т.д.), то число выполняемых им операций все равно существенно увеличивается, что приводит к быстрому снижению производительности его работы. И при этом злоумышленник все время находится под дамокловым мечом, опасаясь своего обнаружения.
Системы анализа защищенности
Системы анализа защищенности проводят всесторонние исследования систем с целью обнаружения уязвимостей, которые могут привести к нарушениям политики безопасности. Результаты, полученные от средств анализа защищенности, представляют "мгновенный снимок" состояния защиты системы в данный момент времени. Несмотря на то, что эти системы не могут обнаруживать атаку в процессе ее развития, они могут определить возможность реализации атак.
Функционировать системы анализа защищенности могут на всех уровнях информационной инфраструктуры, т.е. на уровне сети, операционной системы, СУБД и прикладного программного обеспечения. Наибольшее распространение получили средства анализа защищенности сетевых сервисов и протоколов. Связано это, в первую очередь, с универсальностью используемых протоколов. Изученность и повсеместное использование таких стеков протоколов, как TCP/IP, SMB/NetBIOS и т.п. позволяют с высокой степенью эффективности проверять защищенность информационной системы, работающей в данном сетевом окружении, независимо от того, какое программное обеспечение функционирует на более высоких уровнях. Вторыми по распространенности являются средства анализа защищенности операционных систем. Связано это также с универсальностью и распространенностью некоторых операционных систем (например, UNIX и Windows NT). Однако, из-за того, что каждый производитель вносит в операционную систему свои изменения (ярким примером является множество разновидностей ОС UNIX), средства анализа защищенности ОС анализируют в первую очередь параметры, характерные для всего семейства одной ОС. И лишь для некоторых систем анализируются специфичные для нее параметры. Средств анализа защищенности СУБД и приложений на сегодняшний день не так много, как этого хотелось бы. Такие средства пока существуют только для широко распространенных прикладных систем, типа Web-броузеров Netscape Navigator и Microsoft Internet Explorer, СУБД Microsoft SQL Server и Oracle, Microsoft Office и BackOffice и т.п. [6].
При проведении анализа защищенности эти системы реализуют две стратегии. Первая - пассивная, - реализуемая на уровне операционной системы, СУБД и приложений, при которой осуществляется анализ конфигурационных файлов и системного реестра на наличие неправильных параметров; файлов паролей на наличие легко угадываемых паролей, а также других системных объектов на нарушения политики безопасности. Вторая стратегия, - активная, - осуществляемая в большинстве случаев на сетевом уровне, позволяющая воспроизводить наиболее распространенные сценарии атак, и анализировать реакции системы на эти сценарии.
Системы контроля целостности
Системы контроля целостности работают по замкнутому циклу, обрабатывая файлы, системные объекты и атрибуты системных объектов с целью получения контрольных сумм; затем они сравнивают их с предыдущими контрольными суммами, отыскивая изменения. Когда изменение обнаружено, система посылает сообщение администратору, фиксируя время, соответствующее вероятному времени изменения. Если вновь вернуться к этапам реализации атаки, то системы этого класса функционируют на третьем этапе, т.е. они могут однозначно сказать, происходила атака (точнее изменение контролируемого объекта) или нет.
Системы обнаружения атак
Аналогично системам анализа защищенности "классические" системы обнаружения атак также можно классифицировать по уровню информационной инфраструктуры, на котором обнаруживаются нарушения политики безопасности.
Обнаружение атак реализуется посредством анализа или журналов регистрации операционной системы и прикладного ПО, или сетевого трафика в реальном времени. Компоненты обнаружения атак, размещенные на узлах или сегментах сети, оценивают различные действия, в т.ч. и использующие известные уязвимости. И вновь проводя аналогию с миром физической защиты, системы обнаружения атак - это охранные видеокамеры и различные датчики (движения, давления и т.д.). У вас может на входе в здание (корпоративную сеть) может и обязательно должен стоять охранник (межсетевой экран). Но квалифицированный и опытный злоумышленник может его обмануть, маскируясь под сотрудника фирмы (украв идентификатор и пароль пользователя) или проникая через "черный ход" (через модем). В этом случае датчики (агенты системы обнаружения атак) своевременно обнаружат такие несанкционированные действия.
И вновь обращаясь к рисунку 2, можно заметить, что средства обнаружения атак функционируют сразу на двух этапах - втором и третьем. На втором этапе эти средства дополняют традиционные механизмы новыми функциями, повышающими защищенность корпоративной сети. Например, в описанном выше случае с нарушителем, укравшим пароль и проникшим в сеть через межсетевой экран, система обнаружения атак сможет обнаружить и предотвратить действия, отличающие от нормального поведения пользователя, у которого украли пароль. Также эффективно системы обнаружения атак будут блокировать и враждебные действия привилегированных пользователей (администраторов). И, наконец, эти системы одинаково эффективно функционируют и для защиты периметра корпоративной сети, дополняя возможности межсетевых экранов, и для защиты внутренних сегментов сети. Тем более что по статистике до 70% всех компьютерных инцидентов происходит именно изнутри организации.
Как частный и достаточно распространенный случай применения систем обнаружения атак я хотел бы привести ситуацию с неконтролируемым применением модемов, которые превращают сеть даже защищенную межсетевым экраном в решето. Системы анализа защищенности позволяют обнаружить такие модемы, а системы обнаружения атак - идентифицировать и предотвратить несанкционированные действия, осуществляемые через них.
При обнаружении атак эти системы сравнивают контролируемое пространство (сетевой трафик или журналы регистрации) с известными шаблонами (сигнатурами) несанкционированных действий.
Список литературы
[1] А. Лукацкий. Отмычки к "поясу невинности". Business Online, №5, 2000
[2] А. Лукацкий. Адаптивная безопасность сети. Компьютер-Пресс, №8, 1999
[3] А. Лукацкий. Анатомия распределенной атаки. PCWeek/RE, №5, 2000
[4] В. Алексеенко, Ю. Древс. Основы построения систем защиты производственных предприятий и банков. М.: МИФИ, 1996
[5] А. Лукацкий. Атаки на информационные системы. Типы и объекты воздействия. Электроника: Наука, Технология, Бизнес. №1, 2000
[6] А. Лукацкий. Средства анализа защищенности - сделайте правильный выбор. "Мир Internet", №3, 1999
Одной из главных забот любого
Одной из главных забот любого руководителя является стабильная и бесперебойная работа своего предприятия. Любое отклонение функционирования фирмы от нормального приводит к нанесению различных форм ущерба, например, финансовые и временные потери, потеря имиджа и т.п. В последние годы эти убытки зачастую возникают из-за нарушения политики безопасности в том или ином виде имеющейся в организации.
Когда речь заходит об обеспечении безопасности любого предприятия первое, с чего начинается решение этого вопроса, - это физическая защита. Системы контроля доступа, охранные видеокамеры, датчики, системы сигнализации и т.п. Все это приобретается и устанавливается в большом количестве. Однако когда дело доходит до информационной безопасности, то руководство скептически относится к средствам, ее реализующим. Если турникет, видеокамеру или огнетушитель можно потрогать руками, и целесообразность их применения видна невооруженным взглядом, то применение различных систем защиты информации (систем обнаружения атак, систем анализа защищенности и т.д.) необходимо очень тщательно обосновывать. При этом складывается парадоксальная ситуация. У всех на слуху находятся межсетевые экраны и антивирусные системы. Именно они и приобретаются в первую очередь в случае появления в бюджете статьи на средства защиты информации. Но при этом, эти средства уже не удовлетворяют современным требованиям, предъявляемым к защитным системам. Они не отражают, и даже не обнаруживают, целый ряд очень опасных атак [1].
По сравнению с физической безопасностью компьютерная безопасность находится еще в младенчестве. С каждым новым достижением в области информационных технологий появляются новые аспекты обеспечения информационной безопасности. При этом у уже существующих решений появляются новые грани, на которые приходится смотреть под новым углом зрения.
Физическая защита - относительно статическая область, состоящая из систем разграничения доступа, систем сигнализации и, возможно, оборудования для наблюдения, позволяющих идентифицировать и предотвратить физическое вторжение в защищаемую область. В свою очередь, компьютерная безопасность ориентирована не на физический мир, а на киберпространство, где преступники должны быть определены только при помощи серии нулей и единиц [2].
Все это приводит к непониманию со стороны руководства в необходимости приобретения различных средств защиты. И это несмотря на то, что за последний год число компьютерных преступлений возросло на порядок. И ущерб, нанесенный в результате несанкционированных компьютерных посягательств, измеряется миллионами долларов. При этом злоумышленник может находиться за сотни километров от своей жертвы, в т.ч. и другой стране. Чтобы не утомлять читателя дальнейшими рассуждения о необходимости применения систем обеспечения информационной безопасности хочу привести только один факт. 7 и 8 февраля 2000 года было зафиксировано нарушение функционирования таких популярных и ведущих Internet-серверов, как Yahoo (www.yahoo.com), eBay (www.ebay.com), Amazon (www.amazon.com), Buy (www.buy.com) и CNN (www.cnn.com). 9 февраля аналогичная участь постигла и сервера ZDNet (www.zdnet.com), Datek (www.datek.com) и E*Trade (www.etrade.com) [3]. По некоторым данным трехчасовой простой этих серверов привел к потерям, которые составляют астрономическую сумму в 6 миллиардов долларов! Проведенное ФБР расследование показало, что указанные сервера вышли из строя из-за огромного числа направленных им запросов, что и привело к тому, что эти сервера не могли обработать трафик такого объема и вышли из строя. Например, организованный на сервер Buy трафик превысил средние показатели в 24 раза, и в 8 раз превысил максимально допустимую нагрузку на сервера, поддерживающие работоспособность Buy.
При этом нападении злоумышленники реализовали посылку большого объема данных сразу из нескольких сотен узлов, которые были задействованы в атаке. Именно поэтому данный тип атак получил название распределенной (distributed). В этом случае атакуемые узлы захлебнулись огромным трафиком и не смогли обрабатывать запросы от нормальных пользователей. В случае с обычной реализацией аналогичной атаки необходимо иметь достаточно "толстый" канал доступа в Internet, чтобы реализовать лавину пакетов на атакуемый узел. В случае же распределенной атаки это условие уже не является необходимым. Достаточно иметь dialup-соединение с Internet. Принцип лавины или шторма пакетов достигается за счет большого числа таких относительно медленных соединений.
Классификация уязвимостей
Уязвимостью (vulnerability) я называю любую характеристику информационной системы, использование которой нарушителем может привести к реализации угрозы. При этом неважно, целенаправленно используется уязвимость или это происходит ненамеренно. В качестве нарушителя может выступать любой субъект корпоративной сети, который попытался осуществить попытку несанкционированного доступа к ресурсам сети по ошибке, незнанию или со злым умыслом.
Проблема уязвимостей и их обнаружения исследуется очень давно, и за время ее существования предпринимались различные попытки классифицировать уязвимости по различным критериям. Например, американские проекты Protection Analysis Project и RISOS, исследования лаборатории COAST или компании Internet Security Systems и т.д. Каждая организация приводила и обосновывала свою классификацию. Однако ни одна классификация не может быть категоричной. Например, уязвимость, использование которой для ОС Unix (например, переполнение буфера демона statd) может иметь самые плачевные последствия (самый высокий приоритет), для ОС Windows NT может быть вообще не применима или иметь очень низкую степень риска. Кроме того, существует неразбериха и в самих названиях атак и уязвимостей. Например, одна и та же атака, может иметь совершенно различные наименования у разных производителей (Таблица 1).
Таблица 1. Различные названия одной и той же уязвимости
| CERT | CA-96.06.cgi_example_code |
| CyberSafe | Network: HTTP 'phf' Attack |
| ISS | http-cgi-phf |
| AXENT | phf CGI allows remote command execution |
| Bugtraq | PHF Attacks - Fun and games for the whole family |
| BindView | #107 - cgi-phf |
| Cisco | #3200 - WWW phf attack |
| IBM ERS | Vulnerability in NCSA/Apache Example Code |
| CERIAS | http_escshellcmd |
| L-3 | #180 HTTP Server CGI example code compromises http server |
Для устранения описанной неразберихи с именованием уязвимостей и атак в 1999 году компания MITRE Corporation (http://www.mitre.org) предложила решение, независимое от различных производителя средств поиска уязвимостей. Это решение было реализовано в виде базы данных CVE (Common Vulnerability Enumeration), которая затем была переименована в Common Vulnerabilities and Exposures. Это позволило всем специалистам и производителям разговаривать на одном языке. Так, например, описанные в таблице 1 различные названия одной и той же уязвимости получили единый код CVE-1999-0067.
В разработке базы данных CVE помимо экспертов MITRE принимали участие специалисты многих известных компаний и организаций. Например, ISS, Cisco, BindView, Axent, NFR, L-3, CyberSafe, CERT, Carnegie Mellon University, институт SANS, UC Davis Computer Security Lab, CERIAS и т.д. О своей поддержке базы CVE заявили компании Internet Security Systems, Cisco, Axent, BindView, IBM и другие. Однако, несмотря на столь привлекательную инициативу, база данных CVE пока не получила широкого распространения среди производителей коммерческих продуктов.
В процессе практической деятельности я разработал свою классификацию, отражающую этапы жизненного цикла любой информационной системы (Таблица 2).
Таблица 2. Категории уязвимостей
| Проектирование ИС | Уязвимости проектирования |
| Реализация ИС | Уязвимости реализации |
| Эксплуатация ИС | Уязвимости конфигурации |
Смысл уязвимостей второй категории (уязвимости реализации) заключается в появлении ошибки на этапе реализации в программном или аппаратном обеспечении корректного с точки зрения безопасности проекта или алгоритма. Яркий пример такой уязвимости - "переполнение буфера" ("buffer overflow") во многих реализациях программ, например, sendmail или Internet Explorer. Кстати, приведенный выше пример с ракетой Ariane 5 относится именно к этой категории уязвимостей. Обнаруживаются и устраняются такого рода уязвимости относительно легко - путем обновления исполняемого кода или изменения исходного текста уязвимого ПО. Еще одним примером уязвимостей реализации является случай с компьютерами Tandem, произошедший 1 ноября 1992 г. и 7 января 1993 г. В 3 часа ночи функционирование большинства компьютеров Tandem во всем мире было нарушено по причине сбоя в подсистеме BASE23 Nucleus, приводящего к переполнению переменной микрокода таймера при определении времени. Из-за этой ошибки значения системных часов было сброшено на декабрь 1983 г., что иногда приводило к неправильной интерпретации данных в различных финансовых приложениях.
Последняя причина возникновения уязвимостей - ошибки конфигурации программного или аппаратного обеспечения. Наряду с уязвимостями реализации они являются самой распространенной категорией уязвимостей. Существует множество примеров таких уязвимостей. К их числу можно отнести, например, доступный, но не используемый на узле сервис Telnet, использование "слабых" паролей или паролей менее 6 символов, учетные записи (accounts) и пароли, остановленные по умолчанию (например, SYSADM или DBSNMP в СУБД Oracle), и т.д. Обнаружить и исправить такие уязвимости проще всего (Таблица 3).
Таблица 3. Возможности по обнаружению и устранению уязвимостей
| Уязвимости проектирования | Трудно и долго Трудно и долго (иногда невозможно) |
| Уязвимости реализации | Относительно трудно и долго Легко и относительно долго |
| Уязвимости конфигурации | Легко и быстро Легко и быстро |
Ситуация в России
Я не ставил перед собой цели сравнивать предлагаемые в России решения. Поскольку сравнивать различные средства - задача неблагодарная; особенно в России. Ведь между конечным пользователем и производителем всегда встает третье звено (или несколько) - поставщик, который может свести "на нет" все достоинства предлагаемого решения за счет низкого качества послепродажной и гарантийной поддержки. Вторая причина отказа от сравнения в том, что данные решения - это далеко не все, что должно сравниваться. Для каждого продукта должна существовать своя инфраструктура (которая также должна приниматься во внимание при выборе), включающая в себя качество документации (в том числе и на русском языке) и технической поддержки, наличие авторизованного обучения и квалифицированных консультаций, выезды специалистов организации к заказчику и т.д. Ну и наконец, сравнить и выбрать продукты может только конечный пользователь и только в своей собственной сети, чтобы проверить поведение и удобство использования того или иного решения именно в той технологии обработки информации, которая принята в организации.
В таблице 4 приведен список средств анализа защищенности, наиболее часто используемых в России.
Таблица 4. Средства анализа защищенности, используемые в России
| Internet Scanner | Internet Security Systems | На уровне сети | Первая система, получившая сертификат ГТК. По системе существует авторизованное обучение в России. | |
| System Scanner | Internet Security Systems | На уровне ОС | По системе существует авторизованное обучение в России. | |
| Database Scanner | Internet Security Systems | На уровне СУБД | По системе существует авторизованное обучение в России. | |
| Cisco Secure Scanner | Cisco Systems | На уровне сети | ||
| CyberCop Scanner | Network Associates | На уровне сети | ||
| WebTrends Security Analyzer | WebTrends Corporation | На уровне сети | ||
| NetRecon | Symantec | На уровне сети | Судьба продукта после его покупки у компании Axent пока неясна. | |
| Enterprise | Security Manager | Symantec | На уровне ОС | |
| SFProtect | Hewlett Packard | На уровне сети, ОС, СУБД | ||
| Nessus | Свободно распространяется | На уровне сети | Система имеет сертификат ГТК. |
В России стоимость является, пожалуй, одним из основных критериев выбора системы обнаружения атак. Зачастую такой выбор делается не в пользу более эффективного, а в пользу более дешевого решения. Можно спорить, что такая практика порочна, но она существует и с ней надо считаться. Понимая это, многие производители помимо цены, указанной в прайс-листе, предлагают специальные программы удержания потенциального покупателя. Именно поэтому в вышеприведенной таблице нет колонки "Цена". Можно привести некоторые примеры без указания названий фирм, использующих такие методы:
Предложение для России цен ниже европейских и американских. Оплата выбираемой системы в рассрочку. Скидки при приобретении нескольких средств одного производителя. Скидки для образовательных учреждений. Скидки при переходе с продукта-конкурента. И т.д.
В среднем стоимость анализа одного узла может меняться в диапазоне от 100 до 3 долларов США, в зависимости от числа сканируемых устройств.
Советы покупателю
И хотя в одной статье трудно описать критерии выбора различных средств анализа защищенности, я бы хотел дать некоторые основные советы, которым надо следовать при приобретении таких систем. Замечу, что подробное описание критериев оценки таких систем будет приведено в книге "Обнаружение атак", которая выйдет летом 2001 года в издательстве BHV-СПб (http://www.bhv.ru).
Я категорически не рекомендую использовать в качестве основного параметра выбора системы анализа защищенности число обнаруживаемых ею уязвимостей. Ведь это очень субъективный параметр. В качестве примера можно привести следующий случай. Зачем в сети, в которой используется только платформа Windows система, обнаруживающая еще и Unix'овые уязвимости. Эти возможности являются лишними и возможно никогда не будут использованы. Поэтому подходить к выбору системы анализа защищенности надо очень осторожно и не стоит полагаться только на число обнаруживаемых уязвимостей.
Поскольку постоянно появляются новые уязвимости, то для их эффективного обнаружения необходимо постоянно обновлять базу данных системы анализа защищенности. Ведь не вызывает сомнений необходимость обновления антивирусной системы или установка патчей и Service Pack'ов для операционных систем. Также и с системой поиска уязвимостей. Только в случае периодического и своевременного обновления эта система сможет поддерживать защищенность сети на должном уровне. В идеале разрыв между появлением информации об уязвимости в различных "хакерских" источниках и появлением сигнатуры в базе данных системы обнаружения должен отсутствовать. Еще лучше, когда производитель системы обнаружения уязвимостей идет на шаг впереди злоумышленников и обновляет свою систему еще до того, как информация о новых "дырах" разойдется по всему миру. Однако на практике это далеко не так. И задача и производителя (или поставщика) системы анализа защищенности и персонала, использующего эту систему, снизить этот интервал до минимума. Но как бы часто не обновлялась база данных уязвимостей, существует временной промежуток между сообщением о новой уязвимости и появлением проверки для нее. Уменьшение этого интервала - одна из главных задач, стоящих перед эксплуатирующим систему анализа защищенности подразделением. Один из путей ее решения - создание своих собственных проверок. Решаться это может путем использованием языка описания уязвимостей. Такая возможность существует в системах Internet Scanner, CyberCop Scanner, Nessus, WebTrends Security Analyzer и ряде других.
Механизм описания своих проверок, уязвимостей, атак и иных контролируемых событий является очень полезной возможностью для администраторов, отслеживающих уязвимости, описанные в Bugtraq и иных списках рассылки. Эта возможность позволяет быстро записать новое правило и использовать его в своей сети. Однако необходимо заметить, что хотя данная возможность и является полезной, ее необходимость достаточно эфемерна. В своей практической деятельности мне не приходилось встречаться с организациями, которые могли бы себе позволить содержать целый штат или одного сотрудника, занимающихся исследованиями в области новых проверок и уязвимостей (я не беру в расчет силовые ведомства и иные организации, работающие в области защиты информации). Как правило, человек, отвечающий за обеспечение безопасности в российских организациях, не обладает глубокими познаниями в программировании. Кроме того, помимо написания новых правил на нем "висит" еще много других задач (контроль деятельности пользователей, установка прав доступа, противодействие ПЭМИН и т.д.), и он просто не имеет времени для такой творческой работы, как создание новых проверок.
Несмотря на то, что система анализа защищенности является средством обеспечения информационной безопасности, она сама должна быть защищена от посягательств со стороны злоумышленников, так как выведение ее из строя существенно снизить защищенность всей сети. Для этого в этой системе должны быть предусмотрены механизмы контроля своей целостности, ограничения круга лиц к собранным данным и разграничения прав на запуск проверок.
Далеко не всегда система анализа защищенности является основным средством защиты в сети. Мало того, даже самая "главная" система защиты может быть второстепенной системой в общей телекоммуникационной инфраструктуре. Очень часто приходится встречаться с организациями, в которых отделы защиты информации находятся в подчиненном положении по отношению к отделам информатизации. В таких организациях в качестве корпоративного стандарта принята какая-либо система сетевого управления (например, HP OpenView), с которой и пытаются интегрировать все остальные системы (в том числе и средства защиты). Поэтому при выборе системы поиска уязвимостей необходимо делать выбор в пользу той, которая имеет возможность интеграции с системами управления и другими средствами, используемыми в вашей организации.
Подсистема генерации отчетов - немаловажный элемент системы анализа защищенности. Без нее трудно составить мнение о том, каков уровень защищенности сегментов корпоративной сети. На основе созданных этой системой отчетов администратор безопасности строит всю свою дальнейшую деятельность - изменяет политику безопасности, устраняет обнаруженные уязвимости, реконфигурирует средства защиты, готовит отчеты руководству и т.д. При этом хорошая подсистема генерации отчетов должна обладать следующими свойствами:
Наличие в отчетах, как текстовой информации, так и графических данных, что позволяет удовлетворить практически все требования по созданию удобных в понимании и содержательных отчетов. Наличие в отчетах не только информации об обнаруженной уязвимости, но и об уязвимых операционных системах, вариантах ложного обнаружения, методах устранения, ссылках на сервера производителей, дополнительной информации. В последнее время стало хорошим тоном указание соответствия между обнаруженной проблемой и базой данных CVE, описанной выше. Возможность выборки из всей собранной информации только нужных данных по заданным критериям (интервал времени, название уязвимости, степень риска, операционная система, тип уязвимости и т.д.). Возможность сортировки данных в создаваемых отчетах по различным параметрам (по имени, по дате, по степени риска и т.д.). Возможность создания отчетов для различных категорий специалистов. Как минимум можно выделить три таких категории: руководство компании, руководство среднего звена и технические специалисты. В отчетах первой категории не содержится никакой технической информации об обнаруженных уязвимостях или атаках. Они содержат описание общего состояния защищенности корпоративной сети. Отчеты второй категории могут содержать более подробную техническую информацию, например, описание обнаруженных уязвимостей или атак, но без указания мер по их устранению. К данной категории также относятся так называемые сравнительные отчеты (trend analysis), которые показывают тенденции в изменении уровня защищенности заданных узлов корпоративной сети. К последней категории отчетов можно отнести технические отчеты, содержащие не только подробное описание каждой из обнаруженных проблем, но и рекомендации по их устранению, а также ссылки на дополнительные источники информации. Такие категории отчетов приняты в Internet Scanner и Cisco Secure Scanner. Возможность экспорта создаваемых отчетов. Помимо печати отчетов на принтере и сохранения отчета в файле некоторые системы обнаружения атак могут экспортировать свои отчеты в другие приложения, например, Lotus Notes или MS Exchange. Поддержка различных форматов создаваемых отчетов. Как правило, системы обнаружения атак могут создавать отчеты в двух-трех форматах: HTML, CSV и в своем собственном формате. Однако в зависимости от операционной системы, под управлением которой работает система обнаружения атак, установленных на узле приложений и других параметров, она может создавать отчеты и в других форматах. Например, в формате Microsoft Word, Excel, ODBC, ODBC, DIF (Data Interchange Format), текстовом и т.д. Возможность создания своих шаблонов отчетов. Зачастую имеющихся шаблонов по разным причинам недостаточно. Например, если в организации принят свой собственный шаблон отчетов (с указанием логотипа компании, автора отчета, даты и времени создания, грифа и т.д.). В этом случае выбираемая система обнаружения атак должна иметь механизм подключения и создания своих собственных отчетов. Такими механизмами обладают системы Internet Scanner, Cisco Secure Scanner и другие.
Средства анализа защищенности и их классификация
Разумеется, уязвимости необходимо обнаруживать, чем и занимаются системы анализа защищенности (security assessment systems), также известные как сканеры безопасности (security scanners) или системы поиска уязвимостей. Они проводят всесторонние исследования заданных систем с целью обнаружения уязвимостей, которые могут привести к нарушениям политики безопасности. Результаты, полученные от средств анализа защищенности, представляют "мгновенный снимок" состояния защиты системы в данный момент времени. Несмотря на то, что эти системы не могут обнаруживать атаку в процессе ее развития, они могут определить потенциальную возможность реализации атак.
Эти системы могут быть классифицированы по типам обнаруживаемых ими уязвимостей (Рис.1), описанных выше.
Системы поиска уязвимостей проектирования не получили широкого распространения в российских компаниях. Связано это, на мой взгляд, с высокой стоимостью таких решений и недопониманием их значимости. Единственный класс организаций, где эти системы нашли свое применение, - это лаборатории, осуществляющие сертификацию программно-аппаратного обеспечения и аттестацию информационных систем по требованиям безопасности. Такие лаборатории существуют в рамках всех пяти российских систем сертификации по требованиям защиты информации, принадлежащих ГТК, ФАПСИ, МО РФ, ФСБ и СВР. Примерами таких зарубежных систем можно назвать CRAMM, RANK-IT, @RISK, ALRAM, ARES, LAVA и т.д. Из российских разработок известны ZOND, SEZAM и результаты работ 4 ЦНИИ Министерства Обороны РФ.
Системы анализа защищенности второго и третьего классов получили наибольшее распространение среди конечных пользователей. Существует несколько дополнительных классификаций этих систем. Например, системы анализа исходного текста и исполняемого кода тестируемого программно-аппаратного обеспечения и т.д. Первые также применяются обычно при сертификации программного обеспечения по требованиям безопасности. Такие систему существуют у зарубежных (например, SLINT) и российских (например, АИСТ, АСТМА и СОТМА) производителей.
В большинстве случаев программное обеспечение поставляется в организации без исходных текстов. Кроме того, анализ исходных текстов требует высокой квалификации от обслуживающего их персонала. Да и отсутствие эффективных систем анализа исходных текстов не позволяет проводить такой анализ на качественном уровне. По словам сотрудника одной из отечественных сертификационных лабораторий, "выполнение указанных работ проводится путем ручного анализа исходных текстов программ". Именно поэтому большой интерес вызывают системы поиска уязвимостей в исполняемом коде, самым распространенным подклассом которых являются системы имитации атак, которые моделируют различных несанкционированных воздействий на компоненты информационной системы. Именно эти системы получили широкую известность во всем мире ввиду своей относительной простоты и дешевизны. Посредством таких имитаторов обнаруживаются уязвимости еще до того, как они будут использованы нарушителями для реализации атак. К числу систем данного класса можно отнести SATAN, Internet Scanner, Cisco Secure Scanner и т.д. Из российских систем можно назвать систему с многозначительным названием НКВД, разработанную в Центре безопасности информации.
Системы имитации атак с одинаковым успехом обнаруживают не только уязвимости реализации, но и уязвимости эксплуатации. Именно эти системы, наряду с системами поиска уязвимостей эксплуатации, получили наибольшее распространение среди пользователей.
Как показано на рисунке 2 функционировать системы анализа защищенности, в частности системы поиска уязвимостей реализации и эксплуатации, могут на всех уровнях информационной инфраструктуры любой компании, то есть на уровне сети, операционной системы, СУБД и прикладного программного обеспечения. Наибольшее распространение получили средства анализа защищенности сетевых сервисов и протоколов. Связано это, в первую очередь, с универсальностью используемых протоколов. Изученность и повсеместное использование таких стеков протоколов, как TCP/IP, SMB/NetBIOS и т.п. позволяют с высокой степенью эффективности проверять защищенность корпоративной сети, работающей в данном сетевом окружении, независимо от того, какое программное обеспечение функционирует на более высоких уровнях. Примером такой системы является Internet Scanner компании ISS. Вторыми по распространенности являются средства анализа защищенности операционных систем. Связано это также с универсальностью и распространенностью некоторых операционных систем (например, UNIX и Windows NT). Однако, из-за того, что каждый производитель вносит в операционную систему свои изменения (ярким примером является множество разновидностей ОС UNIX), средства анализа защищенности ОС анализируют в первую очередь параметры, характерные для всего семейства одной ОС. И лишь для некоторых систем анализируются специфичные для нее параметры. Примером такой системы является System Scanner компании ISS. Средств анализа защищенности СУБД и приложений на сегодняшний день не так много, как этого хотелось бы. Такие средства пока существуют только для широко распространенных прикладных систем, типа Web-броузеры (Netscape Communicator, MS Internet Explorer), СУБД (MS SQL Server, Oracle) и т.п. Примером такой системы является Online Scanner и Database Scanner также компании ISS.
При проведении анализа защищенности эти системы реализуют две стратегии. Первая - пассивная, - реализуемая на уровне операционной системы, СУБД и приложений, при которой осуществляется анализ конфигурационных файлов и системного реестра на наличие неправильных параметров; файлов паролей на наличие легко угадываемых паролей, а также других системных объектов на нарушения политики безопасности. Вторая стратегия, - активная, - осуществляемая в большинстве случаев на сетевом уровне, позволяющая воспроизводить наиболее распространенные сценарии атак, и анализировать реакции системы на эти сценарии.
Однако не стоит думать, что при помощи средств анализа защищенности можно тестировать только возможность несанкционированного доступа в корпоративную сеть из сетей открытого доступа (например, Internet). Эти средства с не меньшим успехом могут быть использованы для анализа некоторых сегментов или узлов внутренней сети организации. Системы анализа защищенности могут быть использованы как отделами защиты информации (для оценки уровня безопасности организации), так и управлениями информатизации (для контроля эффективности настройки сетевого, системного и прикладного программно-аппаратного обеспечения). Эта два наиболее распространенных варианта применения систем анализа защищенности. Однако есть и другие варианты. Например, внешними аудиторскими и консалтинговыми компаниями, осуществляющими информационные обследования сетей своих заказчиков. Есть и более интересные варианты - например, для тестирования и сертификации того или иного программно-аппаратного обеспечения. Этот вариант очень популярен на Западе при оценке сетевого оборудования, межсетевых экранов и т.п. различными тестовыми лабораториями. В России такая практика пока не получила широкого распространения. Однако и у нас зафиксированы факты применения средств анализа защищенности. Гостехкомиссия России использует системы Internet Scanner и Nessus в процессе сертификации межсетевых экранов на соответствие требованиям руководящих документов.
В настоящий момент существует более сотни различных средств, автоматизирующих поиск уязвимостей на уровне сети, ОС, СУБД и прикладного ПО. Одни средства ориентированы на обнаружение целого спектра различных уязвимостей, другие - только на определенную их категорию. Например, система Internet Scanner является одним из самых известных средств поиска "дыр" и обнаруживает более 900 различных уязвимостей, принадлежащих различным категориям: Denial of Service, Brute Force, FTP, LDAP, SNMP, RPC, NIS, NFS, DNS и т.д. А система Whisker была создана специально для сканирования Web-серверов и позволяет выявлять уязвимые CGI-скрипты.
Выявление уязвимостей компьютерных сетей
А. В. Лукацкий
Научно-инженерное предприятие "Информзащита"
Асимметричная криптография
Распространенная криптографическая методика состоит в применении пары ключей: открытого и закрытого. Сначала используется подходящий криптографический алгоритм генерации пары открытый-закрытый ключ. Открытый ключ может быть открыт для использования любому лицу, с которым необходимо установить безопасную передачу сообщений. Закрытый ключ держится в секрете и никому не открывается. Открытый ключ применяется для шифрования сообщений, а соответствующий закрытый ключ для их расшифровки.
Для того, чтобы отправить конфиденциальное сообщение отправителю необходим открытый ключ. С его помощью это сообщение шифруется, а затем отсылается. Получатель этого сообщения расшифровывает его с помощью закрытого ключа. В этом случае никто, кроме владельца закрытого ключа, не может дешифровать сообщение. Такая технология известна как асимметричное шифрование. Пары открытых-закрытых ключей также иногда называют асимметричными ключами.
Безопасность Web-сервисов
Автор: Билал Сиддикуи (Bilal Siddiqui)
Перевод: Intersoft Lab
Авторские права: market@iso.ru
В предыдущей статье обсуждались вопросы безопасности Web-сервисов в приложениях, применяемых в электронной коммерции по схеме B2B. В ней также были упомянуты XML-стандарты безопасности, разрабатываемые международными организациями W3C и OASIS.
В этой статье рассматриваются три XML-стандарта безопасности: "Подпись XML" (XML Signatures), "Шифрование XML" (XML Encryption) и "Безопасность Web-сервисов" (Web Services Security) - которые регламентируют следующую функциональность при передаче SOAP-сообщений: пользовательскую аутентификацию, целостность сообщений и конфиденциальность. Можно быть уверенным, что эти три спецификации "заткнут дыру" в SOAP-сервере, о которой рассказывалось в предыдущей статье. А в следующей статье на примере создания, обмена и обработки XML-сообщений в брандмауэрах XML будет показано, как "заделывается эта дыра".
Цифровые подписи
Ключи также используются для создания и проверки цифровых подписей. Алгоритм дайджеста можно применять для вычисления значения дайджеста сообщения, а затем с помощью закрытого ключа по этому значению сгенерировать цифровую подпись. Получатель этого сообщения сначала проверит целостность значения хэш-функции, повторив вычисление дайджеста. Затем он использует открытый ключ отправителя сообщения для проверки подписи. Если значение дайджеста было изменено, эта подпись не будет подтверждена на стороне получателя. Если же проверка значения дайджеста и подписи приведет к положительному результату, можно сделать следующий вывод:
после вычисления дайджеста в сообщение не вносились изменения (целостность сообщения); и
сообщение получено действительно от владельца открытого ключа (пользовательская аутентификация).
Дайджесты сообщений
Дайджесты сообщений - это еще одно понятие, которым оперируют при защищенной передаче сообщений по Интернет. Алгоритмы дайджестов схожи с хэш-функциями: они читают ("переваривают") данные для вычисления значения хеш-функции, называемого дайджестом сообщения. Дайджест сообщения зависит от данных и алгоритма дайджеста. Значение дайджеста может использоваться для проверки целостности сообщения; то есть для обеспечения неизменности данных во время их передачи отправителем получателю. Отправитель посылает дайджест сообщения вместе с этим сообщением. По получении сообщения получатель заново производит вычисление дайджеста . Если в сообщение были внесены изменения, это значение будет другим, и это будет свидетельствовать о том, что сообщение было изменено.
Однако, что делать, если и сообщение, и дайджест изменены? Такой тип модификаций невозможно установить на стороне получателя. Поэтому одних алгоритмов дайджестов сообщения недостаточно для обеспечения целостности сообщений - для решения указанной проблемы необходимы цифровые подписи.
Формирование цифровой подписи XML: основные четыре шага
Первый шаг - это создание элемента Signature. Со временем этот элемент будет оборачивать все другие элементы цифровой подписи XML. У Листинга 2 точно такое же тело как и у Листинга 1, единственное отличие между ними заключается в том, что Листинг 2 содержит объявление пространства имен цифровой подписи XML (http://www.w3.org/2000/09/xmldsig#) и заголовок SOAP. Этот заголовок SOAP оборачивает элемент Signature.
Parameters passed with the method
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<s:GetSpecialDiscountedBookingForPartners
xmlns:s=“http://www.MyHotel.com/partnerservice/”>
<!-- Parameters passed with the method call-->
</s:GetSpecialDiscountedBookingForPartners>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP в данном случае используется как пример XML-формата, чтобы продемонстрировать "Цифровую подпись XML", которая не является специфичной для SOAP. Поэтому ее можно применять, чтобы вставлять подписи и профили сообщения в любой экземпляр XML: SOAP или какой-либо иной.
В следующем примере теги цифровой подписи XML будут вставлены в заголовок SOAP. Цифровая подпись - это гибкая технология, она допускает включение таких тегов в любое место XML-файла. На самом деле существуют три типа подписей XML: заключающая в конверт (enveloping), заключаемая в конверт (enveloped) и обособленная (detached). Если подпись XML оборачивает данные, подлежащие подписанию, говорят, что это заключающая в конверт подпись. Если же данные, подлежащие подписанию, оборачивают эту подпись (например, подпись XML становится элементом данных XML, которые подписываются), то эта подпись называется заключаемой в конверт. Наконец, если подпись и данные, подлежащие подписанию, хранятся раздельно - подписываемый элемент и элемент подписи являются элементами одного уровня - такую подпись принято считать обособленной. В примере, который в этой статье иллюстрирует применение спецификации "Цифровая подпись XML", используются обособленные подписи.
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
</ds:SignedInfo>
<ds:SignatureValue>
</ds:SignatureValue>
<ds:KeyInfo>
</ds:KeyInfo>
</ds:Signature>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<s:GetSpecialDiscountedBookingForPartners
xmlns:s=“http://www.MyHotel.com/partnerservice/”>
<!-- Parameters passed with the method call-->
</s:GetSpecialDiscountedBookingForPartners>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Элемент Signature в Листинге 2 содержит три дочерних элемента: SignedInfo, SignatureValue и KeyInfo.
Этот элемент является единственным обертывающим элементом для других тегов цифровой подписи XML. В последующих шагах: 2, 3 и 4 - мы создадим дочерние узлы для этих трех потомков Signature (SignedInfo, SignatureValue и KeyInfo).
Второй шаг - создание дочерних узлов элемента SignedInfo. Листинг 3 - результат включения дочерних узлов SignedInfo в Листинг 2. Законченная структура элемента SignedInfo - подробная иллюстрация того, как создается подпись XML - элемент SignedInfo имеет несколько потомков, каждый из которых содержит несколько бит информации, назначение которой будет раскрыто ниже.
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
<?xmlversion='1.0'?>
<EncryptedData
xmlns="http://www.w3.org/2001/04/xmlenc#"
MimeType="text/xml">
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>
MyKeyIdentifier</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue>
B457V645B45........</CipherValue>
</CipherData>
</EncryptedData>
Корневой элемент EncryptedData несет зашифрованные данные вместе с такой необходимой информацией, как алгоритм, используемый для шифрования. Этот элемент содержит объявление пространства имен шифрования XML (http://www.w3.org/2001/04/xmlenc#) и атрибут MimeType, значение которого равно text/xml. По этому атрибуту получатель этого зашифрованного XML-файла может понять, что XML-файл был зашифрован, чтобы создать структуру EncryptedData.
Первый потомок корневого элемента - элемент EncryptionMethod. Этот элемент содержит атрибут Algorithm, который определяет алгоритм, использованный при шифровании. Его значение равно http://www.w3.org/2001/04/xmlenc#3des-cbc, что определяет алгоритм тройной DES (Data Encryption Standard, Стандарт шифрования данных).
Элемент ds:KeyInfo тот же самый, что и тот, который использовался при применении спецификации "Цифровая подпись XML". Необходимо отметить, что этот элемент был позаимствован из пространства имен цифровой подписи XML.
Элемент EncryptedData содержит еще один дочерний элемент - CipherData, у которого в свою очередь имеется дочерний элемент CipherValue. Этот элемент CipherValue несет зашифрованное содержание (зашифрованную версию XML-документа). Таким образом, результатом шифрования XML-файла является содержание элемента CipherValue.
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<xenc:EncryptedData
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Element">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>
MyKeyIdentifier</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
B457V645B45........</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Сравним элемент EncryptedData из Листинга 6 с элементом EncryptedData из Листинга 7. Нетрудно видеть, что имеется одно различие: вместо атрибута MimeType Листинга 6 в Листинге 7 появился атрибут Type. Значение этого атрибута равно http:///www.w3.org/2001/04/xmlenc#Element, что означает, что зашифрован XML-элемент.
Таким образом, при шифровании элемента XML-файла следует использовать идентификатор http:///www.w3.org/2001/04/xmlenc#Element в качестве значения атрибута Type. В этом случае получатель зашифрованного XML-файла будет знать, что зашифрованные данные должны интерпретироваться как XML-элемент в расшифрованной простой текстовой форме.
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<s:GetSpecialDiscountedBookingForPartners
xmlns:s=“http://www.MyHotel.com/partnerservice/”
ID="GetSpecialDiscountedBookingForPartners">
<xenc:EncryptedData
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Type="http://www.w3.org/2001/04/xmlenc#Content">
<xenc:EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:KeyName>
MyKeyIdentifier</ds:KeyName>
</ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>
B457V645B45........</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</s:GetSpecialDiscountedBookingForPartners>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<?xmlversion="1.0" encoding="utf-8"?>
<SOAP:Envelope
xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<SOAP:Header>
<wsse:Security>
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
wsu:Id="MyTourOperatorCertificate">
LKSAJDFLKASJDlkjlkj243kj;lkjLKJ...
</wsse:BinarySecurityToken>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml -exc-c14n# "/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
Обеспечение целостности данных и пользовательской аутентификации с помощью подписей XML:
Спецификация подписи XML - "Цифровая подпись XML" (XMLDS) - которая была разработана совместными усилиями организации W3C и IETF, имеет статус Рекомендации W3C. Этот документ определяет правила обработки и синтаксис, предназначенные для упаковки в XML-формат данных о целостности сообщения, его аутентификации и пользовательской аутентификации.
Вернемся к примеру из предыдущей статьи - в нем речь шла о взаимодействии между туроператором и его партнерами (отелями). Предположим, что туроператор хочет вызвать метод GetSpecialDiscountedBookingForPartners Web-сервиса своего партнера. Этот метод предоставляет услугу интерактивного резервирования мест в отеле по специальной цене (со скидкой). Причем увидеть эту скидку могут только бизнес партнеры, а не потребители.
Вызывая метод SOAP GetSpecialDiscountedBookingForPartners, туроператор включает в него информацию о целостности сообщения и пользовательской аутентификации. При получении этого вызова брандмауэру XML отеля потребуется просмотреть SOAP-сообщение, чтобы поверить, что:
сообщение не было изменено, пока оно передавалось в Web-сервис отеля (целостность сообщения); и
запрашивающая сторона является бизнес партнером (пользовательская аутентификация).
Если выполнены эти два условия, брандмауэр XML разрешает запрашивающей стороне перейти к SOAP-серверу. На рисунке 1 показ процесс пользовательской аутентификации:
Туроператор направляет в Web-сервис отеля SOAP-запрос о вызове метода. Этот запрос включает всю информацию, относящуюся к обеспечению безопасности (пользовательская аутентификация и пользовательская аутентификация).
Web-сервис отеля защищен брандмауэром XML, который принимает все запросы, направляемые в этот SOAP-сервер. брандмауэр XML проверяет, идентично ли полученное сообщение тому, которое запрашивающая сторона собиралась отправить.
Если целостность сообщения не нарушена, брандмауэр XML считывает идентификационную информацию запрашивающей стороны из этого SOAP-запроса и проверяет, является ли этот пользователь бизнес партнером.
Если запрашивающая сторона является бизнес партнером, брандмауэр XML разрешает запрашивающей стороне перейти к SOAP-серверу.
Рис. 1. Процесс пользовательской аутентификации с использованием брандмауэра XML
Листинг 1 - это простой SOAP-запрос, который передает в Web-сервис отеля вызов метода GetSpecialDiscountedBookingForPartners. В этом SOAP-запросе отсутствуют какие-либо данные о целостности сообщения или пользовательской аутентификации. Листинг 1 - это начальная точка демонстрации применения спецификации "Цифровая подпись XML".
Обработка шифрования XML
Рассмотрим, как брандмауэр XML работает с понятиями шифрования. Брандмауэр получает Листинг 7 или 8 (SOAP-сообщения с зашифрованными элементами или содержанием) и, прежде чем переслать SOAP-серверу расшифрованный запрос SOAP-сообщения, преобразует их содержание в дешифрованную форму.
Получатель зашифрованного XML-файла (например, в нашем случае брандмауэр XML отеля) расшифровывает этот XML-файл, выполняя следующую последовательность действий:
Извлекает зашифрованное содержание элемента CypherValue.
Считывает значение атрибута алгоритма элемента EncryptionMethod.
Считывает значение атрибута Type элемента EncryptedData.
Получает информацию о ключе из элемента ds:KeyInfo.
Использует полученную информацию для создания простого текстового (расшифрованного) файла.
Основные понятия криптографии
При обсуждении целостности сообщений, аутентификации пользователей и конфиденциальности используются некоторые базовые понятия: ключи, криптография, подписи и сертификаты. Ниже кратко изложены основы криптографии. За более подробной информацией обращайтесь в раздел Ресурсы, где содержится ссылка на справочник по криптографии, который можно бесплатно скачать.
Проверка цифровой подписи XML
Процедура проверки проста и логически может быть выведена из методики формирования цифровой подписи XML, рассмотренной выше. Она распадается на три этапа.
Во-первых, необходимо канонизировать элемент SignedInfo. Напомним, что элемент CanonicalizationMethod устанавливает алгоритм канонизации. Поэтому следует воспользоваться этой канонической формой элемента SignedInfo для оставшейся части процесса проверки.
Во-вторых, необходимо проконтролировать целостность сообщения, проверив дайджест, который находится в элементе Reference, сформированном ранее, на шаге 2. При проверке дайджеста нужно располагать информацией, которая включает:
Данные, по которым построен дайджест. Следует разыменовывать атрибут Reference элемента, чтобы получить эти данные.
Любые трансформации, которые могут применяться к этим данным до запуска алгоритма профиля. В элементе Transforms содержится эта информация. Прежде чем получать дайджест данных, необходимо применить к ним те же трансформации.
Алгоритм дайджеста. Эта информация находится в значении атрибута Algorithm элемента DigestMethod. Необходимо применить этот дайджест сообщения и проверить, не отличается ли значение дайджеста от той, что содержится в элементе DigestValue.
Если проверка дайджеста приводит к отрицательному результату, то процесс проверки заканчивается и считается неудовлетворительным.
Если выясняется, что с величиной профиля все в порядке, наступает очередь третьего этапа - проверки подписи. Для проверки подписи необходим ключ подписавшей стороны (открытый или общий секретный). Информацию о ключе можно получить из элемента KeyInfo, если он присутствует (или если приложению уже известна такая информация). Как только ключ, используемый при проверке подписи, известен, нужно прочитать метод подписи, который применялся при создании этой подписи. Атрибут Algorithm элемента SignatureMethod содержит эту информацию. После чего следует воспользоваться канонической формой элемента SignedInfo и ключом, чтобы подтвердить величину подписи.
При реализации спецификации " Цифровая подпись XML" можно создавать заголовки SOAP для генерации подписанных SOAP-сообщений. Брандмауэр XML, находящийся на стороне получателя, обрабатывает этот заголовок SOAP, чтобы проверить подписи прежде чем переслать запрос на SOAP-сервер. Данный процесс представлен на рисунке 1. Задача обеспечения безопасности может быть достигнуты следующим образом:
Можно проверить, что полученное SOAP-сообщение было действительно отправлено известным отправителем.
Можно проверить, что полученные данные не были изменены, пока они передавались, и что они не отличаются от тех, что отправитель собирался отправить.
Таким образом, касаясь нашего примера, можно быть уверенным, что запрос о резервировании по специальной цене со скидкой был оправлен действительно партнером, и что эти данные не были изменены, пока они передавались. Тем не менее, возможно ситуация, когда данные, передаваемые по Интернет, могут быть просмотрены хакерами. Рассмотрим, как эта проблема может быть решена с помощью спецификации "Шифрование XML".
Ресурсы
Официальные страницы рабочих групп W3C Подпись XML (XML Signature) и Шифрование XML (XML Encryption).
Страница "Безопасность Web-сервисов" рабочей группы OASIS.
Цикл статьей (Часть 1 и Часть 2), посвященных канонизации XML.
В данном справочнике приводится подробное объяснение криптографии. В ней рассмотрены ключи, шифрование, цифровые подписи и профили сообщений.
Эта статья знакомит с сертификатами X.509.
Сертификаты
В самом общем виде цифровые сертификаты - это структура данных, которая содержит две информационных части:
идентификацию (например, имя, контактный адрес и пр.) владельца сертификата (индивидуума или организации); иоткрытый ключ владельца сертификата.
открытый ключ владельца сертификата.
Сертификаты, которые издают соответствующие органы, предоставляются отдельным лицам или организациям и включают две необходимых части : личность владельца и открытый ключ. Такие органы также подписывают сертификат, используя свой собственный закрытый ключ - любая заинтересованная сторона может убедиться в целостности сертификата, проверив эту подпись.
Шифрование целого XML-файла
Давайте начнем с шифрования целого XML-файла. Листинг 6 - это пример такого зашифрованного файла. При этом исходный XML-документ не показан, поскольку он не нужен, так как шифрование XML-файла своим результатом имеет такую же XML-структуру - за исключением зашифрованной величины, заключенной в элементе CipherValue.
Шифрование отдельного элемента
Как было сказано выше, структура EncryptedData несет зашифрованные данные вместе с необходимой информацией. В основе шифрования одиночного элемента XML-файла лежит аналогичный подход. Рассмотрим Листинг 7, в котором зашифрованный элемент GetSpecialDiscountedBookingForPartners из Листинга 1 получен простой заменой элементом EncryptedData.
Шифрование содержания элемента
Рассмотрим Листинг 8, в котором зашифровано только содержание элемента GetSpecialDiscountedBookingForPartners - для этого это содержание было заменено структурой EncryptedData. Этот прием похож на шифрование элемента (см. Листинг 7). Отличие состоит в том, что на этот раз значение атрибута Type тега EncryptedData равно http://www.w3.org/2001/04/xmlenc#Content. Это значение говорит о том, что зашифрованные данные должны интерпретироваться как содержание элемента.
Шифрование XML
Спецификация шифрования XML удовлетворяет требованиям конфиденциальности XML-сообщений. Эта спецификация позволяет реализовать следующую функциональность:
шифрование целого XML-файла;
шифрование любого отдельного элемента XML-файла;
шифрование только содержания XML-файла;
шифрование данных, отличных от XML (например, рисунка JPG);
шифрование уже зашифрованного элемента ("супершифрование").
Симметричная криптография
Существует еще один метод криптографии - так называемая симметричная криптография. При симметричной криптографии для шифрования и дешифрования используется один и тот же ключ. В этом случае этот секретный ключ - симметричный ключ - является общим для двух участников обмена сообщениями. С точки зрения вычислений симметричная криптография требует меньше затрат по сравнению с асимметричной. Именно поэтому асимметричная криптография обычно применяется только для передачи общей конфиденциальной информации. Как только обменивающиеся сообщениями стороны ее получают, они могут перейти к использованию симметричной криптографии.
Введение в безопасность Web-сервисов
Возникает вопрос, каким образом брандмауэр XML использует подписи и шифрование XML для защиты SOAP-серверов? Ведь несмотря на то, что возможности этих двух технологий были продемонстрированы на многочисленных примерах, необходимо выяснить, как применять эти две спецификации при использовании брандмауэра XML для защиты SOAP-серверов, особенно если учесть ни одна из них не является специфичной для SOAP. Попытаемся понять, почему вся информация, касающаяся подписи, была помещена в заголовок SOAP, а не в тело SOAP.
Спецификация консорциума OASIS "Безопасность Web-сервисов" подробно определяет, как применять технологии подписи и шифрования XML при обмене SOAP-сообщениями. Этот стандарт получает элементы низкого уровня из рассмотренных выше спецификаций ("Цифровая подпись XML" и "Шифрование XML") и задает высокоуровневый синтаксис для обертывания в SOAP-сообщениях информации о безопасности.
Спецификация "Безопасность Web-сервисов" описывает механизм безопасного обмена SOAP-сообщениями. Она обеспечивает следующую функциональность:
Целостность сообщения.
Пользовательскую аутентификацию.
Конфиденциальность.
Рассмотрим Листинг 9 - это SOAP-сообщение, которое несет информацию о безопасности согласно синтаксису спецификации "Безопасность Web-сервисов". Листинг 9 - этот тот же самый SOAP-запрос GetSpecialDiscountedBookingForPartners, который неоднократно приводился в этой статье. Однако на этот раз заголовок запроса передает информацию о цифровой подписи в соответствии с рассматриваемой спецификацией.
Вопросы обеспечения безопасности
Максим Филиппов
Менеджер проектов компании
ОАО "Элвис-Плюс"
Журнал "Сети" №7 2003г.
"Предупрежден, значит вооружен"
А.В.Суворов
Настоящая статья - это попытка сделать обзор текущего состояния безопасности беспроводных сетей с целью ответа на вопрос: возможно ли уже сегодня построить корпоративную беспроводную сеть, устраивающую собственника сети с точки зрения обеспечения требуемого уровня безопасности, а также в соответствии с требованиями законодательства РФ и руководящих документов в области защиты информации?
Технологии беспроводных сетей широко используется во всем мире, привлекая внимание пользователей относительно невысокими экономическими затратами и простотой развертывания, удобством использования и гибкой архитектурой. Бесспорным лидером на рынке беспроводных сетей, является оборудование, отвечающее спецификациям семейства стандартов 802.11. Поэтому в дальнейшем при употреблении термина "беспроводные сети", будем иметь в виду сети, построенные на оборудовании, совместимом со стандартами семейства 802.11.
Одним из основных сегментов рынка оборудования беспроводных сетей является решение для так называемых "офисных или корпоративных" сетей. Характерная особенность такого решения - создание непрерывной зоны покрытия в пределах офисного здания. Данное решение часто требует размещения достаточно большого количества точек доступа. И в таком случае, актуальной становится задача мониторинга и управления беспроводной сетью. Следовательно, уже на этапе проектирования необходимо заложить в решение использование средств централизованного управления и мониторинга состояния сети, что в дальнейшем позволит существенно снизить совокупную стоимость владения системой (TCO). В дальнейшем мы не будем возвращаться к вопросам ТСО, - это тема отдельной статьи и отдельного обсуждения.
Другим основным вопросом при построении беспроводных сетей, безусловно, является вопрос обеспечения требуемого уровня безопасности информации, циркулирующей в сети. В первую очередь, причина остроты вопроса в используемой среде передачи данных - радиоэфире. В отличие от обычных сетей, в которых информация передается по проводам, осуществить перехват информации в радиоэфире намного проще - достаточно иметь комплект оборудования, аналогичный комплекту оборудования абонента беспроводной сети. Поэтому в спецификации стандартов 802.11 особое внимание уделено вопросам безопасности - определен протокол обеспечения безопасности беспроводных сетей WEP (Wired Equivalent Privacy).
Безусловно, вопрос обеспечения безопасности, поставленный в этой статье далеко нетривиален, но с чего-то надо начинать… И чтобы подступиться к решению этого вопроса, давайте определим доступные нам меры и средства, позволяющие сделать беспроводную сеть как можно более безопасной. Итак, нам необходимо:
Уменьшить зону радиопокрытия (разумеется, до минимально приемлемой). В идеале, зона радиопокрытия сети не должна выходить за пределы контролируемой территории.
Изменить пароль администратора, установленный по умолчанию
Активизировать фильтрацию по MAC-адресам
Запретить широковещательную рассылку идентификатора сети (SSID)
Изменить идентификатор сети (SSID), установленный по умолчанию
Периодически изменять идентификатор сети (SSID)
Активизировать функции WEP
Периодически изменять WEP-ключи
Установить и настроить персональные МЭ и антивирусные программы у абонентов беспроводной сети
Выполнить соответствующие настройки фильтрации трафика на телекоммуникационном оборудовании и межсетевых экранах
Обеспечить резервирование оборудования, входящего в состав беспроводной сети
Обеспечить резервное копирование ПО и конфигураций оборудования
Осуществлять периодический мониторинг состояния защищенности беспроводной сети с помощью специализированных средств анализа защищенности для беспроводных сетей (см. например, www.iss.net, www.wildpackets.com или www.sniffer.com ).
Все эти методы защиты сегодня можно реализовать на оборудовании практически любого производителя, представленного на рынке беспроводных сетей стандарта 802.11 и имеющего логотип Wi-Fi1.
Назовем комплекс вышеперечисленных мер защиты "начальным" уровнем, ниже которого опускаться категорически нельзя при проектировании корпоративной беспроводной сети.
Допустим, весь комплекс мер реализован, но, увы, учитывая известные технические и технологические проблемы протокола WEР , и как следствие, низкий уровень сложности взлома подобной сети, беспроводную сеть с "начальным" уровнем безопасности лучше всего рассматривать как далеко небезопасную сеть. И, как следствие, точки доступа такой сети (даже при использовании WEP) не следует соединять с внутренней проводной сетью, - они должны находиться по внешнюю сторону от межсетевого экрана. Таким образом, обрабатывать конфиденциальную информацию в сети с описанным выше начальным уровнем безопасности нельзя.
Чтобы исправить ситуацию, некоторые производители (например, Agere Systems, D-Link, US Robotics,), с целью улучшения базового уровня защищенности, предлагают использовать более длинные ключи шифрования протокола WEP2 - 128, 152 или даже 256 бит. Но это часто приводит к отсутствию совместимости с оборудованием стандарта 802.11 других производителей. Кроме того, с точки зрения злоумышленника, трафик протокола WEP представляет из себя набор исходных данных для решения задачи криптоанализа типа "вскрытие с использованием выбранного ключа"3.
А учитывая то, что злоумышленнику известен алгоритм смены ключей, определенный протоколом WEP, на решение этой задачи он затратит несколько часов4. После чего нам обеспечено несанкционированное подключение к нашей беспроводной сети. Мало того, заменить MAC-адрес своей карты доступа на MAC-адрес карты доступа легального пользователя, для злоумышленника не составит особого труда, а нам станет фактически не возможно обнаружить подобный взлом. Увеличение длинны ключа даже до 256 бит, лишь увеличивает количество пакетов, которые должен прослушать злоумышленник (например, используя анализаторы пакетов AirMagnet или AiroPeek), и время, необходимое злоумышленнику для криптоанализа.
Поточный шифр RC4, лежащий в основе WEP-шифрования и разработанный американцем Рональдом Райвестом в 1987 году, получил широкое распространение благодаря удачному сочетанию криптографической стойкости и высокого быстродействия. Уязвимости реализации протокола RC-4 в WEP изучаются криптографами достаточно давно5. По мнению многих экспертов необходимо заменить криптографический инструментарий протокола WEP на более прочный.
Итак, осознание проблем протокола WEP пришло не вчера, поэтому уже сегодня на рынке есть решения, позволяющие сделать использование протокола WEP более безопасным. Например:
Использование некоторых протоколов стандарта 802.1х (о них речь пойдет ниже), позволяет решить проблему динамической смены ключей шифрования для беспроводных устройств.
Протокол MIC ( Message Integrity Check) позволяет защитить WEP-пакеты от их изменения и подделки, в процессе передачи.
Протокол TKIP (Temporal Key Integrity Protocol), также разработаный с целью улучшения ситуации с безопасностью протокола WEP, предполагает использование уникальной ключевой последовательности для каждого устройства, а также обеспечивает динамическую схему ключа каждые 10 000 пакетов. Однако, также как и WEP, протокол TKIP использует для шифрования криптографический алгоритм RC4. Отметим, что для использования протокола TKIP нет необходимости отказываться от имеющегося оборудования 802.11, достаточно лишь обновить программное обеспечение (разумеется, если производитель реализовал поддержку этого протокола).
Теперь обратимся к вопросам обеспечения безопасного информационного взаимодействия пользователей беспроводной сети с ресурсами корпоративной сети. Для решения этой задачи, нам потребуются реализовать авторизацию пользователей беспроводной сети (в протоколе WEP проверка аутентичности пользователя не реализована совсем), а также использовать более сильные методы защиты, способные обеспечить требуемый уровень конфиденциальности и целостности информации. Один из таких методов -
установка сервера контроля доступа, использующего протоколы стандарта EAP/802.1х6 (LEAP; PEAP; EAP-TLS; EAP-TTLS), с целью усиленной аутентификации абонентов беспроводной сети.
Остановимся более подробно на этом методе. Стандарт 802.1х в нашем случае определяет взаимодействие клиента беспроводной сети с сервером доступа на этапе авторизации абонента в системе. Схема авторизации пользователя в беспроводной сети показана на рисунке 1.
Наиболее популярные серверы доступа на сегодняшний день - Cisco Secure Access Control Server и Internet Authentication Service (IAS). Последний встроен в операционную систему Microsoft Windows 2000.
Не вдаваясь в технические подробности реализации конкретных протоколов стандарта 802.1х, необходимо отметить следующие важные моменты: Данная схема требует установки на стороне клиента специализированного программного обеспечения - так называемого "сапликанта". По умолчанию поддержка механизма аутентификации по протоколу 802.1х встроена в операционную систему Windows XP и доступна для установки в виде отдельного пакета для операционной системы Windows 2000 (видимо, войдет в состав пакета обновлений Service Pack #4). Сапликант также может поставляться вместе с драйверами оборудования доступа к беспроводной сети. Ряд протоколов стандарта 802.1х используют в своей работе цифровые сертификаты формата Х.509. Так, протокол PEAP для проверки пользователем сервера доступа использует сертификат сервера доступа, а протоколы EAP-TLS и EAP-TTLS для взаимной авторизации используют сертификаты X.509 как сервера доступа, так и клиента. Отметим, что существует возможность взаимодействия сервера доступа и внешнего хранилища цифровых сертификатов, например, по протоколу LDAP.
В связи с тем, что стандарт 802. 1х относительно молод, сегодня еще можно столкнуться с такими "неприятными" моментами как: реализации различными производителями одного и того же протокола не совместимы друг с другом;
отсутствие сапликантов для некоторых типов клиентских устройств доступа к беспроводной сети.
Но несмотря на все эти неприятные моменты, можно констатировать что реализованный различными производителями набор протоколов стандарта 802.1х (LEAP; PEAP; EAP-TLS; EAP-TTLS), позволяет уже сегодня выбрать и реализовать способ авторизации, устраивающий собственника беспроводной сети.
Мы понимаем, что в нашей сети могут присутствовать различные категории пользователей (абонентов). И вполне естественно, что мы захотим предоставить этим различным категориям пользователей различные права по доступу к тем или иным ресурсам. Простейший пример представлен в Таблице 1.
| Таблица 1 |
| Абоненты беспроводной сети |
Доступ к конфиденциальной информации |
Доступ к публичной информации (в т.ч. Internet) |
| Сотрудник | + |
+ |
| Гость | - |
- |
| Злоумышленник | - |
- |
Очевидно, что после аутентификации абонента беспроводной сети ему будет необходимо присвоить соответствующую его категории политику безопасности. Одной из возможных реализаций подобного подхода является:
Использование технологии, определенной стандартом 802.1q и позволяющей поместить авторизованных абонентов беспроводной сети в различные VLAN с определенной ранее политикой безопасности для каждого из этих VLAN-ов (в зависимости от типа абонента).
Итак, используя в дополнение к методам базового уровня защиты, средства усиленной аутентификации по протоколу 802.1х и средства улучшения защищенности протокола WEP, уже сегодня можно достигнуть приемлемого уровня защиты информации, циркулирующей в беспроводной сети.
К сожалению, сегодня предложить вышеописанные решения может довольно узкий круг компаний. В первую очередь - это лидеры рынка оборудования для беспроводных сетей. Причем безусловным законодателем мод на рынке решений для обеспечения безопасности беспроводных сетей является компания Cisco Sуstems.
Отметим также, что реализация средств защиты в популярных операционных системах может существенно "подтянуть" уровень безопасности для беспроводных сетей, отчасти сняв эту "головную боль" с производителей оборудования. Но вопрос совместимости реализаций конкретных протоколов различными производителями остается открытым.
Попробуем заглянуть в будущее, чтобы понять, каких перемен следует ожидать в области защиты беспроводных сетей в ближайшее время. Вот два основных момента, которые должны поставить точку вместо вопросительного знака в вопросе "Использование беспроводных сетей безопасно?":
· На смену WEP в конце 2003 года должен прийти стандарт 802.11i, который объединит в себе системы усиленной аутентификации, динамической смены ключей, управления ключами, проверки подлинности пакетов и т.д. Вместо WEР-шифрования планируется использовать AES (Advanced Encryption Standart - криптографический протокол Rijndael). Однако, это, в свою очередь, потребует разработки новых, более дорогих базовых наборов микросхем, а значит и дополнительных затрат от пользователей на обновление оборудования;
Значительно улучшится ситуация с совместимостью решений различных производителей в области безопасности беспроводных сетей. Так, уже сейчас организация WECA опубликовала спецификацию Wi-Fi Protected Access (WPA), призванную внести ясность в вопрос совместимость решений в области безопасности различных производителей и определяющую использование протокола TKIP и протоколов аутентификации стандарта 802.1х. Сертификация оборудования на соответствие спецификации Wi-Fi Protected Access начнется уже в первом квартале 2003 года, а к моменту утверждения стандарта 802.1i выйдет новая версия этой спецификации - Wi-Fi Protected Access 2, которая будет удостоверять соответствие решений различных производителей стандарту 802.1i и их интероперабельность.
А теперь вспомним, что мы живем в России, а значит, весь приведенный обзор архитектуры безопасности для беспроводных сетей будет не полным, если мы не остановимся именно на российской специфике использования средств защиты информации и средств криптографической защиты информации. Какие же требования накладывает законодательство на пользователей этих технологий в России?
Необходимо заметить, что за последнее время в России в области защиты информации сделано очень много. Появились соответствующие нормативные и руководящие документы, регламентирующие процесс защиты. Консалтинговые компании проводят аудит безопасности корпоративных сетей. Образованы органы по аттестации информационных систем. Страховые компании предлагают услуги по страхованию информационных рисков. Но, к сожалению, приходится констатировать, что всем этим новомодным услугам еще только предстоит завоевывать популярность на Российском рынке. Возможно, что все эти процессы, наконец, создадут прецеденты реальной юридической ответственности за разглашение конфиденциальной информации, а также ответственности организаций, проектирующих и внедряющих СОБИ (систему обеспечения безопасности информации), выдающих заключения (аттестаты соответствия) о соответствии построенной СОБИ требованиям руководящих документов.
Но вернемся к нашей теме. Как было сказано выше, одной из базовых технологий защиты информации в беспроводных сетях является криптография. Сегодня в России для защиты конфиденциальной информации мы ЛЕГИТИМНО можем использовать только сертифицированные ФАПСИ средства криптографической защиты информации. Именно для ЗАЩИТЫ. Надеяться на то, что позиция России по вопросу использования на ее территории "чужой" криптографии изменится, не стоит- право любого государства определять, как использовать криптографию. С другой стороны, ограничения, действующие на вывоз "сильной" криптографии из США, никто не снимал. Не менее иллюзорны надежды на то, что мы когда либо увидим реализацию российского криптоалгоритма в оборудовании зарубежных производителей.
Оптимальное решение этих проблем видится в использовании технологии защищенных частных виртуальных сетей (VPN):
Внедрение технологии VPN для обеспечения конфиденциальности и целостности информации, циркулирующей в беспроводной сети, в соответствии с требованиями российского законодательства и руководящих документов ФАПСИ и Гостехкомиссии.
Производители оборудования при построении беспроводных сетей с максимальным уровнем защищенности рекомендуют использовать VPN решения на базе семейства протоколов IPSec: например, VPN решения российских производителей органично вписываются в архитектуру SAFE - архитектуру защищенных сетей, построенных на базе оборудования Cisco Systems.
Есть еще один аргумент в пользу использования технологии VPN для защиты информации, циркулирующей в беспроводной сети. Создав на базе VPN продуктов внешнюю защитную оболочку, собственник приобретает уверенность в том, что он защищен не только от известных уязвимостей встроенных протоколов защиты беспроводных сетей, но и от тех, которые могут появиться в дальнейшем. И самое главное - использование VPN решения на базе протокола IPSec российских производителей позволяет придать всей системе защиты легитимность, поскольку появляется возможность использовать сертифицированные ФАПСИ и Гостехкомиссией России продукты.
Не смотря на то, что сама по себе технология защищенных частных виртуальных сетей способна обеспечить жесткую авторизацию пользователя по его цифровому сертификату формата Х.509, ее не следует рассматривать как альтернативу решениям на базе протокола 802.1х. Это взаимодополняющие решения. Поскольку средства VPN обеспечивают защиту на сетевом уровне, а использование решений на базе протокола 802.1х позволяет предотвратить несанкционированный доступ к беспроводной сети на более раннем этапе. Подобное решение позволяет построить многоэшелонированную защиту: авторизуя пользователей по протоколу 802.1х мы убеждаемся, что имеем дело с легальным пользователем нашей беспроводной сети, а реализуя дополнительную авторизацию средствами VPN мы убеждаемся, что допускаем к работе с конфиденциальными ресурсами пользователей, которые имеют на это право. Кроме этого, использование функций межсетевого экранирования на устройстве VPN-шлюз, позволит нам назначать различные права доступа внутри группы пользователей, имеющих доступ к конфиденциальной информации. Необходимо также заметить, что сам протокол 802.1х имеет ряд уязвимостей к атакам типа "man-in-the-middle" и "session hijacking"7. Поэтому, не лишним будет повторить: использование технологии VPN позволяет создать внешнюю защитную оболочку беспроводной сети передачи данных.
Как всегда, вопрос обеспечения требуемого уровня безопасности и вопрос удобства и простоты использования находятся на разных чашах весов. Посмотрим, что является "платой" в случае использования технологии VPN:
Снижение общей пропускной способности сети. По опыту нашей компании, в случае использования в протоколах семейства IPSec сертифицированных криптоядер, снижение производительности составит ориентировочно от 20 до 30%.
В случае использования карманных компьютеров (PDA) и/или беспроводных IP-телефонов найти VPN агента и криптографическое ядро для этих аппаратных платформ, достаточно проблематично. Поэтому, на данном этапе будет правильным применить к этим устройствам доступа политику безопасности, исключающую их взаимодействие с конфиденциальными ресурсами в корпоративной сети.
Увеличение общей стоимости (включая и ТСО) решения.
Теперь, обсудив все основные вопросы, давайте, наконец, посмотрим как может выглядеть архитектура защищенной сети передачи данных с учетом всего вышесказанного - см. рисунок 2.
1
2 Более детально описание уязвимостей протокола WEP см. на http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html
3 Брюс Шнайер. Прикладная криптография, 2-е издание: протоколы, алгоритмы, исходные тексты на языке Си.Под редакцией П.В. Семьянова. М., Триумф, 2002
4 См. например AT&T Labs Technical Report TD-4ZCPZZ "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" (доступно на http://www.cs.rice.edu/~astubble/wep/)
5 См. например Scott R. Fluhrer, Itsik Mantin, Adi Shamir: Weaknesses in the Key Scheduling Algorithm of RC4. (доступно на www.cs.umd.edu/~waa/class-pub/rc4_ksaproc.pc)
6 EAP (Extensible Authentication Protocol) - расширяемый протокол аутентификации позволяет проводить аутентификацию на основе: одноразовых паролей (OTP - one-time passwords), токенов, цифровых сертификатов, смарт-карт, протокола Kerberos. Стандарт 802.1х определяет инкапсуляцию EAP во фреймы сети. Протокол EAP определен в RFC №2284 (см. www.ietf.org/rfc/rfc2284.txt).
7 См. Arunesh Mishra, William A. Arbaugh "An Initial Security Analysis of the IEEE 802.1x Standart" (доступно на http://www.cs.umd.edu/~waa/1x.pdf)
