Введение

Добрый день дорогие читатели, в этой статье я хочу рассмотреть однин из основных способов логирования событий в cisco – syslog. Так же помимо него рассмотрим snmp traps, попробуем настроить "красивый" сбор логов на сервере linux. Журналирование syslog’а в cisco довольно старая и неудобная вещь, о чем пишут многие кто с ней работает. Различные недочеты и что с ними связно в этой статье рассматриваться не будут, только минимальные функции по настройке сервера и сетевых устройств.

Теория

Начнём с того, что все логирование происходит прямо у вас при настройке устройств, как пример при переходе из настройки конфигурации сетевого устройства в привилегированный режим у вас будет выведено сообщение на экран:

R1(config)#exit
R1#
May 10 22:25:56.133: %SYS-5-CONFIG_I: Configured from console by console

Этот способ называется console logging и он включен автоматом на сетевых устройствах cisco. Так же включен и buffered logging, который собирает все лог-сообщения в оперативную память, для их просмотра достаточно ввести команду “show logging”. Но не будем о простом логировании, наша главная задача рассмотреть основной способ для передачи сообщений на сторонний сервер или устройство, для этих мер подходит syslog и SNMP traps.

Syslog

При использовании syslog, необходимо понимать, что мы хотим передавать, для этого нам потребуется “Cisco Severity and Escalation Guidelines”, в котором расписан каждый уровень severity (серьезности) сообщений:

  1. Alerts - Необходимо срочное вмешательство

  2. Critical - Критические события

  3. Errors - Сообщения об ошибках в работе маршрутизатора

  4. Warning - Всевозможные предупреждения

  5. Notifications - Различные важные уведомления

  6. Informational - Информационные сообщения

  7. Debugging - Отладочные сообщения

Для наглядности в тестовом стенде будет использоваться 7 и 5 уровень серьезности сообщений.

Так же, для удобства будем использовать протокол NTP, чтобы синхронизировать время отправки лог-сообщений между маршрутизаторами.

Во время приходящих сообщений на сервер syslog, он руководствуется специальными правилами и категориями для записи и сортировки в определенный файл. Стандартные категории syslog включают в себя: User - сообщения генерируемые процессами пользователя, Kern - сообщения генерируемые ядром, Mail - сообщения от почтовой системы, Daemon - сообщения генерируемые системными демонами, Auth - сообщения связанные с авторизацией пользователей, LPR - сообщения от системы печати, News - сообщения от сервера новостей, UUCP - зарезервировано за системой UUCP, Cron - сообщения полученные от cron.

Далее следуют так называемые “локали” или же категории (Local0 – Local7), зарезервированные для использования администратором системы.

SNMP

SNMP - используется для чтения/чтения и изменения данных с сетевых устройств, существует 4 версии: 1, 2, v2c, 3. Главное различие между версиями это безопасность. Начиная с 3 версии, snmp претерпел сильные изменения и даже его пакет выглядит иначе, чем на более ранних версиях. Подробнее можно прочитать на любой википедии.

SNMP traps - ловушка, которую устройство Cisco будет посылать на сторонний сервер SNMP сообщением для сбора событий происходящих на сетевом устройстве.

Практическая часть

Syslog

Наш тестовый стенд будет построен в GNS3 и состоять из: linux сервера, коммутатора и двух маршрутизаторов cisco. Прежде всего настроим NTP сервер для синхронизации времени между маршрутизатором и двумя коммутаторами. За отправное звено, или же за наш ntp сервер возьмем R1, укажем “stratum 1” для отправной точки синхронизации с остальными устройствами:

R1(config)#ntp master 1

Далее на всех остальных устройствах укажем NTP сервер:

R2(config)#ntp server 11.10.10.1

т.к алгоритм у протокола NTP не быстрый, то ждать синхронизации времени между сетевыми устройствами придется какое-то время. Для отслеживания состояния потребуется команда:

R2#show ntp associations
  address         ref clock       st   when   poll reach  delay  offset   disp
 ~11.10.10.1      .LOCL.           1     39     64     0  0.000   0.000 15937.
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Здесь NTP еще только синхронизируется, когда будет *~ ip address, то это будет означать полную синхронизацию между устройствами. Для отправки логов на наш сервер воспользуемся командой:

R1(config)#logging trap debugging
R1(config)#logging host 10.10.10.50 transport udp port 514
R1(config)#logging origin-id hostname

В данном случае мы перенаправляем все log сообщения на адрес нашего сервера, а также указываем порт – udp 514. Такие же команды мы введем на S1 и R2 разумеется, укажем статический маршрут в сторону нашей основной сети.

После успешного соединения с сервером сетевое устройство выведет уведомление:

*May 10 09:32:23.147: %SYS-6-LOGGINGHOST_STARTSTOP: Logging to host 10.10.10.50 port 514 started - CLI initiated

Далее переходим на наш linux сервер, в нем нам необходимо настроить сбор логов. Для успешной передачи udp, tcp пакета на linux сервере нам необходимо изменить rsyslog.conf, а именно убрать комментарии у четырех строк:

# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port ="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port ="514")

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

$template dynFile, "/var/log/%HOSTNAME%/syslog.log"
*.*                                        ?dynFile

После перезапуска демона rsyslog.service у нас создаются отдельные директории с названием ip адреса сетевого устройства и файла. А именно:

На данном этапе настройка простого syslog сервера закончилась.

SNMP TRAPS

В тестовом стенде, который будет точно такой же, как и при настройке syslog, приведена в пример 3 версия snmp traps. В чем ее различие между всеми остальными?

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

  • noAuthnoPriv - пароли передаются в открытом виде;

  • AuthnoPriv - проходит аутентификация, осуществляется с помощью алгоритмов криптографии;

  • AuthPriv - поддержка аутентификации и шифрования.

Как и говорилось выше, есть множество стандартных профилей, для того чтобы узнать какие из них есть и какая вам больше подходит используйте "show snmp view"

Теперь перейдем к настройке сетевых устройств, нам нужно включить сам snmp сервер и создать access-list, не забыв указать пароль, в режиме ro или rw в зависимости от ваших нужд.

R1(config)#access-list 1 permit host 10.10.10.50
R1(config)#snmp-server community cisco ro 1
R1(config)#snmp-server enable traps snmp

Стоит заметить, что snmp traps более гибок в настройке чем syslog, при включении можно указать в каком режиме эти сообщения будут подаваться:

R1(config)#snmp-server enable traps snmp authentication ?
  coldstart  Enable coldStart trap
  linkdown   Enable linkDown trap
  linkup     Enable linkUp trap
  warmstart  Enable warmStart trap

Выше была приведена настройка snmp сервера 2 версии, в дальнейшей настройки эти команды не потребуются, но для понимания работы snmp-server советую для начала поработать с v2c версией.

Следующим шагом нам нужно создать свой профиль, в который мы передаём или исключаем из него какие-то датчики. Так же создадим группу и передадим туда наш профиль:

R1(config)#snmp-server view EXAMPLE 1.3.6.1.4.1.9.2.1.56.0 included
R1(config)#snmp-server view EXAMPLE 1.3.6.1.2.1.2.2.1.8.0 included
R1(config)#snmp-server view EXAMPLE 1.3.6.1.2.1.1.3.0 included
R1(config)#snmp-server group EX v3 auth read EXAMPLE

Для тестового стенда я решил использовать стандартный профиль v1default, но никто не запрещает использовать вам свою группу, описанную выше, главное записать или исключить нужные датчики.

После создаём пользователя admin с шифрованием sha и паролем cisco123:

R1(config)#snmp-server user admin EX v3 auth sha cisco
R1(config)#snmp-server host 10.10.10.50 version 3 auth admin

Для проверки работоспособности советую воспользоваться snmpget на нашем linux сервере:

