Настройка snmp astra linux

Настройка SNMP в Linux

Simple Network Management Protocol — SNMP — это протокол интернет-стандарта для сбора и организации информации об управляемых устройствах в IP-сетях и для изменения этой информации для изменения поведения устройства. Устройства, которые поддерживают SNMP — модемы, маршрутизаторы, коммутаторы, серверы, рабочие станции, принтеры и т.д.

SNMP широко используется для сетевого мониторинга. SNMP предоставляет данные в виде переменных в управляемых системах, организованных в информационной базе управления (MIB), которые описывают состояние и конфигурацию системы. Затем эти переменные могут быть дистанционно запрошены (и, в некоторых случаях, изменены).

Разработаны и развернуты три значимые версии SNMP. SNMPv1 является исходной версией протокола. Более свежие версии, SNMPv2c и SNMPv3, улучшают производительность, гибкость и безопасность.

Как настроить snmp в Linux?

1. Устанавливаем нужные утилиты для CentOS:

2. Продублируем на всякий случай файл настроек:

3. Редактируем файл /etc/snmp/snmpd.conf. Добавим или отредактируем:

# доступ по snmp будет только с адреса 192.168.1.1 rocommunity public 192.168.1.1 # отключаем логирование в системном журнале dontLogTCPWrappersConnects yes

4. Разрешаем доступ через фаерволл для службы snmp с определенного ip:

# iptables -A INPUT -p tcp -s 192.168.1.1 —dport 161 -j ACCEPT
# iptables -A INPUT -p udp -s 192.168.1.1 —dport 162 -j ACCEPT
# iptables-save > /etc/sysconfig/iptables

# iptables -I INPUT -p udp -m udp —dport 161 -j ACCEPT
# iptables -I INPUT -p udp -m udp —dport 162 -j ACCEPT
# iptables-save > /etc/sysconfig/iptables

5. Перезапускаем службу snmp:

Published by MishLen

One Reply to “Настройка SNMP в Linux”

Интересное видео. Скажите пожалуйста у меня есть Ipon сервер, с NMC SNMP адаптером — ip адаптеру настроил вэбморду вижу SNMP настройки вижу, есть диск даже где лежат 4 файла для SPS-CUI-1.5.0.2-linux-x86_x64 с именами SPS.install, SPS.remove, SPS.ss, SPS.sw. Есть папка даже с MIB файлами EPPC.MIB и RFC1628.MIB. У меня система линукс стоит, работаю через терминал. Как тут можно настроить так чтоб сервер опрашивал ИБП и когда надо выключался, Производитель ИБП IPPON. Я на сервер поставил snmp и snmpd, а что дальше делать не пойму, как то надо все эти файлы что есть собрать в кучу и запустить….
мне нужно просто чтоб сервер выключался когда у батареи мало заряда….

Добавить комментарий Отменить ответ

Рубрики

