阶段七：日志管理与深层防火墙

    logger 是一个用于向系统日志（syslog）写入日志消息的命令行工具。通过 logger，您可以生成日志记录，模拟各种日志级别，并将日志写入不同的日志文件，供系统管理员或程序查看和调试。它通常用于脚本或命令行中，来创建自定义日志消息。

格式:
    logger [OPTION] MESSAGE

    OPTION：指定日志的各种选项，如日志级别、日志标识等。
    MESSAGE：要记录的日志内容。

常用选项：
-p ：指定日志的优先级(priority)（日志级别）。
    例如：-p local0.debug 表示将日志记录为 local0 设施，debug 严重性级别。

-f：将日志写入指定的文件(file)，而不是默认的系统日志文件。
    -i：在日志中包含调用程序的进程ID（PID）。
    -s：同时将日志消息输出到标准输出（终端）和系统日志。
    -n：remote_host：将日志发送到远程主机的 syslog 守护进程。

示例:
    写入默认日志文件（/var/log/messages）: 
    logger "This is a test log message"

    指定日志级别（如 crit）:
    logger -p crit "Critical error in system"

传统的 syslogd 使用 UDP 协议发送日志数据，虽然效率高，但容易丢包。
rsyslogd 支持 TCP 协议，可以保证日志数据的可靠传输，特别适合重要信息的记录和远程日志传输。

支持加密传输（如 TLS），即使在公共网络上传输日志，也能防止数据被窃听或篡改。
满足企业对日志传输安全性的要求，特别是敏感数据的记录。

内置了日志分析和过滤的功能，能够对日志信息进行实时处理。
可快速筛选出关键事件，适用于大规模日志分析场景。

可以直接将日志存储到数据库中（如 MySQL、PostgreSQL），方便后续分析和管理。
提供了更好的日志归档和查询能力，相比于传统文件存储更灵活。

支持条件判断，管理员可以灵活定义日志的处理规则，比如按照日志来源、优先级、关键词等分流存储。
配置更强大，可以应对复杂的日志管理需求

rsyslogd 继承了 syslog 的传统配置方法（如 /etc/rsyslog.conf 格式），因此从旧系统迁移到新系统时非常方便。
适应性强，兼容传统工具和方法。

与用户登录相关的日志：
      /var/log/btmp ： 记录用户登录错误的日志，需要使用lastb命令查看即可
      /var/log/wtmp ： 记录所有用户登录、注销以及系统启动 重启 关机事件日志，需要使用last命令查看
      /var/run/utmp ： 记录当前已经登录的用户信息， 需要使用w、who、users查询日志
      /var/log/lastlog： 记录用户最后一次登录时间的日志， 需要使用lastlog 命令查看日志

大部分的日志， 都是通过 tail 命令查看日志文件 
系统日志： /var/log/message   

安全日志： /var/log/secure

1. 全局指令 (GLOBAL DIRECTIVES)

global(workDirectory="/var/lib/rsyslog")

作用: 临时文件和运行数据（如队列、状态记录）都存这里，类似“工作文件夹”。

module(load="builtin:omfile" Template="RSYSLOG_TraditionalFileFormat")

作用: 保存日志时，用最经典的格式（旧版样式），方便兼容老工具。

2. 模块 (MODULES)
# 使用不同的模块来提供各种功能。以下是一些常见模块的配置：
rsyslog 

# 默认关闭本地套接字（比如logger命令的日志），改用下面的imjournal模块
imuxsock 模块
module(load="imuxsock" SysSock.Use="off")

# 直接从系统日志（systemd的journal）读取日志。
imjournal 模块
module(load="imjournal" UsePid="system" FileCreateMode="0644" StateFile="imjournal.state")
# StateFile="imjournal.state"：记录读到哪了，下次接着读
# FileCreateMode="0644"：生成的文件权限是所有人可读

#注释掉的模块
# 读内核日志（现在用systemd代替了）。
#module(load="imklog") # reads kernel messages (the same are read from journald)
# 定时打--MARK--日志标记（没开）
#module(load="immark") # provides --MARK-- message capability

# 包含额外配置文件
# 可以往/etc/rsyslog.d/目录加其他配置文件，灵活扩展规则
include(file="/etc/rsyslog.d/*.conf" mode="optional")

# 接收远程日志 (Syslog Reception)模块 [默认没开]
rsyslog

# UDP 514端口 接收：速度快但可能丢消息（像广播，不保证对方收到）
#module(load="imudp") # needs to be done just once
#input(type="imudp" port="514")

# TCP 514端口 接收：更可靠，但占用资源多（类似打电话确认收到）。
#module(load="imtcp") # needs to be done just once
#input(type="imtcp" port="514")

