这里写目录标题
1 深入理解 Linux 文件系统
1.inode和block概述
2.inode的内容
3.inode的号码
4.inode的大小
2硬链接与软链接
1 硬链接
2软连接
3EX类型文件恢复
1编译安装 extundelete
2模拟删除并执行恢复操作
4 分析日志文件
4.1 主要日志文
4.2日志文件分析
1内核及系统日志
2用户日志
3程序日志
1深入理解Linux文件系统
在处理 Linux 系统出现的各种故障时,故障的症状是最易发现的,而导致这一故障的原因才是最终排除故障的关键。熟悉 Linux 系统中常见的日志文件,了解一般故障的分析与解决办法,将有助于管理员快速定位故障点、“对症下药”、并及时解决各种系统问题。另外, Linux 系统中通过分区、格式化来创建文件系统,而文件系统的运行又与 block 和 inode 有关。
操作系统的文件数据除了实际内容之外,通常含有非常多的属性,例如 Linux 操作系统的文件权限(rwx)与文件属性(所有者、群组、时间参数等)。文件系统通常会将这两部分内容分别存放在 inode 和 block 中。
1.inode和block*概述
文件是存储在硬盘上的,硬盘的最小存储单位叫做“扇区”(sector),每个扇区存储 512字节。操作系统读取硬盘的时候,不会一个个扇区地读取,这样效率太低,而是一次性连续读取多个扇区,即一次性读取一个"块"(block)。这种由多个扇区组成的"块",是文件存取的最小单位。"块"的大小,最常见的是 4KB,即连续八个 sector 组成一个 block。
文件数据存储在“块”中,那么还必须找到一个地方存储文件的元信息,比如文件的创建者、文件的创建日期、文件的大小等等。这种存储文件元信息的区域就叫做 inode,中文译名为“索引节点”,也叫 i 节点。因此,一个文件必须占用一个 inode,但至少占用一个 block
2.inode的内容
inode 包含很多的文件元信息,但不包含文件名,例如:
*文件的字节数
*文件拥有者的 UserID
*文件的 GroupID
*文件的读、写、执行权限
*文件的时间戳
…
使用 stat 命令即可查看某个文件的 inode 信息。
[root@localhost ~]# stat anaconda-ks.cfg
File: ‘anaconda-ks.cfg’
Size: 1424 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 100663363 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-11-07 03:28:01.914327950 -0500
Modify: 2018-11-07 06:45:44.506987401 -0500
Change: 2018-11-07 06:45:44.506987401 -0500
Birth: -
Linux 系统文件有三个主要的时间属性,分别是ctime(change time), atime(access time), mtime(modify time)。
*ctime(change time) 是最后一次改变文件或目录(属性)的时间,例如执行 chmod, chown 等命令;
*atime(access time)是最后一次访问文件或目录的时间;
*mtime(modify time)是最后一次修改文件或目录(内容)的时间。
刚才提到 inode 中并不包括文件名,其实文件名是存放在目录当中的。
每个 inode 都有一个号码,操作系统用 inode 号码来识别不同的文件,Linux 系统内部不使用文件名,而使用 inode 号码来识别文件。对于用户来说,文件名只是 inode 号码便于识别的别称。
3.inode的号码
用户在访问文件时,表面上是用户通过文件名来打开文件,而实际系统内部的过程分成 以下三步:
*系统找到这个文件名对应的 inode 号码;
*通过 inode 号码,获取 inode 信息;
*根据 inode 信息,找到文件数据所在的 block,并读出数据。
常见的查看 inode 号码的方式有两种:
*ls -i 命令:直接查看文件名所对应的 inode 号码;
*stat 命令:通过查看文件 inode 信息而查看到 inode 号码。
[root@localhost ~]# stat anaconda-ks.cfg
File: ‘anaconda-ks.cfg’
Size: 1424 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode:100663363 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2018-11-07 03:28:01.914327950 -0500
Modify: 2018-11-07 06:45:44.506987401 -0500
Change: 2018-11-07 06:45:44.506987401 -0500
Birth: -
[root@localhost ~]#ls -i anaconda-ks.cfg 100663363 anaconda-ks.cfg
所以,当用户在 Linux 系统中试图访问一个文件时,系统会先根据文件名去查找它对应的 inode,看该用户是否具有访问这个文件的权限。如果有,就指向相对应的数据 block, 如果没有,就返回 Permission denied。
4.inode的大小
inode 也会消耗硬盘空间,所以格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是 inode 区,存放 inode 所包含的信息。每个 inode 的大小,一般是 128 字节或 256 字节。通常情况下不需要关注单个 inode 的大小,而是需要重点关注 inode 总数。inode 的总数在格式化时就给定了,执行“df -i”命令即可查看每个硬盘分区对应的的 inode 总数和已经使用的 inode 数量。
[root@localhost ~]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mapper/cl-root 26214400 38240 26176160 1% /
| devtmpfs | 230666 | 422 | 230244 | 1% /dev |
| ---------------------------- | ----------- | -------------- | ------ | ----------------- |
| tmpfs | 233411 | 1 | 233410 | 1% /dev/shm |
| tmpfs | 233411 | 516 | 232895 | 1% /run |
| tmpfs | 233411 | 16 | 233395 | 1% /sys/fs/cgroup |
| /dev/sda1 | 524288 | 330 | 523958 | 1% /boot |
| /dev/mapper/cl-home 24637440 | 7 24637433 | 1% /home | | |
| tmpfs 233411 | 1 233410 | 1% /run/user/0 | | |
由于 inode 号码与文件名分离,导致一些 Unix/Linux 系统具备以下几种特有的现象。
*文件名包含特殊字符,可能无法正常删除。这时直接删除 inode,能够起到删除文件的作用;
*移动文件或重命名文件,只是改变文件名,不影响 inode 号码;
*打开一个文件以后,系统就以 inode 号码来识别这个文件,不再考虑文件名。
2硬链接与软链接*
在 Linux 系统下的链接文件有两种,一种类似于 Windows 的快捷方式功能的文件,可以快速连接到目标文件或目录,称之为软链接;另一种则是通过文件系统的 inode 链接来产生的新文件名,而不是产生新文件,称之为硬链接。
1 硬链接
一般情况下,文件名和 inode 号码是一一对应关系,每个 inode 号码对应一个文件名。但是 Linux 系统允许多个文件名指向同一个 inode 号码。这意味着,可以用不同的文件名访问同样的内容。ln 命令可以创建硬链接,命令的基本格式为:
ln 源文件 目标
运行该命令以后,源文件与目标文件的 inode 号码相同,都指向同一个 inode。inode
信息中的“链接数”这时就会增加 1 。
当一个文件拥有多个硬链接时,对文件内容修改,会影响到所有文件名;但是删除一个文件名,不影响另一个文件名的访问。删除一个文件名,只会使得 inode 中的"链接数"减 1。需要注意的是不能对目录做硬链接。
通过 mkdir 命令创建一个新目录/app/kgc,其硬链接数应该有 2 个,因为常见的目录本身为 1 个硬链接,而目录 kgc 下面的隐藏目录.(点号)是该目录的又一个硬链接,也算是1 个连接数。
[root@localhost ~]# mkdir -p /app/kgc
[root@localhost ~]# ls -ld /app/kgc/
drwxr-xr-x 2 root root 6 Nov 7 01:40 /app/kgc/
2 软链接
软链接就是再创建一个独立的文件,而这个文件会让数据的读取指向它连接的那个文件 的文件名。例如,文件 A 和文件 B 的 inode 号码虽然不一样,但是文件 A 的,内容是文件B 的路径。读取文件 A 时,系统会自动将访问者导向文件 B。这时,文件 A 就称为文件 B 的“软链接”(soft link)或者“符号链接(symbolic link)。
这意味着,文件 A 依赖于文件 B 而存在,如果删除了文件 B,打开文件 A 就会报错。这是软链接与硬链接最大的不同:文件 A 指向文件 B 的文件名,而不是文件 B 的 inode 号码,文件 B 的 inode“链接数”不会因此发生变化。
软链接的创建命令的基本格式为:
ln -s 源文件或目录 目标文件或目录
3EX类型文件恢复
删除一个文件,实际上并不清除 inode 节点和 block 的数据,只是在这个文件的父目录里面的 block 中,删除这个文件的名字。Linux 是通过 Link 的数量来控制文件删除的,只有当一个文件不存在任何 Link 的时候,这个文件才会被删除。
在 Linux 系统运维工作中,经常会遇到因操作不慎、操作错误等导致文件数据丢失的情况,尤其对于客户企业中一些新手。当然,这里所指的是彻底删除,即已经不能通过“回收站”找回的情况,比如使用“rm -rf”来删除数据。针对 Linux 下的 EXT 文件系统,可用的恢复工具有 debugfs、ext3grep、extundelete 等。 其中 extundelete 是一个开源的 Linux 数据恢复工具,支持 ext3、ext4 文件系统。
在数据被误删除后,第一时间要做的就是卸载被删除数据所在的分区,如果是根分区的 数据遭到误删,就需要将系统进入单用户模式,并且将根分区以只读模式挂载。这样做的原 因很简单,因为将文件删除后,仅仅是将文件的 inode 节点中的扇区指针清零,实际文件还存储在磁盘上,如果磁盘继续以读写模式挂载,这些已删除的文件的数据块就可能被操作系
统重新分配出去,在这些数据库被新的数据覆盖后,这些数据就真的丢失了,恢复工具也回 天无力。所以以只读模式挂载磁盘可以尽量降低数据库中数据被覆盖的风险,以提高恢复数 据成功的比例。
下面将介绍使用 extundelete 工具如何恢复误删除的文件。
1编译安装 extundelete
在编译安装extundelete 之前需要先安装两个依赖包e2fsprogs-libs 和e2fsprogs-devel, 这两个包在系统安装光盘的/Package 目录下就有,使用 rpm 或 yum 命令将其安装。e2fsprogs-devel 安装依赖于 libcom_err-devel 包。
安装完依赖包之后,即可将提前上传的 extundelete 软件包解压、配置、编译、安装。
[root@localhost ~]# yum -y install e2fsprogs-devel e2fsprogs-libs\
[root@localhost ~]# wget[http://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar.](http://nchc.dl.sourceforge.net/project/extundelete/extundelete/0.2.4/extundelete-0.2.4.tar) bz2
[root@localhost ~]# tar -xf extundelete-0.2.4.tar.bz2
[root@localhost ~]# cd extundelete-0.2.4
[root@localhost extundelete-0.2.4]# ./configure --prefix=/usr/local/extundelete&& make && make install
Configuring extundelete 0.2.4 Writing generated files to disk make -s all-recursive
Making all in src
extundelete.cc: In function ‘ext2_ino_t find_inode(ext2_filsys, ext2_filsys, ext2_inode*, std::string, int)’:
extundelete.cc:1272:29: warning: narrowing conversion of ‘search_flags’ from ‘int’ to ‘ext2_ino_t
{aka unsigned int}’ inside { } [-Wnarrowing] buf, match_name2, priv, 0};
^
Making install in src
/usr/bin/install -c extundelete '/usr/local/extundelete/bin'
[root@localhost extundelete-0.2.4]# ln -s /usr/local/extundelete/bin /usr/bin/
2模拟删除并执行恢复操作
使用 fdisk 命令创建新分区,将其挂载到/tmp 目录下,往该目录下新建一些文件或目录。
[root@localhost ~]# mkdir /test/
[root@localhost ~]# mount /dev/sdb1 /test/
[root@localhost ~]# cd /test/
[root@localhost test]# echo a>a
[root@localhost test]# echo a>b
[root@localhost test]# echo a>c
[root@localhost test]# echo a>d
[root@localhost test]# ls
a b c d lost+found
执行完命令‘extundelete /dev/sdb1”后输入”y“即可查看该文件系统的使用情况。
也可以使用“extundelete /dev/sdb1 --inode 2”查看文件系统/dev/sdb1 下存在哪些文件, 具体的使用情况。其中–inode 2 代表从 i 节点为 2 的文件开始查看,一般文件系统格式化挂载之后,i 节点是从 2 开始的,2 代表该文件系统最开始的目录。
模拟误操作并恢复*
使用"rm -rf a b"命令删除/tmp/下的 a 文件和 b 文件,当出现误操作时,立刻卸载该文件系统,然后使用“extundelete /dev/sdb1 --restore-all"恢复/dev/sdb1 文件系统下的所有内容。
root@localhost test]# rm -rf a b
[root@localhost test]# ls c d lost+found
[root@localhost test]# cd
[root@localhost ~]# umount /test/
[root@localhost ~]# extundelete /dev/sdb1 --restore-all
NOTICE: Extended attributes are not restored. Loading filesystem metadata ... 160 groups loaded. Loading journal descriptors ... 26 descriptors loaded. Searching for recoverable inodes in directory / ...
2 recoverable inodes found.
Looking through the directory structure for deleted files ...
0 recoverable inodes still lost.
执行完恢复的命令后,在当前目录下会出现一个/RECOVERED_FILES/目录,里面保 存了已经恢复的文件。
[root@localhost ~]# ls
anaconda-ks.cfg extundelete-0.2.4 extundelete-0.2.4.tar.bz2 RECOVERED_FILES [root@localhost ~]# cd RECOVERED_FILES/
[root@localhost RECOVERED_FILES]# ls
a b
当然 extundelete 的用法还有很多,可以通过 help 查看详细用法。
4xfs类型文件备份和恢复**
extundelete 工具仅可以恢复 EXT 类型的文件,无法恢复 CentOS 7 系统默认采用 xfs 类型的文件。针对 xfs 文件系统目前也没有比较成熟的文件恢复工具,所以建议提前做好数据备份,以避免数据丢失。
xfs 类型的文件可使用 xfsdump 与 xfsrestore 工具进行备份恢复。若系统中未安装xfsdump 与xfsrestore 工具,可以通过yum install -y xfsdump 命令安装。xfsdump 按照inode 顺序备份一个 xfs 文件系统。xfsdump 的备份级别有两种:0 表示完全备份;1-9 表示增量备份。xfsdump 的备份级别默认为 0。xfsdump 的命令格式为:xfsdump -f 备份存放位置要备份路径或设备文件。常用的备份参数包括以下几种:
*-f:指定备份文件目录;
*-L:指定标签 session label;
*-M:指定设备标签 media label;
*-s:备份单个文件,-s 后面不能直接跟路径。
下面通过一个案例来备份恢复 xfs 类型的文件。首先添加一款新硬盘并格式化为 xfs 类型的文件系统,然后挂在到/date 目录下。
[root@localhost ~]#fdisk /dev/sdb
...... //省略部分内容Command (m for help): n
Partition type:p
primary (0 primary, 0 extended, 4 free) e extended
Select (default p): p
Partition number (1-4, default 1):
First sector (2048-41943039, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-41943039, default 41943039): Using default value 41943039
Partition 1 of type Linux and of size 20 GiB is set Command (m for help): p
Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 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 Disk label type: dos
Disk identifier: 0x30e29e0f
Device Boot Start End Blocks Id System
/dev/sdb1 2048 41943039 20970496 83 Linux Command (m for help): w
The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks.
[root@localhost ~]# partprobe/dev/sdb
[root@localhost ~]# mkfs.xfs/dev/sdb1
meta-data=/dev/sdb1 isize=512 agcount=4, agsize=1310656 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=5242624, imaxpct=25
= sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 [root@localhost ~]# mkdir/date
[root@localhost ~]# mount /dev/sdb1 /date/
[root@localhost ~]# cd /date
[root@localhost date]# cp /etc/passwd ./
[root@localhost date]# mkdir test
[root@localhost date]# touch test/a
[root@localhost date]# tree /date
/date
├── passwd
└── test
└── a
1 directory, 2 files
使用 xfsdump 命令备份整个分区。
[root@localhost ~]# xfsdump -f /opt/dump_sdb1 /dev/sdb1
xfsdump: using file dump (drive_simple) strategy
xfsdump: version 3.1.7 (dump format 3.0) - type ^C for status and control
============================= dump label dialog
==============================
please enter label for this dump session (timeout in 300 sec)
-> dump_sdb1 //指定备份会话标签session label entered: "dump_sdb1"
--------------------------------- end dialog ---------------------------------
xfsdump: level 0 dump of localhost.localdomain:/date xfsdump: dump date: Tue Nov 13 03:02:21 2018
xfsdump: session id: 30b70de8-f840-49a4-9ed4-00f1a25d49b7 xfsdump: session label: "dump_sdb1"
xfsdump: ino map phase 1: constructing initial dump list xfsdump: ino map phase 2: skipping (no pruning necessary) xfsdump: ino map phase 3: skipping (only one dump stream) xfsdump: ino map construction complete
xfsdump: estimated dump size: 25856 bytes xfsdump: /var/lib/xfsdump/inventory created
============================= media label dialog
=============================
please enter label for media in drive 0 (timeout in 300 sec)
-> sdb1 //指定设备标签,就是对要备份的设备做一个描述media label entered: "sdb1"
--------------------------------- end dialog ---------------------------------
xfsdump: creating dump session media file 0 (media 0, file 0) xfsdump: dumping ino map
xfsdump: dumping directories xfsdump: dumping non-directory files xfsdump: ending media file
xfsdump: media file size 23520 bytes xfsdump: dump size (non-dir files) : 1568 bytes xfsdump: dump complete: 61 seconds elapsed xfsdump: Dump Summary:
xfsdump: stream 0 /opt/dump_sdb1 OK (success) xfsdump: Dump Status: SUCCESS
[root@localhost ~]# xfsdump -I //查看备份信息与内容file system 0:
fs id: 67105dec-39fd-40a2-9e4f-bcb97ed9de67 session 0:
mount point: localhost.localdomain:/date device: localhost.localdomain:/dev/sdb1 time: Tue Nov 13 03:02:21 2018 session label: "dump_sdb1"
session id:30b70de8-f840-49a4-9ed4-00f1a25d49b7 level: 0
resumed: NO subtree: NO streams: 1
stream 0:
pathname: /opt/dump_sdb1 start: ino 67 offset 0
end: ino 70 offset 0 interrupted:NO media files:1
media file 0:
mfile index:0 mfile type: data mfile size: 23520
mfile start: ino 67 offset 0
mfile end: ino 70 offset 0 media label: "sdb1"
media id: d8ea6e6e-fe31-4c79-bdf4-daa1f665189f xfsdump: Dump Status: SUCCESS
删除之前创建的内容,模拟数据丢失。
[root@localhost ~]# cd /date/
[root@localhost date]#lspasswd test
[root@localhost date]# rm -rf ./*
[root@localhost date]# ls
[root@localhost date]#
使用 xfsrestore 命令恢复文件。xfsrestore 命令的语法为:xfsrestore -f 恢复文件的位置 存放恢复后文件的路径。
[root@localhost ~]# xfsrestore -f /opt/dump_sdb1 /date/
...... // 省 略 部 分 内 容 xfsrestore: Restore Status: SUCCESS
[root@localhost ~]# ls/date/
passwd test
使用 xfsdump 时,需要注意以下的几个限制:
*xfsdump 不支持没有挂载的文件系统备份,所以只能备份已挂载的;
*xfsdump 必须使用 root 的权限才能操作(涉及文件系统的关系);
*xfsdump 只能备份 XFS 文件系统;
*xfsdump 备份下来的数据(档案或储存媒体)只能让 xfsrestore 解析;
xfsdump D 的文件系统。
**
**
2分析日志文件
日志文件是用于记录 Linux 操作系统中各种运行消息的文件,相当于 Linux 主机的“日记”。不同的日志文件记载了不同类型的信息,如 Linux 内核消息、用户登录事件、程序错误等。
日志文件对于诊断和解决系统中的问题很有帮助,因为在 Linux 操作系统中运行的程序通常会把系统消息和错误消息写入相应的日志文件,这样系统一旦出现问题就会“有据可查”。 此外,当主机遭受攻击时,日志文件还可以帮助寻找攻击者留下的痕迹。
2.1主要日志文件
在 Linux 操作系统中,日志数据主要包括以下三种类型。
*内核及系统日志:这种日志数据由系统服务 rsyslog 统一管理,根据其主配置文件
/etc/rsyslog.conf 中的设置决定将内核消息及各种系统程序消息记录到什么位置。系统中有相当一部分程序会把自己的日志文件交由 rsyslog 管理,因而这些程序使用的日志记录也具有相似的格式。
*用户日志:这种日志数据用于记录 Linux 操作系统用户登录及退出系统的相关信息, 包括用户名、登录的终端、登录时间、来源主机、正在使用的进程操作等。
*程序日志:有些应用程序会选择由自己独立管理一份日志文件(而不是交给 rsyslog 服务管理),用于记录本程序运行过程中的各种事件信息。由于这些程序只负责管理自己的日志文件,因此不同程序所使用的日志记录格式可能会存在较大的差异。
Linux 操作系统本身和大部分服务器程序的日志文件都默认放在目录/var/log/下。一部分程序共用一个日志文件,一部分程序使用单个日志文件,而有些大型服务器程序由于日志文件不止一个,所以会在/var/log/目录中建立相应的子目录来存放日志文件,这样既保证了日志文件目录的结构清晰,又可以快速定位日志文件。有相当一部分日志文件只有 root 用户才有权限读取,这保证了相关日志信息的安全性。
对于 Linux 操作系统中的日志文件,有必要了解其各自的用途,这样才能在需要的时候更快地找到问题所在,及时解决各种故障。下面介绍常见的一些日志文件。
*/var/log/messages:记录 Linux 内核消息及各种应用程序的公共日志信息,包括启
动、I/0 错误、网络错误、程序故障等。对于未使用独立日志文件的应用程序或服务,一般都可以从该日志文件中获得相关的事件记录信息。
*/var/log/cron:记录 crond 计划任务产生的事件信息。
*/var/log/dmesg:记录 Linux 操作系统在引导过程中的各种事件信息。
*/var/log/maillog:记录进入或发出系统的电子邮件活动。
*/var/log/lastlog:记录每个用户最近的登录事件。
*/var/log/secure:记录用户认证相关的安全事件信息。
*/var/log/wtmp:记录每个用户登录、注销及系统启动和停机事件。
*/var/log/btmp:记录失败的、错误的登录尝试及验证事件。
4.2日志文件分析*
熟悉了系统中的主要日志文件以后,下面将介绍针对日志文件的分析方法。分析日志文 件的目的在于通过浏览日志查找关键信息、对系统服务进行调试,以及判断发生故障的原因 等。
对于大多数文本格式的日志文件(如内核及系统日志、大多数的程序日志),只要使用 tail、more、less、cat 等文本处理工具就可以查看日志内容。而对于一些二进制格式的日志文件(如用户日志),则需要使用特定的查询命令。
1内核及系统日志
内核及系统日志功能主要由默认安装的 rsyslog-7.4.7-16.el7.x86_64.rpm 软件包提供。rsyslog 服务所使用的配置文件为/etc/rsyslog.conf。通过查看/etc/rsyslog.conf 文件中的内容,可以了解到系统默认的日志设置,具体操作如下:
[root@localhost ~]# grep -v"^$/etc/rsyslog.conf //过滤掉空行# rsyslog configuration file
\# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
\# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES ####
\# The imjournal module bellow is now used as a message source instead of imuxsock.
$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imjournal # provides access to the systemd journal
\#$ModLoad imklog # reads kernel messages (the same are read from journald) #$ModLoad immark # provides --MARK-- message capability
\# Provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514
\# Provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514
\#### GLOBAL DIRECTIVES ####
\# Where to place auxiliary files
$WorkDirectory /var/lib/rsyslog # Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
\# File syncing capability is disabled by default. This feature is usually not required,
\# not useful and an extreme performance hit #$ActionFileEnableSync on
\# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf
\# Turn off message reception via local log socket;
\# local messages are retrieved through imjournal now.
$OmitLocalLogging on
\# File to store the position in the journal
$IMJournalStateFile imjournal.state #### RULES ####
\# Log all kernel messages to the console.
\# Logging much else clutters up the screen.
\#kern.* /dev/console
\# Log anything (except mail) of level info or higher. # Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access.
authpriv.* /var/log/secure
\# Log all the mail messages in one place.
mail.* -/var/log/maillog
\# Log cron stuff
cron.* /var/log/cron
\# Everybody gets emergency messages
*.emerg :omusrmsg:*
\# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
\# Save boot messages also to boot.log
local7.* /var/log/boot.log
\# ### begin forwarding rule ###
\# The statement between the begin ... end define a SINGLE forwarding
\# rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block!
\# Remote Logging (we use TCP for reliable delivery) #
\# An on-disk queue is created for this action. If the remote host is
\# down, messages are spooled to disk and sent when it is up again. #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down
\# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514
\# ### end of the forwarding rule ###
从配置文件/etc/rsyslog.conf 中可以看到,受 rsyslogd 服务管理的日志文件都是 Linux 操作系统中主要的日志文件,它们记录了 Linux 操作系统中内核、用户认证、电子邮件、计划任务等基本的系统消息。在 Linux 内核中,根据日志消息的重要程度不同,将其分为不同的优先级别(数字等级越小,优先级越高,消息越重要)。
Ø | 0 | EMERG(紧急):会导致主机系统不可用的情况。 |
---|---|---|
Ø | 1 | ALERT(警告):必须马上采取措施解决的问题。 |
Ø | 2 | CRIT(严重):比较严重的情况。 |
Ø | 3 | ERR(错误):运行出现错误。 |
Ø | 4 | WARNING(提醒):可能影响系统功能,需要提醒用户的重要事件。 |
Ø | 5 | NOTICE(注意):不会影响正常功能,但是需要注意的事件。 |
Ø | 6 | INFO(信息):一般信息。 |
Ø | 7 | DEBUG(调试):程序或系统调试信息等。 |
内核及大多数系统消息被记录到公共日志文件/var/log/messages 中,而其他一些程序消息被记录到各自独立的日志文件中,此外日志消息还能够记录到特定的存储设备中,或者直接发送给指定用户。
对于 rsyslog 服务统一管理的大部分日志文件,使用的日志记录格式基本上是相同的。以公共日志/var/log/messages 文件的记录格式为例,其中每一行表示一条日志消息,每一条消息均包括以下四个字段。
Ø 时间标签:消息发出的日期和时间。
Ø 主机名:生成消息的计算机的名称。
Ø 子系统名称:发出消息的应用程序的名称。
Ø 消息:消息的具体内容。
在有些情况下,可以设置 rsyslog,使其在把日志信息记录到文件的同时将日志信息发送到打印机进行打印,这样无论网络入侵者怎样修改日志都不能清除入侵的痕迹。rsyslog 日志服务是一个常会被攻击的显著目标,破坏了它将使管理员难以发现入侵及入侵的痕迹, 因此要特别注意监控其守护进程及配置文件。
2用户日志
在 wtmp、btmp、lastlog 等日志文件中,保存了系统用户登录、退出等相关的事件消息。但是这些文件都是二进制的数据文件,不能直接使用 tail、less 等文本查看工具进行浏览, 需要使用 who、w、users、last 和 lastb 等用户查询命令来获取日志信息。
(1) 查询当前登录的用户情况——users、who、w 命令
users 命令只是简单地输出当前登录的用户名称,每个显示的用户名对应一个登录会话。如果一个用户有不止一个登录会话,那他的用户名将显示与其相同的次数。user 命令的具体操作如下:
[root@localhost ~]# users
root root root //root 用户打开三个终端
who 命令用于报告当前登录到系统中的每个用户的信息。使用该命令,系统管理员可以查看当前系统存在哪些不合法用户,从而对其进行审计和处理。who 的默认输出包括用户名、终端类型、登录日期及远程主机。
[root@localhost ~]# who
| root | :0 | 2017-05-07 10:27 (:0) |
| ---- | ----- | ------------------------------- |
| root | pts/1 | 2017-05-07 10:27 (:0) |
| root | pts/2 | 2017-05-07 10:28 (192.168.12.1) |
w 命令用于显示当前系统中的每个用户及其所运行的进程信息,比 users、who 命令的输出内容要丰富一些。w 命令的具体操作如下:
[root@localhost ~]# w
11:48:26 up 1:32, 3 users, load average: 0.03, 0.02, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root :0 :0 10:27 ?xdm? 51.22s 0.27s gdm-session-worker [pam/gdm-password]
| root | pts/1 | :0 | 10:27 1:20m 0.02s 0.02s bash |
| ---- | ----- | ------------ | ------------------------------- |
| root | pts/2 | 192.168.12.1 | 10:28 2.00s 0.65s 0.04s w |
查询用户登录的历史记录——last、lastb 命令
last 命令用于查询成功登录到系统的用户记录,最近的登录情况将显示在最前面。通过last 命令可以及时掌握 Linux 主机的登录情况,若发现未经授权的用户登录过,则表示当前主机可能已被入侵。last 命令的具体操作如下:
[root@localhost ~]# last
| root | pts/0 | | 192.168.12.1 | Sun May 7 11:11 - 11:46 (00:34) |
| ------ | ----- | ---- | ------------ | ----------------------------------- |
| root | pts/2 | | 192.168.12.1 | Sun May 7 10:28 still logged in |
| hackli | tty2 | | | Sun May 7 10:27 - 10:29 (00:01) |
| root | pts/1 | | :0 | Sun May 7 10:27 still logged in |
| root | :0 | :0 | Sun | May 7 10:27 still logged in |
…… //省略部分内容
wtmp begins Wed Apr 12 13:22:51 2017
注: lastb 命令用于查询登录失败的用户记录,如登录的用户名错误、密码不正确等情况都将记录在案。登录失败的情况属于安全事件,因为这表示可能有人在尝试猜解你的密码。除 了使用 lastb 命令查看以外,也可以直接从安全日志文件/var/log/secure 中获得相关信息。
3*程序日志
在 Linux 操作系统中,还有相当一部分应用程序没有使用 rsyslog 服务来管理日志,而是由程序自己维护日志记录。例如,httpd 网站服务程序使用两个日志文件 access_log 和error_log 分别记录客户访问事件和错误事件。不同应用程序的日志记录格式差别较大,且没有严格使用统一的格式,这里不再详细介绍。
总的来说,作为一名合格的系统管理人员,应该提高警惕,随时注意各种可疑状况,定 期并随机检查各种系统日志文件,包括一般信息日志、网络连接日志、文件传输日志及用户
登录日志记录等。在检查这些日志时,要注意是否有不合常理的时间或操作记录。例如,出 现以下现象就应多加注意。
Ø 用户在非常规的时间登录,或者用户登录系统的 IP 地址和以往的不一样。
Ø 用户登录失败的日志记录,尤其是那些一再连续尝试进入失败的日志记录。
Ø 非法使用或不正当使用超级用户权限。
Ø 无故或者非法重新启动各项网络服务的记录。
Ø 不正常的日志记录,如日志残缺不全,或者是诸如 wtmp 这样的日志文件无故缺少了中间的记录文件。
另外,需要提醒管理人员注意的是,日志并不是完全可靠的,高明的黑客在入侵系统后 经常会打扫现场。所以管理人员需要综合运用以上的系统命令,全面、综合地进行审查和检 测,切忌断章取义,否则将可能做出错误的判断。
Ø 是透过文件系统的 UUID 来分辨各个备份档的,因此不能备份两个具有相同
UUI
10:29 (00:01) |
| root | pts/1 | | :0 | Sun May 7 10:27 still logged in |
| root | :0 | :0 | Sun | May 7 10:27 still logged in |
…… //省略部分内容
wtmp begins Wed Apr 12 13:22:51 2017