Linux–系统安全及应用(一)(账号安全控制)

文章目录


一、账号安全控制

  • 用户账号,是计算机使用者的身份凭证或标识,每一个要访问系统资源的人,必须凭借其用户账号才能进入计算机
  • linux 系统中,提供了多种机制来确保用户账号的正当、安全使用

1.基本安全措施

1.1 系统账号清理

  • 在 Linux 系统中,除了用户手动创建的各种账号之外,还包括随系统或程序安装过程而生成的其他大量账号
  • 除了超级用户 root 之外,其他大量账号只是用来维护系统运作、启动或保持服务器进程,一般是不允许登录的,因此也称为非登录用户
  • 为了确保系统安全,这些系统的登录 shell 通常是 /sbin/nologin,表示禁止终端登录,应确保不被人为改动
grep "/sbin/nologin$" /etc/passwd
#查看

usermod -s /sbin/nologin 用户名
#将非登录用户的 shell 设为 /sbin/nologin
12345
  • 各种非登录用户中,还有相当一部分是很少用到的,这些账号可以视为冗余账号,直接删除即可
  • 除此之外,还有一些随应用程序安装的用户账号,若程序卸载以后未能自动删除,则需要管理员手动进行清理
userdel -r 用户名
#删除用户及其宿主目录
12
  • 对于 Linux 服务器中长期不用的用户账号,若无法确认是否应该删除,可以暂时将其锁定(passwd、usermod 命令皆可用来锁定、解锁账号)
usermod -L 用户名
#锁定用户账号
passwd -l 用户名
#锁定用户密码,锁定的用户将无法再登录系统
passwd -S 用户名
#查看账号状态(是否被锁定)
usermod -U 用户名
#解锁用户账号
12345678
mark
  • 如果服务器中的用户账号已经固定,不再更改,还可以采取锁定账号配置文件的方法
chattr +i /etc/passwd /etc/shadow
#锁定文件
lsattr /etc/passwd /etc/shadow
#查看为锁定的状态
chattr -i /etc/passwd /etc/shadpow
#解锁文件
lsattr /etc/passwd /etc/shadow
#查看为解锁的状态
12345678
mark

注:在账号文件被锁定的情况下,其内容不允许变更,因此无法添加、删除账号,也不能更改用户的密码、登录 Shell、宿主目录等属性信息

1.2 密码安全控制

  • 在不安全的网络环境中,为了降低密码被才出或被暴力破解的风险,用户应养成定期更改密码的习惯,避免长期使用同一个密码
  • 管理员可以在服务器端限制用户密码的最大有效天数,对于密码已过期的用户,登录时被要求重新设置密码,否则将拒绝登录
  • 执行以下操作可将密码的有效期设为 30 天(chage 命令用于设置密码时限)
vim /etc/login.defs
...
PASS_MAX_DAYS 30
#该设置方法适用于新建的用户


chage -M 日期 用户
#设置用户密码有效期
chage -E xxxx-xx-xx
#设置过期日期
例:
chage -M 30 xcf
#该设置方法适用于已存在的用户
12345678910111213
mark
mark
  • 在某些特殊情况下,如要求批量创建的用户初次登录时必须自设密码,根据安全规划统一要求所有用户更新密码等,可以由管理员执行强制策略,以便用户在下次登录时必须更改密码
  • 执行以下操作可强制要求用户再下次登录时重设密码
chage -d 0 用户名
#强制在下次登录时修改密码
cat /etc/shadow | grep 用户名
#第三个字段会被修改为 0
1234

1.3 命令历史限制

  • Shell 环境的命令历史机制为用户提供了极大的便利,但另一方面也给用户带来了潜在的风险
  • 只要获得用户的命令历史文件,该用户的命令操作过程将会一览无余,如果层间在命令行输入铭文的密码,则无意之中服务器的安全壁垒又多了一个缺口
  • 在 Bash 终端环境中,历史命令的记录条数由变量 HISTSIZE 控制,默认为 1000 条
  • 通过修改 /etc/profile 文件中的 HISTSIZR 变量值,可以影响系统中的所有用户
#编辑全局变量配置文件,适用于新登录用户
vim /etc/profile
...
export HISTSIZE=200
#设置最多只记录 200 条历史命令


. /etc/profile
#使 /etc/profile 内的命令重载一遍
history
#只能查看 200 条历史记录了