snmpget -u admin -l authNoPriv -a SHA -A cisco123 10.10.10.1 1.3.6.1.2.1.1.3.0
iso.3.6.1.2.1.1.3.0 = Timesticks: (71632) 0:11:56.32

Теперь переходим к настройке linux сервера, а именно изменим файл конфигурации snmp.conf расскоментируя одну строку “mibs :”

Далее нам нужно установить snmpd, snmptrap, snmptt. В snmpd нужно зайти в конфигурационный и изменить две строки, вместо локального подключения к демону разрешить любое подключение по 162 порту.

#agentaddress 127.0.0.1,[::1]
agentaddress udp:162, udp6:[::1]:162

Также необходима настройка и всех остальных утилит. Все они располагаются в директории "/etc/snmp/".

В snmptrapd.conf нам нужно создать пользователя и прописать traphandle:

authUser admin SHA cisco123
traphandle default snmptthandler

В snmptt.ini изменяем параметры:

mode = daemon
net_snmp_perl_enable = 1
unknown_trap_log_enable = 1

Теперь осталось только перезапустить snmpd и snmptt, чтобы применить изменения:

systemclt restart snmptrapd
systemclt restart snmptt

После отправки ловушки от сетевого устройства, наш сервер принимает пакет и записывает его в директорию /var/log/snmptt/

Для примера попробуем создать loopback 100 и выключить его:

R1(config)#int loopback 100
R1(config-if)#no shutdown
May 22 08:45:01.490: %LINK-3-UPDOWN: Interface Loopback100, changed state to up
May 22 08:45:02.489: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100  , changed state to up
R1(config-if)#shutdown
May 22 08:45:39.344: %LINK-5-CHANGED: Interface Loopback100, changed state to ad  ministratively down
May 22 08:45:40.344: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback100  , changed state to down

На нашем сервере появился файл snmptt.log, в котором записаны наши действия:

Mon May 10 04:41:45 2023 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link up on interface
6. Admin state: Loopback100. Operational state: 24
Mon May 10 04:41:57 2023 .1.3.6.1.6.3.1.1.5.4 Normal "Status Events" UNKNOWN - Link down on interface
6. Admin state: Loopback100. Operational state: 24

На этом настройка простого snmptraps сервера окончена!

Заключение

В данной статье я постарался максимально просто рассмотреть настройку логирования на сервере и сетевых устройствах компании cisco. Из приятного и полезного оставляю читателю ссылки на более подробные настройки этих способов логирования, а так же некоторые полезные команды: syslog, snmptraps, snmptrap, snmptraps v3, NTP.

В следующей статье рассмотрим более глубокую настройку логирования aaa accounting на сетевых устройствах cisco.

Комментарии (2)


  1. sirmax123
    28.05.2023 14:29
    +1

    Мир не ограничен rsyslog - можно хоть логстеш использовать

    ну и в целом настройки могут достаточно сильно зависить от устройства

    Я бы добавил что-то вроде
    service timestamps debug datetime msec
    service timestamps log datetime localtime show-timezone

    logging event link-status global
    logging event trunk-status global

    В
    А так описания мало что понятно
    R1(config)#logging trap debugging
    R1(config)#logging host 10.10.10.50 transport udp port 514 R1(config)#logging origin-id hostname

    В первой команде что означают параметры? Зачем она нужна? Какие есть варианты?
    Понятно что можно все это нагуглить, но так и все остальное что в статье написано за 5 минут можно нагуглить - если уж писать стстью то максимально подробно, для тех кто не делал - что бы было сразу понятно что он делает, и почему делает так а не иначе.


    1. sl1 Автор
      28.05.2023 14:29
      +1

      Спасибо за комментарий и указания, все таки первый раз такое пишу и ошибки совершаются. Насчет того что не расписал подробно про команды snmp - согласен, нужно было тщательнее проверять за собой весь свой написанный материал, при написании следующих статей учту этот момент.