Início / user-250204

anx's questions

Martin Hope
anx
Asked: 2019-02-09 19:52:53 +0800 CST
  • 6

Eu preciso substituir o ExecStartparâmetro de um modelo systemd . Confirmei que o arquivo de unidade existe e passa na validação. Adicionar um [email protected]/override.confarquivo funciona bem em algumas máquinas:

user@prod-west-1604$ systemctl --version | head -1
systemd 229
user@prod-west-1604$ file -b /etc/systemd/system/[email protected]
symbolic link to /lib/systemd/system/nginx.service

user@prod-west-1604$ sudo systemctl edit [email protected]
# (opens editor as expected)

No entanto, em máquinas que executam versões mais recentes do systemd, a operação falha:

user@prod-east-1810$ systemctl --version | head -1
systemd 239
user@prod-east-1810$ file -b /etc/systemd/system/[email protected]
symbolic link to /lib/systemd/system/nginx.service

user@prod-east-1810$ sudo systemctl edit [email protected]
Failed to get the load state of [email protected]: Unit name [email protected] is neither a valid invocation ID nor unit name.

Por quê ?

systemd
Martin Hope
anx
Asked: 2017-01-02 08:10:07 +0800 CST
  • 1

Meu servidor (linux) tem algumas regras de iptables bastante simples.

iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -m tcp -p tcp --dport https -j ACCEPT
iptables -A INPUT -j LOG
iptables -A INPUT -j NFLOG
iptables -A INPUT -j DROP

O ICMP não é filtrado, mas nenhuma outra conexão desnecessária é permitida. A regra NFLOG apenas armazena pacotes em um fule de captura de pacotes (pcap). Como o syslog ficou com bastante spam, examinei os detalhes dos pacotes.

tshark -V -a filesize:1 -r /scooby/doo.pcap(IPs e portas [replaced])

Frame 1: 52 bytes on wire (416 bits), 52 bytes captured (416 bits)
    Encapsulation type: Raw IP (7)
    [Protocols in frame: raw:ip:gre:ip:udp:data]
Internet Protocol Version 4, Src: [incoming IP] ([incoming IP]), Dst: [my server IP] ([my server IP])
    Version: 4
    Header length: 20 bytes
    Total Length: 52
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
    Time to live: 52
    Protocol: GRE (47)
Generic Routing Encapsulation (IP)
    Flags and Version: 0x0000
    Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: [not my IP1] ([not my IP1]), Dst: [not my IP2] ([not my IP2])
    Version: 4
    Header length: 20 bytes
    Total Length: 28
    Time to live: 64
    Protocol: UDP (17)
User Datagram Protocol, Src Port: [random port1] ([random port1]), Dst Port: [random port2] ([random port2])
    Length: 8

Os pacotes não solicitados são principalmente pacotes ip:gre:ip:udp. O volume de pacotes GRE - geralmente múltiplos por minuto - supera em muito outros pacotes não solicitados (scanners de vulnerabilidade / spammers / scanners de porta). Nenhum dos IPs dentro do encapsulamento GRE tem qualquer significado especial para mim, apenas vários IPs regulares pertencentes a (exclusivamente) empresas com sede nos EUA (portanto, endereços não totalmente aleatórios).

Por que alguém enviaria esses pacotes GRE?

Existem vulnerabilidades DoS conhecidas relacionadas a pacotes GRE? Isso é uma tentativa de enganar roteadores/servidores mal configurados para encaminhar os pacotes encapsulados para seu destino aparente? O remetente tenta coletar informações sobre a natureza dos possíveis túneis GRE que eu possa ter configurado?

Bônus: a reação mais razoável é realmente "-j DROP"?

iptables gre
Martin Hope
anx
Asked: 2015-08-10 10:49:54 +0800 CST
  • 1

Um site que mantenho é composto de vários aplicativos locais, todos com proxy da mesma instância nginx . Cada aplicativo está sendo executado sob seu próprio usuário e expondo um soquete unix gravável pelo grupo de servidores da web www-data.

Todos os usuários do aplicativo fazem parte do www-datagrupo, portanto podem chown seus soquetes. Como posso melhorar minha configuração, de modo que uma vulnerabilidade em um aplicativo não possa mais ser usada para tentar escalar privilégios por meio de conexões diretas com outros soquetes?

Minha solução anterior: crie um novo grupo para cada usuário e adicione o servidor da web a todos eles. Esta solução é menos preferível, pois complica a adição/remoção de aplicativos e requer uma reinicialização forçada do servidor da web para atualizar os grupos.

nginx
Martin Hope
anx
Asked: 2014-10-22 11:51:44 +0800 CST
  • 2

Uma instância do postfix at sub.example.comestá enviando e-mail para example.comvia LAN, que é um servidor de e-mail e um roteador:

Internet
|
|
203.0.113.1 
<example.com> (127.0.1.1 in /etc/hosts)
192.168.1.1
|
|
192.168.1.99
<sub.example.com>

Sempre que um e-mail da LAN é recebido, uma mensagem de aviso é registrada:

postfix/smtpd[1337]: aviso: hostname example.com não resolve para o endereço 203.0.113.1

No entanto , o domínio resolve para o endereço, com apenas um registro A (mas sem rdns):

# dig example.com
example.com.          3600   IN   A    203.0.113.1
# dig -x 203.0.113.1
..                       1   IN   PTR  new-customer.isp.example

Embora o DNS reverso NÃO esteja correto, não é isso que o aviso diz, nem explica por que ele é acionado apenas pelo correio da LAN. Conforme confirmado via tcpdump, o servidor de correio da LAN EHLOestá com sub.example.com- que é conhecido pelo servidor postfix como 192.168.1.99.

O que está acionando o aviso?

domain-name-system