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 a ponto de se tornar inutilizá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.
Prepare-se para falhas. Crie um plano com antecedência para seguir quando sua segurança for comprometida.
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
senhas devem ser complexas o bastante para não serem facilmente adivinhadas 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
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
This article or section needs expansion.
Reason:
Mencionar
key derivation functions
(funções de derivação de chave), em particular PBKDF2, bcrypt e scrypt, como usá-las, vantagens e desvantagens, especialmente sobre ataques de força bruta baseado em hardware customizado. (Discuss in
talk:security#Removal of incorrect warning
)
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
This article or section needs expansion.
Reason:
Dar um bom conjunto de padrões, e também discussão de vantagens e desvantagens envolvidas. (Discuss in
talk:Security
)
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
[
link quebrado
: replaced by
nvidia-open-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.
Nota
Outros módulos PAM além do
pam_faildelay
também podem sugerir esse atraso. Se vários módulos o fizerem, o PAM usará o maior atraso configurado.
Em particular, tanto
pam_unix
quanto
pam_faillock
definem um atraso mínimo de 2 segundos por padrão. Para remover completamente esse atraso, é necessário adicionar o parâmetro
nodelay
às linhas
auth
desses módulos, por exemplo:
/etc/pam.d/system-auth
Bloqueie o login de um usuário após 3 tentativas
Desde o
pambase
20200721.1-2, o
pam_faillock.so
vem habilitado por padrão para bloquear usuários por 10 minutos após 3 tentativas de login falhas dentro de um período de 15 minutos (ver
FS#67644
). O bloqueio se aplica apenas à autenticação por senha (ex.: login e sudo). Autenticação por chave pública via SSH continua sendo aceita. Para evitar negação total de serviço, esse bloqueio é desativado para o usuário root por padrão.
Por padrão, o mecanismo de bloqueio usa um arquivo por usuário localizado em
/run/faillock/
. Apagar ou esvaziar esse arquivo desbloqueia o usuário. O diretório pertence ao root, mas o arquivo pertence ao usuário, portanto o comando
faillock
apenas esvazia o arquivo e não requer privilégios de root.
O módulo
pam_faillock.so
pode ser configurado pelo arquivo
/etc/security/faillock.conf
. Os principais parâmetros são:
unlock_time
— tempo de bloqueio (em segundos, padrão: 10 minutos)
fail_interval
— intervalo no qual falhas podem causar bloqueio (em segundos, padrão: 15 minutos)
deny
— número de tentativas falhas antes do bloqueio (padrão: 3)
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:
$ faillock --user username --reset
Dica
O objetivo principal do bloqueio é tornar ataques de força bruta inviáveis. Se bloqueios por erro de digitação estiverem ocorrendo com muita frequência, é preferível aumentar o número de tentativas permitidas em vez de reduzir o tempo de bloqueio.
Nota
deny = 0
desativa completamente o mecanismo de bloqueio.
Por padrão, todos os bloqueios de usuários são perdidos após um reboot. Se um atacante puder reiniciar a máquina, é mais seguro que os bloqueios persistam. Para isso, altere o parâmetro
dir
em
/etc/security/faillock.conf
para:
/var/lib/faillock
Nenhum restart é necessário para que as alterações entrem em vigor. Consulte
faillock.conf(5)
para mais opções, como habilitar bloqueio para root, desabilitar para logins centralizados (ex.: LDAP), entre outras.
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
Este artigo ou esta seção precisa de
tradução
.
Notas:
The section regarding alternatives to su don't exist in the
su
page anymore (Discuta em
Talk:Security (Português)#
)
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
[
link quebrado
: package not found]
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
The factual accuracy of this article or section is disputed.
Reason:
Seu navegador pode notar fraude no DNS com
HSTS
. (Discuss in
talk:security
)
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:
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),
Copie isto para
/etc/ca-certificates/trust-source/blacklist/
e
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