Aaron's questions

Prefácio

Estamos testando alguns IPS baseados em host. Neste caso de teste, nosso aplicativo está escutando no loopback e o aplicativo está recebendo tráfego em texto não criptografado. Estamos usando nginx ou haproxy para encerrar o TLS na interface pública. Nosso IDP estará monitorando o loopback para que possa ver o tráfego não criptografado.

Nosso IDP estava vendo datas malformadas/incorretas, então começamos a cavar mais fundo.

[Atualização 2] Como o @kasperd mencionou, o tcpdump está obtendo os carimbos de data e hora do sistema operacional. Dito isso, acontece que esse bug está realmente atrapalhando o IDP, além do tcpdump. Ele vê o connection_established, mas não conseguiu ver uma sessão http válida, pois o syn-ack não é válido.

Um bug foi registrado em redhat.com e centos.org.

Observação

O primeiro syn-ack no loopback sempre tem uma data próxima ao início da época, ou dentro de 2 anos em VMs. Isso varia muito de dezembro de 1970 a fevereiro de 1973 em VMs e no futuro em servidores bare metal Xeon. O NTP está correto em todas as nossas VMs e servidores bare metal, com menos de 50ms de desvio.

Isso só acontece no loopback. Nunca vemos isso no bond0 nos servidores ou eth0 nas VMs.

Servidores de teste e laptops

SO: CentOS 7

Plataformas:

Servidores Dell 20 Core Xeon (sistema operacional de host bare metal)

Servidores HP 20 Core Xeon (sistema operacional de host bare metal)

VirtualBox no MacOS

Hyper-V no Windows 10 Enterprise no Lenovo P50 com 6 núcleos virtuais.

Um roteador baseado em Celeron 4 Core 1,6 GHz (não pode reproduzir no Celeron)

Passos para reproduzir

Em cada plataforma, iniciamos um web listener na porta 80 no loopback.

./simple_python 127.0.0.1 &

O código acima está aqui

Então iniciamos o tcpdump

tcpdump -p -NNnn -XXxx -tttt -vv -s0 -c2 -i lo &

Então nós enrolamos para localhost

curl -s -o /dev/null http://127.0.0.1/

Resultado

