Syslog client в роутере что это

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

В данной статье, я расскажу вам, как организовать передачу лога на компьютер на примере своего роутера D-Link DSL-2540U и бесплатного Syslog-сервера Ipswitch Syslog Server 1.0.0.59.

Для начала проверьте –

поддерживает ли ваш роутер передачу лога по протоколу Syslog.
Для этого зайдите в веб-интерфейс роутера. В настройках, ищите: какие либо намёки на способ ведения лога: «локально», «удалённо» или «Локально + удалённо» (нас интересуют именно 2 последних варианта). Так же, намёком на наличие функции удалённого ведения лога, будет присутствие настройки адреса сервера и номера порта.

Вот так это выглядит в

настройках моего роутера:

Теперь подробнее о настройках, которые изображены на скриншоте:

Mode = Remote – лог в режиме записи на удалённый сервер (то есть не в память роутера а куда то ещё).
Server IP address = 192.168.1.2 – отправлять лог на адрес 192.168.1.2 (это адрес компьютера в моей локальной сети, на который установлена программа Syslog-сервер)
Server UDP Port = 514 – указание номера UDP-порта компьютера, на который будет отправляться лог.

Если подобных настроек найти не удаётся, значит, скорее всего, ваше устройство не поддерживает удалённого ведения лога. Если же вы нашли у себя подобные настройки, то укажите в них необходимые данные.

В качестве

IP-адреса сервера указывается адрес ПК, который должен принимать лог. Если адрес компьютеру назначался автоматически, задайте его вручную и введите в настройки лога роутера именно этот адрес, иначе при следующем запуске, компьютеру будет назначен новый IP и передача лога прекратится.
В качестве порта, для приёма лога по протоколу syslog принято использовать UDP-порт 514. Однако можно ввести и любой другой порт, так или иначе впоследствии может оказаться, что он занят, и потребуется либо освободить его от использующих приложений, либо выбрать другой порт, который будет свободен.
Режим лога следует выбирать исходя из ваших потребностей. Если нужно чтобы лог не хранился на роутере, а просто отправлялся на удалённый ПК – выбирайте режим “Remote”, если же нужно хранить лог и на роутере и на удалённом ПК используйте режим “Both”.

Когда роутер будет настроен, можно перейти к

установке Syslog-сервера.

Я воспользовался бесплатным решением Ipswitch Syslog Server 1.0.0.59. Выбор пал на него чисто случайно (просто он первый в списке был) тем не менее, он оказался удачным. Имеет приятный оконный интерфейс, достаточное количество настроек и не склонен к частым падениям

(бесперебойно работает уже неделю). Из минусов могу выделить лишь то, что при перезапуске не отображает лог, предшествующий перезапуску, но это касается

только отображения

, сам лог всё равно непрерывно пишется в

текстовый документ

.
Скачать программу можно с официального сайта Для этого необходимо заполнить все поля в правой части страницы и нажать кнопку Download.

Из всех полей самое важное – это поле

«Email Address» потому что на этот адрес будет отправлено сообщение с ссылкой на скачивание файла.

После установки приложения запустите его и зайдите в

настройки, нажав на кнопку “Options” в левом верхнем углу окна. Перейдите на вкладку Listeners и убедитесь, что галочка UDP Listener установлена. В опции “Bind to this interface and port” выберите пункт “All assigned”, и укажите в поле справа номер UDP порта, который вы указали при настройке роутера. (Если ваш роутер настроен на отправку лога на TCP-порт, то проделайте всё то же самое для аналогичной опции ниже “TCP Listener”)

Обычно этого должно быть достаточно, чтобы установленный вами Syslog-сервер начал принимать записи журнала роутера. О правильной работоспособности будет свидетельствовать появление записей в таблице “Current”, занимающей основную часть окна приложения. Сообщений может не быть по причине, что роутер их не формирует. Самый верный

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

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

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

Для проверки состояния активных портов существует множество удобных утилит,

