/usr/lib/security/audit_remote.so
用于 Solaris 审计的 audit_remote 插件模块 /usr/lib/security/audit_remote.so 可按照二进制审计记录 (audit.log(4)) 在auditconfig(1M) 中的配置方式将二进制审计记录发送到审计服务器。
如果 audit_remote 插件通过 auditconfig 配置为活动状态,则由 auditd(1M) 装入该插件。使用 auditconfig –setplugin 选项可以更改所有与插件相关的配置参数。
Solaris 审计服务守护进程的审计远程服务 ars(5) 可使用 auditconfig 进行配置以接收 audit_remote 发送的二进制审计记录。
下列属性指定 audit_remote 插件的配置:
host1[:[port1][:mech1]][,host2[:[port2][:mech2]],... \ hostn[:[portn][:mechn]]]
审计主机/服务器列表。审计记录将发送到第一台可用主机。如果在发送数据时主机无法访问或出现超时,则将尝试列表中的下一台主机。如果与所有主机的连接均失败,则将从头开始重新尝试该列表。
p_hosts 条目的 host 部分可采用 getipnodebyname(3SOCKET) 接受的任何形式。
p_hosts 条目的 port 部分是将联系以启动审计服务器连接的主机上的端口。如果未指定,则该端口号是分配给 solaris-audit 服务的端口号。请参见 getservbyname(3XNET)。
p_host 条目的 mech 部分是 GSS-API 机制名称 (mech(4))。如果未指定,则使用本地主机的缺省机制。建议的机制为 kerberos_v5。
尝试连接到服务器并向其发送数据的次数。
缺省值为 3。
连接/发送数据超时的秒数。
缺省值为 5 秒。
要保留的未处理审计记录的最大数目。
缺省值是内核队列控制高界限的值。请参见 auditconfig(1M)。
如果设置为 0,则缺省值是内核队列控制高界限的值。请参见 auditconfig(1M)。
audit_remote plugin 是一个 TCP 客户机,可使用 GSS-API (libgss(3LIB)) 对配置的审计服务器进行验证。发送的二进制 Solaris 审计记录将通过 gss_wrap(3GSS) 生成的每消息令牌形式实施完整性和保密性保护。
该插件启动与审计服务器 (host:port:mech) 的 TCP 连接并通过相应的安全机制 (mech(4)) 建立 GSS 安全上下文(使用 gss_init_sec_context(3GSS))。
如果未指定端口,则将查找服务名称 solaris-audit 以获取 TCP 端口号。如果未指定机制,GSS_C_NO_OID 将用作 gss_init_sec_context(3GSS) 的 mech_type 参数,并使基础 GSS-API 使用本地缺省机制。
gss_init_sec_context(3GSS) 使用 GSS_C_NO_CREDENTIAL 作为启动器的凭证句柄和 audit@<host_fqdn> 格式的目标名称。服务器需要使用 gss_accept_sec_context(3GSS) 以完成上下文建立。
在建立安全上下文后,客户机(audit_remote 插件)调用 gss_wrap(3GSS) 以对传送的有效负荷(审计记录)实现保密性保护。服务器需要使用 gss_unwrap(3GSS) 才能展开收到的数据,并需要使用 gss_get_mic(3GSS) 获取稍后将作为消息检索确认发送回插件的 MIC(Message Integrity Code,消息完整性代码)。
例如,如果 kerberos_v5 机制在客户机上配置为 GSS_API 机制,且双方就使用此机制达成一致,则客户机必须有资格以非交互方式从 Kerberos KDC/TGS 获取 audit/<host_fqdn>@<REALM> 主体的会话密钥。同时,运行审计服务器应用程序的身份必须具有与存储在 keytab 文件 (krb5.conf(4)) 中的 audit/<host_fqdn>@<REALM> 主体关联的长期密钥才能解密会话密钥。
audit_remote 插件启动与 p_hosts 列表中的第一台服务器的连接。如果连接失败或审计记录发送在 p_timeout 秒内没有响应,则在 p_retries 次尝试后插件会尝试连接到下一台服务器。如果与最后一台服务器的连接失败,则插件会重新尝试连接到列表中的第一台主机。每次尝试连接到服务器未成功或发送超时(插件选项插件 audit_remote.so retry <count> <error>.<error> 是连接 <host:port> <the network error>),都将执行 audit_warn(1M)。EPROTO 网络错误指示客户机插件未获得成功的协议版本握手。
所有协议消息的前面都带有说明后跟数据大小的 4 个八位字节。此大小采用网络字节顺序。
协议以版本协商开头,后跟 GSS-API 安全上下文令牌交换。出现错误时将关闭连接(可以选择发送任何输出令牌)。
版本协商以明文形式进行,插件将发送受支持版本的逗号 (,) 分隔列表的八位字节数组。当前版本号是字符 01。接收者需要使用其接受的版本(在当前情况下为字符 01)进行响应。不匹配将视为错误,并将关闭连接。
插件发送的版本八位字节数组和接收者接受的版本字符串联在一起,以构成 GSS 安全上下文建立的通道绑定的应用程序数据字段。
<plugin version characters> || <server accepted version characters> "||" represents concatenation
后续令牌包含一个采用网络字节顺序的 64 位序列号以及一条审计记录 (audit.log(4));客户机使用保密性保护。wrap (64 位序列号 || 审计记录)
服务器使用收到的 64 位序列号以及已展开的 64 位序列号和审计记录的 MIC 令牌确认收到,然后对任何数据丢失负责。客户端上的 MIC 验证确认可以释放审计记录且不保存其用于可能的重新传输。
64 bit sequence number || mic (64 bit sequence number || audit record)
安全的远程审计客户机/服务器通信流:
1) Client <--> Server - TCP handshake 2) Client <--> Server - protocol version negotiation: a) Client --> Server - send data size - uint32_t value (2) b) Client --> Server - send clear text message of the versions supported comma separated, e.g., "01,02,03" for versions 1 and 2 and 3. The only version supported at present is "01" c) Client <-- Server - send data size - uint32_t value (2) d) Client <-- Server - send clear text version selected ("01") :no version match; close connection; try next host 3) Security context initiation: a) Client - Construct channel bindings: initiator address type (GSS_C_AF_NULLADDR) acceptor address type (GSS_C_AF_NULLADDR) application data value (4 octets "0101") b) Client --> Server - send token (data) size - uint32_t value c) Client --> Server - GSS-API per-context token d) Client <-- Server - send token (data) size e) Client <-- Server - GSS-API per-context token :repeat a-e until security context is initialized; if unsuccessful, close connection; try next host 4) Client - transmit thread, when audit record to be sent: a) Client --> Server - send data size b) Client --> Server - GSS-API per-message token wrap (sequence number || audit record) :repeat a-b while less than max (qsize) outstanding records 5) Client - receive thread: a) Client <-- Server - receive data size - uint32_t value b) Client <-- Server - receive sequence number - uint64_t value c) Client <-- Server - receive MIC d) Client - MIC verification - OK e) Client - remove particular audit record pointed by the sequence number from the retransmit buffer :repeat a-e, on error close connection; try next host; retransmit unacknowledged audit records 6) Server - receive thread: a) Client --> Server - receive data size b) Client --> Server - GSS-API receive, uwrap, store per-message token 7) Server - transmit thread: a) Server - MIC generation - message integrity code mic (sequence number || audit record) b) Client <-- Server - send data size c) Client < -- Server - send sequence number d) Client <-- Server - send MIC
使用以下指令可装入 audit_remote.so 并指定要将审计记录发送到的远程审计服务器。kerberos_v5 安全机制被定义为在与服务器通信时使用。
auditconfig -setplugin audit_remote active \ "p_timeout=90;p_retries=2; p_hosts=eggplant.eng.sun.com::kerberos_v5, purple.ebay.sun.com:4592:kerberos_v5"示例 2 使用缺省安全机制使用率的配置
以下示例说明了缺省安全机制使用率的配置。它还说明了如何在其中一台配置的服务器上使用缺省端口:
auditconfig -setplugin audit_remote active \ "p_timeout=10;p_retries=2; p_hosts=jedger.eng.sun.com, jbadams.ebay.sun.com:4592"示例 3 内部插件队列大小设置
某些条件(例如,高峰或突发审计数据通信流量以及服务器和客户机之间线路通信速度缓慢)可能使 audit_remote 插件排队的未处理审计记录的数量达到配置的最大数量。以下示例说明了如何设置队列大小参数。
auditconfig -setplugin audit_remote "" 1000
有关以下属性的说明,请参见 attributes(5):
|
插件配置参数是 "Committed"(已确定)。客户机/服务器协议(版本 "01")是 "Contracted Project Private"(合同项目专用)。有关审计记录格式和内容稳定性,请参见 audit.log(4)。
auditd(1M)、auditconfig(1M)、audit_warn(1M)、getipnodebyname(3SOCKET)、getservbyname(3XNET)、gss_accept_sec_context(3GSS)、gss_get_mic(3GSS)、gss_init_sec_context(3GSS)、gss_wrap(3GSS)、gss_unwrap(3GSS)、libgss(3LIB)、libsocket(3LIB)、audit.log(4)、krb5.conf(4)、mech(4)、ars(5)、attributes(5)、kerberos(5)、tcp(7P)
audit_remote 通过 GSS-API (libgss(3LIB)) 向远程审计服务验证自己。使用 gss 实现机制(例如 Kerberos)提供的缺省 gss 凭证。
IANA 分配的 solaris-audit 服务端口为 16162。