Chinaunix首页 | 论坛 | 博客
  • 博客访问: 240016
  • 博文数量: 115
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 930
  • 用 户 组: 普通用户
  • 注册时间: 2010-12-30 05:27
文章分类

全部博文(115)

文章存档

2011年(10)

2010年(21)

2009年(19)

2008年(65)

我的朋友

分类:

2008-07-01 09:13:52

原作者是freedemon 

SecU Solaris: 2.3- BSM审计系统

0. 预备知识
本文是Freedemon的<>中摘录的一段,因为上下文环境问题,有一些概念会是初读者
比较难以理解,所以现在这里做一个简要解释。

0.1 安全服务 security service 
由参与通信的开放系统的层所提供的服务, 它确保该系统或数据传送具有足够的安全性。简单的说,安全
服务就是在互联网个协议层次上实现和确保安全所需要使用的技术或非技术手段。

在ISO 7489-2开放互连安全模型中,定义了以下五类基本安全服务:
0.1.1 认证: 对象认证安全服务是辨明使用对象身份合法性的过程。它是针对主动攻击的主要防护措施,
它的主要功能是标识(Identify)和鉴别(Authenticate)。标识是辨明一个对象的身份;鉴别是证明该
对象的身份就是其声明的身份。举个例子,在Unix系统中,用户名和UID的唯一对照就是识别的功能,使
用UID来确认用户的唯一身份;而用户名和密码联用进行系统登陆认证的过程,就是鉴别机制。

0.1.2 访问控制: 就是对 主体对象 向 客体对象的操作进行鉴别和控制,防止主体越权访问信息的安全机
制。它是针对越权使用资源和非法访问的防御措施。按照访问控制策略可分为自主访问控制(DAC) 和 强
制访问控制(MAC)两个基本类型。 在Unix系统中,我们常见的访问控制形式为 用户权限矩阵(Permiss
-ion Matrix) 模型 和访问控制表(ACL) 模型,权限矩阵是Unix默认的访问控制形式,而ACL在各种
Unix系统中则表现为facl ( setfacl(8) getfacl(8) )。

0.1.3 机密性: 是针对信息泄漏、窃听等被动威胁的防范措施。机密性保证客体对象(数据流)在不同的安
全区域之间流动时,能够确保不被更低安全级别区域的主体对象所访问(读)到。 机密性安全服务又细分为
信息保密、选择段保密 和 业务流保密,在操作系统级别主要体现为信息保密,多级安全模型MLS是机密性
服务的基本策略模型。

0.1.4 完整性: 是防止非法篡改信息、文件和业务流的安全服务措施,即资源的可获得性。完整性策略保
证客体对象(数据流)在不同的安全区域之间传输时,不会被更低级别的客体对象写入或篡改,从而保证数据
的真实和完整。

0.1.5 抗抵赖: 它是针对对方进行抵赖的防范措施,可用来证实已发生过的操作。这组安全服务又分为
防发送方抵赖,防止信息发送者否认发送过信息;防递交方抵赖,防止信息接收者否认接收过信息;公证,
通信双方互不信任,但对第三方绝对信任,于是依靠第三方证实已发生过的操作。


0.2 安全机制 security mechanism
安全机制就是用于实现安全服务的方法,一项安全服务可能需要多种安全机制结合才能够完成,而一项安
全机制也可以同时存在和服务于多个安全服务中。


0.3 安全策略 security policy 
提供安全服务的一套准则。一个完全的安全策略不仅仅包括在技术上所需要实现的输血安全模型和理论基
础,还包括技术规则,管理规则以及更广泛的行政手段。


0.4 一些基本概念
前面提到了想到多的安全理论概念,不一一赘述,只在这里对一些重要的概念作个浅薄的解释。

0.4.1 主体 Subject
引起信息(在客体之间)流动的对象。 主体是数据的原发因素,也是在整个数据生命周期之间具有引导性
和控制性的对象,常见的主体对象比如 用户,用户进程 或 用户控制的其它数据源发点 等等。

0.4.2 客体 Object
客体,直观的说来,就是数据 或 数据的载体。例如 用户数据,E-Mail,或是存放着这些数据对象的
媒介,例如 文件,文件系统对象 和 磁盘 等(逻辑/物理)设备。

