Vipnet coordinator hw1000 руководство администратора

Документация на продукты ViPNet представлена в виде zip-архивов или непосредственно в виде pdf-файлов. Для просмотра документации Вам понадобится бесплатная программа Adobe Acrobat Reader. Вы ее можете скачать с сайта компании Adobe.

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)

с версии 3.x на версию 4.x

1. Подготовка загрузочной флешки
   1. скачайте и распакуйте архив «hw1000_vipnet_base_x86_64_4.2.0-1958.zip» (https://security.rkomi.ru/sites/default/files/nfs/hw1000_vipnet_base_x86_64_4.2.0-1958.zip)
   2. установите 7-Zip
   3. проверьте с помощью 7-Zip контрольную сумму файла «hw1000_vipnet_base_x86_64_4.2.0-1958.img»

Контрольная сумма должна совпадать с содержимым файла «hw1000_vipnet_base_x86_64_4.2.0-1958.img.sha256.txt» и со скриншотом ниже.

1. установите Win32DiskImager с помощью установочного файла «Win32DiskImager-0.9.5-install.exe»
2. запустите Win32DiskImager с правами локального администратора
3. в окне программы выберите файл «hw1000_vipnet_base_x86_64_4.2.0-1958.img» в распакованной директории (иконка папки)

1. вставьте флешку, выберите соответствующую букву в «Device», нажмите «Write»

ВНИМАНИЕ: СОДЕРЖИМОЕ ФЛЕШКИ БУДЕТ УНИЧТОЖЕНО!

1. нажмите «Yes»

1. дождитесь завершения процесса, нажмите «Exit» и безопасно извлеките флешку

1. подготовьте следующее
   1. загрузочную флешку
   2. флешку с файловой системой FAT32 и VBE-файлом (файл можно получить у администратора ViPNet по защищенному каналу передачи данных)
   3. монитор (VGA)
   4. клавиатуру (PS/2 или USB)
2. вставьте загрузочную флешку в координатор (любой USB порт), перезагрузите (включите, если был выключен) координатор и следуйте инструкциям:
   1. нажмите «F8» при загрузке (для надежности нажимайте кнопку много раз)

1. стрелочками выберите загрузочную флешку (строка должна начинаться с «USB») и нажмите «Enter»

1. дождитесь появления надписи «Are you sure? (y/n)», нажмите «y», затем «Enter»

1. нажмите «y» и «Enter» еще два раза в ответе на вопросы «Is this correct? (y/n)» и «ARE YOU SURE? (y/n)»

1. дождитесь окончания установки ПО и нажмите «Enter» после появления сообщения «Please remove USB flash and press ENTER»

1. дождитесь загрузки координатора и введите логин/пароль user/user

1. в ответ на вопрос «Please select setup wizard operating mode» введите «1», далее «Enter», в ответ на вопрос «Please select a contient or ocean» введите «8», далее «Enter», в ответ на вопрос «Please select a country» введите «38», далее «Enter», в ответ на вопрос «Please select one of the following time zone regions» введите «2», далее «Enter»

1. в ответ на вопрос «Is the above information OK?» введите «1», далее «Enter», в ответ на вопрос «Enter new current date and time (format YYYY-MM-DD hh:mm:ss) Or press Enter to leave current settings» нажмите «Enter», в ответ на вопрос «Would you like installing keys from TFTP, USB or CD storage device? [t/u/c]» введите «u», далее «Enter»

1. вставьте флешку с конфигурацией ViPNet (VBE-файл) и в ответ на вопрос «Insert USB storage device with DST or VBE file and press » нажмите «Enter», в ответ на вопрос «Enter password» введите пароль, который вам скажет администратор, далее «Enter», в ответ на вопрос «Do you want to reboot now? [y/n]» введите «y», далее «Enter»

1. позвоните администратору и попросите проверить удаленный доступ к координатору. Если администратор ViPNet скажет, что все в порядке, надежно удалите VBE-файл (можно воспользоваться программой Eraser или аналогичной)

Администраторы:

Приложение
Интерфейсы ViPNet Coordinator HW1000 Q2/Q3

Время на прочтение
12 мин

Количество просмотров 124K

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.

Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD (Dead Gateway Detection) и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим «ключам» можно будет найти в документации.

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.

Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.

В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).

