Настройка «С-Терра СОВ» совместно с IPsec
Данный сценарий описывает пример настройки С-Терра СОВ версии 4.3 для реализации обнаружения аномалий защищаемого трафика и одновременной передаче трафика в защищенном режиме.
Специальных требований не предъявляется.
Администратор, предварительно, должен ознакомиться: с Руководством Администратора «С-Терра Шлюз» версии 4.3, Руководством Администратора «С-Терра СОВ» версии 4.3. Обладать знаниями в области сетевой информационной безопасности, иметь опыт работы с аналогичным оборудованием/программным обеспечением.
Для организации стенда потребуется:
1. ПАК «С-Терра СОВ» версии 4.3 с установленным программным комплексом «С-Терра СОВ» версии 4.3 (sterra-ids на схеме).
2. Для организации рабочего места администратора - персональный компьютер, под управлением ОС Windows 7 или выше (admin на схеме).
3. Рабочее место в защищаемом сегменте (host1 на схеме).
4. Маршрутизатор (router1 на схеме).
5. ПАК С-Терра Шлюз версии 4.3 с установленным программным комплексом «С-Терра Шлюз» (Spoke1 на схеме).
6. Рабочая станция в сегменте, защищаемом криптошлюзом Spoke1 (host2 на схеме).
7. Коммутационное оборудование.
1. Устройство «С-Терра СОВ» должно быть инициализировано в соответствии с главой «Подготовка к эксплуатации и настройка С-Терра СОВ» документа «Программный комплекс С-Терра СОВ. Версия 4.3. Руководство Администратора». РЛКЕ.00032-01 92 01.
2. Устройство Spoke1 должно быть инициализировано в соответствии с разделом «Инициализация С-Терра шлюз на вычислительных системах архитектуры Intel x86-64. Версия 4.3. Руководство Администратора». РЛКЕ.00027-01 92 01
3. На устройстве router1 должна быть обеспечена функциональность пересылки сетевых пакетов - ip forwarding.
4. Всем устройствам присвоены сетевые имена согласно схеме.
Между устройствами стенда должна быть обеспечена IP связность.
Рисунок 1
1. В офисе предприятия размещены:
1.1. Устройство С-Терра СОВ (сетевое имя sterra-ids).
1.2. Рабочее место администратора (сетевое имя admin).
1.3. Рабочая станция (сетевое имя host1).
1.4. Удостоверяющий центр (сетевое имя Certificate_authority).
2. Недоверенный сегмент эмулируется устройством Router1.
3. Устройство Spoke1 защищает удаленный сегмент сети с рабочей станцией host2.
4. После выполнения всех приведенных в сценарии настроек между устройствами sterra-ids и Spoke1 будет построено защищенное соединение. На интерфейсе Gi0/1 устройства С-Терра СОВ будут детектироваться сетевые инциденты. Записи об этом будут помещаться в журнал инцидентов С-Терра СОВ.
1. Сетевому интерфейсу присвоить адрес из сети 192.168.2.0 с маской 255.255.255.0. В настоящем сценарии - это 192.168.2.254. Указать адрес шлюза по умолчанию, в настоящем сценарии - это 192.168.2.1
1. Сетевому интерфейсу присвоить адрес из сети 192.168.100.0 с маской 255.255.255.0. В сценарии это 192.168.100.4.
2. Задать адрес шлюза по умолчанию: 192.168.100.1.
1. Сетевому интерфейсу присвоить адрес из сети 192.168.1.0 с маской 255.255.255.0. В сценарии это 192.168.1.2.
2. Задать адрес шлюза по умолчанию: 192.168.1.1.
1. Сетевому интерфейсу ens160 присвоить адрес из сети 172.16.100.0 с маской 255.255.255.0. В сценарии это 172.16.100.1
2. Сетевому интерфейсу ens192 присвоить адрес из сети 172.16.1.0 с маской 255.255.255.0. В сценарии это 172.16.1.1
Дата и время на всех криптошлюзах и УЦ должны быть одинаковы, так как для аутентификации используются цифровые сертификаты, в которых зафиксированы дата и время начала их действия и окончания. Также одинаковые дата и время на всей инфраструктуре облегчают поиск неисправностей по лог-файлам.
1. Войдите в CLI разграничения доступа. Для этого, после появления сообщения
S-Terra administrative console
введите логин и пароль для CLI разграничения доступа:
Пользователь и пароль по умолчанию: administrator, s-terra. Обязательно смените пароль для пользователя administrator при помощи команды change user password.
login as: administrator
administrator's password:
administrator@sterragate]
2. Установите правильный тип терминала (для putty тип терминала xterm) и требуемую ширину (для удобства работы), например:
administrator@sterragate] terminal terminal-type xterm
administrator@sterragate] terminal width 150
3. Установите нужную временную зону и правильные дату и время на криптошлюзе, используя консоль linux bash. Для этого выполните следующие команды.
3.1. Войдите в linux bash.
administrator@sterragate] system
Entering system shell...
3.2. Установите нужную временную зону:
root@sterragate:~# dpkg-reconfigure tzdata
4. Установите надежный пароль для пользователя root (под данным пользователем осуществляется доступ по SSH в linux bash):
root@sterragate:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Начальные настройки завершены.
Изменение состояния интерфейсов и назначение IP адресов применяются сразу после ввода соответствующих команд. Политика безопасности применяются после выхода из режима конфигурирования.
1. Запустите cs_console и перейдите в глобальный конфигурационный режим.
2. Задайте имя устройства:
sterragate(config)#hostname sterra-ids
3. Задайте IP адреса в соответствии со схемой стенда на внешнем GigabitEthernet0/0 и внутренних GigabitEthernet0/1 и GigabitEthernet0/2 интерфейсах:
sterra-ids(config)#interface GigabitEthernet 0/0
sterra-ids(config-if)#ip address 172.16.100.2 255.255.255.0
sterra-ids(config-if)#no shutdown
sterra-ids(config-if)#exit
sterra-ids(config)#interface GigabitEthernet 0/1
sterra-ids(config-if)#ip address 192.168.100.1 255.255.255.0
sterra-ids(config-if)#no shutdown
sterra-ids(config-if)#exit
sterra-ids(config)#interface GigabitEthernet0/2
sterra-ids(config-if)#ip address 192.168.2.1 255.255.255.0
sterra-ids(config-if)#no shutdown
sterra-ids(config-if)#exit
4. Убедитесь, что интерфейсы административно включены и line protocol (способность интерфейса передавать пакеты), в данный момент, находится в состоянии up:
sterra-ids(config)#do show interfaces
GigabitEthernet0/0 is up, line protocol is up
Hardware address is 0050.569e.f94e
Internet address is 172.16.100.2/24
MTU 1500 bytes
GigabitEthernet0/1 is up, line protocol is up
Hardware address is 0050.569e.d487
Internet address is 192.168.100.1/24
MTU 1500 bytes
GigabitEthernet0/2 is up, line protocol is up
Hardware address is 0050.569e.7f77
Internet address is 192.168.2.1/24
MTU 1500 bytes
Если line protocol находится в состоянии down, то проверьте подключение сетевого интерфейса криптошлюза к коммутационному или прочему оборудованию.
5. Задайте маршрут по умолчанию через устройство Router1:
sterra-ids(config)#ip route 0.0.0.0 0.0.0.0 172.16.100.1
6. Проверьте доступность устройства Router1:
sterra-ids(config)#do ping 172.16.100.1
PING 172.16.100.1 (172.16.100.1) 100(128) bytes of data.
108 bytes from 172.16.100.1: icmp_seq=1 ttl=64 time=1.13 ms
108 bytes from 172.16.100.1: icmp_seq=2 ttl=64 time=0.237 ms
108 bytes from 172.16.100.1: icmp_seq=3 ttl=64 time=0.192 ms
108 bytes from 172.16.100.1: icmp_seq=4 ttl=64 time=0.200 ms
108 bytes from 172.16.100.1: icmp_seq=5 ttl=64 time=0.299 ms
--- 172.16.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4078ms
rtt min/avg/max/mdev = 0.192/0.411/1.131/0.362 ms
1. Для настройки нужно получить доступ к web-интерфейсу «С-Терра СОВ. Версия 4.3». Для этого на устройстве admin требуется запустить web-браузер, в адресной строке набрать URL интерфейса управления С-Терра СОВ и перейти на страницу авторизации. В поле «Логин» ввести имя пользователя «superadmin», в поле «Пароль» - пароль по умолчанию - «S-Terra-IDS-43» и нажать кнопку «Войти» см. Рисунок 2.
Рисунок 2
2. После успешного логина произойдет переход на главную страницу см. Рисунок 3:
Рисунок 3
3. Сначала требуется настроить интерфейс, на котором будет выполняться анализ трафика. Для этого следует перейти на вкладку «Параметры шаблонов конфигурационных файлов», выбрав в главном меню пункт «Параметры» в разделе «Настройки» см. Рисунок 4.
Рисунок 4
4. В верхней части страницы нажать кнопку «+Добавить параметр» см. Рисунок 5
Рисунок 5
5. В открывшемся диалоговом окне «Добавление параметра», в поле «Название параметра» ввести: «interface», в поле «Значение параметра» - имя интерфейса, на котором будет производиться анализ трафика, в данном случае это «eth1» (Gi0/1 по схеме), в раскрывающемся списке «Узел» выбрать «sterra-ids» и нажать кнопку «Добавить» см. Рисунок 6
Рисунок 6
6. Диалоговое окно будет закрыто, таблица дополнена новым параметром см. Рисунок 7.
Рисунок 7
7. Для применения изменений нужно перейти на страницу «Узлы», выбрав в главном меню одноименный пункт. На открывшейся странице нажать кнопку «Применить изменения» и, затем - «Детальная информация» в строке «sterra-ids» см. Рисунок 8
Рисунок 8
8. Далее
следует активировать правило «SURICATA ICMPv4 unknown code». Для этого
следует перейти на страницу «Список правил», выбрав в главном меню
одноименный пункт в разделе «Правила» см. Рисунок 9
Рисунок 9
9. В раскрывающемся списке «Узел:» выбрать имя узла «sterra-ids», в поле поиска ввести Sid правила «2200025» и нажать кнопку поиска см. Рисунок 10.
Рисунок 10
10. Список правил будет отфильтрован. В строке с найденным правилом нажать кнопку настроек см.Рисунок 11.
Рисунок 11
11. В диалоговом окне «Редактирование правила с SID: 2210046» нажать кнопку «Включить», затем - «Сохранить» см. Рисунок 12.
Рисунок 12
12. Диалоговое окно будет закрыто, состояние правила будет изменено на «Вкл» см.Рисунок 13.
Рисунок 13
13. Для применения изменений нужно перейти на страницу «Узлы», выбрав в главном меню одноименный пункт. На открывшейся странице нажать кнопку «Применить для всех узлов» и, затем - «Детальная информация» в строке узла «sterra-ids» см. Рисунок 14.
Рисунок 14
14. В открывшемся диалоговом окне «Узел sterra-ids» убедиться в том, что запущены сервисы logstash и kibana. После этого перезапустить сервисы: stids-suricata, stids-node-controller. Для этого поочередно нажать кнопки «Перезапуск» в строке каждого сервиса. Затем нажать на кнопку «Закрыть» см. Рисунок 15.
Рисунок 15
15. Далее требуется настроить защищенное соединение с устройством Spoke1. Настройка будет происходить локально при помощи консольного подключения.
Настройка может осуществляться и удаленно (по SSH), но исключительно по доверенному каналу связи. Доверенным каналом связи может считаться канал в пределах контролируемой зоны в случае отсутствия в нем нарушителя (в нашем примере это подсеть 192.168.100.0/24 для центрального офиса и подсеть 192.168.1.0/24 для филиала). Доверенным каналом связи также считается канал, защищенный при помощи протокола IPsec (например, после настройки шифрования между подсетями 192.168.1.0/24 и 192.168.100.0/24 разрешается выполнять настройку критошлюза Spoke1 из подсети 192.168.100.0/24 центрального офиса).
Продукт не поддерживает разностные (delta) списки отзыва сертификатов, только базовые. Учитывайте это при выборе или развертывании УЦ.
Для аутентификации партнеров по IPsec можно использовать только цифровые сертификаты, выпущенные при помощи сертифицированного СКЗИ.
Аутентификация по предопределенным ключам запрещена и возможна только в тестовых целях.
Закрытый ключ для сертификата криптошлюза будет сгенерирован при помощи утилиты cert_mgr с использованием биологического датчика случайных чисел (БИО ДСЧ). Если на криптошлюзе установлен аппаратный датчик случайных чисел, то для выработки случайных чисел по умолчанию будет использоваться аппаратный датчик. Закрытый ключ может храниться либо на файловой системе устройства, либо на защищенном ключевом носителе (токен). В данном сценарии закрытый ключ будет располагаться в специальном контейнере на файловой системе устройства. Если требуется, чтобы контейнер располагался на токене, то смотрите описание параметра create утилиты cert_mgr на портале документации http://doc.s-terra.ru.
В момент генерации ключевой пары будет также сгенерирован запрос на локальный сертификат криптошлюза. Данный запрос для его последующей доставки на УЦ будет сохранен на USB Flash накопитель.
Настройка осуществляется в CLI разграничения доступа.
При выполнении сторонних команд в CLI разграничения доступа/консоли cisco-like перед командой нужно указывать ключевое слово run. Автодополнение для команд, указываемых после run не поддерживается.
1. Генерация закрытого ключа и запроса на сертификат криптошлюза.
1.1. Вставьте USB Flash накопитель в свободный USB порт криптошлюза (накопитель будет автоматически примонтирован).
1.2. Определите имя (идентификатор) USB Flash накопителя на криптошлюзе:
administrator@sterragate] dir media:
1 dr-x 4096 Thu Jul 4 10:40:32 2019 1E181F1C181EF28F
Имя (идентификатор) USB Flash накопителя - 1E181F1C181EF28F.
1.3. Запустите процесс генерации закрытого ключа и запроса на сертификат криптошлюза с сохранением файла запроса на USB Flash накопителе (закрытый ключ остается на криптошлюзе):
administrator@sterragate] run cert_mgr create -subj "C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids" -GOST_R341012_256 -fb64 media:1E181F1C181EF28F/sterra-ids.request
· ключ -subj задает отличительное имя сертификата (Distinguished Name, DN);
Отличительное имя сертификата должно быть уникальным для каждого устройства.
· ключ -GOST_R341012_256 задает использование алгоритма подписи - ГОСТ Р 34.10-2012 (ключ 256 бит).
На УЦ для поддержки алгоритма ГОСТ Р 34.10-2012 (ключ 256 бит) должно быть установлено СКЗИ «КриптоПро CSP» версии 4.0 или новее.
· ключ -fb64 задает месторасположение и формат представления запроса на сертификат; будет использован формат представления BASE64 с сохранением файла запроса в корень USB Flash накопителя под именем sterra-ids.request.
Нажимайте предлагаемые клавиши на клавиатуре для инициализации БИО ДСЧ:
Progress: [********* ]
Press key: O
После завершения работы БИО ДСЧ файл запроса будет сохранен в корне USB Flash накопителя:
administrator@sterragate] dir media:1E181F1C181EF28F/
1 -rwx 473 Thu Jul 4 10:40:32 2019 sterra-ids.request
Настоятельно рекомендуется сохранить контейнер закрытого ключа при помощи утилиты cont_mgr. Контейнер может понадобиться в случае восстановления криптошлюза при отказе HDD/SSD диска. Носитель с файлом контейнера нужно хранить в защищенном и недоступном для третьих лиц месте.
1.4. Отмонтируйте и извлеките USB Flash накопитель (посмотреть точки монтирования можно при помощи команды run mount):
administrator@sterragate] run umount /media/1E181F1C181EF28F
2. Выпуск сертификата криптошлюза на УЦ и импортирование сертификатов УЦ и криптошлюза в базу Продукта.
2.1. Доставьте файл запроса на УЦ и выпустите по нему сертификат криптошлюза.
2.2. Скопируйте выпущенный сертификат для криптошлюза под именем sterra-ids.cer и сертификат УЦ под именем ca.cer в корень USB Flash накопителя.
2.3. Вновь вставьте USB Flash накопитель, содержащий файлы сертификатов, в свободный порт USB на криптошлюзе.
2.4. Убедитесь в наличии сертификатов на USB Flash накопителе:
administrator@sterragate] dir media:1E181F1C181EF28F/
1 -rwx 592 Thu Jul 4 10:40:32 2019 ca.cer
2 -rwx 804 Thu Jul 4 10:40:32 2019 sterra-ids.cer
3 -rwx 473 Thu Jul 4 10:40:32 2019 sterra-ids.request
Сохраняйте сертификаты. Они могу понадобиться в случае восстановления криптошлюза при отказе HDD/SSD диска.
2.5. Импортируйте сертификат УЦ в базу Продукта:
administrator@sterragate] run cert_mgr import -f media:1E181F1C181EF28F/ca.cer -t
· ключ -f задает месторасположение файла сертификата;
· ключ -t используется для импортирования доверенного (trusted) сертификата УЦ.
2.6. Импортируйте сертификат криптошлюза в базу Продукта:
administrator@sterragate] run cert_mgr import -f media:1E181F1C181EF28F/sterra-ids.cer
2.7. Убедитесь, что сертификаты успешно импортированы в базу Продукта:
administrator@sterragate] run cert_mgr show
Found 2 certificates. No CRLs found.
1 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids
Видно, что сертификат УЦ импортирован как trusted, а сертификат криптошлюза как local (local означает, что для данного сертификата есть соответствующий ключевой контейнер).
2.8. Выполните проверку статуса сертификатов в базе Продукта:
administrator@sterragate] run cert_mgr check
1 State: Inactive C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Certificate can not be verified.
2 State: Inactive C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids
Certificate can not be verified.
Видно, что все сертификаты имеют статус Inactive (неактивный) с пометкой: «Certificate can not be verified» (сертификат не может быть проверен). Причиной этому является включенный по умолчанию в консоли cisco-like механизм проверки списка отозванных сертификатов (далее СОС или CRL). Так как в базе Продукта СОС отсутствует, поэтому проверка не может быть осуществлена. Далее будет описан процесс настройки автоматической загрузки СОС и импортирование его в базу Продукта. Загрузка СОС осуществляется по протоколу HTTP с заданной периодичностью.
1. Войдите в cisco-like консоль из CLI разграничения доступа:
Пользователь и пароль по умолчанию cscons, csp. Обязательно смените пароль для пользователя cscons, так как под этим пользователем осуществляется доступ по SSH в cisco-like консоль. Также не забудьте сменить enable пароль.
administrator@sterragate] configure
sterragate login: cscons
Password:
S-Terra Gate 4.3.XXXXX (amd64)
sterragate#
2. Смените пароль для пользователя cscons и на enable:
sterragate#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
sterragate(config)#username cscons secret 0 ПАРОЛЬ
sterragate(config)#enable secret 0 ПАРОЛЬ
1. Параметры IKE.
1.1. Укажите в качестве типа идентификатора, используемого в рамках протокола IKE, отличительное имя (Distinguished Name, DN):
sterra-ids(config)#crypto isakmp identity dn
По умолчанию отличительное имя будет взято из сертификата устройства, например, для sterra-ids это «C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids».
1.2. Настройте параметры DPD (dead peer detection):
sterra-ids(config)#crypto isakmp keepalive 3 2
sterra-ids(config)#crypto isakmp keepalive retry-count 5
Пояснение:
Если в течение 3 секунд отсутствует входящий трафик в IPsec туннеле, то с интервалом в 2 секунды посылается 5 keepalive пакетов в рамках IKE туннеля, чтобы удостовериться в работоспособности туннеля. Если партнер не отвечает на keepalive пакеты, то соответствующий IKE туннель и связанные с ним IPsec туннели уничтожаются. В случае наличия исходящего защищаемого трафика происходит попытка создания новых IKE/IPsec туннелей.
1.3. Включите фрагментацию IKE пакетов:
sterra-ids(config)#crypto isakmp fragmentation
1.4. Включите случайный разброс времени жизни IKE и IPsec SA, чтобы снизить нагрузку на шлюз (позволяет избежать единовременное массовое пересоздания SA):
sterra-ids(config)#crypto isakmp security-association lifetime delta 50
1.5. Увеличьте допустимое количество одновременно инициируемых IKE сессий (не путать с общим количеством IKE сессий) для всех партнёров (значение по умолчанию 30):
sterra-ids(config)#crypto isakmp initiator-sessions-max 100
1.6. Увеличьте допустимое количество одновременных IKE обменов, проводимых шлюзом со всеми партнерами в качестве ответчика (не путать с общим количеством IKE сессий; значение по умолчанию 20):
sterra-ids(config)#crypto isakmp responder-sessions-max 100
1.7. Создайте политику, описывающую параметры IKE туннеля:
sterra-ids(config)#crypto isakmp policy 1
sterra-ids(config-isakmp)# encryption gost
sterra-ids(config-isakmp)# hash gost341112-256-tc26
sterra-ids(config-isakmp)# authentication gost-sig
sterra-ids(config-isakmp)# group vko2
sterra-ids(config-isakmp)# exit
Рекомендуется использовать одну политику для IKE туннелей. Несколько политик может потребоваться в том случае, если необходимо обеспечить совместимость со старыми версиями Продуктов, в которых нет поддержки новых алгоритмов.
2. Параметры IPsec.
2.1. Задайте комбинированный алгоритм шифрования и имитозащиты (набор преобразований) для трафика:
sterra-ids(config)# crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
sterra-ids(cfg-crypto-trans)#exit
2.2. Создайте список доступа (ACL) для трафика, который нужно защищать между центральным офисом и филиалом:
sterra-ids(config)#ip access-list extended IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
sterra-ids(config-ext-nacl)#permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255
sterra-ids(config-ext-nacl)#exit
sterra-ids(config)#
2.3. Создайте крипто-карту (имя VPN, раздел 1):
sterra-ids(config)#crypto map VPN 1 ipsec-isakmp
2.3.1 Укажите список доступа для защищаемого трафика:
sterra-ids(config-crypto-map)# match address IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
2.3.2 Укажите при помощи какого набора алгоритмов нужно защищать трафик:
sterra-ids(config-crypto-map)# set transform-set GOST_ENCRYPT_AND_INTEGRITY
2.3.3 Укажите IP адрес партнера по IPsec, в данном сценарии это внешний IP адрес устройства Spoke1:
sterra-ids(config-crypto-map)# set peer 172.16.1.2
2.3.4 Обязательно отключите историю удаленных туннелей (если не отключить, то могут быть проблемы с построением IPsec туннелей с устройствами, которые находятся за NAT):
sterra-ids(config-crypto-map)# set dead-connection history off
sterra-ids(config-crypto-map)#exit
2.4. Прикрепите созданную крипто-карту VPN к внешнему интерфейсу GigabitEthernet0/0:
sterra-ids(config)#interface GigabitEthernet0/0
sterra-ids(config-if)# crypto map VPN
2.5. Примените настройки:
sterra-ids(config-if)#end
В целях безопасности настоятельно рекомендуется включать проверку списков отзыва сертификатов. Разностные списки отозванных сертификатов (delta CRL) не поддерживаются.
1. Включите проверку СОС:
sterra-ids#configure terminal
sterra-ids(config)# crypto pki trustpoint s-terra_technological_trustpoint
sterra-ids(ca-trustpoint)# revocation-check crl
Если по обоснованным причинам использование СОС невозможно, то выключите проверку СОС и не включайте автоматическую загрузку СОС:
sterra-ids(ca-trustpoint)# revocation-check none
2. Включите автоматическую загрузку и импортирование в базу Продукта списка отозванных сертификатов с HTTP сервера CRL_distribution_point:
sterra-ids(ca-trustpoint)# crl download group ROOTCA http://172.16.101.15/certcrl.crl
3. Настройте периодичность загрузки СОС в 60 минут (по умолчанию 24 часа):
sterra-ids(ca-trustpoint)# crl download time 60
4. Примените настройки:
sterra-ids(ca-trustpoint)#end
5. Проверьте загружен ли СОС в базу Продукта:
sterra-ids#run cert_mgr show
Found 2 certificates. Found 1 CRL.
1 Status: trusted C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 Status: local C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids
3 CRL: C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
Если СОС не загрузился, то проверьте файл журнала, например:
sterra-ids#run grep getcrls_daemon /var/log/cspvpngate.log
Примечание: чтобы не ждать следующего периода загрузки СОС можно перезапустить сервис getcrls вручную:
sterra-ids#run systemctl restart getcrls.service
6. Выполните проверку статуса сертификатов в базе Продукта:
sterra-ids#run cert_mgr check
1 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=S-Terra CSP Test Root CA
2 State: Active C=RU,L=Zelenograd,O=S-Terra CSP,OU=RnD,CN=sterra-ids
Настройка криптошлюза sterra-ids завершена.
В Приложении представлены тексты конфигураций устройства sterra-ids:
· текст консоли cisco-like;
· текст LSP.
На этом настройка устройства С-Терра СОВ завершена.
1. Настройка сводится к конфигурированию защищенного соединения с устройством sterra-ids и выполняется аналогично - средствами cs_console. Текст конфигурации приведен в Приложении.
1. Для проверки работоспособности сначала нужно установить защищенное соединение. Для этого перейти в консоль устройства host1 и выполнить команду:
root@host1:~# ping 192.168.1.2 -c 5
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=62 time=771 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=62 time=0.871 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=62 time=3.77 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=62 time=0.887 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=62 time=0.903 ms
--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 0.871/155.575/771.451/307.939 ms
root@host1:~#
2. Далее - убедиться в том, что защищенное соединение успешно построено. Для этого перейти в консоль устройства sterra-ids и выполнить команду:
root@sterra-ids:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 18 (172.16.100.2,500)-(172.16.1.2,500) active 1916 1836
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 5 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440
root@sterra-ids:~#
3. После этого убедимся, что подсистема СОВ исправно детектирует сетевые инциденты.
4. Для этого необходимо сымитировать аномальный трафик, направляемый на адрес рабочей станции размещенной в контролируемом сегменте сети. Отправим c устройства host2, на адрес устройства host1, десять icmp пакетов с не валидным значением icmp code.
5. Сначала убедимся в том, что соответствующее предустановленное правило для детектирования такой атаки есть и оно активно. Для этого в главном меню в ветке «Правила» нужно выбрать пункт «Список правил». Будет открыта страница «Список правил» см. Рисунок 16.
Рисунок 16
6. В раскрывающемся списке «Узел» выбрать пункт «sterra-ids», в поисковой строке набрать: «ICMPv4 unknown code», и нажать кнопку поиска см. Рисунок 17:
Рисунок 17
7. В таблице должно быть одно искомое правило, в состоянии «Вкл» см. Рисунок 18.
Рисунок 18
8. Далее, в системной консоли устройства host2 следует выполнить команду:
root@host2:~# hping3 192.168.100.4 -1 -c 10 --icmpcode 9999
HPING 192.168.100.4 (ens192 192.168.100.4): icmp mode set, 28 headers + 0 data bytes
len=46 ip=192.168.100.4 ttl=64 id=27853 icmp_seq=0 rtt=3.9 ms
len=46 ip=192.168.100.4 ttl=64 id=27999 icmp_seq=1 rtt=3.8 ms
len=46 ip=192.168.100.4 ttl=64 id=28027 icmp_seq=2 rtt=3.7 ms
len=46 ip=192.168.100.4 ttl=64 id=28043 icmp_seq=3 rtt=7.5 ms
len=46 ip=192.168.100.4 ttl=64 id=28140 icmp_seq=4 rtt=7.5 ms
len=46 ip=192.168.100.4 ttl=64 id=28220 icmp_seq=5 rtt=3.4 ms
len=46 ip=192.168.100.4 ttl=64 id=28225 icmp_seq=6 rtt=3.3 ms
len=46 ip=192.168.100.4 ttl=64 id=28345 icmp_seq=7 rtt=7.2 ms
len=46 ip=192.168.100.4 ttl=64 id=28531 icmp_seq=8 rtt=3.2 ms
Дождаться завершения выполнения команды.
9. Далее, следует перейти в интерфейс управления С-Терра СОВ и открыть страницу «Фильтры журналов», выбрав в главном меню одноименный пункт. На открывшейся странице, в строке «Журнал инцидентов» нажать кнопку «Показать сообщения» см. Рисунок 19 :
Рисунок 19
10. Убедиться в том, что в таблицу «Журнал инцидентов» записаны сообщения «SURICATA ICMPv4 unknown code» см. Рисунок 20:
Рисунок 20
11. На этом проверка работоспособности стенда завершена.
root@host1:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:9e:74:8e brd ff:ff:ff:ff:ff:ff
altname enp11s0
inet 192.168.100.4/24 scope global ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe9e:748e/64 scope link
valid_lft forever preferred_lft forever
root@host1:~# ip route show
default via 192.168.100.1 dev ens192 proto kernel onlink
192.168.100.0/24 dev ens192 proto kernel scope link src 192.168.100.4
root@host1:~#
C:\Users\Administrator>ipconfig
Настройка протокола IP для Windows
Адаптер Ethernet Ethernet0:
DNS-суффикс подключения . . . . . :
Локальный IPv6-адрес канала . . . : fe80::fbc0:a911:5f63:2289%5
IPv4-адрес. . . . . . . . . . . . : 192.168.2.254
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.2.1
C:\Users\Administrator>route print
===========================================================================
Список интерфейсов
5...00 50 56 9e e1 d7 ......Intel(R) 82574L Gigabit Network Connection
8...00 50 56 9e 86 0c ......Intel(R) 82574L Gigabit Network Connection #2
1...........................Software Loopback Interface 1
===========================================================================
IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.254 281
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.2.0 255.255.255.0 On-link 192.168.2.254 281
192.168.2.254 255.255.255.255 On-link 192.168.2.254 281
192.168.2.255 255.255.255.255 On-link 192.168.2.254 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.2.254 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.2.254 281
===========================================================================
Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.2.1 По умолчанию
===========================================================================
IPv6 таблица маршрута
===========================================================================
Активные маршруты:
Метрика Сетевой адрес Шлюз
1 331 ::1/128 On-link
8 281 fe80::/64 On-link
8 281 fe80::74fb:1105:2d60:e651/128
On-link
1 331 ff00::/8 On-link
8 281 ff00::/8 On-link
===========================================================================
Постоянные маршруты:
Отсутствует
C:\Users\Administrator>
root@sterra-ids:~# csconf_mgr show
!
version 12.4
no service password-encryption
!
crypto ipsec df-bit copy
crypto isakmp identity dn
crypto isakmp fragmentation
crypto isakmp security-association lifetime delta 50
crypto isakmp initiator-sessions-max 100
crypto isakmp responder-sessions-max 100
crypto isakmp keepalive 3
crypto isakmp keepalive retry-count 5
username cscons privilege 15 password 0 csp
aaa new-model
!
!
hostname sterra-ids
enable password csp
!
!
!
!
crypto isakmp policy 1
encr gost
hash gost341112-256-tc26
authentication gost-sig
group vko2
!
crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
!
ip access-list extended IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
permit ip 192.168.100.0 0.0.0.255 192.168.1.0 0.0.0.255
!
!
crypto map VPN 1 ipsec-isakmp
match address IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
set transform-set GOST_ENCRYPT_AND_INTEGRITY
set peer 172.16.1.2
set dead-connection history off
!
interface GigabitEthernet0/0
ip address 172.16.100.2 255.255.255.0
crypto map VPN
!
interface GigabitEthernet0/1
ip address 192.168.100.1 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.2.1 255.255.255.0
!
!
ip route 0.0.0.0 0.0.0.0 172.16.100.1
!
crypto pki trustpoint s-terra_technological_trustpoint
revocation-check crl
crypto pki certificate chain s-terra_technological_trustpoint
certificate 58E026BFD6D625BE4582C16C6189C183
30820227308201D4A003020102021058E026BFD6D625BE4582C16C6189C18330
0A06082A850307010103023069310B3009060355040613025255311330110603
…
130101FF040530030101FF301D0603551D0E041604149481B6585600F773A290
4D575026EDC82AAD04E1301006092B06010401823715010403020100300A0608
2A85030701010302034100464986BFF801832B3F3DE1BD725DA9E065A8098425
ADE9BB6B223814A76CEC9E9BD24ECA72A6AE472E96144F5AAA08F9CDC3DA5457
AD4F8901771632E0A0AF83
quit
!
end
root@sterra-ids:~#
root@sterra-ids:~# cat /etc/ifaliases.cf
interface (name="GigabitEthernet0/0" pattern="eth0")
interface (name="GigabitEthernet0/1" pattern="eth1")
interface (name="GigabitEthernet0/2" pattern="eth2")
interface (name="default" pattern="*")
root@sterra-ids:~#
root@router1:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:9e:05:53 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.1/24 scope global ens160
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe9e:553/64 scope link
valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:9e:70:f5 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.1/24 scope global ens192
valid_lft forever preferred_lft forever
inet 172.16.101.15/24 scope global ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe9e:70f5/64 scope link
valid_lft forever preferred_lft forever
root@router1:~#
root@router1:~# ip route show
172.16.1.0/24 dev ens192 proto kernel scope link src 172.16.1.1
172.16.100.0/24 dev ens160 proto kernel scope link src 172.16.100.1
172.16.101.0/24 dev ens192 proto kernel scope link src 172.16.101.15
root@router1:~#
root@router1:~# sysctl -a |grep "ip_forward "
net.ipv4.ip_forward = 1
root@router1:~#
root@spoke1:~# csconf_mgr show
!
version 12.4
no service password-encryption
!
crypto ipsec df-bit copy
crypto isakmp identity dn
crypto isakmp fragmentation
crypto isakmp security-association lifetime delta 50
crypto isakmp initiator-sessions-max 100
crypto isakmp responder-sessions-max 100
crypto isakmp keepalive 3
crypto isakmp keepalive retry-count 5
username cscons privilege 15 password 0 csp
aaa new-model
!
!
hostname spoke1
enable password csp
!
!
!
!
crypto isakmp policy 1
encr gost
hash gost341112-256-tc26
authentication gost-sig
group vko2
!
crypto ipsec transform-set GOST_ENCRYPT_AND_INTEGRITY esp-gost28147-4m-imit
!
ip access-list extended IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
permit ip 192.168.1.0 0.0.0.255 192.168.100.0 0.0.0.255
!
!
crypto map VPN 1 ipsec-isakmp
match address IPSEC_ACl_S-TERRA-IDS_AND_SPOKE1
set transform-set GOST_ENCRYPT_AND_INTEGRITY
set peer 172.16.100.2
set dead-connection history off
!
interface FastEthernet0/0
ip address 172.16.1.2 255.255.255.0
crypto map VPN
!
interface FastEthernet0/1
ip address 192.168.1.1 255.255.255.0
!
!
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
crypto pki trustpoint s-terra_technological_trustpoint
revocation-check crl
crypto pki certificate chain s-terra_technological_trustpoint
certificate 58E026BFD6D625BE4582C16C6189C183
30820227308201D4A003020102021058E026BFD6D625BE4582C16C6189C18330
0A06082A850307010103023069310B3009060355040613025255311330110603
…
130101FF040530030101FF301D0603551D0E041604149481B6585600F773A290
4D575026EDC82AAD04E1301006092B06010401823715010403020100300A0608
2A85030701010302034100464986BFF801832B3F3DE1BD725DA9E065A8098425
ADE9BB6B223814A76CEC9E9BD24ECA72A6AE472E96144F5AAA08F9CDC3DA5457
AD4F8901771632E0A0AF83
quit
!
end
root@spoke1:~#
root@host1:~# ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:9e:0e:b0 brd ff:ff:ff:ff:ff:ff
altname enp11s0
inet 192.168.1.2/24 scope global ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe9e:eb0/64 scope link
valid_lft forever preferred_lft forever
root@host1:~# ip route show
default via 192.168.1.1 dev ens192 proto kernel onlink
192.168.1.0/24 dev ens192 proto kernel scope link src 192.168.1.2
root@host1:~#