0.4.2 粒度 Grained
就是访问控制机制中,对主体或客体对象的访问控制范畴,访问控制力度的大小,意味着相应安全策略的
严密性,例如acl方式实现了粒度到用户的控制方式,实现粒度就比权限矩阵模型要更细小。

可信任计算基 Trusted Computing Base (TCB)
TCB是一种实现安全策略的机制,一个完整的TCB系统包括硬件、固件和软件,并且根据某种安全策略来
处理主体 对客体 的访问。

0.4.4 安全审计 security audit 
为了测试出系统的控制是否足够, 为了保证与已建立的策略和操作堆积相符合, 为了发现安全中的漏洞,
以及为了建议在控制、策略和堆积中作任何指定的改变, 而对系统记录与活动进行的独立观察和考核。
审计模块在整个操作系统安全框架中必须出于一个单向独立的位置,以避免主体对审计跟踪事件的篡改
和干扰,确保审计的独立性和公正性。

0.4.5 安全审计跟踪 security audit trail 
在系统运行过程中收集起来并可用来使安全审计易于进行的数据。


0.5 一些安全标准
安全标准意味着我们实际所使用的系统需要达到的高度,或者说在对应级别上应该实现的安全服务或机制。
这些年来,最流行和通用的标准主要有以下这些:

0.5.1 ISO 7489-2
开放互联安全模型,对应于OSI 7层网络模型的理论安全框架,定义了一系列的基本安全框架,以及网络
各层上确保安全所应该完成的安全服务 和 对应的安全机制。

0.5.2 DOD TCSEC
美国国防部定义的可信任计算机安全标准,后来TCSEC和它的各种衍生版本实质上成为了流通范围最广也
延续时间最长的国际性安全标准。TCSEC提出的最重要的概念就是上一节中提到的TCB,而我们以前常常
听说的操作系统C1/C2安全级别,实际也都是TCB的实现级别。这里只简要介绍一下比较重要的两个安全
级别C2和B1。
C2要求实现的安全机制:
*自主访问控制
*身份鉴别
*安全审计
*TCB并发控制
*客体的安全重用
B1要求实现的安全机制:
在C2基础上增加
*机密性
*完整性
*强制访问控制

0.5.3 CC/EAL
Common Criteria 通用评估准则,是TCSEC标准之后新的安全系统评估准则,也是目前和未来将要流通
的操作系统安全准则。 CC是一个更广泛意义上的信息安全评估准则,因此它的包含方面比TCSEC广泛得多,
也不仅仅包含操作系统安全一方面。其中 EAL是操作系统方面的评估子项,未来我们将更多的听到,某个
操作系统得安全级别达到了CC || EAL 3/4 这样的说法。 (一般简单的意义上,目前从安全机制定义上
说,TCSEC C2基本等于 CC EAL 4)

0.5.4 POSIX .1e
POSIX系列标准(IEEE 1003)并非一个通用的国际标准,但是由于POSIX和Unix系统的紧密关系,所以
Posix系列文档成为了事实上的工业标准。Posix并非一个强制推定的规定,但是和以上几个理论标准不
同,Posix .1e/2c很实际的制定了一系列对应与安全服务和机制的 系统架构,应用API,以及二进制
兼容指令。在Posix .1e/2c中定义实现的几类安全机制有:
扩展信息标记 EL
文件访问控制表 ACL
强制访问控制(机密性保护)  MAC:MLS
强制访问控制(完整性保护)  MAC:Biba
事件审计  Audit

0.6 C2 (我们的目标)
最后,我们的目标就是在Solaris系统基础上构建一个达到C2安全级别的安全操作系统。因此,我们至少
要实现一下安全机制:

认证: 标识(Identify)和鉴别(Authenticate)。标识是辨明一个对象的身份;鉴别是证明该对象的身
份就是其声明的身份。举个例子,在Unix系统中,用户名和UID的唯一对照就是识别的功能,使用UID来
确认用户的唯一身份;而用户名和密码联用进行系统登陆认证的过程,就是鉴别机制。
除了上面所说的Unix基本认证方式以外,Solaris还支持PAM扩展认证方式,PAM支持以模块化的方式实
现认证方法,然后按照一定的认证策略(/etc/pam.conf)来实现更为灵活和可扩展的用户认证。
(因为下面这一节主要讲BSM,在这里不再详述,参见<> p1.4 PAM认证方式)