(например TCPViev), но если не хотите из за такой мелочи искать их, то можно воспользоваться встроенной в Windows утилитой netstat. Просто наберите в командной строке:

На экран будет выведена таблица со списком всех активных в данный момент TCP и UDP портов. Отображение данных может отличаться в зависимости от версии вашей утилиты. У меня это выглядит вот так:

Нас интересует столбец

«локальный адрес», вернее та его часть что находится справа от двоеточия. Это и есть номера открытых портов. Ищите среди них порт который вы указали в настройках роутера и Syslog-сервера (TCP или UDP в зависимости от того что вы использовали). Для того чтобы узнать какое приложение использует этот порт посмотрите на значение в столбце “PID” – это идентификатор процесса. Выяснить как называется процесс поможет диспетчер задач. Откройте его, перейдите на вкладку «Процессы» и в меню «Вид» главного меню выберите пункт «Выбрать столбцы». Поставьте галочку напротив пункта «ИД процесса (PID)», теперь отсортировав процессы по столбцу PID можно без труда найти процесс с соответствующим PID-ом, (если он всё ещё запущен), а кликнув по нему правой кнопкой и выбрав «Место хранения файла» в большинстве случаев можно понять – что за приложение запустило этот процесс.
Найдите все процессы использующие этот порт, и избавьтесь от них, если это возможно, либо перенастройте для использования другого порта, а иногда проще просто выбрать в настройках лога роутера и в Syslog-сервере другой порт, который не занимается ни чем важным. (Только учитывайте при этом, что сам процесс Syslog сервера тоже будет в списке процессов, использующих порт, и от него избавляться не надо)

Table Of Contents

System Message Logging

Understanding System Message Logging

Configuring System Message Logging

System Log Message Format

Default System Message Logging Configuration

Disabling and Enabling Message Logging

Setting the Message Display Destination Device

Enabling and Disabling Time Stamps on Log Messages

Enabling and Disabling Sequence Numbers in Log Messages

Defining the Message Severity Level

Limiting Syslog Messages Sent to the History Table and to SNMP

Setting a Logging Rate Limit

Configuring UNIX Syslog Servers

Logging Messages to a UNIX Syslog Daemon

Configuring the UNIX System Logging Facility

Displaying the Logging Configuration

System Message Logging

This module describes how to configure system message logging on your wireless device in the following sections:

•Understanding System Message Logging

•Configuring System Message Logging

•Displaying the Logging Configuration

Note For complete syntax and usage information for the commands used in this chapter, refer to the Cisco IOS Configuration Fundamentals Command Reference for Release 12.4.

Understanding System Message Logging

By default, wireless devices send the output from system messages and debug privileged EXEC commands to a logging process. The logging process controls the distribution of logging messages to various destinations, such as the logging buffer, terminal lines, or a UNIX syslog server, depending on your configuration. The process also sends messages to the console.

Note The syslog format is compatible with 4.3 BSD UNIX.

When the logging process is disabled, messages are sent only to the console. The messages are sent as they are generated, so message and debug output are interspersed with prompts or output from other commands. Messages are displayed on the console after the process that generated them has finished.

You can set the severity level of the messages to control the type of messages displayed on the console and each of the destinations. You can timestamp log messages or set the syslog source address to enhance real-time debugging and management.

You can access logged system messages by using the access point command-line interface (CLI) or by saving them to a properly configured syslog server. The access point software saves syslog messages in an internal buffer. You can remotely monitor system messages by accessing the access point through Telnet or by viewing the logs on a syslog server.

Configuring System Message Logging

This section describes how to configure system message logging in the following sections:

•System Log Message Format

•Default System Message Logging Configuration

•Disabling and Enabling Message Logging

•Setting the Message Display Destination Device

•Enabling and Disabling Time Stamps on Log Messages

•Enabling and Disabling Sequence Numbers in Log Messages

•Defining the Message Severity Level

•Limiting Syslog Messages Sent to the History Table and to SNMP

