Craig Hicks's questions

Acredito que esta seja a maneira correta de confirmar a integridade do pacote -

$ 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

No entanto, a página do site Debian https://packages.debian.org/sid/amd64/intel-microcode/download

com o título "Página de download para intel-microcode_3.20241112.1_amd64.deb em máquinas AMD64"

listas

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

Além disso, o tamanho é diferente

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

Obviamente, se o tamanho for diferente, a soma de verificação será diferente, mas eu verifiquei a soma de verificação antes de notar o tamanho.

Existe alguma explicação inocente para isso?

Após desbloquear o disco, a verborragia usual mudou e havia uma mensagem sobre baixar firmware. Quero descobrir o que estava acontecendo, então tentei 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 (debian-kernel@lists.debian.org) (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)

A mensagem do microcódigo é muito vaga. É incomum?

Como posso determinar qual firmware tenho, o que devo ter e o que está disponível?

Editar: topo do 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 <hmh@debian.org>  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 <hmh@debian.org>  Thu, 14 Nov 2024 15:37:40 -0300

Estou procurando um programa que pegue a saída iptables -Se a converta em uma listagem em largura .

Por quê? Estou fazendo um trabalho em um roteador usando VyOS onde várias camadas de tabelas são pré-instaladas, por isso é difícil rastrear todas as regras conectadas a INPUT, FORWARD e OUTPUT.

De acordo com o [solicitação] de @JeffSchaller, aqui está a saída de amostra que precisa ser analisada:

$ 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

Estou selecionando a resposta de @LL3 como correta, primeiro após a postagem. A resposta do @LL3 foi modificada para poder ler stdin, então eu removo o patch fazendo o mesmo

<patch removed>

Parabéns à resposta completa de perl-master @JeffSchaller (um pouco mais tarde) mostrando uma listagem ampla e separadamente uma saída do graphviz .

Minhas necessidades de correio são simples. Eu só quero enviar notificações do sistema por meio de um gancho não SMTP. (O gancho envia para uma conta mailgun por https).

Imagino todos os programas linux (por exemplo, cron) chamando algo como "(enviar) e-mail [opções] conteúdo". Ou eles estão chamando o serviço SMTP diretamente?

Se eles estiverem chamando "(enviar) e-mail [opções] conteúdo", deve ser fácil adaptar/escrever um script de shell ou programa para converter essa chamada para o meu gancho.

Encontrei esta referência :

Especificação de PDA Base Padrão Linux 3.0RC1

Sinopse /usr/sbin/sendmail [opções] [endereço...] Descrição

Para entrega de correio eletrônico (email), os aplicativos devem suportar a interface fornecida pelo sendmail (descrito aqui). Essa interface deve ser o método de entrega padrão para aplicativos.

Este programa envia uma mensagem de e-mail para um ou mais destinatários, roteando a mensagem conforme necessário. Este programa não se destina a ser uma rotina de interface do usuário.

Sem opções, o sendmail lê sua entrada padrão até um final de arquivo ou uma linha composta apenas por um único ponto e envia uma cópia da mensagem encontrada para todos os endereços listados. Ele determina as redes a serem usadas com base na sintaxe e no conteúdo dos endereços.

Se um endereço for precedido por uma barra invertida, '\', não será especificado se o endereço estiver sujeito à expansão de alias local.

O formato das mensagens deve ser conforme definido na RFC 2822: Formato de Mensagem da Internet.

Opções

-bm
lê o correio da entrada padrão e o entrega aos endereços dos destinatários. Este é o modo de operação padrão.

... (etc) ...

É isso que estou procurando? Em outras palavras, um programa chamado "sendmail" é invocado, e stdin será o conteúdo do correio compatível com RFC2882.

Obs: Eu sei que existe um programa chamado "nullmail" mas acredito que envia outbound usando SMTP, o que não quero. Pode ser adaptado para o front-end de análise RFC2822.

Obrigado a @ivanivan por informar que o sendmail é a interface de fato . Portanto, para enviar todas as notificações para um endereço de e-mail fixo por meio de uma conta gratuita do Mailgun (e registrá-la também), o seguinte código será suficiente:

