É impossível impedir completamente esses ataques, pelo menos sem uma grande reengenharia do sistema e um pesado fardo para o usuário.
Se um invasor tiver acesso de gravação à sua conta, o usuário poderá criar um ambiente simulado que ocultará todos os rastros do comprometimento aos seus olhos. A maneira mais óbvia é usar LD_PRELOAD para carregar uma biblioteca que se esconda e qualquer outra coisa o invasor plantou (isso não funcionaria em binário vinculado estaticamente, um wrapper mais sofisticado é necessário).
O ataque permanecerá visível para outros usuários até que o invasor tenha escalado para outras contas. Assim, você poderia fazer um processo em execução como root verificar os arquivos em sua conta e relatar qualquer alteração. O problema com isto é que você estará fazendo muitas mudanças legítimas; É improvável que você consiga perceber uma mudança ilegítima entre o ruído.
Existe uma maneira de conter os danos à sua conta, que exige o escalonamento de privilégios para passar por uma interface de usuário totalmente confiável. Isso significaria que:
- A autenticação como raiz deve passar apenas por processos que não pertencem ao usuário e não podem ser controlados pelo usuário. Em particular, nenhuma interface X11.
-
Você deve ter uma maneira de identificar o prompt de login como original: caso contrário, o invasor pode escarnecer da interface do usuário confiável. Existem duas abordagens para isso.
- Tenha uma chave de atenção segura , que não pode ser recuperada para outra função pelo usuário. Pressione o SAK para exibir um prompt de login em um terminal que não esteja sob o controle do usuário. Isso pode ser configurado em alguns unices, mas não tenho conhecimento de uma solução completa que passou por uma séria revisão de segurança.
- O sistema deve autenticar-se para o usuário, novamente por meio de uma interface do usuário sobre a qual o usuário não tem controle. A autenticação pode ser estática, por ex. mostrando uma foto de seus filhos; isso é fácil para você verificar, mas também é fácil falsificar um ataque direcionado. A autenticação pode ser dinâmica, com o sistema mostrando uma senha única que você verifica em um sistema confiável separado; isso requer que você tenha esse sistema (normalmente um token OTP).
Ambas as abordagens funcionam apenas para logins locais. Você não pode ter certeza do caminho entre você e o sistema quando estiver trabalhando remotamente. E você não pode usar nada conveniente como sudo , copiando e colando o comando e assim por diante; você fundamentalmente precisa fazer algo disruptivo do ponto de vista da interface do usuário, como alternar para um terminal diferente.
Ah, e uma vez que o atacante é o root, ele pode facilmente instalar um rootkit que impossibilite a detecção. Ataques locais são comuns de qualquer maneira; Se o invasor tiver comprometido sua conta e este for um ataque avançado (não necessariamente o caso se você simplesmente deixou seu terminal desacompanhado), presuma que a conta root também está comprometida.