•Setting a Logging Rate Limit

•Configuring UNIX Syslog Servers

System Log Message Format

System log messages can contain up to 80 characters and a percent sign (%), which follows the optional sequence number or timestamp information, if configured. Messages are displayed in this format:

seq no:timestamp: %facility-severity-MNEMONIC:description

The part of the message preceding the percent sign depends on the setting of the service sequence-numbers, service timestamps log datetime, service timestamps log datetime [localtime] [msec] [show-timezone], or service timestamps log uptime global configuration command.

Table 1 describes the elements of syslog messages.

The following example shows a partial access point system message:

00:00:46: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up

00:00:47: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up

00:00:47: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up

00:00:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down

00:00:48: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed 
state to down 2

*Mar  1 18:46:11: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)

18:47:02: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)

*Mar  1 18:48:50.483 UTC: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36) 

Default System Message Logging Configuration

Table 2 shows the default system message logging configuration.

Disabling and Enabling Message Logging

Message logging is enabled by default. It must be enabled to send messages to any destination other than the console. When enabled, log messages are sent to a logging process, which logs messages to designated locations asynchronously to the processes that generated the messages.

To disable message logging, follow these steps, beginning in privileged EXEC mode:

Disabling the logging process can slow down the access point because a process must wait until the messages are written to the console before continuing. When the logging process is disabled, messages are displayed on the console as soon as they are produced, often appearing in the middle of command output.

The logging synchronous global configuration command also affects the display of messages to the console. When this command is enabled, messages appear only after you press Return. For more information, see the «Enabling and Disabling Time Stamps on Log Messages» section.

To reenable message logging after it has been disabled, use the logging on global configuration command.

Setting the Message Display Destination Device

If message logging is enabled, you can send messages to specific locations in addition to the console. To specify the locations that receive messages, use one or more of the following commands, beginning in privileged EXEC mode:

The logging buffered global configuration command copies logging messages to an internal buffer. The buffer is circular, so newer messages overwrite older messages after the buffer is full. To display the messages that are logged in the buffer, use the show logging command, in privileged EXEC mode. The first message displayed is the oldest message in the buffer. To clear the contents of the buffer, use the clear logging command, in privileged EXEC mode.

To disable logging to the console, use the no logging console command in global configuration mode. To disable logging to a file, use the no logging file [severity-level-number | type] command in global configuration mode.

Enabling and Disabling Time Stamps on Log Messages

By default, log messages are not time stamped.

To enable timestamping of log messages, follow these steps, beginning in privileged EXEC mode:

To disable timestamps for both debug and log messages, use the no service timestamps command in mode global configuration.

The following example shows part of a logging display with the service timestamps log datetime command enabled:

*Mar  1 18:46:11: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)

The follwoing example shows part of a logging display with the service timestamps log uptime command enabled:

00:00:46: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up

Enabling and Disabling Sequence Numbers in Log Messages

Because there is a chance that more than one log message can have the same timestamp, you can display messages with sequence numbers so that you can unambiguously refer to a single message. By default, sequence numbers in log messages are not displayed.

To enable sequence numbers in log messages, follow these steps, beginning in privileged EXEC mode:

To disable sequence numbers, use the no service sequence-numbers global configuration command.

The follwoing example shows part of a logging display with sequence numbers enabled:

000019: %SYS-5-CONFIG_I: Configured from console by vty2 (10.34.195.36)

Defining the Message Severity Level

You can limit messages that are displayed to the selected device by specifying the severity level of the message. Table 3 describes the severity level.

To define the message severity level, follow these steps, beginning in privileged EXEC mode:

Note Specifying a level causes messages at that level and numerically lower levels to be displayed at the destination.

To disable logging to the console, use the no logging console command in global configuration mode. To disable logging to a terminal other than the console, use the no logging monitor command in global configuration mode. To disable logging to syslog servers, use the no logging trap command in global configuration mode.

