立即与支持人员聊天
与支持团队交流

InTrust 11.6 - Technical Insight

Licensing

The InTrust license is stored in the configuration database. License verification is performed by the InTrust Real-Time Monitoring Service on InTrust servers every three hours. If a license check fails due to the configuration database being offline, attempts are repeated until a connection is established.

Licensing Errors

Licensing errors occur in the following situations:

  • No license has been installed.
  • The license has expired.

If either of these situations occurs:

  • InTrust operation is suspended.
  • Event 8207 is written to the InTrust Server event log.
  • Until a valid license is installed, the same event is written every three hours, and license checks are performed every three minutes.

If you attempt to gather audit data without a license or with an expired license, corresponding error messages will appear in the sessions. No events are written to the InTrust Server log for such attempts.

Real-Time Monitoring

A real-time monitoring rule can be configured so that matching and response actions are executed either on the agent side or on the server side.

Rule matching and response action execution on remote agent mean that:

  • Agent matches rule (body only)
  • Agent executes response action (under security context of the agent)

Rule matching on remote agent and response action execution on server mean that:

  • Agent matches rule (body only)
  • Server executes response action (under security context of the RTM service)

Rule matching and response action execution on server mean that:

  • Agent matched rule (pre-filter only)
  • Server matches rule (both pre-filter and body)
  • Server executes response action (under security context of the RTM service)

If rule matching is configured to be done by server and response action execution—on remote agent, then rule is rejected, and an event is logged in the InTrust log.

Agent-Side Rule Matching

If a rule is configured to be matched on the agent side, the real-time monitoring process goes as follows:

  1. An event is matched.
  2. A remote agent adds the alert to its outbound buffer (a 10MB file buffer).
  3. The remote agent removes the alert from the outbound buffer and sends it to the local agent.
  4. A local (server-side) agent places the alert in a per-agent buffer (a 1MB file buffer):
    • When the per-agent buffer is full, the local agent logs a buffer overflow“” event and stops accepting alerts from that remote agent until 50% of the buffer is free.
    • When the buffer drops to 30% full, a “buffer overflow resolved” event is logged.
    • The remote agent continues trying to re-send the alert.
  5. The Quest InTrust Real-Time Monitoring service reads the alert from the per-agent buffer and places it in another buffer (“4k” buffer), which can store about 4000 alerts and resides in the Quest InTrust Real-Time Monitoring service memory.
  6. The alert is written to the alert database.

Server-Side Rule Matching

If a rule is configured to be matched on the server side, the real-time monitoring process goes as follows:

  1. An event occurs on the agent side.
  2. The remote agent matches the rule’s pre-filter.
  3. The remote agent forwards the event to the local agent (using the process described for agent-side rule processing).
  4. The Real-Time Monitoring rule matches the complete rule (both pre-filter and body).
  5. The RTM Service stores the alert in the “4k” buffer and executes the response action. If the “4k” buffer is full:
    • The response action is not executed.
    • The alert does not get stored in the alert database.
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级