Craig Hicks's questions

我相信这是确认包裹完整性的正确方法 -

$ sha256sum /var/cache/apt/archives/intel-microcode_3.20241112.1~deb12u1_amd64.deb
5ae98379ad2ca170ab4808d2e78e86560a6976264557a3f26c8829ed45aa33bd  /var/cache/apt/archives/intel-microcode_3.20241112.1~deb12u1_amd64.deb

但是 Debian 网站页面 https://packages.debian.org/sid/amd64/intel-microcode/download

标题为“AMD64 机器上的 intel-microcode_3.20241112.1_amd64.deb 下载页面”

列表

Exact Size      7107380 Byte (6.8 MByte)
MD5 checksum        b132ba25e76a0362993eeacac0d26275
SHA1 checksum       Not Available
SHA256 checksum     6aaeef4e106a983b88c8ddec99d105e91064037ead83cc6b35dd1e6d675df485

此外，尺寸也不同

-rw-r--r-- 1 root root 7109172 Dec 18 05:46 /var/cache/apt/archives/intel-microcode_3.20241112.1~deb12u1_amd64.deb

显然，如果大小不同，那么校验和也会不同，但我在注意到大小之前检查了校验和。

对此有什么合理的解释吗？

解锁磁盘后，常用的措辞发生了变化，并出现了一条关于下载固件的消息。我想知道发生了什么，所以我尝试了 dmsg -

% sudo dmsg
[    0.000000] microcode: microcode updated early to revision 0xf8, date = 2023-09-28
[    0.000000] Linux version 6.1.0-30-amd64 ([email protected]) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12)

微码信息很模糊。这是否不正常？

我如何确定我拥有什么固件、我应该拥有什么固件以及什么是可用的固件？

编辑：changelog.Debian 的顶部

intel-microcode (3.20241112.1~deb12u1) bookworm; urgency=medium

  * Build for bookworm
  * All trixie-only changes (from 3.20240813.2) are reverted on this branch

 -- Henrique de Moraes Holschuh <[email protected]>  Sat, 07 Dec 2024 14:49:05 -0300