#!/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="admin@example.com"
# the to-mail-addr must be registered on Mailgun by showing you own it 
ToAddr="somebody@somewhere.com"

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}

Disponível como uma essência

Como pode ser visto, ele não tenta interpretar argumentos do sendmail ou extrair informações semânticas do corpo. Apenas envia todas essas informações brutas como o preâmbulo do corpo do e-mail.

A desvantagem é depender do serviço de software livre e não aberto de um empreendimento comercial, que pode desaparecer algum dia. Mas, nenhuma perda real considerando a simplicidade.

Como informação de fundo, removi o postfix (uma substituição do sendmail) porque estava causando falha de rede na reinicialização. Isso aconteceu possivelmente como algum efeito colateral obscuro de ter executado uma máquina virtual com systemd-nspawn. ( systemd-nspawnfuncionou perfeitamente por sinal). Considerando que a funcionalidade do sendmail era um exagero pela simples necessidade de enviar notificações do sistema, fiquei feliz em descartar a funcionalidade do sendmail em favor da solução acima e evitar a depuração.

Contexto:

Deseja bloquear a atividade do etckeeper/apt hook durante o backup especial.

O objetivo é preservar a integridade do pacote inteiro, por exemplo, esperar até que a instalação de qualquer pacote seja concluída e impedir que uma nova instalação seja iniciada até que o backup especial seja concluído.

Shell script encontrado no cron que parece estar tentando bloquear

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

mas na verdade não é executado atomicamente e por isso é falho. Presumo que o cron shell script faça parte da instalação do Ubuntu 16.04 , não do lançamento do etckeeper . Código de bloqueio defeituoso mostrado abaixo.

Pesquisou a documentação do etckeeper sobre o uso de /var/cache/etckeeper/packagelist.pre-installum arquivo de bloqueio. Nenhuma documentação encontrada. Mas encontrei um pedaço de arquivo de script que grava /var/cache/etckeeper/packagelist.pre-installsem tratá-lo como um arquivo de bloqueio. Neste momento, estou presumindo que /var/cache/etckeeper/packagelist.pre-installnão se destina a servir como uma interface de arquivo de bloqueio para o etckeeper . Script interno do Etckeeper não tratando /var/cache/etckeeper/packagelist.pre-installcomo um arquivo de bloqueio mostrado abaixo.

Pergunta 1: Existe (e em caso afirmativo onde está) documentação sobre o mecanismo de bloqueio do etckeeper ou um portal de desenvolvedores para emitir um pedido de esclarecimento?

Há muitas perguntas e muita discussão nos sites stackexchange sobre o uso de

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

e

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

como bloqueios para apt e dpkg , respectivamente. Todas as comunicações dizem respeito a fechaduras emperradas, como diagnosticá-las e como destravá-las. No entanto, não encontro referências à documentação oficial do apt e dpkg especificando o uso desses arquivos de bloqueio como uma interface formal.

Pergunta 2: Existe (e em caso afirmativo onde está) documentação sobre o mecanismo de bloqueio do apt e/ou mecanismo de bloqueio do dpkg como interfaces públicas?

Script de shell de tentativa de bloqueio com falha, provavelmente fornecido pelo 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 interno escrevendo packagelist.pre-installe não tratando-o como um bloqueio - portanto, não acho que tenha sido planejado como uma interface de bloqueio.

$ 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

Obtenho resultados não intuitivos de "nmap -A" que quero esclarecer.

Configuração: sshd (ssh deamon service) está sendo executado com sucesso. o postfix está instalado e o serviço smpt está em execução. No entanto, ele só configurou para enviar e-mail, não para receber. apache não instalado, iptables vazio, ufw não instalado.

A partir desta fonte primária de documentação do nmap: "As portas fechadas não têm nenhum aplicativo escutando nelas"

A questão:

É possível que algumas instâncias de resultados "filtrados" simplesmente não tenham nenhum aplicativo ouvindo-as? Ou "filtrado" sempre significa que há algum outro motivo? (Se for o último, gostaria de descobrir qual é esse outro motivo, e é por isso que estou perguntando.)

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