Security (Português)

Status de tradução: Esse artigo é uma tradução de security. Data da última tradução: 2020-07-31. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

• Equipe de Segurança do Arch
• Recomendações gerais
• PAM
• Capacidades
• Lista de aplicativos/Segurança
• Diretrizes de segurança para pacotes

Este artigo contém recomendações e melhores práticas para aumentar a segurança de um sistema Arch Linux.

Conceitos

• É possível fortalecer a segurança do seu sistema tanto quanto o faz não usável. O truque é se proteger sem exagerar.
• Existem várias coisas que podem ser feitas para aumentar a segurança, mas a maior ameaça é, e sempre será, o usuário. Quando pensar em segurança, você precisa pensar em camadas. Quando uma é quebrada, a outra deve parar o ataque. Mas você nunca conseguirá fazer seu sistema 100% seguro a menos que o desconecte de todas as redes, guarde e nunca use ele.
• Seja um pouco paranoico. Isto ajuda. E duvide. Se qualquer coisa pareça muito boa para ser verdade, provavelmente o é!
• O princípio do privilégio mínimo: cada parte do sistema deve somente acessar o que precisa usar, e nada mais.

Senhas

Senhas são a chave para proteger seu sistema Linux. Elas protegem suas contas de usuário, sistema de arquivos criptografado, e chaves SSH/GPG. Elas são a maneira principal de permitir o acesso do computador, então grande parte da segurança é sobre escolher senhas seguras e protegê-las.

Escolhendo senhas seguras

Quando depender de uma senha, esta deve ser complexa o bastante para não ser facilmente adivinhada com, por exemplo, informação pessoal, ou quebrada usando métodos como ataques de força bruta. A base de uma senha forte são o tamanho e randomicidade. Na criptografia a qualidade de uma senha é referida como sua segurança entrópica.

Senhas inseguras possuem:

• Informações pessoais identificáveis (exemplo, o nome do seu cachorro, data de nascimento, CEP, jogo favorito)
• Substituição de caracteres simples em palavras (exemplo, k1araj0hns0n)
• Iniciais de palavras ou linhas comuns seguidas ou precedidas de números, símbolos ou caracteres (exemplo, DG091101%)
• Frases comuns ou curtas de palavras gramaticamente relacionadas (e.g. todas as luzes), e até mesmo com substituição de caracteres.
• Qualquer um das senhas mais populares

A melhor escolha para uma senha é algo longo (8-64 caracteres, quanto maior melhor) e gerada de uma fonte randômica.

Ferramentas como pwgen ou apg^AUR podem gerar senhas randômicas. No entanto, estas senhas podem ser difíceis de memorizar. Uma técnicas de memorização (para senhas geralmente digitadas) é gerar uma longa senha e memorizar um número mínimo seguro de caracteres, temporariamente escrevendo toda a senha em um papel. Com o passar do tempo, aumente o número de caracteres digitados - até que a senha esteja em sua memória muscular e não precisa ser lembrada. Esta técnica é mais difícil, mas pode oferecer confiança de que a senha não estará em listas de palavras ou ataques de força bruta "inteligentes" que combinam palavras e substituem caracteres.

Existem também técnicas para fazer senhas seguras e memorizáveis.

Uma das técnicas é fazer uso de uma frase mnemônica, onde cada letra na frase lembra o próximo caractere da senha. Por exemplo, “the girl is walking down the rainy street” pode ser traduzido para t6!WdtR5 ou, de forma menos simples, t&6!RrlW@dtR,57. Esta abordagem ajuda a se lembrar da senha, mas note que várias letras tem diferentes probabilidades de serem encontradas no início de palavras (Wikipedia:Frequência de letras).

Outra técnica é usar uma longa e memorizável série de palavras não relacionadas como uma senha. Se uma frase suficientemente longa é usada, a entropia ganhada do tamanho da senha pode compensar a perda de entropia do uso de palavras de dicionário. Este quadrinho do XKCD demonstra a troca de entropia desse método. O método de senha Diceware usa uma longa senha em combinação com um gerador randômico de números (jogo dos dados).

Outra efetiva técnica é escrever senhas geradas randomicamente em um papel e guardá-lo em um local seguro, como em uma carteira, bolsa ou cofre (para documentos). A maioria das pessoas geralmente faz um bom trabalho em proteger seus bens físicos de ataques, e é mais fácil para elas entender as melhores práticas de segurança física comparado com as digitais. Bruce Schneier aprova esta técnica.

É também muito efetivo combinar estas duas técnicas ao salvar senhas longas geradas randomicamente com um gerenciador de senhas, estas serão acessadas com uma "senha mestre" memorizável que deve ser usada somente para ele. A senha mestre deve ser memorizada e nunca salva. É necessário ter o gerenciador de senhas instalado para facilmente acessar as senhas (isto pode ser visto como uma inconveniência ou camada extra de segurança, dependendo da situação). Alguns gerenciadores possuem versões para smartphone que podem ser usadas para mostrar senhas, estas devem ser colocadas manualmente em sistemas sem o gerenciador de senhas. Note que isto inclui uma fraqueza, você não pode esquecer a senha mestre.

Veja o artigo (em inglês) de Bruce Schneier Escolhendo Senhas Seguras, o FAQ de senha ou Wikipedia:Password strength para conhecimento base adicional.

Mantendo senhas

Uma vez que escolher um senha forte, tenha certeza de mantê-la em segurança. Cuidado com keyloggers (software e hardware), screenloggers, engenharia social, olhar por cima do ombro, e evite reutilizar senhas para que servidores inseguros não vazem mais informação que o necessário. Gerenciadores de senha podem ajudar a gerenciar um grande número de senhas complexas: se você está copiando e colando senhas guardadas para os programas que precisam dela, limpe o buffer de cópia toda vez, e garanta que elas não são salvas em nenhum tipo de log (exemplo, não cole elas em comandos de texto puro do terminal que deve guardá-la em arquivos como .bash_history).