В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.

Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.

Координатор недоступен

«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке ViPNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.

Конверт не доставлен

Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между координаторами (то есть не напрямую по защищенному каналу). Значит, если вы захотите отправить письмо по деловой почте, то клиент упакует его в конверт и отправит сначала на свой координатор. Далее на пути могут быть еще несколько координаторов, и только после этого конверт попадет на узел адресата.

Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.

Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль ViPNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку или SMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появиться ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI. Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. Например, ошибка cpu::Vendor(#3)==’GenuineIntel’ 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Неинформативные конфиги

Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».

Самые популярные выводы это:
iplirdiag -s ipsettings —node-info <идентификатор узла> ##отображение информации об узле
iplirdiag -s ipsettings —v-tun-table ##отображение всех загруженных в драйвер туннелей

Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.

(Un)split tunneling

Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»). Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.

Служебные порты и TCP-туннель

Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.

Замена координатора

Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.

При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.

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

Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.

Пересечения адресов

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.

Невозможность работы GRE

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели также в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

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

Не забываем про время

Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.

Нешифрованный трафик вместо зашифрованного

Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:

1. пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;
2. с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;
3. туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.

Обработка прикладных протоколов (ALG)

На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:

• при использовании NAT должен быть включен ALG;
• при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
• при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
• ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.

Управляется модуль командами группы «alg module» из привилегированного режима (enable).

В заключение

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

Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»

