IT瘾linux推荐

接近九成 Windows 游戏能在 Linux 上运行

Wed, 29 Oct 2025 15:49:15 CST

根据 ProtonDB 的数据，近九成 Windows 游戏现在能在 Linux 上运行。这一进步受益于 WINE 和 Proton 翻译层开发者的努力，以及对 Steam Deck 等 Linux 掌机的兴趣。ProtonDB 将游戏分为五类：白金级游戏无需任何调整即可完美运行；金级游戏需要进行小的调整；银级游戏可玩但并不完美；Borked 级游戏完全无法运行；铜级游戏介于银级和 Borked 级之间。数据显示，白金级新游戏数量正在增长，而 Borked 级游戏数量则在减少。很多热门游戏不支持 Linux 主要是因为反作弊软件与 Linux 的不兼容性导致的。

保护核心资产: LINUX内核防护

Thu, 13 Jul 2023 20:48:51 CST

Shawn the R0ck 写道：操作系统内核常遭受的漏洞利用典型表现为内存污染、进程凭证窃取等。这些漏洞利用往往在操作系统内核内部甚至更深的地方发生，使得它们极为难以侦测和追踪。更加令人担忧的是，内核漏洞利用因其深入系统的最底层并具有最高级别的操作权限，所以其破坏力异常巨大。HardenedVault为Linux操作系统设计了Vault Exploits Defense (VED)作为其基础安全方案。内核级别的防护长期以来一直是网络空中挑战最为严峻的技术难题之一。然而，HardenedVault 利用创新的方式，实现了运行时的全面防护，Vault Exploits Defense (VED) 能有效地检测并阻止已知（Nday）和未知（0day）的 Linux 内核漏洞利用，而这些漏洞利用往往具备极大的破坏力，并且十分难以侦测。另一方面，消除一两个漏洞利用方法比硬编码的防御一堆0day漏洞利用更有价值。无论是已知或者未知(n-day/0-day)的漏洞都可以利用新的漏洞利用方法重新构造漏洞利用，这种数字军火的更替会使防御体系难以应对。因此，未公开的漏洞利用方法的危险程度远高于一堆0day漏洞。VED 经过数年的进化，其特性达到了在预防利用和利用阶段之间的效果，不仅对于绕过 Tetragon 或者 Pipe primitive 这类漏洞利用方法具备免疫能力，甚至一些常见的漏洞利用方法也会在早期被 VED 检测和阻止。对运行时和rootkits防护有兴趣的币圈，链圈，电商圈，X圈的朋友们可以尝试AWS的安全加固镜像（集成了基础长期维护版本的VED）。

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

Sat, 08 Jul 2023 12:01:28 CST

Load 就是对计算机干活多少的度量，Load Average 就是一段时间（1分钟、5分钟、15分钟）内平均Load。

一、Load分析：

情况1：CPU高、Load高

通过top命令查找占用CPU最高的进程PID；
通过top -Hp PID查找占用CPU最高的线程TID;
对于java程序，使用jstack打印线程堆栈信息（可联系业务进行排查定位）；
通过 printf %x tid打印出最消耗CPU线程的十六进制；
在堆栈信息中查看该线程的堆栈信息；

情况2：CPU低、Load高

通过top命令查看CPU等待IO时间，即 %wa；
通过 iostat -d -x -m 1 10查看磁盘IO情况；(安装命令 yum install -y sysstat)
通过 sar -n DEV 1 10查看网络IO情况；
通过如下命令查找占用IO的程序；

      ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

二、CPU高、Load高情况分析

使用 vmstat查看系统纬度的 CPU 负载；
使用 top查看进程纬度的 CPU 负载；

2.1、使用 vmstat 查看系统纬度的 CPU 负载

可以通过 vmstat 从系统维度查看 CPU 资源的使用情况

格式： vmstat -n 1 -n 1表示结果一秒刷新一次

      [root@k8s-10 ~]# vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1      0 2798000   2076 6375040    0    0    10    76   10   49  6  2 91  1  0
 0  0      0 2798232   2076 6375128    0    0     0   207 7965 12525  7  2 90  2  0

返回结果中的主要数据列说明：

r：表示系统中 CPU 等待处理的线程。由于 CPU 每次只能处理一个线程，所以，该数值越大，通常表示系统运行越慢。
b：表示阻塞的进程,这个不多说，进程阻塞，大家懂的。
us：用户CPU时间，我曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
sy：系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
wa：IO 等待消耗的 CPU 时间百分比。该值较高时，说明 IO 等待比较严重，这可能磁盘大量作随机访问造成的，也可能是磁盘性能出现了瓶颈。
id：处于空闲状态的 CPU 时间百分比。如果该值持续为 0，同时 sy 是 us 的两倍，则通常说明系统则面临着 CPU 资源的短缺。

常见问题及解决方法：
如果r经常大于4，且id经常少于40，表示cpu的负荷很重。
如果pi，po长期不等于0，表示内存不足。
如果disk经常不等于0，且在b中的队列大于3，表示io性能不好。

2.1、使用 top 查看进程纬度的 CPU 负载

可以通过 top 从进程纬度来查看其 CPU、内存等资源的使用情况。

      [root@k8s-10 ~]# top -c
top - 19:53:49 up 2 days,  7:57,  3 users,  load average: 0.76, 0.79, 0.58
Tasks: 282 total,   2 running, 280 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.4 us,  1.4 sy,  0.0 ni, 95.0 id,  1.2 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 12304204 total,  2800864 free,  3119064 used,  6384276 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  8164632 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
29884 root      20   0 5346580 929332  14556 S   0.0  7.6   6:19.19 /opt/jdk1.8.0_144/bin/java -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apach+
  875 root      20   0  729524 563424  38612 S   3.1  4.6  93:22.70 kube-apiserver --authorization-mode=Node,RBAC --service-node-port-range=80-60000 --advertise-address=10.68.7.162 --allow-privileged=true -+
 3870 nfsnobo+  20   0  910376 317248  22812 S   1.6  2.6  42:29.59 /bin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/prometheus --storage.tsdb.retention=1d --web.enable-life+

默认界面上第三行会显示当前 CPU 资源的总体使用情况，下方会显示各个进程的资源占用情况。

可以直接在界面输入大小字母 P，来使监控结果按 CPU 使用率倒序排列，进而定位系统中占用 CPU 较高的进程。最后，根据系统日志和程序自身相关日志，对相应进程做进一步排查分析，以判断其占用过高 CPU 的原因。

2.2、strace命令分析

https://oa.kedacom.com/confluence/pages/viewpage.action?pageId=77136289

三、CPU低、Load高情况分析

问题描述：
Linux 系统没有业务程序运行，通过 top 观察，类似如下图所示，CPU 很空闲，但是 load average 却非常高：

处理办法：

load average 是对 CPU 负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。
出现此种情况时，可能是由于僵死进程导致的。可以通过指令 ps -axjf查看是否存在 D 状态进程。
D 状态是指不可中断的睡眠状态。该状态的进程无法被 kill，也无法自行退出。只能通过恢复其依赖的资源或者重启系统来解决。

      等待I/O的进程通过处于uninterruptible sleep或D状态；通过给出这些信息我们就可以简单的查找出处在wait状态的进程
ps -eo state,pid,cmd | grep "^D"; echo "----"

- 查找占用IO的程序
ps -e -L h o state,cmd  | awk '{if($1=="R"||$1=="D"){print $0}}' | sort | uniq -c | sort -k 1nr

Linux 下如何查找木马并处理 - ericyuan - 博客园

Thu, 13 Apr 2023 22:41:24 CST

1、cat /etc/passwd 未发现陌生用户和可疑root权限用户。

2、netstat -anp 查看所有进程及pid号，未发现异常连接。

3、last 查看最近登录用户，未发现异常

4、cat /etc/profile 查看系统环境变量，未发现异常

5、ls -al /etc/rc.d/rc3.d ，查看当前级别下开机启动程序，未见异常（有一些脸生，只好利用搜索引擎了）

6、crontab -l 检查计划任务，root用户和web运行用户各检查一遍，未见任何异常

7、cat /root/.bashrc 和 cat /home/用户/.bashrc 查看各用户变量，未发现异常

8、查看系统日志。主要是/var/log/messages(进程日志)、/var/log/wtmp(系统登录成功日志 who /var/log/wtmp)、/var/log//bmtp(系统登录失败日志)、/var/log/pureftpd.log(pureftpd的连接日志)，未发现异常（考虑到了可能的日志擦除，重点看了日志的连续性，未发现明显的空白时间段）

9、history 查看命令历史。cat /home/用户/.bash_history 查看各用户命令记录，未发现异常

10、系统的查完了，就开始查web的。初步查看各站点修改时间，继而查看各站点的access.log和error.log（具体路径不发了），未发现报告时间前后有异常访问。虽有大量攻击尝试，未发现成功。

11、日志分析完毕，查找可能存在的webshell。方法有两个，其一在服务器上手动查找；其二，将web程序下载到本地使用webshellscanner或者web杀毒等软件进行查杀。考虑到站点较多，数据量大，按第一种方法来。在linux上查找webshell基本两个思路：修改时间和特征码查找。特征码例子：find 目录 -name "*.php"（asp、aspx或jsp） |xargs grep "POST[（特征码部分自己添加）" |more 修改时间：查看最新3天内修改的文件，find 目录 -mtime 0 -o -mtime 1 -o -mtime 2 当然也可以将两者结合在一起，find 目录 -mtime 0 -o -mtime 1 -o -mtime 2 -name "*.php" 的确查找到了一些停用的站点下有webshell

--------

查找全站关键字：“pack”、“eval”

linux下模拟一个木马程序运行过程

Thu, 13 Apr 2023 22:40:45 CST

预备知识：

将一个程序放入到后台，悄悄的执行

./xxx.sh &

进程：

用户进程：由用户来管理

系统进程：由系统内核自行管理

系统中的每个进程，都有一个位置的ID，这就是pid，而且每次启动进程以后，PID都不相同

进程相关的命令

jobs

作用：查看当前运行在后台的进程有哪些

信息

第一列：进程编号

第二列：进程状态

第三列：进程是如何发起的

fg 进程编号把进程从后台调到前台执行

kill %进程编号杀死进程

ps aux 打印系统所有进程

num=`ps aux | grep myser |wc -l` #执行grep myser本身就会创建一个进程，如果有myser这个进程则num为2,如果没有myser这个进程,则num为1,

kill作用杀死进程

格式：kill 信号级别进程PID

信号级别

-9：斩立决。立刻杀死进程

-15：死缓。等待现有的客户端处理完毕之后，立刻杀死进程

【等待期间新的用户请求无法被接入】

木马最终效果

让程序自动运行，而且是开机自动运行起来

程序还可以自我保护

防止程序文件被删除

实现步骤

1. 开发一个伪木马myser,位置：可以随便放，这里为了方便放在/下，实际使用时是放在非常隐蔽的目录下

#!/bin/bash

while true

touch /home/`date +%T`.txt #在/home/下每隔一秒就创建一个文件，文件名为创建时间.txt

sleep 1

done

创建完后赋权限 chmod +x myser

试运行 ./myser ctrl+c停止 cd到/home/目录下查看

2. 将这个木马设置为开机自动启动

在/etc/rc.local中写入

/bin/bash /myser &

3. 开发一个检查木马进程是否正在运行的程序,check.sh ,位置：可以随便放，这里为了方便放在/下，实际使用时是放在非常隐蔽的目录下

#!/bin/bash

num=`ps aux | grep myser |wc -l` #执行grep myser本身就会创建一个进程，如果有myser这个进程则num为2,如果没有myser这个进程,则num为1(),

if [ $num -eq 1 ];then #num为1则表示木马进程已被杀死，需重新启动木马

/bin/bash /myser & # &表示后台启动，不再屏幕上出现信息

创建完后赋权限 chmod +x check.sh

4.将check.sh写进或放进计划任务中

思路1:

写进计划任务中但这样很容易用crontab -l 查看发现

crontab -e #创建计划任务

每分钟执行一次

* * * * * # 分时日月周

crontab -l #查看当前创建了哪些计划任务

思路2:

将check.sh放在/etc/cron.d/cron.hourly

这个目录下的程序会每隔1h自动执行一次

思路3：

执行check.sh的计划任务写在/etc/crontab #这个目录下的crontab中的任务计划不会出现在crontab -l中

*/5 * * * * /bin/bash /etc/check.sh

思路4:

在/etc/init.d下随便找个程序，将执行check的命令写进去

5.重启验证效果---------------reboot关机

开机后在/home/下发现一堆文件

脚本正在运行

杀死进程

过一分钟后再次查看，发现进程已重启，注意看PID是不一样的，表示进程是重新启动过的

自此完成

Linux 系统安全检查

Sun, 09 Apr 2023 10:53:37 CST

对linux系统进行安全检查的方法
1、充分利用Linux和Unix系统中内置的检查命令来检测系统。例如，下面的几个命令在
Linux和Unix系统中就很有用处：

-who，查看谁登陆到系统中；

-w，查看谁登陆到系统中，且在做什么操作；

-last，显示系统曾经被登陆的用户和TTYS；

-history，显示系统过去被运行的命令；

-netstat，可以查看现在的网络状态；

-top，动态实时察看系统的进程；

-finger，查看所有的登陆用户。

2、定期检查系统中的日志、文件、时间和进程信息。如：

-检查/var/log/messages日志文件查看外部用户的登陆状况；

-检查用户目录下/home/username下的登陆历史文件(如：.history 文件)；

-检查用户目录下/home/username的.rhosts、.forward远程登陆文件；

-用“find / -ctime -2 -ctime +1 -ls”命令来查看不到两天以内修改的一些文件；

-用“ls -lac”命令去查看文件真正的修改时间；

-用“cmp file1 file2”命令来比较文件大小的变化；

3，CPU 查看方式
//查看系统cpu使用情况
top

//查看所有cpu核信息
mpstat -P ALL 1

//查看cpu使用情况以及平均负载
vmstat 1

//进程cpu的统计信息
pidstat -u 1 -p pid

//跟踪进程内部函数级cpu使用情况
perf top -p pid -e cpu-clock

4，MEM 查看方式

//查看系统内存使用情况
free -m

//虚拟内存统计信息
vmstat 1

//查看系统内存情况
top

//1s采集周期，获取内存的统计信息
pidstat -p pid -r 1

//查看进程的内存映像信息
pmap -d pid

//检测程序内存问题
valgrind --tool=memcheck --leak-check=full --log-file=./log.txt ./程序名

5，磁盘方式
//查看系统io信息
iotop

//统计io详细信息
iostat -d -x -k 1 10

//查看进程级io的信息
pidstat -d 1 -p pid

//查看系统IO的请求，比如可以在发现系统IO异常时，可以使用该命令进行调查，就能指定到底是什么原因导致的IO异常
perf record -e block:block_rq_issue -ag
^C
perf report

6，网络方式
//显示网络统计信息
netstat -s

//显示当前UDP连接状况
netstat -nu

//显示UDP端口号的使用情况
netstat -apu

//统计机器中网络连接各个状态个数
netstat -a | awk \\'/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}\\'

7，系统负载方式
//查看负载情况
uptime

top

vmstat

//统计系统调用耗时情况
strace -c -p pid

//跟踪指定的系统操作例如epoll_wait
strace -T -e epoll_wait -p pid

//查看内核日志信息
dmesg

//显示TCP连接
ss -t -a

//显示sockets摘要信息
ss -s

//显示所有udp sockets
ss -u -a

//tcp,etcp状态
sar -n TCP,ETCP 1

//查看网络IO
sar -n DEV 1

//抓包以包为单位进行输出
tcpdump -i eth1 host 192.168.1.1 and port 80

//抓包以流为单位显示数据内容
tcpflow -cp host 192.168.1.1

8，分析系统
TOP
perf top -p pid

检查脚本.sh

      #!/bin/bash
echo "Version:1.3"
echo "Author:飞鸟"
echo "Mail:liuquyong112@gmail.com"

cat <<EOF
*********************************************
Linux主机安全检查:
	1.首先采集原始信息保存到/tmp/liuxcheck_${ipadd}_${date}/check_file/文件夹下
	2.将系统日志、应用日志打包并保存到/tmp/linuxcheck_${ipadd}_${date}/log/目录下
	3.在检查过程中若发现存在问题则直接输出到/tmp/linuxcheck_${ipadd}_${date}/danger_file.txt文件中
	4.有些未检查可能存在问题的需要人工分析原始文件
	5.脚本编写环境Centos7,在实际使用过程中若发现问题可以邮件联系:liuquyong112@gmail.com
	6.使用过程中若在windows下修改再同步到Linux下，请使用dos2unix工具进行格式转换,不然可能会报错
	7.在使用过程中必须使用root账号,不然可能导致某些项无法分析

如何使用:
	1.本脚本可以单独运行,单独运行中只需要将本脚本上传到相应的服务器中,然后sh linuxcheck.sh即可
	2.另外本脚本可以作为多台服务器全面检查的安全检查模板,本脚本不需要手工运行,只需要将相应服务器的IP、账号、密码写到hosts.txt文件中，然后sh login.sh即可

功能设计:
	1.V1.0主要功能用来采集信息
	2.V1.1主要功能将原始数据进行分析,并找出存在可疑或危险项
	3.V1.2增加基线检查的功能
	4.V1.3对收集过来的信息,如网络连接的IP、定时任务的URL、自启动文件、关键文件的MD5通过第三方的威胁情报接口进行查询并返回相应的结果
	5.V1.4可以进行相关危险项或可疑项的自动处理


检查内容
	0.IP及版本
		0.1 IP地址
		0.2 版本信息
			0.2.1 系统内核版本
			0.2.2 系统发行版本
		0.3 ARP
			0.3.1 ARP表
			0.3.2 ARP攻击
	1.端口情况
		1.1 开放端口
			1.1.1 TCP开放端口
			1.1.2 UDP开放端口
		1.2 TCP高危端口
		1.3 UDP高危端口
		1.4 端口转发
	2.网络连接
	3.网卡模式
	4.自启动项
		4.1 用户自定义启动项
		4.2 系统自启动项
	5.定时任务
		5.1 系统定时任务
			5.1.1 时间看系统定时任务
			5.1.2 分析可疑系统定时任务
		5.2 用户定时任务
			5.2.1 时间看用户定时任务
			5.2.2 分析可疑用户定时任务
	6.路由与路由转发
	7.进程分析
		7.1 系统进程
		7.2 守护进程
	8.关键文件检查
		8.1 DNS文件
		8.2 hosts文件
		8.3 公钥文件
		8.4 私钥文件
	9.运行服务
	10.登录情况
	11.用户与用户组
		11.1 超级用户
		11.2 克隆用户
		11.3 可登录用户
		11.4 非系统用户
		11.5 shadow文件
		11.6 空口令用户
		11.7 空口令且可登录
		11.8 口令未加密
		11.9 用户组分析
			11.9.1 用户组情况
			11.9.2 特权用户
			11.9.3 相同UID用户组
			11.9.4 相同用户组名
		11.10 文件权限
			11.10.1 etc文件权限
			11.10.2 shadow文件权限
			11.10.3 passwd文件权限
			11.10.4 group文件权限
			11.10.5 securetty文件权限
			11.10.6 services文件权限
			11.10.7 grub.conf文件权限
			11.10.8 xinetd.conf文件权限
			11.10.9 lilo.conf文件权限
			11.10.10 limits.conf文件权限
	12.历史命令
		12.1 系统历史命令
			12.1.1 系统操作历史命令
			12.1.2 是否下载过脚本文件
			12.1.3 是否增加过账号
			12.1.4 是否删除过账号
			12.1.5 历史可疑命令
			12.1.6 本地下载文件
		12.2 数据库历史命令
	13.策略与配置
		13.1 防火墙策略
		13.2 远程访问策略
			13.2.1 远程允许策略
			13.2.2 远程拒绝策略
		13.3 账号与密码策略
			13.3.1 密码有效期策略
			13.3.2 密码复杂度策略
			13.3.3 密码已过期用户
			13.3.4 账号超时锁定策略
			13.3.5 grub密码策略检查
			13.3.6 lilo密码策略检查
		13.4 selinux策略
		13.5 sshd配置
			13.5.1 sshd配置
			13.5.2 空口令登录
			13.5.3 root远程登录
			13.5.4 ssh协议版本
		13.6 NIS配置
		13.7 Nginx配置
			13.7.1 原始配置
			13.7.2 可疑配置
		13.8 SNMP配置检查
	14.可疑文件
		14.1 脚本文件
		14.2 恶意文件
		14.3 最近变动的文件
		14.4 文件属性
			14.4.1 passwd文件属性
			14.4.2 shadow文件属性
			14.4.3 gshadow文件属性
			14.4.4 group文件属性
	15.系统文件完整性
	16.系统日志分析
		16.1 日志配置与打包
			16.1.1 查看日志配置
			16.1.2日志是否存在
			16.1.3 日志审核是否开启
			16.1.4 自动打包日志
		16.2 secure日志分析
			16.2.1 成功登录
			16.2.2 登录失败
			16.2.3 图形登录情况
			16.2.4 新建用户与用户组
		16.3 message日志分析
			16.3.1 传输文件
			16.3.2 历史使用DNS
		16.4 cron日志分析
			16.4.1 定时下载
			16.4.2 定时执行脚本
		16.5 yum日志分析
			16.5.1 下载软件情况
			16.5.2 卸载软件情况
			16.5.3 可疑软件
		16.6 dmesg日志分析
			16.6.1 内核自检分析
		16.7 btmp日志分析
			16.7.1 错误登录分析
		16.8 lastlog日志分析
			16.8.1 所有用户最后一次登录分析
		16.9 wtmp 日志分析
			16.9.1 所有用户登录分析
	17.内核检查
		17.1 内核信息
		17.2 异常内核
	18.安装软件
		18.1 安装软件
		18.2 可疑软件
	19.环境变量
	20.性能分析
		20.1 磁盘使用
			20.1.1 磁盘使用情况
			20.1.2 磁盘使用过大
		20.2 CPU
			20.2.1 CPU情况
			20.2.2 占用CPU前五进程
			20.2.3 占用CPU较多资源进程
		20.3 内存
			20.3.1 内存情况
			20.3.2 占用内存前五进程
			20.3.3 占用内存占多进程
		20.4 网络连接
			20.4.1 并发连接
		20.5 其他
			20.5.1 运行时间及负载情况


*********************************************
EOF

dos2unix linuxcheck.sh
date=$(date +%Y%m%d)

ipadd=$(ifconfig -a | grep -w inet | grep -v 127.0.0.1 | awk 'NR==1{print $2}')

check_file="/tmp/linuxcheck_${ipadd}_${date}/check_file/"
danger_file="/tmp/linuxcheck_${ipadd}_${date}/danger_file.txt"
log_file="/tmp/linuxcheck_${ipadd}_${date}/log/"
rm -rf $check_file
rm -rf $danger_file
rm -rf log_file
mkdir /tmp/linuxcheck_${ipadd}_${date}/
echo "检查发现危险项,请注意:" > ${danger_file}
mkdir $check_file
echo "" >> $danger_file
mkdir $log_file
cd $check_file

if [ $(whoami) != "root" ];then
	echo "安全检查必须使用root账号,否则某些项无法检查"
	exit 1
fi


saveresult="tee -a checkresult.txt"
echo "[0.1]正在检查IP地址....." && "$saveresult"

echo -------------0.IP及版本-------------------
echo -------------0.1IP地址-------------------
echo "[0.1]正在检查IP地址....." | $saveresult
ip=$(ifconfig -a | grep -w inet | awk '{print $2}')
if [ -n "$ip" ];then
	(echo "[*]本机IP地址信息:" && echo "$ip")  | $saveresult
else
	echo "[!!!]本机未配置IP地址" | $saveresult
fi
printf "\n" | $saveresult

echo -------------0.2版本信息------------------
echo "[0.2.1]正在检查系统内核版本....." | $saveresult
corever=$(uname -a)
if [ -n "$corever" ];then
	(echo "[*]系统内核版本信息:" && echo "$corever") | $saveresult
else
	echo "[!!!]未发现内核版本信息" | $saveresult
fi
printf "\n" | $saveresult

echo "[0.2.2]正在检查系统发行版本....." | $saveresult
systemver=$(cat /etc/redhat-release)
if [ -n "$systemver" ];then
	(echo "[*]系统发行版本:" && echo "$systemver") | $saveresult
else
	echo "[!!!]未发现发行版本信息" | $saveresult
fi
printf "\n" | $saveresult

echo -------------0.3 ARP------------------
echo -------------0.3.1 ARP表项-------------
echo "[0.3.1]正在查看ARP表项....." | $saveresult
arp=$(arp -a -n)
if [ -n "$arp" ];then
	(echo "[*]ARP表项如下:" && echo "$arp") | $saveresult
else
	echo "[未发现arp表]" | $saveresult
fi
printf "\n" | $saveresult

echo -------------0.3.2 ARP攻击-------------
echo "[0.3.2]正在检测是否存在ARP攻击....." | $saveresult
arpattack=$(arp -a -n | awk '{++S[$4]} END {for(a in S) {if($2>1) print $2,a,S[a]}}')
if [ -n "$arpattack" ];then
	(echo "[!!!]发现存在ARP攻击:" && echo "$arpattack") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现ARP攻击" | $saveresult
fi
printf "\n" | $saveresult

echo ------------1.查看端口情况-----------------
echo -------------1.1 查看开放端口--------------
echo -------------1.1.1 查看TCP开放端口--------------
#TCP或UDP端口绑定在0.0.0.0、127.0.0.1、192.168.1.1这种IP上只表示这些端口开放
#只有绑定在0.0.0.0上局域网才可以访问
echo "[1.1.1]正在检查TCP开放端口....." | $saveresult
listenport=$(netstat -anltp | grep LISTEN | awk  '{print $4,$7}' | sed 's/:/ /g' | awk '{print $2,$3}' | sed 's/\// /g' | awk '{printf "%-20s%-10s\n",$1,$NF}' | sort -n | uniq)
if [ -n "$listenport" ];then
	(echo "[*]该服务器开放TCP端口以及对应的服务:" && echo "$listenport") | $saveresult
else
	echo "[!!!]系统未开放TCP端口" | $saveresult
fi
printf "\n" | $saveresult

accessport=$(netstat -anltp | grep LISTEN | awk  '{print $4,$7}' | egrep "(0.0.0.0|:::)" | sed 's/:/ /g' | awk '{print $(NF-1),$NF}' | sed 's/\// /g' | awk '{printf "%-20s%-10s\n",$1,$NF}' | sort -n | uniq)
if [ -n "$accessport" ];then
	(echo "[!!!]以下TCP端口面向局域网或互联网开放,请注意！" && echo "$accessport") | $saveresult
else
	echo "[*]端口未面向局域网或互联网开放" | $saveresult
fi
printf "\n" | $saveresult

echo -------------1.1.2 查看UDP开放端口--------------
echo "[1.1.2]正在检查UDP开放端口....." | $saveresult
udpopen=$(netstat -anlup | awk  '{print $4,$NF}' | grep : | sed 's/:/ /g' | awk '{print $2,$3}' | sed 's/\// /g' | awk '{printf "%-20s%-10s\n",$1,$NF}' | sort -n | uniq)
if [ -n "$udpopen" ];then
	(echo "[*]该服务器开放UDP端口以及对应的服务:" && echo "$udpopen") | $saveresult
else
	echo "[!!!]系统未开放UDP端口" | $saveresult
fi
printf "\n" | $saveresult

udpports=$(netstat -anlup | awk '{print $4}' | egrep "(0.0.0.0|:::)" | awk -F: '{print $NF}' | sort -n | uniq)
if [ -n "$udpports" ];then
	echo "[*]以下UDP端口面向局域网或互联网开放:" | $saveresult
	for port in $udpports
	do
		nc -uz 127.0.0.1 $port
		if [ $? -eq 0 ];then
			echo $port  | $saveresult
		fi
	done
else 
	echo "[*]未发现在UDP端口面向局域网或互联网开放." | $saveresult
fi
printf "\n" | $saveresult

echo -------------1.2 TCP高危端口--------------
echo "[1.2]正在检查TCP高危端口....." | $saveresult
tcpport=`netstat -anlpt | awk '{print $4}' | awk -F: '{print $NF}' | sort | uniq | grep '[0-9].*'`
count=0
if [ -n "$tcpport" ];then
	for port in $tcpport
	do
		for i in `cat /tmp/dangerstcpports.dat`
		do
			tcpport=`echo $i | awk -F "[:]" '{print $1}'`
			desc=`echo $i | awk -F "[:]" '{print $2}'`
			process=`echo $i | awk -F "[:]" '{print $3}'`
			if [ $tcpport == $port ];then
				echo "$tcpport,$desc,$process" | tee -a $danger_file | $saveresult
				count=count+1
			fi
		done
	done
fi
if [ $count = 0 ];then
	echo "[*]未发现TCP危险端口" | $saveresult
else
	echo "[!!!]请人工对TCP危险端口进行关联分析与确认" | $saveresult
fi
printf "\n" | $saveresult

echo -------------1.3 UDP高危端口--------------
echo "[1.3]正在检查UDP高危端口....."
udpport=`netstat -anlpu | awk '{print $4}' | awk -F: '{print $NF}' | sort | uniq | grep '[0-9].*'`
count=0
if [ -n "$udpport" ];then
	for port in $udpport
	do
		for i in `cat /tmp/dangersudpports.dat`
		do
			udpport=`echo $i | awk -F "[:]" '{print $1}'`
			desc=`echo $i | awk -F "[:]" '{print $2}'`
			process=`echo $i | awk -F "[:]" '{print $3}'`
			if [ $udpport == $port ];then
				echo "$udpport,$desc,$process" | tee -a $danger_file | $saveresult
				count=count+1
			fi
		done
	done
fi
if [ $count = 0 ];then
	echo "[*]未发现UDP危险端口" | $saveresult
else
	echo "[!!!]请人工对UDP危险端口进行关联分析与确认"
fi
printf "\n" | $saveresult

echo ------------2.网络连接---------------------
echo "[2.1]正在检查网络连接情况....." | $saveresult
netstat=$(netstat -anlp | grep ESTABLISHED)
netstatnum=$(netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}')
if [ -n "$netstat" ];then
	(echo "[*]网络连接情况:" && echo "$netstat") | $saveresult
	if [ -n "$netstatnum" ];then
		(echo "[*]各个状态的数量如下:" && echo "$netstatnum") | $saveresult
	fi
else
	echo "[*]未发现网络连接" | $saveresult
fi
printf "\n" | $saveresult

echo -------------3.网卡模式---------------------
echo "[3.1]正在检查网卡模式....." | $saveresult
ifconfigmode=$(ifconfig -a | grep flags | awk -F '[: = < >]' '{print "网卡:",$1,"模式:",$5}')
if [ -n "$ifconfigmode" ];then
	(echo "网卡工作模式如下:" && echo "$ifconfigmode") | $saveresult
else
	echo "[*]未找到网卡模式相关信息,请人工分析" | $saveresult
fi
printf "\n" | $saveresult

echo "[3.2]正在分析是否有网卡处于混杂模式....." | $saveresult
Promisc=`ifconfig | grep PROMISC | gawk -F: '{ print $1}'`
if [ -n "$Promisc" ];then
	(echo "[!!!]网卡处于混杂模式:" && echo "$Promisc") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现网卡处于混杂模式" | $saveresult
fi
printf "\n" | $saveresult

echo "[3.3]正在分析是否有网卡处于监听模式....." | $saveresult
Monitor=`ifconfig | grep -E "Mode:Monitor" | gawk -F: '{ print $1}'`
if [ -n "$Monitor" ];then
	(echo "[!!!]网卡处于监听模式:" && echo "$Monitor") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现网卡处于监听模式" | $saveresult
fi
printf "\n" | $saveresult

echo -------------4.启动项-----------------------
echo -------------4.1 用户自定义启动项-----------------------
echo "[4.1]正在检查用户自定义启动项....." | $saveresult
chkconfig=$(chkconfig --list | grep -E ":on|启用" | awk '{print $1}')
if [ -n "$chkconfig" ];then
	(echo "[*]用户自定义启动项:" && echo "$chkconfig") | $saveresult
else
	echo "[!!!]未发现用户自定义启动项" | $saveresult
fi
printf "\n" | $saveresult

echo -------------4.2 系统自启动项-----------------------
echo "[4.2]正在检查系统自启动项....." | $saveresult
systemchkconfig=$(systemctl list-unit-files | grep enabled | awk '{print $1}')
if [ -n "$systemchkconfig" ];then
	(echo "[*]系统自启动项如下:" && echo "$systemchkconfig")  | $saveresult
else
	echo "[*]未发现系统自启动项" | $saveresult
fi
printf "\n" | $saveresult

echo -------------4.3 危险启动项-----------------------
echo "[4.3]正在检查危险启动项....." | $saveresult
dangerstarup=$(chkconfig --list | grep -E ":on|启用" | awk '{print $1}' | grep -E "\.(sh|per|py)$")
if [ -n "$dangerstarup" ];then
	(echo "[!!!]发现危险启动项:" && echo "$dangerstarup") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现危险启动项" | $saveresult
fi
printf "\n" | $saveresult

echo ------------5.查看定时任务-------------------
echo ------------5.1系统定时任务分析-------------------
echo ------------5.1.1查看系统定时任务-------------------
echo "[5.1.1]正在分析系统定时任务....." | $saveresult
syscrontab=$(more /etc/crontab | grep -v "# run-parts" | grep run-parts)
if [ -n "$syscrontab" ];then
	(echo "[!!!]发现存在系统定时任务:" && more /etc/crontab ) | tee -a $danger_file | $saveresult
else
	echo "[*]未发现系统定时任务" | $saveresult
fi
printf "\n" | $saveresult

# if [ $? -eq 0 ]表示上面命令执行成功;执行成功输出的是0；失败非0
#ifconfig  echo $? 返回0，表示执行成功
# if [ $? != 0 ]表示上面命令执行失败

echo ------------5.1.2分析系统可疑定时任务-------------------
echo "[5.1.2]正在分析系统可疑任务....." | $saveresult
dangersyscron=$(egrep "((chmod|useradd|groupadd|chattr)|((wget|curl)*\.(sh|pl|py)$))"  /etc/cron*/* /var/spool/cron/*)
if [ $? -eq 0 ];then
	(echo "[!!!]发现下面的定时任务可疑,请注意！！！" && echo "$dangersyscron") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现可疑系统定时任务" | $saveresult
fi
printf "\n" | $saveresult

echo ------------5.2分析用户定时任务-------------------
echo ------------5.2.1查看用户定时任务-------------------
echo "[5.2.1]正在查看用户定时任务....." | $saveresult
crontab=$(crontab -l)
if [ $? -eq 0 ];then
	(echo "[!!!]发现用户定时任务如下:" && echo "$crontab") | $saveresult
else
	echo "[*]未发现用户定时任务"  | $saveresult
fi
printf "\n" | $saveresult

echo ------------5.2.2查看可疑用户定时任务-------------------
echo "[5.2.2]正在分析可疑用户定时任务....." | $saveresult
danger_crontab=$(crontab -l | egrep "((chmod|useradd|groupadd|chattr)|((wget|curl).*\.(sh|pl|py)))")
if [ $? -eq 0 ];then
	(echo "[!!!]发现可疑定时任务,请注意！！！" && echo "$danger_crontab") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现可疑定时任务" | $saveresult
fi
printf "\n" | $saveresult

echo -------------6.路由与路由转发----------------
echo "[6.1]正在检查路由表....." | $saveresult
route=$(route -n)
if [ -n "$route" ];then
	(echo "[*]路由表如下:" && echo "$route") | $saveresult
else
	echo "[*]未发现路由器表" | $saveresult
fi
printf "\n" | $saveresult

echo "[6.2]正在分析是否开启转发功能....." | $saveresult
#数值分析
#1:开启路由转发
#0:未开启路由转发
ip_forward=`more /proc/sys/net/ipv4/ip_forward | gawk -F: '{if ($1==1) print "1"}'`
if [ -n "$ip_forward" ];then
	echo "[!!!]该服务器开启路由转发,请注意！" | tee -a $danger_file  | $saveresult
else
	echo "[*]该服务器未开启路由转发" | $saveresult
fi
printf "\n" | $saveresult

echo ------------7.进程分析--------------------
echo ------------7.1系统进程--------------------
echo "[7.1]正在检查进程....." | $saveresult
ps=$(ps -aux)
if [ -n "$ps" ];then
	(echo "[*]系统进程如下:" && echo "$ps") | $saveresult
else
	echo "[*]未发现系统进程" | $saveresult
fi
printf "\n" | $saveresult

echo "[7.2]正在检查守护进程....." | $saveresult
if [ -e /etc/xinetd.d/rsync ];then
	(echo "[*]系统守护进程:" && more /etc/xinetd.d/rsync | grep -v "^#") | $saveresult
else
	echo "[*]未发现守护进程" | $saveresult
fi
printf "\n" | $saveresult

echo ------------8.关键文件检查-----------------
echo ------------8.1DNS文件检查-----------------
echo "[8.1]正在检查DNS文件....." | $saveresult
resolv=$(more /etc/resolv.conf | grep ^nameserver | awk '{print $NF}') 
if [ -n "$resolv" ];then
	(echo "[*]该服务器使用以下DNS服务器:" && echo "$resolv") | $saveresult
else
	echo "[*]未发现DNS服务器" | $saveresult
fi
printf "\n" | $saveresult

echo ------------8.2hosts文件检查-----------------
echo "[8.2]正在检查hosts文件....." | $saveresult
hosts=$(more /etc/hosts)
if [ -n "$hosts" ];then
	(echo "[*]hosts文件如下:" && echo "$hosts") | $saveresult
else
	echo "[*]未发现hosts文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------8.3公钥文件检查-----------------
echo "[8.3]正在检查公钥文件....." | $saveresult
if [  -e /root/.ssh/*.pub ];then
	echo "[!!!]发现公钥文件,请注意！"  | tee -a $danger_file | $saveresult
else
	echo "[*]未发现公钥文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------8.4私钥文件检查-----------------
echo "[8.4]正在检查私钥文件....." | $saveresult
if [ -e /root/.ssh/id_rsa ];then
	echo "[!!!]发现私钥文件,请注意！" | tee -a $danger_file | $saveresult
else
	echo "[*]未发现私钥文件" | $saveresult
fi
printf "\n" | $saveresult


echo ------------9.运行服务----------------------
echo "[9.1]正在检查运行服务....." | $saveresult
services=$(systemctl | grep -E "\.service.*running" | awk -F. '{print $1}')
if [ -n "$services" ];then
	(echo "[*]以下服务正在运行：" && echo "$services") | $saveresult
else
	echo "[!!!]未发现正在运行的服务！" | $saveresult
fi
printf "\n" | $saveresult

echo ------------10.查看登录用户------------------
echo "[10.1]正在检查正在登录的用户....." | $saveresult
(echo "[*]系统登录用户:" && who ) | $saveresult
printf "\n" | $saveresult

echo ------------11.查看用户信息------------------
echo "[11]正在查看用户信息....." | $saveresult
echo "[*]用户名:口令:用户标识号:组标识号:注释性描述:主目录:登录Shell" | $saveresult
more /etc/passwd  | $saveresult
printf "\n" | $saveresult

echo ------------11.1超级用户---------------------
#UID=0的为超级用户,系统默认root的UID为0
echo "[11.1]正在检查是否存在超级用户....." | $saveresult
Superuser=`more /etc/passwd | egrep -v '^root|^#|^(\+:\*)?:0:0:::' | awk -F: '{if($3==0) print $1}'`
if [ -n "$Superuser" ];then
	echo "[!!!]除root外发现超级用户:" | tee -a $danger_file | $saveresult
	for user in $Superuser
	do
		echo $user | $saveresult
		if [ "${user}" = "toor" ];then
			echo "[!!!]BSD系统默认安装toor用户,其他系统默认未安装toor用户,若非BSD系统建议删除该账号" | $saveresult
		fi
	done
else
	echo "[*]未发现超级用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.2克隆用户---------------------
#相同的UID为克隆用户
echo "[11.2]正在检查是否存在克隆用户....." | $saveresult
uid=`awk -F: '{a[$3]++}END{for(i in a)if(a[i]>1)print i}' /etc/passwd`
if [ -n "$uid" ];then
	echo "[!!!]发现下面用户的UID相同:" | tee -a $danger_file | $saveresult
	(more /etc/passwd | grep $uid | awk -F: '{print $1}') | tee -a $danger_file | $saveresult
else
	echo "[*]未发现相同UID的用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.3可登录用户-------------------
echo "[11.3]正在检查可登录的用户......" | $saveresult
loginuser=`cat /etc/passwd  | grep -E "/bin/bash$" | awk -F: '{print $1}'`
if [ -n "$loginuser" ];then
	echo "[!!!]以下用户可以登录：" | tee -a $danger_file | $saveresult
	for user in $loginuser
	do
		echo $user | tee -a $danger_file | $saveresult
	done
else
	echo "[*]未发现可以登录的用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.4非系统用户-----------------
echo "[11.4]正在检查非系统本身自带用户" | $saveresult
if [ -f /etc/login.defs ];then
	uid=$(grep "^UID_MIN" /etc/login.defs | awk '{print $2}')
	(echo "系统最小UID为"$uid) | $saveresult
	nosystemuser=`gawk -F: '{if ($3>='$uid' && $3!=65534) {print $1}}' /etc/passwd`
	if [ -n "$nosystemuser" ];then
		(echo "以下用户为非系统本身自带用户:" && echo "$nosystemuser") | tee -a $danger_file | $saveresult
	else
		echo "[*]未发现除系统本身外的其他用户" | $saveresult
	fi
fi
printf "\n" | $saveresult

echo ------------11.5shadow文件-----------------
echo "[11.5]正在检查shadow文件....." | $saveresult
(echo "[*]shadow文件" && more /etc/shadow ) | $saveresult
printf "\n" | $saveresult

echo ------------11.6空口令用户-----------------
echo "[11.6]正在检查空口令用户....." | $saveresult
nopasswd=`gawk -F: '($2=="") {print $1}' /etc/shadow`
if [ -n "$nopasswd" ];then
	(echo "[!!!]以下用户口令为空：" && echo "$nopasswd") | $saveresult
else
	echo "[*]未发现空口令用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.7空口令且可登录-----------------
echo "[11.7]正在检查空口令且可登录的用户....." | $saveresult
#允许空口令用户登录方法
#1.passwd -d username
#2.echo "PermitEmptyPasswords yes" >>/etc/ssh/sshd_config
#3.service sshd restart
aa=$(cat /etc/passwd  | grep -E "/bin/bash$" | awk -F: '{print $1}')
bb=$(gawk -F: '($2=="") {print $1}' /etc/shadow)
cc=$(cat /etc/ssh/sshd_config | grep -w "^PermitEmptyPasswords yes")
flag=""
for a in $aa
do
    for b in $bb
    do
        if [ "$a" = "$b" ] && [ -n "$cc" ];then
            echo "[!!!]发现空口令且可登录用户:"$a | $saveresult
            flag=1
        fi
    done
done
if [ -n "$flag" ];then
	echo "请人工分析配置和账号" | $saveresult
else
	echo "[*]未发现空口令且可登录用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.8口令未加密----------------
echo "[11.8]正在检查口令加密用户....." | $saveresult
noenypasswd=$(awk -F: '{if($2!="x") {print $1}}' /etc/passwd)
if [ -n "$noenypasswd" ];then
	(echo "[!!!]以下用户口令未加密:" && echo "$noenypasswd") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现口令未加密的用户"  | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.9用户组分析-----------------------
echo ------------11.9.1 用户组信息------------ ----
echo "[11.9.1]正在检查用户组信息....." | $saveresult
echo "[*]用户组信息如下:"
(more /etc/group | grep -v "^#") | $saveresult
printf "\n" | $saveresult

echo ------------11.9.2 特权用户--------------------
echo "[11.9.2]正在检查特权用户....." | $saveresult
roots=$(more /etc/group | grep -v '^#' | gawk -F: '{if ($1!="root"&&$3==0) print $1}')
if [ -n "$roots" ];then
	echo "[!!!]除root用户外root组还有以下用户:" | tee -a $danger_file | $saveresult
	for user in $roots
	do
		echo $user | tee -a $danger_file | $saveresult
	done
else 
	echo "[*]除root用户外root组未发现其他用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.9.3 相同GID用户组--------------------
echo "[11.9.3]正在检查相应GID用户组....." | $saveresult
groupuid=$(more /etc/group | grep -v "^$" | awk -F: '{print $3}' | uniq -d)
if [ -n "$groupuid" ];then
	(echo "[!!!]发现相同GID用户组:" && echo "$groupuid") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现相同GID的用户组" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.9.4 相同用户组名--------------------
echo "[11.9.4]正在检查相同用户组名....." | $saveresult
groupname=$(more /etc/group | grep -v "^$" | awk -F: '{print $1}' | uniq -d)
if [ -n "$groupname" ];then
	(echo "[!!!]发现相同用户组名:" && echo "$groupname") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现相同用户组名" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10 文件权限--------------------
echo ------------11.10.1 etc文件权限--------------------
echo "[11.10.1]正在检查etc文件权限....." | $saveresult
etc=$(ls -l / | grep etc | awk '{print $1}')
if [ "${etc:1:9}" = "rwxr-x---" ]; then
    echo "[*]/etc/权限为750,权限正常" | $saveresult
else
    echo "[!!!]/etc/文件权限为:""${etc:1:9}","权限不符合规划,权限应改为750" | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.2 shadow文件权限--------------------
echo "[11.10.2]正在检查shadow文件权限....." | $saveresult
shadow=$(ls -l /etc/shadow | awk '{print $1}')
if [ "${shadow:1:9}" = "rw-------" ]; then
    echo "[*]/etc/shadow文件权限为600,权限符合规范" | $saveresult
else
    echo "[!!!]/etc/shadow文件权限为:""${shadow:1:9}"",不符合规范,权限应改为600" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.3 passwd文件权限--------------------
echo "[11.10.3]正在检查passwd文件权限....." | $saveresult
passwd=$(ls -l /etc/passwd | awk '{print $1}')
if [ "${passwd:1:9}" = "rw-r--r--" ]; then
    echo "[*]/etc/passwd文件权限为644,符合规范" | $saveresult
else
    echo "[!!!]/etc/passwd文件权限为:""${passwd:1:9}"",权限不符合规范,建议改为644" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.4 group文件权限--------------------
echo "[11.10.4]正在检查group文件权限....." | $saveresult
group=$(ls -l /etc/group | awk '{print $1}')
if [ "${group:1:9}" = "rw-r--r--" ]; then
    echo "[*]/etc/group文件权限为644,符合规范" | $saveresult
else
    echo "[!!!]/etc/goup文件权限为""${group:1:9}","不符合规范,权限应改为644" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.5 securetty文件权限--------------------
echo "[11.10.5]正在检查securetty文件权限....." | $saveresult
securetty=$(ls -l /etc/securetty | awk '{print $1}')
if [ "${securetty:1:9}" = "-rw-------" ]; then
    echo "[*]/etc/securetty文件权限为600,符合规范" | $saveresult
else
    echo "[!!!]/etc/securetty文件权限为""${securetty:1:9}","不符合规范,权限应改为600" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.6 services文件权限--------------------
echo "[11.10.6]正在检查services文件权限....." | $saveresult
services=$(ls -l /etc/services | awk '{print $1}')
if [ "${services:1:9}" = "-rw-r--r--" ]; then
    echo "[*]/etc/services文件权限为644,符合规范" | $saveresult
else
    echo "[!!!]/etc/services文件权限为""$services:1:9}","不符合规范,权限应改为644" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.7 grub.conf文件权限--------------------
echo "[11.10.7]正在检查grub.conf文件权限....." | $saveresult
grubconf=$(ls -l /etc/grub.conf | awk '{print $1}')
if [ "${grubconf:1:9}" = "-rw-------" ]; then
    echo "[*]/etc/grub.conf文件权限为600,符合规范" | $saveresult
else
    echo "[!!!]/etc/grub.conf文件权限为""${grubconf:1:9}","不符合规范,权限应改为600" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.8 xinetd.conf文件权限--------------------
echo "[11.10.8]正在检查xinetd.conf文件权限....." | $saveresult
xinetdconf=$(ls -l /etc/xinetd.conf | awk '{print $1}')
if [ "${xinetdconf:1:9}" = "-rw-------" ]; then
    echo "[*]/etc/xinetd.conf文件权限为600,符合规范" | $saveresult
else
    echo "[!!!]/etc/xinetd.conf文件权限为""${xinetdconf:1:9}","不符合规范,权限应改为600" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------11.10.9 lilo.conf文件权限--------------------
echo "[11.10.9]正在检查lilo.conf文件权限....." | $saveresult
if [ -f /etc/lilo.conf ];then
liloconf=$(ls -l /etc/lilo.conf | awk '{print $1}')
	if [ "${liloconf:1:9}" = "-rw-------" ];then
		echo "/etc/lilo.conf文件权限为600,符合要求" | $saveresult
	else
		echo "/etc/lilo.conf文件权限不为600,不符合要求,建议设置权限为600" | $saveresult
	fi
else
	echo "/etc/lilo.conf文件夹不存在,不检查,符合要求"
fi
printf "\n" | $saveresult

echo ------------11.10.10 limits.conf文件权限--------------------
echo "[11.10.10]正在检查limits.conf文件权限....." | $saveresult
cat /etc/security/limits.conf | grep -v ^# | grep core
if [ $? -eq 0 ];then
	soft=`cat /etc/security/limits.conf | grep -v ^# | grep core | awk -F ' ' '{print $2}'`
	for i in $soft
	do
		if [ $i = "soft" ];then
			echo "* soft core 0 已经设置,符合要求" | $saveresult
		fi
		if [ $i = "hard" ];then
			echo "* hard core 0 已经设置,符合要求" | $saveresult
		fi
	done
else 
	echo "没有设置core,建议在/etc/security/limits.conf中添加* soft core 0和* hard core 0"  | $saveresult
fi

echo ------------11.11其他--------------------
###############################################
#Access:访问时间,每次访问文件时都会更新这个时间,如使用more、cat
#Modify:修改时间,文件内容改变会导致该时间更新
#Change:改变时间,文件属性变化会导致该时间更新,当文件修改时也会导致该时间更新;但是改变文件的属性,如读写权限时只会导致该时间更新，不会导致修改时间更新
###############################################
echo "[11.11]正在检查useradd时间属性....." | $saveresult
echo "[*]useradd时间属性:" | $saveresult
stat /usr/sbin/useradd | egrep "Access|Modify|Change" | grep -v '(' | $saveresult
printf "\n" | $saveresult

echo "[11.11]正在检查userdel时间属性....." | $saveresult
echo "[*]userdel时间属性:" | $saveresult
stat /usr/sbin/userdel | egrep "Access|Modify|Change" | grep -v '(' | $saveresult
printf "\n" | $saveresult

echo ------------12历史命令--------------------------
echo ------------12.1系统操作历史命令---------------
echo ------------12.1.1系统操作历史命令---------------
echo "[12.1.1]正在检查操作系统历史命令....." | $saveresult
history=$(more /root/.bash_history)
if [ -n "$history" ];then
	(echo "[*]操作系统历史命令如下:" && echo "$history") | $saveresult
else
	echo "[!!!]未发现历史命令,请检查是否记录及已被清除" | $saveresult
fi
printf "\n" | $saveresult

echo ------------12.1.2是否下载过脚本文件---------------
echo "[12.1.2]正在检查是否下载过脚本文件....." | $saveresult
scripts=$(more /root/.bash_history | grep -E "((wget|curl).*\.(sh|pl|py)$)" | grep -v grep)
if [ -n "$scripts" ];then
	(echo "[!!!]该服务器下载过脚本以下脚本：" && echo "$scripts") | tee -a $danger_file | $saveresult
else
	echo "[*]该服务器未下载过脚本文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------12.1.3是否增加过账号---------------
echo "[12.1.3]正在检查是否增加过账号....." | $saveresult
addusers=$(history | egrep "(useradd|groupadd)" | grep -v grep)
if [ -n "$addusers" ];then
	(echo "[!!!]该服务器增加过以下账号:" && echo "$addusers") | tee -a $danger_file | $saveresult
else
	echo "[*]该服务器未增加过账号" | $saveresult
fi
printf "\n" | $saveresult

echo ------------12.1.4是否删除过账号--------------
echo "[12.1.4]正在检查是否删除过账号....." | $saveresult
delusers=$(history | egrep "(userdel|groupdel)" | grep -v grep)
if [ -n "$delusers" ];then
	(echo "[!!!]该服务器删除过以下账号:" && echo "$delusers") | tee -a $danger_file | $saveresult
else
	echo "[*]该服务器未删除过账号" | $saveresult
fi
printf "\n" | $saveresult

echo ------------12.1.5可疑历史命令--------------
echo "[12.1.5]正在检查历史可疑命令....." | $saveresult
danger_histroy=$(history | grep -E "(whois|sqlmap|nmap|beef|nikto|john|ettercap|backdoor|proxy|msfconsole|msf)" | grep -v grep)
if [ -n "$danger_histroy" ];then
	(echo "[!!!]发现可疑历史命令" && echo "$danger_histroy") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现可疑历史命令" | $saveresult
fi
printf "\n" | $saveresult

echo ------------12.1.6本地下载文件--------------
echo "[12.1.6]正在检查历史日志中本地下载文件记录....." | $saveresult
uploadfiles=$(history | grep sz | grep -v grep | awk '{print $3}')
if [ -n "$uploadfiles" ];then
	(echo "[!!!]通过历史日志发现本地主机下载过以下文件:" && echo "$uploadfiles") | $saveresult
else
	echo "[*]通过历史日志未发现本地主机下载过文件" | $saveresult
fi
printf "\n" | $saveresult


echo ------------12.2数据库操作历史命令---------------
echo "[12.2]正在检查数据库操作历史命令....." | $saveresult
mysql_history=$(more /root/.mysql_history)
if [ -n "$mysql_history" ];then
	(echo "[*]数据库操作历史命令如下:" && echo "$mysql_history") | $saveresult
else
	echo "[*]未发现数据库历史命令" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.策略情况---------------------
echo ------------13.1防火墙策略-------------------
echo "[13.1]正在检查防火墙策略....." | $saveresult
firewalledstatus=$(systemctl status firewalld | grep "active (running)")
firewalledpolicy=$(iptables -L | grep "\([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\}")
if [ -n "$firewalledstatus" ];then
	echo "[*]该服务器防火墙已打开"
	if [ -n "$firewalledpolicy" ];then
		(echo "[*]防火墙策略如下" && echo "$firewalledpolicy") | $saveresult
	else
		echo "[!!!]防火墙策略未配置,建议配置防火墙策略!" | tee -a $danger_file | $saveresult
	fi
else
	echo "[！！！]防火墙未开启,建议开启防火墙" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.2远程访问策略-----------------
echo ------------13.2.1远程允许策略-----------------
echo "[13.2.1]正在检查远程允许策略....." | $saveresult
hostsallow=$(more /etc/hosts.allow | grep -v '#')
if [ -n "$hostsallow" ];then
	(echo "[!!!]允许以下IP远程访问:" && echo "$hostsallow") | tee -a $danger_file | $saveresult
else
	echo "[*]hosts.allow文件未发现允许远程访问地址" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.2.2远程拒绝策略-----------------
echo "[13.2.2]正在检查远程拒绝策略....." | $saveresult
hostsdeny=$(more /etc/hosts.deny | grep -v '#')
if [ -n "$hostsdeny" ];then
	(echo "[!!!]拒绝以下IP远程访问:" && echo "$hostsdeny") | $saveresult
else
	echo "[*]hosts.deny文件未发现拒绝远程访问地址" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.3密码策略------------------------
echo ------------13.3.1密码有效期策略------------------------
echo "[13.3.1]正在检查密码有效期策略....." | $saveresult
(echo "[*]密码有效期策略如下:" && more /etc/login.defs | grep -v "#" | grep PASS ) | $saveresult
printf "\n" | $saveresult

echo "[*]正在进行具体项的基线检查......" | $saveresult
passmax=$(cat /etc/login.defs | grep PASS_MAX_DAYS | grep -v ^# | awk '{print $2}')
if [ $passmax -le 90 -a $passmax -gt 0 ];then
	echo "[*]口令生存周期为${passmax}天,符合要求" | $saveresult
else
	echo "[!!!]口令生存周期为${passmax}天,不符合要求,建议设置为0-90天" | $saveresult
fi

passmin=$(cat /etc/login.defs | grep PASS_MIN_DAYS | grep -v ^# | awk '{print $2}')
if [ $passmin -ge 6 ];then
	echo "[*]口令更改最小时间间隔为${passmin}天,符合要求" | $saveresult
else
	echo "[!!!]口令更改最小时间间隔为${passmin}天,不符合要求,建议设置不小于6天" | $saveresult
fi

passlen=$(cat /etc/login.defs | grep PASS_MIN_LEN | grep -v ^# | awk '{print $2}')
if [ $passlen -ge 8 ];then
	echo "[*]口令最小长度为${passlen},符合要求" | $saveresult
else
	echo "[!!!]口令最小长度为${passlen},不符合要求,建议设置最小长度大于等于8" | $saveresult
fi

passage=$(cat /etc/login.defs | grep PASS_WARN_AGE | grep -v ^# | awk '{print $2}')
if [ $passage -ge 30 -a $passage -lt $passmax ];then
	echo "[*]口令过期警告时间天数为${passage},符合要求" | $saveresult
else
	echo "[!!!]口令过期警告时间天数为${passage},不符合要求,建议设置大于等于30并小于口令生存周期" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.3.2密码复杂度策略------------------------
echo "[13.3.1]正在检查密码复杂度策略....." | $saveresult
(echo "[*]密码复杂度策略如下:" && more /etc/pam.d/system-auth | grep -v "#") | $saveresult
printf "\n" | $saveresult

echo ------------13.3.3 密码已过期用户---------------------------
echo "[13.3.3]正在检查密码已过期用户....." | $saveresult
NOW=$(date "+%s")
day=$((${NOW}/86400))
passwdexpired=$(grep -v ":[\!\*x]([\*\!])?:" /etc/shadow | awk -v today=${day} -F: '{ if (($5!="") && (today>$3+$5)) { print $1 }}')
if [ -n "$passwdexpired" ];then
	(echo "[*]以下用户的密码已过期:" && echo "$passwdexpired")  | $saveresult
else
	echo "[*]未发现密码已过期用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.3.4 账号超时锁定策略---------------------------
echo "[13.3.4]正在检查账号超时锁定策略....." | $saveresult
account_timeout=`cat /etc/profile | grep TMOUT | awk -F[=] '{print $2}'` 
if [ "$account_timeout" != ""  ];then
	TMOUT=`cat /etc/profile | grep TMOUT | awk -F[=] '{print $2}'`
	if [ $TMOUT -le 600 -a $TMOUT -ge 10 ];then
		echo "[*]账号超时时间为${TMOUT}秒,符合要求" | $saveresult
	else
		echo "[!!!]账号超时时间为${TMOUT}秒,不符合要求,建议设置小于600秒" | $saveresult
fi
else
	echo "[!!!]账号超时未锁定,不符合要求,建议设置小于600秒" | $saveresult 
fi
printf "\n" | $saveresult

echo ------------13.3.5 grub密码策略检查---------------------------
echo "[13.3.5]正在检查grub密码策略....." | $saveresult
grubpass=$(cat /etc/grub.conf | grep password)
if [ $? -eq 0 ];then
	echo "[*]已设置grub密码,符合要求" | $saveresult 
else
	echo "[!!!]未设置grub密码,不符合要求,建议设置grub密码" | $saveresult 
fi
printf "\n" | $saveresult


echo ------------13.3.6 lilo密码策略检查---------------------------
echo "[13.3.6]正在检查lilo密码策略....." | $saveresult
if [ -f  /etc/lilo.conf ];then
	lilopass=$(cat /etc/lilo.conf | grep password 2> /dev/null)
	if [ $? -eq 0 ];then
		echo "[*]已设置lilo密码,符合要求" | $saveresult
	else
		echo "[!!!]未设置lilo密码,不符合要求,建议设置lilo密码" | $saveresult
	fi
else
	echo "[*]未发现/etc/lilo.conf文件" | $saveresult
fi


echo ------------13.4selinux策略----------------------
echo "[13.4]正在检查selinux策略....." | $saveresult
(echo "selinux策略如下:" && egrep -v '#|^$' /etc/sysconfig/selinux ) | $saveresult
printf "\n" | $saveresult

echo ------------13.5sshd配置文件--------------------
echo ------------13.5.1sshd配置----------------------
echo "[13.5.1]正在检查sshd配置....." | $saveresult
sshdconfig=$(more /etc/ssh/sshd_config | egrep -v "#|^$")
if [ -n "$sshdconfig" ];then
	(echo "[*]sshd配置文件如下:" && echo "$sshdconfig") | $saveresult
else
	echo "[！]未发现sshd配置文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.5.2空口令登录检查--------------------
echo "[13.5.2]正在检查是否允许空口令登录....." | $saveresult
emptypasswd=$(cat /etc/ssh/sshd_config | grep -w "^PermitEmptyPasswords yes")
nopasswd=`gawk -F: '($2=="") {print $1}' /etc/shadow`
if [ -n "$emptypasswd" ];then
	echo "[!!!]允许空口令登录,请注意！！！"
	if [ -n "$nopasswd" ];then
		(echo "[!!!]以下用户空口令:" && echo "$nopasswd") | tee -a $danger_file | $saveresult
	else
		echo "[*]但未发现空口令用户" | $saveresult
	fi
else
	echo "[*]不允许空口令用户登录" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.5.3 root远程登录--------------------
echo "[13.5.3]正在检查是否允许root远程登录....." | $saveresult
cat /etc/ssh/sshd_config | grep -v ^# |grep "PermitRootLogin no"
if [ $? -eq 0 ];then
	echo "[*]root不允许登陆,符合要求" | $saveresult
else
	echo "[!!!]允许root远程登陆,不符合要求,建议/etc/ssh/sshd_config添加PermitRootLogin no" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.5.4 ssh协议版本--------------------
echo "[13.5.4]正在检查ssh协议版本....." | $saveresult
protocolver=$(more /etc/ssh/sshd_config | grep -v ^$ | grep Protocol | awk '{print $2}')
if [ "$protocolver" -eq "2" ];then
	echo "[*]openssh使用ssh2协议,符合要求" 
else
	echo "[!!!]openssh未ssh2协议,不符合要求"
fi

echo ------------13.6 NIS 配置文件--------------------
echo "[13.6]正在检查nis配置....." | $saveresult
nisconfig=$(more /etc/nsswitch.conf | egrep -v '#|^$')
if [ -n "$nisconfig" ];then
	(echo "[*]NIS服务配置如下:" && echo "$nisconfig") | $saveresult
else
	echo "[*]未发现NIS服务配置" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.7 Nginx配置----------------------
echo ------------13.7.1 Nginx配置---------------------
echo "[13.7.1]正在检查Nginx配置文件......" | $saveresult
nginx=$(whereis nginx | awk -F: '{print $2}')
if [ -n "$nginx" ];then
	(echo "[*]Nginx配置文件如下:" && more $nginx/conf/nginx.conf) | $saveresult
else
	echo "[*]未发现Nginx服务" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.7.2 Nginx端口转发分析-------------
echo "[13.7.2]正在检查Nginx端口转发配置......" | $saveresult
nginx=$(whereis nginx | awk -F: '{print $2}')
nginxportconf=$(more $nginx/conf/nginx.conf | egrep "listen|server |server_name |upstream|proxy_pass|location"| grep -v \#)
if [ -n "$nginxportconf" ];then
	(echo "[*]可能存在端口转发的情况,请人工分析:" && echo "$nginxportconf") | $saveresult
else
	echo "[*]未发现端口转发配置" | $saveresult
fi
printf "\n" | $saveresult

echo ------------13.8 SNMP配置检查-------------
echo "[13.8]正在检查SNMP配置......" | $saveresult
if [ -f /etc/snmp/snmpd.conf ];then
	public=$(cat /etc/snmp/snmpd.conf | grep public | grep -v ^# | awk '{print $4}')
	private=$(cat /etc/snmp/snmpd.conf | grep private | grep -v ^# | awk '{print $4}')
	if [ "$public" -eq "public" ];then
		echo "发现snmp服务存在默认团体名public,不符合要求" | $saveresult
	fi
	if [ "$private" -eq "private" ];then
		echo "发现snmp服务存在默认团体名private,不符合要求" | $saveresult
	fi
else
	echo "snmp服务配置文件不存在,可能没有运行snmp服务" | $saveresult
fi
printf "\n" | $saveresult

echo ------------14. 可疑文件-------------------------
echo ------------14.1 脚本文件------------------------
#下面脚本不查找/usr目录和/etc目录,检查时可以根据需求来调整
echo "[14.1]正在检查脚本文件....." | $saveresult
scripts=$(find / *.* | egrep "\.(py|sh|per|pl)$" | egrep -v "/usr|/etc|/var")
if [ -n "scripts" ];then
	(echo "[!!!]发现以下脚本文件,请注意！！！" && echo "$scripts") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现脚本文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------14.2 恶意文件---------------------
#webshell这一块因为技术难度相对较高,并且已有专业的工具，目前这一块建议使用专门的安全检查工具来实现
#系统层的恶意文件建议使用rootkit专杀工具来查杀,如rkhunter,下载地址:http://rkhunter.sourceforge.net

echo ------------14.3 最近24小时内变动的文件---------------------
#查看最近24小时内有改变的文件
(find / -mtime 0 | grep -E "\.(py|sh|per|pl|php|asp|jsp)$") | tee -a $danger_file | $saveresult
printf "\n" | $saveresult


echo ------------14.4 文件属性---------------------
echo ------------14.4.1 passwd文件属性---------------------
echo "[14.4.1]正在检查passwd文件属性......" | $saveresult
flag=0
for ((x=1;x<=15;x++))
do
	apend=`lsattr /etc/passwd | cut -c $x`
	if [ $apend = "i" ];then
		echo "/etc/passwd文件存在i安全属性,符合要求" | $saveresult
		flag=1
	fi
	if [ $apend = "a" ];then
		echo "/etc/passwd文件存在a安全属性" | $saveresult
		flag=1
	fi
done

if [ $flag = 0 ];then
	echo "/etc/passwd文件不存在相关安全属性,建议使用chattr +i或chattr +a防止/etc/passwd被删除或修改" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------14.4.2 shadow文件属性---------------------
echo "[14.4.2]正在检查shadow文件属性......" | $saveresult
flag=0
for ((x=1;x<=15;x++))
do
	apend=`lsattr /etc/shadow | cut -c $x`
	if [ $apend = "i" ];then
		echo "/etc/shadow文件存在i安全属性,符合要求" | $saveresult
		flag=1
	fi
	if [ $apend = "a" ];then
		echo "/etc/shadow文件存在a安全属性" | $saveresult
		flag=1
	fi
done
if [ $flag = 0 ];then
	echo "/etc/shadow文件不存在相关安全属性,建议使用chattr +i或chattr +a防止/etc/shadow被删除或修改" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------14.4.3 gshadow文件属性---------------------
echo "[14.4.3]正在检查gshadow文件属性......" | $saveresult
flag=0
for ((x=1;x<=15;x++))
do
	apend=`lsattr /etc/gshadow | cut -c $x`
	if [ $apend = "i" ];then
		echo "/etc/gshadow文件存在i安全属性,符合要求" | $saveresult
		flag=1
	fi
	if [ $apend = "a" ];then
		echo "/etc/gshadow文件存在a安全属性" | $saveresult
		flag=1
	fi
done
if [ $flag = 0 ];then
	echo "/etc/gshadow文件不存在相关安全属性,建议使用chattr +i或chattr +a防止/etc/gshadow被删除或修改" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult


echo ------------14.4.4 group文件属性---------------------
echo "[14.4.4]正在检查group文件属性......" | $saveresult
flag=0
for ((x=1;x<=15;x++))
do
	apend=`lsattr /etc/group | cut -c $x`
	if [ $apend = "i" ];then
		echo "/etc/group文件存在i安全属性,符合要求" | $saveresult
		flag=1
	fi
	if [ $apend = "a" ];then
		echo "/etc/group文件存在a安全属性" | $saveresult
		flag=1
	fi
done
if [ $flag = 0 ];then
	echo "/etc/group文件不存在相关安全属性,建议使用chattr +i或chattr +a防止/etc/group被删除或修改" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult


echo ------------15 文件完整性----------------------
echo ------------15.1 系统文件完整性----------------------
#通过取出系统关键文件的MD5值,一方面可以直接将这些关键文件的MD5值通过威胁情报平台进行查询
#另一方面,使用该软件进行多次检查时会将相应的MD5值进行对比,若和上次不一样,则会进行提示

echo "[15.1]正在采集系统关键文件MD5....."
file="/tmp/linuxcheck_${ipadd}_${date}/sysfile_md5.txt"
if [ -e "$file" ]; then 
	md5sum -c "$file" 2>&1; 
else
	md5sum /usr/bin/awk >> $file
	md5sum /usr/bin/basename >> $file
	md5sum /usr/bin/bash >> $file
	md5sum /usr/bin/cat >> $file
	md5sum /usr/bin/chattr >> $file
	md5sum /usr/bin/chmod >> $file
	md5sum /usr/bin/chown >> $file
	md5sum /usr/bin/cp >> $file
	md5sum /usr/bin/csh >> $file
	md5sum /usr/bin/curl >> $file
	md5sum /usr/bin/cut >> $file
	md5sum /usr/bin/date >> $file
	md5sum /usr/bin/df >> $file
	md5sum /usr/bin/diff >> $file
	md5sum /usr/bin/dirname >> $file
	md5sum /usr/bin/dmesg >> $file
	md5sum /usr/bin/du >> $file
	md5sum /usr/bin/echo >> $file
	md5sum /usr/bin/ed >> $file
	md5sum /usr/bin/egrep >> $file
	md5sum /usr/bin/env >> $file
	md5sum /usr/bin/fgrep >> $file
	md5sum /usr/bin/file >> $file
	md5sum /usr/bin/find >> $file
	md5sum /usr/bin/gawk >> $file
	md5sum /usr/bin/GET >> $file
	md5sum /usr/bin/grep >> $file
	md5sum /usr/bin/groups >> $file
	md5sum /usr/bin/head >> $file
	md5sum /usr/bin/id >> $file
	md5sum /usr/bin/ipcs >> $file
	md5sum /usr/bin/kill >> $file
	md5sum /usr/bin/killall >> $file
	md5sum /usr/bin/kmod >> $file
	md5sum /usr/bin/last >> $file
	md5sum /usr/bin/lastlog >> $file
	md5sum /usr/bin/ldd >> $file
	md5sum /usr/bin/less >> $file
	md5sum /usr/bin/locate >> $file
	md5sum /usr/bin/logger >> $file
	md5sum /usr/bin/login >> $file
	md5sum /usr/bin/ls >> $file
	md5sum /usr/bin/lsattr >> $file
	md5sum /usr/bin/lynx >> $file
	md5sum /usr/bin/mail >> $file
	md5sum /usr/bin/mailx >> $file
	md5sum /usr/bin/md5sum >> $file
	md5sum /usr/bin/mktemp >> $file
	md5sum /usr/bin/more >> $file
	md5sum /usr/bin/mount >> $file
	md5sum /usr/bin/mv >> $file
	md5sum /usr/bin/netstat >> $file
	md5sum /usr/bin/newgrp >> $file
	md5sum /usr/bin/numfmt >> $file
	md5sum /usr/bin/passwd >> $file
	md5sum /usr/bin/perl >> $file
	md5sum /usr/bin/pgrep >> $file
	md5sum /usr/bin/ping >> $file
	md5sum /usr/bin/pkill >> $file
	md5sum /usr/bin/ps >> $file
	md5sum /usr/bin/pstree >> $file
	md5sum /usr/bin/pwd >> $file
	md5sum /usr/bin/readlink >> $file
	md5sum /usr/bin/rpm >> $file
	md5sum /usr/bin/runcon >> $file
	md5sum /usr/bin/sed >> $file
	md5sum /usr/bin/sh >> $file
	md5sum /usr/bin/sha1sum >> $file
	md5sum /usr/bin/sha224sum >> $file
	md5sum /usr/bin/sha256sum >> $file
	md5sum /usr/bin/sha384sum >> $file
	md5sum /usr/bin/sha512sum >> $file
	md5sum /usr/bin/size >> $file
	md5sum /usr/bin/sort >> $file
	md5sum /usr/bin/ssh >> $file
	md5sum /usr/bin/stat >> $file
	md5sum /usr/bin/strace >> $file
	md5sum /usr/bin/strings >> $file
	md5sum /usr/bin/su >> $file
	md5sum /usr/bin/sudo >> $file
	md5sum /usr/bin/systemctl >> $file
	md5sum /usr/bin/tail >> $file
	md5sum /usr/bin/tcsh >> $file
	md5sum /usr/bin/telnet >> $file
	md5sum /usr/bin/test >> $file
	md5sum /usr/bin/top >> $file
	md5sum /usr/bin/touch >> $file
	md5sum /usr/bin/tr >> $file
	md5sum /usr/bin/uname >> $file
	md5sum /usr/bin/uniq >> $file
	md5sum /usr/bin/users >> $file
	md5sum /usr/bin/vmstat >> $file
	md5sum /usr/bin/w >> $file
	md5sum /usr/bin/watch >> $file
	md5sum /usr/bin/wc >> $file
	md5sum /usr/bin/wget >> $file
	md5sum /usr/bin/whatis >> $file
	md5sum /usr/bin/whereis >> $file
	md5sum /usr/bin/which >> $file
	md5sum /usr/bin/who >> $file
	md5sum /usr/bin/whoami >> $file
	md5sum /usr/lib/systemd/s >> $file
	md5sum /usr/local/bin/rkh >> $file
	md5sum /usr/sbin/adduser >> $file
	md5sum /usr/sbin/chkconfi >> $file
	md5sum /usr/sbin/chroot >> $file
	md5sum /usr/sbin/depmod >> $file
	md5sum /usr/sbin/fsck >> $file
	md5sum /usr/sbin/fuser >> $file
	md5sum /usr/sbin/groupadd >> $file
	md5sum /usr/sbin/groupdel >> $file
	md5sum /usr/sbin/groupmod >> $file
	md5sum /usr/sbin/grpck >> $file
	md5sum /usr/sbin/ifconfig >> $file
	md5sum /usr/sbin/ifdown >> $file
	md5sum /usr/sbin/ifup >> $file
	md5sum /usr/sbin/init >> $file
	md5sum /usr/sbin/insmod >> $file
	md5sum /usr/sbin/ip >> $file
	md5sum /usr/sbin/lsmod >> $file
	md5sum /usr/sbin/lsof >> $file
	md5sum /usr/sbin/modinfo >> $file
	md5sum /usr/sbin/modprobe >> $file
	md5sum /usr/sbin/nologin >> $file
	md5sum /usr/sbin/pwck >> $file
	md5sum /usr/sbin/rmmod >> $file
	md5sum /usr/sbin/route >> $file
	md5sum /usr/sbin/rsyslogd >> $file
	md5sum /usr/sbin/runlevel >> $file
	md5sum /usr/sbin/sestatus >> $file
	md5sum /usr/sbin/sshd >> $file
	md5sum /usr/sbin/sulogin >> $file
	md5sum /usr/sbin/sysctl >> $file
	md5sum /usr/sbin/tcpd >> $file
	md5sum /usr/sbin/useradd >> $file
	md5sum /usr/sbin/userdel >> $file
	md5sum /usr/sbin/usermod >> $file
	md5sum /usr/sbin/vipw >> $file
fi
printf "\n" | $saveresult


echo ------------16 日志分析------------------------------
echo ------------16.1 查看日志配置与打包-------------------
echo ------------16.1.1 查看日志配置----------------------
echo "[16.1.1]正在查看日志配置....." | $saveresult
logconf=$(more /etc/rsyslog.conf | egrep -v "#|^$")
if [ -n "$logconf" ];then
	(echo "[*]日志配置如下:" && echo "$logconf") | $saveresult
else
	echo "[!!!]未发现日志配置文件" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.1.2日志是否存在---------------
echo "[16.1.2]正在分析日志文件是否存在....." | $saveresult
logs=$(ls -l /var/log/)
if [ -n "$logs" ];then
	echo "[*]日志文件存在" | $saveresult
else
	echo "[!!!]日志文件不存在,请分析是否被清除！" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.1.3 日志审核是否开启---------------
echo "[16.1.3]正在分析日志审核是否开启....." | $saveresult
service auditd status | grep running
if [ $? -eq 0 ];then
	echo "[*]系统日志审核功能已开启,符合要求" | $saveresult
else
	echo "[!!!]系统日志审核功能已关闭,不符合要求,建议开启日志审核。可使用以下命令开启:service auditd start" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.1.4 打包日志---------------
echo "[16.1.4]正在打包日志......" | $saveresult
zip -r ${log_file}system_log.zip /var/log/
if [ $? -eq 0 ];then
	echo "[*]日志打包成功" | $saveresult
else
	echo "[!!!]日志打包失败,请工人导出日志" | tee -a $danger_file | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.2secure日志分析---------------
echo ------------16.2.1成功登录--------------------
echo "[16.2.1]正在检查日志中成功登录的情况....." | $saveresult
loginsuccess=$(more /var/log/secure* | grep "Accepted password" | awk '{print $1,$2,$3,$9,$11}')
if [ -n "$loginsuccess" ];then
	(echo "[*]日志中分析到以下用户成功登录:" && echo "$loginsuccess")  | $saveresult
	(echo "[*]登录成功的IP及次数如下：" && grep "Accepted " /var/log/secure* | awk '{print $11}' | sort -nr | uniq -c )  | $saveresult
	(echo "[*]登录成功的用户及次数如下:" && grep "Accepted" /var/log/secure* | awk '{print $9}' | sort -nr | uniq -c )  | $saveresult
else
	echo "[*]日志中未发现成功登录的情况" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.2.2登录失败--------------------
echo "[16.2.2]存在检查日志中登录失败的情况....." | $saveresult
loginfailed=$(more /var/log/secure* | grep "Failed password" | awk '{print $1,$2,$3,$9,$11}')
if [ -n "$loginfailed" ];then
	(echo "[!!!]日志中发现以下登录失败的情况:" && echo "$loginfailed") |  tee -a $danger_file  | $saveresult
	(echo "[!!!]登录失败的IP及次数如下:" && grep "Failed password" /var/log/secure* | awk '{print $11}' | sort -nr | uniq -c)  | $saveresult
	(echo "[!!!]登录失败的用户及次数如下:" && grep "Failed password" /var/log/secure* | awk '{print $9}' | sort -nr | uniq -c)  | $saveresult
else
	echo "[*]日志中未发现登录失败的情况" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.2.3本机登录情况-----------------
echo "[16.2.4]正在检查图本机登录情况....." | $saveresult
systemlogin=$(more /var/log/secure* | grep -E "sshd:session.*session opened" | awk '{print $1,$2,$3,$11}')
if [ -n "$systemlogin" ];then
	(echo "[*]本机登录情况:" && echo "$systemlogin") | $saveresult
	(echo "[*]本机登录账号及次数如下:" && more /var/log/secure* | grep -E "sshd:session.*session opened" | awk '{print $11}' | sort -nr | uniq -c) | $saveresult
else
	echo "[!!!]未发现在本机登录退出情况,请注意！！！" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.2.4新增用户-------------------
echo "[16.2.4]正在检查新增用户....." | $saveresult
newusers=$(more /var/log/secure* | grep "new user"  | awk -F '[=,]' '{print $1,$2}' | awk '{print $1,$2,$3,$9}')
if [ -n "$newusers" ];then
	(echo "[!!!]日志中发现新增用户:" && echo "$newusers") | tee -a $danger_file | $saveresult
	(echo "[*]新增用户账号及次数如下:" && more /var/log/secure* | grep "new user" | awk '{print $8}' | awk -F '[=,]' '{print $2}' | sort | uniq -c) | $saveresult
else
	echo "[*]日志中未发现新增加用户" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.2.5新增用户组-----------------
echo "[16.2.5]正在检查新增用户组....." | $saveresult
newgoup=$(more /var/log/secure* | grep "new group"  | awk -F '[=,]' '{print $1,$2}' | awk '{print $1,$2,$3,$9}')
if [ -n "$newgoup" ];then
	(echo "[!!!]日志中发现新增用户组:" && echo "$newgoup") | tee -a $danger_file | $saveresult
	(echo "[*]新增用户组及次数如下:" && more /var/log/secure* | grep "new group" | awk '{print $8}' | awk -F '[=,]' '{print $2}' | sort | uniq -c) | $saveresult
else
	echo "[*]日志中未发现新增加用户组" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.3message日志分析---------------
echo ------------16.3.1传输文件--------------------
#下面命令仅显示传输的文件名,并会将相同文件名的去重
#more /var/log/message* | grep "ZMODEM:.*BPS" | awk -F '[]/]' '{print $0}' | sort | uniq
echo "[16.3.1]正在检查传输文件....." | $saveresult
zmodem=$(more /var/log/message* | grep "ZMODEM:.*BPS")
if [ -n "$zmodem" ];then
	(echo "[!!!]传输文件情况:" && echo "$zmodem") | tee -a $danger_file | $saveresult
else
	echo "[*]日志中未发现传输文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.3.2历史使用DNS服务器------------
echo "[16.3.2]正在检查日志中使用DNS服务器的情况....." | $saveresult
dns_history=$(more /var/log/messages* | grep "using nameserver" | awk '{print $NF}' | awk -F# '{print $1}' | sort | uniq)
if [ -n "$dns_history" ];then
	(echo "[!!!]该服务器曾经使用以下DNS:" && echo "$dns_history") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现使用DNS服务器" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.4cron日志分析---------------
echo ------------16.4.1定时下载-----------------
echo "[16.4.1]正在分析定时下载....." | $saveresult
cron_download=$(more /var/log/cron* | grep "wget|curl")
if [ -n "$cron_download" ];then
	(echo "[!!!]定时下载情况:" && echo "$cron_download") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现定时下载情况" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.4.2定时执行脚本-----------------
echo "[16.4.2]正在分析定时执行脚本....." | $saveresult
cron_shell=$(more /var/log/cron* | grep -E "\.py$|\.sh$|\.pl$") 
if [ -n "$cron_shell" ];then
	(echo "[!!!]发现定时执行脚本:" && echo "$cron_download") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现定时下载脚本" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.5yum日志分析----------------------
echo ------------16.5.1下载软件情况-------------------
echo "[16.5.1]正在分析使用yum下载软件情况....." | $saveresult
yum_install=$(more /var/log/yum* | grep Installed | awk '{print $NF}' | sort | uniq)
if [ -n "$yum_install" ];then
	(echo "[*]曾使用yum下载以下软件:"  && echo "$yum_install") | $saveresult
else
	echo "[*]未使用yum下载过软件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.5.2下载脚本文件-------------------
echo "[16.5.2]正在分析使用yum下载脚本文件....." | $saveresult
yum_installscripts=$(more /var/log/yum* | grep Installed | grep -E "(\.sh$\.py$|\.pl$)" | awk '{print $NF}' | sort | uniq)
if [ -n "$yum_installscripts" ];then
	(echo "[*]曾使用yum下载以下脚本文件:"  && echo "$yum_installscripts") | $saveresult
else
	echo "[*]未使用yum下载过脚本文件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.5.3卸载软件情况-------------------
echo "[16.5.3]正在检查使用yum卸载软件情况....." | $saveresult
yum_erased=$(more /var/log/yum* | grep Erased)
if [ -n "$yum_erased" ];then
	(echo "[*]使用yum曾卸载以下软件:" && echo "$yum_erased")  | $saveresult
else
	echo "[*]未使用yum卸载过软件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.5.4可疑工具-----------------
echo "[16.5.4]正在检查使用yum安装的可疑工具....." | $saveresult
hacker_tools=$(more /var/log/yum* | awk -F: '{print $NF}' | awk -F '[-]' '{print $1}' | sort | uniq | grep -E "(^nc|sqlmap|nmap|beef|nikto|john|ettercap|backdoor|proxy|msfconsole|msf)")
if [ -n "$hacker_tools" ];then
	(echo "[!!!]发现使用yum下载过以下可疑软件:" && echo "$hacker_tools") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现使用yum下载过可疑软件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.6 dmesg日志分析----------------------
echo ------------16.6.1 内核自检日志---------------------
echo "[16.6.1]正在查看内核自检日志....." | $saveresult
dmesg=$(dmesg)
if [ $? -eq 0 ];then
	(echo "[*]日志自检日志如下：" && "$dmesg" ) | $saveresult
else
	echo "[*]未发现内核自检日志" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.7 btmp日志分析----------------------
echo ------------16.7.1 错误登录日志分析-----------------
echo "[16.7.1]正在分析错误登录日志....." | $saveresult
lastb=$(lastb)
if [ -n "$lastb" ];then
	(echo "[*]错误登录日志如下:" && echo "$lastb") | $saveresult
else
	echo "[*]未发现错误登录日志" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.8 lastlog日志分析----------------------
echo ------------16.8.1 所有用户最后一次登录日志分析-----------------
echo "[16.8.1]正在分析所有用户最后一次登录日志....." | $saveresult
lastlog=$(lastlog)
if [ -n "$lastlog" ];then
	(echo "[*]所有用户最后一次登录日志如下:" && echo "$lastlog") | $saveresult
else
	echo "[*]未发现所有用户最后一次登录日志" | $saveresult
fi
printf "\n" | $saveresult

echo ------------16.9 wtmp日志分析---------------
echo ------------16.9.1所有登录用户分析-------
echo "[16.9.1]正在检查历史上登录到本机的用户:" | $saveresult
lasts=$(last | grep pts | grep -vw :0)
if [ -n "$lasts" ];then
	(echo "[*]历史上登录到本机的用户如下:" && echo "$lasts") | $saveresult
else
	echo "[*]未发现历史上登录到本机的用户信息" | $saveresult
fi
printf "\n" | $saveresult

echo ------------17 内核检查-------------------
echo ------------17.1 内核情况-----------------
echo "[17.1]正在检查内核信息......" | $saveresult
lsmod=$(lsmod)
if [ -n "$lsmod" ];then
	(echo "[*]内核信息如下:" && echo "$lsmod") | $saveresult
else
	echo "[*]未发现内核信息" | $saveresult
fi
printf "\n" | $saveresult

echo ------------17.2 可疑内核检查-----------------
echo "[17.2]正在检查可疑内核....." | $saveresult
danger_lsmod=$(lsmod | grep -Ev "ablk_helper|ac97_bus|acpi_power_meter|aesni_intel|ahci|ata_generic|ata_piix|auth_rpcgss|binfmt_misc|bluetooth|bnep|bnx2|bridge|cdrom|cirrus|coretemp|crc_t10dif|crc32_pclmul|crc32c_intel|crct10dif_common|crct10dif_generic|crct10dif_pclmul|cryptd|dca|dcdbas|dm_log|dm_mirror|dm_mod|dm_region_hash|drm|drm_kms_helper|drm_panel_orientation_quirks|e1000|ebtable_broute|ebtable_filter|ebtable_nat|ebtables|edac_core|ext4|fb_sys_fops|floppy|fuse|gf128mul|ghash_clmulni_intel|glue_helper|grace|i2c_algo_bit|i2c_core|i2c_piix4|i7core_edac|intel_powerclamp|ioatdma|ip_set|ip_tables|ip6_tables|ip6t_REJECT|ip6t_rpfilter|ip6table_filter|ip6table_mangle|ip6table_nat|ip6table_raw|ip6table_security|ipmi_devintf|ipmi_msghandler|ipmi_si|ipmi_ssif|ipt_MASQUERADE|ipt_REJECT|iptable_filter|iptable_mangle|iptable_nat|iptable_raw|iptable_security|iTCO_vendor_support|iTCO_wdt|jbd2|joydev|kvm|kvm_intel|libahci|libata|libcrc32c|llc|lockd|lpc_ich|lrw|mbcache|megaraid_sas|mfd_core|mgag200|Module|mptbase|mptscsih|mptspi|nf_conntrack|nf_conntrack_ipv4|nf_conntrack_ipv6|nf_defrag_ipv4|nf_defrag_ipv6|nf_nat|nf_nat_ipv4|nf_nat_ipv6|nf_nat_masquerade_ipv4|nfnetlink|nfnetlink_log|nfnetlink_queue|nfs_acl|nfsd|parport|parport_pc|pata_acpi|pcspkr|ppdev|rfkill|sch_fq_codel|scsi_transport_spi|sd_mod|serio_raw|sg|shpchp|snd|snd_ac97_codec|snd_ens1371|snd_page_alloc|snd_pcm|snd_rawmidi|snd_seq|snd_seq_device|snd_seq_midi|snd_seq_midi_event|snd_timer|soundcore|sr_mod|stp|sunrpc|syscopyarea|sysfillrect|sysimgblt|tcp_lp|ttm|tun|uvcvideo|videobuf2_core|videobuf2_memops|videobuf2_vmalloc|videodev|virtio|virtio_balloon|virtio_console|virtio_net|virtio_pci|virtio_ring|virtio_scsi|vmhgfs|vmw_balloon|vmw_vmci|vmw_vsock_vmci_transport|vmware_balloon|vmwgfx|vsock|xfs|xt_CHECKSUM|xt_conntrack|xt_state")
if [ -n "$danger_lsmod" ];then
	(echo "[!!!]发现可疑内核模块:" && echo "$danger_lsmod") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现可疑内核模块" | $saveresult
fi
printf "\n" | $saveresult

echo ------------18 安装软件-------------------
echo ------------18.1 安装软件及版本-----------------
echo "[18.1]正在检查安装软件及版本情况....." | $saveresult
software=$(rpm -qa | awk -F- '{print $1,$2}' | sort -nr -k2 | uniq)
if [ -n "$software" ];then
	(echo "[*]系统安装与版本如下:" && echo "$software") | $saveresult
else
	echo "[*]系统未安装软件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------18.2可疑软件-----------------
echo "[18.2]正在检查安装的可疑软件....." | $saveresult
danger_soft=$(rpm -qa  | awk -F- '{print $1}' | sort | uniq | grep -E "^(ncat|sqlmap|nmap|beef|nikto|john|ettercap|backdoor|proxy|msfconsole|msf)$")
if [ -n "$danger_soft" ];then
	(echo "[!!!]以下安装的软件可疑,需要人工分析:"  && echo "$danger_soft") | tee -a $danger_file | $saveresult
else
	echo "[*]未发现安装可疑软件" | $saveresult
fi
printf "\n" | $saveresult

echo ------------19环境变量-----------------
echo "[18]正在检查环境变量....." | $saveresult
env=$(env)
if [ -n "$env" ];then
	(echo "[*]环境变量:" && echo "$env") | $saveresult
else
	echo "[*]未发现环境变量" | $saveresult
fi
printf "\n" | $saveresult

echo ------------20性能分析-----------------
echo ------------20.1磁盘分析-----------------
echo ------------20.1.1磁盘使用-----------------
echo "[20.1.1]正在检查磁盘使用....." | $saveresult
echo "[*]磁盘使用情况如下:" && df -h  | $saveresult
printf "\n" | $saveresult

echo ------------20.1.2检查磁盘使用过大-----------------
echo "[20.1.2]正在检查磁盘使用是否过大....." | $saveresult
#使用超过70%告警
df=$(df -h | awk 'NR!=1{print $1,$5}' | awk -F% '{print $1}' | awk '{if ($2>70) print $1,$2}')
if [ -n "$df" ];then
	(echo "[!!!]硬盘空间使用过高，请注意！！！" && echo "$df" ) | tee -a $danger_file | $saveresult
else
	echo "[*]硬盘空间足够" | $saveresult
fi
printf "\n" | $saveresult

echo ------------20.2CPU分析-----------------
echo ------------20.2.1CPU情况-----------------
echo "[20.2.1]正在检查CPU相关信息....." | $saveresult
(echo "CPU硬件信息如下:" && more /proc/cpuinfo ) | $saveresult
(echo "CPU使用情况如下:" && ps -aux | sort -nr -k 3 | awk  '{print $1,$2,$3,$NF}') | $saveresult
printf "\n" | $saveresult

echo ------------20.2.2占用CPU前5进程-----------------
echo "[20.2.2]正在检查占用CPU前5资源的进程....." | $saveresult
(echo "占用CPU资源前5进程：" && ps -aux | sort -nr -k 3 | head -5)  | $saveresult
printf "\n" | $saveresult

echo ------------20.2.3占用CPU较大进程-----------------
echo "[20.2.3]正在检查占用CPU较大的进程....." | $saveresult
pscpu=$(ps -aux | sort -nr -k 3 | head -5 | awk '{if($3>=20) print $0}')
if [ -n "$pscpu" ];then
	echo "[!!!]以下进程占用的CPU超过20%:" && echo "UID         PID   PPID  C STIME TTY          TIME CMD" 
	echo "$pscpu" | tee -a 20.2.3_pscpu.txt | tee -a $danger_file | $saveresult
else
	echo "[*]未发现进程占用资源超过20%" | $saveresult
fi
printf "\n" | $saveresult

echo ------------20.3 内存分析-----------------
echo ------------20.3.1 内存情况-----------------
echo "[20.3.1]正在检查内存相关信息....." | $saveresult
(echo "[*]内存信息如下:" && more /proc/meminfo) | $saveresult
(echo "[*]内存使用情况如下:" && free -m) | $saveresult
printf "\n" | $saveresult

echo ------------20.3.2占用内存前5进程-----------------
echo "[20.2.2]正在检查占用内存前5资源的进程....." | $saveresult
(echo "[*]占用内存资源前5进程：" && ps -aux | sort -nr -k 4 | head -5) | $saveresult
printf "\n" | $saveresult

echo ------------20.3.3占用内存较多进程-----------------
echo "[20.3.3]正在检查占用内存较多的进程....." | $saveresult
psmem=$(ps -aux | sort -nr -k 4 | head -5 | awk '{if($4>=2) print $0}')
if [ -n "$psmem" ];then
	echo "[!!!]以下进程占用的内存超过20%:" && echo "UID         PID   PPID  C STIME TTY          TIME CMD"
	echo "$psmem" | tee -a $danger_file | $saveresult
else
	echo "[*]未发现进程占用内存资源超过20%" | $saveresult
fi
printf "\n" | $saveresult

echo ------------20.4网络连接-----------------
echo "[20.4]正在检查网络连接情况......" | $saveresult
netstat=$(netstat -anlp | grep ESTABLISHED)
netstatnum=$(netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}')
if [ -n "$netstat" ];then
	(echo "[*]网络连接情况:" && echo "$netstat") | $saveresult
	if [ -n "$netstatnum" ];then
		(echo "[*]各个状态的数量如下:" && echo "$netstatnum")  | $saveresult
	fi
else
	echo "[*]未发现网络连接" | $saveresult
fi
printf "\n" | $saveresult

echo ------------20.5 其他----------------------
echo ------------20.5.1 运行时间及负载-----------------
echo "[20.5.1]正在检查系统运行时间及负载情况......" | $saveresult
(echo "[*]系统运行时间如下:" && uptime) | $saveresult
printf "\n" | $saveresult

echo "[*]正在将检查文件压缩到/tmp/目录下......"
zip -r /tmp/linuxcheck_${ipadd}_${date}.zip /tmp/linuxcheck_${ipadd}_${date}/*

echo "检查结束！！！"
echo "Version:1.2"
echo "Date:2022-11-28"

Linux的root密码恢复

Fri, 09 Dec 2022 15:09:36 CST

theme: condensed-night-purple

本文正在参加「金石计划 . 瓜分6万现金大奖」

恢复root密码

centos恢复密码

1.首先，启动系统，进入开机界面，先让光标停在上面这个内核(Core)上,在界面中按“e”进入编辑界面

进入编辑界面，使用键盘上的上下键把光标往下移动，找到以““Linux16”开头内容所在的行数”，在行的UTF-8最后面输入：init=/bin/sh。
输入完成后，直接按快捷键：Ctrl+x 进入单用户模式。
接着，在光标闪烁的位置中输入：
```
    mount -o remount,rw /
```
以读写方式在/上重新挂载文件系统

回车

在新的一行最后面输入：passwd，完成后按键盘的回车键（Enter）。
输入密码，然后再次确认密码即可密码修改成功后，会显示passwd.....的样式
最后一行中输入：
```
    touch  /.autorelabel
```
回车
输入：
```
    exec /sbin/init
```
回车

漫长等待，且切记不要随意点击！！！

redhat恢复密码

我们将重置root密码，我们想达到的结果是能够重置丢失的超级用户密码，而不需要对机器进行另一种形式的超级用户访问。

假设我们没有对servera上的root帐户的无密码ssh访问权限，并且servera上的学生帐户没有完全的sudo访问权限。

打开servera的控制台，并重新启动它。进入grub菜单，强制系统在执行初始ram disk时暂停启动。

1.1 从控制台重新启动服务器。

1.2. 出现grub菜单倒计时时，按任意键暂停倒计时。

1.3. 突出显示默认条目，并按e键编辑它。

1.4 向下滚动到以linux16开头的行，按End跳转到行尾，删除最后一个 console=，并追加rd.break。

1.5 按Ctrl+X以这些修改后的设置启动

将系统上的root密码改为redhat，注意不要干扰任何SELinux上下文。

2.1 以读写方式在/sysroot上重新挂载文件系统

2.2 将root切换到/sysroot目录

2.3. 将root密码设置为redhat。

2.4 加载默认的SELinux策略。如果失败，请确保系统将在下次重新启动时执行完整的重新标记。

2.5 递归恢复/etc上的SELinux上下文。

在更改root密码之前加载SELinux策略会导致在尝试更新root密码时被拒绝。设置密码然后再加载策略并修复上下文，证实有效。如果您忘记更新上下文，那么在重新启动后，将导致没有本地用户可以登录，因为/etc/shadow上将有一个无效的安全上下文。

重新启动servera系统，并验证您可以使用该密码以root用户身份登录redhat。

按Ctrl+D两次，以来重新启动servera系统。

如果你必须上一步中新建文件 /.autorelabel那么你的系统现在将重新启动两次;否则，只需发生一次重启。

尝试以root用户身份使用密码redhat登录控制台。

Linux网络丢包排查 - 墨天轮

Thu, 27 Oct 2022 14:56:59 CST

一、简介

工作中遇到的服务器，最常用的操作系统就是linux系统，linux 系统使用网络适配器和外部进行数据交换。当在高速链路或异常环境下进行网络通信时，就有可能出现网络数据丢包现象，接下来我主要要说的是：网路丢包的故障定位思路和解决方法。

二、相关原理介绍

1 、网络消息的收发（报文收发过程）

在说丢包故障定位之前，我先来了介绍“网络报文收发过程”。本文以接收报文为例，发送报文与之类似，只是报文的传输方向相反。

1、网络packet首先通过网线被网卡获取，网卡检查packet的crc正常后，去掉packet头得到frame，如果frame中MAC的目的地址为本机地址，则接受该报文，否则丢弃（在混杂模式下也会接收该报文）

2、网卡将frame拷贝到网卡内部缓冲区中，一般是网卡的ring buffer中，拷贝完成后触发软中断通知内核处理

3、内核从ring buffer中拷贝网络数据，并传递给网络协议栈进行解析

4、协议栈解析完成后将数据放入ocket套接字的buffer中，最终传递给上层应用

2 、相关名词解释

Bash代码

      enp125s0f0:flags=4163  mtu 1500      
      inet90.90.160.163  netmask 255.255.252.0  broadcast 90.90.163.255      
      inet6fe80::903a:4e71:69cd:eb09  prefixlen 64  scopeid 0x20      
      ether08:4f:0a:04:85:ac  txqueuelen 1000  (Ethernet)      
      RXpackets 28356  bytes 4397271 (4.1 MiB)      
      RXerrors 0  dropped 15869  overruns 0  frame 0      
      TXpackets 3003  bytes 450378 (439.8 KiB)      
      TXerrors 0  dropped 0 overruns 0  carrier 0  collisions 0

RX errors：表示总的收包的错误数量

RX dropped：表示数据包已进入Ring buffer，但是由于系统原因(如内存不足)导致在拷贝到内存中的过程中被丢弃

RX overruns：表示数据还未进入网卡缓存(Ring buffer)时就被丢弃了，一般是由于Ring buffer中的数据未被及时取出导致溢出，新来的数据只能被丢弃。例如CPU负载大，导致处理网卡数据的速度小于网卡接收数据的速度，Ring buffer溢出。

RX frame：表示misaligend的frames数量

三、丢包故障定位与解决

1 、网卡丢包

首先检查丢包是否是因为crc校验错误导致的：

Bash代码

      [root@localhost ~]# ethtool -S enp1s0f0 | grep crc      
      rx_crc_errors_phy:0

如果crc字段为非0，则表示网络报文在传输时出现了差错，此时可以更换线缆或网卡再做验证。

如果丢包发生在网卡上，则可以通过ethtool -S eth0 | egrep-i drop|error确认

Bash代码

      [root@localhost ~]# ethtool -S enp125s0f0 | egrep -ierror|drop      
      rxq#0_rx_dropped: 0      
      rxq#0_errors: 0      
      rx_oq_drop_pkt_cnt:0

netstat -i也可以提供网卡的收发报文和丢包情况，正常情况下error、drop和overrun字段应该为0

Bash代码

如果RX_OVR一直在增加，说明Ringbuffer有溢出，除了Ring Buffer太小以外，有可能是CPU处于高负荷下，来不及从Ring buffer中获取数据，此时可以检查CPU高负荷的原因，对网卡进行中断亲和设置等操作。通过查看/proc/net/dev也可以查看是否有Ring buffer满而导致的丢包

[root@localhost~]# netstat -i

      KernelInterface table      
      IfaceMTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg      
      enp125s0f01500    29113      0  16149 0          3258      0      0      0 BMRU      
      enp125s0f11500        0      0      0 0             0      0      0      0 BMU      
      enp125s0f21500        0      0      0 0             0      0      0      0 BMU      
      enp125s0f31500        0      0      0 0             0      0      0      0 BMRU      
      enp1s0f01500        0      0      0 0             0      0      0      0 BMU      
              
      
              
      
      enp1s0f11500        0      0      0 0             0      0      0      0 BMU      
      lo65536     1820      0      0 0          1820      0      0      0 LRU

如果硬件或者驱动没有问题，一般网卡丢包是由于Ring buffer太小导致，可以使用ethtool -G修改Ring buffer大小。

Bash代码

      [root@localhost~]# cat proc/net/dev      
      Inter-|Receive                                                |  Transmit      
            
      face|bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed      
      enp125s0f1:0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0      
              
      
              
      
      enp125s0f3:0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0      
      enp125s0f2:0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0      
      enp1s0f1:0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0      
      enp1s0f0:0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0      
      lo:169176    1948    0    0    0     0          0         0   169176    1948    0    0    0     0       0          0      
      enp125s0f0:4880071   32037    0 18238    0     0          0     40408   486664    3302    0    0    0     0       0          0

2 、内核丢包其中的fifo字段统计的是Ringbuffer满而丢弃的包

内核从网卡收到数据以后，交给协议栈处理之前会有缓冲队列backlog，每个CPU都有一个backlog队列，当从网卡中获取数据到backlog中的速率大于从backlog中将数据交给协议栈的速率时就会发生溢出。可以查看/proc/net/softnet_stat文件确认是否有backlog溢出：

Bash代码

      [root@localhost~]# cat proc/net/softnet_stat      
      0000000300000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000      
      0000000000000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

每一行代表一个CPU core接收数据的情况
第1列表示收到的包总数
第2列是丢弃的包计数，此处的丢包指的是从网卡Ring buffer中输出到内核缓存队列时，由于队列满了而丢弃的数据包
第3列表示软中断一次取走netdev_budget个数据包，或取数据包时间超过2ms的次数
第4列~第8列固定为0，没有意义
第9列表示发送数据包时，对应的队列被锁住的次数

如果是因为backlog队列溢出导致的丢包，可以修改backlog队列的大小，通过systctl修改netdev maxbacklog参数，默认大小为1000

Bash代码

sysctl -w net.core.netdev_max_backlog=2000

在将数据交给内核协议栈后，协议栈进行分析处理。在协议栈中也有可能丢包，通过netstat-s可以查看是否有协议栈丢包，-u参数指定udp协议，-t参数指定tcp协议，也可以加-c参数持续输出，看各个数据的变化，本文以UDP协议为例进行讲解

Bash代码

      [root@localhost~]# netstat -s -u      
      IcmpMsg:      
      InType3:1006      
      OutType3:1006      
      Udp:      
      0packetsreceived      
      1006packetsto unknown port received.      
      0packetreceive errors      
      1081packetssent      
      0receivebuffer errors      
      0sendbuffer errors      
      UdpLite:      
      IpExt:      
      InMcastPkts:3245      
      OutMcastPkts:11      
      InBcastPkts:6213      
      InOctets:2859135      
      OutOctets:633832      
      InMcastOctets:495247      
      OutMcastOctets:2658      
      InBcastOctets:2038580      
      InNoECTPkts:13895      
      [root@localhost~]#

packet receive errors表示接收有丢包
packets to unknown port received表示系统接收到的UDP报文的目标端口没有应用在监听，一般影响不严重
receive/send buffer errors表示收发队列太小导致的丢包数量

对于收发队列太小导致的丢包，可以通过调整收发队列参数来解决，系统默认的receive/sendbuffer大小如下：

Bash代码

      [root@localhost ~]# sysctlnet.core.rmem_default      
      net.core.rmem_default =229376      
      [root@localhost ~]# sysctlnet.core.wmem_default      
      net.core.wmem_default =229376

可以使用以下命令修改buffer大小

Bash代码

      sysctl-w net.core.rmem_max=26214400# 设置为 25M      
      sysctl -w net.core.wmem_max=26214400# 设置为 25M

通过查看/proc/net/snmp文件也可以查看各个协议的收发包情况：

Bash代码

      Ip: Forwarding DefaultTTL InReceives InHdrErrorsInAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequestsOutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKsFragFails FragCreates      
      Ip: 2 64 14757 0 28 0 0 0 4844 5745 512 0 0 0 0 0 0 00      
      Icmp: InMsgs InErrors InCsumErrors InDestUnreachsInTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoRepsInTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrorsOutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchosOutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps      
      Icmp: 1038 0 0 1038 0 0 0 0 0 0 0 0 0 0 1038 0 1038 00 0 0 0 0 0 0 0 0      
      IcmpMsg: InType3 OutType3      
      IcmpMsg: 1038 1038      
      Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpensPassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegsInErrs OutRsts InCsumErrors      
      Tcp: 1 200 120000 -1 0 2 0 0 2 2768 3592 0 0 0 0      
      Udp: InDatagrams NoPorts InErrors OutDatagramsRcvbufErrors SndbufErrors InCsumErrors IgnoredMulti      
      Udp: 0 1038 0 1113 0 0 0 0      
      UdpLite: InDatagrams NoPorts InErrors OutDatagramsRcvbufErrors SndbufErrors InCsumErrors IgnoredMulti      
      UdpLite: 0 0 0 0 0 0 0 0/

3 、应用丢包

内核协议栈把接收到的报文放到socket套接字的buffer中，应用程序从buffer中不断读取报文。所以这里有两个和应用程序有关的因素会影响丢包：socket buffer的大小和应用程序报文读取速度。

socket buffer大小可在应用程序初始化socket时设置，不过增大buffer的值会增加内存的使用，请根据实际情况配置；对于应用程序报文处理速度，应采用异步方式处理

四、其他定位方法

1 、dropwatch

dropwatch可以输出数据包是在哪个内核函数中丢失的：

Bash代码

      [root@localhost~]# dropwatch -l kas      
      Initalizingkallsyms db      
      dropwatch>start      
      Enablingmonitoring...      
      Kernelmonitoring activated.      
      IssueCtrl-C to stop monitoring      
      1drops at skb_queue_purge+20 (0xffff000008708d3c)      
      2drops at __netif_receive_skb_core+504(0xffff00000871bd7c)      
      1drops at __netif_receive_skb_core+504(0xffff00000871bd7c)

Linux丢包故障的解决与思路 - Albert的博客 | Albert's Blog

Thu, 27 Oct 2022 14:43:39 CST

Linux丢包故障的解决与思路

前言

本文为大部分内容是转载: 原文地址，和之前一样，在原文的基础上进行了一些格式的调整，包括一些错别字的修正，以及进行了一些博文链接的插入，以便于读者或者我自己更好的理解。

我们使用 Linux作为服务器操作系统时，为了达到高并发处理能力，充分利用机器性能，经常会进行一些内核参数的调整优化，但不合理的调整常常也会引起意想不到的其他问题，本文就一次 Linux服务器丢包故障的处理过程，结合 Linux内核参数说明和 TCP/IP协议栈相关的理论，介绍一些常见的丢包故障定位方法和解决思路。

在开始之前，我们先用一张图解释 linux 系统接收网络报文的过程。

首先网络报文通过物理网线发送到网卡

网络驱动程序会把网络中的报文读出来放到 ring buffer 中，这个过程使用 DMA（Direct Memory Access），这个过程不需要 CPU 参与

内核从 ring buffer 中读取报文进行处理，执行 IP 和 TCP/UDP 层的逻辑，最后把报文放到应用程序的 socket buffer 中

应用程序从 socket buffer 中读取报文进行处理

在接收 UDP 报文的过程中，图中任何一个过程都可能会主动或者被动地把报文丢弃，因此丢包可能发生在网卡和驱动，也可能发生在系统和应用。之所以没有分析发送数据流程，一是因为发送流程和接收类似，只是方向相反；另外发送流程报文丢失的概率比接收小，只有在应用程序发送的报文速率大于内核和网卡处理速率时才会发生。本篇文章假定机器只有一个名字为 eth0 的 interface，如果有多个 interface 或者 interface 的名字不是 eth0，请按照实际情况进行分析。

NOTE：文中出现的 RX（receive）表示接收报文，TX（transmit）表示发送报文。

一、问题现象

本次故障的反馈现象是：从办公网访问公网服务器不稳定，服务器某些端口访问经常超时，但 Ping测试显示客户端与服务器的链路始终是稳定低延迟的。通过在服务器端抓包，发现还有几个特点：

从办公网访问服务器有多个客户端，是同一个出口IP，有少部分是始终能够稳定连接的，另一部分间歇访问超时或延迟很高

同一时刻的访问，无论哪个客户端的数据包先到达，服务端会及时处理部分客户端的SYN请求，对另一部分客户端的SYN包“视而不见”，如tcpdump数据所示，源端口为56909的SYN请求没有得到响应，同一时间源端口为50212的另一客户端SYN请求马上得到响应。

          $ sudo tcpdump -i eth0 port 22 and "tcp[tcpflags] & (tcp-syn) != 0"
18:56:37.404603 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321481 ecr 0,nop,wscale 7], length 0
18:56:38.404582 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321731 ecr 0,nop,wscale 7], length 0
18:56:40.407289 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198322232 ecr 0,nop,wscale 7], length 0
18:56:44.416108 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198323234 ecr 0,nop,wscale 7], length 0
18:56:45.100033 IP CLIENT.50212 > SERVER.22: Flags [S], seq 4207350463, win 65535, options [mss 1366,nop,wscale 5,nop,nop,TS val 821068631 ecr 0,sackOK,eol], length 0
18:56:45.100110 IP SERVER.22 > CLIENT.50212: Flags [S.], seq 1281140899, ack 4207350464, win 27960, options [mss 1410,sackOK,TS val 1709997543 ecr 821068631,nop,wscale 7], length 0
18:56:52.439086 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198325240 ecr 0,nop,wscale 7], length 0
18:57:08.472825 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198329248 ecr 0,nop,wscale 7], length 0
18:57:40.535621 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198337264 ecr 0,nop,wscale 7], length 0
18:57:40.535698 IP SERVER.22 > CLIENT.56909: Flags [S.], seq 3621462255, ack 1190606851, win 27960, options [mss 1410,sackOK,TS val 1710011402ecr 198337264,nop,wscale 7], length 0

如果能排除网卡或者驱动丢包可能的话， linux系统丢包的原因相对就很多，常见的有： UDP报文错误、防火墙、 UDP buffer size不足、系统负载过高等，这里对这些丢包原因进行分析。

二、名词解释

          # ifconfig em2
em2       Link encap:Ethernet  HWaddr AC::3D:A9::0D
          inet addr:211.211.211.211  Bcast:211.211.211.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:  Metric:
          RX packets: errors: dropped: overruns: frame:
          TX packets: errors: dropped: overruns: carrier:
          collisions: txqueuelen:
          RX bytes: ( (1.3 TiB)
          Memory:94b00000-94b20000

RX errors: 表示总的收包的错误数量，这包括 too-long-frames 错误，Ring Buffer 溢出错误，crc 校验错误，帧同步错误，fifo overruns 以及 missed pkg 等等。
RX dropped: 表示数据包已经进入了 Ring Buffer，但是由于 内存不够等系统原因，导致在拷贝到内存的过程中被丢弃。
RX overruns: 表示了 fifo 的 overruns，这是由于 Ring Buffer(aka Driver Queue) 传输的 IO 大于 kernel 能够处理的 IO 导致的，而 Ring Buffer 则是指在发起 IRQ 请求之前的那块 buffer。很明显，overruns 的增大意味着数据包没到 Ring Buffer 就被网卡物理层给丢弃了，而 CPU 无法即使的处理中断是造成 Ring Buffer 满的原因之一，上面那台有问题的机器就是因为 interruprs分布的不均匀(都压在 core0)，没有做 affinity而造成的丢包。
RX frame: 表示 misaligned的 frames

对于 TX 的来说，出现上述 counter 增大的原因主要包括 aborted transmission, errors due to carrirer, fifo error, heartbeat erros 以及 windown error，而 collisions 则表示由于 CSMA/CD 造成的传输中断。

dropped与 overruns的区别

dropped：表示这个数据包已经进入到网卡的接收缓存 fifo队列，并且开始被系统中断处理准备进行数据包拷贝（从网卡缓存 fifo队列拷贝到系统内存），但由于此时的系统原因（比如内存不够等）导致这个数据包被丢掉，即这个数据包被 Linux系统丢掉。

overruns：表示这个数据包还没有被进入到网卡的接收缓存fifo队列就被丢掉，因此此时网卡的fifo是满的。为什么fifo会是满的？因为系统繁忙，来不及响应网卡中断，导致网卡里的数据包没有及时的拷贝到系统内存，fifo是满的就导致后面的数据包进不来，即这个数据包被网卡硬件丢掉。所以，个人觉得遇到 overruns非0，需要检测cpu负载与cpu中断情况

三、排查过程

3.1、丢包的可能性

服务器能正常接收到数据包，问题可以限定在 两种可能：

部分客户端发出的数据包本身异常；

服务器处理部分客户端的数据包时触发了某种机制丢弃了数据包。因为出问题的客户端能够正常访问公网上其他服务，后者的可能性更大。

有哪些情况会导致Linux服务器丢弃数据包？

3.2 、确认有 UDP 丢包发生

要查看网卡是否有丢包，可以使用 ethtool -S eth0查看，在输出中查找 bad 或者 drop 对应的字段是否有数据，在正常情况下，这些字段对应的数字应该都是 0。如果看到对应的数字在不断增长，就说明网卡有丢包。另外一个查看网卡丢包数据的命令是 ifconfig，它的输出中会有 RX(receive 接收报文)和 TX（transmit 发送报文）的统计数据：

          ~# ifconfig eth0
...
        RX packets 3553389376  bytes 2599862532475 (2.3 TiB)
        RX errors 0  dropped 1353  overruns 0  frame 0
        TX packets 3479495131  bytes 3205366800850 (2.9 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
...

此外， linux系统也提供了各个网络协议的丢包信息，可以使用 netstat -s命令查看，加上 –udp 可以只看 UDP 相关的报文数据：

          [root@holodesk02 GOD]# netstat -s -u
IcmpMsg:
    InType0: 3
    InType3: 1719356
    InType8: 13
    InType11: 59
    OutType0: 13
    OutType3: 1737641
    OutType8: 10
    OutType11: 263
Udp:
    517488890 packets received
    2487375 packets to unknown port received.
    47533568 packet receive errors
    147264581 packets sent
    12851135 receive buffer errors
    0 send buffer errors
UdpLite:
IpExt:
    OutMcastPkts: 696
    InBcastPkts: 2373968
    InOctets: 4954097451540
    OutOctets: 5538322535160
    OutMcastOctets: 79632
    InBcastOctets: 934783053
    InNoECTPkts: 5584838675

对于上面的输出，关注下面的信息来查看 UDP 丢包的情况：

packet receive errors不为空，并且在一直增长说明系统有 UDP 丢包
packets to unknown port received表示系统接收到的 UDP 报文所在的目标端口没有应用在监听，一般是服务没有启动导致的，并不会造成严重的问题
receive buffer errors表示因为 UDP 的接收缓存太小导致丢包的数量

NOTE：并不是丢包数量不为零就有问题，对于 UDP 来说，如果有少量的丢包很可能是预期的行为，比如丢包率（丢包数量/接收报文数量）在万分之一甚至更低。

3.2 、确认网卡或者驱动丢包

之前讲过，如果 ethtool -S eth0中有 rx_***_errors那么很可能是网卡有问题，导致系统丢包，需要联系服务器或者网卡供应商进行处理。

          # ethtool -S eth0 | grep rx_ | grep errors
     rx_crc_errors: 0
     rx_missed_errors: 0
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     rx_errors: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_frame_errors: 0
     rx_fifo_errors: 0

netstat -i也会提供每个网卡的接发报文以及丢包的情况，正常情况下输出中 error 或者 drop 应该为 0。

如果硬件或者驱动没有问题，一般网卡丢包是因为设置的缓存区（ring buffer）太小，可以使用 ethtool 命令查看和设置网卡的 ring buffer。

ethtool -g可以查看某个网卡的 ring buffer，比如下面的例子

          # ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

Pre-set 表示网卡最大的 ring buffer值，可以使用 ethtool -G eth0 rx 8192设置它的值。

3.3 、UDP 报文错误丢包

如果在传输过程中UDP 报文被修改，会导致 checksum 错误，或者长度错误，linux 在接收到 UDP 报文时会对此进行校验，一旦发明错误会把报文丢弃。

如果希望 UDP 报文 checksum 及时有错也要发送给应用程序，可以在通过 socket 参数禁用 UDP checksum 检查：

          int disable = 1;
setsockopt(sock_fd, SOL_SOCKET, SO_NO_CHECK, (void*)&disable, sizeof(disable)

3.4 、UDP buffer size 不足丢包

linux 系统在接收报文之后，会把报文保存到缓存区中。因为缓存区的大小是有限的，如果出现 UDP 报文过大（超过缓存区大小或者 MTU 大小）、接收到报文的速率太快，都可能导致 linux 因为缓存满而直接丢包的情况。

在系统层面，linux 设置了 receive buffer 可以配置的最大值，可以在下面的文件中查看，一般是 linux 在启动的时候会根据内存大小设置一个初始值。

/proc/sys/net/core/rmem_max：允许设置的 receive buffer 最大值

/proc/sys/net/core/rmem_default：默认使用的 receive buffer 值

/proc/sys/net/core/wmem_max：允许设置的 send buffer 最大值

/proc/sys/net/core/wmem_dafault：默认使用的 send buffer 最大值

但是这些初始值并不是为了应对大流量的 UDP 报文，如果应用程序接收和发送 UDP 报文非常多，需要将这个值调大。可以使用 sysctl 命令让它立即生效：

          sysctl -w net.core.rmem_max=26214400 # 设置为 25M，临时生效，下次启动消失

也可以修改 /etc/sysctl.conf中对应的参数在下次启动时让参数保持生效。

如果报文报文过大，可以在发送方对数据进行分割，保证每个报文的大小在 MTU 内。

另外一个可以配置的参数是 netdev_max_backlog，它表示 linux 内核从网卡驱动中读取报文后可以缓存的报文数量，默认是 1000，可以调大这个值，比如设置成 2000：

          sudo sysctl -w net.core.netdev_max_backlog=2000

3.5 、系统负载过高丢包

系统 CPU、memory、IO 负载过高都有可能导致网络丢包

比如 CPU 如果负载过高，系统没有时间进行报文的 checksum 计算、复制内存等操作，从而导致网卡或者 socket buffer 处丢包；

memory 负载过高，会应用程序处理过慢，无法及时处理报文；

IO 负载过高，CPU 都用来响应 IO wait，没有时间处理缓存中的 UDP报文。

linux系统本身就是相互关联的系统，任何一个组件出现问题都有可能影响到其他组件的正常运行。对于系统负载过高，要么是应用程序有问题，要么是系统不足。对于前者需要及时发现，debug 和修复；对于后者，也要及时发现并扩容。

3.6 、应用丢包

上面提到系统的 UDP buffer size，调节的 sysctl 参数只是系统允许的最大值，每个应用程序在创建 socket 时需要设置自己 socket buffer size的值。

linux系统会把接受到的报文放到 socket的 buffer中，应用程序从 buffer 中不断地读取报文。所以这里有两个和应用有关的因素会影响是否会丢包：socket buffer size 大小以及应用程序读取报文的速度。

对于第一个问题，可以在应用程序初始化 socket的时候设置 socket receive buffer的大小，比如下面的代码把 socket buffer 设置为 20MB：

          uint64_t receive_buf_size = 20*1024*1024;  //20 MB
setsockopt(socket_fd, SOL_SOCKET, SO_RCVBUF, &receive_buf_size, sizeof(receive_buf_size));

如果不是自己编写和维护的程序，修改应用代码是件不好甚至不太可能的事情。很多应用程序会提供配置参数来调节这个值，请参考对应的官方文档；如果没有可用的配置参数，只能给程序的开发者提 issue 了。很明显，增加应用的 receive buffer 会减少丢包的可能性，但同时会导致应用使用更多的内存，所以需要谨慎使用。另外一个因素是应用读取 buffer 中报文的速度，对于应用程序来说， 处理报文应该采取异步的方式

3.7 、包丢在什么地方

想要详细了解 linux 系统在执行哪个函数时丢包的话，可以使用 dropwatch工具，它监听系统丢包信息，并打印出丢包发生的函数地址：

          # dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring

1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
4 drops at unix_release_sock+20e (0xffffffff817dc94e)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

通过这些信息，找到对应的内核代码处，就能知道内核在哪个步骤中把报文丢弃，以及大致的丢包原因。如果 dropwatch信息输出过多，或者不好用，可以阅读下我的另外两篇博文： iptables观察数据包流向、定位netfilter丢包。这两种方式可以解决绝大部分二三层的数据丢包问题。也可以在 kfree_skb处编写小工具，实现过滤数据包打印栈回溯信息（ebpf可能是一种实现方式、我自己没有做过尝试，后续有时间会做一个）。

此外，还可以使用 linux perf 工具监听 kfree_skb（把网络报文丢弃时会调用该函数）事件的发生：

          sudo perf record -g -a -e skb:kfree_skb
sudo perf script

关于 perf 命令的使用和解读，网上有很多文章可以参考。

3.8 、关于UDP丢包的总结

UDP 本身就是无连接不可靠的协议，适用于报文偶尔丢失也不影响程序状态的场景，比如视频、音频、游戏、监控等。对报文可靠性要求比较高的应用不要使用 UDP，推荐直接使用 TCP。当然，也可以在应用层做重试、去重保证可靠性
如果发现服务器丢包，首先通过监控查看系统负载是否过高，先想办法把负载降低再看丢包问题是否消失
如果系统负载过高，UDP 丢包是没有有效解决方案的。如果是应用异常导致 CPU、memory、IO 过高，请及时定位异常应用并修复；如果是资源不够，监控应该能及时发现并快速扩容
对于系统大量接收或者发送 UDP 报文的，可以通过调节系统和程序的 socket buffer size来降低丢包的概率
应用程序在处理 UDP 报文时，要采用异步方式，在两次接收报文之间不要有太多的处理逻辑

3.9、防火墙拦截

服务器端口无法连接，通常就是查看防火墙配置了，虽然这里已经确认同一个出口IP的客户端有的能够正常访问，但也不排除配置了DROP特定端口范围的可能性。如果系统防火墙丢包，表现的行为一般是所有的 UDP 报文都无法正常接收，当然不排除防火墙只 drop 一部分报文的可能性。如果遇到丢包比率非常大的情况，请先检查防火墙规则，保证防火墙没有主动 drop UDP报文。

如何确认

查看 iptables filter表，确认是否有相应规则会导致此丢包行为：

          $ sudo iptables-save -t filter

这里容易排除防火墙拦截的可能性。 iptables观察数据包流向、定位netfilter丢包。

3.10、连接跟踪表溢出

除了防火墙本身配置DROP规则外，与防火墙有关的还有连接跟踪表nf_conntrack，Linux为每个经过内核网络栈的数据包，生成一个新的连接记录项，当服务器处理的连接过多时，连接跟踪表被打满，服务器会丢弃新建连接的数据包。

如何确认

通过dmesg可以确认是否有该情况发生：

          $ dmesg |grep nf_conntrack

如果输出值中有“nf_conntrack: table full, dropping packet”，说明服务器nf_conntrack表已经被打满。

通过/proc文件系统查看nf_conntrack表实时状态：

          # 查看nf_conntrack表最大连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_max
65536
# 查看nf_conntrack表当前连接数
$ cat /proc/sys/net/netfilter/nf_conntrack_count
7611

当前连接数远没有达到跟踪表最大值，排除这个因素。

如何解决

如果确认服务器因连接跟踪表溢出而开始丢包，首先需要查看具体连接判断是否正遭受DOS攻击，如果是正常的业务流量造成，可以考虑调整nf_conntrack的参数：

nf_conntrack_max决定连接跟踪表的大小，默认值是65535，可以根据系统内存大小计算一个合理值： CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32)，如32G内存可以设置1048576；

nf_conntrack_buckets决定存储 conntrack条目的哈希表大小，默认值是 nf_conntrack_max的1/4，延续这种计算方式： BUCKETS = CONNTRACK_MAX/4，如32G内存可以设置262144；

nf_conntrack_tcp_timeout_established决定ESTABLISHED状态连接的超时时间，默认值是5天，可以缩短到1小时，即3600。

          $ sysctl -w net.netfilter.nf_conntrack_max=1048576
$ sysctl -w net.netfilter.nf_conntrack_buckets=262144
$ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

3.11、Ring Buffer溢出

排除了防火墙的因素，我们从底向上来看Linux接收数据包的处理过程，首先是网卡驱动层。如下图所示，物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃。

如何确认

通过ethtool或/proc/net/dev可以查看因Ring Buffer满而丢弃的包统计，在统计项中以fifo标识：

          $ ethtool -S eth0|grep rx_fifo
rx_fifo_errors: 0
$ cat /proc/net/dev
Inter-|   Receive                                                |  Transmit

 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
  eth0: 17253386680731 42839525880    0    0    0     0          0 244182022 14879545018057 41657801805    0    0    0     0       0         0

可以看到服务器的接收方向的fifo丢包数并没有增加，这里自然也排除这个原因。

如何解决

如果发现服务器上某个网卡的fifo数持续增大，可以去确认CPU中断是否分配均匀，也可以尝试增加Ring Buffer的大小，通过ethtool可以查看网卡设备Ring Buffer最大值，修改Ring Buffer当前设置：

          # 查看eth0网卡Ring Buffer最大值和当前设置
$ ethtool -g eth0
Ring parameters for eth0:

Pre-set maximums:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096   
Current hardware settings:
RX:     1024   
RX Mini:    0
RX Jumbo:   0
TX:     1024   
# 修改网卡eth0接收与发送硬件缓存区大小
$ ethtool -G eth0 rx 4096 tx 4096
Pre-set maximums:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096   
Current hardware settings:
RX:     4096   
RX Mini:    0
RX Jumbo:   0
TX:     4096

3.12 netdev_max_backlog溢出

netdev_max_backlog是内核从NIC收到包后，交由协议栈（如IP、TCP）处理之前的缓冲队列。每个CPU核都有一个 backlog队列，与 Ring Buffer同理，当接收包的速率大于内核协议栈处理的速率时，CPU的 backlog队列不断增长，当达到设定的 netdev_max_backlog值时，数据包将被丢弃。

如何确认

通过查看/proc/net/softnet_stat可以确定是否发生了netdev backlog队列溢出：

          $ cat /proc/net/softnet_stat
01a7b464 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
01d4d71f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0349e798 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
017e0826 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

其中：每一行代表每个CPU核的状态统计，从CPU0依次往下；每一列代表一个CPU核的各项统计：第一列代表中断处理程序收到的包总数；第二列即代表由于netdev_max_backlog队列溢出而被丢弃的包总数。从上面的输出可以看出，这台服务器统计中，并没有因为netdev_max_backlog导致的丢包。

如何解决

netdev_max_backlog的默认值是1000，在高速链路上，可能会出现上述第二列统计不为0的情况，可以通过修改内核参数net.core.netdev_max_backlog来解决：

          $ sysctl -w net.core.netdev_max_backlog=2000

3.13、反向路由过滤

反向路由过滤机制是Linux通过反向路由查询，检查收到的数据包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果没有通过验证，则丢弃数据包，设计的目的是防范IP地址欺骗攻击。rp_filter提供了

三种模式供配置：

0 - 不验证
1 - RFC3704定义的严格模式：对每个收到的数据包，查询反向路由，如果数据包入口和反向路由出口不一致，则不通过
2 - RFC3704定义的松散模式：对每个收到的数据包，查询反向路由，如果任何接口都不可达，则不通过

如何确认

查看当前rp_filter策略配置：

          $ cat /proc/sys/net/ipv4/conf/eth0/rp_filter

如果这里设置为1，就需要查看主机的网络环境和路由策略是否可能会导致客户端的入包无法通过反向路由验证了。

从原理来看这个机制工作在网络层，因此，如果客户端能够Ping通服务器，就能够排除这个因素了。

如何解决

根据实际网络环境将rp_filter设置为0或2：

          $ sysctl -w net.ipv4.conf.all.rp_filter=2

或

          $ sysctl -w net.ipv4.conf.eth0.rp_filter=2

3.14 半连接队列溢出

半连接队列指的是TCP传输中服务器收到SYN包但还未完成三次握手的连接队列，队列大小由内核参数tcp_max_syn_backlog定义。当服务器保持的半连接数量达到 tcp_max_syn_backlog后，内核将会丢弃新来的SYN包。

如何确认

通过dmesg可以确认是否有该情况发生：

          $ dmesg | grep "TCP: drop open request from"

半连接队列的连接数量可以通过netstat统计SYN_RECV状态的连接得知

          $ netstat -ant|grep SYN_RECV|wc -l
0

大多数情况下这个值应该是0或很小，因为半连接状态从第一次握手完成时进入，第三次握手完成后退出，正常的网络环境中这个过程发生很快，如果这个值较大，服务器极有可能受到了SYN Flood攻击。

如何解决

tcp_max_syn_backlog的默认值是256，通常推荐内存大于128MB的服务器可以将该值调高至1024，内存小于32MB的服务器调低到128，同样，该参数通过sysctl修改：

          $ sysctl -w net.ipv4.tcp_max_syn_backlog=1024

另外，上述行为受到内核参数 tcp_syncookies的影响，若启用 syncookie机制，当半连接队列溢出时，并不会直接丢弃SYN包，而是回复带有 syncookie的SYC+ACK包，设计的目的是防范SYN Flood造成正常请求服务不可用。

          $ sysctl -w net.ipv4.tcp_syncookies=1
net.ipv4.tcp_syncookies = 1

3.15 PAWS

PAWS全名Protect Againest Wrapped Sequence numbers，目的是解决在高带宽下，TCP序列号在一次会话中可能被重复使用而带来的问题。

如上图所示，客户端发送的序列号为A的数据包A1因某些原因在网络中“迷路”，在一定时间没有到达服务端，客户端超时重传序列号为A的数据包A2，接下来假设带宽足够，传输用尽序列号空间，重新使用A，此时服务端等待的是序列号为A的数据包A3，而恰巧此时前面“迷路”的A1到达服务端，如果服务端仅靠序列号A就判断数据包合法，就会将错误的数据传递到用户态程序，造成程序异常。

PAWS要解决的就是上述问题，它依赖于timestamp机制，理论依据是：在一条正常的TCP流中，按序接收到的所有TCP数据包中的timestamp都应该是单调非递减的，这样就能判断那些timestamp小于当前TCP流已处理的最大timestamp值的报文是延迟到达的重复报文，可以予以丢弃。在上文的例子中，服务器已经处理数据包Z，而后到来的A1包的timestamp必然小于Z包的timestamp，因此服务端会丢弃迟到的A1包，等待正确的报文到来。

PAWS机制的实现关键是内核保存了Per-Connection的最近接收时间戳，如果加以改进，就可以用来优化服务器TIME_WAIT状态的快速回收。

TIME_WAIT状态是TCP四次挥手中主动关闭连接的一方需要进入的最后一个状态，并且通常需要在该状态保持2*MSL（报文最大生存时间），它存在的意义有两个：

1.可靠地实现TCP全双工连接的关闭：关闭连接的四次挥手过程中，最终的ACK由主动关闭连接的一方（称为A）发出，如果这个ACK丢失，对端（称为B）将重发FIN，如果A不维持连接的TIME_WAIT状态，而是直接进入CLOSED，则无法重传ACK，B端的连接因此不能及时可靠释放。

2.等待“迷路”的重复数据包在网络中因生存时间到期消失：通信双方A与B，A的数据包因“迷路”没有及时到达B，A会重发数据包，当A与B完成传输并断开连接后，如果A不维持TIME_WAIT状态2 MSL时间，便有可能与B再次建立相同源端口和目的端口的“新连接”，而前一次连接中“迷路”的报文有可能在这时到达，并被B接收处理，造成异常，维持2MSL的目的就是等待前一次连接的数据包在网络中消失。

TIME_WAIT状态的连接需要占用服务器内存资源维持，Linux内核提供了一个参数来控制TIME_WAIT状态的快速回收：tcp_tw_recycle，它的理论依据是：

在PAWS的理论基础上，如果内核保存Per-Host的最近接收时间戳，接收数据包时进行时间戳比对，就能避免TIME_WAIT意图解决的第二个问题：前一个连接的数据包在新连接中被当做有效数据包处理的情况。这样就没有必要维持TIME_WAIT状态2*MSL的时间来等待数据包消失，仅需要等待足够的RTO（超时重传），解决ACK丢失需要重传的情况，来达到快速回收TIME_WAIT状态连接的目的。

但上述理论在多个客户端使用NAT访问服务器时会产生新的问题：同一个NAT背后的多个客户端时间戳是很难保持一致的（timestamp机制使用的是系统启动相对时间），对于服务器来说，两台客户端主机各自建立的TCP连接表现为同一个对端IP的两个连接，按照Per-Host记录的最近接收时间戳会更新为两台客户端主机中时间戳较大的那个，而时间戳相对较小的客户端发出的所有数据包对服务器来说都是这台主机已过期的重复数据，因此会直接丢弃。

如何确认

通过netstat可以得到因PAWS机制timestamp验证被丢弃的数据包统计：

          $ netstat -s |grep -e "passive connections rejected because of time stamp" -e "packets rejects in established connections because of timestamp”
387158 passive connections rejected because of time stamp
825313 packets rejects in established connections because of timestamp

通过sysctl查看是否启用了tcp_tw_recycle及tcp_timestamp:

          $ sysctl net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_recycle = 1
$ sysctl net.ipv4.tcp_timestamps
net.ipv4.tcp_timestamps = 1

这次问题正是因为服务器同时开启了tcp_tw_recycle和timestamps，而客户端正是使用NAT来访问服务器，造成启动时间相对较短的客户端得不到服务器的正常响应。

如何解决

如果服务器作为服务端提供服务，且明确客户端会通过NAT网络访问，或服务器之前有7层转发设备会替换客户端源IP时，是不应该开启tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外还被其他机制依赖，推荐继续开启：

          $ sysctl -w net.ipv4.tcp_tw_recycle=0
$ sysctl -w net.ipv4.tcp_timestamps=1

3.16 怎么知道为什么数据包被丢弃

dropwatch

通过谷歌搜索，发现一个很酷的工具叫 dropwatch 。x相关知识可以参考这篇博文。没有现成的 Ubuntu 安装软件包，但可以通过 github 下载：

https://github.com/pavel-odintsov/drop_watch

以下是我可以编译的说明：

          sudo apt-get install -y libnl-3-dev libnl-genl-3-dev binutils-dev libreadline6-dev
git clone https://github.com/pavel-odintsov/drop_watch.git
cd drop_watch/src
make

这里是输出！它告诉我哪个内核函数丢失数据包，酷！

          sudo ./dropwatch -l kas
Initalizing kallsyms db
dropwatch> start
Enabling monitoring...
Kernel monitoring activated.
Issue Ctrl-C to stop monitoring

1 drops at tcp_v4_do_rcv+cd (0xffffffff81799bad)
10 drops at tcp_v4_rcv+80 (0xffffffff8179a620)
1 drops at sk_stream_kill_queues+57 (0xffffffff81729ca7)
4 drops at unix_release_sock+20e (0xffffffff817dc94e)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)
1 drops at igmp_rcv+e1 (0xffffffff817b4c41)

perf

用perf监控丢弃的数据包

还有另一个很酷的方法，用来调试发生什么。

可以使用 perf 监视 kfree_skb 事件，这将告诉你什么时候丢弃数据包（内核堆栈发生的地方）：

          sudo perf record -g -a -e skb:kfree_skb
sudo perf script

扩展阅读

还有这两个很酷的文章：

监控和调优Linux网络堆栈：接收数据

https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/

监控和调优Linux网络堆栈：发送数据

https://blog.packagecloud.io/eng/2017/02/06/monitoring-tuning-linux-networking-stack-sending-data/

结论

Linux提供了丰富的内核参数供使用者调整，调整得当可以大幅提高服务器的处理能力，但如果调整不当，就会引进莫名其妙的各种问题，比如这次开启tcp_tw_recycle导致丢包，实际也是为了减少TIME_WAIT连接数量而进行参数调优的结果。我们在做系统优化时，时刻要保持辩证和空杯的心态，不盲目吸收他人的果，而多去追求因，只有知其所以然，才能结合实际业务特点，得出最合理的优化配置。

https://jermine.vdo.pub/linux/linux%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%A2%E5%8C%85%E6%95%85%E9%9A%9C%E7%9A%84%E8%A7%A3%E5%86%B3/

https://cizixs.com/2018/01/13/linux-udp-packet-drop-debug/

Linux主机性能测试方法

Thu, 13 Oct 2022 17:11:12 CST

背景

最近打算用躺家吃灰的树莓派4B搭一个NAS，用来快捷方便地访问和备份一些资源。由于备选的硬件（芯片、硬盘、网线、路由器等）和软件（内网穿透技术）的技术选型比较多，这时候就需要有一个能简单评估服务性能的方法。因此简单搜寻了一下常见方案，方便在技术选型时有个统一的对比标准，并且对一些常见指标能在数量级上有一些感性的理解。

硬盘

对于硬盘的读写速度测试，首先我们需要注意根据读写的实现细节不同，测试出的结果会有很大的差别。例如对于读来说，是否走缓存读、缓存的大小如何；对于写来说，是否只写缓存、是否同步等待刷盘、刷盘的时机如何，等等。

在实际测试的时候一定要明确自己使用的是哪种IO模式，否则就会得到一些似是而非的结论。

设备查询

在测试硬盘前，我们首先得知道我们有哪些硬盘、分别对应哪些分区。用 lsblk （list block）命令可以查看当前机器下挂载的块设备：

  $ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 29.3G  0 disk
└─sda1        8:1    1 29.3G  0 part /media/pi/5615-BDE2
mmcblk0     179:0    0 59.5G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 59.2G  0 part /

可以看到，这里的 sda (SATA device a) 表示我外部插入的一个U盘；mmcblk0 (Multimedia card block 0) 表示树莓派自带的一张 SD 卡。这两个类型是 disk，也就是实体磁盘。

每个 disk 会被分成多个 partition，也就是这里的 sda1 和 mmcblk0p1、mmcblk0p2。每个 partition 又会 mount 到不同的文件夹下，用于在文件系统中进行访问。因此对于文件系统本身来说，我们只会关心到 partition 层面。

通过 df 命令我们也能直接观察到所有分区的挂载情况：

  $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        59G   11G   46G  19% /
devtmpfs        3.5G     0  3.5G   0% /dev
tmpfs           3.7G     0  3.7G   0% /dev/shm
tmpfs           3.7G   65M  3.6G   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.7G     0  3.7G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   32M  221M  13% /boot
tmpfs           738M  4.0K  738M   1% /run/user/1000
/dev/sda1        30G   23M   30G   1% /media/pi/5615-BDE2

同时，disk 和 partition 的详细信息也可以通过 fdisk 命令查看：

  $ sudo fdisk -l
Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x140cee6b

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 124735487 124203008 59.2G 83 Linux


Disk /dev/sda: 29.3 GiB, 31457280000 bytes, 61440000 sectors
Disk model: ProductCode
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf3203eea

Device     Boot Start      End  Sectors  Size Id Type
/dev/sda1        2048 61439999 61437952 29.3G  7 HPFS/NTFS/exFAT

总之，在这里我们只需要搞清楚我们想测试的磁盘和分区分别是哪个即可。

hdparm

对于读性能测试，我们一般可以用 hdparm 工具（hard disk parameter? hardware device parameter?）。Debian下直接 apt 安装即可：

  $ sudo apt install hdparm -y

hdparm目前只支持磁盘读性能测试，提供了三种方式进行测试：

直接读内存： sudo hdparm -T [device] 。
带buffer读磁盘： sudo hdparm -t [device] 。
不带buffer读磁盘: sudo hdparm -t --direct [device] 。

以我的 mmcblk0 设备为例，跑出来结果分别如下（当然，每次测试建议跑多次取平均值，这里偷个懒）：

  $ sudo hdparm -T /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   1840 MB in  2.00 seconds = 921.43 MB/sec
 
$ sudo hdparm -t /dev/mmcblk0

/dev/mmcblk0:
 Timing buffered disk reads: 130 MB in  3.04 seconds =  42.74 MB/sec
 
$ sudo hdparm -t --direct /dev/mmcblk0

/dev/mmcblk0:
 Timing O_DIRECT disk reads: 124 MB in  3.01 seconds =  41.17 MB/sec

显然，走内存读是飞快，不过对于测试磁盘性能来说没有任何意义；不带buffer看起来比带buffer要慢一点点，差别不太大；考虑到现实场景中大多数都是带buffer的读，因此我们在比较时用带buffer读的结果来进行参考即可。

dd

dd (data definition? data duplicator?) 是进行磁盘操作、文件生成之类的常用工具。在 gnu 的 coreutils 下，类 Unix 发行版几乎都自带。

写性能

一般我们会用 dd 来进行磁盘写性能测试，一般来说也有三种方式：

直接写内存： dd bs=1M count=256 if=/dev/zero of=test 。
使用内存做缓存写完后一次性刷盘： dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync。
使用内存做缓存，每写完一部分就刷一次盘： dd bs=1M count=256 if=/dev/zero of=test oflag=dsync。

还是以我的 mmcblk0 设备为例（当前目录即挂载的 mmcblk0 设备），跑出来结果分别如下（当然，每次测试建议跑多次取平均值，这里还是偷个懒）：

  $ dd bs=1M count=256 if=/dev/zero of=test
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 1.39574 s, 192 MB/s

$ dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 31.739 s, 8.5 MB/s

$ dd bs=1M count=256 if=/dev/zero of=test oflag=dsync
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 39.694 s, 6.8 MB/s

$ rm test

可见写内存不sync的确还是快，不过还是没啥参考意义。考虑到实际情况下大部分程序都是采用 fdatasync 的模式来写，因此我们在比较时用这个数据即可。

读性能

当然，有人也会利用 dd 进行读性能测试，比如：

  $ sudo dd bs=1M count=256 if=/dev/mmcblk0 of=/dev/null
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 6.03649 s, 44.5 MB/s

看起来很美好，结果也和 hdparm 差不多。但是当你第二次再跑这个命令的时候，由于写缓存的存在，结果会快特别多：

  $ sudo dd bs=1M count=256 if=/dev/mmcblk0 of=/dev/null
256+0 records in
256+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 0.267236 s, 1.0 GB/s

显然这样的测试是没有意义的。考虑到这种测试方法甚至很难做到幂等，这里还是不建议用 dd 来测试读性能。

小结

对于磁盘读性能测试，建议使用 sudo hdparm -t [device]。

对于磁盘写性能测试，建议使用 dd bs=1M count=256 if=/dev/zero of=test conv=fdatasync。

网络

网速测试一般分两种，一种是测试当前设备对普通公网设备的读写速度；另一种是点对点测试两个服务器之间的速度。

speedtest

speedtest 工具在各地都有测速服务器，通过命令行（speedtest-cli）或者网页（https://speedtest.cn，https://speedtest.net）都可以进行网速上下行的测试。这里以命令行为例：

  $ sudo apt install speedtest-cli -y

$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from China Mobile (183.192.82.69)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Chinamobile-5G (Shanghai) [8.49 km]: 6.054 ms
Testing download speed................................................................................
Download: 128.24 Mbit/s
Testing upload speed......................................................................................................
Upload: 22.88 Mbit/s

虽然多次测试可能会访问到不同的测试点、导致结果有区别，不过其实也大差不差了。

在使用时偶尔会遇到返403，不要慌，多试几下一般就好了。

iperf3

如果我们并不是想测试公网网速，而是测试两个服务器之间点对点的网速。这时用 iperf3 工具就好。

  $ sudo apt install iperf3 -y # Debian 下
$ brew install iperf3        # MacOS 下

需要注意，除了 iperf3 之外，还有一个 iperf。这两个版本分别由不同组织开发，前后也不兼容。虽然似乎 iperf3 有坑，不过似乎功能多一点，尤其是支持了下行带宽测试（iperf 只支持上行带宽测试），所以这里还是用 iperf3。

iperf3 是 C/S 架构，服务端开启 server ，客户端开启 client，然后互相通信进行测速。以我在家的树莓派和一个在 HK 的 Azure 主机为例：

  $ iperf3 -s -p 5555                   # azure 主机上开启 server

$ iperf3 -c 104.208.65.181 -p 5555    # pi 上开启 client 并连接 server

测试完成后，client 上会有报告：

  $ iperf3 -c 104.208.65.181 -p 5555
Connecting to host 104.208.65.181, port 5555
[  5] local 192.168.1.2 port 35994 connected to 104.208.65.181 port 5555
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.68 MBytes  72.8 Mbits/sec    0   2.95 MBytes
[  5]   1.00-2.00   sec  1.25 MBytes  10.5 Mbits/sec  2018    252 KBytes
[  5]   2.00-3.00   sec  2.50 MBytes  21.0 Mbits/sec  1076    286 KBytes
[  5]   3.00-4.00   sec  3.75 MBytes  31.5 Mbits/sec  861    237 KBytes
[  5]   4.00-5.00   sec  2.50 MBytes  21.0 Mbits/sec   99    187 KBytes
[  5]   5.00-6.00   sec  1.25 MBytes  10.5 Mbits/sec    0    206 KBytes
[  5]   6.00-7.00   sec  2.50 MBytes  21.0 Mbits/sec    0    215 KBytes
[  5]   7.00-8.00   sec  2.50 MBytes  21.0 Mbits/sec    0    218 KBytes
[  5]   8.00-9.00   sec  2.50 MBytes  21.0 Mbits/sec    0    218 KBytes
[  5]   9.00-10.00  sec  2.50 MBytes  21.0 Mbits/sec    0    220 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  29.9 MBytes  25.1 Mbits/sec  4054             sender
[  5]   0.00-10.09  sec  26.5 MBytes  22.1 Mbits/sec                  receiver

iperf Done.

这里可以看出 client 对 server 的上行带宽大约是 22Mbit/sec。

类似的，server配置不变，client加上 -R 参数后可以测试出 server 对 client 的下行带宽：

  $ iperf3 -c 104.208.65.181 -p 5555 -R
Connecting to host 104.208.65.181, port 5555
Reverse mode, remote host 104.208.65.181 is sending
[  5] local 192.168.1.2 port 36000 connected to 104.208.65.181 port 5555
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  6.47 MBytes  54.3 Mbits/sec
[  5]   1.00-2.00   sec  25.7 MBytes   216 Mbits/sec
[  5]   2.00-3.00   sec  13.2 MBytes   111 Mbits/sec
[  5]   3.00-4.00   sec  16.3 MBytes   137 Mbits/sec
[  5]   4.00-5.00   sec  12.4 MBytes   104 Mbits/sec
[  5]   5.00-6.00   sec  14.4 MBytes   121 Mbits/sec
[  5]   6.00-7.00   sec  14.0 MBytes   117 Mbits/sec
[  5]   7.00-8.00   sec  13.9 MBytes   116 Mbits/sec
[  5]   8.00-9.00   sec  11.5 MBytes  96.7 Mbits/sec
[  5]   9.00-10.00  sec  11.3 MBytes  95.2 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.09  sec   142 MBytes   118 Mbits/sec  2560             sender
[  5]   0.00-10.00  sec   139 MBytes   117 Mbits/sec                  receiver

iperf Done.

这里可以看出 server 对 client 的下行带宽大约是 117Mbit/sec。

CPU&内存

sysbench

对于CPU和内存的性能测试，可以使用 sysbench 工具。

  $ sudo apt install sysbench -y # Debian 下
$ brew install sysbench        # MacOS 下

对于我的树莓派测试如下：

CPU单线程测试，可以看出单核每秒操作数大约1483：

  $ sysbench cpu --threads=1 run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  1483.17

General statistics:
    total time:                          10.0002s
    total number of events:              14839

Latency (ms):
         min:                                    0.67
         avg:                                    0.67
         max:                                    1.88
         95th percentile:                        0.68
         sum:                                 9992.91

Threads fairness:
    events (avg/stddev):           14839.0000/0.00
    execution time (avg/stddev):   9.9929/0.00

内存读写测试，可以看出读写速度约是 1814MiB 每秒：

  $ sysbench memory run
sysbench 1.0.18 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time


Running memory speed test with the following options:
  block size: 1KiB
  total size: 102400MiB
  operation: write
  scope: global

Initializing worker threads...

Threads started!

Total operations: 18590983 (1858174.07 per second)

18155.26 MiB transferred (1814.62 MiB/sec)


General statistics:
    total time:                          10.0001s
    total number of events:              18590983

Latency (ms):
         min:                                    0.00
         avg:                                    0.00
         max:                                    0.20
         95th percentile:                        0.00
         sum:                                 4463.57

Threads fairness:
    events (avg/stddev):           18590983.0000/0.00
    execution time (avg/stddev):   4.4636/0.00

需要注意的是，对 MacOS 的 CPU benchmark 似乎有坑，测试出来的结果异常的大，不具有参考价值。

md5sum

虽然 sysbench 的基准测试看起来比较靠谱，但是实际环境下，真正的执行效率还跟执行的指令啥的都有挺大关系。比如，我们以执行 md5 的速度来对比 CPU 的执行效率：

  $ dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.81996 s, 184 MB/s
cd573cfaace07e7949bc0c46028904ff  -

通过 dd 命令向 md5sum 持续发送 1GB 的数据进行计算，计算的速度也可以看成是 CPU 单核性能的一种指标。（考虑到管道操作是单线程，这个指令其实也只能用到一个核）

然后，如果我们多找几个 CPU 进行以下对比，我们就会发现一些神奇的现象：

Cortex-A72（ARM）

sysbench 单线程：1479.99 event/s
dd + md5sum：184 MB/s

Neoverse-N1（ARM）

sysbench 单线程：3497.70 event/s
dd + md5sum：424 MB/s

Intel(R) Xeon(R) Platinum 8171M CPU @ 2.60GHz（x86_64）

sysbench 单线程：820.19 event/s
dd + md5sum：409 MB/s

Intel(R) Xeon(R) CPU E5-26xx v4（x86_64）

sysbench 单线程：927.74 event/s
dd + md5sum：459 MB/s

Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz（x86_64）

sysbench 单线程：1054.30 event/s
dd + md5sum：515 MB/s

可以发现 ARM 架构的机器在 sysbench 上表现几乎都比 X86_64 的机器好很多，但是实际跑 md5sum 却相差不大甚至差不少。

可见不同架构间二者的指标并不完全正相关；不过相同架构间二者的指标还是基本正相关的。

参考资料

dd-benchmark

man-hdparm

iperf

【Linux】解决可恶的 “NIC Link is Down”_从善若水的博客-CSDN博客

Sun, 09 Oct 2022 09:52:32 CST

文章目录

可恶的 “NIC Link is Down”

前一段时间调试5G实时视频业务，网卡总是会出现 NIC Link is Down的错误，一般几秒之后网卡就会恢复。但是也会遇到一些情况网卡发生 NIC Link is Down之后无法自动恢复，这时候只能重新启动测试PC才能恢复。

下面是我通过dmesg抓到的错误信息：

      May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Up1000Mbps Full Duplex, Flow Control: Rx/Tx
May2909:10:35 server kernel: e1000e: eth0 NIC Link is Down

总的来说错误原因就是 kernel: e1000e: eth0 NIC Link is Down。

怎样解决 “NIC Link is Down”

1. 检查网线是否有问题

这是最简单的方式了，只需要替换一根网线，然后继续观察问题是否会再次出现。有些时候有问题的网线会导致这样的错误。

2. 可能是 e1000e网卡驱动的bug

可以尝试更新最新版本的 e1000e 网卡驱动，具体步骤如下：

Ubuntu：可以尝试通过这个脚本进行升级【传送门】
CentOS、RHEL：尝试通过这个Intel的指南进行升级【传送门】

3. NIC出了问题

换一个NIC再进行测试，观察问题是否再次出现。如果NIC是绑定在主板上的，那只能更换一个主板再进行测试了。

4. Switch Port 出了问题

改变 PC/Server 的交换机端口，再进行测试。你可以通过 ethtool命令查看Linux上的网络配置与交换机上的配置是否一致。

5. 尝试更新你的BIOS && 开启ASPM模式

根据经验如果关闭 ASPM模式也可能导致这样的问题。除此之外，保证你的BIOS版本是最新的，如果不是可以进行更新。

6. 关闭流控（flow control）

有些时候开启流控之后会导致一些奇怪的网络错误，可以使用命令将其关闭，并观察问题是否会再次出现，

      ethtool-A eth0 rx off tx off

使用下述命令查看修改是否生效，

      [root@CSRS:~]thtool -a eth0

Pause parametersforeth0:

Autonegotiate:  on
RX:             off
TX:             off

如果看到off，那么流控已经被关闭了。

7. 更换主板与板载网卡和CPU🚑

有一次我发现在 E3-1230v2上持续出现这样的问题，后来我索性将磁盘移植到一块新的 E3-1230v2上，并更换了主板（包括板载NIC）。

linux磁盘监控--iostat一点小问题和util计算公式

Tue, 13 Sep 2022 09:40:26 CST

iostat简介

     iostat - Report Central Processing Unit (CPU) statistics and input/output statistics for devices, partitions and network filesystems (NFS)

通常用来看linux服务器io指标，也能看cpu，但是top看cpu比iostat猛，也能看网络指标NFS，但是sar又比iostat猛，所以就用来看io。

磁盘io负载通常影响线上数据落地，如果磁盘负载高，有很多请求在队列中来不及处理，导致线上数据处理延迟，因此需要个磁盘io负载的监控，笔者用的是iostat。

     (base) [work@node1 wwwroot]$ iostat -zx 
Linux 2.6.32-696.18.7.el6.x86_64 (ger-frankfurt-loget-dt-001)   12/11/2019  _x86_64_    (40 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.78    0.00    1.96    0.10    0.00   92.17

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.18     5.11    7.04   31.90   647.66  2769.29    87.76     0.05    1.22    2.55    0.93   0.24   0.92
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    3.79    3.79    0.00   3.76   0.00
sdb               0.00     0.15    4.95    3.63   420.92   455.76   102.17     0.06    6.83    0.25   15.82   0.10   0.08

以上命令能统计磁盘io的繁忙程度，读取util即可反应出来。but磁盘负载明显满了，告警却没有，排查发现，命令【iostat -xz】打印一次统计记录，每个盘符一条记录数据，但是这条数据却是固定的，我石化了，
如下所示，第二次统计记录是真实数据。

     (base) [work@node1 wwwroot]$ iostat -zx 1
Linux 2.6.32-696.18.7.el6.x86_64 (ger-frankfurt-loget-dt-001)   12/11/2019  _x86_64_    (40 CPU)
【我是假的】
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.78    0.00    1.96    0.10    0.00   92.17

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.18     5.11    7.04   31.90   647.64  2768.94    87.75     0.05    1.20    2.55    0.91   0.24   0.92
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    3.79    3.79    0.00   3.76   0.00
sdb               0.00     0.15    4.95    3.62   420.93   455.61   102.28     0.06    6.83    0.25   15.85   0.10   0.08
【我是真的】
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.85    0.00    7.12   39.22    0.00   34.81

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    2.00  238.00   264.00 117144.00   489.20   138.23  738.70  660.50  739.35   4.17 100.10
sdb               0.00     5.00   15.00 1375.00   120.00 19024.00    13.77    10.85    7.81    0.00    7.89   0.06   8.30
【我是真的】
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          20.02    0.00    7.25   37.41    0.00   35.32

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               2.00     2.00    2.00   74.00   136.00 35880.00   473.89   133.12  472.54  479.00  472.36  13.14  99.90
sdb               0.00     1.00   13.00 3289.00   104.00 42992.00    13.05    26.25    7.95    0.46    7.98   0.06  19.70
【我是真的】
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          19.89    0.00    7.29   42.86    0.00   29.96

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               1.00     1.00    7.00    6.00  1064.00  3072.00   318.15   135.67 1655.85  747.57 2715.50  76.92 100.00
sdb               0.00     0.00   14.00 2897.00   112.00 30664.00    10.57    22.76    7.82    1.14    7.85   0.06  17.90

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.64    0.00    7.71   32.16    0.00   37.49

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              12.00    36.00   22.00  614.00  7464.00 75232.00   130.03   153.18  678.43  165.18  696.82   1.57 100.00
sdb               0.00     1.00   17.00 3382.00   136.00 44016.00    12.99    29.80    8.77    0.18    8.81   0.07  22.40

读第二次数据解决问题

iostat -zx 1 2
统计两次数据，取第二次的，这也是奇葩。

关键指标释义--util公式

瑕不掩瑜，小毛病虽然让人尴尬，但是看磁盘io还是iostat猛。
整点关注3个指标：
1、avgqu-sz：请求队列长度。
2、svctm：平均io处理时长（毫秒）。
3、%util：io繁忙程度，就是负载强度。

rrqm/s: 每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并
wrqm/s: 每秒对该设备的写请求被合并次数
r/s: 每秒完成的读次数
w/s: 每秒完成的写次数
rkB/s: 每秒读数据量(kB为单位)
wkB/s: 每秒写数据量(kB为单位)
avgrq-sz:平均每次IO操作的数据量(扇区数为单位)
avgqu-sz: 平均等待处理的IO请求队列长度
await: 平均每次IO请求等待时间(包括等待时间和处理时间，毫秒为单位)
svctm: 平均每次IO请求的处理时间(毫秒为单位)
%util: 采用周期内用于IO操作的时间比率，即IO队列非空的时间比率

对于以上示例输出，我们可以获取到以下信息：

     Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda              12.00    36.00   22.00  614.00  7464.00 75232.00   130.03   153.18  678.43  165.18  696.82   1.57 100.00

每秒有636次IO操作(r/s+w/s)，其中以写操作为主体
平均每次IO请求等待处理的时间为678.43毫秒，处理耗时为1.57毫秒
等待处理的IO请求队列中，平均有153.18个请求驻留

公式

util = (r/s+w/s) * (svctm/1000)

对于上面的例子有：util = (22+614)*(1.57/1000) = 0.999

Linux文件系统inode详解

Sat, 13 Aug 2022 09:50:00 CST

文件系统

文件系统是操作系统中负责管理持久数据的子系统，说简单点，就是负责把用户的文件存到磁盘硬件中，因为即使计算机断电了，磁盘里的数据并不会丢失，所以可以持久化的保存文件。

文件系统的基本数据单位是文件，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同，就会形成不同的文件系统。

Linux 最经典的一句话是：「一切皆文件」，不仅普通的文件和目录，就连块设备、管道、socket 等，也都是统一交给文件系统管理的。

Linux 文件系统会为每个文件分配两个数据结构：索引节点（index node）和目录项（directory entry），它们主要用来记录文件的元信息和目录层次结构。

索引节点，也就是inode，用来记录文件的元信息，比如 inode 编号、文件大小、访问权限、创建时间、修改时间、数据在磁盘的位置等等。索引节点是文件的唯一标识，它们之间一一对应，也同样都会被存储在硬盘中，所以索引节点同样占用磁盘空间。
目录项，也就是dentry，用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，就会形成目录结构，但它与索引节点不同的是，目录项是由内核维护的一个数据结构，不存放于磁盘，而是缓存在内存。

由于索引节点唯一标识一个文件，而目录项记录着文件的名，所以目录项和索引节点的关系是多对一，也就是说，一个文件可以有多个目录。比如，硬链接的实现就是多个目录项中的索引节点指向同一个文件。

注意，目录也是文件，也是用索引节点唯一标识，和普通文件不同的是，普通文件在磁盘里面保存的是文件数据，而目录文件在磁盘里面保存子目录或文件。

虽然名字很相近，但是它们不是一个东西，目录是个文件，持久化存储在磁盘，而目录项是内核一个数据结构，缓存在内存。

如果查询目录频繁从磁盘读，效率会很低，所以内核会把已经读过的目录用目录项这个数据结构缓存在内存，下次再次读到相同的目录时，只需从内存读就可以，大大提高了文件系统的效率。

注意，目录项这个数据结构不只是表示目录，也是可以表示文件的。

文件数据是如何存储在磁盘的呢？

磁盘读写的最小单位是扇区，扇区的大小只有 512字节，那么如果数据大于512字节时候，磁盘需要不停地移动磁头来查找数据，我们知道一般的文件很容易超过512字节那么如果把多个扇区合并为一个块，那么磁盘就可以提高效率了。那么磁头一次读取多个扇区就为一个块“block”（Linux上称为块，Windows上称为簇）。所以，文件系统把多个扇区组成了一个逻辑块，每次读写的最小单位就是逻辑块（数据块），Linux 中的逻辑块大小为 4KB，也就是一次性读写 8 个扇区，这将大大提高了磁盘的读写的效率。

文件系统记录的数据，除了其自身外，还有数据的权限信息，所有者等属性，这些信息都保存在inode中，那么谁来记录inode信息和文件系统本身的信息呢，比如说文件系统的格式，inode与data的数量呢？那么就有一个超级区块（supper block）来记录这些信息了。

superblock：记录此 filesystem 的整体信息，包括inode/block的总量、使用量、剩余量，以及文件系统的格式与相关信息等
inode：记录文件的属性信息，可以使用stat命令查看inode信息。
block：实际文件的内容，如果一个文件大于一个块时候，那么将占用多个block，但是一个块只能存放一个文件。（因为数据是由inode指向的，如果有两个文件的数据存放在同一个块中，就会乱套了）

node用来指向数据block，那么只要找到inode，再由inode找到block编号，那么实际数据就能找出来了。

索引节点是存储在硬盘上的数据，为了加速文件的访问，通常会把索引节点加载到内存中。我们不可能把超级块和索引节点区全部加载到内存，这样内存肯定撑不住，所以只有当需要使用的时候，才将其加载进内存，它们加载进内存的时机是不同的：

超级块：当文件系统挂载时进入内存；
索引节点区：当文件被访问时进入内存；

虚拟文件系统

文件系统的种类众多，而操作系统希望对用户提供一个统一的接口，于是在用户层与文件系统层引入了中间层，这个中间层就称为虚拟文件系统（Virtual File System，VFS）。VFS 定义了一组所有文件系统都支持的数据结构和标准接口，这样程序员不需要了解文件系统的工作原理，只需要了解 VFS 提供的统一接口即可。在 Linux 文件系统中，用户空间、系统调用、虚拟机文件系统、缓存、文件系统以及存储之间的关系如下图：

Linux 支持的文件系统也不少，根据存储位置的不同，可以把文件系统分为三类：

磁盘的文件系统，它是直接把数据存储在磁盘中，比如 Ext 2/3/4、XFS 等都是这类文件系统。
内存的文件系统，这类文件系统的数据不是存储在硬盘的，而是占用内存空间，我们经常用到的/proc 和 /sys 文件系统都属于这一类，读写这类文件，实际上是读写内核中相关的数据。
网络的文件系统，用来访问其他计算机主机数据的文件系统，比如 NFS、SMB 等等。

文件系统首先要先挂载到某个目录才可以正常使用，比如 Linux 系统在启动时，会把文件系统挂载到根目录。

Linux 采用为分层的体系结构，将用户接口层、文件系统实现和存储设备的驱动程序分隔开，进而兼容不同的文件系统。虚拟文件系统（Virtual File System, VFS）是 Linux 内核中的软件层，它在内核中提供了一组标准的、抽象的文件操作，允许不同的文件系统实现共存，并向用户空间程序提供统一的文件系统接口。下面这张图展示了 Linux 虚拟文件系统的整体结构：

从上图可以看出，用户空间的应用程序直接、或是通过编程语言提供的库函数间接调用内核提供的 System Call 接口（如open()、write()等）执行文件操作。System Call 接口再将应用程序的参数传递给虚拟文件系统进行处理。

每个文件系统都为 VFS 实现了一组通用接口，具体的文件系统根据自己对磁盘上数据的组织方式操作相应的数据。当应用程序操作某个文件时，VFS 会根据文件路径找到相应的挂载点，得到具体的文件系统信息，然后调用该文件系统的对应操作函数。

VFS 提供了两个针对文件系统对象的缓存 INode Cache 和 DEntry Cache，它们缓存最近使用过的文件系统对象，用来加快对 INode 和 DEntry 的访问。Linux 内核还提供了 Buffer Cache 缓冲区，用来缓存文件系统和相关块设备之间的请求，减少访问物理设备的次数，加快访问速度。Buffer Cache 以 LRU 列表的形式管理缓冲区。

VFS 的好处是实现了应用程序的文件操作与具体的文件系统的解耦，使得编程更加容易：

应用层程序只要使用 VFS 对外提供的read()、write()等接口就可以执行文件操作，不需要关心底层文件系统的实现细节；
文件系统只需要实现 VFS 接口就可以兼容 Linux，方便移植与维护；
无需关注具体的实现细节，就实现跨文件系统的文件操作。

了解 Linux 文件系统的整体结构后，下面主要分析 Linux VFS 的技术原理。由于文件系统与设备驱动的实现非常复杂，笔者也未接触过这方面的内容，因此文中不会涉及具体文件系统的实现。

VFS 结构

Linux 以一组通用对象的角度看待所有文件系统，每一级对象之间的关系如下图所示：

fd 与 file

每个进程都持有一个fd[]数组，数组里面存放的是指向file结构体的指针，同一进程的不同fd可以指向同一个file对象；

file是内核中的数据结构，表示一个被进程打开的文件，和进程相关联。当应用程序调用open()函数的时候，VFS 就会创建相应的file对象。它会保存打开文件的状态，例如文件权限、路径、偏移量等等。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L936 结构体已删减
struct file {
    struct path                   f_path;
    struct inode                  *f_inode;
    const struct file_operations  *f_op;
    unsigned int                  f_flags;
    fmode_t                       f_mode;
    loff_t                        f_pos;
    struct fown_struct            f_owner;
}

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/path.h#L8
struct path {
    struct vfsmount  *mnt;
    struct dentry    *dentry;
}

从上面的代码可以看出，文件的路径实际上是一个指向 DEntry 结构体的指针，VFS 通过 DEntry 索引到文件的位置。

除了文件偏移量f_pos是进程私有的数据外，其他的数据都来自于 INode 和 DEntry，和所有进程共享。不同进程的file对象可以指向同一个 DEntry 和 Inode，从而实现文件的共享。

DEntry 与 INode

Linux文件系统会为每个文件都分配两个数据结构，目录项（DEntry, Directory Entry）和索引节点（INode, Index Node）。

DEntry 用来保存文件路径和 INode 之间的映射，从而支持在文件系统中移动。DEntry 由 VFS 维护，所有文件系统共享，不和具体的进程关联。dentry对象从根目录“/”开始，每个dentry对象都会持有自己的子目录和文件，这样就形成了文件树。举例来说，如果要访问”/home/beihai/a.txt”文件并对他操作，系统会解析文件路径，首先从“/”根目录的dentry对象开始访问，然后找到”home/“目录，其次是“beihai/”，最后找到“a.txt”的dentry结构体，该结构体里面d_inode字段就对应着该文件。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/dcache.h#L89 结构体已删减
struct dentry {
    struct dentry *d_parent;     // 父目录
    struct qstr d_name;          // 文件名称
    struct inode *d_inode;       // 关联的 inode
    struct list_head d_child;    // 父目录中的子目录和文件
    struct list_head d_subdirs;  // 当前目录中的子目录和文件
}

每一个dentry对象都持有一个对应的inode对象，表示 Linux 中一个具体的目录项或文件。INode 包含管理文件系统中的对象所需的所有元数据，以及可以在该文件对象上执行的操作。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L628 结构体已删减
struct inode {
    umode_t                 i_mode;          // 文件权限及类型
    kuid_t                  i_uid;           // user id
    kgid_t                  i_gid;           // group id

    const struct inode_operations    *i_op;  // inode 操作函数，如 create，mkdir，lookup，rename 等
    struct super_block      *i_sb;           // 所属的 SuperBlock

    loff_t                  i_size;          // 文件大小
    struct timespec         i_atime;         // 文件最后访问时间
    struct timespec         i_mtime;         // 文件最后修改时间
    struct timespec         i_ctime;         // 文件元数据最后修改时间（包括文件名称）
    const struct file_operations    *i_fop;  // 文件操作函数，open、write 等
    void                    *i_private;      // 文件系统的私有数据
}

虚拟文件系统维护了一个 DEntry Cache 缓存，用来保存最近使用的 DEntry，加速查询操作。当调用open()函数打开一个文件时，内核会第一时间根据文件路径到 DEntry Cache 里面寻找相应的 DEntry，找到了就直接构造一个file对象并返回。如果该文件不在缓存中，那么 VFS 会根据找到的最近目录一级一级地向下加载，直到找到相应的文件。期间 VFS 会缓存所有被加载生成的dentry。

INode 存储的数据存放在磁盘上，由具体的文件系统进行组织，当需要访问一个 INode 时，会由文件系统从磁盘上加载相应的数据并构造 INode。一个 INode 可能被多个 DEntry 所关联，即相当于为某一文件创建了多个文件路径（通常是为文件建立硬链接）。

SuperBlock

SuperBlock 表示特定加载的文件系统，用于描述和维护文件系统的状态，由 VFS 定义，但里面的数据根据具体的文件系统填充。每个 SuperBlock 代表了一个具体的磁盘分区，里面包含了当前磁盘分区的信息，如文件系统类型、剩余空间等。SuperBlock 的一个重要成员是链表s_list，包含所有修改过的 INode，使用该链表很容易区分出来哪个文件被修改过，并配合内核线程将数据写回磁盘。SuperBlock 的另一个重要成员是s_op，定义了针对其 INode 的所有操作方法，例如标记、释放索引节点等一系列操作。

// https://elixir.bootlin.com/linux/v5.4.93/source/include/linux/fs.h#L1425 结构体已删减
struct super_block {
    struct list_head    s_list;               // 指向链表的指针
    dev_t               s_dev;                // 设备标识符
    unsigned long       s_blocksize;          // 以字节为单位的块大小
    loff_t              s_maxbytes;           // 文件大小上限
    struct file_system_type    *s_type;       // 文件系统类型
    const struct super_operations    *s_op;   // SuperBlock 操作函数，write_inode、put_inode 等
    const struct dquot_operations    *dq_op;  // 磁盘限额函数
    struct dentry        *s_root;             // 根目录
}

SuperBlock 是一个非常复杂的结构，通过 SuperBlock 我们可以将一个实体文件系统挂载到 Linux 上，或者对 INode 进行增删改查操作。所以一般文件系统都会在磁盘上存储多份 SuperBlock，防止数据意外损坏导致整个分区无法读取。

inode 内容

inode包含很多的文件元信息，但不包含文件名，例如：字节数、属主UserID、属组GroupID、读写执行权限、时间戳等。而文件名存放在目录当中，但Linux系统内部不使用文件名，而是使用inode号码识别文件。对于系统来说文件名只是inode号码便于识别的别称。

stat

查看inode信息

[root@localhost ~]# mkdir test
[root@localhost ~]# echo "this is test file" > test.txt
[root@localhost ~]# stat test.txt
  File: ‘test.txt’
  Size: 18              Blocks: 8          IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 33574994    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2019-08-28 19:55:05.920240744 +0800
Modify: 2019-08-28 19:55:05.920240744 +0800
Change: 2019-08-28 19:55:05.920240744 +0800
 Birth: -

三个主要的时间属性：

ctime：change time是最后一次改变文件或目录（属性）的时间，例如执行chmod，chown等命令。
atime：access time是最后一次访问文件或目录的时间。
mtime：modify time是最后一次修改文件或目录（内容）的时间。

file

查看文件类型

[root@localhost ~]# file test
test: directory
[root@localhost ~]# file test.txt
test.txt: ASCII text

inode 号码

表面上，用户通过文件名打开文件，实际上，系统内部将这个过程分为三步：

系统找到这个文件名对应的inode号码；
通过inode号码，获取inode信息；
根据inode信息，找到文件数据所在的block，并读出数据。

其实系统还要根据inode信息，看用户是否具有访问的权限，有就指向对应的数据block，没有就返回权限拒绝。

ls -i

直接查看文件i节点号，也可以通过stat查看文件inode信息查看i节点号。

[root@localhost ~]# ls -i
33574991 anaconda-ks.cfg      2086 test  33574994 test.txt

inode 大小

inode也会消耗硬盘空间，所以格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区，存放inode所包含的信息。每个inode的大小，一般是128字节或256字节。通常情况下不需要关注单个inode的大小，而是需要重点关注inode总数。inode总数在格式化的时候就确定了。

df -i

查看硬盘分区的inode总数和已使用情况

[root@localhost ~]# df -i
Filesystem               Inodes IUsed   IFree IUse% Mounted on
/dev/mapper/centos-root 8910848 26029 8884819    1% /
devtmpfs                 230602   384  230218    1% /dev
tmpfs                    233378     1  233377    1% /dev/shm
tmpfs                    233378   487  232891    1% /run
tmpfs                    233378    16  233362    1% /sys/fs/cgroup
/dev/sda1                524288   328  523960    1% /boot
tmpfs                    233378     1  233377    1% /run/user/0

文件的读写

文件系统在打开一个文件时，要做的有：

系统找到这个文件名对应的inode：在目录表中查找该文件名对应的项，由此得到该文件相对应的 inode 号
通过inode号，获取到磁盘中的inode信息，其中最重要的内容是磁盘地址表
通过inode信息中的磁盘地址表，文件系统把分散存放的文件物理块连接成文件的逻辑结构。在磁盘地址表中有 13 个块号，文件将以块号在磁盘地址表中出现的顺序依次读取相应的块。找到文件数据所在的block，读出数据。

根据以上流程，我们可以发现，inode应该是有一个专门的存储区域的，以方便系统快速查找。事实上，一块磁盘创建的时候，操作系统自动将硬盘分成两个区域：存放文件数据的数据区，与存放inode信息的inode区（inode table）。

每个inode的大小一般是128B或者256B。inode节点的总数，在格式化时就给定，一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中，每个inode节点的大小为128字节，每1KB就设置一个inode，那么inode table的大小就会达到128MB，占整块硬盘的12.8%。

也就是说，每个分区的inode总数从格式化之后就固定了，因此有可能会出现存储空间没有占满，但因为小文件太多而耗尽了inode的情况。这个时候就只能清除inode占用高的文件或者目录或修改inode数量了，当然，inode的调整需要重新格式化磁盘，需要确保数据已经得到有效备份后，再进行此操作。

这时候又产生了新的问题：文件创建时要为文件分配哪一个inode号呢？即如何保证分配的inode号没有被占用？
既然是”是否被占用”的问题，使用位图是最佳方案，像bmap记录block的占用情况一样。标识inode号是否被分配的位图称为inodemap简称为imap。这时要为一个文件分配inode号只需扫描imap即可知道哪一个inode号是空闲的。

(位图法就是bitmap的缩写。所谓bitmap，就是用每一位来存放某种状态，适用于大规模数据，但数据状态又不是很多的情况。)
类似bmap块位图一样，inode号是预先规划好的。inode号分配后，文件删除也会释放inode号。分配和释放的inode号，像是在一个地图上挖掉一块，用完再补回来一样。
imap存在着和bmap和inode table一样需要解决的问题：如果文件系统比较大，imap本身就会很大，每次存储文件都要进行扫描，会导致效率不够高。同样，优化的方式是将文件系统占用的block划分成块组，每个块组有自己的imap范围，以减少检索时间。

利用df -i命令可以查看inode数量方面的信息

文件的操作

系统对文件的操作会可能影响inode：

复制：创建一个包含全部数据与新inode号的新文件
移动：在同一磁盘下移动时，所在目录改变，node号与实际数据存储的块的位置都不会变化。跨磁盘移动当然会删除本磁盘的数据并创建一条新的数据在另一块磁盘中。
硬链接：同一个inode号代表的文件有多个文件名，即可以用不同的文件名访问同一份数据，但是它们指向的inode编号是相同的，并且文件元数据中链接数会增加。不可以对目录创建硬链接。
软链接：软链接的本质是一个链接文件，其中存储的了对另一个文件的指针。所以对一个文件创建软链接，inode号不相同，创建软链接文件的链接数不会增加。可以对目录创建软链接。
删除：当删除文件时，会先检查inode中的链接数。如果链接数大于1，就只会删掉一个硬链接，不影响数据。如果链接数等于1，那么这个inode就会被释放掉，对应的inode指向的块也会被标记为空闲的（数据不会被置零，所以硬盘数据被误删除后，若没有新数据写入可恢复）。如果是软链接，原文件被删除后链接文件就变成了悬挂链接（dangling link），无法正常访问了。

利用inode还可以删除一些文件名中有转义字符或控制字符的文件，最典型的就是开头为减号-的文件。这种无法直接用rm命令来搞，就可以先查出它们的inode编号再删除： find ./ -inum 10086 -exec rm {} \

特有现象

由于inode号码与文件名分离，导致一些Unix/Linux系统具备以下几种特有的现象。

文件名包含特殊字符，可能无法正常删除。这时直接删除inode，能够起到删除文件的作用； find ./* -inum 节点号 -delete
移动文件或重命名文件，只是改变文件名，不影响inode号码；
打开一个文件以后，系统就以inode号码来识别这个文件，不再考虑文件名。

这种情况使得软件更新变得简单，可以在不关闭软件的情况下进行更新，不需要重启。因为系统通过inode号码，识别运行中的文件，不通过文件名。更新的时候，新版文件以同样的文件名，生成一个新的inode，不会影响到运行中的文件。等到下一次运行这个软件的时候，文件名就自动指向新版文件，旧版文件的inode则被回收。

inode 耗尽故障

由于硬盘分区的inode总数在格式化后就已经固定，而每个文件必须有一个inode，因此就有可能发生inode节点用光，但硬盘空间还剩不少，却无法创建新文件。同时这也是一种攻击的方式，所以一些公用的文件系统就要做磁盘限额，以防止影响到系统的正常运行。至于修复，很简单，只要找出哪些大量占用i节点的文件删除就可以了。

硬链接与软连接

Linux系统中有一种比较特殊的文件称之为链接（link）。通俗地说，链接就是从一个文件指向另外一个文件的路径。linux中链接分为俩种，硬链接和软链接。简单来说，硬链接相当于源文件和链接文件在磁盘和内存中共享一个inode，因此，链接文件和源文件有不同的dentry，因此，这个特性决定了硬链接无法跨越文件系统，而且我们无法为目录创建硬链接。软链接和硬链接不同，首先软链接可以跨越文件系统，其次，链接文件和源文件有着不同的inode和dentry，因此，两个文件的属性和内容也截然不同，软链接文件的文件内容是源文件的文件名。

硬链接是多个目录项中的「索引节点」指向一个文件，也就是指向同一个 inode，但是 inode 是不可能跨越文件系统的，每个文件系统都有各自的 inode 数据结构和列表，所以硬链接是不可用于跨文件系统的。由于多个目录项都是指向一个 inode，那么只有删除文件的所有硬链接以及源文件时，系统才会彻底删除该文件。

软链接相当于重新创建一个文件，这个文件有独立的 inode，但是这个文件的内容是另外一个文件的路径，所以访问软链接的时候，实际上相当于访问到了另外一个文件，所以软链接是可以跨文件系统的，甚至目标文件被删除了，链接文件还是在的，只不过指向的文件找不到了而已。

软硬链接实现的原理不同
- 硬链接是建立一个目录项，包含文件名和文件的inode，但inode是原来文件的inode号，并不建立其所对应得数据。所以硬链接并不占用inode。
- 软连接也创建一个目录项，也包含文件名和文件的inode，但它的inode指向的并不是原来文件名所指向的数据的inode，而是新建一个inode，并建立数据，数据指向的是原来文件名，所以原来文件名的字符数，即为软连接所占字节数
软硬链接所能创建的目标有区别
- 因为每个分区各有一套不同的inode表，所以硬链接不能跨分区创建而软连接可以,因为软连接指向的书文件名。
硬链接不能指向目录
- 如果说目录有硬链接那么可能引入死循环，但是你可能会疑问软连接也会陷入循环啊，答案当然不是，因为软连接是存在自己的数据的，可以查看自己的文件属性，既然可以判断出来软连接，那么自然不会陷入循环，并且系统在连续遇到8个符号连接后就停止遍历。但是硬链接可就不行了，因为他的inode号一致，所以就判断不出是硬链接，所以就会陷入死循环了。

参考链接：

Linux系统安全加固指南

Sat, 30 Apr 2022 21:10:32 CST

▲ 点击上方“分布式实验室”关注公众号

回复“1”抽取纸质技术书

本指南旨在说明如何尽可能地加强Linux的安全性和隐私性，并且不限于任何特定的指南。

免责声明：如果您不确定自己在做什么，请不要尝试在本文中使用任何内容。

本指南仅关注安全性和隐私性，而不关注性能，可用性或其他内容。

列出的所有命令都将需要root特权。以“$”符号开头的单词表示一个变量，不同终端之间可能会有所不同。

— 1 —
选择正确的Linux发行版

选择一个好的Linux发行版有很多因素。

避免分发冻结程序包，因为它们在安全更新中通常很落后。
不使用与Systemd机制的发行版。Systemd包含许多不必要的攻击面；它尝试做的事情远远超出了必要，并且超出了初始化系统应做的事情。
使用musl作为默认的C库。Musl专注于最小化，这会导致很小的攻击面，而其他C库（例如glibc）过于复杂，容易产生漏洞。例如，与musl中的极少数漏洞相比，glibc中的一百多个漏洞已被公开披露。尽管仅靠披露的CVE本身通常是不准确的统计信息，但有时这种情况有时可以用来表示过分的问题。Musl还具有不错的漏洞利用缓解措施，尤其是其新的强化内存分配器。
最好默认情况下使用LibreSSL而不是OpenSSL的发行版。OpenSSL包含大量完全不必要的攻击面，并且遵循不良的安全做法。例如，它仍然保持OS / 2和VMS支持这些已有数十年历史的古老操作系统。这些令人讨厌的安全做法导致了可怕的Heartbleed漏洞。LibreSSL是OpenBSD团队的OpenSSL分支，它采用了出色的编程实践并消除了很多攻击面。在LibreSSL成立的第一年内，它缓解了许多漏洞，其中包括一些高严重性的漏洞。

用作强化操作系统基础的最佳发行版是Gentoo Linux，因为它可以让您精确地配置系统，以达到理想的效果，这将非常有用，尤其是参考我们在后面的章节中使用更安全的编译标志。

但是，由于Gentoo的巨大可用性缺陷，它对于许多人来说可能并不顺手。在这种情况下，Void Linux的Musl构建是一个很好的折衷方案。

— 2 —
内核

内核是操作系统的核心，不幸的是很容易受到攻击。正如Brad Spengler曾经说过的那样，可以将其视为系统上最大，最易受攻击的setuid根二进制文件。因此，对内核进行尽可能多的强化非常重要。

Stable vs LTS内核

Linux内核以两种主要形式发布：稳定和长期支持（LTS）。稳定版本是较新的版本，而LTS发行版本是较老的稳定版本，长期以来一直受支持。选择上述任何一个发行版本都有许多后果。

Linux内核未使用CVE标识安全漏洞。这意味着大多数安全漏洞的修复程序不能向后移植到LTS内核。但是稳定版本包含到目前为止进行的所有安全修复。

但是，有了这些修复程序，稳定的内核将包含更多新功能，因此大大增加了内核的攻击面，并引入了大量新错误。相反，LTS内核的受攻击面较小，因为这些功能没有被不断添加。

此外，稳定的内核还包括更新的强化功能，以减轻LTS内核没有的某些利用。此类功能的一些示例是Lockdown LSM和STACKLEAK GCC插件。

总而言之，在选择稳定或LTS内核时需要权衡取舍。LTS内核具有较少的强化功能，并且并非当时所有的公共错误修复都已向后移植，但是通常它的攻击面更少，并且引入未知错误的可能性也较小。

稳定的内核具有更多的强化功能，并且包括所有已知的错误修复，但它也具有更多的攻击面以及引入更多未知错误的机会更大。最后，最好使用较新的LTS分支（如4.19内核）。

Sysctl

Sysctl是允许用户配置某些内核设置并启用各种安全功能或禁用危险功能以减少攻击面的工具。要临时更改设置，您可以执行：

      sysctl -w $tunable = $value

要永久更改sysctls，您可以将要更改的sysctls添加到/etc/sysctl.conf或/etc/sysctl.d中的相应文件，具体取决于您的Linux发行版。

以下是您应更改的建议sysctl设置。

Kernel self-protection：

      kernel.kptr_restrict=2

内核指针指向内核内存中的特定位置。这些在利用内核方面可能非常有用，但是默认情况下不会隐藏内核指针，例如，通过读取/proc/kallsyms的内容即可轻松发现它们。此设置旨在减轻内核指针泄漏。另外，您可以设置kernel.kptr_restrict = 1以仅从没有CAP_SYSLOG功能的进程中隐藏内核指针。

      kernel.dmesg_restrict=1

dmesg是内核日志，它公开了大量有用的内核调试信息，但这通常会泄漏敏感信息，例如内核指针。更改上述sysctl设置会将内核日志限制为CAP_SYSLOG功能。

      kernel.printk=3 3 3 3

尽管dmesg_restrict的值，启动过程中内核日志仍将显示在控制台中。能够在引导过程中记录屏幕的恶意软件可能会滥用此恶意软件以获得更高的特权。此选项可防止这些信息泄漏。必须将其与下面描述的某些引导参数结合使用才能完全有效。

      kernel.unprivileged_bpf_disabled=1        
net.core.bpf_jit_harden=2

eBPF暴露了很大的攻击面，因此需加以限制。这些系统将eBPF限制为CAP_BPF功能（在5.8之前的内核版本上为CAP_SYS_ADMIN），并启用JIT强化技术，例如常量绑定。

      dev.tty.ldisc_autoload=0

这将加载TTY行规则限制为CAP_SYS_MODULE功能，以防止非特权的攻击者使用TIOCSETD ioctl加载易受攻击的线路规则，而该TIOCSETD ioctl之前已在许多漏洞利用中被滥用。

      vm.unprivileged_userfaultfd=0

serfaultfd() 系统调用经常被滥用以利用“事后使用(use-after-free)”缺陷。因此，该sysctl用于将此syscall限制为CAP_SYS_PTRACE功能。

      kernel.kexec_load_disabled=1

kexec是一个系统调用，用于在运行时引导另一个内核。可以滥用此功能来加载恶意内核并在内核模式下获得任意代码执行能力，因此该sysctl设置将被禁用。

      kernel.sysrq=4

SysRq密钥向非特权用户公开了许多潜在的危险调试功能。与通常的假设相反，SysRq不仅是物理攻击的问题，而且还可以远程触发。该sysctl的值使其可以使用户只能使用SAK密钥，这对于安全地访问root是必不可少的。或者，您可以简单地将值设置为0以完全禁用SysRq。

      kernel.unprivileged_userns_clone=0

请注意，尽管该sysctl仅在某些Linux发行版中存在，因为它需要内核补丁。如果您的内核不包含此补丁，则可以通过设置user.max_user_namespaces = 0来完全禁用用户名称空间（包括root用户）。

      kernel.unprivileged_userns_clone=0

用能事件会增加大量内核攻击面，并导致大量漏洞。此sysctl设置将性能事件的所有使用限制为CAP_PERFMON功能（5.8之前的内核版本为CAP_SYS_ADMIN）。

请注意，此sysctl设置需要在某些发行版中具备相关的内核补丁。否则，此设置等效于kernel.perf_event_paranoid = 2，它仅限制此功能的子集。

网络：

      net.ipv4.tcp_syncookies=1

这有助于防止SYN泛洪攻击，这种攻击是拒绝服务攻击的一种形式，在这种攻击中，攻击者发送大量虚假的SYN请求，以尝试消耗足够的资源以使系统对合法流量不响应。

      net.ipv4.tcp_rfc1337=1

这通过丢弃处于时间等待状态的套接字的RST数据包来防止time-wait状态。

      net.ipv4.conf.all.rp_filter=1        
net.ipv4.conf.default.rp_filter=1

这些启用了源验证，以验证从计算机所有网络接口接收到的数据包。

net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.ipv4.conf.default.secure_redirects=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.default.accept_redirects=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0

这些设置禁用了ICMP重定向，以防止中间人攻击并最大程度地减少信息泄露。

      net.ipv4.icmp_echo_ignore_all=1

此设置使您的系统忽略所有ICMP请求，以避免Smurf攻击，使设备更难以在网络上枚举，并防止通过ICMP时间戳识别时钟指纹。

net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.default.accept_source_route=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.default.accept_source_route=0

源路由是一种允许用户重定向网络流量的机制。由于这可用于执行中间人攻击，在中间人攻击中，出于恶意目的将流量重定向，因此上述设置将会禁用此功能。

      net.ipv6.conf.all.accept_ra=0        
net.ipv6.conf.default.accept_ra=0

恶意的IPv6路由广告可能会导致中间人攻击，因此应将其禁用。

      net.ipv4.tcp_sack=0        
net.ipv4.tcp_dsack=0        
net.ipv4.tcp_fack=0

禁用TCP SACK。ACK通常被利用，并且在许多情况下是不必要的，因此如果您不需要它，则应将其禁用。

用户空间：

      kernel.yama.ptrace_scope=2

ptrace是一个系统调用，它允许程序调试、修改和检查另一个正在运行的进程，从而使攻击者可以轻易修改其他正在运行的程序的内存。设置将ptrace的使用限制为仅具有CAP_SYS_PTRACE功能的进程。或者，将sysctl设置为3以完全禁用ptrace。

      vm.mmap_rnd_bits=32        
vm.mmap_rnd_compat_bits=16

ASLR是一种常见的漏洞利用缓解措施，它可以使进程的关键部分在内存中的位置随机化。这可能会使各种各样的漏洞利用更困难，因为它们首先需要信息泄漏。上述设置增加了用于mmap ASLR的熵的位数，从而提高了其有效性。

这些sysctls的值必须根据CPU体系结构进行设置。以上值与x86兼容，但其他体系结构可能有所不同。

      fs.protected_symlinks=1        
fs.protected_hardlinks=1

仅当在可全局写入的粘性目录之外，当符号链接和关注者的所有者匹配或目录所有者与符号链接的所有者匹配时，才允许遵循符号链接。这还可以防止没有对源文件的读/写访问权限的用户创建硬链接。这两者都阻止了许多常见的TOCTOU漏洞（time-of-check-to-time-of-use）。

fs.protected_fifos=2      
fs.protected_regular=2

这些阻止了在可能由攻击者控制的环境（例如，全局可写目录）中创建文件，从而使数据欺骗攻击更加困难。

引导参数

引导参数在引导时使用引导加载程序（bootloader）将设置传递给内核。类似于sysctl，可以使用某些设置来提高安全性。引导加载程序通常在引导参数设置方式上有所不同。下面列出了一些示例，但是您应该研究特定bootloader的修改参数的必要步骤。

如果使用GRUB作为引导程序，请编辑/etc /default/grub并将参数添加到GRUB_CMDLINE_LINUX_DEFAULT=line。

如果使用Syslinux，请编辑/boot/syslinux/syslinux.cfg并将它们添加到APPEND行中。

如果使用systemd-boot，请编辑您的加载程序条目，并将其附加到linux行的末尾。

建议使用以下设置以提高安全性。

Kernel self-protection：

slab_nomerge

这将禁用slab合并，这将通过防止覆盖合并的缓存中的对象并使其更难以影响slab缓存的布局，从而大大增加了堆利用的难度。

      slub_debug=FZ

这些启用健全性检查（F）和重新分区（Z）。健全性检查会添加各种检查，以防止某些slab操作中的损坏。重新分区会在slab周围添加额外的区域，以检测slab何时被覆盖超过其实际大小，从而有助于检测溢出。

      init_on_alloc=1 init_on_free=1

这样可以在分配和空闲时间期间将内存清零，这可以帮助减轻使用后使用的漏洞并清除内存中的敏感信息。如果您的内核版本低于5.3，则这些选项不存在。而是在上述slub_debug选项后面附加“ P”，以获得slub_debug=FZP并添加page_poison=1。由于它们实际上是一种调试功能，刚好具有一些安全性，因此它们在释放时提供的内存擦除形式较弱。

      page_alloc.shuffle=1

此选项使页分配器空闲列表随机化，从而通过降低页分配的可预测性来提高安全性，同时这也提高了性能。

      pti=on

这将启用内核页表隔离，从而减轻崩溃并防止某些KASLR绕过。

      vsyscall=none

这将禁用vsyscall，因为它们已过时且已被vDSO取代。 vsyscall也在内存中的固定地址上，使其成为ROP攻击的潜在目标。

      debugfs=off

这将禁用debugfs，它会公开许多有关内核的敏感信息。

      oops=panic

有时某些内核漏洞利用会导致所谓的“oops”。此参数将引发内核对此类事件panic，从而防止这些攻击。但是，有时错误的驱动程序会导致无害的操作，这会导致系统崩溃，这意味着此引导参数只能在某些硬件上使用。

      module.sig_enforce=1

这仅允许加载已使用有效密钥签名的内核模块，使加载恶意内核模块更加困难。

这可以防止加载所有树外内核模块（包括DKMS模块），除非您已对其进行签名，这意味着诸如VirtualBox或Nvidia驱动程序之类的模块可能不可用，但根据您的设置可能并不重要。

      lockdown=confidentiality

内核锁定LSM可以消除用户空间代码滥用以升级为内核特权并提取敏感信息的许多方法。为了在用户空间和内核之间实现清晰的安全边界，此LSM是必需的。上面的选项在confidentiality模式（最严格的选项）中启用此功能。这意味着module.sig_enforce=1。

      mce=0

这将导致内核对ECC内存中无法利用的错误panic，而这些错误可能会被利用。对于没有ECC内存的系统，这是不必要的。

      quiet loglevel=0

这些参数可防止引导期间信息泄漏，并且必须与上面的kernel.printk sysctl结合使用。

CPU缓解：

最好启用适用于您的CPU的所有CPU缓解措施，以确保您不受已知漏洞的影响。这是启用所有内置缓解措施的列表：

      spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force

您必须研究系统受其影响的CPU漏洞，并相应地选择上述缓解措施。请记住，您将需要安装微代码更新，以完全免受这些漏洞的影响。但所有这些操作都可能导致性能显着下降。

结果：

如果遵循了以上所有建议（不包括特定的CPU缓解措施），则将具有：

      slab_nomerge slub_debug=FZ init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on vsyscall=none debugfs=off oops=panic module.sig_enforce=1 lockdown=confidentiality mce=0 quiet loglevel=0

如果将GRUB用作引导加载程序，则可能需要重新生成GRUB配置文件才能应用这些文件。

hidepid

proc是一个伪文件系统，其中包含有关系统上当前正在运行的所有进程的信息。默认情况下，所有用户都可以访问此程序，这可能使攻击者可以窥探其他进程。

要只允许用户看到自己的进程，而不能看到其他用户的进程，则必须使用hidepid=2，gid=proc挂载选项来挂载/proc。gid=proc将proc组从此功能中排除，因此您可以将特定的用户或进程列入白名单。添加这些选项的一种方法是编辑/etc/fstab并添加：

      proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0

systemd-logind仍然需要查看其他用户的进程，因此，要使用户会话在systemd系统上正常工作，必须创建/etc/systemd/system/systemd-logind.service.d/hidepid.conf并添加：

      [Service]        
SupplementaryGroups=proc

减少内核攻击面

最好禁用不是绝对必要的任何功能，以最大程度地减少潜在的内核攻击面。这些功能不必一定很危险，它们可以只是被删除以减少攻击面的良性代码。切勿禁用您不了解的随机事物。以下是一些可能有用的示例，具体取决于您的设置。

引导参数：

引导参数通常可以用来减少攻击面，这样的例子之一是：

      ipv6.disable=1

这将禁用整个IPv6堆栈，如果您尚未迁移到该堆栈，则可能不需要该堆栈。如果正在使用的IPv6，请不要使用此引导参数。

将内核模块列入黑名单：

内核允许非特权的用户通过模块自动加载来间接导致某些模块被加载。这使攻击者可以自动加载易受攻击的模块，然后加以利用。一个这样的示例是CVE-2017-6074，其中攻击者可以通过启动DCCP连接来触发DCCP内核模块的加载，然后利用该内核模块中的漏洞。

可以通过将文件插入/etc/modprobe.d并将指定的内核模块列入黑名单的方法，将特定的内核模块列入黑名单。

Install参数告诉modprobe运行特定命令，而不是像往常一样加载模块。/bin/false是仅返回1的命令，该命令实际上不会执行任何操作。两者都告诉内核运行/bin/false 而不是加载模块，这将防止攻击者利用该模块。以下是最有可能不需要的内核模块：

install dccp /bin/false
install sctp /bin/false
install rds /bin/false
install tipc /bin/false
install n-hdlc /bin/false
install ax25 /bin/false
install netrom /bin/false
install x25 /bin/false
install rose /bin/false
install decnet /bin/false
install econet /bin/false
install af_802154 /bin/false
install ipx /bin/false
install appletalk /bin/false
install psnap /bin/false
install p8023 /bin/false
install p8022 /bin/false
install can /bin/false
install atm /bin/false

特别是模糊的网络协议会增加大量的远程攻击面。此黑名单：

DCCP — Datagram Congestion Control Protocol

SCTP — Stream Control Transmission Protocol

RDS — Reliable Datagram Sockets

TIPC — Transparent Inter-process Communication

HDLC — High-Level Data Link Control

AX25 — Amateur X.25

NetRom

X25

ROSE

DECnet

Econet

af_802154 — IEEE 802.15.4

IPX — Internetwork Packet Exchange

AppleTalk

PSNAP — Subnetwork Access Protocol

p8023 — Novell raw IEEE 802.3

p8022 — IEEE 802.2

CAN — Controller Area Network

ATM

install cramfs /bin/false
install freevxfs /bin/false
install jffs2 /bin/false
install hfs /bin/false
install hfsplus /bin/false
install squashfs /bin/false
install udf /bin/false

将各种稀有文件系统列入黑名单。

install cifs /bin/true
install nfs /bin/true
install nfsv3 /bin/true
install nfsv4 /bin/true
install gfs2 /bin/true

如果不使用网络文件系统，也可以将其列入黑名单。

install vivid /bin/false

vivid driver驱动程序仅用于测试目的，并且是特权提升漏洞的原因，因此应禁用它。

install bluetooth /bin/false
install btusb /bin/false

禁用具有安全问题历史记录的蓝牙。

install uvcvideo /bin/false

这会禁用网络摄像头，以防止其被用来监视您。

您也可以将麦克风模块列入黑名单，但这在系统之间可能会有所不同。要查找模块的名称，请在/proc/asound/modules中查找并将其列入黑名单。例如，一个这样的模块是snd_hda_intel。

请注意，尽管有时麦克风的内核模块与扬声器的模块相同。这意味着像这样禁用麦克风也可能会无意中禁用任何扬声器，虽然扬声器也有可能变成麦克风，所以这不一定是消极的结果。

最好从物理上删除这些设备，或者至少在BIOS/UEFI中禁用它们。禁用内核模块并不总是那么有效。

rfkill：

可以通过rfkill将无线设备列入黑名单，以进一步减少远程攻击面。要将所有无线设备列入黑名单，请执行：

rfkill block all

WiFi可以通过以下方式解锁：

rfkill unblock wifi

在使用systemd的系统上，rfkill在所有会话中均保持不变，但是，在使用其他init系统的系统上，您可能必须创建一个init脚本以在引导时执行这些命令。

其他内核指针泄漏

前面的部分已经防止了一些内核指针泄漏，但是还有更多泄漏。

在文件系统上，/boot中存在内核映像和System.map文件。/usr/src和/{,usr/} lib/modules目录中还有其他敏感的内核信息。您应该限制这些目录的文件权限，以使它们只能由root用户读取。您还应该删除System.map文件，因为除高级调试外，它们都不需要。

此外，某些日志记录守护程序（例如systemd的journalctl）包括内核日志，可用于绕过上述dmesg_restrict保护。从adm组中删除用户通常足以撤销对以下日志的访问：

gpasswd -d $user adm

限制对sysfs的访问

该脚本是可配置的，并允许基于组将特定的应用程序列入白名单。建议应用此方法，并使其在启动时使用init脚本执行。或者这样做成systemd服务[1]。

为了使基本功能在使用systemd的系统上运行，必须将一些系统服务列入白名单。这可以通过创建/etc/systemd/system/user@.service.d/sysfs.conf并添加以下内容来完成：

      [Service]        
SupplementaryGroups=sysfs

但是，这不能解决所有问题。许多应用程序可能仍会中断，您需要将它们正确列入白名单。

Linux强化

某些发行版（例如Arch Linux）包括强化的内核程序包。它包含许多强化补丁程序和更注重安全性的内核配置。如果可能的话，建议安装它。

Grsecurity

Grsecurity是一组内核修补程序，可以大大提高内核安全性。这些补丁曾经可以免费获得，但是现在需要购买了。如果可用，则强烈建议您获取它。Grsecurity提供了最新的内核和用户空间保护。

内核运行时防护

Linux Kernel Runtime Guard（LKRG）是一个内核模块，可确保运行时内核的完整性并检测漏洞。它可以杀死整个类别的内核漏洞。但这并不是一个完美的缓解方法，因为LKRG在设计上可以绕开。它仅适用于现成的恶意软件。但是，尽管可能性不大，但LKRG本身可能会像其他任何内核模块一样公开新的漏洞。

自编译内核

建议编译您自己的内核，同时启用尽可能少的内核模块和尽可能多的安全性功能，以将内核的受攻击面保持在绝对最低限度。

另外，应用内核强化补丁，例如如上所述的linux-hardened或grsecurity。

发行版编译的内核还具有公共内核指针/符号，这对于漏洞利用非常有用。编译自己的内核将为您提供独特的内核符号，连同kptr_restrict，dmesg_restrict和其他针对内核指针泄漏的强化措施，将使攻击者更加难以创建依赖于内核指针知识的漏洞利用程序。

您就可以从Whonix的强化内核[2]中汲取灵感或使用它。

— 3 —
强制访问措施

强制访问控制（MAC）系统对程序可以访问的内容进行细粒度的控制。这意味着您的浏览器将无权访问您的整个主目录或类似目录。

最常用的MAC措施是SELinux和AppArmor。SELinux比AppArmor更安全，因为它的粒度更细。例如，它是基于inode而不是基于路径的，允许强制执行明显更严格的限制，可以过滤内核ioctl等。不幸的是，这是以难以使用和难以学习为代价的，因此某些人可能会首选AppArmor。

要在内核中启用AppArmor，必须设置以下引导参数：

      apparmor=1 security=apparmor

要启用SELinux，请设置以下参数：

      selinux=1 security=selinux

请记住，仅启用MAC措施本身并不能神奇地提高安全性。您必须制定严格的政策才能充分利用它。例如，要创建AppArmor配置文件，请执行：

aa-genprof $path_to_program

打开程序，然后像往常一样开始使用它。AppArmor将检测需要访问哪些文件，并将它们添加到配置文件中（如果您选择的话）。但是，仅凭这一点不足以提供高质量的配置文件。请参阅AppArmor文档[3]以获取更多详细信息。

如果您想更进一步，则可以通过实施initramfs勾子来设置一个完整的系统MAC策略，该策略限制每个单个用户空间进程，该挂钩对init系统强制实施MAC策略。这就是Android使用SELinux的方式，以及Whonix未来将如何使用AppArmor的方式。对于加强实施最小特权原则的强大安全模型是必要的。

— 4 —
沙箱

应用沙箱

沙箱可让您在隔离的环境中运行程序，该环境对系统的其余部分具有有限的访问权限或完全没有访问权限。您可以使用它们来保护应用程序安全或运行不受信任的程序。

建议与AppArmor或SELinux一起在单独的用户帐户中使用Bubblewrap到沙箱程序。您也可以考虑改用gVisor，它的优点是为每个来宾提供了自己的内核。

这些方法中的任何一个都可以用来创建一个功能强大的沙箱，并且暴露的攻击面最小。如果您不想自己创建沙箱，请在完成后考虑使用Whonix的sandbox-app-launcher。您不应该使用Firejail[4]。

诸如Docker和LXC之类的容器解决方案经常被误导为沙盒形式。它们太宽松了，无法广泛支持各种应用程序，因此不能认为它们是强大的应用程序沙箱。

常见沙箱逃逸

PulseAudio：PulseAudio是一种常见的声音服务器，但在编写时并未考虑隔离或沙盒的问题，这使其成为重复出现的沙盒逃逸漏洞。为了防止这种情况，建议您从沙箱中阻止对PulseAudio的访问，或者从系统中完全卸载它。
D-Bus：D-Bus是台式机Linux上最流行的进程间通信形式，但它也是沙箱逃逸的另一种常见途径，因为它允许与服务自由交互。这些漏洞的一个例子就是Firejail。您应该从沙箱中阻止对D-Bus的访问，或者通过MAC以细粒度的规则进行调解。
GUI隔离：任何Xorg窗口都可以访问另一个窗口。这允许琐碎的键盘记录或屏幕截图程序，甚至可以记录诸如root密码之类的内容。您可以使用嵌套的X11服务器（例如Xpra或Xephyr和bubblewrap）将Xorg窗口沙箱化。默认情况下，Wayland将窗口彼此隔离，这将是一个比Xorg更好的选择，尽管Wayland可能不如Xorg普遍可用，因为它在开发中较早。
ptrace：如前所述，ptrace是一个系统调用，可能会被滥用破坏在沙箱外部运行的进程。为避免这种情况，您可以通过sysctl启用内核YAMA ptrace限制，也可以在seccomp过滤器中将ptrace syscall列入黑名单。
TIOCSTI：TIOCSTI是一个ioctl，它允许注入终端命令，并为攻击者提供了一种简单的机制，可以在同一用户会话内的其他进程之间横向移动。可以通过将seccomp过滤器中的ioctl列入黑名单或使用bubblewrap的--new-session参数来缓解这种攻击。
Systemd沙箱：虽然不建议使用systemd，但有些系统可能无法切换。这些人至少可以使用沙盒服务，因此他们只能访问所需的内容。

这是一个沙箱化systemd服务的示例：

      [Service]        
CapabilityBoundingSet=CAP_NET_BIND_SERVICE        
ProtectSystem=strict        
ProtectHome=true        
ProtectKernelTunables=true        
ProtectKernelModules=true        
ProtectControlGroups=true        
ProtectKernelLogs=true        
ProtectHostname=true        
ProtectClock=true        
ProtectProc=invisible        
ProcSubset=pid        
PrivateTmp=true        
PrivateUsers=yes        
PrivateDevices=true        
MemoryDenyWriteExecute=true        
NoNewPrivileges=true        
LockPersonality=true        
RestrictRealtime=true        
RestrictSUIDSGID=true        
RestrictAddressFamilies=AF_INET        
RestrictNamespaces=yes        
SystemCallFilter=write read openat close brk fstat lseek mmap mprotect munmap rt_sigaction rt_sigprocmask ioctl nanosleep select access execve getuid arch_prctl set_tid_address set_robust_list prlimit64 pread64 getrandom        
SystemCallArchitectures=native        
UMask=0077        
IPAddressDeny=any        
AppArmorProfile=/etc/apparmor.d/usr.bin.example

所有选项的说明：

CapabilityBoundingSet=— Specifies the capabilitiesthe process is given.

ProtectHome=true— Makes all home directories inaccessible.

ProtectKernelTunables=true— Mounts kernel tunables such as those modified throughsysctlas read-only.

ProtectKernelModules=true— Denies module loading and unloading.

ProtectControlGroups=true— Mounts all control group hierarchies as read-only.

ProtectKernelLogs=true— Prevents accessing the kernel logs.

ProtectHostname=true— Prevents changes to the system hostname.

ProtectClock— Prevents changes to the system clock.

ProtectProc=invisible— Hides all outside processes.

ProcSubset=pid— Permits access to only the pid subset of/proc.

PrivateTmp=true— Mounts an empty tmpfs over/tmpand/var/tmp, therefore hiding their previous contents.

PrivateUsers=true— Sets up an empty user namespace to hide other user accounts on the system.

PrivateDevices=true— Creates a new/devmount with minimal devices present.

MemoryDenyWriteExecute=true— Enforces a memory W^X policy.

NoNewPrivileges=true— Prevents escalating privileges.

LockPersonality=true— Locks down thepersonality()syscall to prevent switching execution domains.

RestrictRealtime=true— Prevents attempts to enable realtime scheduling.

RestrictSUIDSGID=true— Prevents executing setuid or setgid binaries.

RestrictAddressFamilies=AF_INET— Restricts the usable socket address families to IPv4 only (AF_INET).

RestrictNamespaces=true— Prevents creating any new namespaces.

SystemCallFilter=...— Restricts the allowed syscalls to the absolute minimum. If you aren't willing to maintain your own custom seccomp filter, then systemd provides many [predefined system call sets](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#System Call Filtering) that you can use.@system-servicewill be suitable for many use cases.

SystemCallArchitectures=native— Prevents executing syscalls from other CPU architectures.

UMask=0077— Sets the umaskto a more restrictive value.

IPAddressDeny=any— Blocks all incoming and outgoing traffic to/from any IP address. SetIPAddressAllow=to configure a whitelist. Alternatively, setup a network namespace withPrivateNetwork=true.

AppArmorProfile=...— Runs the process under the specified AppArmor profile.

您不能仅将此示例配置复制到您的配置中，每种服务的要求各不相同，并且必须针对每种服务微调沙箱。要了解有关您可以设置的所有选项的更多信息，请阅读systemd.exec手册页[5]。

如果您使用的系统不是systemd而是init，那么可以使用bubblewrap轻松复制所有这些选项。

gVisor

普通沙箱固有地与主机共享同一内核。您信任我们已经评估为不安全的内核，可以正确限制这些程序。由于主机内核的整个攻击面已完全暴露，因此沙盒中的内核利用程序可以绕过任何限制。已经进行了一些努力来限制使用seccomp的攻击面，但不足以完全解决此问题。

GVisor是解决此问题的方法。它为每个应用程序提供了自己的内核，该内核以内存安全的语言重新实现了Linux内核的大部分系统调用，从而提供了明显更强的隔离性。

虚拟机

虽然不是传统的“沙盒”，但虚拟机通过虚拟化全新系统来分离进程，从而提供了非常强大的隔离性。KVM是内核模块，它允许内核充当管理程序，而QEMU是利用KVM的仿真器。Virt-manager和GNOME Boxs都是良好且易于使用的GUI，用于管理KVM / QEMU虚拟机。不建议使用Virtualbox的原因[6]有很多。

— 5 —
强化内存分配器

hardened_malloc是一种硬化的内存分配器，可为堆内存损坏漏洞提供实质性的保护。它很大程度上基于OpenBSD的malloc设计，但具有许多改进。

可以通过LD_PRELOAD环境变量针对每个应用程序使用hardened_malloc。例如，假设您编译的库位于/usr/lib/libhardened_malloc.so，则可以执行：

LD_PRELOAD="/usr/lib/libhardened_malloc.so" $program

通过全局预加载该库，也可以在系统范围内使用它，这是使用它的推荐方法。为此，请编辑/etc/ld.so.preload并插入：

/usr/lib/libhardened_malloc.so

尽管大多数应用程序都可以正常工作，但hardened_malloc可能会破坏某些应用程序。建议使用以下选项编译hardened_malloc以最大程度地减少损坏：

      CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 CONFIG_GUARD_SLABS_INTERVAL=8

您还应该使用sysctl设置以下内容，以适应hardened_malloc创建的大量保护页：

      vm.max_map_count=524240

Whonix项目[7]为基于Debian的发行版提供了hardened_malloc软件包。

— 6 —
强化编译标志

编译自己的程序可以带来很多好处，因为它使您能够优化程序的安全性。但是，执行完全相反的操作并降低安全性很容易，如果您不确定自己在做什么，请跳过本节。在基于源的发行版（例如Gentoo）上，这将是最简单的，但也可以在其他发行版上这样做。

某些编译选项可用于添加其他漏洞利用缓解措施，从而消除整个类别的常见漏洞。您可能听说过常规保护，例如位置独立可执行文件，堆栈粉碎保护程序，立即绑定，只读重定位和FORTIFY_SOURCE，但是本节将不做介绍，因为它们已被广泛采用。相反，它将讨论诸如控制流完整性和影子堆栈之类的现代漏洞利用缓解措施。

本节涉及主要用C或C ++编写的本机程序。您必须使用Clang编译器，因为这些功能在GCC上不可用。请记住，由于未广泛采用这些缓解措施，因此某些应用程序在启用它们后可能无法运行。

控制流完整性（CFI）是一种缓解漏洞利用的方法，旨在防止诸如ROP或JOP之类的代码重用攻击。由于更广泛采用的缓解措施（例如NX）使过时的利用技术过时了，因此使用这些技术利用了很大一部分漏洞。Clang支持细粒度的前沿CFI，这意味着它可以有效缓解JOP攻击。Clang的CFI本身并不能减轻ROP；您还必须使用下面记录的单独机制。要启用此功能，必须应用以下编译标志：-flto -fvisibility=hidden -fsanitize=cfi

影子堆栈通过将程序复制到其他隐藏堆栈中来保护程序的返回地址。然后比较主堆栈和影子堆栈中的返回地址，看两者是否不同。如果是这样，则表明存在攻击，程序将中止，从而减轻了ROP攻击。Clang具有称为ShadowCallStack的功能，可以完成此操作，但是，仅在ARM64上可用。要启用此功能，必须应用以下编译标志：-fsanitize=shadow-call-stack

如果上述ShadowCallStack不是一个选项，则可以选择使用具有相似目标的SafeStack。但是，不幸的是，此功能有许多漏洞，因此效果不甚理想。如果仍然希望启用此功能，则必须应用以下编译标志：-fsanitize=safe-stack

最常见的内存损坏漏洞之一是未初始化的内存。Clang有一个选项可以使用零或特定模式自动初始化变量。建议将变量初始化为零，因为使用其他模式比利用漏洞缓解功能更适合发现错误。要启用此功能，必须应用以下编译标志：-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang 但该选项的存在目前正在辩论[8]中。

— 7 —
内存安全语言

用内存安全语言编写的程序会自动受到保护，免受各种安全漏洞的影响，这些安全漏洞包括缓冲区溢出，未初始化的变量，售后使用等。Microsoft和Google的安全研究人员进行的研究证明，已发现的大多数漏洞都是内存安全问题。这样的内存安全语言的示例包括Rust，Swift和Java，而内存不安全语言的示例包括C和C ++。如果可行，应使用内存安全替代品替换尽可能多的程序。

— 8 —
Root账户

root可以执行任何操作，并且可以访问您的整个系统。因此，应尽可能将其锁定，以使攻击者无法轻松获得root用户访问权限。

/etc/securetty

/etc/securetty文件指定允许您以root用户身份登录的位置。该文件应保留为空，以便任何人都不能从终端上这样做。

限制su

su可让您从终端切换用户。默认情况下，它尝试以root用户身份登录。要将su的使用限制在wheel组中，请编辑/etc/pam.d/su和/etc/pam.d/su-l并添加：

auth required pam_wheel.so use_uid

您应该在wheel组中拥有尽可能少的用户。

锁定root账户

要锁定root帐户以防止任何人以root身份登录，请执行：

passwd -l root

在执行此操作之前，请确保您具有获取根的替代方法（例如，从活动USB引导并更改为文件系统的chroot），以免您无意中将自己锁定在系统之外。

拒绝通过SSH的远程root登陆

为了防止某人通过SSH以root身份登录，请编辑/etc/ssh/sshd_config并添加：

PermitRootLogin no

增加散列回合数

您可以增加shadow使用的哈希回合数，从而通过迫使攻击者计算更多的哈希值来破解您的密码，从而提高哈希密码的安全性。默认情况下，shadow使用5000次回合，但是您可以将其增加到任意数量。尽管配置的回合越多，登录速度就越慢。编辑/etc/pam.d/passwd并添加回合选项。

password required pam_unix.so sha512 shadow nullok rounds=65536

这使shadow执行65536次散列回合。

应用此设置后，密码不会自动重新加密，因此您需要使用以下方法重置密码：

passwd $username

限制Xorg root访问

默认情况下，某些发行版以root用户身份运行Xorg，这是一个问题，因为Xorg包含大量古老而又复杂的代码，这增加了巨大的攻击面，并使其更有可能拥有可以获取root特权的漏洞利用程序。要阻止它作为root用户执行，请编辑/etc/X11/Xwrapper.config并添加：

      needs_root_rights = no

安全访问root

恶意软件可以使用多种方法来嗅探root帐户的密码。因此，访问根帐户的传统方式是不安全的，最好根本不访问根，但这实际上是不可行的。本节详细介绍了访问根帐户的最安全方法。在安装操作系统后，应立即应用这些说明，以确保该软件不含恶意软件。

您绝对不能使用普通用户帐户访问root，因为root可能已被盗用。您也不能直接登录到根帐户。通过执行以下操作，创建一个单独的“管理员”用户帐户，该帐户仅用于访问root用户，而不能用于访问其他用户：

useradd admin

执行并来设置一个非常强的密码：

passwd admin

仅允许该帐户使用您首选的权限提升机制。例如，如果使用sudo，则通过执行以下命令来添加sudoers异常：

visudo -f /etc/sudoers.d/admin-account

然后输入：

      admin ALL=(ALL) ALL

确保没有其他帐户可以访问sudo（或您的首选机制）

现在，要实际登录到该帐户，请先重新启动-例如，这可以防止受损的窗口管理器执行登录欺骗。当提供登录提示时，请通过按键盘上的以下组合键来激活安全注意键：

Alt + SysRq + k

这将杀死当前虚拟控制台上的所有应用程序，从而克服登录欺骗攻击。现在，您可以安全地登录到您的管理员帐户，并使用root用户执行任务。完成后，注销管理员帐户，然后重新登录到非特权用户帐户。

— 9 —
防火墙

防火墙可以控制传入和传出的网络流量，并且可以用来阻止或允许某些类型的流量。除非有特殊原因，否则应始终阻止所有传入流量。建议设置严格的iptables或nftables防火墙。火墙必须针对您的系统进行微调，并且没有一个适合所有防火墙的规则集。建议您熟悉创建防火墙规则。Arch Wiki[9]和手册页[10]都是很好的资源。

这是基本iptables配置的示例，该配置禁止所有传入的网络流量：

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT

但是，您不应尝试在实际系统上使用此示例。它仅适用于某些台式机系统。

— 10 —
身份标识

为了保护隐私，最好最大程度地减少可追溯到您的信息量。

主机名和用户名

请勿在主机名或用户名中添加唯一标识的内容。将它们保留为通用名称，例如“host”和“user”，以便它们无法识别您。

Timezones / Locales / Keymaps

如果可能，应将您的时区设置为“ UTC”，将区域设置和键盘映射设置为“ US”。

机器ID

一个独一无二的机器ID被存储在/var/lib/dbus/machine-id （systemd系统是保存在/etc/machine-id）这些应编辑为通用名称，例如Whonix ID。

b08dfa6083e7567a1921a715000001fb

MAC地址欺骗

MAC地址是分配给网络接口控制器（NIC）的唯一标识符。每次您连接到网络时（WIFI或以太网）则您的MAC地址已暴露。这使人们可以使用它来跟踪您并在本地网络上唯一地标识您。

但您不应该完全随机化MAC地址。拥有完全随机的MAC地址是显而易见的，并且会对您脱颖而出的行为产生不利影响。

MAC地址的OUI（组织唯一标识符）部分标识芯片组的制造商。对MAC地址的这一部分进行随机化处理可能会为您提供以前从未使用过的OUI，数十年来从未使用过的OUI或在您所在的地区极为罕见的OUI，因此使您脱颖而出，很明显地表明您在欺骗MAC地址。

MAC地址的末尾标识您的特定设备，并且可以用来跟踪您的设备。仅对MAC地址的这一部分进行随机化可防止您被跟踪，同时仍使MAC地址看起来可信。

要欺骗这些地址，请首先执行以下命令找出您的网络接口名称：

ip a

接下来，安装macchanger并执行：

macchanger -e $network_interface

要在每次引导时随机分配MAC地址，您应该为您的特定初始化系统创建一个初始化脚本。这是systemd的一个示例：

      [Unit]        
Description=macchanger on eth0        
Wants=network-pre.target        
Before=network-pre.target        
BindsTo=sys-subsystem-net-devices-eth0.device        
After=sys-subsystem-net-devices-eth0.device        
        
[Service]        
ExecStart=/usr/bin/macchanger -e eth0        
Type=oneshot        
        
[Install]        
WantedBy=multi-user.target

上面的示例在启动时欺骗了eth0接口的MAC地址。将eth0替换为您的网络接口。

时间攻击

几乎每个系统都有不同的时间。这可用于时钟偏斜指纹攻击，几毫秒的差异足以使用户被暴露识别。

ICMP时间戳：

ICMP时间戳会在查询答复中泄漏系统时间。阻止这些攻击的最简单方法是利用防火墙阻止传入连接，或者使内核忽略ICMP请求。

TCP时间戳：

TCP时间戳也会泄漏系统时间。内核尝试通过对每个连接使用随机偏移量来解决此问题，但这不足以解决问题。因此应该禁用TCP时间戳，可以通过使用sysctl设置以下内容来完成：

      net.ipv4.tcp_timestamps=0

TCP初始化序号：

TCP初始序列号（ISN）是泄漏系统时间的另一种方法。为了减轻这种情况，您必须安装tirdad内核模块，该模块会生成用于连接的随机ISN。

时间同步：

时间同步对于匿名性和安全性至关重要。错误的系统时钟可能使您遭受时钟偏斜指纹攻击，或者可以用来为您提供过时的HTTPS证书，从而绕过证书到期或吊销。

最流行的时间同步方法NTP是不安全的，因为它未经加密和未经身份验证，因此攻击者可以轻易地拦截和修改请求。NTP还会以NTP时间戳格式泄漏本地系统时间，该格式可用于时钟偏斜指纹识别，如前所述。

因此，您应该卸载所有NTP客户端并禁用systemd-timesyncd（如果正在使用）。您可以通过安全连接（HTTPS或最好是Torion服务）连接到受信任的网站，而不是NTP，并从HTTP标头中提取当前时间。达到此目的的工具是sdwdate或我自己的安全时间同步工具。

按键指纹

可以通过他们在键盘上输入键的方式来对人进行指纹识别。您可以通过键入速度，在两次按键之间的暂停，每次按键被按下和释放的确切时间等方式来唯一地进行指纹识别。可以使用KeyTrac在线进行测试。

Kloak是一种工具，旨在通过混淆按键和释放事件之间的时间间隔来克服这种跟踪方法。当按键被按下时，它会引入随机延迟，然后由应用程序选择。

— 11 —
文件权限

默认情况下，文件的权限是非常宽松的。您应该在整个系统中搜索权限不当的文件和目录，并对其进行限制。例如，在诸如Debian之类的某些发行版中，用户的Home目录是全局可读的。

这可以通过执行以下操作来限制：

chmod 700 /home/$user

另外一些示例是/boot，/usr /src和/ {,usr /} lib/modules 它们包含内核映像，System.map和其他各种文件，所有这些文件都可能泄漏有关内核的敏感信息。

chmod 700 /boot /usr/src /lib/modules /usr/lib/modules

在基于Debian的发行版中，必须使用dpkg-statoverride保留文件许可权。否则，它们将在更新期间被覆盖。

Whonix的SUID Disabler和Permission Hardener会自动应用本节中详细介绍的步骤。

setuid / setgid

Setuid / SUID允许用户使用二进制文件所有者的特权执行二进制文件。这通常用于允许非特权用户使用通常仅为root用户保留的某些功能。因此，许多SUID二进制文件都有特权升级安全漏洞的历史记录。Setgid / SGID类似，但适用于组而不是用户。要使用setuid或setgid位查找系统上的所有二进制文件，请执行：

      find / -type f \( -perm -4000 -o -perm -2000 \)

然后，您应该删除不使用的程序上的所有不必要的setuid / setgid位，或将其替换为功能。要删除setuid位，请执行：

chmod u-s $path_to_program

要删除setgid位，执行：

chmod g-s $path_to_program

要向文件添加功能，请执行：

setcap $capability+ep $path_to_program

或者，要删除不必要的功能，请执行：

setcap -r $path_to_program

umask

umask设置新创建文件的默认文件权限。默认的umask是0022，它不是很安全，因为它为系统上的每个用户提供了对新创建文件的读取访问权限。要使所有者以外的任何人都不可读新文件，请编辑/etc/profile并添加：

umask 0077

— 12 —
核心转储

核心转储包含特定时间（通常是该程序崩溃时）该程序的已记录内存。它们可能包含敏感信息，例如密码和加密密钥，因此必须将其禁用。

禁用它们的方法主要有三种：sysctl，systemd和ulimit。

sysctl

通过sysctl设置以下设置：

      kernel.core_pattern=|/bin/false

systemd

创建/etc/systemd/coredump.conf.d/disable.conf并添加如下内容：

      [Coredump]        
Storage=none

ulimit

编辑/etc/security/limits.conf并添加如下内容：

* hard core 0

setuid进程

即使在进行了这些设置之后，以提升的特权运行的进程仍可能会转储其内存。

为了防止他们这样做，请通过sysctl设置以下内容：

      fs.suid_dumpable=0

— 13 —
Swap

与核心转储类似，交换或分页将部分内存复制到磁盘，其中可能包含敏感信息。应该将内核配置为仅在绝对必要时进行交换，相应的sysctl设置：

      vm.swappiness=1

— 14 —
PAM

PAM是用于用户身份验证的框架。这就是您登录时使用的机制。您可以通过要求使用强密码或在失败的登录尝试后强制执行延迟验证来使其更加安全。

要强制使用强密码，可以使用pam_pwquality。它强制执行密码的可配置策略。例如，如果您希望密码至少包含16个字符（最小），与旧密码（difok）至少6个不同的字符，至少3个数字（dcredit），至少2个大写字母（ucredit），至少2个字符小写字母（lcredit）和至少3个其他字符（ocredit），然后编辑/etc/pam.d/passwd并添加：

      password required pam_pwquality.so retry=2 minlen=16 difok=6 dcredit=-3 ucredit=-2 lcredit=-2 ocredit=-3 enforce_for_root        
password required pam_unix.so use_authtok sha512 shadow

要强制执行延迟验证，可以使用pam_faildelay。要在两次失败的登录尝试之间添加至少4秒的延迟以阻止暴力破解尝试，请编辑/etc/pam.d/system-login并添加：

auth optional pam_faildelay.so delay=4000000

4000000 是4秒（以微秒为单位）。

— 15 —
Microcode更新

Microcode更新对于修复关键的CPU漏洞（如Meltdown和Spectre等）至关重要。大多数发行版都将这些发行版包含在其软件仓库中，例如Arch Linux和Debian。

— 16 —
IPv6隐私扩展

IPv6地址是从计算机的MAC地址生成的，从而使您的IPv6地址是唯一的，并直接绑定到计算机。隐私扩展会生成一个随机的IPv6地址，以减轻这种形式的跟踪。请注意，如果您开启了MAC地址欺骗机制或禁用了IPv6，则无需执行这些步骤。

要启用这些功能，请通过sysctl设置以下设置：

net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2

NetworkManager

要为NetworkManager启用隐私扩展，请编辑/etc/NetworkManager/NetworkManager.conf并添加：

      [connection]        
ipv6.ip6-privacy=2

systemd-networkd

要为systemd-networkd启用隐私扩展，请创建/etc/systemd/network/ipv6-privacy.conf并添加：

      [Network]        
IPv6PrivacyExtensions=kernel

— 17 —
分区和挂载选项

文件系统应分为多个分区，以对其权限进行细粒度控制。可以添加不同的安装选项以限制可以执行的操作：

nodev - 禁止使用设备

nosuid - 禁止setuid或setgid位

noexec - 禁止执行任何二进制文件

这些安装选项应在/etc/fstab中尽可能设置。如果您不能使用单独的分区，请创建绑定挂载。一个更安全的/etc/fstab的示例：

/        /          ext4    defaults                              1 1
/home    /home      ext4    defaults,nosuid,noexec,nodev          1 2
/tmp     /tmp       ext4    defaults,bind,nosuid,noexec,nodev     1 2
/var     /var       ext4    defaults,bind,nosuid                  1 2
/boot    /boot      ext4    defaults,nosuid,noexec,nodev          1 2

请注意，可以通过shell脚本绕过noexec[11]。

— 18 —
熵

熵基本上反应操作系统信息收集的随机程度，对于诸如加密之类的事情至关重要。因此，最好通过安装其他随机数生成器（如haveged和jitterentropy）从各种来源收集尽可能多的熵。

为了使jitterentropy正确运行，必须通过创建/usr/lib/modules-load.d/jitterentropy.conf并添加以下内容尽早加载内核模块：

jitterentropy_rng

RDRAND

RDRAN是提供随机数的CPU指令。如果可用，内核会自动将其用作熵源。但是由于它是专有的并且是CPU本身的一部分，因此无法审核和验证其安全性。您甚至无法对代码进行反向工程。该RNG以前曾遭受过漏洞的攻击，其中有些可能是后门攻击。通过设置以下引导参数可以不信任此功能：

      random.trust_cpu=off

— 19 —
以root身份编辑文件

建议不要以root用户身份运行普通的文本编辑器。大多数文本编辑器可以做的不仅仅是简单地编辑文本文件，而且还可以被利用。例如，以root身份打开vi并输入：sh。现在，您具有一个可以访问整个系统的root shell，攻击者可以轻松利用该shell。

解决方案是使用sudoedit。这会将文件复制到一个临时位置，以普通用户身份打开文本编辑器，编辑该临时文件并以root用户身份覆盖原始文件。这样，实际的编辑器就不会以root身份运行。要使用sudoedit，执行：

sudoedit $path_to_file

默认情况下，它使用vi，但是可以通过EDITOR或SUDO_EDITOR环境变量来切换默认编辑器。例如，要使用nano，请执行：

EDITOR=nano sudoedit $path_to_file

可以在/etc/environment中全局设置此环境变量。

— 20 —
特定发行版的安全强化

HTTP包管理器镜像

默认情况下，Linux发行版通常使用HTTP或HTTP和HTTPS镜像的混合来从其软件存储库下载软件包。人们认为这很好，因为程序包管理器会在安装前验证程序包的签名。但是，从历史上看，已经有很多绕过此方法的地方。您应将软件包管理器配置为从HTTPS镜像专门下载以进行深度防御。

APT seccomp-bpf

自软件包管理器Debian Buster以来，APT已支持可选的seccomp-bpf过滤。这限制了允许执行APT的系统调用，这可能严重限制攻击者尝试利用APT中的漏洞时对系统造成危害的能力。要启用此功能，请创建/etc/apt/apt.conf.d/40sandbox并添加：

      APT::Sandbox::Seccomp "true";

— 21 —
物理安全

全盘加密可确保对驱动器上的所有数据进行加密，并且不会被物理攻击者读取。大多数发行版都支持在安装过程中启用加密，请确保设置了强密码。您也可以使用dm-crypt手动加密驱动器。

请注意，全盘加密不包括/boot，这样仍然可以修改内核、引导加载程序和其他关键文件。为了完全防止篡改，您还必须实施经过验证的引导。

BIOS / UEFI强化

您还应该禁用所有未使用的设备和引导选项，例如USB引导，以减少攻击面。

别忽略BIOS或UEFI的更新，确保将其更新。将其与常规操作系统更新一样重要。

此外，请参阅《NSA的硬件和固件安全指南[12]》

Bootloader密码

引导加载程序会在引导过程的早期执行，并负责加载操作系统。保护它非常重要，否则，它可能会被篡改。例如，本地攻击者可以通过在启动时使用init=/bin/bash作为内核参数来轻松获得root shell，该命令告诉内核执行/bin/bash而不是常规的init系统。您可以通过为引导加载程序设置密码来防止这种情况。仅设置引导程序密码不足以完全保护它。还必须按照以下说明设置经过验证的启动。

Grub：

要为GRUB设置密码，请执行：

grub-mkpasswd-pbkdf2

输入您的密码，该密码将生成一个字符串。它将类似于“ grub.pbkdf2.sha512.10000.C4009... “ 。创建/etc/grub.d/40_password并添加：

set superusers="$username"
password_pbkdf2 $username $password

用grub-mkpasswd-pbkdf2生成的字符串替换“ $ password”。“ $ username”将用于被允许使用GRUB命令行，编辑菜单项和执行任何菜单项的超级用户。对于大多数人来说，这只是“root”。

重新生成您的配置文件，GRUB现在将受到密码保护。

要仅限制编辑引导参数并访问GRUB控制台，同时仍然允许您引导，请编辑 /boot/grub/grub.cfg并在 “menuentry '$OSName' ”旁边添加“ --unrestricted”参数。

menuentry 'Arch Linux' --unrestricted

您将需要再次重新生成配置文件以应用此更改。

Syslinux：

Syslinux可以设置主密码或菜单密码。引导任何条目都需要主密码，而引导特定条目仅需要菜单密码。

要为Syslinux设置主密码，请编辑/boot/syslinux/syslinux.cfg并添加：

MENU MASTER PASSWD $password

要设置菜单密码，请编辑/boot/syslinux/syslinux.cfg，并在带有您要密码保护的项目的标签内，添加：

MENU PASSWD $password

将“$password”替换为您要设置的密码。

这些密码可以是纯文本，也可以使用MD5，SHA-1，SHA-256或SHA-512进行散列。建议先使用强哈希算法（例如SHA-256或SHA-512）对密码进行哈希处理，以避免将其存储为明文形式。

systemd-boot：

systemd-boot具有防止在引导时编辑内核参数的选项。在loader.conf文件中，添加：

editor no

systemd-boot并不正式支持保护内核参数编辑器的密码，但是您可以使用systemd-boot-password来实现。

验证引导

经过验证的引导通过密码验证来确保引导链和基本系统的完整性。这可用于确保物理攻击者无法修改设备上的软件。

如果没有经过验证的引导，则一旦获得物理访问权限，就可以轻松绕过上述所有预防措施。经过验证的引导不仅像许多人认为的那样是为了物理安全。它还可以用于防止远程恶意软件持久化——如果攻击者设法破坏了整个系统并获得了很高的特权，则经过验证的引导将在重新引导后还原其更改，并确保它们无法持久化。

经过验证的最常见的引导实现是UEFI安全引导，但是它本身并不是一个完整的实现，因为它仅会验证引导加载程序和内核，这意味着可以通过以下方法：

仅UEFI安全启动就没有一成不变的信任根，因此物理攻击者仍然可以刷新设备的固件。为了减轻这种情况，请结合使用UEFI安全启动和Intel Boot Guard或AMD Secure Boot。

远程攻击者（或不使用加密的物理攻击者）可以简单地修改操作系统的任何其他特权部分。例如，如果他们有修改内核的特权，那么他们也可以修改/sbin/init来有效地获得相同的结果。因此，仅验证内核和引导加载程序不会对远程攻击者产生任何影响。为了减轻这种情况，您必须使用dm-verity验证基本操作系统，尽管由于传统Linux发行版的布局，这非常困难且笨拙。

通常，很难在传统Linux上实现可靠的经过验证的引导实现。

USBs

USB设备为物理攻击提供了重要的攻击面。例如BadUSB和Stuxnet是此类攻击的范例。最佳实践是禁止所有新连接的USB且仅将受信任设备列入白名单，USBGuard对此非常有用。

您也可以将nousb用作内核引导参数，以禁用内核中的所有USB支持。可以sysctl设置kernel.deny_new_usb=1

DMA攻击

直接内存访问（DMA）攻击涉及通过插入某些物理设备来完全访问所有系统内存。这可以通过控制设备可访问的内存区域的IOMMU或将特别易受攻击的内核模块列入黑名单来缓解。

要启用IOMMU，请设置以下内核引导参数：

      intel_iommu=on amd_iommu=on

您只需要为特定的CPU制造商启用该选项，但同时启用这两个选项就没有问题。

      efi=disable_early_pci_dma

通过在非常早的启动过程中禁用所有PCI桥接器上的busmaster位，此选项可修复上述IOMMU中的漏洞[13]。

此外，Thunderbolt和FireWire通常容易受到DMA攻击。要禁用它们，请将这些内核模块列入黑名单：

install firewire-core /bin/false
install thunderbolt /bin/false

冷启动攻击

当攻击者在擦除RAM中的数据之前对其进行分析时，就会发生冷启动攻击。使用现代RAM时，冷启动攻击不太实用，因为RAM通常会在几秒钟或几分钟内清除，除非将其放入冷却液（如液氮或冷冻机）中。攻击者必须在几秒钟内将设备中的RAM棒拔出并将其暴露于液氮中，而且确保用户不会注意到。

如果冷启动攻击是威胁模型的一部分，请在关机后保护计算机几分钟，以确保没有人可以访问您的RAM记忆棒。您也可以将RAM棒焊接到主板上，以使其更难以卡住。如果使用笔记本电脑，请取出电池，然后直接用充电电缆供电。关机后请拔出电缆，以确保RAM彻底断电无法访问。

在内核自我保护启动参数部分中，空闲时内存清零选项将用零覆盖内存中的敏感数据。此外，强化的内存分配器可以通过CONFIG_ZERO_ON_FREE配置选项清除用户空间堆内存中的敏感数据。尽管如此，某些数据仍可能保留在内存中。

此外，现代内核还包括复位攻击缓解措施，该命令可命令固件在关机时擦除数据，尽管这需要固件支持。

确保正常关闭计算机，以使上述缓解措施可以开始。

如果以上都不适用您的威胁模型，则可以实施Tails的内存擦除过程，该过程将擦除大部分内存（视频内存除外），并且已被证明是有效的。

— 22 —
最佳实践

一旦对系统进行了尽可能多的加固，就应该遵循良好的隐私和安全性惯例：

禁用或删除不需要的东西以最小化攻击面。

保持更新。配置cron任务或init脚本以每天更新系统。

不要泄漏有关您或您的系统的任何信息，无论它看起来多么渺小。

遵循常规的安全和隐私建议[14]

尽管已经进行了强化，但您必须记住Linux仍然是一个有缺陷的操作系统，没有任何强化可以完全修复它。

— 23 —
其他指南

您应该进行尽可能多的研究，而不要依赖单一的信息来源。最大的安全问题之一就是用户。这些是我认为有价值的其他指南的链接：

https://wiki.archlinux.org/index.php/Security
https://www.whonix.org/wiki/Documentation
https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
https://github.com/a13xp0p0v/kconfig-hardened-check/

— 24 —
术语

您可能需要重新生成GRUB配置，以应用对引导加载程序所做的某些更改。在不同的发行版之间，执行此操作的步骤有时可能会有所不同。例如，在诸如Arch Linux之类的发行版上，应通过执行以下命令来重新生成配置文件：

grub-mkconfig -o $path_to_grub_config

“$path_to_grub_config”取决于您如何设置系统。它通常是/boot/grub/grub.cfg或/boot/EFI/grub/grub.cfg，但是在执行此命令之前，请务必确保正确。

另外，在Debian或Ubuntu等发行版上，您应该执行以下命令：

update-grub

— 25 —
能力

在Linux内核中，“ root特权”分为各种不同的能力（capabilities）。这在应用最小特权原则时很有帮助——可以给它们仅授予特定的子集，而不是授予进程总的root特权。例如，如果程序只需要设置系统时间，则只需要CAP_SYS_TIME而不是root所有能力。这会限制可能造成的损害，但是，您仍必须谨慎授予能力，因为无论如何，其中许多能力可能会被滥用以获取完整的root特权。

Linux 打算合併 /dev/random 與 /dev/urandom 遇到的問題

Sun, 03 Apr 2022 12:33:00 CST

在 Hacker News 上看到「 Problems emerge for a unified /dev/*random (lwn.net)」的，原文是「 Problems emerge for a unified /dev/*random」(付費內容，但是可以透過 Hacker News 上的連結直接看)。

標題提到的兩個 device 的性質會需要一些背景知識，可以參考維基百科上面「 /dev/random」這篇的說明，兩個都是 CSPRNG，主要的分別在於 /dev/urandom 通常不會 block：

The /dev/urandom device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.

而 /dev/random 不保證不會 block，有可能會因為 entropy 不夠而卡住：

/dev/random typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently.

然後順便講一下，因為這是 crypto 相關的設計修改，加上是 kernel level 的界面，安全性以及相容性都會是很在意的點，而 Hacker News 上的討論裡面很多是不太在意這些的，你會看到很多「很有趣」的想法在上面討論 XDDD

回到原來的文章，Jason A. Donenfeld (Linux kernel 裡 RNG maintainer 之一，不過近期比較知名的事情還是 WireGuard 的發明人) 最近不斷的在改善 Linux kernel 裡面這塊架構，這次打算直接拿 /dev/random 換掉 /dev/urandom：「 Uniting the Linux random-number devices」。

不過換完後 Google 的 Guenter Roeck 就在抱怨在 QEMU 環境裡面炸掉了：

This patch (or a later version of it) made it into mainline and causes a large number of qemu boot test failures for various architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I observed). Common denominator is that boot hangs at "Saving random seed:". A sample bisect log is attached. Reverting this patch fixes the problem.

他透過 git bisect 找到發生問題的 commit，另外從卡住的訊息也可以大概猜到在虛擬機下 entropy 不太夠。

另外從他們三個 (加上 Linus) 在 mailing list 上面討論的訊息可以看到不少交流：「 Re: [PATCH v1] random: block in /dev/urandom」，包括嘗試「餵」entropy 進 /dev/urandom 的 code...

後續看起來還會有一些嘗試，但短期內看起來應該還是會先分開...

Metasploit Framework 6.1.32+20220303 (macOS, Linux, Windows) -- 渗透测试框架

Fri, 04 Mar 2022 15:03:00 CST

请访问原文链接： Metasploit Framework 6.1.32+20220303 (macOS, Linux, Windows) -- 渗透测试框架，查看最新版。原创作品，转载请保留出处。

作者主页： www.sysin.org

世界上最广泛使用的渗透测试框架

知识就是力量，尤其是当它被分享时。作为开源社区和 Rapid7 之间的合作，Metasploit 帮助安全团队做的不仅仅是验证漏洞、管理安全评估和提高安全意识；它使防守队员能够始终领先比赛一步（或两步）。

版本比较

Open Source: Metasploit Framework

Download

Commercial Support: Metasploit Pro

下载地址

macOS：metasploit-framework-VERSION.x86_64.pkg
Windows：metasploit-framework-VERSION-x64.msi
Linux deb x64：metasploit-framework_VERSION_amd64.deb
Linux deb x86：metasploit-framework_VERSION_i386.deb
Linux deb arm64：metasploit-framework_VERSION_arm64.deb
Linux rpm x64：metasploit-framework-VERSION.el6.x86_64.rpm

百度网盘链接： https://pan.baidu.com/s/14jnv2S4EhzdHr3cWnwfNJA 提取码：17p9

Linux性能：为什么你应该添加交换空间swap

Tue, 09 Nov 2021 14:08:02 CST

我们知道使用Linux交换空间而不是 RAM（内存）会严重降低性能。那么，有人可能会问，既然我有足够多的可用内存，删除交换空间不是更好吗？简短的回答是不会。启用交换空间会带来性能优势，即使您有足够多的内存。

即使安装了足够多的服务器内存，您也会经常发现在长时间正常运行后会使用交换空间。请参阅以下来自具有大约一个月正常运行时间的实时聊天服务器的示例：

                total        used        free      shared  buff/cache   available
Mem:           3.7G        1.0G        445M         84M        2.2G        2.2G
Swap:          1.8G        308M        1.5G

free -h这里的输出显示使用了 308M 的交换空间。当我运行swapping检查时，没有迹象表明正在进行或不合时宜的swap I/O活动。此外，kswap服务并没有消耗太多 CPU 时间。实际上，在top（按 CPU 时间排序的顶级进程）中找不到kswap进程。为了确认，我使用了 ps命令：

  ps -A | grep kswap
40 ? 00:00: 29 kswapd0

...所以在这种情况下，与许多情况一样，swap使用不会降低Linux服务器的性能。现在，让我们看看交换空间实际上如何改善Linux服务器性能。

在具有足够RAM的系统上交换空间的优点

即使仍有可用的 RAM，Linux系统使用一些swap也是正常的并且是一件好事。Linux 内核会将 几乎从未使用过的内存页面移动到交换空间中，以确保在内存中为更频繁使用的内存页面提供更多可缓存空间（一个页面就是一块内存）。当内核被迫不断地将内存页面移入和移出内存和交换空间swap时，交换使用会成为一个性能问题。

另一个优点是swap让管理员有时间对低内存问题做出反应。我们经常会注意到服务器运行缓慢，并且在登录时会注意到大量交换。如果没有交换（如下一节所述），内存不足会产生更加突然和严重的连锁反应。所以我会建议将交换空间设置为您最大进程的大小。比如mysql在my.cnf中配置的内存。

有些人建议不要交换或交换大小略大于总RAM。如果您能为此提出正当理由，那么这可能是您的选择。但是，这在服务器上几乎不是这种情况，您应该在您的决定与 Swap对您的特定应用程序的影响之间取得平衡。 Swap不会改变服务器所需的 RAM 量。它旨在改善系统的性能。

总结：
— 即使仍有可用的RAM，Linux内核也会将几乎从未使用过的内存页移动到交换空间中。
— 最好换出一段时间不活动的内存页，将经常使用的数据保留在缓存中，这应该发生在服务器最空闲的时候，这是内核的目标。
— 避免将交换空间设置得太大，否则会导致性能问题、中断或响应时间延长。

当可用内存不足时，交换空间与不使用交换空间

与上面的情况不同，如果您没有足够的内存，则在任何内存需求高峰期间，交换将被频繁使用并且明显更多。如果您没有足够的内存并且没有交换空间，这通常会导致无法为需要更多内存页的请求分配内存。作为最后的手段，内核将部署 OOM杀手来攻击高内存进程（通常是 MySQL、java 等）。

要更详细地了解Linux交换空间 Swap，请阅读 Kernel.org文档中的交换管理和Page Frame 回收章节。如果您的交换空间“已使用”始终为“0”，那么您确实有大量自由可用的 RAM，在这种情况下，删除交换空间可能是最好的。

总结：
— Swap I/O的扩展性很差。如果仅在服务器空闲时无法交换内存页，则应调整或禁用 Swap。
— 禁用 Swap后，性能问题会很快变得明显，OOM杀手可能会抓住你！:)

为了进行比较，以下是在同一服务器上使用来自 procps-ng-3.3.1的旧版free的输出：

               total       used       free     shared    buffers     cached
Mem:          3.7G       3.3G       445M         0B       4.2M       1.7G
-/+ buffers/cache:       1.6G       2.1G
Swap:         1.8G       308M       1.5G

内核缓存压力和交换

现在您已启用交换。考虑按照以下指南调整服务器的缓存压力和swap vm.swappiness。

vfs_cache_pressure – 控制内核回收内存的频率，用于缓存目录和inode对象。（默认值 = 100，推荐值 50 到 200）

swappiness – 此值用于定义内核交换内存页面的积极程度。较高的值会增加攻击性；较低的值会减少交换量。（默认值 = 60，推荐值在 1 到 60 之间）删除 0 值的交换，但在大多数情况下通常不推荐。

要编辑，您可以在 /etc/sysctl.conf文件中添加或替换这些行。例如，如果您在升级前内存不足，您可以尝试以下操作：

  vm.swappiness=10
vm.vfs_cache_pressure=200

这将增加缓存压力，这似乎有些适得其反，因为缓存对性能有好处。但是，过于频繁的交换会显着降低服务器的整体性能。因此，不在内存中保留尽可能多的缓存将有助于减少交换活动。此外，将 vm.swappiness设置为10或低至 1，将减少磁盘交换。

在具有大量可用内存的服务器上，使用以下命令：

  vm.swappiness=10
vm.vfs_cache_pressure=50

这将降低缓存压力。由于缓存对性能有好处，我们希望将缓存数据在内存中保留更长时间。由于缓存会变大，我们仍然希望减少交换以不增加交换 I/O。

要使用这些命令检查当前值，请使用：

  sudo cat /proc/sys/vm/swappiness
sudo cat /proc/sys/vm/vfs_cache_pressure

要在不重新启动的情况下临时启用这些设置，请使用以下命令：

  sudo sysctl -w vm.swappiness=10
sudo sysctl -w vm.vfs_cache_pressure=50

swap - myfreax

myfreax 15 Dec 2020 • 4 min readmyfreax

Burp Suite Pro 2021.10 (macOS, Linux) -- 查找、发现和利用漏洞

Tue, 02 Nov 2021 10:34:22 CST

请访问原文链接： Burp Suite Pro 2021 (macOS, Linux) -- 查找、发现和利用漏洞，查看最新版。原创作品，转载请保留出处。

作者：gc(at)sysin.org，主页： www.sysin.org

简介

Burp Suite Professional 是一套用于测试 web 安全性的高级工具集 —- 所有这些都在一个产品中。从一个基本的拦截代理到尖端的 Burp 扫描器，使用 Burp Suite Pro，正确的工具只需点击一下就可以了。

我们强大的自动化让您有更多的机会做您最擅长的，而 Burp Suite 处理容易实现的目标。先进的手动工具将帮助你识别目标更微妙的盲点。

Burp Suite Pro 是由一个研究团队开发的。这意味着在我们发布之前，发现成果已经包含在我们的最新更新中。我们的 pentesting 工具将使您的工作更快，同时让您了解最新的攻击向量。

功能介绍

Manual penetration testing features 手动渗透测试功能

Intercept everything your browser sees

A powerful proxy/history lets you modify all HTTP(S) communications passing through your browser.

Manage recon data

All target data is aggregated and stored in a target site map - with filtering and annotation functions.

Expose hidden attack surface

Find hidden target functionality with an advanced automatic discovery function for “invisible” content.

Test for clickjacking attacks

Generate and confirm clickjacking attacks for potentially vulnerable web pages, with specialist tooling.

Work with WebSockets

WebSockets messages get their own specific history - allowing you to view and modify them.

Break HTTPS effectively

Proxy even secure HTTPS traffic. Installing your unique CA certificate removes associated browser security warnings.

Manually test for out-of-band vulnerabilities

Make use of a dedicated client to incorporate Burp Suite’s out-of-band (OAST) capabilities during manual testing.

Speed up granular workflows

Modify and reissue individual HTTP and WebSocket messages, and analyze the response - within a single window.

Quickly assess your target

Determine the size of your target application. Auto-enumeration of static and dynamic URLs, and URL parameters.

Assess token strength

Easily test the quality of randomness in data items intended to be unpredictable (e.g. tokens).

Advanced/custom automated attacks 高级/自定义自动攻击

Faster brute-forcing and fuzzing

Deploy custom sequences of HTTP requests containing multiple payload sets. Radically reduce time spent on many tasks.

Query automated attack results

Capture automated results in customized tables, then filter and annotate to find interesting entries/improve subsequent attacks.

Construct CSRF exploits

Easily generate CSRF proof-of-concept attacks. Select any suitable request to generate exploit HTML.

Facilitate deeper manual testing

See reflected/stored inputs even when a bug is not confirmed. Facilitates testing for issues like XSS.

Scan as you browse

The option to passively scan every request you make, or to perform active scans on specific URLs.

Automatically modify HTTP messages

Settings to automatically modify responses. Match and replace rules for both responses and requests.

Automated scanning for vulnerabilities 自动扫描漏洞

Harness pioneering AST technology

High signal: low noise. Scan with pioneering, friction-free, out-of-band-application security testing (OAST).

Conquer client-side attack surfaces

Hybrid AST and built-in JavaScript analysis engine help to find holes in client-side attack surfaces.

Fuel vulnerability coverage with research

Cutting-edge scan logic from PortSwigger Research combines with coverage of over 100 generic bugs.

Fine-tune scan control

Get fine-grained control, with a user-driven scanning methodology. Or, run “point-and-click” scans.

Remediate bugs effectively

Custom descriptions and step-by-step remediation advice for every bug, from PortSwigger Research.

Configure scan behavior

Customize what you audit, and how. Skip specific checks, fine-tune insertion points, and much more.

Navigate difficult applications

Crawl more complex targets. Burp Suite’s crawler identifies locations based on content - not just URL.

Effectively apply IAST

Source identification and vulnerability reporting simplified, with optional code instrumentation.

Experience browser-driven scanning

Browser-driven scanning is already striding toward better coverage of tricky targets like AJAX-heavy single page apps.

Productivity tools 生产力工具

Deep-dive message analysis

Show follow-up, analysis, reference, discovery, and remediation in a feature-rich HTTP editor.

Utilize both built-in and custom configurations

Access predefined configurations for common tasks, or save and reuse custom configurations.

Multiply project options

Auto-save all working projects to disk, and add configurations to pre-saved projects.

Make code more readable

Automatically pretty-print code formats including JSON, JavaScript, CSS, HTML, and XML.

Easily remediate scan results

See source, discovery, contents, and remediation, for every bug, with aggregated application data.

Simplify scan reporting

Customize with HTML/XML formats. Report all evidence identified, including issue details.

Speed up data transformation

Decode or encode data, with multiple built-in operations (e.g. Hex, Octal, Base64).

Extensions 扩展

Create custom extensions

Extender API ensures universal adaptability. Code custom extensions to make Burp work for you.

Logger++

For in-depth vulnerability detail, ordered and arranged in an easily accessible table, make use of Logger++.

Autorize

When testing for authorization vulnerabilities, save time and perform repeat requests with Autorize.

Turbo Intruder

Configured in Python, with a custom HTTP stack, Turbo Intruder can unleash thousands of requests per second.

J2EE Scan

Expand your Java-specific vulnerability catalogue and hunt the most niche bugs, with J2EEScan.

Access the extension library

The BApp Store customizes and extends capabilities. Over 250 extensions, written and tested by Burp users.

Upload Scanner

Adapt Burp Scanner’s attacks by uploading and testing multiple file-type payloads, with Upload Scanner.

AuthMatrix

Run AuthMatrix with Autorize to define your access-level vulnerability authorization check.

Param Miner

Quickly find unkeyed inputs with Param Miner - can guess up to 65,000 parameter names per second.

Backslash Powered Scanner

Find research-grade bugs, and bridge human intuition and automation, with Backslash Powered Scanner.

下载地址

官方版本：Professional / Community 2021.10
百度网盘链接： https://pan.baidu.com/s/1jlqpII0Ibu2jwrk82je3JA 提取码：pjtm

本站特别版：今天刚刚发布，需要测试验证后更新。

Burp Suite Pro for macOS
百度网盘链接：

集成 keygen，直接运行，无需额外安装 Java

修复原版图标，Big Sur 图标适配

已知问题：首次运行窗口会变得非常小，拖拽，下次启动即可正常。应用程序运行显示的图标是 java 的图标，比较丑陋，因为破解使用 java loader 导致。
Burp Suite Pro for Linux
百度网盘链接：

安装： chmod +x burpsuitepro-linux-2021.10.bin && sudo ./burpsuitepro-linux-2021.10.bin

集成安装、注册和卸载

主界面一览

有哪些 Linux 平板电脑可供选择

Thu, 28 Oct 2021 17:27:00 CST

有很多基于 Linux 的笔记本电脑，也有预装了 Linux 的迷你 PC，而市场上还有一些基于 Linux 的智能手机。

那平板电脑呢？有没有一些不错的基于 Linux 的平板电脑？这可能不能用一句话说清楚。

许多仅使用 Linux 的系统制造商专注于制造台式电脑。这主要是由于触摸设备上的 Linux 体验与安卓和 iOS 提供的体验相距甚远。

但这是否意味着你不能在平板电脑上使用 Linux？并非如此。对于早期尝试用户和 DIY 爱好者来说，还有一些选择的。让我们来看看在这些 Linux 平板电脑中，你有哪些选择。

Ubuntu Touch

好吧！这不是一个平板电脑，而是一个操作系统。但它确实让你可以在一些旧的安卓平板电脑上安装一个适合触摸操作的 Ubuntu 版本。

注意“一些”这个词。Ubuntu Touch 官方支持 Nexus 7、联想 M10、Xperia Z4 和 BQ Aquaris 平板。你甚至可以尝试在你的其他平板电脑上安装 Ubuntu Touch。它可能无法 100% 工作，但仍然非常有用。

Ubuntu Touch 是 Ubuntu 团队的一个项目，但是他们在 2017 年中止了它。 UBports 承担了继续这个项目的责任，他们在有限的资源下做的很棒。

总而言之，如果你喜欢各种实验，想让你的旧安卓平板电脑获得新生，Ubuntu Touch 可能是你的周末项目。

PineTab

Pine64 始于其单板计算机 Pine A64，以作为树莓派的替代品。随着时间的推移，它推出了几个 Pine 品牌的产品。这份名单里包括低调的 PineTime 智能手表、PineBook 笔记本电脑、PinePhone 智能手机和 PineTab 平板电脑。

这些 Pine 设备通常价格低廉，并允许用户对这些小设备进行完全控制。这种可魔改的特性帮助它聚集了一大批开源 DIY 爱好者的粉丝。

PineTab 基本上使用了与带有触摸屏和键盘的 Pine64 单板计算机相同的组件。它不是看起来最漂亮的平板电脑，也不打算成为这样的。

它的规格很一般，有一个高清 IPS 电容式触摸屏、全志 A64 芯片组、四核 CPU 和 2GB 内存。

它无法与 iPad 或 Galaxy Tab 竞争，但它允许你安装你选择的发行版，并按你的要求进行配置。

请记住，Pine 的库存有限，所以如果你能看到这个设备可以购买，那你很幸运。

PineNote

另一个 Pine 设备，与你在上一节看到的 PineTab 略有不同。

PineTab 是一款用于浏览互联网、使用应用程序和玩游戏的 Linux 平板电脑，而 PineNote 是用来做笔记和阅读书籍和文件的。

它有一个电子墨水显示屏，你可能在 Kindle 等电子书阅读器上见过。除了电子书阅读器之外，PineNote 还可以你用 Wacom 笔做笔记。

PineNote 拥有四核 Rockchip、多点触控电子墨水面板、4GB 内存和 128GB eMMC 存储。它也是为数不多的价格高于通常的 399 美元的平板点之一。

请记住，PineNote 正处于早期开发阶段，只接受开发者的订单。

RasPad

RasPad 是一个用于树莓派设备的套件，可以把它变成一个基于触摸功能的设备。与普通的平板不同，这不是一个扁平的设备，而是有一个楔形的身体。这使得它更容易在办公桌上使用。

RasPad 是专门为树莓派设备创建的，你可以轻松使用它的大部分端口。它有一个专门的 RasPad 操作系统，但你可以自由使用常规的树莓派操作系统或 Ubuntu 或任何其他适合树莓派的操作系统。在选择操作系统时请考虑触控友好性。

请记住，树莓派设备不包括在套件中。你必须要单独购买。

你的选择是什么？

我知道我们离一个优秀的 Linux 平板电脑还很远，但它们至少可以和市场上的安卓平板电脑竞争。至少我们有一些可用的选择，这也是一线希望。

你是否已经拥有以上列出的设备之一了？你的体验如何？

如果你只能选择其中之一，那么你选择哪一款 Linux 平板电脑？

via: https://itsfoss.com/linux-tablets/

作者： Abhishek Prakash 选题： lujun9972 译者： wxy 校对： wxy

本文由 LCTT 原创编译， Linux中国荣誉推出

关于 Linux 内核的 30 件你不知道的事

Fri, 27 Aug 2021 15:00:16 CST

Linux 内核今年 30 岁了。

Linux 内核今年 30 岁了。这开创性的开源软件的三个十年，让用户能够运行自由软件，让他们能从运行的应用程序中学习，让他们能与朋友分享他们所学到的知识。有人认为，如果没有 Linux 内核，我们如今所享受的开源文化和自由软件的累累硕果，可能就不会应时而出现。如果没有 Linux 作为催化剂，苹果、微软和谷歌所开源的那些就不可能开源。Linux 作为一种现象，对开源文化、软件开发和用户体验的影响，是怎么强调都不为过的，但所有这一切，都滥觞于一个 Linux 内核。

Linux 内核是启动计算机、并识别和确保计算机内外所连接的所有组件之间通信的软件。这些对于大多数用户从未想过，更不用说能理解的代码，Linux 内核有很多令人惊讶的地方。以下是 Linux 内核在其三十年生命中每一年的一件事。顺序无关。

Linux 是第一个具有 USB 3.0 驱动的操作系统。Sarah Sharp 在 2009 年 6 月 7 日宣布她的 USB 3.0 设备的驱动程序可以使用了，她的代码被包含在内核 2.6.31 版本中。
当某些事件发生时，内核会将自己标记为“受污染”，这在以后的故障排除中可能有用。运行一个“被污染”的内核并不是什么问题。但如果出现错误，首先要做的是在一个没有被污染的内核上重现该问题。
你可以指定一个主机名或域名作为 ip= 内核命令行选项的一部分，Linux 会保留它，而不是用 DHCP 或 BOOTP 提供的主机名或域名来覆盖它。例如， ip=::::myhostname::dhcp 设置主机名 myhostname。
在文本启动过程中，可以选择显示黑白的、16 色的或 224 色的 Tux 徽标之一。
在娱乐业中，DRM 是一种用来防止访问媒介的技术。然而，在 Linux 内核中，DRM 指的是直接渲染管理器Direct Rendering Manager，它指的是用于与对接显卡的 GPU 的库（ libdrm）和驱动程序。
能够在不重启的情况下给 Linux 内核打补丁。
如果你自己编译内核，你可以将文本控制台配置为超过 80 列宽。
Linux 内核提供了内置的 FAT、exFAT 和 NTFS（读和写）支持。
Wacom 平板电脑和许多类似设备的驱动程序都内置在内核中。
大多数内核高手使用 git send-email 来提交补丁。
内核使用一个叫做 Sphinx 的文档工具链，它是用 Python 编写的。
Hamlib 提供了具有标准化 API 的共享库，可以通过你的 Linux 电脑控制业余无线电设备。
我们鼓励硬件制造商帮助开发 Linux 内核，以确保兼容性。这样就可以直接处理硬件，而不必从制造商那里下载驱动程序。直接成为内核一部分的驱动程序也会自动从新版本内核的性能和安全改进中受益。
内核中包含了许多树莓派模块（Pi Hats）的驱动程序。
netcat 乐队发布了一张只能作为 Linux 内核模块播放的专辑。
受 netcat 发布专辑的启发，人们又开发了一个把你的内核变成一个音乐播放器的模块。
Linux 内核的功能支持许多 CPU 架构：ARM、ARM64、IA-64、 m68k、MIPS、Nios II、PA-RISC、OpenRISC、PowerPC、s390、 Sparc、x86、Xtensa 等等。
2001 年，Linux 内核成为第一个以长模式运行的 x86-64 CPU 架构。
Linux 3.4 版引入了 x32 ABI，允许开发者编译在 64 位模式下运行的代码，而同时只使用 32 位指针和数据段。
内核支持许多不同的文件系统，包括 Ext2、Ext3、Ext4、JFS、XFS、GFS2、GCFS2、BtrFS、NILFS2、NFS、Overlay FS、UDF 等等。
虚拟文件系统Virtual File System（VFS）是 Linux 内核中的一个软件层，为用户运行的应用程序提供文件系统接口。它也是内核的一个抽象层，以便不同的文件系统实现可以共存。
Linux 内核包括一个实体的盲文输出设备的驱动程序。
在 2.6.29 版本的内核中，启动时的 Tux 徽标被替换为 “Tuz”，以提高人们对当时影响澳大利亚的塔斯马尼亚魔鬼Tasmanian Devil（即袋獾）种群的一种侵袭性癌症的认识。
控制组Control Groups（cgroups）是容器（Docker、Podman、Kubernetes 等的基础技术）能够存在的原因。
曾经花了大量的法律行动来解放 CIFS，以便将其纳入内核中，而今天，CIFS 模块已被内置于内核，以实现对 SMB 的支持。这使得 Linux 可以挂载微软的远程共享和基于云的文件共享。
对于计算机来说，产生一个真正的随机数是出了名的困难（事实上，到目前为止是不可能的）。 hw_random 框架可以利用你的 CPU 或主板上的特殊硬件功能，尽量改进随机数的生成。
操作系统抖动 是应用程序遇到的干扰，它是由后台进程的调度方式和系统处理异步事件（如中断）的方式的冲突引起的。像这些问题在内核文档中都有详细的讨论，可以帮助面向 Linux 开发的程序员写出更聪明的代码。
make menuconfig 命令可以让你在编译前使用 GUI 来配置内核。 Kconfig 语言定义了内核配置选项。
对于基本的 Linux 服务器，可以实施一个 看门狗 系统来监控服务器的健康状况。在健康检查间隔中， watchdog 守护进程将数据写入一个特殊的 watchdog 内核设备，以防止系统重置。如果看门狗不能成功记录，系统就会被重置。有许多看门狗硬件的实现，它们对远程任务关键型计算机（如发送到火星上的计算机）至关重要。
在火星上有一个 Linux 内核的副本，虽然它是在地球上开发的。

via: https://opensource.com/article/21/8/linux-kernel

作者： Seth Kenlon 选题： lujun9972 译者： wxy 校对： wxy

本文由 LCTT 原创编译， Linux中国荣誉推出

Kubernetes组件问题排查思路 – 十点运维吧-Linux|Kubernetes|Docker|Prometheus|Python|Golang|云原生|SRE

Mon, 23 Aug 2021 18:36:29 CST

Kubernetes的基础组件就像一栋房子的地基，它们的重要性不言而喻。作为Kubernetes集群的维护者，经常会遇到组件的问题，那平时是怎么去定位解决的呢？

这里简要分析一下我的排查思路。

通过集群的状态，找到故障的节点或者组件
分析组件的日志
使用pprof分析组件的具体性能

确定范围

Kubernetes的基础组件不多，而且部署也非常简单，所以在定义范围的时候还是很容易的，比如我们在使用 kubectl get nodes的时候，如果某个节点的状态是 NotReady，我们脑海中是不是会出现两种可能？
（1）节点的kubelet组件有问题
（2）节点的网络组件有问题

这样一来，大体方向已经确定了，然后就是做排除法了。

这里为何说是排除法？因为在解决问题的途中，我们通常会采用 先假设再验证的方式进行，先把所以可能的因素列出来，然后一个一个的去验证去排除，直到解决问题。

分析日志

日志分析是故障排查最直接的方式，大部分问题都能从日志里体现出来，Kubernetes的组件日志查看方式通常有两种：

通过systemd启动的服务，使用 journalctl -l -u xxxx
使用静态pod启动的服务，使用 kubectl logs -n kube-system $PODNAME --tail 100

当然，很多时候不仅仅是分析它本身的问题，我们还会关注周边的问题，比如基础设施的CPU、内存、IO等情况，这样进行综合考虑来找出问题。

性能分析

为什么把性能分析放到最后呢？

对于大部分人来说，并不擅长，也不喜欢分析组件的性能。第一是时间比较长，第二是要对各个性能指标有一定的了解，第三是学习成本比较大。

众所周知，Kubernetes的版本迭代比较快，基本一年会发2-3个版本，如此快的迭代速度，不排除一些版本中存在BUG，存在一些性能问题。所以在实在没招的情况下，可以尝试对其组件的性能进行分析。

Kubernetes是使用Golang开发，而Golang的pprof是性能分析的利器，提供交互式界面和UI图形化，比较直观，可以很方便的找出问题。除此之外，还可以使用go-torch将profile数据生成火焰图，这样会更直观。

Kubernetes的组件都可以使用 pprof进行性能分析，界面在 host:port/debug/pprof/。

pprof的常用方式

使用交互式命令

查看堆栈调用信息

`1`	`go tool pprof http://localhost:8001/debug/pprof/heap`

查看 30 秒内的 CPU 信息

`1`	`go tool pprof http://localhost:8001/debug/pprof/profile?seconds=30`

查看 goroutine 阻塞

    go tool pprof http://localhost:8001/debug/pprof/block

收集 5 秒内的执行路径

    go tool pprof http://localhost:8001/debug/pprof/trace?seconds=5

争用互斥持有者的堆栈跟踪

    go tool pprof http://localhost:8001/debug/pprof/mutex

通过UI界面

UI分析工具使用起来相对比较麻烦，我们需要先导出文件，然后再使用 go tool工具起服务进行分析。

比如我们导出kube-scheduler的堆栈信息。

    curl -sK -v http://localhost:10251/debug/pprof/heap > heap.out

然后使用go tool工具起一个服务，如下：

    go tool pprof -http=0.0.0.0:8989 heap.out

然后就可以在浏览器上看到具体的堆栈信息图了。

注意，这里需要在服务端安装 graphviz组件，各种操作系统的安装方式见[3]。

UI界面主要的菜单以及其功能简要介绍如下：

VIEW：查看模式
- Top：从高到底排序查看
- Graph：默认的模式，以关系图形式查看
- Flame Graph：以火焰图形式查看
- Peek：排序查看，展示的信息更多
- Source：排序查看，带源码标注
- Disassemble：现实所有总量
SAMPLE：为VIEW提供查看模式
- alloc_objects：已分配的对象总量（不管是否已释放
- alloc_space：已分配的内存总量（不管是否已释放）
- inuse_objects：已分配但尚未释放的对象数量
- inuse_sapce：已分配但尚未释放的内存数量
REFINE：提供筛选能力

上面简单介绍了pprof的基本使用方法，下面就Kubernetes的各个组件进行简单的分析，这里只就CPU信息进
行获取以及展示。

注意：由于版本原因，有的版本默认开启了pprof，有的版本则没有，如果没有开启的，需要自行去开启，参数基本都是 profiling: true，具体的信息可以到官网进行查看[4]。

分析kube-apiserver

（1）使用kubectl proxy启动一个代理

`1`	`kubectl proxy`

（2）另起一个终端，获取CPU信息

`1`	`curl -sK -v http://localhost:8001/debug/pprof/profile >apiserver-cpu.out`

（3）使用go tool工具启动服务

`1`	`go tool pprof -http=0.0.0.0:8989 apiserver-cpu.out`

（4）在浏览器上进行查看

分析kube-scheduler

（1）获取CPU的信息

`1`	`curl -sK -v http://localhost:10251/debug/pprof/profile >scheduler-cpu.out`

（2）使用go tool工具启动服务

`1`	`go tool pprof -http=0.0.0.0:8989 scheduler-cpu.out`

（3）在浏览器进行查看

分析kube-controller-manager

（1）获取CPU的信息

`1`	`curl -sK -v http://localhost:10252/debug/pprof/profile >controller-cpu.out`

（2）使用go tool工具启动服务

`1`	`go tool pprof -http=0.0.0.0:8989 controller-cpu.out`

（3）在浏览器进行查看

分析kubelet

（1）使用kubectl proxy启动一个代理

`1`	`kubectl proxy`

（2）另起一个终端，获取CPU信息

`1`	`curl -sK -v http://127.0.0.1:8001/api/v1/nodes/k8s-node04-138/proxy/debug/pprof/profile >kubelet-cpu.out`

（3）使用go tool工具启动服务

`1`	`go tool pprof -http=0.0.0.0:8989 kubelet-cpu.out`

（4）在浏览器上进行查看

能够抓到具体的性能数据才是第一步，后续的具体分析才会帮助我们找到问题。

文档

linux grep 查看大日志文件

Mon, 07 Jun 2021 15:52:26 CST

这是我参与更文挑战的第7天，活动详情查看：更文挑战

如果❤️我的文章有帮助，欢迎点赞、关注。这是对我继续技术创作最大的鼓励。

linux grep 查看大日志文件

场景

今天隔离还在继续，在家办公。忽然下午午工作群里发来一个 mysql 机器io/负载上升的预警，异常发生在 15：45 ~ 16：00 之间。为了事后为了查明原因，需要翻看慢查询日志 slow.log 才发现日志 8G 多... 故事就这样开始了

怎么办呢。第一个想到的就是常用 grep 匹配关键字

grep 关键字

grep 常用于 关键字 匹配文件文本信息。
但关键字从哪里来呢，可以命令 head slow3306_9110.log 查看下检索文件的 内容结构

因为异常发生在 15：45 ~ 16：00 之间，我就可以这样写

grep -n 'Time: 210607 15:[45-59]' slow3306_9110.log

时间 15：45 至 15：59 之间内容，但这样匹配只能看到时间，这明显不是我们想要的

grep 显示匹配行附近内容

A -> After
B -> Before
C -> Context

举个例子：

grep -A5 'Time: 210607 15:[45-59]' slow3306_9110.log

就能把匹配 Time: 210607 行的 下面 5 行也显示出来。

grep 多关键字搜索

但这时我们有会发现， Query_time: 0.925375 查询时间有大有小。我现在在查故障明细是只想看 查询消耗时间大的。

所以这里就需要用到 grep 多关键字搜索

匹配多个关键字（且）

管道符连接 多个条件 实现关键字 且关系 匹配：

grep -A5 'Time: 210607 15:[45-59]' slow3306_9110.log | grep 'Query_time: (\d[2-5])'

同一行同时满足两个条件（ Time、 Query_time）才能够匹配。

不过这里也必须说明： 因为上图内容格式中，Time 和 Query_time 不在同一列，所以上诉命令只是这个演示。实际只能匹配 同一行同时满足两个条件 内容

grep -E 匹配多个关键字（或）

grep -E "word1|word2|word3" file.txt

匹配文件中同一行包含 word1、word2、word3 之一

总结

总结下来。

由于多行无法同时命中 时间 15：45 至 15：59 和 查询时间在 2~5位整数之间。
另外由于文件太大，grep 一次就能跑个 3、4 分钟实际体验并不好

Linux - 系统指标 CPU load - 简书

Thu, 03 Jun 2021 19:20:28 CST

cpu load

cpu load通常做为一个机器负载的衡量指标

cpu load是对使用或者等待cpu进程的统计(数量的累加)。每一个使用(using)或者等待(waiting)CPU的进程(process)，都会使load值+1。
每一个结束的(teminates)进程，都会使load值-1。

所谓使用CPU的进程，是指状态为 running的进程，或者说是在cpu run queue里的进程。
所谓等待CPU的进程，是指状态为 runnable的进程，或者说是在cpu ready queue里的进程。

大部分Unix操作系统只计算 running和 runnable的进程。但是Linux系统除了上述两种状态进行，还计算 uninterruptible sleep状态的进程(通常是在等待磁盘IO)。因此，如果有很多进程被block在IO处，Linux系统显示的load会被Unix系统高一些。举个例子，如果有进程由于NFS服务挂掉或者USB设备太慢而block住的话，会显示一个奇怪的现象： cpu使用率不高，但是cpu load很高。

cpu load average

通常，我们关注的不是cpu load，而是cpu load average这个指标。

所有的Unix和类Unix操作系统，都有3 个"load average"的统计指标。分别表示 1分钟、5分钟和15分钟内的cpu负载均值。

使用 uptime命令是查看cpu负载最简单的命令：

$ uptime
14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09

当然， w和 top命令也包含cpu load信息。

top命令：

image.png

w命令：

image.png

load average的意义

load average是个无量纲的，大致可认为是cpu进程队列中进程的数量和cpu可处理能力的比值。比如cpu最多同时能处理10个进程，

如果队列中进程数量为5，load average为50%，说明cpu还没达到负载上限
如果队列中进程数量为10，load average为100%，说明刚好达到负载上限
如果队列中进程数量为15，load average为150%，说明超出了cpu的处理能力

单个cpu的load average为0.7以上时，需要注意是否快达到了服务能力的瓶颈。

cpu load和cpu utilization

cpu load(cpu负载)相较于cpu utilization(cpu使用率)更能反映机器的负载情况。

因为，假如有两个配置相同的机器，一个机器cpu utilization是50%，另一个是70%，我们可以认为70%的机器负载比50%的高。但是如果两个机器的cpu use都是100%的话，谁的负载更高，就不得而知了。而cpu load是可以反映出来的。

比如两个机器的per cpu load分别是1.5和1.8，但是他们的cpu use都是100%。但是我们依旧可以知道哪台机器负载更高。

假如在一个单核机器上，load average是"1.73 0.60 7.98"，那么可以大致这么解释：

在过去1分钟中，系统负载超额73%。(1.73个runnable进程，但是有0.73个进程需要等待)
在过去5分钟中，系统负载有40%空闲
在过去15分钟中，系统负载超额698%。(7.98个runnable进程，但是有6.98个需要等待)

参考

Linux系统安全强化指南

Sat, 08 May 2021 03:29:30 CST

本指南旨在说明如何尽可能地加强Linux的安全性和隐私性，并且不限于任何特定的指南。

免责声明：如果您不确定自己在做什么，请不要尝试在本文中使用任何内容。

本指南仅关注安全性和隐私性，而不关注性能，可用性或其他内容。列出的所有命令都将需要root特权。以“$”符号开头的单词表示一个变量，不同终端之间可能会有所不同。

选择正确的Linux发行版

选择一个好的Linux发行版有很多因素。

避免分发冻结程序包，因为它们在安全更新中通常很落后。
不使用与Systemd机制的发行版。 Systemd包含许多不必要的攻击面；它尝试做的事情远远超出了必要，并且超出了初始化系统应做的事情。
使用musl作为默认的C库。 Musl专注于最小化，这会导致很小的攻击面，而其他C库（例如glibc）过于复杂，容易产生漏洞。例如，与musl中的极少数漏洞相比，glibc中的一百多个漏洞已被公开披露。尽管仅靠披露的CVE本身通常是不准确的统计信息，但有时这种情况有时可以用来表示过分的问题。 Musl还具有不错的漏洞利用缓解措施，尤其是其新的强化内存分配器。
最好默认情况下使用LibreSSL而不是OpenSSL的发行版。OpenSSL包含大量完全不必要的攻击面，并且遵循不良的安全做法。例如，它仍然保持OS / 2和VMS支持这些已有数十年历史的古老操作系统。这些令人讨厌的安全做法导致了可怕的Heartbleed漏洞。LibreSSL是OpenBSD团队的OpenSSL分支，它采用了出色的编程实践并消除了很多攻击面。在LibreSSL成立的第一年内，它缓解了许多漏洞，其中包括一些高严重性的漏洞。

用作强化操作系统基础的最佳发行版是Gentoo Linux，因为它可以让您精确地配置系统，以达到理想的效果，这将非常有用，尤其是参考我们在后面的章节中使用更安全的编译标志。

但是，由于Gentoo的巨大可用性缺陷，它对于许多人来说可能并不顺手。在这种情况下，Void Linux的Musl构建是一个很好的折衷方案。

内核

Stable vs LTS内核

Linux内核以两种主要形式发布：稳定和长期支持（LTS）。稳定版本是较新的版本，而LTS发行版本是较老的稳定版本，长期以来一直受支持。选择上述任何一个发行版本都有许多后果。

Linux内核未使用CVE标识安全漏洞。这意味着大多数安全漏洞的修复程序不能向后移植到LTS内核。但是稳定版本包含到目前为止进行的所有安全修复。

但是，有了这些修复程序，稳定的内核将包含更多新功能，因此大大增加了内核的攻击面，并引入了大量新错误。相反，LTS内核的受攻击面较小，因为这些功能没有被不断添加。

此外，稳定的内核还包括更新的强化功能，以减轻LTS内核没有的某些利用。此类功能的一些示例是Lockdown LSM和STACKLEAK GCC插件。

总而言之，在选择稳定或LTS内核时需要权衡取舍。LTS内核具有较少的强化功能，并且并非当时所有的公共错误修复都已向后移植，但是通常它的攻击面更少，并且引入未知错误的可能性也较小。稳定的内核具有更多的强化功能，并且包括所有已知的错误修复，但它也具有更多的攻击面以及引入更多未知错误的机会更大。最后，最好使用较新的LTS分支（如4.19内核）。

Sysctl

Sysctl是允许用户配置某些内核设置并启用各种安全功能或禁用危险功能以减少攻击面的工具。要临时更改设置，您可以执行：

sysctl -w $tunable = $value

要永久更改sysctls，您可以将要更改的sysctls添加到/etc/sysctl.conf或/etc/sysctl.d中的相应文件，具体取决于您的Linux发行版。

以下是您应更改的建议sysctl设置。

Kernel self-protection

kernel.kptr_restrict=2

kernel.dmesg_restrict=1

dmesg是内核日志，它公开了大量有用的内核调试信息，但这通常会泄漏敏感信息，例如内核指针。更改上述sysctl设置会将内核日志限制为CAP_SYSLOG功能。

kernel.printk=3 3 3 3

kernel.unprivileged_bpf_disabled=1    

net.core.bpf_jit_harden=2

dev.tty.ldisc_autoload=0

vm.unprivileged_userfaultfd=0

userfaultfd() 系统调用经常被滥用以利用“事后使用(use-after-free)”缺陷。因此，该sysctl用于将此syscall限制为CAP_SYS_PTRACE功能。

kernel.kexec_load_disabled=1

kernel.sysrq=4

kernel.unprivileged_userns_clone=0

用户名称空间是内核中的一项功能，旨在改善沙箱并使非特权用户易于访问它，但是，此功能公开了重要的内核攻击面，以进行特权升级，因此该sysctl将用户名称空间的使用限制为CAP_SYS_ADMIN功能。对于无特权的沙箱，建议使用具有很少攻击面的setuid二进制文件，以最大程度地减少特权升级的可能性。沙箱章节部分将进一步讨论此主题。

请注意，尽管该sysctl仅在某些Linux发行版中存在，因为它需要内核补丁。如果您的内核不包含此补丁，则可以通过设置user.max_user_namespaces = 0来完全禁用用户名称空间（包括root用户）。

kernel.perf_event_paranoid=3

性能事件会增加大量内核攻击面，并导致大量漏洞。此sysctl设置将性能事件的所有使用限制为CAP_PERFMON功能（5.8之前的内核版本为CAP_SYS_ADMIN）。

请注意，此sysctl设置需要在某些发行版中具备相关的内核补丁。否则，此设置等效于kernel.perf_event_paranoid = 2，它仅限制此功能的子集。

网络

net.ipv4.tcp_syncookies=1

net.ipv4.tcp_rfc1337=1

这通过丢弃处于时间等待状态的套接字的RST数据包来防止time-wait状态。

net.ipv4.conf.all.rp_filter=1    

net.ipv4.conf.default.rp_filter=1

这些启用了源验证，以验证从计算机所有网络接口接收到的数据包。

net.ipv4.conf.all.accept_redirects=0    

net.ipv4.conf.default.accept_redirects=0    

net.ipv4.conf.all.secure_redirects=0    

net.ipv4.conf.default.secure_redirects=0    

net.ipv6.conf.all.accept_redirects=0    

net.ipv6.conf.default.accept_redirects=0    

net.ipv4.conf.all.send_redirects=0    

net.ipv4.conf.default.send_redirects=0

这些设置禁用了ICMP重定向，以防止中间人攻击并最大程度地减少信息泄露。

net.ipv4.icmp_echo_ignore_all=1

此设置使您的系统忽略所有ICMP请求，以避免Smurf攻击，使设备更难以在网络上枚举，并防止通过ICMP时间戳识别时钟指纹。

net.ipv4.conf.all.accept_source_route=0    

net.ipv4.conf.default.accept_source_route=0    

net.ipv6.conf.all.accept_source_route=0    

net.ipv6.conf.default.accept_source_route=0

net.ipv6.conf.all.accept_ra=0    

net.ipv6.conf.default.accept_ra=0

恶意的IPv6路由广告可能会导致中间人攻击，因此应将其禁用。

net.ipv4.tcp_sack=0    

net.ipv4.tcp_dsack=0    

net.ipv4.tcp_fack=0

禁用TCP SACK。ACK通常被利用，并且在许多情况下是不必要的，因此如果您不需要它，则应将其禁用。

用户空间

kernel.yama.ptrace_scope=2

vm.mmap_rnd_bits=32    

vm.mmap_rnd_compat_bits=16

ASLR是一种常见的漏洞利用缓解措施，它可以使进程的关键部分在内存中的位置随机化。这可能会使各种各样的漏洞利用更困难，因为它们首先需要信息泄漏。上述设置增加了用于mmap ASLR的熵的位数，从而提高了其有效性。

这些sysctls的值必须根据CPU体系结构进行设置。以上值与x86兼容，但其他体系结构可能有所不同。

fs.protected_symlinks=1    

fs.protected_hardlinks=1

fs.protected_fifos=2    

fs.protected_regular=2

这些阻止了在可能由攻击者控制的环境（例如，全局可写目录）中创建文件，从而使数据欺骗攻击更加困难。

引导参数

引导参数在引导时使用引导加载程序（bootloader）将设置传递给内核。类似于sysctl，可以使用某些设置来提高安全性。引导加载程序通常在引导参数设置方式上有所不同。下面列出了一些示例，但是您应该研究特定bootloader的修改参数的必要步骤。

如果使用GRUB作为引导程序，请编辑/etc /default/grub并将参数添加到GRUB_CMDLINE_LINUX_DEFAULT=line。

如果使用Syslinux，请编辑/boot/syslinux/syslinux.cfg并将它们添加到APPEND行中。

如果使用systemd-boot，请编辑您的加载程序条目，并将其附加到linux行的末尾。

建议使用以下设置以提高安全性。

Kernel self-protection

slab_nomerge

这将禁用slab合并，这将通过防止覆盖合并的缓存中的对象并使其更难以影响slab缓存的布局，从而大大增加了堆利用的难度。

slub_debug=FZ

init_on_alloc=1 init_on_free=1

page_alloc.shuffle=1

此选项使页分配器空闲列表随机化，从而通过降低页分配的可预测性来提高安全性，同时这也提高了性能。

pti=on

这将启用内核页表隔离，从而减轻崩溃并防止某些KASLR绕过。

vsyscall=none

这将禁用vsyscall，因为它们已过时且已被vDSO取代。 vsyscall也在内存中的固定地址上，使其成为ROP攻击的潜在目标。

debugfs=off

这将禁用debugfs，它会公开许多有关内核的敏感信息。

oops=panic

module.sig_enforce=1

这仅允许加载已使用有效密钥签名的内核模块，使加载恶意内核模块更加困难。

这可以防止加载所有树外内核模块（包括DKMS模块），除非您已对其进行签名，这意味着诸如VirtualBox或Nvidia驱动程序之类的模块可能不可用，但根据您的设置可能并不重要。

lockdown=confidentiality

mce=0

这将导致内核对ECC内存中无法利用的错误panic，而这些错误可能会被利用。对于没有ECC内存的系统，这是不必要的。

quiet loglevel=0

这些参数可防止引导期间信息泄漏，并且必须与上面的kernel.printk sysctl结合使用。

CPU缓解

最好启用适用于您的CPU的所有CPU缓解措施，以确保您不受已知漏洞的影响。这是启用所有内置缓解措施的列表：

spectre_v2=on spec_store_bypass_disable=on tsx=off tsx_async_abort=full,nosmt mds=full,nosmt l1tf=full,force nosmt=force kvm.nx_huge_pages=force

您必须研究系统受其影响的CPU漏洞，并相应地选择上述缓解措施。请记住，您将需要安装微代码更新，以完全免受这些漏洞的影响。但所有这些操作都可能导致性能显着下降。

结果

如果遵循了以上所有建议（不包括特定的CPU缓解措施），则将具有：

slab_nomerge slub_debug=FZ init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on vsyscall=none debugfs=off oops=panic module.sig_enforce=1 lockdown=confidentiality mce=0 quiet loglevel=0

如果将GRUB用作引导加载程序，则可能需要重新生成GRUB配置文件才能应用这些文件。

hidepid

/proc是一个伪文件系统，其中包含有关系统上当前正在运行的所有进程的信息。默认情况下，所有用户都可以访问此程序，这可能使攻击者可以窥探其他进程。要只允许用户看到自己的进程，而不能看到其他用户的进程，则必须使用hidepid=2，gid=proc挂载选项来挂载/proc。gid=proc将proc组从此功能中排除，因此您可以将特定的用户或进程列入白名单。添加这些选项的一种方法是编辑/etc/fstab并添加：

proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0

systemd-logind仍然需要查看其他用户的进程，因此，要使用户会话在systemd系统上正常工作，必须创建/etc/systemd/system/systemd-logind.service.d/hidepid.conf并添加：

[Service]    

SupplementaryGroups=proc

减少内核攻击面

最好禁用不是绝对必要的任何功能，以最大程度地减少潜在的内核攻击面。这些功能不必一定很危险，它们可以只是被删除以减少攻击面的良性代码。切勿禁用您不了解的随机事物。以下是一些可能有用的示例，具体取决于您的设置。

引导参数

引导参数通常可以用来减少攻击面，这样的例子之一是：

ipv6.disable=1

这将禁用整个IPv6堆栈，如果您尚未迁移到该堆栈，则可能不需要该堆栈。如果正在使用的IPv6，请不要使用此引导参数。

将内核模块列入黑名单

内核允许非特权的用户通过模块自动加载来间接导致某些模块被加载。这使攻击者可以自动加载易受攻击的模块，然后加以利用。一个这样的示例是CVE-2017-6074，其中攻击者可以通过启动DCCP连接来触发DCCP内核模块的加载，然后利用该内核模块中的漏洞。

可以通过将文件插入/etc/modprobe.d并将指定的内核模块列入黑名单的方法，将特定的内核模块列入黑名单。

Install参数告诉modprobe运行特定命令，而不是像往常一样加载模块。 /bin/false是仅返回1的命令，该命令实际上不会执行任何操作。两者都告诉内核运行/bin/false 而不是加载模块，这将防止攻击者利用该模块。以下是最有可能不需要的内核模块：

install dccp /bin/false    

install sctp /bin/false    

install rds /bin/false    

install tipc /bin/false    

install n-hdlc /bin/false    

install ax25 /bin/false    

install netrom /bin/false    

install x25 /bin/false    

install rose /bin/false    

install decnet /bin/false    

install econet /bin/false    

install af_802154 /bin/false    

install ipx /bin/false    

install appletalk /bin/false    

install psnap /bin/false    

install p8023 /bin/false    

install p8022 /bin/false    

install can /bin/false    

install atm /bin/false

特别是模糊的网络协议会增加大量的远程攻击面。此黑名单：

DCCP — Datagram Congestion Control Protocol
SCTP — Stream Control Transmission Protocol
RDS — Reliable Datagram Sockets
TIPC — Transparent Inter-process Communication
HDLC — High-Level Data Link Control
AX25 — Amateur X.25
NetRom
X25
ROSE
DECnet
Econet
af_802154 — IEEE 802.15.4
IPX — Internetwork Packet Exchange
AppleTalk
PSNAP — Subnetwork Access Protocol
p8023 — Novell raw IEEE 802.3
p8022 — IEEE 802.2
CAN — Controller Area Network
ATM

install cramfs /bin/false    

install freevxfs /bin/false    

install jffs2 /bin/false    

install hfs /bin/false    

install hfsplus /bin/false    

install squashfs /bin/false    

install udf /bin/false

将各种稀有文件系统列入黑名单。

install cifs /bin/true    

install nfs /bin/true    

install nfsv3 /bin/true    

install nfsv4 /bin/true    

install gfs2 /bin/true

如果不使用网络文件系统，也可以将其列入黑名单。

install vivid /bin/false

vivid driver[1]驱动程序仅用于测试目的，并且是特权提升漏洞的原因，因此应禁用它。

install bluetooth /bin/false    

install btusb /bin/false

禁用具有安全问题历史记录的蓝牙。

install uvcvideo /bin/false

这会禁用网络摄像头，以防止其被用来监视您。

您也可以将麦克风模块列入黑名单，但这在系统之间可能会有所不同。要查找模块的名称，请在/proc/asound/modules中查找并将其列入黑名单。例如，一个这样的模块是snd_hda_intel。

请注意，尽管有时麦克风的内核模块与扬声器的模块相同。这意味着像这样禁用麦克风也可能会无意中禁用任何扬声器，虽然扬声器也有可能变成麦克风，所以这不一定是消极的结果。

最好从物理上删除这些设备，或者至少在BIOS/UEFI中禁用它们。禁用内核模块并不总是那么有效。

rfkill

可以通过rfkill将无线设备列入黑名单，以进一步减少远程攻击面。要将所有无线设备列入黑名单，请执行：

rfkill block all

WiFi可以通过以下方式解锁：

rfkill unblock wifi

在使用systemd的系统上，rfkill在所有会话中均保持不变，但是，在使用其他init系统的系统上，您可能必须创建一个init脚本以在引导时执行这些命令。

其他内核指针泄漏

前面的部分已经防止了一些内核指针泄漏，但是还有更多泄漏。

在文件系统上，/boot中存在内核映像和System.map文件。/usr/src和/{,usr/} lib/modules目录中还有其他敏感的内核信息。您应该限制这些目录的文件权限，以使它们只能由root用户读取。您还应该删除System.map文件，因为除高级调试外，它们都不需要。

此外，某些日志记录守护程序（例如systemd的journalctl）包括内核日志，可用于绕过上述dmesg_restrict保护。从adm组中删除用户通常足以撤销对以下日志的访问：

gpasswd -d $user adm

限制对sysfs的访问

sysfs是伪文件系统，可提供大量的内核和硬件信息。它通常安装在/sys上。 sysfs导致大量信息泄漏，尤其是内核指针泄漏。Whonix的security-misc软件包包括hide-hardware-info脚本，该脚本限制访问此目录以及/proc中的一些脚本，以试图隐藏潜在的硬件标识符并防止内核指针泄漏。该脚本是可配置的，并允许基于组将特定的应用程序列入白名单。建议应用此方法，并使其在启动时使用init脚本执行。或者这样做成systemd服务。

为了使基本功能在使用systemd的系统上运行，必须将一些系统服务列入白名单。这可以通过创建/etc/systemd/system/user@.service.d/sysfs.conf并添加以下内容来完成：

[Service]    

SupplementaryGroups=sysfs

但是，这不能解决所有问题。许多应用程序可能仍会中断，您需要将它们正确列入白名单。

Linux强化

某些发行版（例如Arch Linux）包括强化的内核程序包。它包含许多强化补丁程序和更注重安全性的内核配置。如果可能的话，建议安装它。

Grsecurity

内核运行时防护

自编译内核

建议编译您自己的内核，同时启用尽可能少的内核模块和尽可能多的安全性功能，以将内核的受攻击面保持在绝对最低限度。

另外，应用内核强化补丁，例如如上所述的linux-hardened或grsecurity。

发行版编译的内核还具有公共内核指针/符号，这对于漏洞利用非常有用。编译自己的内核将为您提供独特的内核符号，连同kptr_restrict，dmesg_restrict和其他针对内核指针泄漏的强化措施，将使攻击者更加难以创建依赖于内核指针知识的漏洞利用程序。

您就可以从Whonix的强化内核中汲取灵感或使用它。

强制访问措施

强制访问控制（MAC）系统对程序可以访问的内容进行细粒度的控制。这意味着您的浏览器将无权访问您的整个主目录或类似目录。

最常用的MAC措施是SELinux和AppArmor。SELinux比AppArmor更安全，因为它的粒度更细。例如，它是基于inode而不是基于路径的，允许强制执行明显更严格的限制，可以过滤内核ioctl等。不幸的是，这是以难以使用和难以学习为代价的，因此某些人可能会首选AppArmor。

要在内核中启用AppArmor，必须设置以下引导参数：

apparmor=1 security=apparmor

要启用SELinux，请设置以下参数：

selinux=1 security=selinux

请记住，仅启用MAC措施本身并不能神奇地提高安全性。您必须制定严格的政策才能充分利用它。例如，要创建AppArmor配置文件，请执行：

aa-genprof $path_to_program

打开程序，然后像往常一样开始使用它。AppArmor将检测需要访问哪些文件，并将它们添加到配置文件中（如果您选择的话）。但是，仅凭这一点不足以提供高质量的配置文件。请参阅AppArmor文档[5]以获取更多详细信息。

如果您想更进一步，则可以通过实施initramfs勾子来设置一个完整的系统MAC策略，该策略限制每个单个用户空间进程，该挂钩对init系统强制实施MAC策略。这就是Android使用SELinux的方式，以及Whonix未来将如何使用AppArmor的方式。对于加强实施最小特权原则的强大安全模型是必要的。

沙箱

应用沙箱

沙箱可让您在隔离的环境中运行程序，该环境对系统的其余部分具有有限的访问权限或完全没有访问权限。您可以使用它们来保护应用程序安全或运行不受信任的程序。

建议与AppArmor或SELinux一起在单独的用户帐户中使用Bubblewrap[6]到沙箱程序。您也可以考虑改用gVisor，它的优点是为每个来宾提供了自己的内核。

这些方法中的任何一个都可以用来创建一个功能强大的沙箱，并且暴露的攻击面最小。如果您不想自己创建沙箱，请在完成后考虑使用Whonix的sandbox-app-launcher。您不应该使用Firejail。

诸如Docker和LXC之类的容器解决方案经常被误导为沙盒形式。它们太宽松了，无法广泛支持各种应用程序，因此不能认为它们是强大的应用程序沙箱。

常见沙箱逃逸

PulseAudio

PulseAudio是一种常见的声音服务器，但在编写时并未考虑隔离或沙盒的问题，这使其成为重复出现的沙盒逃逸漏洞。为了防止这种情况，建议您从沙箱中阻止对PulseAudio的访问，或者从系统中完全卸载它。

D-Bus

D-Bus是台式机Linux上最流行的进程间通信形式，但它也是沙箱逃逸的另一种常见途径，因为它允许与服务自由交互。这些漏洞的一个例子就是Firejail。您应该从沙箱中阻止对D-Bus的访问，或者通过MAC以细粒度的规则进行调解。

GUI隔离

任何Xorg窗口都可以访问另一个窗口。这允许琐碎的键盘记录或屏幕截图程序，甚至可以记录诸如root密码之类的内容。您可以使用嵌套的X11服务器（例如Xpra或Xephyr和bubblewrap）将Xorg窗口沙箱化。默认情况下，Wayland将窗口彼此隔离，这将是一个比Xorg更好的选择，尽管Wayland可能不如Xorg普遍可用，因为它在开发中较早。

ptrace

如前所述，ptrace是一个系统调用，可能会被滥用破坏在沙箱外部运行的进程。为避免这种情况，您可以通过sysctl启用内核YAMA ptrace限制，也可以在seccomp过滤器中将ptrace syscall列入黑名单。

TIOCSTI

TIOCSTI是一个ioctl，它允许注入终端命令，并为攻击者提供了一种简单的机制，可以在同一用户会话内的其他进程之间横向移动。可以通过将seccomp过滤器中的ioctl列入黑名单或使用bubblewrap的--new-session参数来缓解这种攻击。

Systemd沙箱

虽然不建议使用systemd，但有些系统可能无法切换。这些人至少可以使用沙盒服务，因此他们只能访问所需的内容。这是一个沙箱化systemd服务的示例：

[Service]    

CapabilityBoundingSet=CAP_NET_BIND_SERVICE    

ProtectSystem=strict    

ProtectHome=true    

ProtectKernelTunables=true    

ProtectKernelModules=true    

ProtectControlGroups=true    

ProtectKernelLogs=true    

ProtectHostname=true    

ProtectClock=true    

ProtectProc=invisible    

ProcSubset=pid    

PrivateTmp=true    

PrivateUsers=yes    

PrivateDevices=true    

MemoryDenyWriteExecute=true    

NoNewPrivileges=true    

LockPersonality=true    

RestrictRealtime=true    

RestrictSUIDSGID=true    

RestrictAddressFamilies=AF_INET    

RestrictNamespaces=yes    

SystemCallFilter=write read openat close brk fstat lseek mmap mprotect munmap rt_sigaction rt_sigprocmask ioctl nanosleep select access execve getuid arch_prctl set_tid_address set_robust_list prlimit64 pread64 getrandom    

SystemCallArchitectures=native    

UMask=0077    

IPAddressDeny=any    

AppArmorProfile=/etc/apparmor.d/usr.bin.example

所有选项的说明：

CapabilityBoundingSet=— Specifies the capabilities[8]the process is given.
ProtectHome=true— Makes all home directories inaccessible.
ProtectKernelTunables=true— Mounts kernel tunables such as those modified through sysctlas read-only.
ProtectKernelModules=true— Denies module loading and unloading.
ProtectControlGroups=true— Mounts all control group hierarchies as read-only.
ProtectKernelLogs=true— Prevents accessing the kernel logs.
ProtectHostname=true— Prevents changes to the system hostname.
ProtectClock— Prevents changes to the system clock.
ProtectProc=invisible— Hides all outside processes.
ProcSubset=pid— Permits access to only the pid subset of /proc.
PrivateTmp=true— Mounts an empty tmpfs over /tmpand /var/tmp, therefore hiding their previous contents.
PrivateUsers=true— Sets up an empty user namespace to hide other user accounts on the system.
PrivateDevices=true— Creates a new /devmount with minimal devices present.
MemoryDenyWriteExecute=true— Enforces a memory W^X policy.
NoNewPrivileges=true— Prevents escalating privileges.
LockPersonality=true— Locks down the personality()syscall to prevent switching execution domains.
RestrictRealtime=true— Prevents attempts to enable realtime scheduling.
RestrictSUIDSGID=true— Prevents executing setuid or setgid binaries.
RestrictAddressFamilies=AF_INET— Restricts the usable socket address families to IPv4 only ( AF_INET).
RestrictNamespaces=true— Prevents creating any new namespaces.
SystemCallFilter=...— Restricts the allowed syscalls to the absolute minimum. If you aren't willing to maintain your own custom seccomp filter, then systemd provides many predefined system call sets that you can use. @system-servicewill be suitable for many use cases.
SystemCallArchitectures=native— Prevents executing syscalls from other CPU architectures.
UMask=0077— Sets the umask[9]to a more restrictive value.
IPAddressDeny=any— Blocks all incoming and outgoing traffic to/from any IP address. Set IPAddressAllow=to configure a whitelist. Alternatively, setup a network namespace with PrivateNetwork=true.
AppArmorProfile=...— Runs the process under the specified AppArmor profile.

您不能仅将此示例配置复制到您的配置中，每种服务的要求各不相同，并且必须针对每种服务微调沙箱。要了解有关您可以设置的所有选项的更多信息，请阅读 systemd.exec手册页。

如果您使用的系统不是systemd而是init，那么可以使用bubblewrap轻松复制所有这些选项。

gVisor

普通沙箱固有地与主机共享同一内核。您信任我们已经评估为不安全的内核，可以正确限制这些程序。由于主机内核的整个攻击面已完全暴露，因此沙盒中的内核利用程序可以绕过任何限制。已经进行了一些努力来限制使用seccomp的攻击面，但不足以完全解决此问题。

GVisor是解决此问题的方法。它为每个应用程序提供了自己的内核，该内核以内存安全的语言重新实现了Linux内核的大部分系统调用，从而提供了明显更强的隔离性。

虚拟机

强化内存分配器

hardened_malloc是一种硬化的内存分配器，可为堆内存损坏漏洞提供实质性的保护。它很大程度上基于OpenBSD的malloc设计，但具有许多改进。

可以通过LD_PRELOAD环境变量针对每个应用程序使用hardened_malloc。例如，假设您编译的库位于/usr/lib/libhardened_malloc.so，则可以执行：

LD_PRELOAD="/usr/lib/libhardened_malloc.so" $program

通过全局预加载该库，也可以在系统范围内使用它，这是使用它的推荐方法。为此，请编辑/etc/ld.so.preload并插入：

/usr/lib/libhardened_malloc.so

尽管大多数应用程序都可以正常工作，但hardened_malloc可能会破坏某些应用程序。建议使用以下选项编译hardened_malloc以最大程度地减少损坏：

CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 CONFIG_GUARD_SLABS_INTERVAL=8

您还应该使用sysctl设置以下内容，以适应hardened_malloc创建的大量保护页：

vm.max_map_count=524240

Whonix项目为基于Debian的发行版提供了hardened_malloc软件包。

强化编译标志

编译自己的程序可以带来很多好处，因为它使您能够优化程序的安全性。但是，执行完全相反的操作并降低安全性很容易，如果您不确定自己在做什么，请跳过本节。在基于源的发行版（例如Gentoo）上，这将是最简单的，但也可以在其他发行版上这样做。

某些编译选项可用于添加其他漏洞利用缓解措施，从而消除整个类别的常见漏洞。您可能听说过常规保护，例如位置独立可执行文件，堆栈粉碎保护程序，立即绑定，只读重定位和FORTIFY_SOURCE，但是本节将不做介绍，因为它们已被广泛采用。相反，它将讨论诸如控制流完整性和影子堆栈之类的现代漏洞利用缓解措施。

本节涉及主要用C或C ++编写的本机程序。您必须使用Clang编译器，因为这些功能在GCC上不可用。请记住，由于未广泛采用这些缓解措施，因此某些应用程序在启用它们后可能无法运行。

控制流完整性（CFI）是一种缓解漏洞利用的方法，旨在防止诸如ROP或JOP之类的代码重用攻击。由于更广泛采用的缓解措施（例如NX）使过时的利用技术过时了，因此使用这些技术利用了很大一部分漏洞。Clang支持细粒度的前沿CFI，这意味着它可以有效缓解JOP攻击。Clang的CFI本身并不能减轻ROP；您还必须使用下面记录的单独机制。要启用此功能，必须应用以下编译标志：

-flto -fvisibility=hidden -fsanitize=cfi

-fsanitize=shadow-call-stack

如果上述ShadowCallStack不是一个选项，则可以选择使用具有相似目标的SafeStack。但是，不幸的是，此功能有许多漏洞，因此效果不甚理想。如果仍然希望启用此功能，则必须应用以下编译标志：

-fsanitize=safe-stack

最常见的内存损坏漏洞之一是未初始化的内存。Clang有一个选项可以使用零或特定模式自动初始化变量。建议将变量初始化为零，因为使用其他模式比利用漏洞缓解功能更适合发现错误。要启用此功能，必须应用以下编译标志：

-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang

但该选项的存在目前正在辩论中。

内存安全语言

Root账户

root可以执行任何操作，并且可以访问您的整个系统。因此，应尽可能将其锁定，以使攻击者无法轻松获得root用户访问权限。

/etc/securetty

/etc/securetty文件指定允许您以root用户身份登录的位置。该文件应保留为空，以便任何人都不能从终端上这样做。

限制su

su可让您从终端切换用户。默认情况下，它尝试以root用户身份登录。要将su的使用限制在wheel组中，请编辑/etc/pam.d/su和/etc/pam.d/su-l并添加：

auth required pam_wheel.so use_uid

您应该在wheel组中拥有尽可能少的用户。

锁定root账户

要锁定root帐户以防止任何人以root身份登录，请执行：

passwd -l root

在执行此操作之前，请确保您具有获取根的替代方法（例如，从活动USB引导并更改为文件系统的chroot），以免您无意中将自己锁定在系统之外。

拒绝通过SSH的远程root登陆

为了防止某人通过SSH以root身份登录，请编辑/etc/ssh/sshd_config并添加：

PermitRootLogin no

增加散列回合数

password required pam_unix.so sha512 shadow nullok rounds=65536

这使shadow执行65536次散列回合。

应用此设置后，密码不会自动重新加密，因此您需要使用以下方法重置密码：

passwd $username

限制Xorg root访问

needs_root_rights = no

安全访问root

恶意软件可以使用多种方法来嗅探root帐户的密码。因此，访问根帐户的传统方式是不安全的，最好根本不访问根，但这实际上是不可行的。本节详细介绍了访问根帐户的最安全方法。在安装操作系统后，应立即应用这些说明，以确保该软件不含恶意软件。

您绝对不能使用普通用户帐户访问root，因为root可能已被盗用。您也不能直接登录到根帐户。通过执行以下操作，创建一个单独的“管理员”用户帐户，该帐户仅用于访问root用户，而不能用于访问其他用户：

useradd admin

执行并来设置一个非常强的密码：

passwd admin

仅允许该帐户使用您首选的权限提升机制。例如，如果使用sudo，则通过执行以下命令来添加sudoers异常：

visudo -f /etc/sudoers.d/admin-account

然后输入：

admin ALL=(ALL) ALL

确保没有其他帐户可以访问sudo（或您的首选机制）

现在，要实际登录到该帐户，请先重新启动-例如，这可以防止受损的窗口管理器执行登录欺骗。当提供登录提示时，请通过按键盘上的以下组合键来激活安全注意键：

Alt + SysRq + k

防火墙

防火墙可以控制传入和传出的网络流量，并且可以用来阻止或允许某些类型的流量。除非有特殊原因，否则应始终阻止所有传入流量。建议设置严格的iptables或nftables防火墙。火墙必须针对您的系统进行微调，并且没有一个适合所有防火墙的规则集。建议您熟悉创建防火墙规则。Arch Wiki[14]和手册页[15]都是很好的资源。

这是基本iptables配置的示例，该配置禁止所有传入的网络流量：

*filter    

:INPUT DROP [0:0]    

:FORWARD DROP [0:0]    

:OUTPUT ACCEPT [0:0]    

:TCP - [0:0]    

:UDP - [0:0]    

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT    

-A INPUT -i lo -j ACCEPT    

-A INPUT -m conntrack --ctstate INVALID -j DROP    

-A INPUT -p udp -m conntrack --ctstate NEW -j UDP    

-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP    

-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable    

-A INPUT -p tcp -j REJECT --reject-with tcp-reset    

-A INPUT -j REJECT --reject-with icmp-proto-unreachable    

COMMIT

但是，您不应尝试在实际系统上使用此示例。它仅适用于某些台式机系统。

身份标识

为了保护隐私，最好最大程度地减少可追溯到您的信息量。

主机名和用户名

请勿在主机名或用户名中添加唯一标识的内容。将它们保留为通用名称，例如“host”和“user”，以便它们无法识别您。

Timezones / Locales / Keymaps

如果可能，应将您的时区设置为“ UTC”，将区域设置和键盘映射设置为“ US”。

机器ID

一个独一无二的机器ID被存储在/var/lib/dbus/machine-id （systemd系统是保存在/etc/machine-id）这些应编辑为通用名称，例如Whonix ID：

b08dfa6083e7567a1921a715000001fb

MAC地址欺骗

MAC地址是分配给网络接口控制器（NIC）的唯一标识符。每次您连接到网络时（WIFI或以太网）则您的MAC地址已暴露。这使人们可以使用它来跟踪您并在本地网络上唯一地标识您。

但您不应该完全随机化MAC地址。拥有完全随机的MAC地址是显而易见的，并且会对您脱颖而出的行为产生不利影响。

MAC地址的OUI（组织唯一标识符）部分标识芯片组的制造商。对MAC地址的这一部分进行随机化处理可能会为您提供以前从未使用过的OUI，数十年来从未使用过的OUI或在您所在的地区极为罕见的OUI，因此使您脱颖而出，很明显地表明您在欺骗MAC地址。

MAC地址的末尾标识您的特定设备，并且可以用来跟踪您的设备。仅对MAC地址的这一部分进行随机化可防止您被跟踪，同时仍使MAC地址看起来可信。

要欺骗这些地址，请首先执行以下命令找出您的网络接口名称：

ip a

接下来，安装macchanger并执行：

macchanger -e $network_interface

要在每次引导时随机分配MAC地址，您应该为您的特定初始化系统创建一个初始化脚本。这是systemd的一个示例：

[Unit]    

Description=macchanger on eth0    

Wants=network-pre.target    

Before=network-pre.target    

BindsTo=sys-subsystem-net-devices-eth0.device    

After=sys-subsystem-net-devices-eth0.device    

  

[Service]    

ExecStart=/usr/bin/macchanger -e eth0    

Type=oneshot    

  

[Install]    

WantedBy=multi-user.target

上面的示例在启动时欺骗了eth0接口的MAC地址。将eth0替换为您的网络接口。

时间攻击

几乎每个系统都有不同的时间。这可用于时钟偏斜指纹攻击，几毫秒的差异足以使用户被暴露识别。

ICMP时间戳

ICMP时间戳会在查询答复中泄漏系统时间。阻止这些攻击的最简单方法是利用防火墙阻止传入连接，或者使内核忽略ICMP请求。

TCP时间戳

TCP时间戳也会泄漏系统时间。内核尝试通过对每个连接使用随机偏移量来解决此问题，但这不足以解决问题。因此应该禁用TCP时间戳，可以通过使用sysctl设置以下内容来完成：

net.ipv4.tcp_timestamps=0

TCP初始化序号

TCP初始序列号（ISN）是泄漏系统时间的另一种方法。为了减轻这种情况，您必须安装tirdad内核模块，该模块会生成用于连接的随机ISN。

时间同步

时间同步对于匿名性和安全性至关重要。错误的系统时钟可能使您遭受时钟偏斜指纹攻击，或者可以用来为您提供过时的HTTPS证书，从而绕过证书到期或吊销。

最流行的时间同步方法NTP是不安全的，因为它未经加密和未经身份验证，因此攻击者可以轻易地拦截和修改请求。NTP还会以NTP时间戳格式泄漏本地系统时间，该格式可用于时钟偏斜指纹识别，如前所述。

因此，您应该卸载所有NTP客户端并禁用systemd-timesyncd（如果正在使用）。您可以通过安全连接（HTTPS或最好是Torion服务）连接到受信任的网站，而不是NTP，并从HTTP标头中提取当前时间。达到此目的的工具是sdwdate或我自己的安全时间同步工具。

按键指纹

可以通过他们在键盘上输入键的方式来对人进行指纹识别。您可以通过键入速度，在两次按键之间的暂停，每次按键被按下和释放的确切时间等方式来唯一地进行指纹识别。可以使用KeyTrac在线进行测试。

Kloak是一种工具，旨在通过混淆按键和释放事件之间的时间间隔来克服这种跟踪方法。当按键被按下时，它会引入随机延迟，然后由应用程序选择。

文件权限

默认情况下，文件的权限是非常宽松的。您应该在整个系统中搜索权限不当的文件和目录，并对其进行限制。例如，在诸如Debian之类的某些发行版中，用户的Home目录是全局可读的。

这可以通过执行以下操作来限制：

chmod 700 /home/$user

另外一些示例是/boot，/usr /src和/ {,usr /} lib/modules 它们包含内核映像，System.map和其他各种文件，所有这些文件都可能泄漏有关内核的敏感信息。

chmod 700 /boot /usr/src /lib/modules /usr/lib/modules

在基于Debian的发行版中，必须使用dpkg-statoverride保留文件许可权。否则，它们将在更新期间被覆盖。

Whonix的SUID Disabler和Permission Hardener[22]会自动应用本节中详细介绍的步骤。

setuid / setgid

Setuid / SUID允许用户使用二进制文件所有者的特权执行二进制文件。这通常用于允许非特权用户使用通常仅为root用户保留的某些功能。因此，许多SUID二进制文件都有特权升级安全漏洞的历史记录。 Setgid / SGID类似，但适用于组而不是用户。要使用setuid或setgid位查找系统上的所有二进制文件，请执行：

find / -type f \( -perm -4000 -o -perm -2000 \)

然后，您应该删除不使用的程序上的所有不必要的setuid / setgid位，或将其替换为功能。要删除setuid位，请执行：

chmod u-s $path_to_program

要删除setgid位，执行：

chmod g-s $path_to_program

要向文件添加功能，请执行：

setcap $capability+ep $path_to_program

或者，要删除不必要的功能，请执行：

setcap -r $path_to_program

umask

umask 0077

核心转储

核心转储包含特定时间（通常是该程序崩溃时）该程序的已记录内存。它们可能包含敏感信息，例如密码和加密密钥，因此必须将其禁用。

禁用它们的方法主要有三种：sysctl，systemd和ulimit

sysctl

通过sysctl设置以下设置：

kernel.core_pattern=|/bin/false

systemd

创建/etc/systemd/coredump.conf.d/disable.conf并添加如下内容：

[Coredump]    

Storage=none

ulimit

编辑/etc/security/limits.conf并添加如下内容：

* hard core 0

setuid进程

即使在进行了这些设置之后，以提升的特权运行的进程仍可能会转储其内存。

为了防止他们这样做，请通过sysctl设置以下内容：

fs.suid_dumpable=0

Swap

与核心转储类似，交换或分页将部分内存复制到磁盘，其中可能包含敏感信息。应该将内核配置为仅在绝对必要时进行交换，相应的sysctl设置：

vm.swappiness=1

PAM

PAM是用于用户身份验证的框架。这就是您登录时使用的机制。您可以通过要求使用强密码或在失败的登录尝试后强制执行延迟验证来使其更加安全。

要强制使用强密码，可以使用pam_pwquality。它强制执行密码的可配置策略。例如，如果您希望密码至少包含16个字符（最小），与旧密码（difok）至少6个不同的字符，至少3个数字（dcredit），至少2个大写字母（ucredit），至少2个字符小写字母（lcredit）和至少3个其他字符（ocredit），然后编辑/etc/pam.d/passwd并添加：

password required pam_pwquality.so retry=2 minlen=16 difok=6 dcredit=-3 ucredit=-2 lcredit=-2 ocredit=-3 enforce_for_root    

password required pam_unix.so use_authtok sha512 shadow

要强制执行延迟验证，可以使用pam_faildelay。要在两次失败的登录尝试之间添加至少4秒的延迟以阻止暴力破解尝试，请编辑/etc/pam.d/system-login并添加：

auth optional pam_faildelay.so delay=4000000

4000000 是4秒（以微秒为单位）。

Microcode更新

Microcode更新对于修复关键的CPU漏洞（如Meltdown和Spectre等）至关重要。大多数发行版都将这些发行版包含在其软件仓库中，例如Arch Linux和Debian。

IPv6隐私扩展

IPv6地址是从计算机的MAC地址生成的，从而使您的IPv6地址是唯一的，并直接绑定到计算机。隐私扩展会生成一个随机的IPv6地址，以减轻这种形式的跟踪。请注意，如果您开启了MAC地址欺骗机制或禁用了IPv6，则无需执行这些步骤。

要启用这些功能，请通过sysctl设置以下设置：

net.ipv6.conf.all.use_tempaddr=2    

net.ipv6.conf.default.use_tempaddr=2

NetworkManager

要为NetworkManager启用隐私扩展，请编辑/etc/NetworkManager/NetworkManager.conf并添加：

[connection]    

ipv6.ip6-privacy=2

systemd-networkd

要为systemd-networkd启用隐私扩展，请创建/etc/systemd/network/ipv6-privacy.conf并添加：

[Network]    

IPv6PrivacyExtensions=kernel

分区和挂载选项

文件系统应分为多个分区，以对其权限进行细粒度控制。可以添加不同的安装选项以限制可以执行的操作：

nodev - 禁止使用设备
nosuid - 禁止setuid或setgid位
noexec - 禁止执行任何二进制文件

这些安装选项应在/etc/fstab中尽可能设置。如果您不能使用单独的分区，请创建绑定挂载。一个更安全的/etc/fstab的示例：

/        /          ext4    defaults                              1 1    

/home    /home      ext4    defaults,nosuid,noexec,nodev          1 2    

/tmp     /tmp       ext4    defaults,bind,nosuid,noexec,nodev     1 2    

/var     /var       ext4    defaults,bind,nosuid                  1 2    

/boot    /boot      ext4    defaults,nosuid,noexec,nodev          1 2

请注意，可以通过shell脚本绕过noexec。

熵

熵基本上反应操作系统信息收集的随机程度，对于诸如加密之类的事情至关重要。因此，最好通过安装其他随机数生成器（如haveged和jitterentropy）从各种来源收集尽可能多的熵。

为了使jitterentropy正确运行，必须通过创建/usr/lib/modules-load.d/jitterentropy.conf并添加以下内容尽早加载内核模块：

jitterentropy_rng

RDRAND

random.trust_cpu=off

以root身份编辑文件

建议不要以root用户身份运行普通的文本编辑器。大多数文本编辑器可以做的不仅仅是简单地编辑文本文件，而且还可以被利用。例如，以root身份打开vi并输入：sh。现在，您具有一个可以访问整个系统的root shell，攻击者可以轻松利用该shell。

解决方案是使用sudoedit。这会将文件复制到一个临时位置，以普通用户身份打开文本编辑器，编辑该临时文件并以root用户身份覆盖原始文件。这样，实际的编辑器就不会以root身份运行。要使用sudoedit，执行：

sudoedit $path_to_file

默认情况下，它使用vi，但是可以通过EDITOR或SUDO_EDITOR环境变量来切换默认编辑器。例如，要使用nano，请执行：

EDITOR=nano sudoedit $path_to_file

可以在/etc/environment中全局设置此环境变量。

特定发行版的安全强化

HTTP包管理器镜像

APT seccomp-bpf

APT::Sandbox::Seccomp "true";

物理安全

全盘加密可确保对驱动器上的所有数据进行加密，并且不会被物理攻击者读取。大多数发行版都支持在安装过程中启用加密，请确保设置了强密码。您也可以使用dm-crypt[28]手动加密驱动器。

请注意，全盘加密不包括/boot，这样仍然可以修改内核、引导加载程序和其他关键文件。为了完全防止篡改，您还必须实施经过验证的引导。

BIOS / UEFI强化

如果您仍在使用旧版BIOS，则应迁移到UEFI，以利用较新的安全功能。大多数BIOS或UEFI实现都支持设置密码。最好启用它并设置一个非常强壮的密码。虽然这是很弱的保护，因为重置密码很简单。它通常存储在易失性内存中，因此攻击者只需要能够卸下CMOS电池几秒钟，或者他们就可以使用某些主板上的跳线将其重置。

您还应该禁用所有未使用的设备和引导选项，例如USB引导，以减少攻击面。

别忽略BIOS或UEFI的更新，确保将其更新。将其与常规操作系统更新一样重要。

此外，请参阅《 NSA的硬件和固件安全指南》。

Bootloader密码

grub-mkpasswd-pbkdf2

输入您的密码，该密码将生成一个字符串。它将类似于“ grub.pbkdf2.sha512.10000.C4009... ”。创建/etc/grub.d/40_password并添加：

set superusers="$username"    

password_pbkdf2 $username $password

用grub-mkpasswd-pbkdf2生成的字符串替换“$username”将用于被允许使用GRUB命令行，编辑菜单项和执行任何菜单项的超级用户。对于大多数人来说，这只是“root”。

重新生成您的配置文件，GRUB现在将受到密码保护。

要仅限制编辑引导参数并访问GRUB控制台，同时仍然允许您引导，请编辑 /boot/grub/grub.cfg并在 “menuentry '$OSName' ”旁边添加“ --unrestricted”参数。

menuentry 'Arch Linux' --unrestricted

您将需要再次重新生成配置文件以应用此更改。

Syslinux

Syslinux可以设置主密码或菜单密码。引导任何条目都需要主密码，而引导特定条目仅需要菜单密码。

要为Syslinux设置主密码，请编辑/boot/syslinux/syslinux.cfg并添加：

MENU MASTER PASSWD $password

要设置菜单密码，请编辑/boot/syslinux/syslinux.cfg，并在带有您要密码保护的项目的标签内，添加：

MENU PASSWD $password

将“ $password”替换为您要设置的密码。

这些密码可以是纯文本，也可以使用MD5，SHA-1，SHA-256或SHA-512进行散列。建议先使用强哈希算法（例如SHA-256或SHA-512）对密码进行哈希处理，以避免将其存储为明文形式。

systemd-boot

systemd-boot具有防止在引导时编辑内核参数的选项。在loader.conf文件中，添加：

editor no

systemd-boot并不正式支持保护内核参数编辑器的密码，但是您可以使用systemd-boot-password来实现[30]。

验证引导

经过验证的引导通过密码验证来确保引导链和基本系统的完整性。这可用于确保物理攻击者无法修改设备上的软件。

如果没有经过验证的引导，则一旦获得物理访问权限，就可以轻松绕过上述所有预防措施。经过验证的引导不仅像许多人认为的那样是为了物理安全。它还可以用于防止远程恶意软件持久化——如果攻击者设法破坏了整个系统并获得了很高的特权，则经过验证的引导将在重新引导后还原其更改，并确保它们无法持久化。

经过验证的最常见的引导实现是UEFI安全引导，但是它本身并不是一个完整的实现，因为它仅会验证引导加载程序和内核，这意味着可以通过以下方法：

仅UEFI安全启动就没有一成不变的信任根，因此物理攻击者仍然可以刷新设备的固件。为了减轻这种情况，请结合使用UEFI安全启动和Intel Boot Guard或AMD Secure Boot。
远程攻击者（或不使用加密的物理攻击者）可以简单地修改操作系统的任何其他特权部分。例如，如果他们有修改内核的特权，那么他们也可以修改/sbin/init来有效地获得相同的结果。因此，仅验证内核和引导加载程序不会对远程攻击者产生任何影响。为了减轻这种情况，您必须使用dm-verity[31]验证基本操作系统，尽管由于传统Linux发行版的布局，这非常困难且笨拙。

通常，很难在传统Linux上实现可靠的经过验证的引导实现。

USBs

USB设备为物理攻击提供了重要的攻击面。例如BadUSB和Stuxnet是此类攻击的范例。最佳实践是禁止所有新连接的USB且仅将受信任设备列入白名单，USBGuard对此非常有用。

您也可以将nousb用作内核引导参数，以禁用内核中的所有USB支持。可以sysctl设置kernel.deny_new_usb=1

DMA攻击

直接内存访问（DMA）攻击涉及通过插入某些物理设备来完全访问所有系统内存。这可以通过控制设备可访问的内存区域的IOMMU或将特别易受攻击的内核模块列入黑名单来缓解。

要启用IOMMU，请设置以下内核引导参数：

intel_iommu=on amd_iommu=on

您只需要为特定的CPU制造商启用该选项，但同时启用这两个选项就没有问题。

efi=disable_early_pci_dma

通过在非常早的启动过程中禁用所有PCI桥接器上的busmaster位，此选项可修复上述IOMMU中的漏洞。

此外，Thunderbolt和FireWire通常容易受到DMA攻击。要禁用它们，请将这些内核模块列入黑名单：

install firewire-core /bin/false    

install thunderbolt /bin/false

冷启动攻击

当攻击者在擦除RAM中的数据之前对其进行分析时，就会发生冷启动攻击。使用现代RAM时，冷启动攻击不太实用，因为RAM通常会在几秒钟或几分钟内清除，除非将其放入冷却液（如液氮或冷冻机）中。攻击者必须在几秒钟内将设备中的RAM棒拔出并将其暴露于液氮中，而且确保用户不会注意到。

如果冷启动攻击是威胁模型的一部分，请在关机后保护计算机几分钟，以确保没有人可以访问您的RAM记忆棒。您也可以将RAM棒焊接到主板上，以使其更难以卡住。如果使用笔记本电脑，请取出电池，然后直接用充电电缆供电。关机后请拔出电缆，以确保RAM彻底断电无法访问。

在内核自我保护启动参数部分中，空闲时内存清零选项将用零覆盖内存中的敏感数据。此外，强化的内存分配器可以通过CONFIG_ZERO_ON_FREE配置选项清除用户空间堆内存中的敏感数据。尽管如此，某些数据仍可能保留在内存中。

此外，现代内核还包括复位攻击缓解措施，该命令可命令固件在关机时擦除数据，尽管这需要固件支持。

确保正常关闭计算机，以使上述缓解措施可以开始。

如果以上都不适用您的威胁模型，则可以实施Tails的内存擦除过程，该过程将擦除大部分内存（视频内存除外），并且已被证明是有效的。

最佳实践

一旦对系统进行了尽可能多的加固，就应该遵循良好的隐私和安全性惯例：

禁用或删除不需要的东西以最小化攻击面。
保持更新。配置cron任务或init脚本以每天更新系统。
不要泄漏有关您或您的系统的任何信息，无论它看起来多么渺小。
遵循常规的安全和隐私建议

尽管已经进行了强化，但您必须记住Linux仍然是一个有缺陷的操作系统，没有任何强化可以完全修复它。

其他指南

您应该进行尽可能多的研究，而不要依赖单一的信息来源。最大的安全问题之一就是用户。这些是我认为有价值的其他指南的链接：

Arch Linux Security wiki page： https://wiki.archlinux.org/index.php/Security

Whonix Documentation： https://www.whonix.org/wiki/Documentation

NSA RHEL 5 Hardening Guide(稍有过时，但仍包含有用的信息）： https://apps.nsa.gov/iaarchive ... e.cfm

KSPP recommended kernel settings： https://kernsec.org/wiki/index ... tings

kconfig-hardened-check： https://github.com/a13xp0p0v/k ... heck/

术语

grub-mkconfig -o $path_to_grub_config

"$path_to_grub_config" 取决于您如何设置系统。它通常是/boot/grub/grub.cfg或/boot/EFI/grub/grub.cfg，但是在执行此命令之前，请务必确保正确。

另外，在Debian或Ubuntu等发行版上，您应该执行以下命令：

update-grub

能力

Linux上TCP的几个内核参数调优 - 无毁的湖光-Al - 博客园

Wed, 22 Jul 2020 10:28:44 CST

Linux作为一个强大的操作系统，提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中，笔者积累了一些在内网环境应该进行调优的参数。在此分享出来，希望对大家有所帮助。

调优清单

好了，在这里先列出调优清单。请记住，这里只是笔者在内网进行TCP内核参数调优的经验，仅供参考。同时，笔者还会在余下的博客里面详细解释了为什么要进行这些调优！

序号	内核参数	值	备注
1.1	/proc/sys/net/ipv4/tcp_max_syn_backlog	2048
1.2	/proc/sys/net/core/somaxconn	2048
1.3	/proc/sys/net/ipv4/tcp_abort_on_overflow	1
2.1	/proc/sys/net/ipv4/tcp_tw_recycle	0	NAT环境必须为0
2.2	/proc/sys/net/ipv4/tcp_tw_reuse	1
3.1	/proc/sys/net/ipv4/tcp_syn_retries	3
3.2	/proc/sys/net/ipv4/tcp_retries2	5
3.3	/proc/sys/net/ipv4/tcp_slow_start_after_idle	0

tcp_max_syn_backlog,somaxconn,tcp_abort_on_overflow

tcp_max_syn_backlog,somaxconn,tcp_abort_on_overflow这三个参数是关于
内核TCP连接缓冲队列的设置。如果应用层来不及将已经三次握手建立成功的TCP连接从队列中取出,溢出了这个缓冲队列(全连接队列)之后就会丢弃这个连接。如下图所示:

从而产生一些诡异的现象,这个现象诡异之处就在于，是在TCP第三次握手的时候丢弃连接

就如图中所示,第二次握手的SYNACK发送给client端了。所以就会出现client端认为连接成功，而Server端确已经丢弃了这个连接的现象！由于无法感知到Server已经丢弃了连接。
所以如果没有心跳的话，只有在发出第一个请求后，Server才会发送一个reset端通知这个连接已经被丢弃了，建立连接后第二天再用，也会报错！所以我们要调大Backlog队列！

      echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2048 > /proc/sys/net/core/somaxconn

当然了，为了尽量避免第一笔调用失败问题，我们也同时要设置

      echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow

设置这个值以后，Server端内核就会在这个连接被溢出之后发送一个reset包给client端。

如果我们的client端是NIO的话，就可以收到一个socket close的事件以感知到连接被关闭！

注意Java默认的Backlog是50

这个TCP Backlog的队列大小值是min(tcp_max_syn_backlog,somaxconn,应用层设置的backlog),而Java如果不做额外设置，Backlog默认值仅仅只有50。C语言在使用listen调用的时候需要传进Backlog参数。

tcp_tw_recycle

tcp_tw_recycle这个参数一般是用来抑制TIME_WAIT数量的,但是它有一个副作用。即在tcp_timestamps开启(Linux默认开启)，tcp_tw_recycle会经常导致下面这种现象。

也即，如果你的Server开启了tcp_tw_recycle，那么别人如果通过NAT之类的调用你的Server的话，NAT后面的机器只有一台机器能正常工作，其它情况大概率失败。具体原因呢由下图所示:

在tcp_tw_recycle=1同时tcp_timestamps(默认开启的情况下),对同一个IP的连接会做这样的限制，也即之前后建立的连接的时间戳必须要大于之前建立连接的最后时间戳，但是经过NAT的一个IP后面是不同的机器，时间戳相差极大，就会导致内核直接丢弃时间戳较低的连接的现象。由于这个参数导致的问题，高版本内核已经去掉了这个参数。如果考虑TIME_WAIT问题，可以考虑设置一下

      echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

tcp_syn_retries

这个参数值得是client发送SYN如果server端不回复的话，重传SYN的次数。对我们的直接影响呢就是connet建立连接时的超时时间。当然Java通过一些C原生系统调用的组合使得我们可以进行超时时间的设置。在Linux里面默认设置是5,下面给出建议值3和默认值5之间的超时时间。

tcp_syn_retries	timeout
1	min(so_sndtimeo,3s)
2	min(so_sndtimeo,7s)
3	min(so_sndtimeo,15s)
4	min(so_sndtimeo,31s)
5	min(so_sndtimeo,63s)

下图给出了，重传和超时情况的对应图:

当然了，不同内核版本的超时时间可能不一样，因为初始RTO在内核小版本间都会有细微的变化。所以，有时候在抓包时候可能会出现（3,6,12......)这样的序列。当然Java的API有超时时间:

      java:
 // 函数调用中携带有超时时间
 public void connect(SocketAddress endpoint, int timeout) ;

所以，对于Java而言，这个内核参数的设置没有那么重要。但是，有些代码可能会有忘了设置timeout的情况，例如某个版本的Kafka就是，所以它在我们一些混沌测试的情况下，容灾恢复的时间会达到一分多钟，主要时间就是卡在connect上面-_-!，而这时我们的tcp_syn_retries设置的是5，也即超时时间63s。减少这个恢复时间的手段就是:

      echo 3 > /proc/sys/net/ipv4/tcp_syn_retries

tcp_retries2

tcp_retries2这个参数表面意思是在传输过程中tcp的重传次数。但在某个版本之后Linux内核仅仅用这个tcp_retries2来计算超时时间，在这段时间的重传次数纯粹由RTO等环境因素决定，重传超时时间在5/15下的表现为:

tcp_retries2	对端无响应
5	25.6s-51.2s根据动态rto定
15	924.6s-1044.6s根据动态rto定

如果我们在应用层设置的Socket所有ReadTimeout都很小的话(例如3s),这个内核参数调整是没有必要的。但是，笔者经常发现有的系统，因为一两个慢的接口或者SQL，所以将ReadTimeout设的很大的情况。

平常这种情况是没有问题的，因为慢请求频率很低，不会对系统造成什么风险。但是，物理机突然宕机时候的情况就不一样了，由于ReadTimeOut设置的过大，导致所有落到这台宕机的机器都会在min(ReadTimeOut,(924.6s-1044.6s)(Linux默认tcp_retries2是15))后才能从read系统调用返回。假设ReadTimeout设置了个5min，系统总线程数是200，那么只要5min内有200个请求落到宕机的server就会使A系统失去响应！

但如果将tcp_retries2设置为5,那么超时返回时间即为min(ReadTimeOut 5min,25.6-51.2s),也就是30s左右，极大的缓解了这一情况。

      echo 5 > /proc/sys/net/ipv4/tcp_retries2

但是针对这种现象，最好要做资源上的隔离,例如线程上的隔离或者机器级的隔离。

golang的goroutine调度模型就可以很好的解决线程资源不够的问题，但缺点是goroutine里面不能有阻塞的系统调用，不然也会和上面一样，但仅仅对于系统之间互相调用而言，都是非阻塞IO,所以golang做微服务还是非常Nice的。当然了我大Java用纯IO事件触发编写代码也不会有问题，就是对心智负担太高-_-!

物理机突然宕机和进程宕不一样

值得注意的是，物理机宕机和进程宕但内核还存在表现完全不一样。

仅仅进程宕而内核存活，那么内核会立马发送reset给对端，从而不会卡住A系统的线程资源。

tcp_slow_start_after_idle

还有一个可能需要调整的参数是tcp_slow_start_after_idle，Linux默认是1，即开启状态。开启这个参数后，我们的TCP拥塞窗口会在一个RTO时间空闲之后重置为初始拥塞窗口(CWND)大小，这无疑大幅的减少了长连接的优势。对应Linux源码为:

      static void tcp_event_data_sent(struct tcp_sock *tp,
				struct sk_buff *skb, struct sock *sk){
	// 如果开启了start_after_idle,而且这次发送的时间-上次发送的时间>一个rto，就重置tcp拥塞窗口
	if (sysctl_tcp_slow_start_after_idle &&
	    (!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
		tcp_cwnd_restart(sk, __sk_dst_get(sk));
}

关闭这个参数后，无疑会提高某些请求的传输速度(在带宽够的情况下)。

      echo 0 > /proc/sys/net/ipv4/tcp_slow_start_after_idle

当然了，Linux启用这个参数也是有理由的，如果我们的网络情况是时刻在变化的，例如拿个手机到处移动，那么将拥塞窗口重置确实是个不错的选项。但是就我们内网系统间调用而言，是不太必要的了。

初始CWND大小

毫无疑问，新建连接之后的初始TCP拥塞窗口大小也直接影响到我们的请求速率。在Linux2.6.32源码中，其初始拥塞窗口是(2-4个)mss大小，对应于内网估计也就是(2.8-5.6K)(MTU 1500)，这个大小对于某些大请求可能有点捉襟见肘。
在Linux 2.6.39以上或者某些RedHat维护的小版本中已经把CWND
增大到RFC 6928所规定的的10段，也就是在内网里面估计14K左右(MTU 1500)。

      Linux 新版本
/* TCP initial congestion window */
#define TCP_INIT_CWND		10

总结

Linux提供了一大堆内参参数供我们进行调优，其默认设置的参数在很多情况下并不是最佳实践，所以我们需要潜心研究，找到最适合当前环境的组合。

TCP CLOSE_WAIT 过多解决方案-Smurf Linux运维-51CTO博客

Sat, 27 Jun 2020 10:51:47 CST

一、“多半是程序的原因”？这个还是交给程序猿吧

二、linux 下 CLOSE_WAIT过多的解决方法

情景描述：系统产生大量“Too many open files”

原因分析：在服务器与客户端通信过程中，因服务器发生了socket未关导致的closed_wait发生，致使监听port打开的句柄数到了1024个，且均处于close_wait的状态，最终造成配置的port被占满出现“Too many open files”，无法再进行通信。

close_wait状态出现的原因是被动关闭方未关闭socket造成

解决办法：有两种措施可行

一、解决：

原因是因为调用ServerSocket类的accept()方法和Socket输入流的read()方法时会引起线程阻塞，所以应该用setSoTimeout()方法设置超时（缺省的设置是0，即超时永远不会发生）；超时的判断是累计式的，一次设置后，每次调用引起的阻塞时间都从该值中扣除，直至另一次超时设置或有超时异常抛出。

比如，某种服务需要三次调用read()，超时设置为1分钟，那么如果某次服务三次read()调用的总时间超过1分钟就会有异常抛出，如果要在同一个Socket上反复进行这种服务，就要在每次服务之前设置一次超时。

二、规避：

调整系统参数，包括句柄相关参数和TCP/IP的参数；

注意：

/proc/sys/fs/file-max 是整个系统可以打开的文件数的限制，由sysctl.conf控制；

ulimit修改的是当前shell和它的子进程可以打开的文件数的限制，由limits.conf控制；

lsof是列出系统所占用的资源,但是这些资源不一定会占用打开文件号的；比如：共享内存,信号量,消息队列,内存映射等,虽然占用了这些资源,但不占用打开文件号；

因此，需要调整的是当前用户的子进程打开的文件数的限制，即limits.conf文件的配置；

如果cat /proc/sys/fs/file-max值为65536或甚至更大，不需要修改该值；

若ulimit -a ；其open files参数的值小于4096（默认是1024), 则采用如下方法修改open files参数值为8192；方法如下：

1.使用root登陆，修改文件/etc/security/limits.conf

vim /etc/security/limits.conf

添加

xxx - nofile 8192

xxx 是一个用户，如果是想所有用户生效的话换成 * ，设置的数值与硬件配置有关，别设置太大了。

#<domain>     <type>   <item>       <value>
*         soft    nofile    8192 
*         hard    nofile    8192

#所有的用户每个进程可以使用8192个文件描述符。

2.使这些限制生效

确定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行：

session required pam_limits.so

然后用户重新登陆一下即可生效。

3. 在bash下可以使用ulimit -a 参看是否已经修改：

一、修改方法：（暂时生效,重新启动服务器后,会还原成默认值）

sysctl -w net.ipv4.tcp_keepalive_time=600   
sysctl -w net.ipv4.tcp_keepalive_probes=2 
sysctl -w net.ipv4.tcp_keepalive_intvl=2

注意：Linux的内核参数调整的是否合理要注意观察，看业务高峰时候效果如何。

二、若做如上修改后，可起作用；则做如下修改以便永久生效。

vi /etc/sysctl.conf

若配置文件中不存在如下信息，则添加：

net.ipv4.tcp_keepalive_time = 1800 
net.ipv4.tcp_keepalive_probes = 3 
net.ipv4.tcp_keepalive_intvl = 15

编辑完 /etc/sysctl.conf,要重启network 才会生效

/etc/rc.d/init.d/network restart

然后，执行sysctl命令使修改生效，基本上就算完成了。

------------------------------------------------------------

修改原因：

当客户端因为某种原因先于服务端发出了FIN信号，就会导致服务端被动关闭，若服务端不主动关闭socket发FIN给Client，此时服务端Socket会处于CLOSE_WAIT状态（而不是LAST_ACK状态）。通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（系统默认超时时间的是7200秒，也就是2小时）。如果服务端程序因某个原因导致系统造成一堆CLOSE_WAIT消耗资源，那么通常是等不到释放那一刻，系统就已崩溃。因此，解决这个问题的方法还可以通过修改TCP/IP的参数来缩短这个时间，于是修改tcp_keepalive_*系列参数：

tcp_keepalive_time：

/proc/sys/net/ipv4/tcp_keepalive_time

INTEGER，默认值是7200(2小时)

当keepalive打开的情况下，TCP发送keepalive消息的频率。建议修改值为1800秒。

tcp_keepalive_probes：INTEGER

/proc/sys/net/ipv4/tcp_keepalive_probes

INTEGER，默认值是9

TCP发送keepalive探测以确定该连接已经断开的次数。(注意:保持连接仅在SO_KEEPALIVE套接字选项被打开是才发送.次数默认不需要修改,当然根据情形也可以适当地缩短此值.设置为5比较合适)

tcp_keepalive_intvl：INTEGER

/proc/sys/net/ipv4/tcp_keepalive_intvl

INTEGER，默认值为75

当探测没有确认时，重新发送探测的频度。探测消息发送的频率（在认定连接失效之前，发送多少个TCP的keepalive探测包）。乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。(对于普通应用来说,这个值有一些偏大,可以根据需要改小.特别是web类服务器需要改小该值,15是个比较合适的值)

1. 系统不再出现“Too many open files”报错现象。

2. 处于TIME_WAIT状态的sockets不会激长。

在 Linux 上可用以下语句看了一下服务器的TCP状态(连接状态数量统计)：

netstat -n| awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

redis进程OOM被linux内核kill问题调查 - 简书

Mon, 15 Jun 2020 07:54:52 CST

【发现问题】

运维人员收到zabbix告警说codis集群usa-9节点所在机器，原swap 4G 空间只剩下80k。其立即登录该机器增加了约6G的swap空间。

    Lack of free swap space on USARN-H-Host-Linux-172.24.19.59: PROBLEM (Value: 80 KB) 2019.11.13 14:47:34

接着收到某个应用的500错误告警，错误堆栈里提到codis该usa-9节点 “JedisConnectionException: Unexpected end of stream”，再次登录usa-9拿到 linux的系统日志如下：

    Nov 13 14:56:19 vm-centos6 kernel: codis-server invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Nov 13 14:56:19 vm-centos6 kernel: codis-server cpuset=/ mems_allowed=0
Nov 13 14:56:19 vm-centos6 kernel: Pid: 4492, comm: codis-server Not tainted 2.6.32-504.el6.x86_64 #1
Nov 13 14:56:19 vm-centos6 kernel: Call Trace:
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff810d40c1>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff81127300>] ? dump_header+0x90/0x1b0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8122ea2c>] ? security_real_capable_noaudit+0x3c/0x70
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff81127782>] ? oom_kill_process+0x82/0x2a0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff811276c1>] ? select_bad_process+0xe1/0x120
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff81127bc0>] ? out_of_memory+0x220/0x3c0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff811344df>] ? __alloc_pages_nodemask+0x89f/0x8d0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8116c69a>] ? alloc_pages_current+0xaa/0x110
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff811246f7>] ? __page_cache_alloc+0x87/0x90
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff811240de>] ? find_get_page+0x1e/0xa0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff81125697>] ? filemap_fault+0x1a7/0x500
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8114eae4>] ? __do_fault+0x54/0x530
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8114f0b7>] ? handle_pte_fault+0xf7/0xb00
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff814470e1>] ? sock_aio_read+0x1a1/0x1b0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff810a2bbb>] ? __remove_hrtimer+0x3b/0xb0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8114fcea>] ? handle_mm_fault+0x22a/0x300
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff811d68e0>] ? ep_send_events_proc+0x0/0x110
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8104d0d8>] ? __do_page_fault+0x138/0x480
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8152ffbe>] ? do_page_fault+0x3e/0xa0
Nov 13 14:56:19 vm-centos6 kernel: [<ffffffff8152d375>] ? page_fault+0x25/0x30
Nov 13 14:56:19 vm-centos6 kernel: Mem-Info:
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA per-cpu:
Nov 13 14:56:19 vm-centos6 kernel: CPU    0: hi:    0, btch:   1 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    1: hi:    0, btch:   1 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    2: hi:    0, btch:   1 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    3: hi:    0, btch:   1 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA32 per-cpu:
Nov 13 14:56:19 vm-centos6 kernel: CPU    0: hi:  186, btch:  31 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    1: hi:  186, btch:  31 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    2: hi:  186, btch:  31 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: CPU    3: hi:  186, btch:  31 usd:   0
Nov 13 14:56:19 vm-centos6 kernel: Node 0 Normal per-cpu:
Nov 13 14:56:19 vm-centos6 kernel: CPU    0: hi:  186, btch:  31 usd:  35
Nov 13 14:56:19 vm-centos6 kernel: CPU    1: hi:  186, btch:  31 usd:   3
Nov 13 14:56:19 vm-centos6 kernel: CPU    2: hi:  186, btch:  31 usd:  59
Nov 13 14:56:19 vm-centos6 kernel: CPU    3: hi:  186, btch:  31 usd: 184
Nov 13 14:56:19 vm-centos6 kernel: active_anon:4040530 inactive_anon:451920 isolated_anon:0
Nov 13 14:56:19 vm-centos6 kernel: active_file:3492 inactive_file:4985 isolated_file:0
Nov 13 14:56:19 vm-centos6 kernel: unevictable:0 dirty:2037 writeback:1387 unstable:0
Nov 13 14:56:19 vm-centos6 kernel: free:35841 slab_reclaimable:2943 slab_unreclaimable:7727
Nov 13 14:56:19 vm-centos6 kernel: mapped:296 shmem:73 pagetables:13459 bounce:0
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA free:15668kB min:52kB low:64kB high:76kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15276kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Nov 13 14:56:19 vm-centos6 kernel: lowmem_reserve[]: 0 3000 18150 18150
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA32 free:71556kB min:11160kB low:13948kB high:16740kB active_anon:2063844kB inactive_anon:519380kB active_file:656kB inactive_file:1132kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3072160kB mlocked:0kB dirty:660kB writeback:0kB mapped:120kB shmem:0kB slab_reclaimable:628kB slab_unreclaimable:68kB kernel_stack:0kB pagetables:204kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2688 all_unreclaimable? yes
Nov 13 14:56:19 vm-centos6 kernel: lowmem_reserve[]: 0 0 15150 15150
Nov 13 14:56:19 vm-centos6 kernel: Node 0 Normal free:56140kB min:56364kB low:70452kB high:84544kB active_anon:14098276kB inactive_anon:1288300kB active_file:13312kB inactive_file:18808kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15513600kB mlocked:0kB dirty:7488kB writeback:5548kB mapped:1064kB shmem:292kB slab_reclaimable:11144kB slab_unreclaimable:30840kB kernel_stack:2184kB pagetables:53632kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:52256 all_unreclaimable? yes
Nov 13 14:56:19 vm-centos6 kernel: lowmem_reserve[]: 0 0 0 0
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA: 1*4kB 2*8kB 2*16kB 2*32kB 1*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15668kB
Nov 13 14:56:19 vm-centos6 kernel: Node 0 DMA32: 2308*4kB 391*8kB 210*16kB 146*32kB 62*64kB 37*128kB 26*256kB 22*512kB 18*1024kB 3*2048kB 0*4096kB = 71592kB
Nov 13 14:56:19 vm-centos6 kernel: Node 0 Normal: 756*4kB 706*8kB 494*16kB 330*32kB 170*64kB 89*128kB 21*256kB 3*512kB 0*1024kB 0*2048kB 0*4096kB = 56320kB
Nov 13 14:56:19 vm-centos6 kernel: 65997 total pagecache pages
Nov 13 14:56:19 vm-centos6 kernel: 57354 pages in swap cache
Nov 13 14:56:19 vm-centos6 kernel: Swap cache stats: add 46466585, delete 46409231, find 15690882/21869217
Nov 13 14:56:19 vm-centos6 kernel: Free swap  = 0kB
Nov 13 14:56:19 vm-centos6 kernel: Total swap = 4063228kB
Nov 13 14:56:19 vm-centos6 kernel: 4718576 pages RAM
Nov 13 14:56:19 vm-centos6 kernel: 117970 pages reserved
Nov 13 14:56:19 vm-centos6 kernel: 9305 pages shared
Nov 13 14:56:19 vm-centos6 kernel: 4551285 pages non-shared
Nov 13 14:56:19 vm-centos6 kernel: [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
Nov 13 14:56:19 vm-centos6 kernel: [  514]     0   514     2729        1   1     -17         -1000 udevd
Nov 13 14:56:19 vm-centos6 kernel: [  837]     0   837     2729        1   1     -17         -1000 udevd
Nov 13 14:56:19 vm-centos6 kernel: [ 1272]     0  1272    62838      313   3       0             0 vmtoolsd
Nov 13 14:56:19 vm-centos6 kernel: [ 1310]     0  1310    15023        6   2       0             0 VGAuthService
Nov 13 14:56:19 vm-centos6 kernel: [ 1386]     0  1386    23283       40   0     -17         -1000 auditd
Nov 13 14:56:19 vm-centos6 kernel: [ 1406]     0  1406    62464      692   2       0             0 rsyslogd
Nov 13 14:56:19 vm-centos6 kernel: [ 1436]     0  1436     4589       36   0       0             0 irqbalance
Nov 13 14:56:19 vm-centos6 kernel: [ 1452]    32  1452     4744       18   2       0             0 rpcbind
Nov 13 14:56:19 vm-centos6 kernel: [ 1472]    29  1472     5837        2   0       0             0 rpc.statd
Nov 13 14:56:19 vm-centos6 kernel: [ 1589]    81  1589     5394       47   2       0             0 dbus-daemon
Nov 13 14:56:19 vm-centos6 kernel: [ 1621]     0  1621     1020        1   0       0             0 acpid
Nov 13 14:56:19 vm-centos6 kernel: [ 1631]    68  1631     9521      162   2       0             0 hald
Nov 13 14:56:19 vm-centos6 kernel: [ 1632]     0  1632     5099        2   1       0             0 hald-runner
Nov 13 14:56:19 vm-centos6 kernel: [ 1664]     0  1664     5629        2   3       0             0 hald-addon-inpu
Nov 13 14:56:19 vm-centos6 kernel: [ 1674]    68  1674     4501        2   0       0             0 hald-addon-acpi
Nov 13 14:56:19 vm-centos6 kernel: [ 1689]     0  1689     2728        1   3     -17         -1000 udevd
Nov 13 14:56:19 vm-centos6 kernel: [ 1695]     0  1695    96534       43   1       0             0 automount
Nov 13 14:56:19 vm-centos6 kernel: [ 1823]     0  1823    20332       28   0       0             0 master
Nov 13 14:56:19 vm-centos6 kernel: [ 1846]    89  1846    20398       24   2       0             0 qmgr
Nov 13 14:56:19 vm-centos6 kernel: [ 1849]     0  1849    28661        2   3       0             0 abrtd
Nov 13 14:56:19 vm-centos6 kernel: [ 1862]     0  1862    29342       24   2       0             0 crond
Nov 13 14:56:19 vm-centos6 kernel: [ 1876]     0  1876     5394        7   0       0             0 atd
Nov 13 14:56:19 vm-centos6 kernel: [ 1889]     0  1889    19879        2   0       0             0 login
Nov 13 14:56:19 vm-centos6 kernel: [ 1891]     0  1891     1016        2   3       0             0 mingetty
Nov 13 14:56:19 vm-centos6 kernel: [ 1893]     0  1893     1016        2   0       0             0 mingetty
Nov 13 14:56:19 vm-centos6 kernel: [ 1895]     0  1895     1016        2   2       0             0 mingetty
Nov 13 14:56:19 vm-centos6 kernel: [ 1897]     0  1897     1016        2   0       0             0 mingetty
Nov 13 14:56:19 vm-centos6 kernel: [ 1899]     0  1899     1016        2   1       0             0 mingetty
Nov 13 14:56:19 vm-centos6 kernel: [ 1996]     0  1996   521256       57   0       0             0 console-kit-dae
Nov 13 14:56:19 vm-centos6 kernel: [ 2063]     0  2063    27076        2   1       0             0 bash
Nov 13 14:56:19 vm-centos6 kernel: [29526]     0 29526    25812       47   1       0             0 ping
Nov 13 14:56:19 vm-centos6 kernel: [ 4492]     0  4492  6354569  4432393   1       0             0 codis-server
Nov 13 14:56:19 vm-centos6 kernel: [25500]     0 25500   133214      139   0       0             0 SFTMonitor
Nov 13 14:56:19 vm-centos6 kernel: [25501]     0 25501   222155      168   1       0             0 SFTServer
Nov 13 14:56:19 vm-centos6 kernel: [19596]     0 19596    16672       22   2     -17         -1000 sshd
Nov 13 14:56:19 vm-centos6 kernel: [26159]   500 26159     4441       10   3       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26161]   500 26161     4441      132   0       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26162]   500 26162     4441       49   0       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26163]   500 26163     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26164]   500 26164     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26165]   500 26165     4441       49   0       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26166]   500 26166     4441       49   0       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26167]   500 26167     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26168]   500 26168     4441       49   3       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26169]   500 26169     4441       49   1       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26170]   500 26170     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26171]   500 26171     4441       49   0       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26172]   500 26172     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26174]   500 26174     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [26175]   500 26175     4441       49   2       0             0 zabbix_agentd
Nov 13 14:56:19 vm-centos6 kernel: [23868]    38 23868     7683       44   2       0             0 ntpd
Nov 13 14:56:19 vm-centos6 kernel: [ 3221]    89  3221    20352      231   2       0             0 pickup
Nov 13 14:56:19 vm-centos6 kernel: [ 3463]     0  3463    24592      291   2       0             0 sshd
Nov 13 14:56:19 vm-centos6 kernel: [ 3466]     0  3466    27087      145   0       0             0 bash
Nov 13 14:56:19 vm-centos6 kernel: [ 3490]     0  3490    26297       51   0       0             0 dd
Nov 13 14:56:19 vm-centos6 kernel: Out of memory: Kill process 4492 (codis-server) score 941 or sacrifice child
Nov 13 14:56:19 vm-centos6 kernel: Killed process 4492, UID 0, (codis-server) total-vm:25418276kB, anon-rss:17729176kB, file-rss:396kB
//这是运维收到机器原4G swap只剩80k告警时，立即去增加了约6G swap空间产生的日志，但redis进程已经在20秒前被kill掉了
Nov 13 14:56:39 vm-centos6 kernel: Adding 5999996k swap on /home/swap/swapfile.  Priority:-2 extents:8 across:6499708k

【分析问题】

redis实例被系统内核关闭掉了，系统日志最重要的就是一头一尾两句：

    codis-server invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Killed process 4492, UID 0, (codis-server) total-vm:25418276kB, anon-rss:17729176kB, file-rss:396kB

redis进程申请4K内存空间时（order=0所以是2^0页也就是4k），系统内存不足触发了oom-killer，最后被选中kill的就是redis进程自己。
参考 https://www.jianshu.com/p/c2e7d36829af的内存结构，mask(0x201da)的最低2位 "10"=2是会Allocate from ZONE_HIGHMEM，但在64位系统中是没有highmem区的，实际是从normal区请求内存。从日志得知“Node 0 Normal free:56140kB min:56364kB”，normal区当前可用56140kB小于最低限制56364kB，由此触发的oom-killer。

codis-monitor监控对该节点的内存使用告警阈值为65%，maxmemory=12G，所以在K-V使用内存到 12G * 65% = 7.8G 时会发出告警。但节点被kill时并没有发出告警，也就是说K-V使用的内存还不到 7.8G，机器总内存 18G swap区当时 4G，没有别的什么进程能消耗内存。
从日志可以看到“anon-rss:17729176kB”，redis节点被关闭时占用内存约16.9G，一边说redis占用内存16.9G耗光了内存导致OOM，一边说redis的K-V数据量不超过7.8G。
于是调查anon-rss的含义，RSS是说从操作系统角度来看分配给进程的内存。又核对codis-monitor的65%是怎么设置的，原来是针对info命令打印出来的 used_memory 实际K-V数据所使用内存，info命令还有 used_memory_rss 字段表示操作系统分配给redis所占用的内存，used_memory_rss 能大于 used_memory 表示内存碎片率即另一个字段 mem_fragmentation_ratio。

至此理解阈值告警的used_memory字段和系统层面分配的used_memory_rss字段后，可以得知这两个现象描述的是不同维度的事情，初步猜测是内存碎片过大，导致redis总占用内存超过机器内存总量，先于K-V存储数据达到告警阈值。

【验证问题】

由于该usa-9节点redis已重启无法追溯问题现场，于是遍历了usa集群的其他redis节点来验证初步猜测。
1）usa-2节点

    [root@usa-idc-micen-codis-app2 ~]# top -c
 PID USER      PR  NI  VIRT  RES  SHR S   %CPU   %MEM    TIME+    COMMAND                                                                                                                                                                         
4498 root      20   0 26.9g  17g    884 S      4.3        96.9   23255:49  /opt/xyz/codis202/bin/codis-server *:8998

    [root@usa-idc-micen-codis-app2 ~]# free -m
                       total       used        free     shared   buffers   cached
Mem:                   17971      17784        187       0         8        19
-/+ buffers/cache:     17755        215
Swap:                   3967       2553       1414

    xxx.xxx.xxx.xxx:8998> info
# Memory
used_memory_human:6.63G
used_memory_rss_human:17.00G
mem_fragmentation_ratio:2.57

2）usa-4节点

    [root@usa-idc-micen-codis-app4 log]# top -c
  PID USER      PR  NI  VIRT    RES    SHR   S     %CPU    %MEM    TIME+     COMMAND                                                                                                                                                                         
 9297 root      20   0   11.2g   10g   1076   S       3.0          59.5     1780:23   /opt/xyz/codis202/bin/codis-server *:8998

    [root@usa-idc-micen-codis-app4 log]# free -m
                        total       used       free     shared    buffers     cached
Mem:                    17971      17751        219        0        138        5184
-/+ buffers/cache:      12429       5542
Swap:                    3967        631        3336

    xxx.xxx.xxx.xxx:8998> info
# Memory
used_memory_human:7.63G
used_memory_rss_human:10.44G
mem_fragmentation_ratio:1.37

3）usa-1节点

    [root@usa-idc-micen-codis-app1 ~]# top -c
 PID  USER    PR  NI   VIRT   RES   SHR  S   %CPU   %MEM    TIME+     COMMAND                                                                                                                                                                         
4617 root      20   0   29.8g  15g   876   S      3.0       89.8     22864:35   /opt/xyz/codis202/bin/codis-server *:8998

    [root@usa-idc-micen-codis-app1 ~]# free -m
                      total       used         free     shared    buffers     cached
Mem:                  17971       17813        158        0         30         97
-/+ buffers/cache:    17685        285
Swap:                 11780        4239       7541

    xxx.xxx.xxx.xxx:8998> info
# Memory
used_memory_human:6.61G
used_memory_rss_human:15.74G
mem_fragmentation_ratio:2.38

总结：
1）usa-2节点状况最接近OOM的usa-9节点，K-V数据存储6.63G但包含内存碎片的总内存占用17G，内存碎片惊人的达到了10G以上，相当于存储6G数据但浪费10G内存不可用，碎片率2.57远远超过业界建议的1.5。间接验证了usa-9节点是因为内存碎片过大，总占用内存达到物理内存上限，申请新内存页失败导致OOM。
2）top命令查看到的进程常驻内存RES，应该就是info命令查看到的redis包含碎片的占用内存used_memory_rss，也即是内核日志kill时的清理出来的内存anon-rss。
3）除了usa-4节点状况健康：碎片率1.37低于1.5、剩余内存5G、swap区几乎没用，其他节点碎片量和碎片率过大、内存剩余无几、swap区大量使用。尤其是usa-2节点离OOM不远，但其能在悬崖边游走而没有掉下去，是因为上面提到的K-V存储内存65%阈值告警对redis所做的保护只读不写，让包含碎片的总占用内存没有超过物理内存总量，但usa-9节点就没这么好运。

【解决问题】

1）保守治疗就是让redis节点不容易OOM。一是增加swap区加大物理内存耗尽的容忍度，降低触发oom-killer的机会；二是调低K-V存储告警阈值从65%到60%让保护提前生效，从而降低包含碎片的内存占用总量超过物理内存的风险。
2）有效治疗就是清理内存碎片，redis4.0之后具备了清理能力，但目前使用的redis3.2只能通过关机重启，加入新机器节点逐步迁移slot，迁移完成之后关闭重启旧节点。困难有三个：一是缺乏自动运维手段，逐个slot手工迁移费时；二是之前缺乏项目组对redis的使用约束，里面会存放有大key，迁移这些slot时带来的停顿项目组可不会接受；三是缺乏使用约束，项目组很可能把redis当db使用，这些被重度使用的slot所在节点会有master-slave保证高可用（几乎都不开持久化），如果迁移slot时在缺乏新的slave备份的情况下出现redis挂掉数据丢失，项目组完全无法接受。
3）长期治疗就是降低内存碎片，要求项目组对使用到的所有key补上TTL，一小时或一星期都行，让过期key能被清理，从而降低内存使用量和内存碎片量。但完全没项目组认领的key，只能暂时留在redis内，后期用脚本遍历对没有TTL的key补默认TTL。

【思考问题】

1）内存碎片是如何产生的？
可以确定的是频繁的对key set新值。比如整数集合（intSet）数据结构，假设以连续int16空间存储多个小整数，一旦加入一个2字节以上的大整数时，所有小整数都会升级成int32或int64的空间，之后再把这个大整数删除，所有小整数可不会降级回到int16，于是有一半以上的内存空间被浪费了。另外假设set keyA 1m_str，之后再set keyA int_val，空余出来的内存是否能释放，有待验证。

【待思考项】

1）redis启用持久化时，fork子进程需要同redis进程相等的内存空间（实际上copy-on-write不会真使用完全一样多的内存空间），如果只分配45%物理内存给redis进程，剩余留给持久化子进程可不划算。所以推荐的是打开内核参数 vm.overcommit_memory = 1，让分配内存空间给fork子进程时，由swap区来担保分配。redis启动日志也能看到这条警告：

    # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

vm.overcommit_memory 默认是0，也就是说redis进程申请内存只能从物理剩余内存中申请，不会去使用swap区。那top命令查看usa-2节点显示的VIRT=26.9g是怎么计算出来的？

Linux Namespace 浅析

Tue, 14 Jan 2020 00:00:00 CST

目前Linux内核总共支持以下6种Namespace：

IPC：隔离System V IPC和POSIX消息队列。
Network：隔离网络资源。
Mount：隔离文件系统挂载点。
PID：隔离进程ID。
UTS：隔离主机名和域名。
User：隔离用户ID和组ID。

Linux对Namespace的操作，主要是通过clone、setns和unshare这3个系统调用来完成的，clone创建新进程时，接收一个叫flags的参数，这些flag包括 CLONE_NEWNS、CLONE_NEWIPC、CLONE_NEWUTS、CLONE_NEWNET（Mount namespace）、CLONE_NEWPID和 CLONE_NEWUSER，用于创建新的namespace，这样clone创建出来新进程之后就属于新的namespace了，后续新进程创建的进程默认属于同一namespace。

如果想要给已存在进程设置新的namespace，可通过unshare函数（ long unshare(unsigned long flags)）完成设置，其入参flags表示新的namespace。当想要给已存在进程设置已存在的namespace，可通过setns函数（ int setns(int fd, int nstype)）来完成设置，每个进程在procfs目录下存储其相关的namespace信息，可找到已存在的namesapce，然后通过setns设置即可：

  [root@centos ~]# ls -l /proc/10401/ns   
总用量 0   
lrwxrwxrwx 1 root root 0 1月  12 11:36 ipc -> ipc:[4026531839]   
lrwxrwxrwx 1 root root 0 1月  12 11:36 mnt -> mnt:[4026531840]   
lrwxrwxrwx 1 root root 0 1月  12 11:36 net -> net:[4026531956]   
lrwxrwxrwx 1 root root 0 1月  12 11:36 pid -> pid:[4026531836]   
lrwxrwxrwx 1 root root 0 1月  12 11:36 user -> user:[4026531837]   
lrwxrwxrwx 1 root root 0 1月  12 11:36 uts -> uts:[4026531838]

上述每个虚拟文件对应该进程所处的namespace，如果其他进程想进入该namespace，open该虚拟文件获取到fd，然后传给setns函数的fd入参即可，注意虚拟文件type和nstype要对应上。

目前Linux内核总共支持以下6种Namespace，分别是IPC、Network、Mount、PID、UTS、User：

IPC

IPC也就是进程间通信，Linux下有多种进程间通信，比如socket、共享内存、Posix消息队列和SystemV IPC等，这里的IPC namespace针对的是SystemV IPC和Posix消息队列，其会用标识符表示不同的消息队列，进程间通过找到标识符对应的消息队列来完成通信，IPC namespace做的事情就是相同的标识符在不同namespace上对应不同的消息队列，这样不同namespace的进程无法完成进程间通信。

Network

Network Namespace隔离网络资源，每个Network Namespace都有自己的网络设备、IP地址、路由表、/proc/net目录、端口号等。每个Network Namespace会有一个loopback设备（除此之外不会有任何其他网络设备）。因此用户需要在这里面做自己的网络配置。IP工具已经支持Network Namespace，可以通过它来为新的Network Namespace配置网络功能。

Mount

Mount namesapce用户隔离文件系统挂载点，每个进程能看到的文件系统都记录在/proc/xx/mounts里。在创建了一个新的Mount Namespace后，进程系统对文件系统挂载/卸载的动作就不会影响到其他Namespace。

PID

PID Namespace用于隔离进程PID号，这样一来，不同的Namespace里的进程PID号就可以是一样的了。当创建一个PID Namespace时，第一个进程的PID号是1，也就是init进程。init进程有一些特殊之处，例如init进程需要负责回收所有孤儿进程的资源。另外，发送给init进程的任何信号都会被屏蔽，即使发送的是SIGKILL信号，也就是说，在容器内无法“杀死”init进程。

注意，但是当用ps命令查看系统的进程时，会发现竟然可以看到host的所有进程：

这是因为ps命令是从procfs读取信息的，而procfs并没有得到隔离。虽然能看到这些进程，但由于它们其实是在另一个PID Namespace中，因此无法向这些进程发送信号。

UTS

UTS Namespace用于对主机名和域名进行隔离，也就是uname系统调用使用的结构体structutsname里的nodename和domainname这两个字段，UTS这个名字也是由此而来的。为什么需要uts namespace呢，因为为主机名可以用来代替IP地址，比如局域网通过主机名访问机器。

User

User Namespace用来隔离用户资源，比如一个进程在Namespace里的用户和组ID与它在host里的ID可以不一样，这样可以做到，一个host的普通用户可以在该容器（user namespace）下拥有root权限，但是它的特权被限定在容器内。（容器内的这类root用户，实际上还是有很多特权操作不能执行，基本上如果这个特权操作会影响到其他容器或者host，就不会被允许）

小结

一般namespace都是和cgroup结合来使用的，但是直接操作Namespace和Cgroup并不是很容易，因此docker的出现就显得有必要了，Docker通过Libcontainer来处理这些底层的事情。这样一来，Docker只需要简单地调用Libcontainer的API，就能将完整的容器搭建起来。而作为Docker的用户，就更不用操心这些事情了，只需要通过一两条简单的Docker命令启动容器即可。

如何排查 Linux 机器是否已经被入侵？

Wed, 10 Jul 2019 08:00:00 CST

背景信息：以下情况是在CentOS 6.9的系统中查看的，其它Linux发行版类似。

1 .入侵者可能会删除机器的日志信息，可以查看日志信息是否还存在或者是否被清空，相关命令示例：

2.入侵者可能创建一个新的存放用户名及密码文件，可以查看/etc/passwd及/etc/shadow文件，相关命令示例：

3.入侵者可能修改用户名及密码文件，可以查看/etc/passwd及/etc/shadow文件内容进行鉴别，相关命令示例：

4.查看机器最近成功登陆的事件和最后一次不成功的登陆事件，对应日志“/var/log/lastlog”，相关命令示例：

5.查看机器当前登录的全部用户，对应日志文件“/var/run/utmp”，相关命令示例：

6.查看机器创建以来登陆过的用户，对应日志文件“/var/log/wtmp”，相关命令示例：

7.查看机器所有用户的连接时间（小时），对应日志文件“/var/log/wtmp”，相关命令示例：

8.如果发现机器产生了异常流量，可以使用命令“tcpdump”抓取网络包查看流量情况或者使用工具”iperf”查看流量情况。

9.可以查看/var/log/secure日志文件，尝试发现入侵者的信息，相关命令示例：

10.查询异常进程所对应的执行脚本文件

a.top命令查看异常进程对应的PID

b.在虚拟文件系统目录查找该进程的可执行文件

11.如果确认机器已经被入侵，重要文件已经被删除，可以尝试找回被删除的文件。

当进程打开了某个文件时，只要该进程保持打开该文件，即使将其删除，它依然存在于磁盘中。这意味着，进程并不知道文件已经被删除，它仍然可以向打开该文件时提供给它的文件描述符进行读取和写入。除了该进程之外，这个文件是不可见的，因为已经删除了其相应的目录索引节点。

在/proc 目录下，其中包含了反映内核和进程树的各种文件。/proc目录挂载的是在内存中所映射的一块区域，所以这些文件和目录并不存在于磁盘中，因此当我们对这些文件进行读取和写入时，实际上是在从内存中获取相关信息。大多数与 lsof 相关的信息都存储于以进程的 PID 命名的目录中，即 /proc/1234 中包含的是 PID 为 1234 的进程的信息。每个进程目录中存在着各种文件，它们可以使得应用程序简单地了解进程的内存空间、文件描述符列表、指向磁盘上的文件的符号链接和其他系统信息。lsof 程序使用该信息和其他关于内核内部状态的信息来产生其输出。所以lsof 可以显示进程的文件描述符和相关的文件名等信息。也就是我们通过访问进程的文件描述符可以找到该文件的相关信息。

当系统中的某个文件被意外地删除了，只要这个时候系统中还有进程正在访问该文件，那么我们就可以通过lsof从/proc目录下恢复该文件的内容。

假设入侵者将/var/log/secure文件删除掉了，尝试将/var/log/secure文件恢复的方法可以参考如下：

a.查看/var/log/secure文件，发现已经没有该文件。

b.使用lsof命令查看当前是否有进程打开/var/log/secure，

c.从上面的信息可以看到 PID 1264（rsyslogd）打开文件的文件描述符为4。同时还可以看到/var/log/ secure已经标记为被删除了。因此我们可以在/proc/1264/fd/4（fd下的每个以数字命名的文件表示进程对应的文件描述符）中查看相应的信息，如下：

d.从上面的信息可以看出，查看/proc/1264/fd/4就可以得到所要恢复的数据。如果可以通过文件描述符查看相应的数据，那么就可以使用I/O重定向将其重定向到文件中，如：

e.再次查看/var/log/secure，发现该文件已经存在。对于许多应用程序，尤其是日志文件和数据库，这种恢复删除文件的方法非常有用。

linux 启动流程分析

Thu, 27 Jun 2019 08:00:00 CST

今天，一起探讨操作系统的启动流程。

这个部分比较有意思。因为在BIOS阶段，计算机的行为基本上被写死了，程序员可以做的事情并不多；但是，一旦进入操作系统，程序员几乎可以定制所有方面。所以，这个部分与程序员的关系更密切。

我主要关心的是Linux操作系统，它是目前服务器端的主流操作系统。下面的内容针对的是Debian发行版，因为我对其他发行版不够熟悉。

加载内核

操作系统接管硬件以后，首先读入 /boot 目录下的内核文件。

以我的电脑为例，/boot 目录下面大概是这样一些文件：

启动初始化进程

内核文件加载以后，就开始运行第一个程序 /sbin/init，它的作用是初始化系统环境。

由于init是第一个运行的程序，它的进程编号（pid）就是1。其他所有进程都从它衍生，都是它的子进程。

确定运行级别

许多程序需要开机启动。它们在Windows叫做"服务"（service），在Linux就叫做"守护进程"（daemon）。

init进程的一大任务，就是去运行这些开机启动的程序。但是，不同的场合需要启动不同的程序，比如用作服务器时，需要启动Apache，用作桌面就不需要。Linux允许为不同的场合，分配不同的开机启动程序，这就叫做"运行级别"（runlevel）。也就是说，启动时根据"运行级别"，确定要运行哪些程序。

Linux预置七种运行级别（0-6）。一般来说，0是关机，1是单用户模式（也就是维护模式），6是重启。运行级别2-5，各个发行版不太一样，对于Debian来说，都是同样的多用户模式（也就是正常模式）。

init进程首先读取文件 /etc/inittab，它是运行级别的设置文件。如果你打开它，可以看到第一行是这样的：

initdefault的值是2，表明系统启动时的运行级别为2。如果需要指定其他级别，可以手动修改这个值。

那么，运行级别2有些什么程序呢，系统怎么知道每个级别应该加载哪些程序呢？......回答是每个运行级别在/etc目录下面，都有一个对应的子目录，指定要加载的程序。

上面目录名中的"rc"，表示run command（运行程序），最后的d表示directory（目录）。下面让我们看看 /etc/rc2.d 目录中到底指定了哪些程序。

可以看到，除了第一个文件README以外，其他文件名都是"字母S+两位数字+程序名"的形式。字母S表示Start，也就是启动的意思（启动脚本的运行参数为start），如果这个位置是字母K，就代表Kill（关闭），即如果从其他运行级别切换过来，需要关闭的程序（启动脚本的运行参数为stop）。

后面的两位数字表示处理顺序，数字越小越早处理，所以第一个启动的程序是motd，然后是rpcbing、nfs......数字相同时，则按照程序名的字母顺序启动，所以rsyslog会先于sudo启动。

这个目录里的所有文件（除了README），就是启动时要加载的程序。如果想增加或删除某些程序，不建议手动修改 /etc/rcN.d 目录，最好是用一些专门命令进行管理（参考这里和这里）。

加载开机启动程序

前面提到，七种预设的"运行级别"各自有一个目录，存放需要开机启动的程序。不难想到，如果多个"运行级别"需要启动同一个程序，那么这个程序的启动脚本，就会在每一个目录里都有一个拷贝。这样会造成管理上的困扰：如果要修改启动脚本，岂不是每个目录都要改一遍？

Linux的解决办法，就是七个 /etc/rcN.d 目录里列出的程序，都设为链接文件，指向另外一个目录 /etc/init.d ，真正的启动脚本都统一放在这个目录中。init进程逐一加载开机启动程序，其实就是运行这个目录里的启动脚本。

下面就是链接文件真正的指向。

这样做的另一个好处，就是如果你要手动关闭或重启某个进程，直接到目录 /etc/init.d 中寻找启动脚本即可。比如，我要重启Apache服务器，就运行下面的命令：

/etc/init.d 这个目录名最后一个字母d，是directory的意思，表示这是一个目录，用来与程序 /etc/init 区分。

用户登录

开机启动程序加载完毕以后，就要让用户登录了。

一般来说，用户的登录方式有三种：

这三种情况，都有自己的方式对用户进行认证。

（1）命令行登录：init进程调用getty程序（意为get teletype），让用户输入用户名和密码。输入完成后，再调用login程序，核对密码（Debian还会再多运行一个身份核对程序/etc/pam.d/login）。如果密码正确，就从文件 /etc/passwd 读取该用户指定的shell，然后启动这个shell。

（2）ssh登录：这时系统调用sshd程序（Debian还会再运行/etc/pam.d/ssh ），取代getty和login，然后启动shell。

（3）图形界面登录：init进程调用显示管理器，Gnome图形界面对应的显示管理器为gdm（GNOME Display Manager），然后用户输入用户名和密码。如果密码正确，就读取/etc/gdm3/Xsession，启动用户的会话。

进入login shell

所谓shell，简单说就是命令行界面，让用户可以直接与操作系统对话。用户登录时打开的shell，就叫做login shell。

Debian默认的shell是Bash，它会读入一系列的配置文件。上一步的三种情况，在这一步的处理，也存在差异。

（1）命令行登录：首先读入 /etc/profile，这是对所有用户都有效的配置；然后依次寻找下面三个文件，这是针对当前用户的配置。

需要注意的是，这三个文件只要有一个存在，就不再读入后面的文件了。比如，要是 ~/.bash_profile 存在，就不会再读入后面两个文件了。

（2）ssh登录：与第一种情况完全相同。

（3）图形界面登录：只加载 /etc/profile 和 ~/.profile。也就是说，~/.bash_profile 不管有没有，都不会运行。

打开non-login shell

老实说，上一步完成以后，Linux的启动过程就算结束了，用户已经可以看到命令行提示符或者图形界面了。但是，为了内容的完整，必须再介绍一下这一步。

用户进入操作系统以后，常常会再手动开启一个shell。这个shell就叫做 non-login shell，意思是它不同于登录时出现的那个shell，不读取/etc/profile和.profile等配置文件。

non-login shell的重要性，不仅在于它是用户最常接触的那个shell，还在于它会读入用户自己的bash配置文件 ~/.bashrc。大多数时候，我们对于bash的定制，都是写在这个文件里面的。

你也许会问，要是不进入 non-login shell，岂不是.bashrc就不会运行了，因此bash 也就不能完成定制了？事实上，Debian已经考虑到这个问题了，请打开文件 ~/.profile，可以看到下面的代码：

上面代码先判断变量 $BASH_VERSION 是否有值，然后判断主目录下是否存在 .bashrc 文件，如果存在就运行该文件。第三行开头的那个点，是source命令的简写形式，表示运行某个文件，写成"source ~/.bashrc"也是可以的。

因此，只要运行～/.profile文件，～/.bashrc文件就会连带运行。但是上一节的第一种情况提到过，如果存在～/.bash_profile文件，那么有可能不会运行～/.profile文件。解决这个问题很简单，把下面代码写入.bash_profile就行了。

这样一来，不管是哪种情况，.bashrc都会执行，用户的设置可以放心地都写入这个文件了。

Bash的设置之所以如此繁琐，是由于历史原因造成的。早期的时候，计算机运行速度很慢，载入配置文件需要很长时间，Bash的作者只好把配置文件分成了几个部分，阶段性载入。系统的通用设置放在 /etc/profile，用户个人的、需要被所有子进程继承的设置放在.profile，不需要被继承的设置放在.bashrc。

顺便提一下，除了Linux以外， Mac OS X 使用的shell也是Bash。但是，它只加载.bash_profile，然后在.bash_profile里面调用.bashrc。而且，不管是ssh登录，还是在图形界面里启动shell窗口，都是如此。

IT瘾linux推荐

接近九成 Windows 游戏能在 Linux 上运行

保护核心资产: LINUX内核防护

Linux系统中负载较高问题排查思路与解决方法 - 朝明 - 博客园

一、Load分析：

情况1：CPU高、Load高

情况2：CPU低、Load高

二、CPU高、Load高情况分析

2.1、使用 vmstat 查看系统纬度的 CPU 负载

2.1、使用 top 查看进程纬度的 CPU 负载

2.2、strace命令分析

三、CPU低、Load高情况分析

Linux 下如何查找木马并处理 - ericyuan - 博客园

linux下模拟一个木马程序运行过程

Linux 系统安全检查

Linux的root密码恢复

theme: condensed-night-purple

恢复root密码

centos恢复密码

redhat恢复密码

Linux网络丢包排查 - 墨天轮

Linux丢包故障的解决与思路 - Albert的博客 | Albert's Blog

Linux丢包故障的解决与思路

前言

一、问题现象

二、名词解释

三、排查过程

3.1、丢包的可能性

3.2 、确认有 UDP 丢包发生

3.2 、确认网卡或者驱动丢包

3.3 、UDP 报文错误丢包

3.4 、UDP buffer size 不足丢包

3.5 、系统负载过高丢包

3.6 、应用丢包

3.7 、包丢在什么地方

3.8 、关于UDP丢包的总结

3.9、防火墙拦截

3.10、连接跟踪表溢出

3.11、Ring Buffer溢出

3.12 netdev_max_backlog溢出

3.13、反向路由过滤

3.14 半连接队列溢出

3.15 PAWS

3.16 怎么知道为什么数据包被丢弃

dropwatch

perf

扩展阅读

结论

Linux主机性能测试方法

背景

硬盘

设备查询

hdparm

dd

写性能

读性能

小结

网络

speedtest

iperf3

CPU&内存

sysbench

md5sum

Cortex-A72（ARM）

Neoverse-N1（ARM）

Intel(R) Xeon(R) Platinum 8171M CPU @ 2.60GHz（x86_64）

Intel(R) Xeon(R) CPU E5-26xx v4（x86_64）

Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz（x86_64）

参考资料

【Linux】解决可恶的 “NIC Link is Down”_从善若水的博客-CSDN博客

文章目录

可恶的 “NIC Link is Down”

怎样解决 “NIC Link is Down”

1. 检查网线是否有问题

2. 可能是 e1000e网卡驱动的bug

3. NIC出了问题

4. Switch Port 出了问题

5. 尝试更新你的BIOS && 开启ASPM模式

6. 关闭 流控（flow control）

7. 更换主板与板载网卡和CPU🚑

6. 关闭流控（flow control）