This check happens every 2-5 mins, & from various nagios servers. With this check going on, the logging buffer and log messages that's are sent to the remote-syslog servers, will be flooded with this useless message.
So how can we filter this? Very easy.
The means to filter these or similar messages is quite simple with a suppression rule and by applying the suppression. 1st let's look at how cisco classify all log messages.
http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_monitoring/configuration/guide/b_sysmon_cg42crs/b_sysmon_cg42crs_chapter_0100.html
All messages has the following;
So knowing this information, will help in identifying the messages or via using log management/crunching tools like; sawmill, splunk, ng-syslog, etc... You can write triggers to handle certain log messages base on the log message type and severity, etc.....
The same applies within the IOS-XR integral suppression. Here we will break down the log format and build a suppression rule named "dropitlikeitshot_log"
So for the ssh error message;
%SECURITY-SSHD-6-INFO_GENERAL : Failed to read from socket
We now know the following
- it's a SECURITY message from the SSHD service
- with a severity of 6 { unix-information level]
- the information is general
- and the body contains "Failed to read from socket"
NOTE: If you choose the latter ( all-alarms ) this would not require a message-category , and may limit your flexibility with regards to the suppression of certain types of messages.
Now know the above following details of our unix-like log messages, we can build a suppression rule and apply it.
Okay that was very easy and we learn of one way to build and activate a suppression filter.
Key points to consider b4 you start suppressing log messages;
- if you suppress it, the message would not be logged or recorded
- beaware of any active suppression rules that are currently applied
- you might want to disable suppression during any major upgrades to ensure nothing is suppressed from your view
- you don't have the luxury to apply suppression per logging destinations, as you do within IOS, so suppression effects ALL local/remote/file-logging equally
- modifying an active rule, requires you to disable the suppression before you can make any changes
Logging within IOS-XR is a need to ensure critical to informational events are always present. Without logging, we would blind to system generated events. It may come a time to filter certain types of messages from the logging systems to reduce load or eliminate redundant or useless information.
Ken Felix
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
^ ^
=( < > )=
o
/ \
No comments:
Post a Comment