2018-04-10 21:05:30.087769 IP (tos 0x0, ttl 127, id 49233, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.25134 > 127.0.0.1.80: Flags [S], cksum 0xfe30 (incorrect -> 0xce27), seq 4053136920, win 65495, options [mss 65495,sackOK,TS val 22951497 ecr 0,nop,wscale 13], length 0
    0x0000:  0000 0000 0000 0000 0000 0000 0800 4500  ..............E.
    0x0010:  003c c051 4000 7f06 3d68 7f00 0001 7f00  .<.Q@...=h......
    0x0020:  0001 622e 0050 f195 f618 0000 0000 a002  ..b..P..........
    0x0030:  ffd7 fe30 0000 0204 ffd7 0402 080a 015e  ...0...........^
    0x0040:  3649 0000 0000 0103 030d                 6I........
1973-02-14 22:12:10.785902 IP (tos 0x0, ttl 127, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    127.0.0.1.80 > 127.0.0.1.25134: Flags [S.], cksum 0xfe30 (incorrect -> 0x2f28), seq 3928063281, ack 4053136921, win 65483, options [mss 65495,sackOK,TS val 22951497 ecr 22951497,nop,wscale 13], length 0
    0x0000:  0000 0000 0000 0000 0000 0000 0800 4500  ..............E.
    0x0010:  003c 0000 4000 7f06 fdb9 7f00 0001 7f00  .<..@...........
    0x0020:  0001 0050 622e ea21 7d31 f195 f619 a012  ...Pb..!}1......
    0x0030:  ffcb fe30 0000 0204 ffd7 0402 080a 015e  ...0...........^
    0x0040:  3649 015e 3649 0103 030d                 6I.^6I....

Em todos os casos, o syn-ack é sempre alguma data entre 1970 e 1973 nas VMs e no futuro nos Xeons.

• Consigo reproduzir isso 100% do tempo em cada uma das plataformas, exceto no Celeron. Não usamos Celerons no data center. Eu estava apenas tentando encontrar algo não afetado.

O que mais eu tentei fazer isso ir embora?

• Eu tentei fixar aplicativos em um núcleo usando taskset.
• Tentei configurar diferentes variáveis ​​que afetam a libc, como TZ, LANG, LC_ALL, etc...
• Eu tentei desabilitar todos os recursos de descarregamento da interface, apesar de ser um loopback e eles não deveriam fazer nada.
• Eu tentei algumas configurações diferentes de sysctl.
• Eu tentei usar snaplen diferente no tcpdump. (Estou ciente de alguns problemas históricos em torno do snaplength)
• Verifiquei que o relógio do hardware está correto.

O que eu não tentei

• Não tentei configurar o direcionamento do fluxo de recebimento, pois não faríamos isso em nossos data centers sem uma boa razão.
• Provavelmente há uma infinidade de outras coisas que eu poderia tentar, mas isso realmente parece um bug de condição de libc / buffer / race de algum tipo.

Algum pensamento sobre onde no código do Linux isso pode estar ocorrendo? Estou hesitante em mergulhar na glibc, pois não sou um desenvolvedor C.

[Atualização] Parece que @jackthecoiner encontrou onde outra pessoa está tendo esse problema e ainda não recebeu nenhum feedback no site da Redhat.

Por quê?

Meus serviços são iniciados por meio de arquivos de unidade apropriados ou scripts de inicialização. Não tenho necessidade de usuários regulares fazerem nada de especial em meus servidores além do su. Estou procurando especificamente uma maneira de desligar completamente o polkit sem que ele seja iniciado por conta própria quando outros serviços são reiniciados.

Prevejo um problema explicando isso também para os auditores em nosso ambiente PCI. Temos que descrever a finalidade de cada serviço. Não temos um caso de uso legítimo para polkit em um ambiente PCI.

Nota adicional: não instalei o polkit. Esses servidores têm uma instalação mínima em torno de 670 MB em / Foi uma atualização do systemd que parece ter instalado o polkit e a especificação aparentemente tem dependências de todos os serviços gerenciados do systemd. Uma vez instalado, tenho que reconstruir a máquina para removê-lo, assim como tentar removê- nsslo depois de instalá-lo. Minha preocupação é que, se eu forçar a desinstalação, isso pode ter deixado arquivos que tropeçarão no systemd que assume que está lá.

O que eu tentei:

Criar /etc/polkit-1/rules.d/99-deny-all.rulescom

polkit.addRule(function(action, subject) {
    return polkit.Result.YES;
});

Então

systemctl daemon-reload && systemctl daemon-reexec

Isso não faz nada, /usr/lib/polkit-1/polkitd --no-debugcontinua a iniciar quando outros serviços no systemd são reiniciados.

[Atualização] Como Alexander mencionou, reiniciar o polkit aplicará as configurações ao próprio polkit e isso é bom, mas estou procurando uma maneira de dizer ao polkit para não iniciar que não interrompa outros serviços.

[ atualização 2 ] Isso pode impedir que alguns serviços sejam reiniciados corretamente.

Mascare ou desative o serviço:

Isso faz com que outros serviços travem na inicialização e no desligamento, aguardando o polkit.

Editar /usr/share/dbus-1/sstem-services/org.freedesktop.PolicyKit1.servicecom:

[snip]
Exec=/bin/false
[snip]

Então

systemctl daemon-reload && systemctl daemon-reexec

Isso não faz nada, /usr/lib/polkit-1/polkitd --no-debugcontinua a iniciar quando outros serviços no systemd são reiniciados.

Eu li as páginas do manual algumas vezes. Provavelmente é algo muito simples que estou perdendo. Minha preferência seria por um método que persista após as atualizações do pacote systemd.

O objetivo final que estou procurando é que o polkit.service não inicie quando outros daemons forem reiniciados, como unbound, bind, dhcp, etc.

Declaração do problema

Eu tenho um servidor de cache e encaminhamento de ligação que está funcionando quase conforme o esperado. Todas as consultas são encaminhadas, seu TTL é armazenado em cache. À primeira vista, tudo parecia normal até que eu observei o tempo de resposta nunca cair abaixo dos 150ms da minha VPN.

Ao executar o tcpdump, descobri que, embora o bind estivesse ciente de que o TTL era maior que 0 (TTL de 14.000 neste caso), o resolvedor ainda estava encaminhando todas as solicitações. O TTL da resposta ainda diminui conforme o esperado , mas cada solicitação ainda é encaminhada upstream, independentemente do TTL restante no registro em cache.

Se eu desabilitar o encaminhamento, esse comportamento cessa e o cache funciona conforme o esperado.

Versão

Bind 9.9.4-29  (Redhat forked)
OS: CentOS 7

Partes relevantes da configuração

allow-query { local; };
recursion yes;
allow-recursion { local; };
max-cache-size unlimited;
stacksize unlimited;
datasize unlimited;

    zone "." IN {
    type forward;
    forward first;
    forwarders { 192.168.120.3; 192.168.120.2; };
    };

Eu tentei os dois forward first;e forward only;este resolvedor quase não tem carga e vários GB de memória disponíveis. A qualquer momento, ele nunca tem mais do que algumas centenas de registros armazenados em cache.

É provável que eu tenha uma expectativa errada de comportamento no bind? Usando o Unbound, não vi esse comportamento, mas gostaria de voltar a vincular por outros motivos.