访问控制: 在Solaris系统中,主要的访问控制方式有传统的Unix权限矩阵和facl两种方式,主体对象为
用户或用户进程,而最常见的客体对象就是文件。在只使用传统权限模式的情况下,Solaris只能达到C1
安全级别,当使用facl ( setfacl(8)和getfacl(8))时才能达到C2安全级别;如果要实现更高的安全
级别(B1)的话,必须使用Sun的另一个产品TrustedSolaris了,在这个系统中增加了类型裁决(TE)和
强制访问控制:多级安全模型(MAC:MLS) 两种措施。
(具体参见<> p1.5.1基础文件权限 和 p1.5.3 facl)

审计: 在传统的Unix系统中,并没有独立的内核级审计措施。而系统管理员们也一直是通过Syslog和
accton等传统日志来实现审计功能的。为了达到C2安全级别,Solaris系统按照Posix .1e标准实现
了一个独立的安全审计模块BaseSecurityModule (BSM),BSM默认在系统中不启用,在下面一节我们
主要对BSM的特性和使用进行说明。

在一个典型的安全操作系统中,我们可以画出这样一个安全模型图:

                       -----------------------------------
                       |                  访问控制决策单元 |    
                       |      ========                   |   
                       |      |  授   |                  |
                       |      |  权   |                  |
[安全管理员]  <------>  |      |   数   |                  |
                       |      |  据   |                  |
                       |      |  库   |                  |
                       |      ========                   |
                       |          ^                      |
                       |          |                      |
               -----------|-----------------------
                                  |
                                  |                  ||
                ||                v                  ||
                ||          ==============           ||
        ||        ||           ||          ||
[用户]    --------||------>>  || 引用监控器 ||  =========||======>>  [[客体对象.文件]]
        ||          ||           ||          ||
                ||          ==============           ||
                ||                |                  ||
        ||                |                  ||
        <身分鉴别>             |               <访问控制>
                                  |
        |              |                   |               
        |              |                   |
        |              |                   |
        +-----------------+-------------------|
                         |||
                 |||
                 V
                [[ 审计子系统 ]]



2.3.1 审计系统概念
审计(audit)是对影响系统安全的各种活动进行记录并为系统安全员提供安全管理依据的程序模块。作为一个
独立的安全模块,审计子系统是安全操作系统不可缺少的一部分,并对系统中发生的各种安全事件作一个单向
收集,已备日后分析和查证。

在传统的Unix中,最常见的具有审计功能的功能子系统是syslogd,系统管理员更够自己定义一系列的配置,
有系统内核和应用程序自主的发出告警信息,并有syslogd进程记录在文件或设备中,已被日后查证。这种方
式的缺点是显而易见的,只能进行很粗粒度的事件审计;并且由于事件都是由用户自己定义,所以并不可靠;
由于syslogd把安全事件和系统其他的各种进程事件存放在一起,所以进行审计时也非常困难。syslog不是
一种专业、专用的审计系统。
(参见<> p1.6.2)

Unix另一种可以用作审计用途的是acct功能,acct本身最早是用于系统资源记账的一种附加日志措施,但是
同时也具有对用户执行命令进行审计的功能。acct可以自动的监控用户所执行的每一条命令(以一个完整可执
行文件为单位),并把它和相关的运行时系统信息记录在案,日后可以使用lastcomm命令进行察看,或者使用
sar进行记账分析。
acct用于审计功能的缺陷,首先,acct审计的粒度还是太大,只能都到达进程级别;其次acct不是专用的审
计措施,因此需要对系统相当熟悉的管理员手动分析才能得出可靠结果,并且acct的审计信息不是很可靠,存
在被销毁和篡改的可能;最后,acct的应用对于系统资源的消耗非常大,需要耗费较多的cpu和磁盘资源,因
此acct不适合开启在需要运行较多进程的系统上,例如E-Mail服务器。
(参见<> p1.6.3)