export HISTSIZE=200
#适用于当前用户
#查看历史篇幅太长,这里不再贴图展示
123456789101112131415
  • 也可以修改用户宿主目录中的 ~/.bashrc 文件,添加清空历史命令的操作语句
vim ~/.bashrc

...
echo " " > ~/.bash_history


init 6
#重启虚拟机以待测试
...
...
history
1234567891011
mark
mark

1.4 终端自动注销

  • 在 Bash 终端环境中,还可以设置一个闲置超时时间,当超过指定的时间没有任何输入时即自动注销终端,这样可以避免当管理员不在时其他人对服务器的误操风险
  • 闲置超时由变量 TMOUT 来控制,默认单位为秒
#编辑全局变量配置文件
vim /etc/profile
...
export TMOUT=600       #输出闲置超时变量
#600s为10min
. /etc/profile
#执行该文件内命令后生效
1234567

2.用户切换与提权

  • 大多数 Linux 服务器并不建议用户直接以 root 用户进行登录
  • 一方面可以大大减少因为误操作而导致的破坏,另一方面也降低了特权密码在不安全的网络总被泄露的风险
  • 鉴于这些原因,需要为普通用户提供一种身份切换或权限提升机制,以便在必要时执行管理任务

2.1 su 命令——切换用户

  • 使用 su 命令,可以切换为指定的另一个用户,从而具有该用户的所有权限
  • 当然,切换时需要对目标用户的密码进行验证(从 root 切换为其他用户时除外)
su -root
#若当前登录的为其他用户,需要切换为 root 用户
#需输入 root 用户的密码,验证成功后即可成功获得 root 权限
123
  • 上述命令操作中,选项“-”等同于“–login”或“-l”,表示切换用户后进入目标用户的登录 Shell 环境,若缺少此选项则仅切换身份、不切换用户环境
  • 对于切换为 root 用户的情况,“root”可以省略
    mark
  • 默认情况下,任何用户都允许使用 su 命令,从而有机会反复尝试其他用户(如 root)的登录密码,带来安全风险
  • 为了加强 su 命令的使用控制,可以借助于 pam_wheel 认证模块,只允许极个别用户使用 su 命令进行切换
  • 实现过程如下:
gpasswd -a xcf wheel
#将授权使用 su 命令的用户添加到 wheel 组
grep wheel /etc/group
#确认 wheel 组成员

#修改认证配置
vim /etc/pam.d/su
...
auth            required        pam_wheel.so use_uid
#取消注释
...
1234567891011
mark
mark
mark
  • 可以看到,启用 pam_wheel 认证以后,未加入到 wheel 组内的其他用户将无法使用 su 命令,尝试进行切换时将会按照“拒绝权限”来处理,从而将切换用户的权限控制在最小范围内
关于 /etc/pam.d/su 配置文件的补充:
1.上图中标记的两行默认状态时开启第一行,注释第二行,此时允许所有用户使用 su 名
2.两行都注释即允许所有用户都能使用 su 命令,但 root 下使用 su 切换到其他普通用户需要输入密码
3.如果第一行不注释,则 root 使用 su 切换普通用户就不需要输入密码
4.pam_rootok.so 模块的主要作用是使 uid 为 0 的用户,即 root 用户能够直接通过认证而不用输入密码
5.如果开启第二行,表示只有root用户和wheel组内的用户才可以使用su命令
6.如果注释第一行,开启第二行,表示只有wheel组内的用户才能使用su命令
1234567
  • 使用 su 命令切换用户的操作将会记录到安全日志 /var/log/secure 文件中,可以根据需求查案
cat /var/log/secure
1

2.2 sudo 命令——提升执行权限

  • 通过 su 命令可以非常方便地切换为另一个用户,但前提条件是必须知道目标用户的登录密码
  • 对于生产环境中的 Linux 服务器,每多一个人知道特权密码,那么其安全风险也就增加一份
  • 那么,有没有一种这种的办法,既可以让普通用户拥有一部分管理权限,又不需要将 root 用户的密码告诉他呢,这就是 sudo 命令,可以提升执行权限
  • 不过需要管理员预先进行授权,指定允许哪些用户以超级用户(或者其他普通用户)的身份来执行哪些命令

