Linux安全应用指导培训资料.docx
《Linux安全应用指导培训资料.docx》由会员分享，可在线阅读，更多相关《Linux安全应用指导培训资料.docx（46页珍藏版）》请在冰豆网上搜索。
Linux安全应用指导培训资料
华为技术有限公司内部技术指导
DKBA8328-2015.11
Linux安全应用指导
华为技术有限公司
HuaweiTechnologiesCo.,Ltd.
版权所有XX
Allrightsreserved
修订声明Revisiondeclaration
本指导拟制与解释部门：
网络安全能力中心
本指导的相关系列规范或文件：
相关国际规范或文件一致性：
替代或作废的其它规范或文件：
无
相关规范或文件的相互关系：
无
简介
随着公司业务发展，越来越多的产品被公众所熟知，并成为安全研究组织的研究对象、黑客的漏洞挖掘目标，产品的安全问题不可小视。
公司内许多产品使用Linux系统作为软件开发和安装的基础，由于对Linux系统中编译器、软件服务、系统自身防护等方面缺乏足够的了解，使产品存在许多安全漏洞，产品也因此遭受黑客的攻击。
《Linux安全应用指导》结合Linux系统中常用的安全机制安全特性同时结合业界最佳实践，针对业内普遍的Linux系统漏洞和软件漏洞给出指导方法，帮助产品开发团队减少由于设计过程中未引入安全机制或软件加固方法而引入安全风险。
本指导的制订目的是希望能指导读者选择正确的安全机制和软件加固方法，以减少安全漏洞的产生。
指导涵盖Linux系统中的：
权限管理、访问控制、认证、审计、文件系统保护、漏洞攻击防护等内容。
使用对象
本指导的读者及使用对象主要是产品涉及Linux系统的需求分析人员、设计人员、开发人员、测试人员等。
适用范围
本指导适合于公司涉及使用Linux操作系统的产品（嵌入式产品除外），如使用欧拉serverOS、suse等产品。
指导解释
Linux安全应用指导目的在于通过结合业内的最佳实践，对在Linux系统下合理的使用安全机制和安全特性来解决产品安全问题和增强系统安全能力提出要求。
其目的在于以下几点：
1.充分发挥Linux已有的安全能力。
2.将Linux社区中普遍使用的安全组件及解决方案吸纳进来，合理的应用到系统中，增强系统的安全能力。
3.为产品线安全人员解决Linux安全问题赋能。
用词约定
规则：
编程时必须遵守的约定。
建议：
编程时必须加以考虑的约定。
说明：
对此规则/建议进行必要的解释。
示例：
对此规则/建议从正面给出例子。
术语解释
名词
解释
MAC
强制访问控制（MandatoryAccessControl——MAC），用于将系统中的信息分密级和类进行管理，以保证每个用户只能访问到那些被标明可以由他访问的信息的一种访问约束机制。
DAC
自主访问控制（DiscretionaryAccessControl，DAC）是这样的一种控制方式，由客体的属主对自己的客体进行管理，由属主自己决定是否将自己的客体访问权或部分访问权授予其他主体，这种控制方式是自主的。
容器
容器是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。
PAM
PAM（PluggableAuthenticationModules）是由Sun提出的一种认证机制。
它通过提供一些动态链接库和一套统一的API，将系统提供的服务和该服务的认证方式分开，使得系统管理
员可以灵活地根据需要给不同的服务配置不同的认证方式而无需更改服务程序，同时也便于向系统中添加新的认证手段。
ASLR
ASLR（Addressspacelayoutrandomization）是一种针对缓冲区溢出的安全保护技术，通过对堆、栈、共享库映射等线性区布局的随机化，通过增加攻击者预测目的地址的难度，防止攻击者直接定位攻击代码位置，达到阻止溢出攻击的目的。
DEP
DEP（DataExecutionPrevention）是一套软硬件技术，能够在内存上执行额外检查以帮助防止在系统上运行恶意代码。
ACL
访问控制列表（AccessControlList，ACL）。
1权限管理
1.1权限最小化
1.1.1禁止直接使用root账号登录Linux系统
说明：
root是Linux系统中的超级特权用户，具有所有Linux系统资源的访问权限。
如果允许直接使用root账号登录Linux系统对系统进行操作，会带来很多潜在的安全风险，为了规避由此带来的风险，应禁止直接使用root帐号登录操作系统，仅在必要的情况通过其他技术手段（如：
su）间接的使用root账号。
禁止直接使用root账号登录可以规避很多潜在的安全风险，提高系统安全性。
此条目需满足以下要求：
✓禁止直接通过root账号远程登录系统（ssh远程登录）
✓禁止直接使用root账号本地标准终端登录（本地tty登录，如：
tty1、tty2等）
此条目对以下情况不做强制要求：
✓对于设备维护用串口不做强制要求，如console。
✓系统初始化和调测阶段不在规则范围内。
实施指导：
●禁止root账号本地直接登录
1）编辑root登录设备控制文件securetty
vi/etc/securetty
2）注释掉或删除所有标准终端设备（形如ttyN，如：
tty1、tty2等）
#tty1
#tty2
…
#ttyN
3）保存文件后root用户本地标准终端登录即被禁止
Login：
root
Password：
Loginincorrect
●禁止root账号远程直接登录
例：
修改openssh服务配置文件，禁止root账号远程直接登录
1）编辑openssh服务配置文件sshd_config
vi/etc/ssh/sshd_config
2）查找PermitRootLogin配置项（若不存在需添加），将其设置为No
PermitRootLoginNo
3）保存文件后，重新启动sshd服务
/etc/init.d/sshdrestart
1.1.2除有明确特权需求，应用程序应以非root账号运行
说明：
root权限是Linux系统中的超级特权用户，具有所有Linux资源的访问权限。
若自研程序或者第三方程序存在堆栈溢出漏洞，那么攻击者就可以利用漏洞植入任意代码，获取程序执行者的权限，进而控制整个系统。
因此，我们应该按照最小权限原则设计Linux系统权限，即使程序中存在堆栈溢出漏洞，由于被植入恶意代码的程序只有普通用户权限，无法对系统造成严重影响，攻击面大大降低。
实施指导:
比如一个程序在使用普通用户就可以正常运行的情况，就不应用root帐号运行，按照安全设计的最小权限原则，分析应用程序进程所需要的最小权限，无特权需求的程序禁止使用root运行。
实施方法如下：
root#useraddhuawei
su-user-cprogram
user代表用户名，program是程序名（这里要注意的是程序名要给决对路径）
1.1.3采用不同权限的帐号运行不同的应用并对帐号进行权限分离
说明：
在设计实现应用系统时，应根据各个组成部分（子系统或程序）运行所需的操作系统权限的不同以及暴露给用户的访问权限的不同，对其进行划分和授权，采用不同权限的帐号运行不同的程序或组成部分。
此条目需满足以下要求：
✓运行web服务的系统帐号不能和运行数据库的系统帐号是同一个帐号，并且要做访问的权限分离。
实施指导:
例如典型的WEB应用系统，由WEB系统和数据库系统组成，WEB系统对外提供访问服务，外部用户通过WEB服务获取页面相关的数据，这此页面数据敏感度相对低一些，而数据库系统一般存放业务相关的重要数据，敏感度高，通常会为两个系统建立不同的帐号和权限，并分配不同的目录来存放敏感度不同的数据。
对于WEB系统使用Apache服务器情况，会建立apache用户来运行httpd进程，限制httpd进程只能特定WEB文件、配置文件和日志数据，如var/www；同时，对数据库使用mysql的情况，也会为数据库建立专门的帐户mysql和相应的特权目录，让mysqld服务进程只能访问限定的目录，如var/lib/mysql。
通过这样的划分和授权，达到用不同的权限帐号运行不同的程序并实现了运行权限的分离。
1.1.4在运行时有特权需求的程序，在特权操作完后如后续无特权需求，必须使用setuid放弃特权
说明：
程序中有些任务必需使用root权限执行，当特权操作完成后并且后续无特权需求，应调用setuid（）函数放弃root用户的权利，使用普通用户权限运行程序。
需要注意的是一旦调用setuid（）函数放弃root用户的权利，在后续执行中这个进程就只能以普通用户的身份运行。
此条目需满足以下要求：
✓在程序启动时需要特权需求，启动完成后不需要特权需求的程序，需放弃特权。
实施指导:
#include
#include
#include
intmain（）
{
if（!
setuid（getuid（）））\\抛弃root权限,进入普通用户权限
{
printf（"setuidsuccessfully!
\n"）;
}else{
printf（"setuiderror!
"）;
perror（"setuid"）;
}
return0;
}
1.1.5使用sudo机制代替以root帐号登录运行特权程序的方式。
说明：
sudo可以使普通用户以特定的用户权限执行某些命令。
大部分系统管理命令都需要使用root权限执行，对于系统管理员来说，适当的对其它用户授权可以减轻系统管理员负担，但直接授予其它用户root用户密码会带来安全方面的风险，而使用sudo可以解决这一问题。
此条目需满足以下要求：
✓系统中的需要以root帐号执行的自开发程序，可以使用sudo机制避免使用root帐号登录。
实施指导:
下面看一个完整的例子：
$cat/etc/sudoers
为方便对允许使用sudo命令的用户分类，我们可以用户分组：
User_AliasNETWORK_MAINTAINERS=www,com
#定义NETWORK_COMMANDS可以运行网络接口配置命令
Cmnd_AliasNETWORK_COMMANDS=/bin/ifconfig,/bin/ping
#NETWORK_MAINTAINERS用户组可以用root身份运行NETWORK_COMMANDS中包含的命令
NETWORK_MAINTAINERSlocalhost=（root）NETWORK_COMMANDS
1.1.6应对允许使用su到root帐号的用户进行明确授权，非授权用户不能切换到root
说明：
su命令可以使一个一般用户拥有超级用户或其他用户的权限，它经常被用于从普通用户账号切换到系统root账号。
su命令为用户变更身份提供了便捷的途径，但如果不加约束的使用su命令，会给系统带来潜在的风险。
通过对用户su访问root账户的权力进行限制，仅对部分账号进行su使用授权，可以提高系统账号使用的安全性。
此条目需满足以下要求：
✓需建立su访问组，非组内帐号未无法使用su命令切换到root账号（包括在已知root口令的情况下）
实施指导：
●使用pam_limits模块限制suroot的访问组
例：
通过组成员限制能够su为root的用户
1）编辑pam的su配置文件
vi/etc/pam.d/su
2）查找authrequiredpam_wheel.so配置行（若不存在需添加），做如下设置：
authrequiredpam_wheel.sogroup=wheel
3）保存文件后，根据需要将su授权的账号加入wheel组即可。
usermod-a-Gwheeltestuser
这样，只有wheel组的用户可以su到root（执行su的用户仍需要知道root口令，但未被授权的用户即使知道root口令也无法通过su切换为root用户。
POSIX能力（pcap）是一种分散root用户权利的方式，使用POSIX可以对具有特权需求的程序进行授权访问。
在需要的时，通过POSIX可以把一项或几项特权赋予需要的程序。
因此，POSIX以授予最小的完成工作所需的权限的方式提供一个更安全的选择，坚持了最小权限的安全原则。
1.1.7使用POSIXCapabilities功能避免直接使用root权限
说明：
某个程序运行权限为root,但是可能并不需要root权限的全部能力，以ping命令为例，ping命令可能只需要cap_net_raw能力来发送ICMPping报文，对于root其它能力并不是必需的。
因此，只需要将cap_net_raw能力分配ping命令，这样普通用户就可以使用ping命令了。
使用setcap分配运行命令所需要的能力替换直接使用root。
此功能需要内核版本在2.6.13以上，并且xattr（扩展文件属性）功能在内核设置中被打开。
下表为setcap中提供的能力：
名称
值
解释
CAP_CHOWN
0
允许改变文件的所有权
CAP_DAC_OVERRIDE
1
忽略对文件的所有DAC访问限制
CAP_DAC_READ_SEARCH
2
忽略所有对读、搜索操作的限制
CAP_FOWNER
3
以最后操作的UID,覆盖文件的先前的UID
CAP_FSETID
4
确保在文件被修改后不修改setuid/setgid位
CAP_KILL
5
允许对不属于自己的进程发送信号
CAP_SETGID
6
允许改变组ID
CAP_SETUID
7
允许改变用户ID
CAP_SETPCAP
8
允许向其它进程转移能力以及删除其它进程的任意能力（只限init进程）
CAP_LINUX_IMMUTABLE
9
允许修改文件的不可修改（IMMUTABLE）和只添加（APPEND-ONLY）属性
CAP_NET_BIND_SERVICE
10
允许绑定到小于1024的端口
CAP_NET_BROADCAST
11
允许网络广播和多播访问
CAP_NET_ADMIN
12
允许执行网络管理任务：
接口、防火墙和路由等
CAP_NET_RAW
13
允许使用原始（raw）套接字
CAP_IPC_LOCK
14
允许锁定共享内存片段
CAP_IPC_OWNER
15
忽略IPC所有权检查
CAP_SYS_MODULE
16
插入和删除内核模块
CAP_SYS_RAWIO
17
允许对ioperm/iopl的访问
CAP_SYS_CHROOT
18
允许使用chroot（）系统调用
CAP_SYS_PTRACE
19
允许跟踪任何进程
CAP_SYS_PACCT
20
允许配置进程记帐（processaccounting）
CAP_SYS_ADMIN
21
允许执行系统管理任务：
加载/卸载文件系统、设置磁盘配额、开/关交换设备和文件等
CAP_SYS_BOOT
22
允许重新启动系统
CAP_SYS_NICE
23
允许提升优先级，设置其它进程的优先级
CAP_SYS_RESOURCE
24
忽略资源限制
CAP_SYS_TIME
25
允许改变系统时钟
CAP_SYS_TTY_CONFIG
26
允许配置TTY设备
CAP_MKNOD
27
允许使用mknod（）系统调用
CAP_LEASE
28
允许在文件上建立租借锁
CAP_SETFCAP
31
允许在指定的程序上授权能力给其它程序
实施指导:
参考设计样例中的《使用setcap避免直接使用root》方案
1.2文件和目录权限
1.2.1系统中禁止有无主文件存在
说明：
无主文件（和目录）是指属于没有匹配到任何用户的用户ID的文件。
通常管理员删除一个用户但是该用户在文件系统中尚有文件时会发生这种情况。
同样的情况也会发生在用户组上。
这些文件叫做未分组文件。
如果新用户分配到某个已删除用户的用户ID，新用户将能够访问某些原本无意访问的文件。
因此，应根据实际情况对其进行合理处理如删除、添加新的用户或用户组等。
实施指导：
可使用如下命令检查无主文件和未分组文件
root#find/\（-nouser-o-nogroup\）–print
1.2.2除有明确需求，应删除文件不必要的setuid和setgid位
说明：
非法带有setuid和setgid的可执行文件可能对系统造成威胁。
因此，建议对除必须要带SUID位的可执行文件进行检查，删除不必要可执行文件的setuid和setgid位。
必须要带SUID位的的可执行文件根据系统版本和配置不同会不同。
此条目需满足以下要求：
✓公司自主开发的软件/程序需遵守本条目（操作系统自带程序不做严格限制）。
实施指导：
可使用如下命令来显示setuid和setgid可执行文件：
root#find/-typef\（-perm-4000-o-perm-2000\）–print
显然，命令结果中会列出很多设置了setuid/setgid位的文件（例如/usr/bin/passwd文件）：
仔细确认文件列表并确认是否有必要设置该权限。
如果确定某可执行文件没有必要设置setuid位，使用以下命令将其删除：
root#chmod-sFILE
1.2.3应为系统用户设置缺省的umask值
说明：
umask设置了用户创建文件的默认权限。
一般在/etc/profile、$[HOME]/.bash_profile或$[HOME]/.profile中设置umask值。
因此系统必须设置Umask值，普通用户推荐值为022,超级用户推荐值为027。
如果用户希望创建的文件或目录的权限不是umask指定的缺省权限，可以修改缺省的umask值，然后再创建文件或目录。
实施指导：
$umask
查询默认的umask值
020
系统默认为020，更改为所希望的022
$umask022
$touchtestfile
创建文件
$ls-ltestfile
查看创建后的权限
rxwr-xr-xadminadmin786Nov1710:
45/home/testfile
1.2.4使用特殊属性位Sticky位对共享目录权限进行控制
说明：
Sticky位是Linux系统下的一种特殊文件属性位，可用于加强对文件的权限管理，合理的使用Sticky位属性，能够帮助提高文件和目录的安全性。
使用Sticky位对共享目录权限进行控制，可以防止共享目录中不属于自己的文件被恶意或无意删除。
在Linux系统下，最典型的共享目录为用于临时文件存取的/tmp和/var/tmp目录。
此条目需满足以下要求：
✓对/tmp和/var/tmp目录应设置Sticky位，确保用户（root除外）只能对自己建立的文件或目录进行删除/更名/移动等动作。
实施指导：
在Linux系统下，有一些特殊文件属性位用于加强对文件的权限管理，合理的使用这些特殊属性，能够帮助提高文件和目录的安全性。
使用Sticky位对共享目录权限进行控制，可以防止共享目录中不属于自己的文件被恶意或无意删除。
对不希望被修改的文件设置非可变位（Immutablebit），系统不允许对这个文件进行任何的修改。
如果对目录设置这个属性，那么任何的进程只能修改目录中已存在的文件，不能建立和删除文件。
对不允许修改历史内容的文件设置只追加位（Append-onlybit），系统只允许在这个文件之后追加数据，不允许任何进程覆盖或者截断这个文件。
如果目录具有这个属性，系统将只允许在这个目录下建立和修改文件，而不允许删除任何文件。
●设置sticky位
chmod+t/tmp
$ls-ld/tmpdrwxrwxrwt1rootroot786Nov1710:
45/tmp
注意：
rwt权限中t代表sticky和execute位。
如果显示的是T，那么只有sticky位置位了。
1.2.5利用特殊文件属性Append-only位保护系统命令行历史日志文件，防止内容被篡改
说明：
在Linux系统下，有一些特殊文件属性位用于加强对文件的权限管理，合理的使用这些特殊属性，能够帮助提高文件和目录的安全性。
对不允许修改历史内容的文件设置只追加位（Append-onlybit），系统将只允许在这个文件之后追加数据，不允许任何进程覆盖或者截断这个文件。
如果目录具有这个属性，系统将只允许在这个目录下建立和修改文件，而不允许删除任何文件。
此条目需满足以下要求：
✓对系统中的用户命令行历史日志文件（典型名称如：
.bash_history）设置只追加位（Append-onlybit），防止日志被篡改。
此条目对以下情况不做强制要求：
✓对命令行日志文件有定期截断或回滚需求的系统不做追加位（Append-onlybit）设置的强制要求。
实施指导：
●设置非可变位和只追加位
$sudochattr+aitest.txt
$lsattrtest.txt----ia----------test.txt
2访问控制
2.1自主访问控制
2.1.1使用POSIXACL进行更细粒度的访问控制
说明：
虽然Linux系统提供了文件控制机制，但是也具有一些局限性。
例如，一个目录只允许一个组访问。
POSIXACL提供了一种更加细粒度的访问控制机制，通过运用这种机制，文件系统对象可以为具体用户和组分配访问权限。
每一个文件系统对象都有一条对应的访问ACL，用于控制对该对象的访问。
此外，目录还可以包括一条缺省的ACL，该缺省ACL决定了本目录中创建的对象的首次访问ACL。
此功能需要内核版本2.6以上，并且内核开启POSIXACL、xattr功能。
此建议适用于提供对文件或目录的细粒度访问控制的情形，比如：
同一个用户组中的两个用户，对特定的文件或目录，需要设定一个用户拥有写的权限，而另一个用户只拥有只读权限。
此条目需满足以下要求：
✓对于特定的目录或文件仅允许特定的几个用户组或用户设置使用权限的情形，建议使用ACL进行细粒度的访问控制。
POSIXACL条目名称
解释
用法
ACL_USER_OBJ
所有者的访问权限
user:
:
ACL_USER
accessrightsofsomespecificuser,otherthantheowner
除所有者外，一些特定用户的访问权限
user:
USERNAME:
ACL_GROUP_OBJ
accessrightsofthegroupthatownsthefile
文件所属组的访问权限
group:
:
ACL_GROUP
accessrightsofsomegroupthatdoesn’townthefile
非文件所属组的访问权限
group:
GROUPNAME:
ACL_OTHER
accessrightsofanyonenototherwisecovered
所有没有覆盖用户的访问根限
other:
:
ACL_MASK
maximumpossibleaccessrightsfore
升级会员 