3. 日志规则 (RULES)
# 日志规则部分定义了不同日志级别和类别的日志存储位置。

# 内核日志到控制台
# 作用: 将所有内核消息（`kern.*`）输出到控制台。由于太多信息会使屏幕杂乱，因此通常会注释掉。
#kern.* /dev/console

# 系统日志存储
# 所有普通日志（排除邮件、登录、定时任务）存这里
*.info;mail.none;authpriv.none;cron.none /var/log/messages

# 安全日志
# 登录、权限相关的日志（如SSH登录失败）存这里，权限严格。
authpriv.* /var/log/secure

# 邮件日志
# 邮件日志，用“异步写入”（先放内存，攒一波再写硬盘，避免卡住）。
mail.* -/var/log/maillog

# cron 日志
# 定时任务（cron）的日志，比如任务何时执行。
cron.* /var/log/cron

# 紧急消息
# 紧急日志（比如系统崩溃）弹窗给所有登录的用户。
*.emerg :omusrmsg:*

# 新闻错误日志
# 将 `uucp` 和 `news` 类别中 `crit`（严重）及以上级别的错误存储到 `/var/log/spooler` 文件。
uucp,news.crit /var/log/spooler

# 启动日志
# 开机启动过程的日志存这里。
local7.* /var/log/boot.log

4. 日志转发 (Forwarding) 示例
# 实现将系统日志统一全部转发到其他的服务器， 这在进行系统日志收集中非常的重要

# action(type="omfwd"
# queue.filename="fwdRule1"
# queue.maxdiskspace="1g"
# queue.saveonshutdown="on"
# queue.type="LinkedList"
# action.resumeRetryCount="-1"
# Target="remote_host" Port="XXX" Protocol="tcp")

# omfwd模块
# 把日志转发到另一台机器，比如：
    # Target="remote_host" Port="XXX"：目标的IP和端口。
    # Protocol="tcp"：用TCP发（更可靠）。
    # queue.maxdiskspace="1g"：如果网络断了，最多存1G日志在本地等着。
    # action.resumeRetryCount="-1"：无限重试，直到发出去为止。

  authpriv.*                           /var/log/secure
  #服务名称[连接符号]日志等级             日志记录位置
  #认证相关服务.所有日志等级              记录在/var/log/secure 日志中

      “.”代表只要比后面的等级高的（包含该等级）日志都记录下来。比如：“cron.info” 代表 cron 服务产生的日志，只要日志等级大于等于 info 级别，就记录
      “.=”代表只记录所需等级的日志，其他等级的都不记录。比如：“*.=emerg”代表任何日志服务产生的日志，只要等级是 emerg 等级就记录。这种用法及少见，了解就好
      “.!”代表不等于，也就是除了该等级的日志外，其他等级的日志都记录。

  日志文件的绝对路径: 【大多数情况】
      这是最常见的日志保存方法，如“/var/log/secure”就是保存系统验证和授权信息日志的。
  
  系统设备文件: 【相对较少】
      如“/dev/lp0”代表第一台打印机，如果日志保存位置是打印机设备的话，当有日志时就会在打印机打印
  
  转发给远程主机:  【针对特殊的个别服务需要发送给其他服务器的情况】
      因为可以选择使用 TCP 协议和 UDP 协议传输日志信息，所以有两种发送格式。
      如使用“ @192.168.88.102:514 ”，就会把日志内容使用 UDP 协议发送到192.168.88.102 的 UDP 514 端口上；
      如果使用“@@192.168.88.102:514”就会把日志内容使用 TCP 协议发送到 192.168.88.102 的 TCP 514 端口上，其中 514 是日志服务默认端口。当然只要 192.168.88.102 同意接收此日志，就可以把日志内容保存在日志服务器上。
  
  忽略或丢弃日志：【相对较少】
      如果接受日志的对象是“~”，代表这个日志不会记录，而被直接丢弃。如“local3.*      ~”代表忽略 local3 服务类型所有的日志都不记录。

**注意事项：**

- 修改配置前先备份原文件，尤其是 SSH、Nginx、数据库和 Kubernetes 生产配置。

把所有服务的“临界点”以上的错误都保存在/var/log/alert.log 日志中

格式写法：
*.crit   /var/log/alert.log

# 注意： 该目标文件如果不存在，会自动进行创建

systemctl restart rsyslog

systemctl status rsyslog

生成日志的格式：
    logger -p 日志级别 "日志内容"

查看日志的命令：
    tail -Nf 日志文件

    N表示：从后往前查看多少行
    f： 表示实时监听日志最新的变化

需求： 将node1中全部日志统一转发到node3来接收， 同时要求保证在node1也要本地保存一份