Como uma regra, não pegue senhas inseguras somente porquê as mais seguras são difíceis de se lembrar. Senhas são um ato de equilíbrio. É melhor ter um banco de dados criptografado com senhas seguras, guardadas atrás de uma chave e uma senha mestre forte, que ter várias senhas fracas similares. Escrevê-las é talvez igualmente efetivo [1], evitando potenciais vulnerabilidades nas soluções de software enquanto requer segurança física.

Outro aspecto de uma senha forte é que esta não deve ser facilmente recuperável de outros lugares.

Se você usa a mesma senha da criptografia do disco para seu login (útil para por exemplo, montar automaticamente a partição criptografada ou diretório no login), garanta que /etc/shadow também está na partição criptografada, ou usa um algoritmo de hash forte (exemplo, sha512/bcrypt, não md5) para a hash da senha guardada (veja SHA password hashes para mais informações).

Se você está fazendo backup do seu banco de dados de senhas, tenha certeza de que cada cópia não está guardada atrás de qualquer outra senha que está guardada dentro dela, por exemplo um disco criptografado ou um serviço autentificado de armazenamento remoto, você pode não conseguir acessá-lo em caso de necessidade; um truque útil é proteger os discos ou contas onde o banco de dados com uma hash criptográfica simples da senha mestre. Mantenha uma lista de todos os locais de backup: se um dia você teme que a senha mestre foi compromissada você vai ter de mudá-la imediatamente em todos os bancos de dados e localizações com chaves derivadas dela.

Controle de versão de forma segura em um banco de dados pode ser muito complicado: se decidir fazer isto, você deve ter uma maneira de atualizar a chave mestre de todos os bancos de dados que ela vazou. Pode não ser imediatamente percebível que a chave mestre foi vazada: para reduzir o risco de alguém descobrir sua senha antes de você saber que ela foi vazada, você pode mudá-la periodicamente. Se teme que você perdeu controle sobre alguma cópia do banco de dados, você vai precisar mudar todas as senhas contidas dentro do tempo que isto pode fazer o ataque de força bruta na chave mestre, de acordo com sua entropia.

Hashes de senha

Por padrão, Arch guarda as senhas com hash do usuário no arquivo, somente legível pelo root, /etc/shadow, separado de parâmetros de outro usuário guardado no arquivos, legível por todos, /etc/passwd, veja usuários e grupos#Base de dados de usuários. Veja também #Restringindo o root.

As senhas são configuradas com o comando passwd, que estica elas com a função crypt e então as salva em /etc/shadow. Veja também SHA password hashes. As senhas também são embaralhadas para defendê-las contra ataques tabela arco-íris.

Veja também How are passwords stored in Linux (Understanding hashing with shadow utils).

Forçando o uso de senhas fortes com pam_cracklib

pam_cracklib oferece proteção contra ataques de dicionário e ajuda a configurar uma política de senha que pode ser forçada pelo sistema.

Atenção: A conta root não é afetado por esta política.

Nota: Você pode usar a conta root para definir uma senha para um usuário que ignora a política desejada/configurada. Isto é útil quando definir senhas temporárias.

Se por exemplo você quer forçar esta política:

• solicitar duas vezes a senha em caso de erro (opção retry)
• tamanho mínimo de 10 caracteres (opção minlen)
• mínimo de 6 caracteres que devem ser diferentes da antiga senha quando usar uma nova (opção difok)
• mínimo de 1 dígito (opção dcredit)
• mínimo de 1 letra maiúscula (opção ucredit)
• mínimo de 1 letra minúscula (opção lcredit)
• mínimo de 1 outro caractere (opção ocredit)

Edite o arquivo /etc/pam.d/passwd:

#%PAM-1.0
password required pam_cracklib.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
password required pam_unix.so use_authtok sha512 shadow

O password required pam_unix.so use_authtok instrui o módulo pam_unix para não solicitar por uma senha e deixar essa tarefa para pam_cracklib.

Você pode ler as páginas man pam_cracklib(8)^{[link inativo 2020-09-13]} e pam_unix(8) para mais informações.

CPU

Microcódigo

Veja microcode para informações de como instalar atualizações importantes de segurança para o microcódigo da sua CPU.

Desabilitar hyper-threading

Se seu computador contém uma CPU Intel, desabilitar hyper-threading é uma consideração de segurança devido a Microarchitectural Data Sampling (microarquitetônica data de amostra), veja https://docs.kernel.org/admin-guide/hw-vuln/mds.html. O desenvolvedor do kernel Greg Kroah-Hartman aprova desabilitar Hyper-Threading como uma opção de fortalecer a segurança para sistemas rodando código não confiável, como navegadores que habilitam Javascript.

Para verificar se você é afetado, execute:

$ grep . -r /sys/devices/system/cpu/vulnerabilities/

Se a saída conter SMT vulnerable, você deveria desabilitar hyper-threading. Note que vai existir impacto no desempenho e você deve considerar se isto é aceitável.

Hyper-threading pode geralmente ser desabilitado no firmware do seu sistema. Consulte a documentação da sua placa-mãe ou sistema para mais informações. Você pode também desabilitar hyper-threading no kernel ao adicionar os seguintes parâmetros do kernel:

l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force

Depois reinicie e verifique a saída do grep que agora deve dizer SMT disabled.

Vulnerabilidades da CPU

Com o aparecimento das vulnerabilidades Spectre/Meltdown, certas mitigações configuráveis foram adicionadas ao kernel. Veja a documentação do kernel para mais detalhes.

Memória

Hardened malloc

hardened_malloc (hardened_malloc^AUR, hardened-malloc-git^AUR) é um substituto para o malloc() da glibc. O projeto foi originalmente desenvolvido para integração com Bionic do Android e musl por Daniel Micay, do GrapheneOS, mas também existe suporte a distribuições linux na arquitetura x86_64.

Enquanto hardened_malloc ainda não é integrado no glibc (ajuda e pull requests são bem vindos) pode ser facilmente usada com LD_PRELOAD. Em testes até agora, somente causa problemas com alguns programas se habilitado globalmente em /etc/ld.so.preload. Por exemplo, man pode deixar de funcionar apropriadamente a menos que sua opção de ambiente seccomp é desabilitada por não possuir getrandom na writelist padrão, apesar de que isto pode ser facilmente consertado ao compilar novamente com a chamada de sistema adicionada. Desde que hardened_malloc tem impacto no desempenho, você pode decidir que implementação usar de caso a caso baseado na superfície de ataque e necessidade de desempenho.

