Difference between revisions of "Projects/Audit"

Latest revision as of 12:01, 29 October 2013

Description

This project creates a pluggable audit interface to allow the monitoring of security-related events on the KDC.

The interface is considered "experimental", in that API stability is not guaranteed to future major releases.

Requirements

The new audit system should be:

• build-time enabled;
• run-time pluggable;
• simple and flexible, so it could be easily replaced with the OS specific and third-parties implementations;

Events

We consider events under the categorization of the Common Criteria Class FIA.

This section details the categories of the auditable events and the associated data.

1. Startup and shutdown of the KDC must be recorded by audit system;

2. The bulk of the audit information will be produced while processing AS and TGS requests. Though KDC request processing can be grouped into several logical phases, we generate (usually) only two events, one at the initial receipt of a request, and a second, final, one before sending a reply. All events relating to the same request can be linked together in the audit log by a 32-character alphanumeric string (about 190 bits of uniqueness) which is randomly generated at the start of processing. If the request is a S4U2Self or S4U2Proxy request, an additional audit event will be generated with information particular to the S4U request. The following table lists the logical stages of KDC processing, and which components are logged in the AS and TGS cases:

The following information will be made available to audit plugins:

a unique request ID

the complete KDC request structure

the KDC reply structure (possibly only partially populated)

the client's IP address and port number

the stage of KDC processing at which the audit event was triggered

the KDC status string (as appears in kdc.log)

ticket IDs (checksums) for any supplied tickets or ticket to be returned

the remote client's realm (for referrals)

the impersonated user for an S4U2Self request

the "type of violation" which caused the request to fail, if applicable

Other events to consider for the future development:

3. Further details about policy viloations

Event description, reason and how to fix it;

4. Secrets (Common Criteria FCS_CKM.1, FCS_CKM.4);

long- and short-term key creation, manipulation, cleaning.

Design details

Ticket ID

Ticket ID is recorded as part of audit messages. This allows to link tickets to their initial TGT at any stage of the Kerberos exchange.

For the purpose of this project we will create a private to KDC ticket ID: each successfully created ticket will be hashed and recorded into audit log. The administrators will correlate the primary and derived ticket IDs after the fact.

For the future, however, we need a more complex system that would allow to tie the tickets from a successful AS_REQ all the way to the application server. It is marked as an action item in this section.

Request ID

Request ID is a randomly generated alpha-numeric string. Using this ID an administrator can easily correlate multiple audit events related to a single request. It should be informative both in cases when the request is sent to multiple KDCs, or to the same KDC multiple times.

KDC facing API

/* Audit plugin loaded/unloaded */
krb5_error_code 
load_audit_plugin(krb5_context context);
krb5_error_code 
unload_audit_plugin(krb5_context context);
krb5_boolean
kau_isloaded(krb5_context context);
/* event specific functions */
krb5_error_code
kau_kdc_start(krb5_context context, const int event_id, const int status);
krb5_error_code
kau_kdc_stop(krb5_context context, const int event_id, const int status);
krb5_error_code
kau_asreq(krb5_context context, const int event_id, const int status, audit_state *state);
krb5_error_code
kau_tgsreq(krb5_context context, const int event_id, const int status, audit_state *state);
krb5_error_code
kau_s4u2self(krb5_context context, const int event_id, const int status,  audit_state *state);
krb5_error_code
kau_s4u2proxy(krb5_context context, const int event_id, const int status, audit_state *state);
krb5_error_code
kau_u2u(krb5_context context, const int event_id, const int status, audit_state *state);
/* utilities */
krb5_error_code
kau_init_kdc_req(krb5_context context, krb5_kdc_req *request,  const krb5_fulladdr *from, audit_state **au_state);
krb5_error_code
kau_make_tkt_id(krb5_context context, const krb5_ticket *ticket, char **out);
krb5_error_code
kau_make_req_id(krb5_context context, const krb5_kdc_req *request, char **out);

where event_id references to the Phase (left column of events table), and audit_state structure holds the following information:

typedef struct _audit_state {
   krb5_kdc_req *req_in;   /* request in the original form */
   krb5_kdc_req *req_mod;  /* modified (per protocol) request */
   krb5_kdc_rep  *reply;
   const krb5_fulladdr *from;
   const char    *status; /* additional information string */
   char *tkt_in_id;       /* primary (TGT) ticket ID */
   char *tkt_out_id;      /* derived (service or referral TGT) ticket ID */
   char *evid_tkt_id;     /* for s4u2proxy - user's evidence ticket ID, for u2u - TGT ticket ID */
   char *req_in_id;       /* original-request ID */
   char *req_mod_id;      /* modified-request ID */
   krb5_int32 sess_etype; /* session key enctype */
   krb5_int32 srv_etype;  /* enctype of the long-term key of service */
   krb5_int32 rep_etype;  /* reply-encrypting key enctype */
   krb5_boolean tkt_renewed;
   krb5_boolean tkt_validated;
   /* referrals */
   krb5_data *cl_realm;   /* remote client's realm */
   /* s4u and u2u */
   krb5_principal s4u2self_user;  /* impersonated user */
   krb5_principal s4u2proxy_user; /* delegated user */
   krb5_principal u2u_user;       /* client for the second ticket */
   char *violation;               /* local or protocol policy problem */
} audit_state;