2.2.1 添加授权

  • sudo 机制的配置文件为 /etc/sudoers,文件的默认权限为 440,需使用专门的 visudo 工具进行编辑,虽然也可以用 vim 进行编辑,但保存时必须执行“:wq!”来强行操作,否则系统将提示为只读文件而拒绝保存
visudo
或
vim /etc/sudoers
123
  • 授权配置主要包括用户、主机、命令三个部分,即授权那些人在哪些主机上执行哪些命令
  • 各部分具体含义如下
用户(user):授权的用户名,或采用“%组名”的形式(授权一个组的所有用户)
主机(MACHINE):使用此配置文件的主机名称,此部分主要是方便在多个主机间公用同一份 sudoers 文件,一般设为 localhost 或实际的主机名即可,ALL 代表所有主机
命令(COMMANDS):允许授权的用户通过 sudo 方式执行的特权命令,需填写命令程序的完整路径,多个命令之间以逗号“,”进行分隔
123
  • 典型的 sudo 配置记录中,每一行对应一个用户或组的 sudo 授权配置
  • 例如,授权用户能够执行 ifconfig 命令来修改 ip 地址,而 wheel 组的用户不需验证密码即可执行任何命令
  • 另外有个好习惯,记得先查询一下完整路径
which ifconfig
1
mark
visudo
#按“G”,跳转至最后一行
xcf01 localhost=/sbin/ifconfig
%wheel ALL=NOPASSWD:ALL
#添加以上两行
#如果是 vim /etc/sudoers 需要“wq!”才能正常保存退出
#配置行过长,不再贴图演示
1234567
su xcf
#切换到用户 xcf
sudo ifconfig ens33:0 192.168.126.22
#设置虚拟网卡
ifconfig
#检查
exit
#回到 root
12345678
mark
  • 当使用相同授权的用户较多,或者授权的命令较多时,可以采用集中定义的别名
  • 用户、主机、命令部分都可以定义为别名(必须为大写),分别通过 User_Alias(用户别名)、Host_Alias(主机别名)、Cmnd_Alias(命令别名) 来进行设置
useradd xcf02
useradd xcf03
echo '123123' | passwd --stdin xcf02
echo '123123' | passwd --stdin xcf03
#新建两个用户用作测试