Para tentar usar isso de forma individual, use o script wrapper hardened-malloc-preload, ou manualmente inicie um programa com o valor apropriado do preload:

LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox

Uso apropriado com o Firejail pode ser encontrado em sua página da wiki, e algumas opções de compilação para o hardened_malloc podem ser encontradas no repositório do github.

Armazenamento

Criptografia de dados em repouso

Criptografia de dados em repouso, preferencialmente encriptação total de disco (FDE) com senha forte, é a única maneira de proteger seus dados contra recuperação física. Oferece segurança completa quando o computador está desligado ou os discos em questão estão desmontados.

No entanto, Uma vez que o computador está ligado e a unidade de armazenamento é montada, os dados se tornam tão vulneráveis quanto um disco não criptografado. É uma boa prática desmontar as partições de dados quando estas não são mais necessárias.

Certos programas, como dm-crypt, permitem ao usuário criptografar um arquivo de loop como um volume virtual. É uma alternativa razoável a encriptação total de disco quando somente certas partes do sistema precisam ser protegidas.

Sistemas de arquivos

O kernel agora previne problemas de segurança relacionados com hardlinks e symlinks se os switches do sysctl fs.protected_hardlinks e fs.protected_symlinks estão habilitados, então não é mais um grande benefício de segurança se separar de diretórios escritos por qualquer um.

Sistemas de arquivos que contém diretórios modificáveis por qualquer um podem ainda ser mantidos separados como uma maneira de limitar o dano de exaustão do espaço em disco. No entanto, encher /var ou /tmp é o bastante para derrubar serviços. Mecanismos mais flexíveis para lidar com esta preocupação existem (como quotas), e alguns sistemas de arquivos incluem funcionalidades relacionadas (Btrfs tem quotas em subvolumes).

Opções de montagem

Seguindo o princípio de privilégio mínimo, sistemas de arquivos devem ser montados com as opções de montagem mais restritivas e possíveis (sem perder funcionalidade).

Opções de montagem relevantes são:

• nodev: Não interprete caracteres ou dispositivos especiais de bloco no sistema de arquivos.
• nosuid: Não permita que bits de set-user-identifier ou set-group-identifier tomem efeito.
• noexec: Não permita a direta execução de qualquer binário no sistema de arquivos montado.
  • Definir noexec no /home desabilita scripts e quebra o Wine*, Steam PyCharm, etc.
  • Alguns pacotes (compilar nvidia-dkms por exemplo) podem precisar de exec no /var.

Nota: Wine não precisa do parâmetro exec para executáveis do Windows. Ele é somente necessário quando Wine é instalado no /home.

Sistemas de arquivos usados somente para dados devem sempre ser montado com nodev, nosuid e noexec.

Potenciais sistemas de arquivos a serem montados:

• /var
• /home
• /dev/shm
• /tmp
• /boot

Permissão de acesso a arquivos

As permissões de arquivos padrão permitem acesso de leitura para quase qualquer um, mudar permissões pode esconder informações valiosas de um atacante que ganha acesso a uma conta não root como os usuários http ou nobody.

Por exemplo:

# chmod 700 /boot /etc/{iptables,arptables}

O Umask 0022 padrão pode ser mudado para melhorar a segurança para novos arquivos. O Guia de Segurança da NSA RHEL5 (inglês) sugere um umask de 0077 para segurança máxima, que faz novos arquivos não serem legíveis para outros usuários que não sejam o dono dele. Para mudar isto, veja Umask#Definir o valor da máscara.

Configuração do usuário

Depois de instalar faça um usuário para uso diário. Não use o usuário root para isto.

Forçar um atraso depois de uma tentativa de entrar com a senha

Coloque a seguinte linha para /etc/pam.d/system-login, para adicionar um atraso de no mínimo 4 segundos entre tentativas de login:

/etc/pam.d/system-login

auth optional pam_faildelay.so delay=4000000

4000000 é o tempo em microsegundos.

Bloqueie o login de um usuário após 3 tentativas

Para aumentar a segurança do sistema é possível bloquear um usuário depois de um número especificado de tentativas de login. A conta do usuário pode continuar bloqueada até o usuário root desbloquear, ou automaticamente depois de um período de tempo definido.

Para bloquear um usuário por 10 minutos unlock_time=600 depois de três tentativas de login deny=3, adicione os parâmetros parra a configuração PAM como a seguir:

/etc/pam.d/system-login

auth required pam_tally2.so deny=3 unlock_time=600 onerr=succeed file=/var/log/tallylog

Isto é tudo o que é necessário. Se você se sentir com coragem, erre três vezes a sua senha de login. E então veja o que acontece. Para desbloquear um usuário manualmente faça:

# pam_tally2 --reset --user nome_do_usuário

unlock_time é especificado em segundos. Se você quer permanentemente bloquear um usuário após três tentativas remova unlock_time da linha. O usuário não vai conseguir logar até que o root desbloqueie a conta.

Limite a quantidade de processos

Em sistemas com muitos usuários, ou não confiáveis, é importante limitar o número de processos que cada um pode executar de uma vez só, prevenindo bombas fork e outros ataques de negação de serviço. /etc/security/limits.conf determina quantos processos cada usuário ou grupo pode abrir, e por padrão é vazio (exceto pelos comentários úteis). Adcionar as seguintes linhas para este arquivos vai limitar todos os usuários a 100 processos ativos, a menos que eles usem o comando prlimit para explicitamente aumentar o máximo para 200 por sessão. Estes valores podem ser modificados para um número apropriado de processos que um usuário deve ter acesso, ou hardware que você está administrando.

* soft nproc 100
* hard nproc 200

O atual número de threads para cada usuário pode ser encontrado com ps --no-headers -Leo user | sort | uniq --count. Isto pode ajudar a determinar os valores apropriados para os limites.