在Solaris系统中,为了达到更高的安全级别,我们就必须启用系统的独立安全审计模块:BSM。
BSM作为内核安全审计模块,对系统事件的敏感度和准确性都相当高,可以根据用户需求进程状态,登录信息甚
至系统调用 进行细粒度的详细审计,并且用于日后分析;但是正因为这样BSM的缺点也非常明显,最重要的一条
就是会占用比较多系统资源,因此不适合在负荷较重或资源紧缺的系统上开启。


2.3.2 审计系统现状
上面说了那么多理论和概念,我自己都累了,这里先休息一下,讲讲其他系统中安全审计子系统的现状。

Sco OpenServer/ Unixware:
虽然Sco系统的其他部分都很早糟糕,但我们不不承认,在安全方面Sco系统还是有很好的实现的,例如很好的
实现了基于角色的访问控制(RBAC),系统内建的内核级审计子系统等等。在系统中,auth角色用于进行认证和
审计事件的管理,并且系统内置了许多系统审计事件。

Linux:
到目前为止,Linux系统中并没有出除了syslog和acct以外的独立的安全审计子系统,所以到目前为止Linux
都没有实现Posix 1e规范,并且也注定了Linux无法达到C1以上的安全级别。虽然有一些开发者对Linux添加
了各种安全加强实现例如SELinux等,但直至今天Linux还是没有完成Posix 1e audit.

Windows2000:
虽然在安全性方面win2000一直为人所诟病,但是我们不可否认,除了应用程序方面的安全问题更多一点以外,
在win2000的内核里跑着的是一个相当优秀的安全模型,甚至在很大程度上超越了传统的Unix系统。实现了进程
权能控制和内核事件审计等优秀功能,并且具有相当好的灵活性,稳固性和扩展性。关于我们的主题:审计子系统
已经是Win2000内核的一部分了。但是默认情况下没有开启,如果你有需求,可以在控制面板=>本地安全策略=>
审计 中开启几种特定类型事件的审计功能。

FreeBSD:
基础的FreeBSD和Linux一样,没有独立的审计子系统。不过幸运的是,一个从99年开始开发的FreeBSD内核
安全框架项目TrustedBSD,已经把Audit纳入了开发计划以内,预计将会在2003年3季度正式合并到FreeBSD
5.* Current的代码树中,目前也可以在网络上通过CVS同步TrustedBSD Audit Project。


2.3.3 Solaris审计系统实现
在Solaris 2.3之后的系统中,BSM就是Solaris初始化系统的一部分了,因此你只要安装了Solaris系统,BSM
默认就已经存在于你的系统内了。系统中至少需要一下包:
SUNWcar - Core architecture
SUNWcsr - Core SPARC
SUNWcsu - Core SPARC
SUNWhea - Header files
SUNWman - Online manual pages