Table 3 describes the severity level keywords. It also lists the corresponding UNIX syslog definitions from the most severe level to the least severe level.

The software generates four other categories of messages:

•Error messages about software or hardware malfunctions, displayed at levels warnings through emergencies: these types of messages mean that the functionality of the access point is affected.

•Output from the debug commands, displayed at the debugging level: debug commands are typically used only by the Technical Assistance Center (TAC).

•Interface up or down transitions and system restart messages, displayed at the notifications level: this message is only for information; access point functionality is not affected.

•Reload requests and low-process stack messages, displayed at the informational level: this message is only for information; access point functionality is not affected.

Note Authentication request log messages are not logged on to a syslog server. This feature is not supported on Cisco Aironet access points.

Limiting Syslog Messages Sent to the History Table and to SNMP

If you have enabled syslog message traps to be sent to an SNMP network management station by using the snmp-server enable trap command, you can change the level of messages sent and stored in the access point history table. You can also change the number of messages that are stored in the history table.

Messages are stored in the history table because SNMP traps are not guaranteed to reach their destination. By default, one message of the level warning and numerically lower levels (see Table 3) are stored in the history table even if syslog traps are not enabled.

To change the level and history table size defaults, follow these steps, beginning in privileged EXEC mode:

When the history table is full (it contains the maximum number of message entries specified with the logging history size command in global configuration mode), the oldest message entry is deleted from the table to allow the new message entry to be stored.

To return the logging of syslog messages to the default level, use the no logging history command in global configuration mode. To return the number of messages in the history table to the default value, use the no logging history size command in global configuration mode.

Setting a Logging Rate Limit

You can set a limit on the number of messages that the access point logs per second. You can enable the limit for all messages or for messages sent to the console, and you can specify that messages of a specific severity are exempt from the limit.

To enable a logging rate limit, follow these steps, beginning in privileged EXEC mode:

To disable the rate limit, use the no logging rate-limit command in global configuration mode.

Configuring UNIX Syslog Servers

The next sections describe how to configure the 4.3 BSD UNIX server syslog daemon and define the UNIX system logging facility.

Logging Messages to a UNIX Syslog Daemon

Before you can send system log messages to a UNIX syslog server, you must configure the syslog daemon on a UNIX server. Log in as root, and perform these steps.

Note Some recent versions of UNIX syslog daemons no longer accept by default syslog packets from the network. If this is the case with your system, use the UNIX man syslogd command to determine what options must be added to or removed from the syslog command line to enable logging of remote syslog messages.

Step 1 Add a line such as the following to the file /etc/syslog.conf:

local7.debug /usr/adm/logs/cisco.log

The local7 keyword specifies the logging facility to be used; see Table 4 for information on the facilities. The debug keyword specifies the syslog level; see Table 3 for information on the severity levels. The syslog daemon sends messages at this level or at a greater severity level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.

Step 2 Create the log file by entering these commands at the UNIX shell prompt:

$ touch /usr/adm/log/cisco.log

$ chmod 666 /usr/adm/log/cisco.log

Step 3 Ensure the syslog daemon reads the new changes by entering this command:

$ kill -HUP `cat /etc/syslog.pid`

For more information, see the man syslog.conf and man syslogd commands on your UNIX system.

Configuring the UNIX System Logging Facility

When sending system log messages to an external device, you can cause the access point to identify its messages as originating from any of the UNIX syslog facilities.

To configure UNIX system facility message logging, follow these steps, beginning in privileged EXEC mode:

To remove a syslog server, use the no logging host command in global configuration mode, and specify the syslog server IP address. To disable logging to syslog servers, enter the no logging trap command in global configuration mode.

Table 4 lists the 4.3 BSD UNIX system facilities that the Cisco IOS software supports. For more information about these facilities, consult the operator’s manual for your UNIX operating system.

Displaying the Logging Configuration

To display the current logging configuration and the contents of the log buffer, use the show logging command in privileged EXEC mode. For information about the fields in this display, refer to the Cisco IOS Configuration Fundamentals Command Reference for Release 12.2.