Execute Xorg sem root

Xorg é geralmente considerado inseguro devido a sua arquitetura e design datado. É recomendado não executá-lo como root.

Veja Xorg#Xorg sem root para mais detalhes de como executá-lo sem root. Alternativamente, use Wayland ao invés do Xorg.

Restringindo o root

O usuário root é, por definição, o usuário mais poderoso no sistema. Por isso, existe um número de maneiras de manter o poder do usuário root enquanto limita sua capacidade de causar danos, ou ao menos fazer suas ações mais rastreáveis.

Use sudo ao invés de su

Ao usar sudo para acesso privilegiado é preferível ao su por um número de razões.

• Mantém um log de cada comando com poderes administrativos que o usuário normal executou.
• A senha do usuário root não precisa ser dada para cada usuário que precisa de poderes administrativos.
• sudo previne usuários de acidentalmente executar comandos como root que não precisa de poderes administrativos. Isto é compatível com o princípio do privilégio mínimo.
• Programas individuais podem ser habilitados por usuário, ao invés de oferecer poderes administrativos somente para executar um comando. Por exemplo, para dar ao usuário alice acesso a um programa específico:

# visudo

/etc/sudoers

alice ALL = NOPASSWD: /caminho/do/programa

Ou, comandos individuais podem ser permitidos para todos os usuários. Para montar compartilhamento do Samba de um servidor como usuário normal:

%users ALL=/sbin/mount.cifs,/sbin/umount.cifs

Isto permite que todos os usuários que são membros do grupo users executem os comandos /sbin/mount.cifs e /sbin/umount.cifs de qualquer máquina (ALL).

Dica:

Para usar a versão restritiva do nano ao invês do vi com visudo,

/etc/sudoers

Defaults editor=/usr/bin/rnano

Fazer EDITOR=nano visudo é considerado como um severo problema de segurança desde que tudo pode ser usado como um EDITOR.

Editando arquivos usando sudo

Veja sudo#Editando arquivos. Alternativamente, use um editor como rvim ou rnano que tem capacidades restritivas para ser executado com segurança mesmo como root.

Restringindo o login do root

Uma vez que sudo está apropriadamente configurado, o acesso total a conta root pode ser pesadamente restrito ou negado sem perder muita usabilidade. Para desabilitar o root, mas ainda permitir o uso do sudo, você pode usar passwd --lock root.

Somente permita certos usuários

O pam_wheel.so do PAM deixa você permitir somente usuários no grupo wheel para logar usando o su. Veja su#su and wheel.

Negando login SSH

Até mesmo se você não deseja negar o login do root para usuário locais, é sempre uma boa prática negar o login do root pelo ssh. O objetivo é adicionar uma camada extra de segurança antes que um usuário possa completamente danificar seu sistema remotamente.

Especificar combinações de login aceitáveis com access.conf

Quando alguém tenta logar com PAM, /etc/security/access.conf é verificado para a primeira combinação equivalente as suas propriedades de login. Sua tentativa então falha ou tem sucesso baseado na regra para aquela combinação.

+:root:LOCAL
-:root:ALL

Regras podem ser definidas para grupos e usuários específicos. Neste exemplo, o usuário archie pode logar localmente, assim como todos os usuários no grupo wheel e adm. Todos os outros logins são rejeitados:

+:archie:LOCAL
+:(wheel):LOCAL
+:(adm):LOCAL
-:ALL:ALL

Leia mais em access.conf(5)

Controle de acesso mandatório

Controle de Acesso Mandatório (MAC, Mandatory Access Control em inglês) é o tipo de política de segurança que se difere significativamente do controle de acesso discricionário (DAC, discretionary access control em inglês) usado por padrão no Arch e a maioria das distribuições Linux. MAC essenciamente significa que cada ação que afeta o sistema de alguma maneira é verificada com um conjunto de regras de segurança. Ela, em contraste com métodos do DAC, não pode ser modificada pelos usuários. Usar virtualmente qualquer sistema de controle de acesso mandatório vai melhorar significantemente a segurança do seu computador, apesar de existirem diferenças em como cada um é implementado.

Pathname MAC

Controle de acesso baseado no caminho (pathname) é uma forma simples de controle de acesso que oferece permissões baseadas no caminho de dado arquivo. Sua desvantagem é que permissões não são carregadas com arquivos se eles são movidos do sistema. A vantagem é que isto pode ser implementado em uma grande variedade de sistemas de arquivos, diferente das alternativas baseadas em labels.

• AppArmor é uma implementação MAC mantida pela Canonical vista como uma alternativa "mais fácil" ao SELinux.
• Tomoyo é outro simples, fácil de usar, sistema que oferece controle de acesso mandatório. É pensado para ser simples no uso e em implementação, precisando de poucas dependências.

Labels MAC

Controle de acesso baseado em Labels significa que os atributos extendidos de um arquivo são usados para governar suas permissões de segurança. Enquanto este sistema é discutívelmente mais flexível em suas ofertas de segurança que o baseado em pathname MAC, somente funciona em sistemas de arquivos que suportam estes atributos extendidos.

• SELinux, baseado em um projeto NSA para melhorar a segurança do Linux, implementa MAC completamente separado do sistema de usuários e seus cargos. Oferece uma extremamente robusta política de MAC multinível cujo controle pode ser facilmente mantido em um sistema que cresce e muda sua configurações iniciais.

Listas de controle de acesso

Listas de Controle de Acesso (Access Control Lists, ACLs) são uma alternativa para adicionar regras diretamente para o sistema de arquivos. ACLs implementam o controle de acesso ao verificar ações de programas contra uma lista de comportamentos permitidos.

Deixando o kernel mais seguro

Auto proteção / Exploração de mitigações do kernel

O pacote linux-hardened usa um conjunto básico de patches para deixar o kernel mais seguro e mais opções de configuração, em tempo de compilação, focadas em segurança do que o pacote linux. Customização, por meio de compilação, pode ser feita para escolher um diferente relação entre segurança e desempenho do que o padrão focado em segurança.