intel-microcode (3.20241112.1) unstable; urgency=medium

  * New upstream microcode datafile 20241112 (closes: #1086483)
    - Mitigations for INTEL-SA-01101 (CVE-2024-21853)
      Improper Finite State Machines (FSMs) in the Hardware logic in some
      4th and 5th Generation Intel Xeon Processors may allow an authorized
      user to potentially enable denial of service via local access.
    - Mitigations for INTEL-SA-01079 (CVE-2024-23918)
      Potential security vulnerabilities in some Intel Xeon processors
      using Intel SGX may allow escalation of privilege.  Intel disclosed
      that some processor models were already fixed by a previous
      microcode update.
    - Updated mitigations for INTEL-SA-01097 (CVE-2024-24968)
      Improper finite state machines (FSMs) in hardware logic in some
      Intel Processors may allow an privileged user to potentially enable a
      denial of service via local access.
    - Mitigations for INTEL-SA-01103 (CVE-2024-23984)
      A potential security vulnerability in the Running Average Power Limit
      (RAPL) interface for some Intel Processors may allow information
      disclosure.  Added mitigations for more processor models.
  * Updated Microcodes:
    sig 0x000806f8, pf_mask 0x87, 2024-06-20, rev 0x2b000603, size 588800
    sig 0x000806f7, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f6, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f5, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x000806f4, pf_mask 0x87, 2024-06-20, rev 0x2b000603
    sig 0x00090672, pf_mask 0x07, 2024-05-29, rev 0x0037, size 224256
    sig 0x00090675, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000b06f2, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000b06f5, pf_mask 0x07, 2024-05-29, rev 0x0037
    sig 0x000906a3, pf_mask 0x80, 2024-06-03, rev 0x0435, size 223232
    sig 0x000906a4, pf_mask 0x80, 2024-06-03, rev 0x0435
    sig 0x000a06a4, pf_mask 0xe6, 2024-08-02, rev 0x0020, size 138240
    sig 0x000b06a2, pf_mask 0xe0, 2024-05-29, rev 0x4123, size 220160
    sig 0x000b06a3, pf_mask 0xe0, 2024-05-29, rev 0x4123
    sig 0x000b06a8, pf_mask 0xe0, 2024-05-29, rev 0x4123
    sig 0x000c06f2, pf_mask 0x87, 2024-06-20, rev 0x21000283, size 560128
    sig 0x000c06f1, pf_mask 0x87, 2024-06-20, rev 0x21000283
  * source: update symlinks to reflect id of the latest release, 20241112
  * Update changelog for 3.20240910.1 and 3.20240813.1 with new information:
    INTEL-SA-1103 was addressed by 3.20240813.1 for some processor models,
    and not by 3.20240910. INTEL-SA-1079 was addressed by 3.20240910.1 for
    some processor models.

 -- Henrique de Moraes Holschuh <[email protected]>  Thu, 14 Nov 2024 15:37:40 -0300

我正在寻找一个程序来获取输出iptables -S并将其转换为广度优先列表。

为什么？我正在使用VyOS的路由器上做一些工作，其中预先安装了几层表，因此很难追溯连接到 INPUT、FORWARD 和 OUTPUT 的所有规则。

根据@JeffSchaller 的 [request]，这里是需要解析的示例输出：

$ sudo iptables -S 
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N LAN1_IN
-N MINIUPNPD
-N UBNT_FW_IN_SUSPEND_HOOK
-N UBNT_PFOR_FW_HOOK
-N UBNT_PFOR_FW_RULES
-N UBNT_VPN_IPSEC_FW_HOOK
-N UBNT_VPN_IPSEC_FW_IN_HOOK
-N VYATTA_FW_IN_HOOK
-N VYATTA_FW_LOCAL_HOOK
-N VYATTA_FW_OUT_HOOK
-N VYATTA_POST_FW_FWD_HOOK
-N VYATTA_POST_FW_IN_HOOK
-N VYATTA_POST_FW_OUT_HOOK
-N WAN_IN
-N WAN_LOCAL
-N WAN_OUT
-A INPUT -j UBNT_VPN_IPSEC_FW_HOOK
-A INPUT -j VYATTA_FW_LOCAL_HOOK
-A INPUT -j VYATTA_POST_FW_IN_HOOK
-A FORWARD -j MINIUPNPD
-A FORWARD -j UBNT_VPN_IPSEC_FW_IN_HOOK
-A FORWARD -j UBNT_PFOR_FW_HOOK
-A FORWARD -j UBNT_FW_IN_SUSPEND_HOOK
-A FORWARD -j VYATTA_FW_IN_HOOK
-A FORWARD -j VYATTA_FW_OUT_HOOK
-A FORWARD -j VYATTA_POST_FW_FWD_HOOK
-A OUTPUT -j VYATTA_POST_FW_OUT_HOOK
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j LOG --log-prefix "[LAN1_IN-10-D]"
-A LAN1_IN -m comment --comment LAN1_IN-10 -m state --state INVALID -j DROP
-A LAN1_IN -p udp -m comment --comment LAN1_IN-20 -m udp --dport 53 -m set --match-set dnsaddr dst -j RETURN
-A LAN1_IN -p udp -m comment --comment LAN1_IN-30 -m set --match-set dnsaddr src -m udp --dport 53 -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-60 -m state --state NEW -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-70 -m state --state RELATED -j RETURN
-A LAN1_IN -m comment --comment LAN1_IN-80 -m state --state ESTABLISHED -j RETURN
-A LAN1_IN -m comment --comment "LAN1_IN-10000 default-action drop" -j LOG --log-prefix "[LAN1_IN-default-D]"
-A LAN1_IN -m comment --comment "LAN1_IN-10000 default-action drop" -j DROP
-A VYATTA_FW_IN_HOOK -i eth0 -j WAN_IN
-A VYATTA_FW_IN_HOOK -i eth1 -j LAN1_IN
-A VYATTA_FW_LOCAL_HOOK -i eth0 -j WAN_LOCAL
-A VYATTA_FW_OUT_HOOK -o eth0 -j WAN_OUT
-A VYATTA_POST_FW_FWD_HOOK -j ACCEPT
-A VYATTA_POST_FW_IN_HOOK -j ACCEPT
-A VYATTA_POST_FW_OUT_HOOK -j ACCEPT
-A WAN_IN -m comment --comment WAN_IN-10 -m state --state ESTABLISHED -j RETURN
-A WAN_IN -m comment --comment WAN_IN-20 -m state --state RELATED -j RETURN
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j LOG --log-prefix "[WAN_IN-30-D]"
-A WAN_IN -m comment --comment WAN_IN-30 -m state --state INVALID -j DROP
-A WAN_IN -m comment --comment "WAN_IN-10000 default-action drop" -j DROP
-A WAN_LOCAL -m comment --comment WAN_LOCAL-10 -m state --state ESTABLISHED -j RETURN
-A WAN_LOCAL -m comment --comment WAN_LOCAL-20 -m state --state RELATED -j RETURN
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j LOG --log-prefix "[WAN_LOCAL-30-D]"
-A WAN_LOCAL -m comment --comment WAN_LOCAL-30 -m state --state INVALID -j DROP
-A WAN_LOCAL -m comment --comment "WAN_LOCAL-10000 default-action drop" -j LOG --log-prefix "[WAN_LOCAL-default-D]"
-A WAN_LOCAL -m comment --comment "WAN_LOCAL-10000 default-action drop" -j DROP
-A WAN_OUT -m comment --comment WAN_OUT-10 -m state --state NEW -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-20 -m state --state RELATED -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-30 -m state --state ESTABLISHED -j RETURN
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j LOG --log-prefix "[WAN_OUT-40-D]"
-A WAN_OUT -m comment --comment WAN_OUT-40 -m state --state INVALID -j DROP
-A WAN_OUT -m comment --comment "WAN_OUT-10000 default-action drop" -j LOG --log-prefix "[WAN_OUT-default-D]"
-A WAN_OUT -m comment --comment "WAN_OUT-10000 default-action drop" -j DROP

我选择@LL3 的答案是正确的，首先通过帖子。@LL3 的答案已被修改为能够读取标准输入，所以我删除了同样的补丁

<patch removed>

感谢 -master @JeffSchallerperl的（稍晚一点）完整的答案，显示了广度优先列表和单独的 graphviz输出。

我的邮件需求很简单。我只想通过非 SMTP 挂钩发送系统通知。（挂钩通过 https 发送到 mailgun 帐户）。

我想象所有的 linux 程序（例如 cron）调用类似“（发送）邮件 [选项] 内容”的东西。或者他们直接调用 SMTP 服务？

如果他们正在调用“（发送）邮件 [选项] 内容”，那么应该很容易改编/编写一个 shell 脚本或程序来将该调用转换为我的挂钩。

我确实找到了这个参考：

Linux 标准基础 PDA 规范 3.0RC1

概要 /usr/sbin/sendmail [选项] [地址...] 说明

要发送电子邮件（email），应用程序应支持 sendmail 提供的接口（在此处描述）。该接口应是应用程序的默认交付方法。

该程序向一个或多个收件人发送一封电子邮件，并根据需要路由该邮件。该程序不打算用作用户界面例程。

在没有选项的情况下，sendmail 读取其标准输入直到文件末尾或仅包含一个点的行，并将在那里找到的消息的副本发送到列出的所有地址。它根据地址的语法和内容确定要使用的网络。

如果地址前面有反斜杠“\”，则未指定地址是否受本地别名扩展的约束。

消息格式应符合 RFC 2822：Internet 消息格式中的定义。

选项

-bm
从标准输入读取邮件并将其发送到收件人地址。这是默认的操作模式。

... （ETC） ...

这就是我要找的吗？换句话说，调用了一个名为“sendmail”的程序，stdin 将是符合 RFC2882 的邮件内容。

注意：我知道有一个名为“nullmail”的程序，但我相信它使用我不想要的 SMTP 发送出站邮件。可能它可以适应 RFC2822 解析前端。

感谢@ivanivan 告知sendmail是事实上的接口。因此，要通过免费的 Mailgun帐户将所有通知发送到固定的电子邮件地址（并记录它），以下代码就足够了：

#!/bin/bash
Logfile=/var/log/sendmail-dummy.log
Tmpf=$(mktemp -t sendmail-dummy-XXXXXX.txt)
TmpCurlLog=$(mktemp -t sendmail-dummy-XXXXXX.txt)
trap 'rm -f ${Tmpf} ${TmpCurlLog}' 0

Date=$(date +%F-%T)
echo "[$Date] Caller: $(caller)" >>${Tmpf}
echo "[$Date] Caller: $0" >>${Tmpf}
echo "[$Date] Args: ${@}" >>${Tmpf}
echo "[$Date] Content:" >>${Tmpf}
while read line ; do
    echo $line  >>${Tmpf}
done
echo "" >>${Tmpf}

MailgunDomain="example.com"
# The key is assigned by Mailgun when signing up for free account 
Key="key-<some hex string>"
# not sure if the from-mail-addr has to belong to example.com
FromAddr="[email protected]"
# the to-mail-addr must be registered on Mailgun by showing you own it 
ToAddr="[email protected]"

curl -s --user "api:${Key}" "https://api.mailgun.net/v3/${MailgunDomain}/messages" \
     -F from=" <$FromAddr>" \
     -F to="${ToAddr}" \
     -F subject='Notification' \
     -F text="<${Tmpf}" > ${TmpCurlLog}
rc=$?

echo "----------------------------------------" >> ${Logfile}
echo "[$Date] curl result = $rc" >> ${Logfile}
cat ${Tmpf} >> ${Logfile}
echo "----------------------------------------" >> ${Logfile}
cat ${TmpCurlLog} >> ${Logfile}
echo "" >> ${Logfile}
echo "++++++++++++++++++++++++++++++++++++++++" >> ${Logfile}

可作为要点

可以看出，它不会尝试解释 sendmail args 或从正文中提取语义信息。只需将所有原始信息作为邮件正文的序言发送。

缺点是依赖于商业企业的免费、非开放软件服务，有朝一日可能会消失。但是，考虑到简单性，并没有真正的损失。

作为背景信息，我删除了postfix（sendmail 的替代品），因为它会导致重启时出现网络故障。这可能是使用systemd-nspawn. （systemd-nspawn顺便说一句，工作得很好）。考虑到sendmail功能对于发送系统通知的简单需求来说是多余的，我很高兴放弃sendmail功能以支持上述解决方案，并避免调试。

语境：

想要在特殊备份期间锁定etckeeper/apt挂钩活动。

目标是保持整个包的完整性，例如，等到任何包安装完成，然后在特殊备份完成之前阻止新的安装开始。

在cron下发现 shell 脚本似乎试图锁定

/var/cache/etckeeper/packagelist.pre-install

但实际上它不是原子执行的，所以它是有缺陷的。我认为cron shell 脚本是Ubuntu 16.04安装的一部分，而不是etckeeper版本的一部分。 有缺陷的锁码如下所示。

搜索有关用作锁定文件的etckeeper文档。/var/cache/etckeeper/packagelist.pre-install找不到任何文档。但是确实找到了一个脚本文件，它写入/var/cache/etckeeper/packagelist.pre-install而不将其视为锁定文件。此时我假设它/var/cache/etckeeper/packagelist.pre-install不打算用作etckeeper的锁定文件接口。 Etckeeper 内部脚本不 /var/cache/etckeeper/packagelist.pre-install视为锁定文件，如下所示。

问题 1：是否有（如果有的话）关于 etckeeper 锁定机制的文档，或开发人员门户以发出澄清请求？

在stackexchange网站上有很多关于使用

/var/lib/apt/lists/lock    (we call it apt lock below)

和

/var/lib/dpkg/lock     (we call it dpkg lock below)

分别作为apt和dpkg的锁。所有的通信都与卡住的锁有关，如何诊断它们，以及如何解开它们。但是，我发现没有引用官方apt和dpkg文档来指定这些锁定文件用作正式接口。

问题 2：是否有（如果有）关于apt锁定机制和/或dpkg锁定机制作为公共接口的文档？

有缺陷的锁定尝试 shell 脚本，可能由Ubuntu 16.04提供：

$ sudo cat /etc/cron.daily/etckeeper
#!/bin/sh
set -e
if [ -x /usr/bin/etckeeper ] && [ -e /etc/etckeeper/etckeeper.conf ]; then
    . /etc/etckeeper/etckeeper.conf
    if [ "$AVOID_DAILY_AUTOCOMMITS" != "1" ]; then
        # avoid autocommit if an install run is in progress
        lockfile=/var/cache/etckeeper/packagelist.pre-install
        if [ -e "$lockfile" ] && [ -n "$(find "$lockfile" -mtime +1)" ]; then
            rm -f "$lockfile" # stale
        fi
        if [ ! -e "$lockfile" ]; then
            AVOID_SPECIAL_FILE_WARNING=1
            export AVOID_SPECIAL_FILE_WARNING
            if etckeeper unclean; then
                etckeeper commit "daily autocommit" >/dev/null
            fi
        fi
    fi
fi

Etckeeper内部 shell scipt 写入packagelist.pre-install而不将其视为锁 - 因此我不认为它打算用作锁接口。

$ sudo cat /etc/etckeeper/pre-install.d/10packagelist 
#!/bin/sh
# This list will be later used when committing.
mkdir -p /var/cache/etckeeper/
etckeeper list-installed > /var/cache/etckeeper/packagelist.pre-install
etckeeper list-installed fmt > /var/cache/etckeeper/packagelist.fmt

我从“nmap -A”得到不直观的结果，我想澄清一下。

设置：sshd（ssh 守护程序服务）正在成功运行。postfix 已安装，因此 smpt 服务正在运行。但是，它只配置为发送邮件，而不是接收。未安装 apache，iptables 为空，未安装 ufw。

从这个主要的 nmap 文档来源： “关闭的端口没有应用程序监听它们”

问题：

是否有可能某些“过滤”结果实例也根本没有应用程序监听它们？还是“过滤”总是意味着还有其他原因？ （如果是后者，我想知道另一个原因是什么，这就是我问的原因。）

nmap -A xxxxxx.com

Starting Nmap 7.01 ( https://nmap.org ) at 2018-01-21 18:13 PST
Nmap scan report for xxxxxx.com (45.**.***.***)
Host is up (0.058s latency).
rDNS record for 45.**.***.***: li****-***.members.linode.com
Not shown: 995 closed ports
PORT    STATE    SERVICE      VERSION
22/tcp  open     ssh          OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 **** (RSA)
|_  256 **** (ECDSA)
25/tcp  filtered smtp
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

sudo lsof -i -n

COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd    3396    root    3u  IPv4  15205      0t0  TCP *:ssh (LISTEN)
sshd    3396    root    4u  IPv6  15214      0t0  TCP *:ssh (LISTEN)
master  4988    root   12u  IPv4  19670      0t0  TCP 127.0.0.1:smtp (LISTEN)
master  4988    root   13u  IPv6  19671      0t0  TCP [::1]:smtp (LISTEN)
sshd    5582    root    3u  IPv4  30352      0t0  TCP **.**.***.***:ssh->**.**.***.***:54224 (ESTABLISHED)
sshd    5602 izxzxzn    3u  IPv4  30352      0t0  TCP **.**.***.***:ssh->**.**.***.***:54224 (ESTABLISHED)

sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination