One of the new features in recent Halo releases is Logging and Alerting: the ability to have security events raise a live alert or create a log entry for auditing. Because the features are so new, we wanted to give a brief intro on how to use them.
Just as they sound, logs are records of something happening and alerts are more urgent notices that get sent to an email address (or indirectly to a pager or other email accessible service, like a ticketing system).
In Part 1, we’ll look at how to create log and alert entries; in Part 2 we’ll show you how to see logs in the web portal; and in Part 3 we’ll look at how to get alerts to the right email accounts.
Creating alerts and logs
The portal allows you to create logs and alerts from three different sources; Configuration Policies, Special Events Policies, and GhostPort logins.
Configuration Policy logging and alerting
Take a look at one of your configuration policies (in the Portal, go to “Policies”, then “Configuration Policies”, select a policy, and then press “Expand All”). Click on one of the rules and you’ll see the details show up on the right. Each rule needs one or more checks underneath that actually test something on the system.
When a system fails any checks, the encompassing rule fails as well. We need to decide what action to take. If you simply want to log that the rule failed for future reference, check off the “Log” box. To get an alert sent to one or more emails, check off “Alert” as well. If you just want to have the failure show up in the daily report but nowhere else, uncheck both.
As a side note, if you don’t want the rule at all because it just doesn’t apply to your environment, just uncheck “Active”.
There’s one more relevant flag here for each rule: the “Critical” flag. If you check this off for a given rule, it marks the log entry and/or alert as critical. We’ll see how to use this in both Logs and Alerts in a minute.
Special Events Policy logging and alerting
The Special Events Policy was added recently to handle system events that don’t easily fit in a normal Security Policy. To follow along, go to the portal, Choose “Policies”, and then “Special Events Policies”.
If you haven’t worked with Special Events Policies before, you’ll only have a single policy called the “Global Events Policy”; this applies to all machines that don’t have their own custom policy. If you have a group of machines about which you have higher or lower alerting needs, you can create a specific Security Event Policy for them. For example, I might want to be alerted to a reboot on almost all machines under my control. However, I have a group of development machines that get rebooted regularly and don’t need to know about it; I’ll create a “Development” Security Events Policy for them and uncheck “Server restarted”.
Click on a policy and you’ll see the types of events that can have special actions; events like “Server restarted”, “Server account deleted”, and “Server firewall modified”. If you’d like to create a log entry if one of those events happens, click the “Log Event” box to the right. To also get an emailed alert, check off “Generate an alert”.
Just as with the configuration policy rules, there’s a third option for each; “Flag critical”. Check this off to add a “Critical” flag to the log and/or alert.
GhostPort Login logging and alerting
When your staff use GhostPorts to log in and put in temporary firewall rules, we want to make sure you can see login successes and failures. Both create Log entries and Alerts, so you can be notified about user login attempts.