No entanto, alguns pacotes não funcionarão quando este kernel é usado. Por exemplo:

• skypeforlinux-bin^AUR
• throttled

Se você usa um driver não incluído no kernel como NVIDIA, você vai precisar mudar para seu pacote DKMS.

Comparação do ASLR do userspace

O pacote linux-hardened oferece uma implementação melhorada da randomização do layout do espaço de endereçamento (Address Space Layout Randomization, ASLR) para processos do userspace. O comando paxtest pode ser usado para obter uma estimativa da entropia provida:

Processos 64-bit

linux-hardened 5.4.21.a-1-hardened

Anonymous mapping randomization test     : 32 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 40 quality bits (guessed)
Heap randomization test (PIE)            : 40 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 32 quality bits (guessed)
Main executable randomization (PIE)      : 32 quality bits (guessed)
Shared library randomization test        : 32 quality bits (guessed)
VDSO randomization test                  : 32 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 40 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 40 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 44 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 44 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)
Randomization under memory exhaustion @~0: 32 bits (guessed)
Randomization under memory exhaustion @0 : 32 bits (guessed)

linux 5.5.5-arch1-1

Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 20 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 29 bits (guessed)
Randomization under memory exhaustion @0 : 29 bits (guessed)

linux-lts 4.19.101-1-lts

Anonymous mapping randomization test     : 28 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 28 quality bits (guessed)
Heap randomization test (PIE)            : 28 quality bits (guessed)
Main executable randomization (ET_EXEC)  : 28 quality bits (guessed)
Main executable randomization (PIE)      : 28 quality bits (guessed)
Shared library randomization test        : 28 quality bits (guessed)
VDSO randomization test                  : 19 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 30 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 30 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 22 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 22 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0 : 28 bits (guessed)

processos 32-bit (em um kernel x86_64)

linux-hardened

Anonymous mapping randomization test     : 16 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 22 quality bits (guessed)
Heap randomization test (PIE)            : 27 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 18 quality bits (guessed)
Shared library randomization test        : 16 quality bits (guessed)
VDSO randomization test                  : 16 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 24 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 24 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 28 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 28 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)
Randomization under memory exhaustion @~0: 18 bits (guessed)
Randomization under memory exhaustion @0 : 18 bits (guessed)

linux

Anonymous mapping randomization test     : 8 quality bits (guessed)
Heap randomization test (ET_EXEC)        : 13 quality bits (guessed)
Heap randomization test (PIE)            : 13 quality bits (guessed)
Main executable randomization (ET_EXEC)  : No randomization
Main executable randomization (PIE)      : 8 quality bits (guessed)
Shared library randomization test        : 8 quality bits (guessed)
VDSO randomization test                  : 8 quality bits (guessed)
Stack randomization test (SEGMEXEC)      : 19 quality bits (guessed)
Stack randomization test (PAGEEXEC)      : 19 quality bits (guessed)
Arg/env randomization test (SEGMEXEC)    : 11 quality bits (guessed)
Arg/env randomization test (PAGEEXEC)    : 11 quality bits (guessed)
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)
Randomization under memory exhaustion @~0: No randomization
Randomization under memory exhaustion @0 : No randomization

Restringindo acesso a logs do kernel

Os logs do kernel contém informações úteis para um atacante tentando explorar vulnerabilidades do kernel, como endereços sensíveis da memória. A opção kernel.dmesg_restrict proíbe o acesso a logs sem a capacidade CAP_SYS_ADMIN (que somente processos executados pelo root tem por padrão).

/etc/sysctl.d/51-dmesg-restrict.conf

kernel.dmesg_restrict = 1

Dica: Isto é habilitado por padrão no linux-hardened.

Restrigindo acesso a ponteiros do kernel no sistema de arquivos proc

Definir kernel.kptr_restrict para 1 vai esconder os símbolos de endereços do kernel em /proc/kallsyms de usuários comuns sem CAP_SYSLOG, dificultando a exploração do kernel para resolver endereços/símbolos dinamicamente. Isto não será de muita ajuda em um kernel Arch Linux pré-compilado, desde que um atacante determinado pode simplesmente baixar o kernel e conseguir os símbolos manualmente, mas se você está compilando seu próprio kernel, isto pode auxiliar na mitigação da exploração local da raiz. Isto vai quebrar alguns comandos do perf quando usado por usuários que não são o root (mas muitas funcionalidades do perf precisam de privilégios root de qualquer maneira). Veja FS#34323 para mais detalhes.

Definir kernel.kptr_restrict para 2 esconderá símbolos de endereços do kernel em /proc/kallsyms independente de privilégios.

/etc/sysctl.d/51-kptr-restrict.conf

kernel.kptr_restrict = 1

Nota: linux-hardened define kptr_restrict=2 por padrão ao invês do 0.

Deixando o BPF mais seguro

BPF é um sistema usado para carregar e executar bytecode dentro do kernel dinamicamente durante sua execução. É usado em um número de subsistemas do kernel Linux como rede (ex., XDP, tc), rastreamento (ex., kprobes,uprobes, tracepoints) e segurança (ex., seccomp). É também útil para segurança de rede avançada, criação de perfil de desempenho e rastramento dinâmico.

BPF foi originalmente um acrônimo de Berkeley Packet Filter (filtrador de pacotes Berkeley) desde que o BPF clássico original foi usado para ferramentas capturadoras de pacotes para BSD. Eventualmente evoluiu para Extended BPF (eBPF), que brevemente depois foi renomeado para somente BPF (não um acrônimo). BPF não deve ser confundido com ferramentas de filtro de pacotes como iptables ou netfilter, apesar que ele pode ser usado para implementar elas.

O código do BPF pode ser tanto interpretado quanto compilado usando um compilador Just-In-Time (JIT). O kernel do Arch é compilado com CONFIG_BPF_JIT_ALWAYS_ON que desabilita o interpretador do BPF e força todo BPF a usar compilação JIT. Isto dificulta o uso do BPF para escalar ataques que exploram vulnerabilidades no estilo do SPECTRE por atacantes. Veja o patch do kernel que introduziu CONFIG_BPF_JIT_ALWAYS_ON para mais detalhes.