Воронежский институт МВД России
Кафедра информационной безопасности
УТВЕРЖДАЮ
Заместитель начальника кафедры
информационной безопасности
полковник полиции
А.В. Мельников
«___» ___________ 2018 г.
Тезисы лекции
по программе повышения квалификации
сотрудников подразделений территориальных органов МВД России по теме:
«ПАК ViPNet Coordinator HW1000/2000,
правила эксплуатации и обработки информации»
(c использованием системы дистанционных образовательных технологий)
Блок дистанционного обучения в системе MOODLE
Тема №2. «Защита каналов связи ИМТС МВД России с помощью программно-аппаратной технологии ViPNet»
Лекция №1. «Принципы организации защищенной телекоммуникационной инфраструктуры»
Подготовил:
старший преподаватель кафедры
информационной безопасности
подполковник полиции
С.В. Зарубин
Обсуждены и одобрены
на заседании
методической секции кафедры
информационной безопасности
протокол № __ от _______ 2018 г.
Обсуждены и одобрены
на заседании кафедры
информационной безопасности
протокол № __ от _______ 2018 г.
Воронеж 2018
1. Принципы организации защищенной телекоммуникационной инфраструктуры.
Обеспечение информационной безопасности в телекоммуникационных системах актуально, прежде всего, для организаций со сложной, территориально-распределенной, многоуровневой структурой: крупных банков, транснациональных и государственных компаний. Зачастую телекоммуникационные системы подобных организаций построены с использованием оборудования различных поколений и от разных производителей, что заметно усложняет процесс управления информационной системой. Не исключением является и распределенная телекоммуникационная система органов внутренних дел – так называемая интегрированная мультисервисная телекоммуникационная сеть (ИМТС).
Телекоммуникационная система ОВД отличается разнородностью, ее сегменты состоят из различных баз, наборов распределенных систем и задач локального характера. Это делает внутриведомственные ресурсы особенно уязвимыми. В процессе обмена данными между сотрудниками ОВД сети могут быть поражены вредоносными программами, которые разрушают базы данных и осуществляют передачу сведений третьим лицам.
Итак, что же относится к главным угрозам телекоммуникационной системы ОВД? По мнению специалистов, наиболее серьезную опасность для информационной инфраструктуры сегодня представляют вирусы (троянское ПО, черви), шпионское и рекламное программное обеспечение, спам и фишинг-атаки типа «отказ в обслуживании» и социальный инжиниринг. Причем источником угроз могут быть как удаленные пользователи, так и сотрудники локального сегмента ИМТС (часто ненамеренно).
Реализация вредоносных алгоритмов может привести как к парализации системы и ее сбоям, так и к утере, подмене или утечке информации. Все это чревато огромными потерями для ведомства.
Таким образом, главными задачами любой системы информационной безопасности являются:
• обеспечение доступности данных для авторизированных пользователей – возможности оперативного получения информационных услуг;
• гарантия целостности информации – ее актуальности и защищенности от несанкционированного изменения или уничтожения;
• обеспечение конфиденциальности сведений.
Для решения обозначенных целей сегодня применяются такие методы защиты информации, как регистрация и протоколирование, идентификация и аутентификация, управление доступом, создание межсетевых экранов и криптография. Однако о них, как и о конкретных программных продуктах на их основе, мы поговорим несколько позже.
Стоит отметить, что важность обеспечения информационной безопасности оценена и на государственном уровне, что отражается в требованиях нормативно-правовых актов, таких как:
• Гражданский кодекс РФ.
• Федеральный закон от 29.06.2004 г. № 98-ФЗ «О коммерческой тайне».
• Федеральный закон от 27.07.2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
• Федеральный закон от 27.07.2006 г. № 152-ФЗ «О персональных данных».
• Федеральный закон от 6.04.2011 г. № 63-ФЗ «Об электронной подписи».
Необходимо остановиться о регуляторах в области информационной безопасности телекоммуникационных систем.
Регуляторами в области информационной безопасности в РФ являются: Федеральная служба по техническому и экспортному контролю, Федеральная служба безопасности, Федеральная служба охраны, Министерство обороны РФ, Министерство связи и массовых коммуникаций РФ, Служба внешней разведки РФ и Банк России.
Так, регуляторами выдвигаются следующие требования к защите данных в компьютерных сетях:
• использование лицензионных технических средств и ПО;
• проведение проверки объектов информации на соответствие нормативным требованиям по защищенности;
• составление списка допустимых к применению программных средств и запрет на использование средств, не входящих в этот перечень;
• использование и своевременное обновление антивирусных программ, проведение регулярных проверок компьютеров на предмет заражения вредоносными ПО;
• разработка способов профилактики по недопущению попадания вирусов в сеть;
• разработка методов хранения и восстановления зараженного ПО.
В банковских структурах также необходимо обеспечивать разграничение доступа к данным для предотвращения преступных действий со стороны сотрудников и внедрять методы шифрования данных с целью обеспечения безопасности проведения электронных денежных операций.
Комплексный подход при построении системы информационной безопасности и защиты информации.
Надежную защиту информации в телекоммуникационной системе может обеспечить только комплексный подход, подразумевающий одновременное использование аппаратных, программных и криптографических средств (ни одно из этих средств в отдельности не является достаточно надежным). Подобный подход предусматривает анализ и оптимизацию всей системы, а не отдельных ее частей, что позволяет обеспечить баланс характеристик, тогда как улучшение одних параметров нередко приводит к ухудшению других.
Стандартом построения системы безопасности является ISO 17799, который предусматривает внедрение комплексного подхода к решению поставленных задач. Соблюдение данного стандарта позволяет решить задачи по обеспечению конфиденциальности, целостности, достоверности и доступности данных.
Организационные меры, принимаемые при комплексном подходе, являются самостоятельным инструментом и объединяют все используемые методы в единый целостный защитный механизм. Такой подход обеспечивает безопасность данных на всех этапах их обработки. При этом правильно организованная система не создает пользователям серьезных неудобств в процессе работы.
Комплексный подход включает детальный анализ внедряемой системы, оценку угроз безопасности, изучение средств, используемых при построении системы, и их возможностей, анализ соотношения внутренних и внешних угроз и оценку возможности внесения изменений в систему.
Таким образом, для обеспечения защиты информации необходимо предпринимать следующие меры:
• формирование политики безопасности и составление соответствующей документации;
• внедрение защитных технических средств.
И хотя 60–80% усилий по обеспечению безопасности в крупных телекоммуникационных системах направлено на реализацию первого пункта, второй является не менее, а возможно и более, важным.
Что касается угроз, то для телекоммуникационных систем можно выделить следующие из наиболее часто встречающихся:
1. Прослушивание каналов, т.е. запись и последующий анализ всего проходящего потока сообщений. Прослушивание в большинстве случаев не замечается легальными участниками информационного обмена.
2. Умышленное уничтожение или искажение (фальсификация) про­ходящих по сети сообщений, а также включение в поток ложных сообще­ний. Ложные сообщения могут быть восприняты получателем как под­линные.
3. Присвоение злоумышленником своему узлу или ретранслятору чужого идентификатора, что дает возможность получать или отправлять сообщения от чужого имени.
4. Преднамеренный разрыв линии связи, что приводит к полному прекращению доставки всех (или только выбранных злоумышленником) сообщений.
5. Внедрение сетевых вирусов, т.е. передача по сети тела вируса с его последующей активизацией пользователем удаленного или локального узла.
В соответствии с этим специфические задачи защиты в сетях пере­дачи данных состоят в следующем:
1. Аутентификация одноуровневых объектов, заключающаяся в подтверждении подлинности одного или нескольких взаимодействующих объектов при обмене информацией между ними.
2. Контроль доступа, т.е. защита от несанкционированного исполь­зования ресурсов сети.
3. Маскировка данных, циркулирующих в сети.
4. Контроль и восстановление целостности всех находящихся в сети данных.
5. Арбитражное обеспечение, т.е. защита от всевозможных отказов от отправки, приема или содержания отправленных или принятых данных.
2. Механизмы защиты информации в телекоммуникационной инфраструктуре.
Для решения перечисленных задач в телекоммуникационных системах создаются специальные ме­ханизмы защиты. Их перечень и содержание для общего случая могут быть представлены следующим образом.
1. Механизмы аутентификации, т.е. опознавания* пользователей, обращающихся к ресурсам сети, и представляемых им ресурсов. Для этих целей используются общеизвестные пароли, вводимые в открытом или зашифрованном виде, индивидуальные характеристики опознаваемых субъектов или объектов. В последнее время для опознавания пользовате­лей все большее распространение получают так называемые идентифика­ционные карточки.
2. Механизмы контроля доступа, осуществляющие проверку пол­номочий субъекта или объекта на право использования им запраши­ваемого ресурса. Для обеспечения указанного контроля используются списки полномочий, матрицы доступа, мандаты доступа и т.п.
3. Механизмы шифрования данных, используемые для обеспечения секретности находящихся в сети данных. Для указанных целей использу­ются два класса криптографического преобразования данных: симмет­ричные, осуществляемые с использованием секретного ключа и асиммет­ричные, осуществляемые с использованием ключей общего пользования. Непременным условием функционирования механизма шифрования яв­ляется наличие подсистемы (службы) управления распределением ключей.
4. Механизмы цифровой (электронной) подписи, включающие две подсистемы: закрытия блоков данных и проверки закрытых блоков. За­крытие блоков данных осуществляется шифрованием таким образом, что образуемый шифртекст является функцией персональных ключей подпи-сантов, содержания подписываемого текста и, быть может, некоторых дополнительных параметров (цаты, времени суток, идентификатора ЭВМ и т.п.). Проверка закрытых блоков, например, в случае возникновения конфликтных ситуаций достигается созданием службы арбитража, кото­рой должны быть известны все реквизиты подписи и решениям которой подчинялись бы участники обмена данными в сети.
5. Механизмы обеспечения целостности среды передачи и данных, причем выделяются два аспекта целостности: целостность одного блока данных (или поля памяти) и целостность потока блоков данных.
Обеспечение целостности одного блока данных достигается тем, что на передающем объекте к блоку передаваемых данных прибавляется признак, значение которого является некоторой функцией данных блока (например, контрольной суммой), а на принимающем объекте вычисляет­ся значение этого признака по принятому блоку, которое затем сравни­вается с полученным его значением.
Целостность потока блоков достигается последовательной нумера­цией передаваемых блоков.
6. Механизмы управления маршрутом, предназначенные для защи­ты от попыток несанкционированного изменения маршрута передачи данных: при обнаружении таких попыток маршрут передачи изменяется.
7. Механизмы освидетельствования, предназначенные для обеспе­чения объективного разрешения конфликтных ситуаций, возникающих в процессе передачи-приема данных в сети. Суть их заключается в анализе сложившейся ситуации третьей стороной (арбитром), которой должны доверять обе взаимодействующие стороны и которая обладает информа­цией, необходимой для объективного освидетельствования.
Особенности защиты информации в вычислительных сетях обусловлены тем, что сети, обладающие несомненными (по сравнению с ло­кальными ЭВМ) преимуществами обработки информации, усложняют организацию защиты, причем основные проблемы при этом состоят в следующем.
1) Разделение совместно используемых ресурсов. В силу совместного использования большого количества ресурсов различными пользовате­лями сети, возможно находящимися на большрм расстоянии друг от дру­га, сильно повышается риск НСД — в сети его можно осуществить проще и незаметнее.
2) Расширение зоны контроля. Администратор или оператор от­дельной системы или подсети должен контролировать деятельность поль­зователей, находящихся вне пределов его досягаемости, возможно в дру­гой стране. При этом он должен поддерживать рабочий контакт со сво­ими коллегами в других организациях.
3) Комбинация различных программно-аппаратных средств. Соеди­нение нескольких систем, пусть даже однородных по характеристикам, в сеть увеличивает уязвимость всей системы в целом. Система настроена на выполнение своих специфических требований безопасности, которые мо­гут оказаться несовместимы с требованиями на других системах. В слу­чае соединения разнородных систем риск повышается.
4) Неизвестный периметр. Легкая расширяемость сетей ведет к то­му, что определить границы сети подчас бывает сложно; один и тот же узел может быть доступен для пользователей различных сетей.
Более того, для многих из них не всегда можно точно определить сколько пользователей имеют доступ к определенному узлу и кто они.
5) Множество точек атаки. В сетях один и тот же набор данных или сообщение могут передаваться через несколько промежуточных уз­лов, каждый из которых является потенциальным источником угрозы. Естественно, это не может способствовать повышению защищенности се­ти. Кроме того, ко многим современным сетям можно получить доступ с помощью коммутируемых линий связи и модема, что во много раз увели­чивает количество возможных точек атаки. Такой способ прост, легко осуществим и трудно контролируем; поэтому он считается одним из наи­более опасных. В списке уязвимых мест сети также фигурируют линии связи и различные виды коммуникационного оборудования: усилители сигнала, ретрансляторы, модемы и т.д.
6) Сложность управления и контроля доступа к системе. Многие атаки на сеть могут осуществляться без получения физического доступа к определенному узлу — с помощью сети из удаленных точек. В этом случае идентификация нарушителя может оказаться очень сложной, если не не­возможной. Кроме того, время атаки может оказаться слишком мало для принятия адекватных мер.
3. Программно-аппаратные средства защиты информации в телекоммуникационной инфраструктуре.
К основным программно-аппаратным средствам относятся:
1. Межсетевые экраны. Они обеспечивают разделение сетей и предотвращают нарушение пользователями установленных правил безопасности. Современные межсетевые экраны отличаются удобным управлением и большим функционалом (возможностью организации VPN, интеграции с антивирусами и др.).
В настоящее время наблюдаются тенденции:
• к реализации межсетевых экранов аппаратными, а не программными средствами (это позволяет снизить затраты на дополнительное оборудование и ПО и повысить степень защищенности);
• к внедрению персональных межсетевых экранов;
• к ориентации на сегмент SOHO, что приводит к расширению функционала данных средств.
2. Антивирусная защита информации. Усилия крупнейших производителей направлены на обеспечение эшелонированной защиты корпоративных сетей. Разрабатываемые системы защищают рабочие станции, а также закрывают почтовые шлюзы, прокси-серверы и другие пути проникновения вирусов. Эффективным решением является параллельное использование двух и более антивирусов, в которых реализованы различные методы обнаружения вредоносного ПО.
3. Системы обнаружения атак. Подобные системы тесно интегрированы со средствами блокировки вредоносных воздействий и с системами анализа защищенности. Система корреляции событий акцентирует внимание администратора только на тех событиях, которые могут нанести реальный ущерб инфраструктуре компании. Производители IDS стремятся к повышению скоростных показателей своих разработок.
4. Контроль доступа и средства защиты информации внутри сети. С целью обеспечения безопасности данных крупными компаниями проводится автоматизация управления информационной безопасностью или создание общей консоли управления, а также разграничение доступа между сотрудниками согласно их функционалу. В области средств создания VPN отмечается стремление к повышению производительности процессов шифрования и обеспечения мобильности клиентов (то есть доступа к сведениям с любого устройства). Разработчики систем контроля содержимого стремятся добиться того, чтобы созданные ими системы не создавали дискомфорта пользователям.
4. Тенденции в сфере комплексной защиты информации телекоммуникационных систем.
Комплексные средства защиты информации меняются со временем и определяются прежде всего текущими экономическими условиями и существующими угрозами. Так, увеличение количества вредоносных атак и экономический кризис заставляют российские компании и госструктуры выбирать только реально работающие решения. Этим объясняется смена ориентиров.
Если раньше корпорации были нацелены в первую очередь на выполнение требований регуляторов, то теперь им не менее важно обеспечить реальную безопасность бизнеса путем внедрения соответствующих программных и аппаратных средств. Все больше компаний стремится интегрировать защитные средства с другими системами ИТ-структур, в частности, SIEM. Функция администрирования средств защиты передается от подразделений безопасности в ИТ-отделы.
В последнее время руководителями компаний и ИТ-директорами уделяется особое внимание технологичности применения, совместимости и управляемости средств защиты. Отмечается переход от простого поиска уязвимостей (чисто технического подхода) к риск-ориентированному менеджменту (к комплексному подходу).
Все более важными для клиентов становятся наглядность отчетности, удобство интерфейса, обеспечение безопасности виртуальных сред при работе с мобильными устройствами. В связи с увеличением доли целевых атак растет спрос на решения в области защищенности критических объектов и инфраструктуры (расследования компьютерных инцидентов, предотвращение DDoS-атак).
Цена организации корпоративной системы защиты сведений складывается из множества составляющих. В частности, она зависит от сферы деятельности компании, количества сотрудников и пользователей, территориальной распределённости системы, требуемого уровня защищенности и др. На стоимость работ влияет цена приобретаемого оборудования и ПО, объем выполняемых работ, наличие дополнительных сервисов и другие факторы.
Так, стоимость программно-аппаратного комплекса Cisco WebSecurity варьируется от $170 (при количестве пользователей до 1000) до $670 (5000–10 000 пользователей). Локально развертываемое устройство McAfee WebGateway стоит от $2000 до $27 000. Цена веб-фильтра Websense WebSecurity может достигать $40 000.
Стоимость Barracuda WebFilter стартует от $1500 за оборудование, обслуживающее до 100 пользователей одновременно (аппарат для обслуживания 300–8000 пользователей обойдется в $4000). При этом ежегодное обновление ПО обойдется еще в $400–1100. Приобрести GFI WebMonitor для 100 пользователей на один год можно за 208 000 рублей ($2600).
Итак, современная информационная безопасность телекоммуникационной системы базируется на концепции комплексной защиты информации, подразумевающей одновременное использование многих взаимосвязанных программно-аппаратных решений и мер социального характера, которые поддерживают и дополняют друг друга.