安装完毕之后,BSM包含四部分:
二进制程序: /usr/sbin/*audit*
配置文件和初始化脚本: /etc/security/*
日志文件: /var/audit
启动脚本: /etc/rc2.d/S99audit

最后的启动脚本系统中默认不存在,只有在手工开启BSM之后才会建立。


2.3.4 BSM部署
只要明白了审计的概念,开启BSM进行系统事件审计就是一件非常轻松的工作了,不过有两个前置条件需要满足:
a.系统EEPROM安全级别必须设为1 以上,也就是设置需要口令,这主要是针对Sparc平台设定的,因为BSM的
应用是为了提高到C2安全级别,而C2级别不仅对系统,而且对硬件和固件的安全也有相当高的要求
(btw:严格意义上说,如果不满足硬件安全措施的话,Intel体系的操作系统是不可能达到C2以上级别的)
b.需要禁用系统volmgr,也就是移动卷管理,原理同上,是为了提供更高的安全性。
实际上,既使你不满足这两个条件,同样可以正常开启BSM功能,只不过在运行初始化脚本是会得到一个警告提示。

完成准备工作后,我们只要简单的执行如下两条命令就可以开启BSM:
===
# init 1            (重新引导或改变运行级别到单用户状态)
#/etc/security/bsmconv        (运行BSM初始化脚本,开启审计功能)

# reboot            (重新启动系统,或者Ctrl+D改变到多用户状态)

===
现在,当重新启动系统的最后步骤,你可以在终端上看到BSM服务启动的状况,同时会显示默认审计的时间数目。

如果要关闭BSM审计功能的话,同样也很简单:
===
# init 1
# /etc/security/bsmunconv

# reboot
===


2.3.5 BSM配置
在默认的情况下,BSM也能够良好的工作,当然如果你有特殊需求的话,可以根据你的实际系统情况进行优化或
配置,在这里只列出若干配置文件的功能:

BSM所有的配置文件都存放在/etc/security目录下( (4)代表详细信息察看man (4) ):
audit_class(4)
审计类别定义

audit_control(4)
审计进程控制信息

audit_data(4)
审计进程当前信息

audit.log(4)
审计日志格式

audit_event(4)
时间定义到类别的映射文件

audit_user(4)
按用户审计时的用户定义文件


除了上面的配置文件之外,系统中还有一些用于BSM管理的脚本。
audit_startup(1M)
启动BSM进程运行。 

auditconfig(1M)
读取配置文件,重新配置audit进程。

auditd(1M)
审计监控服务。

auditreduce(1M)
审计事件日志管理,可以调整日志格式,生成时间周期等信息。

auditstat(1M)
先是内核审计进程状态。

bsmconv(1M)
开启BSM功能。

bsmunconv(1M) 
关闭BSM功能。

praudit(1M)
打印BSM审计日志内容。


2.3.6 BSM应用
在默认配置情况下,BSM每天(24小时)会生成一个以当天日期为名字的审计日志,存放在/var/audit目录下,
这个文件具有自己的数据结构,所以直接查看时是乱码,必须使用系统命令 praudit来查看。

# praudit /var/audit/xxxxxx.xxxxxx.log


另一个可能用到的命令是auditreduce ,这个命令允许管理员对审计日志做一些设置,例如调整审计事件集
或 调整审计日志生成周期等等。

auditreduce和praudit是系统中BSM管理最基本的两个命令,组合起来可以完成相当多的功能:

用管道联合两个命令,会显示系统中所有的历史审计事件。
# auditreduce | praudit

再加上lp,将把所有审计事件直接打印出来。
# auditreduce | praudit | lp

如果系统中有相当多的审计信息的话,查找将是非常困难的事情,这条命令可以按照yymmdd的时间格式显示
目标时间段内的审计事件,范例为显示April 13, 1990, 用户fred的 登录类别 审计事件集。
# auditreduce -d 900413 -u fred -c lo | praudit

过滤目标时间所有的登录日志信息(Class:lo),并且输出到一个单独的日志文件中:
# auditreduce -c lo -d 870413 -O /usr/audit_summary/logins 

auditreduce的 -b 和 -a 选项允许用户按照 yyyymmdd00:00:00 的时间格式制定一个时间段(Before & After)。
# auditreduce -a 91071500:00:00 | praudit 
# auditreduce -b 91071500:00:00 | praudit 


2.3.7 其他
前面讲述了BSM的基本应用和管理,Solaris关于这方面的功能也的确少得可怜,至于怎么灵活运用,还是等熟
悉了那两条基本命令之后自己写脚本吧。当然网络上也有一些范例脚本可以参照的。

最后介绍两个有用的管理工具:

eXpert-BSMTM
一个很强大的商业BSM分析工具,不过目前也可以免费使用,支持Solaris 7/8 (Sparc|Intel)平台,可以在
下面地址下载。


Sun WBEM
Solaris内置的图形界面管理工具,也就是AdminConsole,在WBEM 2.3之后的版本支持对BSM信息的管理。
可以用下面命令开启:
# /usr/sadm/bin/wbemadmin              (第一次运行时会安装一系列的管理脚本)
# /usr/sadm/bin/smc               (开启管理终端)


参考信息:
auditconfig(1M),          auditd(1M),         audit_startup(1M),  audit.log(4),  
audit_control(4),  attri-butes(5),    bsmconv(1M),        praudit(1M)

SunSHIELD Basic Security Module Guide

阅读(1967) | 评论(0) | 转发(0) |
0

上一篇:grep,egrep,fgrep用法

下一篇:V440无法启动

给主人留下些什么吧!~~