O kernel inclui uma funcionalidade que aumenta a segurança para BPF compilado com o JIT que pode mitigar alguns tipos de ataques de injeção de JIT ao custo de desempenho e a habilidade de rastrear e debugar muitos programas BPF. Pode ser habilitado ao definir net.core.bpf_jit_harden para 1 (habilita maior segurança para código sem privillégios) ou 2 (habilita maior segurança para todo o código).

Veja as configurações net.core.bpf_* na documentação do kernel para mais detalhes.

Dica: linux-hardened define net.core.bpf_jit_harden=2 por padrão ao invês de 0.

Escopo do ptrace

A chamada do sistema ptrace(2) oferece uma forma pela qual um processo (o "tracer") pode observar e controlar a execução de outro processo (o "tracee"), examinar e mudar a memória e registradores do tracee. ptrace é geralmente usado por ferramentas de depuração incluindo gdb, strace, perf, reptyr e outras. No entanto, isto também oferece uma forma de que processos maliciosos possam ler dados e controlar outros processos.

Arch habilita o Yama LSM por padrão, que oferece um parâmetro do kernel kernel.yama.ptrace_scope. Este parâmetro é definido para 1 (restrito) por padrão que previne tracers de executar uma chamada ptrace nos tracees fora de um escopo restrito a menos que o tracer é privilegiado ou tem a capacidade CAP_SYS_PTRACE. Isto é uma melhora significante na segurança comparado com as permissões clássicas. Sem este módulo, não há separação entre processos sendo executados pelo mesmo usuário (na falta de camadas de segurança adicionais como pid_namespaces(7)).

Nota: Por padrão, você pode ainda considerar o uso de ferramentas que precisam do ptrace ao executar eles com privilégios, e.x. usando sudo.

Se você não precisa usar ferramentas de depuração, considere definir kernel.yama.ptrace_scope para 3 (somente admin) ou 4 (ptrace não é possível) para aumentar a segurança do sistema.

hidepid

Atenção:

• Isto pode causar problemas para certas aplicações como um programa sendo executado em uma sandbox e Xorg (veja a resolução abaixo).
• Isto causa problemas com D-Bus, PulseAudio e bluetooth quando usam systemd > 237.64-1.

O kernel tem a habilidade de esconder processos de outros usuários, normalmente acessíveis pelo /proc, de usuários sem privilégios ao montar o sistema de arquivos proc com as opções hidepid= e gid=, documentada em https://docs.kernel.org/filesystems/proc.html.

Isto grandemente complica a tarefa de um intruso de conseguir informações sobre os processo em execução, se alguns serviços são executados com privilégios elevados, se outros usuários executam algum programa sensível, se outros usuários executam qualquer programa, impossibilita saber se qualquer usuário executa um programa específico (dado que o programa não se revela por seu comportamento), e, como bônus, programas mal escritos que passam informação sensível por argumentos são agora protegidos contra bisbilhoteiros locais.

O grupo proc, provido pelo pacote filesystem, age como uma whitelist de usuários autorizados a possuir acesso a informações de processos de outros usuários. Se usuários ou serviços precisam de acesso a diretórios em /proc/<pid> fora de seu próprio, adicione eles para o grupo.

Por exemplo, para esconder informações de processos de outros usuários exceto os do grupo proc:

/etc/fstab

proc	/proc	proc	nosuid,nodev,noexec,hidepid=2,gid=proc	0	0

Para sessões de usuário funcionarem corretamente, uma exceção deve ser adicionada para o systemd-logind:

/etc/systemd/system/systemd-logind.service.d/hidepid.conf

[Service]
SupplementaryGroups=proc

Restrigindo o carregamento de módulos

O kernel padrão do Arch vem com CONFIG_MODULE_SIG_ALL habilitado que assina todos os módulos do kernel compilados como parte do pacote linux. Permitindo a restrição de módulos, onde estes podem somente ser carregados quando eles são assinados com uma chave válida, em termos práticos isto significa que todos os módulos fora da árvore de módulos compilada localmente ou oferecida por pacotes, como virtualbox-host-modules-arch não podem ser carregados. O carregamento de módulos do kernel pode ser restringido ao definir o parâmetro do kernel module.sig_enforce=1. Mais informação pode ser encontrada na documentação do kernel.

Desabilitar o kexec

Kexec permite trocar o atual kernel em execução.

/etc/sysctl.d/51-kexec-restrict.conf

kernel.kexec_loaded_disabled = 1

Dica: kexec é desabilitado por padrão no linux-hardened.

Modo lockdown do kernel

Desde o Linux 5.4 o kernel ganhou uma funcionalidade de lockdown opcional, com o objetivo de fortalecer a barreira entre UID 0 (root) e o kernel. Quando habilitado algumas aplicações podem deixar de funcionar se elas dependerem de acesso de baixo nível do hardware ou do kernel.

Para usar o modo lockdown, seu LSM deve ser inicializado, verifique isto ao executar cat /sys/kernel/security/lsm. Se a saída não ter lockdown, defina o parâmetro do kernel lsm=lockdown,yama e reinicie.

Lockdown tem dois modos de operação:

• integrity: funcionalidades do kernel que permitem que usuários modifiquem o kernel em execução são desabilitadas (kexec, bpf).
• confidentiality: funcionalidades do kernel que permitem que usuários extraiam informações confidenciais do kernel são também desabilitadas.

Para habilitá-lo, execute:

# echo modo > /sys/kernel/security/lockdown

Para habilitá-lo na inicialização, use o parâmetro do kernel lockdown=modo.

Nota:

• O lockdown do kernel não pode ser desabilitado durante sua execução.
• O lockdown do kernel desabilita a hibernação.

Aplicações sandbox

Veja também Wikipedia:Sandbox (computer security).

Nota: O item de configuração CONFIG_USER_NS do namespace do usuário está atualmente habilitado no linux (4.14.5 ou posterior), linux-lts (4.14.15 ou posterior) e linux-hardened. Sua falta faz com que certas funcionalidades sandbox não estejam disponíveis para as aplicações.