visudo
...
...
User_Alias USERS=xcf02,xcf03
#用户别名
Host_Alias HOSTS=localhost,xcf01,xcf02
#主机别名
Cmnd_Alias CMNDS=/sbin/*!/sbin/reboot,!/sbin/poweroff,!/sbin/init,!/shutdown
#命令别名
USERS HOSTS=CMNDS
#调用别名
#让用户 xcf02 和 xcf03 执行 /sbin/ 目录下除了 reboot、poweroff、init、shutdown 以外的其他所有命令程序
123456789101112131415161718
#sudo 配置记录的命令部分允许使用通配符“*”、取反符号“!”
#当需要授权某个目录下的所有命令或取消其中个别命令时也别有用
12
mark
  • 默认情况下,通过 sudo 防止执行的操作并不记录
  • 若要启用 sudo 日志记录以备管理员查看,应在 /etc/sudoers 文件中增加“Defaults logfile”设置
visudo
...
...
Defaults logfile="/var/log/sudo"   #将该命令添加至最后一行:wq保存并退出即可
1234

2.2.2 通过 sudo 执行特权命令

  • 对于已获得授权的用户,通过 sudo 方式执行特权命令时,只要将正常的命令行作为 sudo 命令的参数即可
  • 由于特权命令程序通常位于 /sbin、/user/sbin 等目录下,普通用户执行时应使用绝对路径
  • 前文有过使用,这里不再贴图演示
  • 在当前会话过程中,第一次通过 sudo 执行命令时,必须以用户自己的密码(不是 root 用户或其他用户的密码)进行验证
  • 伺候再次通过 sudo 执行命令时,只要与前一次 sudo 操作的间隔时间不超过五分钟,则不再重复验证
  • 若要查看用户自己获得哪些 sudo 授权,可以执行以下命令,已授权的用户可以看到自己的 sudo 配置
su 用户名
sudo -l
12
  • 如果已启用 sudo 日志,则可以从 /var/log/sudo 文件中看到用户的 sudo 操作记录
tail /var/log/sudo 
1

3.补充:PAM 安全认证

  • PAM(Pluggable Authenticcation Modules),是 Linux 系统可插拔认证模块
  • Linux 系统使用 su 命令存在安全隐患,默认情况下,任何用户都允许使用 su 命令,从而有机会反复尝试其他用户(如 root)的登录密码,带来安全风险
  • 为了加强 su 命令的使用控制,可以借助于 PAM 认证模块,只允许极个别用户使用 su 进行切换

3.1 PAM 及其作用

  1. PAM 是一种高效而且灵活便利的用户级别认证方式,它也是当前 Linux 服务器普遍使用的认证方式
  2. PAM 提供了对所有服务进行认证的中央机制,适用于 login,远程登录(telnet,rlogin,fsh,ftp),su 等应用程序
  3. 系统管理员通过 PAM 配置文件来指定不同应用程序的不同认证策略

3.2 PAM 认证原理

  1. PAM 认证一般遵循的顺序:Service(服务)→ PAM(配置文件)→ pam_*.so
  2. PAM 首先要确定哪一项服务,然后加载相应的 PAM 配置文件(位于 /etc/pam.d 下),最后调用认证文件(位于 /lib/security 下)进行安全认证
  3. 用户访问服务器的时候,服务器的某一个服务程序把用户的请求发送到 PAM 模块进行认证,不同的应用程序所对应的 PAM 模块也是不同的
  4. 如果想查看某个程序是否支持 PAM 认证,可以用 ls 命令进行查看
ls /etc/pam.d | grep su
#查看su是否支持PAM模块认证
12
mark

3.3 PAM 认证的构成

  • 每一行都是一个独立的认证和过程,它们按从上往下的顺序依次由 PAM 模块调用
  • 每行都有三个分区:认证类型、控制类型、PAM 模块、PAM 模块参数
cat /etc/pam.d/su
1

mark
第一列:PAM 有以下四种模块类型,分别代表四种不同的任务

认证模块类型作用
auth对用户身份进行识别,如提示输入密码,判断是否为 root
account对账号各项属性进行检查,如是否允许登录系统,帐号是否已经过期,是否达到最大用户数等
password使用用户信息来更新数据,如修改用户密码
session定义登录前以及退出后所要进行的会话操作管理,如登录连接信息,用户数据的打开和关闭,挂载文件系统

第二列:PAM使用控制类型来处理和判断各个模块的返回值

控制类型作用
required需要返回一个成功值,如果返回失败,不会立刻将失败结果返回,而是继续进行同类型的下一验证,所有此类型的模块都执行完成后,再返回失败。该行以及所涉及模块的成功是用户通过鉴别的必要条件
requisite与 required 类似,但如果此模块返回失败,则立刻返回失败并表示此类型失败
sufficient如果此模块返回成功,则不管后面的验证,直接向程序返回成功,表示验证通过,如果返回失败,则可以看成 optional(慎用)
optional不进行成功与否的返回,一般不用于验证,只是显示信息(通常用于 session 类型);不管成功、失败,继续下一模块的验证,且此模块的服务也能享用
include表示在验证过程中调用其他的 PAM 配置文件;比如很多应用通过完整调用 /etc/pam.d/system-auth(主要负责用户登录系统的认证工作)来实现认证而不需要重新逐一去写配置项

第三列:代表PAM模块,默认是在/lib64/security/目录下,如果不在此默认路径下,要填写绝对路径
第四列:代表PAM模块的参数,这个需要根据所使用的模块来添加

3.4 PAM 认证类型

  1. 认证管理:
    接收用户名和密码,进而对用户的密码进行认证
  2. 账户管理:
    检查账户是否被允许登录,账号是否已经过期,账号的登录是否有时间段的限制等
  3. 密码管理:
    主要是用来修改用户的密码
  4. 会话管理:
    主要是提供对会话的管理和记账

3.5 PAM 控制类型

控制类型也可以称作 Control Flags,用于 PAM 验证类型的返回加过

  1. required 验证失败时仍然继续,但返回 Fail
  2. requisite 验证失败则立即结束整个验证过程,返回 Fail
  3. sufficient 验证成功则立即返回,不再继续,否则忽略结果并继续
  4. optional 不用于验证,只是显示信息(通常用于 session 类型)
    mark

原创文章,作者:Zhu, Yuanyuan,如若转载,请注明出处:https://www.yidc.net/archives/7690