Craig Hicks's questions

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="[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}

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