Atenção: Uso não privilegiado do namespace do usuário CONFIG_USER_NS_UNPRIVILEGED) é habilitado por padrão no linux (5.1.8 ou posterior), linux-lts (4.19.55-2 ou posterior) e linux-zen (5.1.14.zen1-2 ou posterior) a menos que o sysctl kernel.unprivileged_userns_clone esteja definido como 0. Desde que isto aumenta grandemente a superfície de ataque para escalonamento de privilégios locais, é recomendado desabilitar isto manualmente ou usar o kernel linux-hardened. Para mais informações veja FS#36969.

Firejail

Firejail é uma ferramenta fácil e simples de usar para programas e servidores sandbox. Firejail é sugerido para navegadores e programas que usam internet, como também para qualquer servidor que você pode estar executando.

bubblewrap

bubblewrap é uma aplicação sandbox desenvolvida do Flatpak com um uso de recursos menor do que o Firejail. Enquanto não possui certas funcionalidades como fazer whitelist de caminhos de arquivos, bubblewrap oferece ligação de montagem como também a criação de namespaces do user/IPC/PID/network/cgroup e suporta sandboxes complexas e simples.

chroot

Encasulamento manual chroot também pode ser feito.

Containers do Linux

Containers do Linux são outra boa opção quando você precisa de mais separação que outras opções como KVM e VirtualBox() oferecem. LXC é executado em cima do kernel existente em um pseudo-chroot com seu próprio hardware virtual.

Outras opções de virtualização

Usar opções de total virtualização como VirtualBox, KVM, Xen ou Qubes OS (baseado no Xen) pode também melhorar a isolação e segurança caso você queira executar programas arriscados ou navegar sites perigosos.

Rede e firewalls

Firewalls

Enquanto o kernel do Arch é capaz de usar o iptables do Netfilter e nftables, eles não são habilitados por padrão. É altamente recomendado configurar alguma forma de firewall para proteger os serviços em execução no sistema. Muitos recursos (incluindo ArchWiki) não dizem explicitamente que serviços vale a pena proteger, então habilitar um firewall é uma boa precaução.

• Veja iptables e nftables para informações gerais.
• Veja Simple stateful firewall para um guia de como configurar um firewall com iptables.
• Veja Category:Firewalls para outras maneiras de configurar filtro de rede.
• Veja Ipset para bloquear listas de endereços ip, tais como estes da Bluetack.

Parâmetros do kernel

Parâmetros do kernel que afetam a rede podem ser definidos usando Sysctl. Para como fazer isto veja Sysctl#TCP/IP stack hardening.

SSH

Para mitigar ataques de força bruta é recomendado aplicar autentificação baseada em chave. Para OpenSSH, veja OpenSSH#Force public key authentication. Alternativamente Fail2ban ou Sshguard oferecem formas de proteção menores ao monitorar logs e escrever regras de firewall mas abrem a possibilidade de ataques de negação de serviço, desde que um atacante pode fraudar pacotes como se eles fossem do administrador depois de indentificar seu endereço. Existem linhas de defesa contra isso, tais como filtragem de caminho reverso e desabilitar redirecionamento ICMP.

Você pode querer fortalecer a autentificação ainda mais ao usar autentificação de dois fatores. Google Authenticator oferece um procedimento de autentificação de dois fatores usando senhas de uso único (one-time passcodes, OTP).

Negar o login do root também é uma boa prática, ambos para rastreiar instruções e adicionar uma camada adicional de segurança antes do acesso root. Para OpenSSH, veja OpenSSH#Deny.

DNS

Solicitações DNS são, por padrão na maioria dos sistemas, enviadas e recebidas de forma não criptografada e sem verificar a autenticidade do que foi recebido em servidores qualificados. Isto possibilita ataques man-in-the-middle, onde um atacante intercepta suas solicitações DNS e modifica as respostas para entregar um endereço IP que leva a uma página de phishing para coletar informações valiosas. Nem você nem o navegador ou outro software deve estar ciente se isto acontecer desde que o protocolo DNS confia na legitimidade dos resultados da solicitação sem nenhuma verificação.

DNSSEC é um conjunto de padrões que precisa que os servidores DNS providam clientes com autentificação de origem de dados do DNS, autentificação de negação de existência, e integridade de dados. No entanto, ainda não é amplamente utilizado. Com DNSSEC habilitado, um atacante não pode fazer modificações nas suas solicitações DNS e retornar resultados, mas deve ainda conseguir lê-las.

DNSCrypt, como também o desenvolvimento posterior de protocolos alternativos como DNS over TLS e DNS over HTTPS, usa criptografia para comunicações seguras com servidores DNS. Normalmente somente um protocolo é empregado em um nível de sistema. Veja Resolução de nome de domínio#Servidores DNS para softwares suportados.

Se você tem um nome de domínio, defina uma política Sender Policy Framework para combater fraude de email.

Proxies

Proxies são normalmente usadas como uma camada extra entre aplicações e a rede, limpando dados de fontes não confiáveis. A superfície de ataque de um pequeno proxy executado com baixos privilégios é significamente menor que uma aplicação complexa com privilégios do usuário final.

Por exemplo, o resolvedor DNS é implementado na glibc, que é linkada com a aplicação (que pode estar sendo executada como root), então um bug no resolvedor DNS pode levar a execução de código remota. Isto pode ser previnido ao instalar um servidor de cache DNS, como dnsmasq, que age como um proxy. [2]

Gerenciando certificados SSL

Veja OpenSSL e Network Security Services (NSS) para gerenciar certificados SSL customizados do lado do servidor. Notavelmente, o projeto relacionado Let’s Encrypt também é suportado.

As cadeias de confiança padrão de certificados SSL da internet são providas pelo pacote ca-certificates e suas dependências. Note que Arch depende de fontes confiáveis (exemplo, ca-certificates-mozilla) provendo certificados a serem confiados por padrão pelo sistema.

