Information about local incidents is logged by anti-virus as events and sent by the Agent to Administration Server. Examples of anti-virus events are dangerous object detection, license expiration, or anti-virus database corruption.
Events may be received locally as pop-up notifications and sound signals. Optionally, e-mail notifications about events can be sent from local computers and information can be registered in Windows Event Log.
If anti-virus management is centralized, local notifications are recommended to be disabled for most events. Only those informing of a blocked operation should be shown, for example, about a blocked attempt to start a malicious file, or a blocked opening of a phishing web page. If these notifications are disabled, the user will not know why some web pages cannot be displayed or some files disappear from removable media. They even may come to a wrong conclusion and decide that either the computer is infected or the operating system malfunctions, and will contact a wrong administrator.
To provide the administrator with information about events on the network computers, they are sent by Agents to the Administration Server and stored in the database. After this they can be viewed through Kaspersky Administration Console.
Event Storing Parameters
Sending events to Administration Server and storing them in the database is not an unconditional behavior of Kaspersky Administration Kit. You can configure which events to save in the database and for how long. By default none event is stored in the database forever. Maximum storing time is 180 days, but many events are stored for 30 or even 7 days.
Event sending and storing parameters are set up in Kaspersky Anti-Virus policy. Just like policy of any other managed product, it has a tab where all events to be registered are specified
Kaspersky Administration Kit events are classified as follows:
The category of an event is a built-in characteristic, it cannot be modified. For example, infected object detecting is always a critical event; you cannot assign it warning or any other status.
Event Storing Settings
Storing settings are configured in event properties. Events can be saved:
On Administration Server—for a specified period of time (by default, 30 days for all Kaspersky Anti-Virus events)
In the event log on the client computer
In the event log on Administration Server
In Windows Event Log, Kaspersky Anti-Virus events are recorded to the Kaspersky Event Log section.
Events stored in the Administration Server database can be viewed in the console. They can be filtered by a wider list of attributes than in Windows Event Log. Also, Administration Server reports are based on the events stored in the database. So as reports could be used as a reliable analysis tool, it is very important that all events concerned with threat detection and processing were stored in the Server database.
In Windows Event Log events may be stored for longer. There is actually a limitation there, but the one imposed on the log size (by default, 4 MB), not on the storing time, and if a computer is not constantly attacked, the log will not be overfilled for much longer than 30 or even 180 days.
Thereby Windows Event Log can be used as a kind of an archive. After events are removed from the Server database, they can be found in Windows log. However, this rather relates to storing events in a client computer log. If events of the whole network are logged on Administration Server, it is quickly filled and new events replace old ones, and it cannot be used as an archive.
To view events in the operating system log, use the Event Viewer system utility available through Administrative Tools menu.
Kaspersky Administration Console provides the same functionality for the events saved in the server database. You can view events in the Events node of the Event and computer selections container. There are several standard event selections. Selection is, actually, a saved filter. It displays events that meet the specified search conditions. In standard selections search conditions are simple—events for the last several days, or events belonging to one category:
Recent events—by default, all events for the last 7 days. The period can be modified
Audit events—informational event subcategory that includes records about system configuration changing
The administrator can create new event selections with more complicated filtering conditions1.
Event storing settings adjoin notification parameters. Notifications are necessary for the administrator to be informed in time about important events, especially those that may require immediate reaction. If events are just recorded to the server database and operating system logs, the administrator will not know about them until he opens the corresponding event2.
Methods of Notification Delivery
Administration Server supports several ways for sending notifications:
sing NET SEND tools
By running an executable file or script
E-mail notifications are easy to set up and use. Everybody has a mail box, and everybody knows what an e-mail server address and an e-mail address are. In other words, an e-mail notification can be configured almost in any network without making any additional arrangements. And if the administrator looks into the mail box more frequently than in Kaspersky Administration Console, notification goal will be achieved.
NET SEND notification tool potentially better attract the administrator’s attention. They are shown on the computer as pop-up modal windows and will be noticed anyway. Such display behavior means that NET SEND notification tools should be used only for very important and comparatively rare events. Otherwise, the administrator will quickly be tired of pop-up windows and disable the annoying notifications.
At present, NET SEND notification tools are gradually out of use. They are implemented in the Messenger service, which is absent in the latest Windows versions—Windows Vista, Windows Server 2008 and Windows 7. In Windows XP and Windows Server 2003 it is available, but is disabled by default.
SNMP notification is based on a standard network resource management protocol. To use these notifications in Kaspersky Administration Kit, tools that support this protocol must be installed on Administration Server.
Running an executable file or script is rather not a notification method, but an extended event reaction. In substance, the administrator can automatically run any command if an event takes place. Note that the command will be run on Administration Server, not on the computer where the event has happened. It is an expert-level facility, and most administrators do not use it.
Event storing and notification settings need not be specified for every event. You can select several events, click the Settings button and modify a parameter—it will be applied to all selected events.
Notification Delivery Parameters
Notification delivery parameters, that is, addressees, e-mail server address or name of the executable file to be run, are specified in the Reports and Notifications node properties. E mail notification delivery parameters are prompted for in the Quick Start wizard at the first start of the console. To configure notifications by other means or modify the specified delivery parameters, in the properties window of the Reports and Notifications node open the Notification tab.
E-mail delivery settings are almost the same as in the Quick Start wizard. At the upper level you specify the parameters without which e-mail notification is impossible in principle:
E-mail recipient address—you can specify several addresses separated by a comma or semicolon
Address (or name) of SMTP server
SMTP server port—the default port 25 is the standard port for sending messages over SMTP
To specify message subject, SMTP server authentication parameters, or the sender address, click the Parameters button. These settings are not critical for sending e-mail notification. Authorization is not always necessary, a subject will be provided automatically by Administration Server, and if the sender is not specified explicitly, the first recipient’s address will be used for sending.
NET SEND notification settings include only the recipients’ addresses. Recipients in this case are computers, which can be specified by names or IP addresses separated by a comma or semicolon.
For running an executable file or script, only its path is necessary3. To execute a complicated sequence of actions, a script is usually written. An executable file or script can be run with parameters, which can contain event attributes specified in macros—where the event happened, when, and the event description. Analogous macros can be used for generating an e-mail subject and the notification text.
The same notification text is used in both e-mail and NET SEND messages. The standard text includes most event attributes and usually need not to be changed.
Macros in the Notification Text
The macros that can be used in the notification text (and also in an e-mail notification subject or executable file or script parameters) are listed below:
Macro notation for using in message text or commands
IP address for the connection
Customizing Notification Delivery Parameters
In Reports and Notifications node properties, general settings for all events are specified. Such parameters as e mail server address and port, sender address and authorization data are usually the same for all events. And that goes for the notification text, too: if it includes all event attributes, it becomes multipurpose. Different addressees for different events might come in handy in some cases, not often though.
What actually can (and should) be different is the command triggered by an event, in other words, settings for notification by starting an executable file or script. First, such an exceptional reaction is likely to be necessary only for some events, not in the least for all. Second, automated reaction must be different for different events.
Anyway, if general settings are no good for some events, you can specify individual parameters. For this purpose you should click the Settings link in the event properties. The open window contains the same options as those described earlier in properties of the Reports and Notifications node. Initially, all events inherit general settings. To specify individual delivery parameters for an event, disable the Use Administration Server settings option. Individual notifications can be specified for each notification method independently.
Notification Sending Restrictions
If the administrator does not want to be constantly distracted by notifications, they can limit the number of notifications sent over a period of time. If the limit is 5 notifications in 1 hour than the first 5 events within an hour will trigger notifications whereas all the other events occurred within 1 hour since the first one will simply be saved in the database without triggering a notification. After 1 hour passes newer events will trigger notifications again.
Each event type is treated separately. Even if the limit for infected object detections has been reached, notifications about events of other types will be delivered.
If some events do not interest you at all, disable in their properties all storing and notification options. After this, the Agent will not send such events to the Server.
1—Detailed information on creating and configuring event selections is presented later in this chapter
2—It does not mean the administrator will not know about the incidents concerned with events at all. Important incidents change computer status, which is described later
3—An executable file or script is launched on Administration Server, so the path must be specified in the context of the computer where Administration Server is installed