# 本地保存， 本省rsyslog日志就会进行本地保存，依靠规则模块相关配置 【不需要关心】

# 思考： 如何完成全部日志统一转发操作呢？ 能想到解决方案的前提一定是对rsyslog的配置文件熟悉

解决方案： 日志转发 (Forwarding) 

vi /etc/rsyslog.conf

systemctl restart rsyslog
ststemctl status rsyslog

vi /etc/rsyslog.conf

systemctl restart rsyslog

ststemctl status  rsyslog

firewall-cmd --add-port 514/tcp --permanent
firewall-cmd --reload
firewall-cmd --list-all

logger  "system  log  node1 ......"

通过刚刚演示的二个案例： 
    案例一： 演示针对某一个服务 或者 某几个服务进行日志转发到其他服务器方案

    案例二： 演示针对整个系统日志统一转发到其他的服务器方案

实际场景价值呢？ 
    在进行集中化日志管理方案中， 我们就需要将机房中多个服务器的日志统一汇总到日志服务器中， 然后基于日志服务器进行统一的监控管理操作， 并最终部署一个告警和监控服务， 从而实现统一日志管理

    对于系统日志服务而言：除了可以使用后续要学习专门用于采集日志的方案外， 我们也可以直接使用rsyslog所提供的这种日志转发的能力 从而更加方便完成日志转发到日志服务器的需求

    其他价值： 能够对rsyslog的系统日志有一个基本认识， 大概清楚有哪些日志文件， 当后续系统发生相关问题的时候，我们可以通过对应的系统日志查询错误，进行解决问题

    例如： 安全检查， 检查近期在这一周内，访问服务器超过100次的用户有哪些？ 看记录用户登录信息日志

dnf install logrotate

默认安装了 logrotate 工具

logrotate [选项] 配置文件名

选项：如果此命令没有选项，则会按照配置文件中的条件进行日志轮替
    -v：        显示日志轮替过程。加了-v 选项，会显示日志的轮替的过程
    -f：        强制进行日志轮替。不管日志轮替的条件是否已经符合，强制配置文件中所有的日志进行轮替

该命令主要是用于测试环节中使用， 用于测试配置的轮替方案是否生效

cat /etc/logrotate.conf

# 轮替周期:  指定日志轮替的周期为每周。可以设置为 daily、weekly、monthly 等。
weekly

# 保留日志文件的数量: 保留 4 个日志文件的备份（即保留当前日志和 3 个旧日志）。
rotate 4

# 在日志轮替时，自动创建新的日志文件
create

# 使用日期作为日志轮替文件的后缀
dateext

# 在日志轮替时压缩旧日志。
#compress

# 包含/etc/logrotate.d/目录中所有的子配置文件。也就是说会把这个目录中所有子配置文件读取进来，进行日志轮替。
include /etc/logrotate.d

#以上日志日志配置为默认配置，如果需要轮替的日志没有设定独立的参数，那么都会遵守以上参数。
#如果轮替日志配置了独立参数，那么独立参数优先级更高。

/var/log/hawkey.log {
    missingok   # 如果日志文件缺失，不报错。
    notifempty  # 如果日志文件为空，则不进行轮替。
    rotate 4    # 保留 4 个日志文件的备份（即保留当前日志和 3 个旧日志）。
    weekly      # 日志轮替的周期为每周
    create      # 创建新的日志文件
}

/var/log/httpd/access.log 
/var/log/httpd/error.log 
{
   rotate 5 # 保留的日志文件的个数为5个
   mail recipient@example.org  # 信息发送到指定邮箱
   size 100k  # 日志大于 100KB 时才进行日志轮替，不再按照时间轮替
   sharedscripts # 无论有多少个日志文件需要轮替 以下脚本只执行一次
   postrotate # 在日志轮替结束之后，执行以下脚本
       /usr/bin/killall -HUP httpd # 重启 apache 服务
   endscript #脚本结束
}

需求说明： 
    1- 设置为周轮替一次
    2- 保留6个轮替日志
    3- 日志不存在，忽略日志的警告信息
    4- 在日志轮替之前执行去除日志a属性， 以便于能够顺利完成轮替操作
    5- 在日志轮替之后执行重启rsyslog服务：/bin/kill -HUP $(/bin/cat /var/run/rsyslogd.pid 2>/dev/null) &>/dev/null

注： 在配置前， 先对文件添加a属性，对日志文件进行保护

第一步： 先给 /var/log/alert.log  增加 a 属性
第二步： 配置轮替配置文件：
    思考：该文件放置的位置在哪里呢？ /etc/logrotate.d/ 

第三步：重启轮替的服务   
    systemctl restart logrotate