Pluggable interface

/* Audit plugin vtable */
typedef struct krb5_audit_vtable_st {
   /* Mandatory: name of module. */
   char                 *name;
   int                   conf_options;
   kau_open_fn           open;
   kau_close_fn          close;
   kau_kdc_start_fn      kdc_start;
   kau_kdc_stop_fn       kdc_stop;
   kau_as_req_fn         as_req;
   kau_tgs_req_fn        tgs_req;
   kau_s4u2self_fn       tgs_s4u2self;
   kau_s4u2proxy_fn      tgs_s4u2proxy;
   kau_u2u_fn            tgs_u2u;;
} *krb5_audit_vtable;
 
typedef krb5_error_code
(*kau_open_fn)(kau_ctx *au_ctx);
typedef krb5_error_code
(*kau_close_fn)(kau_ctx au_ctx);
typedef krb5_error_code
(*kau_kdc_start_fn)(kau_ctx au_ctx, const int event_id, int status);
typedef krb5_error_code
(*kau_kdc_stop_fn)(kau_ctx au_ctx, const int event_id, int status);
typedef krb5_error_code
(*kau_as_req_fn)(kau_ctx au_ctx, const int event_id, int status, audit_state *state);
typedef krb5_error_code
(*kau_tgs_req_fn)(kau_ctx au_ctx, const int event_id, int status, audit_state *state);
typedef krb5_error_code
(*kau_s4u2self_fn)(kau_ctx au_ctx, const int event_id, int status,  audit_state *state);
typedef krb5_error_code
(*kau_s4u2proxy_fn)(kau_ctx au_ctx, const int event_id, int status,  audit_state *state);
typedef krb5_error_code
(*kau_u2u_fn)(kau_ctx au_ctx, const int event_id, int status, audit_state *state);

JSON based audit module

We will use libaudit module available on Fedora, Debian, SuSe for the first round. The new JSON utility library will be built to parse Kerberos specific structures. The "simple" audit module will be statically linked to this library.

The following is a proposed Dictionary - the basic field names for JSON parsing:

Configuration

The following ./configure option to be added:

--with-audit-plugin

For example, --with-audit-plugin=simple, where simple is the name of the audit plugin module

Test

A testable audit module, k5audit_test, will be built, and enabled for a python test program which is added. This test module uses the internal libauditjenc library to generate a JSON encoding of the audit event, and writes that encoded string to a flat file, which is parsed by the python test program.

Future work

1. Standardize a Ticket ID;
2. Make reporting auditable events configurable. For example, one can choose to report TGS_REQ, but not AS_REQ;
3. Sanitize KDC request and KDC reply before passing them to the concrete audit implementation: security sensitive information should not leave KDC boundaries;
4. Develop audit system for Preauth and Authdata mechanisms;
5. Expand Kerberos Audit facility to the application servers and kadmin.

References

1. Common Criteria for Information Technology Security Evaluation http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf
2. Oracle Solaris Auditing http://docs.oracle.com/cd/E19963-01/html/821-1456/auditov-1.html
3. Understanding Linux Audit http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html
4. Advanced Security Audit Policy Settings http://technet.microsoft.com/en-us/library/dd772712(v=ws.10).aspx
5. Events Classification in Log Audit http://airccse.org/journal/nsa/0410ijnsa5.pdf
6. CEE Log Syntax (CLS) Encoding http://cee.mitre.org/language/1.0-beta1/cls.html

Commits

   e63b2c9b0ed3b19f6aa1ac90222240690a1bc55b KDC Audit infrastructure and plugin implementation
   1003f0173f266a6428ccf2c89976f0029d3ee831 KDC Audit infrastructure and plugin implementation (merged)
   5036f91e7b61a73a1ec2d39ce1cc6bbf60dd82ab Fix audit test module initialization

Completed in [krbdev.mit.edu #7712] and [krbdev.mit.edu #7713]

Release Notes

Administrator experience:

• Add an experimental pluggable interface for auditing KDC processing. This interface may change in a backwards-incompatible way in a future release.