ViPNet Coordinator

ViPNet Coordinator - комплекс российских программных и аппаратных средств защиты информации, предназначенный для создания защищенных виртуальных частных сетей (VPN) и безопасного обмена данными.

SNMP-коллектор

1. Разрешить подключение по порту:

firewall local add src <IP-адрес сервера KOMRAD> dst @local udp dport 161 pass 

2. Запустить агент:

inet snmp start

3. Задать community:

inet snmp community add

4. При необходимости включить v2 или v3 SNMP:

inet snmp v2 ro on

5. Настроить SNMP-коллектор в соответствии с рисунком:

подсказка

Расписание устанавливается по необходимой частоте

6. Заполнить поле get соответствующими OID

7. Проверить подключение

Для SNMP v3:

 inet snmp user add <имя пользователя> [{md5 | sha}]

1. Заполнить на комрад:

inet snmp user set <имя пользователя> key

2. На KOMRAD заполнить:

inet snmp v3 ro on 

SNMP-traps

Для протоколов SNMPv1 и SNMPv2

Необходимо добавить сетевой фильтр, разрешающий передачу SNMP-оповещений на порт 1162:

firewall local add src @local dst <IP-адрес сервера KOMRAD> udp dport 1162 pass

Задайте адрес сервера KOMRAD для отправки SNMP-оповещений:

inet snmp trapsink add <IP-адрес сервера KOMRAD> port <номер> {v1 | inform}

<адрес> — IP-адрес сервера KOMRAD, <номер> — номер UDP-порта, v1 — отправлять оповещения типа TRAP по протоколу SNMPv1, inform — отправлять оповещения типа INFORM по протоколу SNMPv2c

Пример заполнения:

inet snmp trapsink add 192.168.12.55 port 1162 inform

Разрешите чтение SNMP-параметров ViPNet Coordinator HW:

inet snmp v2 ro on 

Разрешите отправку SNMP-оповещений:

inet snmp v2 traps on

Подключение SNMP-агента

Включите запуск SNMP-агента при загрузке ViPNet Coordinator HW:

inet snmp autostart on 

По умолчанию SNMP-агент регистрирует в системном журнале события с уровнем важности error. При необходимости измените уровень важности:

inet snmp logging `уровень важности`

Список возможных значений параметра уровень важности:

• off — регистрация событий выключена.
• critical — регистрируются критические ошибки, после которых SNMP-агент не может продолжить работу.
• error — регистрируются ошибки, после которых SNMP-агент может продолжать работу.
• info — регистрируется полная информация о работе SNMP-агента.
• debug — регистрируется служебная информация, используемая при отладке.

Syslog-коллектор

Сбор событий с Vipnet coordinator можно вести разными спосоьбами:

1. Экспорт журнала IP-пакетов по сети в формате CEF на произвольный UDP-порт
2. Системный журнал строго на UDP-порт 514

Экспорт журнала IP-пакетов по сети в формате CEF

1. Остановите службу iplircfg:

iplir stop

2. Откройте файл конфигурации iplir.conf:

iplir config

3. В секции misc добавьте параметры экспорта журнала IP-пакетов:

• cef_enabled — разрешение экспорта записей журнала IP-пакетов по сети:
• yes — запустить экспорт.
• no — остановить экспорт.
• cef_ip — IP-адрес сетевого узла, на который будут посылаться сообщения CEF.

4. Сохраните изменения в файле iplir.conf — нажмите Ctrl+O, затем Enter. Закройте файл iplir.conf — нажмите Ctrl+X.

5. Откройте файл конфигурации интерфейса iplir.conf-ethX, записи журнала IP-пакетов которого вы хотите экспортировать:

iplir config ethX

где X - номер интерфейса, например:

iplir config eth0

6. В секции [cef] задайте параметры формирования сообщений CEF в режиме hw:

• event — определяет формирование сообщений CEF при регистрации IP-пакетов, проходящих через интерфейс:
• all — для всех IP-пакетов.
• blocked — для блокированных IP-пакетов или с предупреждением о вторжении (значение по умолчанию).
• exclude — определяет формирование сообщений CEF, заданных в event, за исключением указанных номеров событий. Их перечисление допускается в любом порядке через запятую. При экспорте в ViPNet TIAS версии 3.8 и выше рекомендуется исключить все события, кроме 67 и 142.

7. Запустите службу iplircfg:

iplir start

8. Если сетевой узел, на который будут посылаться сообщения CEF, расположен в открытой сети, создайте разрешающее исходящее правило:

firewall local add src @local dst <IP-адрес-KOMRAD> service @Syslog pass

9. Создайте правило файрвола для разрешения отправки логов. Если между координатором и сервером сбора логов есть файрвол, добавьте разрешающее правило:

firewall local add rule "Allow Syslog" src @local dst <IP-адрес сервера KOMRAD> udp dport 49050 pass

10. Пример события:

<38>Aug 19 21:11:44 hw CEF:0|infotecs|hw|4.5|30|Local IP packet blocked by Public Network filter|10|deviceExternalId=39e20091 start=1787163001000 end=1787163001000 src=10.0.9.123 dst=10.0.9.208 spt=8 dpt=0 proto=icmp cnt=1 dvc=10.0.9.208 in=84 deviceInboundInterface=eth0 cn1=800h cn1Label=Eth protocol hex cs1=NAT no cs2=Drop yes cs3=Broadcast no cs4=Forward no cs5=Encrypted no cs1Label=FlagNAT cs2Label=FlagDrop cs3Label=FlagBroadcast cs4Label=FlagForward cs5Label=FlagEncrypted deviceDirection=0 devProd=VA VMWARE devVer=4.5.8-1191 dvchost=va1000-TEST customerURI=http://va1000-TEST:8080

Сстемный журнал

События о работе служб iplircfg, mftpd, failoverd регистрируются в системном журнале. Это позволяет контролировать работоспособность ViPNet Coordinator, своевременно выявлять и устранять причины сбоев в его работе. Журнал может храниться на ViPNet Coordinator HW (локальное протоколирование) или на удаленном сетевом узле (удаленное протоколирование).

Особенности настройки удаленного протоколирования:

• Если для удаленного протоколирования будет использоваться открытый узел, задайте фильтр открытой сети, разрешающий исходящий трафик по протоколу UDP на порт 514 этого открытого узла.
• При переключении интерфейса, через который настроено удаленное протоколирование в режим получения настроек от DHCP-сервера, возможна временная потеря связи с удаленным узлом. Чтобы избежать этого, перед настройкой интерфейса включите локальное протоколирование: hostname# machine set loghost local. После применения настроек снова включите удаленное протоколирование.
• Не рекомендуется использовать удаленное протоколирование в кластере, так как на удаленный сетевой узел не будут передаваться журналы с пассивного узла (то есть часть информации о работе ViPNet Coordinator будет утеряна).
• Если все же необходимо настроить удаленное протоколирование в кластере, задайте параметры протоколирования на обоих узлах.

Журналы, которые можно передавать с помощью syslog:

1. Настройка проверки состояния шлюзов (DGD)
2. Настройка протоколирования событий транспортного сервера MFTP
3. Служба failoverd

Подключаем передачу по syslog на порт 514:

machine set loghost <IP-адрес KOMRAD-сервера>

На самом KOMRAD в настройках коллектора syslog поменять порт UDP со стандартного 49050 на 514:

Настройка проверки состояния шлюзов (DGD)

Запустите службу DGD:

inet dgd mode on

Для каждого шлюза настройте проверку его состояния с помощью отправки запросов на тестовый IP-адрес или IP-адрес шлюза:

inet dgd next-hop add <имя шлюза> {address <адрес шлюза> | interface <интерфейс>} [test-address <тестовый адрес>] {check | no-check} {icmp | tcp80 | tcp443}

В параметре <имя шлюза> задайте произвольное имя шлюза, которое будет использоваться при настройке DGD.

Укажите IP-адрес шлюза в параметре <адрес шлюза> или имя сетевого интерфейса ViPNet Coordinator HW в параметре <интерфейс> — если интерфейс, через который доступен шлюз, получает IP-адрес по DHCP/PPP.

В параметре <тестовый адрес> укажите IP-адрес сетевого узла, по которому будет проверяться доступность шлюза. Если значение не задано, в качестве тестового IP-адреса будет использоваться IP-адрес шлюза. Несколько шлюзов могут иметь один и тот же тестовый IP-адрес.

осторожно

Не используйте одинаковые IP-адреса для проверки шлюзов DGD и для параметров testip при работе в кластере — это может привести к циклической перезагрузке обоих узлов кластера

• check — включить проверку состояния шлюза.
• no-check — выключить проверку состояния шлюза.
• icmp — использовать широковещательный запрос ICMP для проверки состояния шлюза.
• tcp80 — использовать TCP-соединение по порту 80 для проверки состояния шлюза.
• tcp443 — использовать TCP-соединение по порту 443 для проверки состояния шлюза.