第四步： 测试
    直接使用强制轮替命令， 强制触发轮替， 观察是否产生新的轮替文件
    logrotate -vf  /etc/logrotate.conf
    轮替完成后， 查看 /var/log/alert.log属性， 此时该属性的a属性应该是不存在的

chattr +a /var/log/alert.log     

lsattr /var/log/alert.log

cd /etc/logrotate.d/

vi  alert

输入 i 插入以下内容：
/var/log/alert.log {
        weekly
        rotate 6
        missingok
        sharedscripts
        prerotate
                chattr -a /var/log/alert.log
        endscript
        sharedscripts
        postrotate
                /bin/kill -HUP $(/bin/cat /var/run/rsyslogd.pid 2>/dev/null) &>/dev/null
        endscript
}

systemctl restart logrotate
systemctl status logrotate

logrotate -vf  /etc/logrotate.conf

chattr命令： 
    一个用于修改 Linux 文件属性的命令。chattr 全称为 change attribute，它可以改变文件或目录的特殊属性，从而影响它们的行为，例如防止文件被修改、删除等。

格式：
    chattr [选项] [文件或目录]

常用选项：
    +：添加属性。
    -：移除属性。
    =：仅保留指定属性，移除其他所有属性

常见的文件属性：
    a: 文件只能追加数据，不能被删除或修改现有内容（追加模式）。
    i: 文件不可更改（不可删除、不可重命名、不可写入）。
    d: 文件不会包含在备份工具（如 dump）中。
    s: 文件被删除时，其数据会被安全地擦除（覆盖为零）。
    u: 文件被删除时，其数据会被保留，可用于后续恢复。
    c: 文件自动压缩，读取时解压缩，写入时压缩。
    t: 禁止文件使用尾部合并（tail-merging，适用于某些文件系统）。
    e: 文件具有扩展属性。

示例用法：
    1. 防止文件被删除或修改（设置不可更改属性）： 
            chattr +i /etc/passwd
            添加 i 属性，使其不可更改。这意味着即使是 root 用户也无法删除、修改或重命名该文件，直到属性被移除。
    2. 设置文件为只能追加（日志文件保护）
            chattr +a /var/log/myapp.log
            设置为只能追加内容，任何覆盖或删除操作都会失败。这在保护日志文件时非常有用。

    3. 查看文件属性,文件的当前属性可以通过 lsattr 命令查看:
            lsattr /etc/passwd
    4. 移除属性:
            chattr -i /etc/passwd
    5. 批量操作,可以对整个目录及其内容设置属性:
            chattr -R +i /important_dir

HUP 信号 
    是 Linux/Unix 系统中的一种信号，完整名称为 Hangup Signal，信号编号是 1。它最初设计用于通知进程终端连接被挂断（如用户退出终端），但在现代系统中，它的用途已经扩展，特别是在管理守护进程和服务时被广泛使用。

作用：

    挂断通知：
        最初用途是向进程告知终端或连接已经挂断，例如用户通过电话调制解调器断开连接。
        进程收到 HUP 信号后，通常会终止。

    重新加载配置文件：
        现代守护进程收到 HUP 信号时，会重新加载配置文件，而不会终止进程。这是运维中常用的功能。
        守护进程在接收到 HUP 信号时会执行重新初始化操作，比如 Nginx、rsyslog、sshd 等服务。

    日志文件切换：
        某些进程（如 syslogd、rsyslogd）收到 HUP 信号后，会关闭当前日志文件并打开新的日志文件，常用于日志轮替。

注意： 不同的进程对应HUP信号的响应的方案是不一样的， 对应的应用是否支持哪种作用建议通过AI查询即可

一般使用kill命令向进程发送HUP信号：
格式：kill -HUP <PID>

示例一：
    kill -HUP 1234  向进程 ID 为 1234 的进程发送 HUP 信号。

示例二： 通过文件存储的 PID
    kill -HUP $(cat /var/run/nginx.pid)
    读取存储在 /var/run/nginx.pid 中的进程 ID，并向其发送 HUP 信号。

HUP 信号的具体行为由接收进程决定，经典的服务进程响应行为：
    sshd        重新加载配置文件，但不会中断现有会话。
    nginx        平滑地重新加载配置文件，不中断现有连接。
    rsyslog        切换日志文件或重新加载配置。
    bash        通知 Bash 终端断开连接。
    tmux        会话继续运行，但会分离挂断的终端。

并不是所有的应用都支持接收HUP信号, 所以在使用HUP信号的时候, 首先要先确定 目标进程是否支持HUP信号, 以及支持具体行为是什么

sestatus

sudo setenforce 0  # 切换为 Permissive 模式
sudo setenforce 1  # 切换为 Enforcing 模式

vim /etc/selinux/config

ausearch -m avc

restorecon /path/to/file