To display the logging history file, use the show logging history command in privileged EXEC mode.

CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2009 Cisco Systems, Inc. All rights reserved.

Summary

RouterOS is capable of logging various system events and status information. Logs can be saved in routers memory (RAM), disk, file, sent by email or even sent to remote syslog server (RFC 3164).

Log messages

Sub-menu level: /log

All messages stored in routers local memory can be printed from /log menu. Each entry contains time and date when event occurred, topics that this message belongs to and message itself.

[admin@ZalaisKapots] /log> print 
jan/02/1970 02:00:09 system,info router rebooted 
sep/15 09:54:33 system,info,account user admin logged in from 10.1.101.212 via winbox 
sep/15 12:33:18 system,info item added by admin 
sep/15 12:34:26 system,info mangle rule added by admin 
sep/15 12:34:29 system,info mangle rule moved by admin 
sep/15 12:35:34 system,info mangle rule changed by admin 
sep/15 12:42:14 system,info,account user admin logged in from 10.1.101.212 via telnet 
sep/15 12:42:55 system,info,account user admin logged out from 10.1.101.212 via telnet 
01:01:58 firewall,info input: in:ether1 out:(none), src-mac 00:21:29:6d:82:07, proto UDP, 
                          10.1.101.1:520->10.1.101.255:520, len 452

If logs are printed at the same date when log entry was added, then only time will be shown. In example above you can see that second message was added on sep/15 current year (year is not added) and the last message was added today so only the time is displayed.

For example following command will print all log messages where one of the topics is info and will detect new log entries until Ctrl+C is pressed

[admin@ZalaisKapots] /log > print follow where topics~".info"
12:52:24 script,info hello from script
-- Ctrl-C to quit.

If print is in follow mode you can hit ‘space’ on keyboard to insert separator:

[admin@ZalaisKapots] /log > print follow where topics~".info"
12:52:24 script,info hello from script

 = = =   = = =   = = =      = = =   = = =   = = =      = = =   = = =   = = =

-- Ctrl-C to quit.

Logging configuration

Sub-menu level: /system logging

Actions

Sub-menu level: /system logging action

Topics

Each log entry have topic which describes the origin of log message. There can be more than one topic assigned to log message. For example, OSPF debug logs have four different topics: route, ospf, debug and raw.

11:11:43 route,ospf,debug SEND: Hello Packet 10.255.255.1 -> 224.0.0.5 on lo0 
11:11:43 route,ospf,debug,raw PACKET: 
11:11:43 route,ospf,debug,raw     02 01 00 2C 0A FF FF 03 00 00 00 00 E7 9B 00 00 
11:11:43 route,ospf,debug,raw     00 00 00 00 00 00 00 00 FF FF FF FF 00 0A 02 01 
11:11:43 route,ospf,debug,raw     00 00 00 28 0A FF FF 01 00 00 00 00 

List of Facility independent topics

Topics used by various RouterOS facilities

12:41:40 route,bgp,debug,timer KeepaliveTimer expired 
12:41:40 route,bgp,debug,timer     RemoteAddress=2001:470:1f09:131::1 

Logging to file

To log everything to file, add new log action:

/system logging action add name=file target=disk disk-file-name=log

and then make everything log using this new action:

/system logging add action=file

You can log only errors there by issuing command:

/system logging add topics=error action=file 

This will log into files log.0.txt and log.1.txt.

You can specify maximum size of file in lines by specifying disk-lines-per-file. <file>.0.txt is active file were new logs are going to be appended and once it size will reach maximum it will become <file>.1.txt, and new empty <file>.0.txt will be created.

You can log into USB flashes or into MicroSD/CF (on Routerboards) by specifying it’s directory name before file name. For example, if you have accessible usb flash as usb1 directory under /files, you should issue following command:

/system logging action add name=usb target=disk disk-file-name=usb1/log

Examples

Webproxy logging

