| Скачать в формате PDF | 
|
|---|
Расширение возможностей протоколирования и мониторинга шлюза безопасности «С-Терра Шлюз»
Настоящий документ содержит описание способа совместного использования Продуктов компании ООО
«С-Терра СиЭсПи» и Продуктов третьих производителей.
ООО «С-Терра СиЭсПи» осуществляет сопровождение настоящего сценария в части настроек Продуктов Компании. Упоминание наименований, продуктов, торговых марок третьих организаций исключительно неформально и не является поддержкой, рекомендацией либо рекламой. ООО «С-Терра СиЭсПи» не несет какой-либо ответственности в отношении работоспособности и использования этих Продуктов.
Документ имеет статус вспомогательного материала, который может быть использован технологическими партнерами, компаниями-интеграторами, при разработке собственных решений.
Решения, разработанные на базе данного сценария, могут применяться в действующих сетях/системах
только после тестовой и/или опытной эксплуатации.
Дополнительные файлы:
zbx_sterra_gates_snmpv2_template.zip
В данном сценарии рассматривается настройка SNMP-агента для сбора статистики на шлюзе безопасности «С-Терра Шлюз 4.2» с примерами пользовательских скриптов, некоторые настройки Syslog, шаблон для сервера Zabbix и прочее.
С устройства Server будет запрашиваться статистика шлюза GW1 по SNMP протоколу. Построение защищенного IPsec туннеля в данном сценарии рассматриваться не будет.
Канал между системой мониторинга Server и шлюзом GW1 должен быть доверенным. В данном документе мониторинг будет осуществляться через подсеть 192.168.1.0/24, которая является доверенной. Если требуется осуществлять мониторинг через Интернет, то трафик нужно защитить при помощи IPsec.
Схема стенда (Рисунок 1):
Рисунок 1
В состав Продукта «С-Терра Шлюз» входит два SNMP агента. Первый (VPNGATE) отвечает за предоставление информации о подсистемах IKE/IPsec, второй (SNMPD) – за выдачу общей информации о системе (счетчики сетевых интерфейсов, загрузка ЦПУ/ОЗУ и так далее).
Два SNMP агента работают следующим образом. Агент SNMPD принимает все SNMP запросы на порту 161 и проксирует определенные объектные идентификаторы (OIDs, список можно посмотреть в /etc/snmp/snmpd.conf) агенту VPNGATE.
SNMP агент VPNGATE не поддерживает SNMPv3, но благодаря проксированию запросов от SNMPD к VPNGATE становится возможным получение статистики об подсистемах IKE/IPsec по SNMPv3.
Дополнительную информацию о настройке SNMP можно прочитать в документации на «С-Терра Шлюз 4.2» (http://doc.s-terra.com/ -> С-Терра Шлюз -> С-Терра Шлюз 4.2 -> Мониторинг).
В данном документе для настройки SNMP агента VPNGATE будет использоваться cisco-like консоль.
Замените содержимое по умолчанию файла /etc/snmp/snmpd.conf на приведенное ниже и отредактируйте настройки, руководствуясь пояснениями:
###############################################################
# Listen for connections from the local system only.
#agentaddress udp:127.0.0.1:161
# Listen for connections on all interfaces.
#agentaddress udp:161
####################################################################
# ATTENTION: change community and restrict access to SNMP requests #
# from the specified sources for security reasons. #
####################################################################
# Read-only access from anywhere with 'public' community string.
rocommunity public default -V customview
# Read-only access from 10.0.0.0/16 with 'public' community string.
#rocommunity public 10.0.0.0/16 -V customview
# .iso.org.dod.internet.mgmt.mib-2
view customview included .1.3.6.1.2.1
# .iso.org.dod.internet.private.enterprises.cisco
view customview included .1.3.6.1.4.1.9
# S-TERRA-CSP-MIB.
view customview included .1.3.6.1.4.1.31342
# .iso.org.dod.internet.private.enterprises.Debian.project.keepalived
view customview included .1.3.6.1.4.1.9586.100.5
# .iso.identified-organization.dod.internet.private.enterprise.ucdavis
view customview included .1.3.6.1.4.1.2021
# .iso.identified-organization.dod.internet.private.enterprise.netSnmpObjects.nsExtensions
# For using 'extend' directive (NET-SNMP-EXTEND-MIB).
view customview included 1.3.6.1.4.1.8072.1.3
# Configures monitoring of all disks found on the system, using the specified (percentage) threshold.
includeAllDisks 10%
# Proxy directive to pass part of the OID tree to S-Terra CSP SNMP agent to retrieve IKE and IPsec stats.
# Example of S-Terra Gate SNMP configuration in Cisco-like console:
# snmp-server community public RO
# snmp-server polling address 127.0.0.1
# snmp-server polling udp-port 1161
proxy -v 2c -c "public" 127.0.0.1:1161 .1.3.6.1.4.1.9 # IKE and IPsec stats
proxy -v 2c -c "public" 127.0.0.1:1161 .1.3.6.1.2.1.1.1.0 # sysDescr
###############################################################
Пояснения:
agentaddress <ip-адрес>:<порт> - локальный адрес шлюза, на который будет приходить запрос от системы управления сетевой инфраструктурой; 161 - локальный порт (стандартный).
rocommunity – задает значение community-строки (в данном случае – “public”) с правами только на чтение, а следующее за ним ключевое слово default -V <имя> указывает какие объектные идентификаторы (OID) будут выдаваться. Если нужны права не только на чтение, но и на запись значений OID, замените rocommunity на rwcommunity.
view <имя> included <OID> – задает значения, объектных идентификаторов, доступные для использования. В качестве <OID> в конфигурации указаны поддеревья идентификаторов, т.е. доступными для использования становятся все присутствующие в системе значения, являющиеся дочерними к указанным.
includeAllDisks <число>% – включает мониторинг дискового пространства. Числом указывается процент оставшегося места на диске. В случае, если свободного места на диске оказывается меньше указанного, переменная UCD-SNMP-MIB::dskErrorFlag.<номер> для соответствующего раздела примет значение «1».
proxy -v 2c -c "public" 127.0.0.1:1161 <OID> – указывает, что запросы к <OID> нужно перенаправлять встроенному агенту VPNGATE.
Важно: после внесения изменений в конфигурационный файл /etc/snmp/snmpd.conf необходимо перезапустить демон SNMPD
Чтобы при перезагрузке шлюза демон SNMPD стартовал автоматически, выполните команду:
root@GW1:~# update-rc.d snmpd enable
update-rc.d: using dependency based boot sequencing
Также опционально в файл /etc/snmp/snmpd.conf могут быть добавлены следующие настройки:
sysdescr <текстовое описание платформы>
syslocation <описание физического расположения шлюза безопасности>
syscontact <контактная информация администратора шлюза безопасности>
При добавлении параметра sysdescr следует закомментировать строку с проксированием OID .1.3.6.1.2.1.1.1.0 к агенту VPNGATE, в противном случае будет всегда возвращаться значение, полученное от VPNGATE.
Пример настройки:
sysdescr S-Terra Gate 7000 4.2 KC1
syslocation Moscow, Company office A, Room 34, rack 1
syscontact A.A.Ivanov <ivanov@company.ru>
Настройка встроенного SNMP-агента осуществляется посредством конфигурации в cisco-like консоли:
1. Войдите в режим конфигурирования cs_console:
root@GW1~# cs_console
GW1>en
Password:
2. Перейдите в режим настройки:
GW1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3. Задайте настройки встроенного SNMP-агента следующими командами:
GW1(config)#snmp-server community public
GW1(config)#snmp-server polling address 127.0.0.1
GW1(config)#snmp-server polling udp-port 1161
4. Далее следует выйти из cisco-like консоли:
GW1(config)#end
GW1#exit
Community строка в команде snmp-server community (в данном случае public) и UDP порт в snmp-server polling udp-port должны соответствовать строкам из настроек proxy в файле /etc/snmp/snmpd.conf (строки proxy -v 2c -c "public" …).
Информацию по настройке встроенного SNMP-агента с использованием LSP конфигурации можно посмотреть в документации, http://doc.s-terra.ru раздел С-Терра Шлюз -> С-Терра Шлюз 4.2 -> Мониторинг -> Выдача статистики -> Настройка SNMP-агента для выдачи статистики -> LSP (native) конфигурация.
Создайте учетную запись пользователя SNMPv3, для этого:
1. Остановите SNMP-демон:
root@GW1:~# service snmpd stop
2. Выполните команду:
net-snmp-config --create-snmpv3-user -ro [-A authpass] [-X privpass] [-a MD5|SHA] [-x DES|AES] <username>
где <username> – имя учетной записи.
Например:
root@GW1:~# net-snmp-config --create-snmpv3-user -ro -A "password" -X "secretpass" -a SHA -x AES test_user
adding the following line to /var/lib/snmp/snmpd.conf:
createUser test_user SHA "password" AES secretpass
adding the following line to /usr/share/snmp/snmpd.conf:
rouser test_user
3. Запустите SNMP-демон:
root@GW1:~# service snmpd start
В данном сценарии проверка работоспособности производится с помощью отправки SNMP запросов с использованием утилит snmpwalk и snmpget c устройства Server на шлюз GW1. На устройство Server рекомендуется установить нужный набор MIB файлов для преобразования OID в читаемый вид. Архив с MIB файлами доступен на портале http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2 -> файл mibs.zip.
Выполните запрос к SNMPD агенту, например, для получения времени работы системы:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (408670) 1:08:06.70
Выполните запрос для получения IKE и IPsec статистики (эти запросы проксируются к агенту VPNGATE):
root@Server:~# snmpwalk -v 2c -c public 192.168.1.1:161 1.3.6.1.4.1.9.9.171
CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecMibLevel.0 = INTEGER: 1
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeGlobalActiveTunnels.0 = Gauge32: 0
CISCO-IPSEC-FLOW-MONITOR-MIB::cikeGlobalPreviousTunnels.0 = Counter32: 0 SAs
…
Выполните запросы для просмотра значений sysDescr, sysLocation, sysContact (если они были заданы):
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: S-Terra Gate 7000 4.2 KC1
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: Moscow, Company office A, Room 34, rack 1
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: A.A.Ivanov <ivanov@company.ru>
Если параметр sysDescr не был задан, то по соответствующему запросу будет возвращаться ответ от агента VPNGATE:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: S-Terra Gate 4.2.18201, Emulation of: Cisco IOS Software, 2800 Software (C2800NM-ADVIPSERVICESK9-M), Version 12.4(13a), RELEASE SOFTWARE (fc1)
Для проверки работы SNMPv3 выполните любой из запросов выше, указав третью версию протокола (-v 3) и подставив параметры аутентификации, которые были заданы при создании пользователя SNMPv3:
root@Server:~# snmpget -v 3 -u test_user -l authPriv -A "password" -X "secretpass" -a SHA -x AES 192.168.1.1:161 1.3.6.1.2.1.25.1.1.0
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (233475) 0:38:54.75
SNMPD можно настроить так, чтобы по SNMP запросу выполнялся какой либо указанный пользователем скрипт и возвращался результат его работы, что позволяет расширить возможности мониторинга.
Программы и скрипты запускаются демоном SNMPD от пользователя snmp.
Рассмотрим простой пример пользовательского скрипта. Создайте файл /home/test_script.sh со следующим содержимым:
#!/bin/bash
echo Test
echo 1234
exit 0
Этот скрипт два раза выводит по одной строке в stdout и завершается с кодом 0. Для того, чтобы иметь возможность вызвать данный скрипт по SNMP запросу и получать результат его выполнения, добавьте в файл /etc/snmp/snmpd.conf следующую строку:
extend custom_script /bin/bash /home/test_script.sh
где:
extend – директива (ключевое слово),
custom_script – название директивы,
/bin/bash /home/test_script.sh – команда, выполняющаяся при вызове этой директивы по SNMP.
После редактирования конфигурационного файла нужно перезапустить демон SNMPD.
Для проверки работы пользовательских скриптов с устройства Server будут отправляться SNMP запросы на шлюз GW1.
Отправьте следующий SNMP запрос:
root@Server:~# snmpwalk -v 2c -c public 192.168.1.1:161 NET-SNMP-AGENT-MIB::nsExtensions
NET-SNMP-EXTEND-MIB::nsExtendNumEntries.0 = INTEGER: 1
NET-SNMP-EXTEND-MIB::nsExtendCommand."custom_script" = STRING: /bin/bash
NET-SNMP-EXTEND-MIB::nsExtendArgs."custom_script" = STRING: /home/test_script.sh
NET-SNMP-EXTEND-MIB::nsExtendInput."custom_script" = STRING:
NET-SNMP-EXTEND-MIB::nsExtendCacheTime."custom_script" = INTEGER: 5
NET-SNMP-EXTEND-MIB::nsExtendExecType."custom_script" = INTEGER: exec(1)
NET-SNMP-EXTEND-MIB::nsExtendRunType."custom_script" = INTEGER: run-on-read(1)
NET-SNMP-EXTEND-MIB::nsExtendStorage."custom_script" = INTEGER: permanent(4)
NET-SNMP-EXTEND-MIB::nsExtendStatus."custom_script" = INTEGER: active(1)
NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."custom_script" = STRING: Test
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."custom_script" = STRING: Test
1234
NET-SNMP-EXTEND-MIB::nsExtendOutNumLines."custom_script" = INTEGER: 2
NET-SNMP-EXTEND-MIB::nsExtendResult."custom_script" = INTEGER: 0
NET-SNMP-EXTEND-MIB::nsExtendOutLine."custom_script".1 = STRING: Test
NET-SNMP-EXTEND-MIB::nsExtendOutLine."custom_script".2 = STRING: 1234
NET-SNMP-EXTEND-MIB::nsExtendOutLine."custom_script".2 = No more variables left in this MIB View (It is past the end of the MIB tree)
Выделены строки, показывающие код возврата и строки, которые вывел скрипт test_script.sh.
Примечание: данный запрос выполняет все директивы extend, прописанные в конфигурационном файле /etc/snmp/snmpd.conf.
Чтобы получить какое-либо конкретное значение от скрипта, например, код возврата, выполните следующий SNMP запрос (обратите внимание на экранирование кавычек в теле запроса):
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendResult.\"custom_script\"
NET-SNMP-EXTEND-MIB::nsExtendResult."custom_script" = INTEGER: 0
Чтобы получить, например, вторую выведенную скриптом строку выполните:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"custom_script\".2
NET-SNMP-EXTEND-MIB::nsExtendOutLine."custom_script".2 = STRING: 1234
Следующий запрос получает сразу все строки, которые скрипт пишет в stdout:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutputFull.\"custom_script\"
NET-SNMP-EXTEND-MIB::nsExtendOutputFull."custom_script" = STRING: Test
1234
Таким запросом удобнее пользоваться в случаях, когда скрипт пишет только одну строку в stdout.
В данном варианте используется создание пользовательского OID, при запросе к которому будет выполняться скрипт.
Для демонстрации будет использоваться скрипт /home/test_script.sh из примера выше.
В конфигурационный файл /etc/snmp/snmpd.conf добавьте следующую строку:
extend .1.3.6.1.4.1.31342.1.1.1000.1 custom_script /bin/bash /home/test_script.sh
где:
extend – директива (ключевое слово),
.1.3.6.1.4.1.31342.1.1.1000.1 – OID из ветви для пользовательских нужд (1.3.6.1.4.1.31342.1.1.1000) S-TERRA-CSP-MIB,
custom_script – название директивы,
/bin/bash /home/test_script.sh – команда, выполняющаяся при вызове этой директивы по SNMP.
После редактирования конфигурационного файла нужно перезапустить демон SNMPD.
Для проверки работы отправьте SNMP запрос, содержащий указанный OID:
root@Server:~# snmpwalk -v 2c -c public 192.168.1.1:161 .1.3.6.1.4.1.31342.1.1.1000.1
S-TERRA-CSP-MIB::stGateUserDefined.1.1.0 = INTEGER: 1
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.2.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = STRING: "/bin/bash"
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.3.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = STRING: "/home/test_script.sh"
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.4.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = ""
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.5.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 5
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.6.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 1
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.7.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 1
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.20.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 4
S-TERRA-CSP-MIB::stGateUserDefined.1.2.1.21.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 1
S-TERRA-CSP-MIB::stGateUserDefined.1.3.1.1.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = STRING: "Test"
S-TERRA-CSP-MIB::stGateUserDefined.1.3.1.2.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = STRING: "Test
1234"
S-TERRA-CSP-MIB::stGateUserDefined.1.3.1.3.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 2
S-TERRA-CSP-MIB::stGateUserDefined.1.3.1.4.13.99.117.115.116.111.109.95.115.99.114.105.112.116 = INTEGER: 0
S-TERRA-CSP-MIB::stGateUserDefined.1.4.1.2.13.99.117.115.116.111.109.95.115.99.114.105.112.116.1 = STRING: "Test"
S-TERRA-CSP-MIB::stGateUserDefined.1.4.1.2.13.99.117.115.116.111.109.95.115.99.114.105.112.116.2 = STRING: "1234"
S-TERRA-CSP-MIB::stGateUserDefined.1.4.1.2.13.99.117.115.116.111.109.95.115.99.114.105.112.116.2 = No more variables left in this MIB View (It is past the end of the MIB tree)
Данный вариант не рекомендуется к использованию из-за неудобного формата получающихся OID.
В данном разделе приведены примеры пользовательских скриптов, которые можно использовать для получения расширенной информации о состоянии шлюза. Настройка SNMPD конфигурации для выполнения пользовательских скриптов описана в соответствующем разделе.
Некоторые из приведенных ниже примеров используют cron для своей работы. Для того, чтобы сервис cron стартовал автоматически после включения или перезагрузки шлюза, необходимо выполнить следующую команду в linux bash консоли шлюза:
root@GW1:~# update-rc.d cron enable
При переходе состояния шлюза в MASTER, BACKUP или FAULT выполняются соответствующие скрипты, которые находятся в директории /etc/keepalived/scripts/
Отредактируйте /etc/keepalived/scripts/notify_master следующим образом:
#!/bin/bash
# Script to run during MASTER transit
echo MASTER > /home/status.txt
exit 0
То же самое сделайте для скриптов notify_backup и notify_fault, заменив значение вывода команды echo на нужное. В конфигурационном файле /etc/snmp/snmpd.conf создайте директиву extend, по обращению к которой будет прочитан VRRP статус из файла, например:
extend show_vrrp_status /bin/cat /home/status.txt
Для удобства мониторинга срока действия локального сертификата были созданы специальные скрипты. Скрипты лежат в директории get_days_until_local_cert_exp в архиве snmp_extend_scripts.zip, который доступен для загрузки на портале документации http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2.
Рядом со скриптами также находится файл README.txt с подробными пояснениями по работе скриптов.
Для начала работы со скриптами выполните следующие действия:
1. Ознакомьтесь с содержимым файла README.txt.
2. Создайте на криптошлюзе следующую директорию:
/opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/
и перенесите оба скрипта в нее.
3. Настройте cron на выполнение скрипта get_days_until_local_cert_exp.cron.bash один раз в сутки. Дополнительно: выполните данный скрипт вручную, не дожидаясь его вызова из cron.
4. В конфигурационном файле /etc/snmp/snmpd.conf создайте директиву extend для скрипта get_days_until_local_cert_exp.extend.bash:
extend get_days_until_local_cert_exp /bin/bash /opt/snmp_monitoring/snmp_extend/get_days_until_local_cert_exp/get_days_until_local_cert_exp.extend.bash
После редактирования файла необходимо перезапустить демон SNMPD.
Отправьте SNMP запрос для получения количества дней до истечения локального сертификата:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"get_days_until_local_cert_exp\".1
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_days_until_local_cert_exp".1 = STRING: 338
Отправьте SNMP запрос для получения кода выхода скрипта:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendResult.\"get_days_until_local_cert_exp\"
NET-SNMP-EXTEND-MIB::nsExtendResult."get_days_until_local_cert_exp" = INTEGER: 0
Для мониторинга статистики системы шифрования (количество входящих, исходящих, потерянных IPsec пакетов, потери низкоприоритетных и высокоприоритетных пакетов, проценты потерь) были созданы специальные скрипты.
Скрипты лежат в директории check_kstat_show в архиве snmp_extend_scripts.zip, который доступен для загрузки на портале документации http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2.
Рядом со скриптами также находится файл README.txt с подробными пояснениями по работе скриптов.
Для начала работы со скриптами выполните следующие действия:
1. Ознакомьтесь с содержимым файла README.txt.
2. Создайте на криптошлюзе следующую директорию:
/opt/snmp_monitoring/snmp_extend/check_kstat_show/
и перенесите оба скрипта в нее.
3. Настройте cron на выполнение скрипта check_kstat_show.cron.py c периодичностью в одну или несколько минут. Дополнительно: выполните данный скрипт вручную, не дожидаясь его вызова из cron.
4. В конфигурационном файле /etc/snmp/snmpd.conf создайте директивы extend, которые будут отвечать за вызов скрипта check_kstat_show.extend.sh с нужными параметрами, например:
extend ipsec_dropped_percentage /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh ipsec_dropped_percentage
extend high_prio_dropped_pkts /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh high_prio_dropped_pkts
extend low_prio_dropped_pkts /bin/bash /opt/snmp_monitoring/snmp_extend/check_kstat_show/check_kstat_show.extend.sh low_prio_dropped_pkts
После редактирования файла необходимо перезапустить демон SNMPD.
Отправьте SNMP запрос для проверки одной из созданных директив extend, например:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"ipsec_dropped_percentage\".1
NET-SNMP-EXTEND-MIB::nsExtendOutLine."ipsec_dropped_percentage".1 = STRING: 0.0
Для мониторинга состояния сетевого канала с использованием ICMP ping до задаваемого пользователем адреса хоста и вычисления таких параметров как rtt, jitter и loss были созданы специальные скрипты.
Скрипты лежат в директории get_rtt_jitter_loss в архиве snmp_extend_scripts.zip, который доступен для загрузки на портале документации http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2.
Рядом со скриптами также находится файл README.txt с подробными пояснениями по работе скриптов.
Для начала работы со скриптами выполните следующие действия:
1. Ознакомьтесь с содержимым файла README.txt.
2. Создайте на криптошлюзе следующую директорию:
/opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/
и перенесите оба скрипта в нее.
3. Отредактируйте скрипт get_rtt_jitter_loss.cron.bash, указав в переменной HOST_TO_MONITORING желаемый адрес хоста.
4. Настройте cron на выполнение скрипта get_rtt_jitter_loss.cron.bash с желаемой периодичностью. Дополнительно: выполните данный скрипт вручную, не дожидаясь его вызова из cron.
5. В конфигурационном файле /etc/snmp/snmpd.conf создайте директивы extend, которые будут отвечать за вызов скрипта get_rtt_jitter_loss.extend.bash с нужными параметрами, например:
extend get_rtt /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash rtt
extend get_loss /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash loss
extend get_jitter /bin/bash /opt/snmp_monitoring/snmp_extend/get_rtt_jitter_loss/get_rtt_jitter_loss.extend.bash jitter
После редактирования файла необходимо перезапустить демон SNMPD.
Отправьте SNMP запрос для проверки одной из созданных директив extend, например:
root@Server:~# snmpget -v 2c -c public 192.168.1.1:161 NET-SNMP-EXTEND-MIB::nsExtendOutLine.\"get_rtt\".1
NET-SNMP-EXTEND-MIB::nsExtendOutLine."get_rtt".1 = STRING: 0.592
Для удобства мониторинга шлюзов С-Терра Шлюз по SNMP был создан шаблон для Zabbix сервера. Архив с шаблоном доступен на портале http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2 -> файл zbx_sterra_gates_snmpv2_template.zip.
В архиве вместе с шаблоном присутствует его описание (README.md). Шаблон протестирован на версиях Zabbix 4.4 и 5.0 LTS.
Для импорта шаблона в веб интерфейсе Zabbix перейдите на вкладку Configuration -> Templates и нажмите на кнопку Import. Выберите файл шаблона и импортируйте его с параметрами по умолчанию.
Для корректной работы шаблона на сервере Zabbix должен присутствовать нужный набор MIB файлов. Архив с MIB файлами доступен на портале http://doc.s-terra.com в разделе Типовые сценарии применения -> Версия 4.2 -> файл mibs.zip.
При использовании шаблона для мониторинга криптошлюзов С-Терра Шлюз версии 4.2 следует перевести некоторые элементы данных, перечисленные ниже, в состояние Disabled. Эти элементы данных по умолчанию работают для криптошлюзов С-Терра Шлюз версии 4.3.
1. Из группы IPsec Monitoring:
· Number of active IPsec tunnels with S-Terra Unit
2. Из группы Extended:
· Все элементы данных
3. Из раздела Triggers:
· Все триггеры Days until local certificate expires Trigger
4. Из раздела Discovery rules:
· VRRP Instance Discovery
В случае, если был настроен мониторинг срока действия локального сертификата в точном соответствии с разделом «Мониторинг срока действия локального сертификата», оставьте соответствующие элементы данных (“Days until local certificate expires” и “Days until local certificate expires (script exit code)”) и относящиеся к ним триггеры включенными.
В случае, если был настроен мониторинг сетевого канала с помощью ICMP в точном соответствии с разделом «Мониторинг состояния канала с помощью ICMP», оставьте соответствующие элементы данных включенными (“SLA Jitter”, “SLA Loss” и “SLA RTT”).
Если вы хотите, чтобы элементы данных, относящиеся к статистике системы шифрования (“IPsec dropped packets percentage”, “High priority packets dropped”, “Low priority packets dropped”), были работоспособными, выполните инструкцию из раздела «Мониторинг статистики системы шифрования» в точном соответствии с приведенным там примером.
В конфигурационном файле /etc/rsyslog.conf можно настроить отправку логов на несколько серверов по заданным IP-адресам и номерам портов. Например, следующие строки:
*.err @192.168.0.10:516
*.err @192.168.0.200:51400
указывают, что все логи уровня важности err и выше нужно отправлять на адреса, заданные после символа ‘@’.
Для нужд резервирования, один и тот же лог можно и отправлять на сервер и сохранять локально, например, следующие строки:
local7.* /var/log/example.log
local7.* @192.168.0.10:1024
указывают, что лог категории (канала) local7 всех уровней важности следует записывать в файл /var/log/example.log, а также отправлять на сервер по заданному IP-адресу и порту.
Для того, чтобы добавить имя хоста в syslog-сообщения, задайте соответствующее имя в файле /etc/hosts в следующей строке:
127.0.0.1 <имя хоста> localhost
Так же обратите внимание, что некоторые syslog-сообщения берут имя хоста из файла /etc/hostname.
Параметры, задаваемые командой logging в cisco-like консоли, позволяют настраивать адрес хоста, на который будут отправляться syslog-сообщения, относящиеся к vpn агенту. По умолчанию, vpn агент отправляет сообщения на адрес 127.0.0.1, где они обрабатываются rsyslog и записываются в файл /var/log/cspvpngate.log. Если в cisco-like консоли задать другой адрес хоста для отправки сообщений, то в таком случае они будут сразу отсылаться на указанный адрес, и не попадут в локальный файл /var/log/cspvpngate.log.
Утилиты snmptrap и snmpinform на шлюзе отвечают за отправку SNMP-трапов. Шаблон команды для отправки трап сообщения из linux консоли может быть следующим:
snmptrap -v <версия SNMP> -c <community-строка> <IP-адрес сервера>:<порт> <uptime> <OID> <object/OID> <тип переменной> <значение>
Значение параметра uptime задавать необязательно и можно заменить пустыми кавычками – “” или ‘’. Примеры отправки тестового SNMPv2-трапа с использованием кастомного OID:
root@GW1:~# snmptrap -v 2c -c public 10.0.0.1:1162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 s "Test message"
root@GW1:~# snmpinform -v 2c -c public 10.0.101.148:162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 i 1234
Отправка SNMPv3 трапов требует указания дополнительных параметров аутентификации. Пример отправки SNMPv3 трапа:
root@GW1:~# snmpinform -v 3 -l authpriv -u User -a MD5 -x DES -A "UserPassword" -X "UserSecret" 10.0.0.1:162 '' .1.3.6.1.4.1.31342.1.2 .1.3.6.1.4.1.31342.1.2 s "Test message v3"
Настройка конфигурационных файлов в данном сценарии не рассматривается.
Если у Вас устройство «С-Терра Шлюз» без SPDS, то до полного выполнения всех шагов инструкции не перезагружайте устройство. Будьте внимательны, инструкция ниже актуальна только для шлюзов класса КС1 и КС2 (см. значение параметров PLATFORM и CLASS в файле /etc/image_version).
Для отправки электронной почты можно воспользоваться утилитой msmtp. По умолчанию она в системе не установлена. Скачать архив со всеми требуемыми к установке пакетами можно в личном кабинете партнера https://www.s-terra.ru/auth/.
1. Установить пакеты можно следующим образом (вместо ‘x’ должны быть указаны версии пакетов из архива):
root@GW1:~# dpkg -i libntlm0_x.x-x_amd64.deb
root@GW1:~# dpkg -i libgsasl7_x.x.x-x_amd64.deb
root@GW1:~# dpkg -i msmtp_x.x.x-x_amd64.deb
2. Если у Вас «С-Терра Шлюз» без SPDS, то перед перезагрузкой устройства необходимо осуществить пересчёт хэш-сумм:
root@GW1:~# /opt/VPNagent/bin/links_verify.sh update
Для того чтобы использовать msmtp для отправки сообщений следует указать SMTP сервер, который их будет перенаправлять. Настройки для подключения к такому серверу следует указать в файле конфигураций $HOME/.msmtprc (где $HOME – домашняя директория пользователя которым будет отправляться почта). Если такой файл отсутствует, создайте его и введите требуемые настройки. Подробнее о настройках msmtp можно узнать здесь: https://marlam.de/msmtp/documentation/
Создадим файл /root/.msmtprc и добавим в него нужные настройки.
Ниже указаны настройки для SMTP сервера yandex.ru:
Оптимальная работа при данных настройках не гарантируется. Отсылаемые письма могут быть заблокированы yandex.ru как спам. Для отправления писем рекомендуется использовать собственный SMTP сервер.
# Default values
defaults
auth on
port 587
tls on
tls_certcheck off
# Yandex account
account yandex
host smtp.yandex.ru
from <имя пользователя>@yandex.ru
user <имя_пользователя>@yandex.ru
password <пароль_пользователя>
# What account will be used if 'msmtp' is used without '-a' option
account default : yandex
где
defaults – указывает на то, что дальше будут писаться значения по умолчанию;
· auth on – указывает на то, что метод аутентификации будет выбран автоматически;
· port 587 – говорит о том, что для соединения с SMTP сервером будет использован указанный порт (587);
· tls on – соединения будут защищаться при помощи TLS;
· tls_certcheck off – отключает проверку сертификата сервера;
account yandex – указывает на то, что дальше будут писаться значения для аккаунта с названием ‘yandex’ (можно указать любое название);
· host smtp.yandex.ru – указывает на то, что письма связанные с аккаунтом будут отсылаться на SMTP сервер с указанным названием (smtp.yandex.ru);
· from <имя_пользователя>@yandex.ru – устанавливает обратный адрес (на этот адрес будут отправляться уведомления в случае если письмо не удалось доставить);
· user <имя_пользователя>@yandex.ru – задает имя аутентифицируемого пользователя;
· password <пароль_пользователя> – здесь требуется указать пароль пользователя;
account default : yandex – указывает на то, что по умолчанию утилитой будут использоваться настройки, указанные в account Yandex.
После указания настроек можно отправлять письма. Для этого можно использовать файлы следующего содержания:
To: <адрес_получателя>
From: <имя пользователя>@yandex.ru
Subject: <тема_письма>
[текст_письма]
Обратите внимание, что обязательно должна присутствовать пустая строка между ‘Subject’ и текстом письма, в противном случае текст письма будет утерян.
Отправить письмо можно следующей командой:
root@GW1:~# cat <имя_файла> | msmtp <адрес_получателя>