• FreeBSD (33)
  • Консольные команды в FreeBSD (2)
  • Настройка веб-сервера (1)
  • ПО (FreeBSD) (13)
  • Полезные команды (2)
  • Сеть (FreeBSD) (2)
  • Система (FreeBSD) (11)
  • Управление (2)
  • Веб-сервер (5)
  • Консольные команды в Linux (7)
  • ПО (Linux) (14)
  • Прочее (6)
  • Сеть (Linux) (1)
  • Система (Linux) (18)
  • Microsoft Exchange (19)
  • Powershell (24)
  • SCCM (1)
  • Server 2008 R2 (14)
  • Server 2012 R2 (11)
  • SQL Server (1)
  • Разное (Windows) (18)
  • Резервное копирование (1)
  • Hyper-V (3)
  • VMware (9)

  Свежие записи

  Источник

  Краткое руководство как готовить SNMPv3

  Настройка v3-пользователя на агенте сервера для штатного линуксового snmpd (пакет net-snmp ). Out of scope: snmp traps и пользователи с правом запиcи (rw).

  

  Третья версия протокола позволяет передавать пакеты в зашифрованном виде, что даёт возможность безопасно передавать телеметрию через публичные сети без риска раскрытия как аутентификационной информации (аналог community), так и шифруя сам поток данных симметричным алгоритмом с общим ключём.

  Напоминалка как настраивается v1/v2c

  В версиях v1 / v2c использовалось понятие community . Это что-то типа парольной фразы, которую агент получает от клиента. При совпадении community с настройками доступа (например, IP-адресом клиента из разрешённого диапазона), агент отдаёт телеметрию. Всё передаётся открытым методом, как сам community , так и запрашиваемая телеметрия.

  В tcpdump запросы выглядят так (community comminity_name ):

  tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 20:28:09.382435 IP (tos 0x48, ttl 44, id 25108, offset 0, flags [DF], proto UDP (17), length 74) 192.158.1.38.46214 > 198.51.100.1.161: < SNMPv2c C="comminity_name" < GetNextRequest(25) R=1193096294 .1.3.6.1.2.1 >> 20:28:09.414940 IP (tos 0x48, ttl 44, id 25112, offset 0, flags [DF], proto UDP (17), length 77) 192.158.1.38.46214 > 198.51.100.1.161: < SNMPv2c C="comminity_name" < GetNextRequest(28) R=1193096295 .1.3.6.1.2.1.1.1.0 >> 20:28:09.447385 IP (tos 0x48, ttl 44, id 25117, offset 0, flags [DF], proto UDP (17), length 77) 192.158.1.38.46214 > 198.51.100.1.161: < SNMPv2c C="comminity_name" < GetNextRequest(28) R=1193096296 .1.3.6.1.2.1.1.2.0 >> 20:28:09.479880 IP (tos 0x48, ttl 44, id 25125, offset 0, flags [DF], proto UDP (17), length 77) 192.158.1.38.46214 > 198.51.100.1.161: < SNMPv2c C="comminity_name" < GetNextRequest(28) R=1193096297 .1.3.6.1.2.1.1.3.0 >> 20:28:09.512357 IP (tos 0x48, ttl 44, id 25128, offset 0, flags [DF], proto UDP (17), length 77) . 

  NB! В tcpdump здесь и дальше только запросы, ответов нет.

  Настройка v2 community производится добавлением строки в файле /etc/snmp/snmpd.conf , со следующим синтаксисом:

  rocommunity[6] communityname [access] [-V view]

  • 6 (опционально) — признак ipv6 (он традиционно отдельно от ipv4)
  • communityname — название community , фактически общий пароль
  • access (опционально) — опциональные настройки доступа клиента, варианты: default , hostname , network/bits
  • -V view (опционально) — действующее ограничение по видимости древа oid для данного community, настраивается отдельно, out of scope

  rocommunity comminity_name rocommunity6 comminity_name

  Тут настроено одно community comminity_name только для чтения для обоих версий протокола IP без дополнительных настроек ограничения.

  Этого достаточно для понимания.

  Аутентификация в SNMPv3

  В версии v3 отказались от понятия community . Ну, как отказались, переработали, но термин такой исключён. Появилось шифрование потока и аутентификационной информации. Что взамен?

  То есть, против типичной схемы пары «логин/пароль» появилась не очень очевидная «логин/два пароля», что изначально вводит в ступор. Для каждого из паролей ещё надо задать алгоритм, с которым они будут использоваться:

  • пароль для аутентификации — нужно указать алгоритм хэширования, традиционно MD5 или SHA, в более поздних версиях появились вариации SHA
  • пароль для шифрования — нужно указать алгоритм симметричного шифрования, традиционно DES или AES, в более поздних версиях появились вариации AES

  В tcpdump запросы по версии v3 выглядит примерно так:

  tcpdump: listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 23:28:39.753314 IP (tos 0x48, ttl 44, id 62294, offset 0, flags [DF], proto UDP (17), length 92) 192.158.1.38.48116 > 198.51.100.1.161: < SNMPv3 < F=r > < USM B=0 T=0 U="" > < ScopedPDU E= C="" < GetRequest(14) R=30306933 >> > 23:28:39.785927 IP (tos 0x48, ttl 44, id 62301, offset 0, flags [DF], proto UDP (17), length 171) 192.158.1.38.48116 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=9 T=330 U="user_name" > < ScopedPDU [!scoped PDU]8f_6f_9f_0a_aa_3b_69_8c_02_30_66_48_52_7d_52_2b_9e_b0_a2_84_cc_60_8a_9e_d5_67_30_52_26_88_0e_68_a7_89_5d_df_78_a4_9b_4e_62_dc_f6_54_f8_16_00_02_ba_f7>> 23:28:39.818831 IP (tos 0x48, ttl 44, id 62308, offset 0, flags [DF], proto UDP (17), length 174) 192.158.1.38.48116 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=9 T=330 U="user_name" > < ScopedPDU [!scoped PDU]f1_46_7e_ec_3a_d4_38_94_69_38_14_73_20_71_de_1a_24_b2_61_56_d9_a2_c3_20_b2_6b_6e_11_5f_23_25_f7_56_ba_09_df_09_82_79_54_ec_22_7a_f5_81_60_52_59_83_65_40_09_ac>> 23:28:39.851664 IP (tos 0x48, ttl 44, id 62310, offset 0, flags [DF], proto UDP (17), length 174) 192.158.1.38.48116 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=9 T=330 U="user_name" > < ScopedPDU [!scoped PDU]43_30_e9_c9_7c_e2_07_9e_41_74_53_98_51_79_ff_7b_26_51_93_b2_fe_35_db_8e_a4_67_58_87_3e_de_8c_f6_5a_3e_1d_a4_47_d7_3d_f9_c8_b1_ac_2f_d2_48_3a_57_d0_f4_a8_45_9c>> 23:28:39.884478 IP (tos 0x48, ttl 44, id 62316, offset 0, flags [DF], proto UDP (17), length 174) 192.158.1.38.48116 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=9 T=330 U="user_name" > < ScopedPDU [!scoped PDU]a0_35_d4_83_cb_6a_82_f1_bd_d7_16_58_00_ff_d7_5e_03_3a_01_c8_be_2e_6d_e5_bf_eb_7c_ce_07_12_76_fc_ee_6e_61_dc_18_d3_4b_7e_dd_f7_bc_f1_3e_de_ad_52_a2_2e_22_ea_74>> . 

  Можно обратить внимание, что имя пользователя не шифруется, надо это иметь в виду, чтобы ничего лишнего на этот счёт не раскрыть на транзите.

  Настройка производится чуть сложнее для понимания. Дело в том, что недостаточно закинуть в конфиг заранее подготовленную срочку (с некоторыми оговорками), так как аутентификационная информация генерируется в момент создания пользователя. Это, конечно, заметно осложняет деплой snmpd конфига с помощью типичных средств развёртывания, например, ansible.

  Суммарно, и агент и его клиент должны обладать общей информацией (помимо знания клиента о хосте агента):

  • имя пользователя
  • пароль для аутентификации (типовая cli-опция для net-snmp -a )
  • алгоритм аутентификации (типовая cli-опция для net-snmp -A )
  • пароль для шифрования (типовая cli-опция для net-snmp -x )
  • алгоритм шифрования (типовая cli-опция для net-snmp -X )

  Помимо уже названного конфига /etc/snmp/snmpd.conf , существует ещё по крайней мере два для динамического создания и хранения аутентификационной информации:

  Даемон snmpd формирует необходимые строчки при запуске, поэтому перед созданием юзера надо погасить процесс. Специальный встроенный скрипт сообщит, что процесс запущен и не даст создать пользователя без его остановки, так как при остановке процесса один из этих файлов перезатирается in-memory значениями.

  Создание пользователя на агенте производится командой (опции расписаны выше):

  net-snmp-create-v3-user -ro -a 'auth_pass' -A SHA -x 'priv_pass' -X AES user_name

  Так создаётся пользователь с именем user_name с паролем аутентификации auth_pass , алгоритмом аутентификации SHA , паролем шифрования priv_pass и алгоритмом шифрования AES . Технически по результату выполнения этого скрипта, добавляется по строке в два вышеназванных конфига:

  • в /var/lib/snmp/snmpd.conf строка createUser user_name SHA «auth_pass» AES «priv_pass»
  • в /usr/share/snmp/snmpd.conf строка rouser user_name

  Но это не всё. При запуске даемона snmpd происходит модификация файла /var/lib/snmp/snmpd.conf : все строчки с началом createUser исчезают и появляются уже рабочие строки вида:

  usmUser 1 3 0x80001f888052e226409c42d06300000000 "user_name" "user_name" NULL .1.3.6.1.6.3.10.1.1.3 0x018a3bb9c17caafed74347e50d918963e37e70d7 .1.3.6.1.6.3.10.1.2.4 0xcfdecd0e1bc6bf08eb7ae90e68bdb414 ""

  Файл /usr/share/snmp/snmpd.conf остаётся нетронутым. В дальнейшем возможно манипулировать аутентификационной информацией в строке usmUser с помощью cli-утилиты snmpusm (см. man).

  SNMPv3 security level

  Пару слов на счёт уровня безопасности v3. Традиционно выглядит как:

  • noAuthNoPriv — передавать данные без аутентификации и шифрования
  • authNoPriv — передавать данные с успешной аутентификацией, но не шифруя их
  • authPriv — передавать данные с успешной аутентификацией и с использованием шифрования

  Первый из них — малополезная экзотика, остановимся на остальных двух authNoPriv и authPriv .

  Нагляднее будет показать пару строк tcpdump. Вот так выглядит обмен для authNoPriv :

  10:50:58.534839 IP (tos 0x48, ttl 44, id 54935, offset 0, flags [DF], proto UDP (17), length 92) 192.158.1.38.20723 > 198.51.100.1.161: < SNMPv3 < F=r > < USM B=0 T=0 U="" > < ScopedPDU E= C="" < GetRequest(14) R=1808634162 >> > 10:50:58.567563 IP (tos 0x48, ttl 44, id 54937, offset 0, flags [DF], proto UDP (17), length 162) 192.158.1.38.20723 > 198.51.100.1.161: < SNMPv3 < F=ar > < USM B=10 T=39805 U="user_name" > < ScopedPDU E=_80_00_1f_88_80_52_e2_26_40_9c_42_d0_63_00_00_00_00 C="" < GetNextRequest(25) R=1808634161 .1.3.6.1.2.1 >> > 10:50:58.600457 IP (tos 0x48, ttl 44, id 54945, offset 0, flags [DF], proto UDP (17), length 165) 192.158.1.38.20723 > 198.51.100.1.161: < SNMPv3 < F=ar > < USM B=10 T=39805 U="user_name" > < ScopedPDU E=_80_00_1f_88_80_52_e2_26_40_9c_42_d0_63_00_00_00_00 C="" < GetNextRequest(28) R=1808634163 .1.3.6.1.2.1.1.1.0 >> > . 

  10:51:47.463848 IP (tos 0x48, ttl 44, id 61280, offset 0, flags [DF], proto UDP (17), length 92) 192.158.1.38.54277 > 198.51.100.1.161: < SNMPv3 < F=r > < USM B=0 T=0 U="" > < ScopedPDU E= C="" < GetRequest(14) R=1901099838 >> > 10:51:47.496541 IP (tos 0x48, ttl 44, id 61282, offset 0, flags [DF], proto UDP (17), length 172) 192.158.1.38.54277 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=10 T=39854 U="user_name" > < ScopedPDU [!scoped PDU]f2_87_ea_15_87_25_a7_b8_44_b4_38_62_15_86_d4_4e_1a_99_34_9e_6c_4d_6a_39_ea_1c_d7_1c_6e_f6_1f_76_c0_e2_ba_91_4d_8e_d5_9c_e7_06_29_c1_47_6e_a2_9a_2b_5c>> 10:51:47.529402 IP (tos 0x48, ttl 44, id 61290, offset 0, flags [DF], proto UDP (17), length 175) 192.158.1.38.54277 > 198.51.100.1.161: < SNMPv3 < F=apr > < USM B=10 T=39854 U="user_name" > < ScopedPDU [!scoped PDU]da_e4_d6_48_f1_ea_28_7f_bf_ce_d6_e0_ef_f7_95_06_0c_d7_79_7c_f1_4b_78_75_4f_1a_e2_00_a6_83_d5_e6_c2_82_55_0f_09_a4_7d_f1_e1_f2_a0_64_d3_c3_d7_13_c3_ae_95_8b_db>> . 

  В принципе, видно, что в первом случае только часть информации шифруется (например, аутентификационная), при этом можно перехватить список запрашиваемых OID. Во втором случае вся информация остаётся зашифрованной, немного увеличив размер пакета. Наверное, где-то там на шифрование ещё утилизируется больше вычислительных мощностей, но не думаю что существенно много для нашего времени, так как используется довольно быстрое симметричное шифрование с общим ключём.

  Настройка клиента

  Традиционно, проверяется, работает ли snmp вообще с помощью встроенной утилиты snmpwalk. Вот так можно проверить работу клиента v2c (с community ):

  snmpwalk -v 2c -c communityname hostname

  Вот так можно проверить работу клиента v3 (с шифрованием authPriv ):

  snmpwalk -v 3 -a SHA -A auth_pass -x AES -X priv_pass -l authPriv -u user_name hostname

  • SHA — алгоритм аутентификации
  • auth_pass — пароль для аутентификации
  • AES — алгоритм шифрования
  • priv_pass — пароль для шифрования
  • authPriv — уровень безопасности «с аутентификацией и шифрованием»
  • user_name — имя пользователя
  • hostname — имя хоста агента

  Если всё так работает, осталось заполнить аналогичные строки в софте мониторинга:

  

  Если что-то не работает, посмотреть в правила фаерволла на обоих концах и попробовать «поволкать» с хоста системы мониторинга, посмотреть в tcpdump, попробовать как работает клиент с локалхоста агента как по внешнему IP-адресу, так и по loopback адресу, например, 127.0.0.1 или ::1 .

  Источник

  Читайте также:  Admin password kali linux