These two screenshots will show you how to configure the RouterOS logging facility to send Webrpoxy logs to a remote syslog server, in this example, located at 192.168.100.12. The syslog server can be any software that supports receiving syslogs, for example Kiwi syslog.

Add a new logging action, with «remote» and the IP of the remote server. Call it whatever you like

Then add a new logging rule with the topic «webproxy» and then newly created action. Note that you must have webproxy running on this router already, for this to work. To test, you can temporary change the action to «memory» and see the «log» window if the webproxy visited websites are logged. If it works, change it back to your new remote action

Note: it’s a good idea to add another topic in the same rule: !debug. This would be to ensure you don’t get any debug stuff, only the visited sites.

Rsyslog

It is possible to send all logs to a remote syslog server, one example of a syslog server is Rsyslog. Below you can find configuration example that is relevant to RouterOS:

/system logging action
set [find name=remote] remote=10.0.0.1
/system logging
add action=remote topics=info
add action=remote topics=critical
add action=remote topics=error
add action=remote topics=warning

With this configuration all logs will be present on the device and on the remote syslog server. Below you can find configuration lines that are relevant to a Rsyslog server (only lines that should be changed from the default values):

#/etc/rsyslog.conf
$ModLoad imudp
$UDPServerAddress 10.0.0.1
$UDPServerRun 514
$AllowedSender UDP, 10.0.0.0/24 127.0.0.1

$template Router1Log, "/var/log/MikroTik/router1.log"
:fromhost-ip, isequal, "10.0.0.2" -?Router1Log
& stop

For security reasons you should only allow Rsyslog to listen to a certain address, this limits the instance to a single interface. You should also specify only certain IP addresses that are allowed to send their logs to the particular syslog server.

Уровень сложности
Простой

Время на прочтение
7 мин

Количество просмотров 6.5K

Введение

Добрый день дорогие читатели, в этой статье я хочу рассмотреть однин из основных способов логирования событий в 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.

Устройства Cisco позволяют писать подробные «лог» журналы, позволяющие анализировать состояние устройств, выявлять проблемы и разбирать сетевые инциденты. Глубина логирования это как всегда компромисс между сбором максимально возможной информации и возможностью проанализировать этот объем. Анализ логов необходимо производить регулярно, а при большом количестве устройств имеет смысл установки в сети единого сервера логирования и, возможно, автоматизировать процесс анализа критичных событий.

Способы логирования

Существует шесть способов сбора лог-информации с устройств Cisco:

1. Console logging — вывод сообщений на консоль маршрутизатора, т.е. для их чтения нужно быть подключенным к консоли.
2. Buffered logging — в этом случае все лог-сообщения будут размещаться в оперативной памяти маршрутизатора. Просмотреть их можно командой show logging, но следует помнить, что буфер сбора логов ограничен и при большом количестве сообщений старые записи будут затёрты более новыми и будут потеряны. Размер буфера можно менять.
3. Terminal logging — выводятся лог-сообщения на VTY терминал. По умолчанию функция отключена, чтобы включить надо ввести в терминале команду terminal monitor.
4. Syslog — устройство будит посылать лог сообщения на один или несколько внешних syslog серверов.
5. SNMP traps — устройство Cisco будет посылать посылать SNMP сообщения (traps) на один или несколько SNMP серверов для сбора событий происходящих на маршрутизаторе.
6. AAA accounting — если использовать AAA, то можно заставить устройство отправлять информацию о подключениях администраторов к устройству и командах выполненных на маршрутизаторе во время этого подключения на NAS (Network Access Server) сервер.

Каждый из способов сбора лог сообщений можно включить либо отключить, а также настроить на каждом глубину (уровень) логирования. Всего существует 8 уровней от 0 до 7:

• 0    Emergencies   Система не работоспособна 
• 1    Alerts        Необходимо срочное вмешательство 
• 2    Critical      Критические события 
• 3    Errors        Сообщения о ошибках 
• 4    Warning       Всевозможные предупреждения
• 5    Notifications Различные важные уведомления
• 6    Informational Информационные сообшения
• 7    Debugging     Отладочые сообщения