Pode ter ocasiões onde você quer se afastar do padrão. Por exemplo, você pode ler algumas noticias e fazer que um certificado seja considerado como não confiável do que esperar até os provisores confiáveis o façam. A inflaestrutura do Arch faz isto simples:

1. Obter o certificado respectivo no formato .crt (Exemplo: view, download; caso seja um Autoridade Certificadora Raiz, você pode também encontrá-lo no caminho do seu sistema),
2. Copie isto para /etc/ca-certificates/trust-source/blacklist/ e
3. Execute update-ca-trust como root.

Para verificar se a blacklist funcionou como desejado, você pode reabrir seu navegador preferido e usar a GUI dele para ver isso, que deve mostrar o certificado como untrusted (ou não confiável).

Segurança física

Acesso fisíco a um computador é acesso a seu sistema com bastante tempo e recursos. No entanto, um alto nível prático de segurança pode ser obtido ao colocar uma quantidade suficiente de barreiras.

Um atacante pode ganhar controle total do seu computador na sua próxima inicialização ao simplesmente colocar um IEEE 1394 (FireWire), Thunderbolt ou dispositivo PCI Express malicioso, já que eles dão total acesso a memória.[3] Existe pouco que você pode fazer para prevenir isso, ou a modificação do próprio hardware - tal como firmware malicioso em um disco. No entanto, a maioria dos atacantes não irão ter este nível de conhecimento e determinação.

#Criptografia de dados em repouso irá prevenir acesso a seus dados se o computador é roubado, mas firmware malicioso pode ser instalado para obter estes dados no seu próximo login por um atacante com recursos.

Fechando a BIOS

Adicionar uma senha na BIOS previne alguém de inicializar uma mídia removível, que é basicamente o mesmo que ter acesso a sua conta root. Você deve ter certeza que o seu disco é o primeiro na ordem de boot e desabilitar os outros discos de serem bootáveis se puder.

Gerenciadores de boot

É muito importante proteger seu gerenciador de boot. Um gerenciador de boot não protegido pode passar qualquer restrições de login, ao definir o parâmetro do kernel init=/bin/sh para inicializar diretamente para um shell.

Syslinux

Syslinux suporta o uso de senhas. Permitindo a definição de uma senha por item do menu ou uma senha global.

GRUB

GRUB suporta senhas no gerenciador de boot também. Veja GRUB/Tips and tricks#Password protection of GRUB menu para detalhes. Também tem suporte a /boot criptografado, que somente deixa algumas partes do código não criptografado. A configuração do GRUB, kernel e initramfs são criptografadas.

Partição de boot em um dispositivo removível

Uma ideia popular é colocar a partição de boot em um dispositivo removível para fazer o sistema não bootável sem ele. Usuários desta ideia geralmente usam encriptação total de disco, e alguns também usam cabeçalhos de encriptação desanexado na partição de boot.

Este método pode também ser unido com /boot criptografado.

Deslogar automaticamente

Se você está usando bash ou Zsh, você pode definir TMOUT para se deslogar automaticamente dos shells depois de um período determinado.

O exemplo a seguir vai automaticamente se desconectar dos consoles virtuais (mas não emuladores de terminal no X11):

/etc/profile.d/shell-timeout.sh

TMOUT="$(( 60*10 ))";
[ -z "$DISPLAY" ] && export TMOUT;
case $( /usr/bin/tty ) in
	/dev/tty[0-9]*) export TMOUT;;
esac

Se você realmente quer isso aconteça com TODO login Bash/Zsh (até mesmo dentro do X), use:

$ export TMOUT="$(( 60*10 ))";

Note que isto não vai funcionar se existe algum comando sendo executado no shell (exemplo: uma sessão SSH ou outro shell sem suporte a TMOUT). Mas se você está usando VC majoritariamente para reiniciar o GDM/Xorg congelados como root, então isto é útil.

Proteja-se contra dispositivos USB maliciosos

Instale USBGuard, um framework de software que ajuda na proteção do seu computador contra dispositivos USB maliciosos (como BadUSB^{[link inativo 2021-11-19 ⓘ]}, PoisonTap ou LanTurtle) ao implementar uma whitelist e blacklist de capacidades baseada nos atributos do dispositivo.

Pacotes

Autentificação

Ataques em gerenciadores de pacotes são possíveis sem uso apropriado de assinatura de pacotes, e pode afetar até mesmo gerenciadores de pacotes em sistemas com assinatura apropriada. Arch usa assinatura de pacotes por padrão e depende de uma rede de confiança de 5 chaves mestre. Veja Pacman-key para detalhes.

Atualizações

É importante regularmente atualizar o sistema.

Siga alertas de vulnerabilidades

Se subscreva nas atualizações de alerta de segurança de vulnerabilidades comuns e explosição (CVE, Common Vulnerabilities and Exposure), disponibilizadas pelo banco de dados de vulnerabilidades nacionais(NVD, National Vulnerability Database), que pode ser encontrada na página de download do NVD. O Arch Linux Security Tracker serve como um recurso particularmente útil que combina o Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) e conjuntos de dados do CVE em forma tabular. Veja também Equipe de Segurança do Arch.

Também considere se subscrever nas notificações de novas versões do software que você usa, especialmente se você instala software por meios diferentes dos repositórios principais ou AUR. Alguns softwares tem mailing lists onde você pode se inscrever para notificações de segurança. Sites que hospedam código fonte podem oferecer feeds RSS para novas versões.

Recompilando pacotes

Pacotes podem ser compilados novamente para remover funções e funcionalidades não desejadas como uma forma de diminuir a superficie de ataque. Por exemplo, bzip2 pode ser recompilado sem bzip2recover para evitar CVE-2016-3189. Opções para aumentar a segurança podem ser também aplicadas manualmente ou por meio de um facilitador.

Veja também

• Arch Linux Security Tracker
• CentOS Wiki: OS Protection
• Hardening the Linux desktop
• Hardening the Linux server
• Linux Foundation: Linux workstation security checklist
• privacytools.io Privacy Resources
• Red Hat Enterprise Linux 7 Security Guide
• Securing Debian Manual
• The paranoid #! Security Guide