Auditing data access
It’s also important to understand the kinds of requests that clients make. This can help you identify requests that are out of the ordinary, which might be evidence of a potential attack.
Log analysis
The primary way to accomplish this is through log analysis. It is important to regularly examine (or at least summarize) the log files to classify the types and frequency of operations being performed. A sudden increase in any one kind of traffic can be a red flag, but situations like the following might be of particular interest:
-
Connections from unusual client addresses, or a spike in requests from certain clients.
-
Operations that fail with invalidCredentials (49) or insufficientAccessRights (50) results.
-
Search operations that fail with a timeLimitExceeded (3), sizeLimitExceeded (4), or adminLimitExceeded (11) results.
-
Search operations that do not return any entries.
-
Search operations that return large numbers of entries.
-
Search or compare operations that explicitly attempt to retrieve or target the userPassword attribute (or another password attribute).
-
Search operations that might represent attempts to exfiltrate data from the server through trawling. This can include things like repeated substring filters with subInitial filters in sequential order, such as searches with filters like
(cn=aa*),(cn=ab*),(cn=aa*), and so on. It can also include greater-or-equal and less-or-equal filters with similar patterns. -
Unindexed search attempts.
If you regularly characterize the types of operations that clients request, then you might be able to more easily identify anomalous requests.
There might be other specific events that you always want to know about. For example, you might want to know whenever clients retrieve search result entries that contain encoded passwords, or whenever a client alters the server’s access control definitions or the set of privileges granted to an account. In such cases, you can create criteria to specifically identify those types of operations, and then you can use that criteria to create a logger that only records those types of events.
If you want to know about these kinds of events right away, then you could create an admin alert access logger using that criteria. This causes the server to generate an administrative alert (with an alert type of access-log-criteria-matched) whenever it processes an operation matching that criteria.
Account status notification handlers
You might want to audit certain events related to password policy processing. For example, if the server is configured to lock accounts after too many failed attempts, then you might want to have a record of any time that happens. You might also want to have a record of all administrative password resets and self password changes.
This can be accomplished with account status notification handlers, and the server provides implementations that can either record messages about these kinds of events in the server error log or that can send email messages about them. If you would like to handle them in other ways, then you can use the UnboundID Server SDK to create a custom account status notification handler that implements the desired behavior.