Если вы настроили проверку шлюза с использованием TCP-соединения, создайте разрешающий сетевой фильтр:

firewall local add src @local dst <тестовый адрес> tcp dport 80 tcp dport 443 pass

Добавьте правило проверки состояния шлюза, при выполнении которого будет действовать определённая политика маршрутизации:

inet dgd rule add <имя правила> match-next-hop <имя шлюза> {up | down}

В параметре <имя правила> задайте уникальное имя правила проверки состояния шлюза. В параметре <имя шлюза> укажите имя шлюза, заданное на шаге 2. Выберите условие применения правила:

• up — правило будет применяться, если шлюз доступен.
• down — правило будет применяться, если шлюз недоступен.

Задайте действие правила, созданного на предыдущем шаге:

inet dgd rule add <имя правила> action-priority <приоритет> service {log command <текст сообщения> | route command policy active {<имя политики> | default}}

В параметре <имя правила> укажите имя правила проверки состояния шлюза. В параметре <приоритет> задайте приоритет правила: от 1 до 255. Чем меньше значение, тем выше приоритет правила. Выберите действие, которое будет выполняться при соблюдении всех условий правила, заданных на предыдущем шаге:

• log command текст сообщения`` — записать событие с текстом текст сообщения в системный журнал.
• route command policy active имя политики`` — активировать политику маршрутизации с именем имя политики.
• route command policy active default — активировать политику маршрутизации по умолчанию.

Чтобы настроить общие параметры для проверки доступности шлюзов:

inet dgd configuration {default | interval-time <интервал> | response-time <время> | retries-count <число проверок> | syslog-level <уровень важности>}

• interval-time <интервал> — задать время в секундах, через которое производится проверка соединения с тестовым IP-адресом шлюза. Возможные значения: 1–120.
• response-time <время> — задать время в секундах, в течение которого ожидается ответ от тестового IP-адреса шлюза. Возможные значения: 1–120.
• retries-count <число проверок> — задать число проверок IP-адреса шлюза, при достижении которого шлюз считается нерабочим. Возможные значения: 1–10.
• syslog-level <уровень важности> — изменить уровень важности событий, записываемых в системный журнал. Возможные значения: 0–4.
• default — сброс параметров на значения по умолчанию:

<уровень важности> — уровень важности событий, записываемых в системный журнал. Возможные значения:

• 0 — критические события (critical);
• 1 — ошибки (error);
• 2 — извещения (notice);
• 3 — информационные сообщения (info);
• 4 — отладочные события (debug);

Каждый последующий уровень включает в себя предыдущие. Значение -1 отключает регистрацию событий службы DGD. Чтобы просмотреть параметры проверки доступности шлюзов и состояние шлюзов:

inet show dgd next-hop

Настройка протоколирования событий транспортного сервера MFTP

Служба mftpd записывает информацию о событиях, происходящих в процессе работы транспортного сервера MFTP, в системный журнал. Завершите работу службы mftpd:

mftp stop

Откройте файл mftp.conf для редактирования:

mftp config

В секции [debug] при необходимости измените значения следующих параметров:

1. debuglevel — уровень важности событий, записываемых в журнал.

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

2. debuglogfile — источник информации, выводимой в журнал, в формате: syslog:<facility.level>, где:

facility — процесс, формирующий информацию. Возможные значения: kern (ядро), user (пользовательские программы) или daemon (службы). level — уровень важности информации. Возможные значения: err (ошибка), info (информационное сообщение) или debug (отладочная информация).

Значение параметра debuglogfile по умолчанию — syslog:daemon.debug. Сохраните изменения (Ctrl+O, затем нажмите Enter) и закройте редактор (Ctrl+X). Запустите службу mftpd:

mftp start

Настройка системы защиты от сбоев

Система защиты от сбоев предназначена для контроля работоспособности ПО ViPNet Coordinator HW и создания отказоустойчивого решения на базе двух ViPNet Coordinator HW. Система может работать в одиночном режиме или в режиме кластера. Параметры работы системы защиты от сбоев задаются в файле failover.ini. По умолчанию система защиты от сбоев работает в одиночном режиме и обеспечивает:

• контроль собственной работоспособности;
• контроль работоспособности запущенных служб и драйверов ViPNet Coordinator HW, ведение статистики использования системных ресурсов;
• контроль сбоев при обработке IP-пакетов драйвером ViPNet.

Перейти в конфиг failover.ini

failover config edit

В секции debug настройте параметр debuglevel.