Чем больше номер уровня тем большее количество информации будет сообщать устройство. Так, уровень №6 будет содержать информацию всех остальных уровней с меньшими номерами.

Метки времени

В записях логов Cisco возможно использование двух типов меток времени – промежуток времени, прошедший с момента включения устройства (uptime) и текущие дата и время (по-умолчанию).
Для настройки uptime используется команда:

(config)#service timestamps log uptime

Для того чтобы заставить маршрутизатор Cisco снабжать все лог сообщения подробным временем их происхождения, следует использовать команду service timestamps log datetime, которая имеет несколько опций:

• msec — указывать миллисекунды в каждой лог записи, без этой опции лог сообщения будут иметь временные отметки глубиной до секунды; 
• localtime — эта опция указывает устройству использовать местное время для лог записей, рекомендуется использовать её для упрощения понимания логов. Однако следует помнить о возможной путанице, если несколько маршрутизаторов с разных часовых поясов,буду писать свои логи на один syslog сервер;
• show-timezone — при помощи данной опции можно заставить устройство cisco указывать текущий часовой пояс в каждом лог сообщении, при помощи этой опции можно упростить разбор лог сообщений от нескольких устройств с разными часовыми поясами;

Ещё пара команд для правильного отображения времени в логах. 

Для отображения локального времени в логах в памяти устройства применяется команда:

(config)#service timestamps log datetime localtime

 Ну и ещё одна команда для режима отладки (debugging):

(config)#service timestamps debug datetime localtime

Console logging

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

R7(config)# logging console 6

или

R7(config)# logging console informational

Также может быть очень полезной команда logging synchronous на консоль, это упростит чтение логов.

Buffered logging

Запись логов в оперативную память. Как правило, сейчас устройства обладают достаточным количеством оперативной памяти поэтому лог размером, например 52000 байт не будет критичным для устройства Cisco.

R7(config)# logging buffered 52000
R7(config)# logging buffered informational

Terminal logging

Terminal logging настроен по-умолчанию, но на VTY терминалы логи не выводятся. Для включения вывода логирования, в момент когда вы подключены к устройству по telnet или ssh необходимо ввести команду terminal monitor в привилегированном режиме. Отключение вывода лог сообщений: terminal no monitor

R7(config)# logging monitor warning
R7# terminal monitor

Syslog

Вывод лог информации на syslog сервер. Является наиболее удобным методом анализа логов, в случае, когда имеется большое количество устройств. Метод позволяет централизовать сбор логов. Здесь используются настройки syslog, настраивается категория (facility), уровень логов отправляемых на сервер, ip-адрес syslog сервера и адрес устройства с которого будут отсылаться логи (здесь логично использовать Loopback):

R7(config)#logging facility local2
R7(config)#logging trap notifications
R7(config)#logging source-interface Loopback1
R7(config)#logging host 10.10.10.1

Ещё дополнительна команды для удобства чтения логов, она добавляет имя устройства к каждой записи:

R7(config)logging origin-id hostname

Безопасность syslog сервера

По-умолчанию большинство syslog серверов принимают все сообщения. Поэтому злоумышленник может зафлудить сервер ложными или не интересными нам сообщениями. Чтобы этого избежать, считается хорошим тоном ограничить прием сообщений  syslog сервером, таким образом чтобы он мог работать только с внутренней сетью предприятия, либо (если предприятие большое и ip пространство хорошо спланировано) только с сетями выделенными под управление сетевыми устройствами. Сервер принимает сообщения на порту 514 (UDP).

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

R7(config)#service sequence-numbers

Позволяет получить дополнительную информацию с устройств Cisco, которая не можут быть получена вышеуказанными способами. Для этого может понадобиться сервер TACACS. Об ААА и TACACS я писал здесь.

Полезные команды связанные с логированием

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