O firewall protege contra worms e invasões, ataques “de fora para dentro”, mas não protege contra vírus e trojans executados localmente.
No primeiro tipo de ataque, o invasor procura uma porta aberta, tenta identificar o servidor ou programa que está ativo na porta (o SSH ou Apache, por exemplo), pesquisa por alguma vulnerabilidade conhecida ou erro de configuração e, caso encontre alguma coisa, lança um ataque, tentando utilizar a falha para obter acesso ao sistema. Com o firewall ativo, o ataque é frustrado logo no início, já que com todas as portas fechadas, simplesmente não existe por onde entrar, a menos que exista alguma falha de segurança no próprio IPtables, o que seria bastante improvável.
Imagine que um desktop que acessa a web apenas como cliente é uma casa, enquanto que um servidor é uma loja de porta aberta. Você pode fechar e reforçar todas as portas, transformando sua casa em um bunker (habilitar o firewall, fechando todas as portas), onde ninguém terá como entrar, a menos que consiga convencer você a abrir a porta para ele. Em um servidor a questão é mais complicada já que, assim como em uma loja, é preciso deixar a porta bem aberta para que os clientes possam entrar e sair.
A segurança, nesse caso, precisa ser feita em vários níveis. Em primeiro vem o firewall, que bloqueia todas as portas que não são usadas, mantendo abertas apenas as portas realmente utilizadas. Em segundo lugar vem a questão das atualizações de segurança. Ninguém invade um servidor simplesmente porque o SSH está habilitado, invade caso esteja em uso uma versão desatualizada, com alguma vulnerabilidade conhecida, ou caso exista alguma conta de usuário ativa, com uma senha fácil. Mantendo o servidor atualizado e seguindo regras básicas de segurança, o risco é pequeno.
Na hora de escolher uma distribuição para ser usada em um servidor, um dos quesitos mais importantes a analisar é justamente a questão das atualizações de segurança: em quanto tempo os pacotes são atualizados ao ser descoberta uma vulnerabilidade e por quanto tempo são disponibilizadas atualizações para a versão em uso.
A maior parte das distribuições comerciais oferece atualizações de segurança por 12 ou 18 meses depois de lançada uma nova versão. Nesse quesito, as distribuições baseadas no Debian levam uma certa vantagem, pois no Debian as atualizações são oferecidas de forma contínua. Sempre que uma nova versão é lançada, você pode atualizar os pacotes utilizando o apt-get e, assim, continuar instalando as atualizações indefinidamente.
O segundo tipo de ataque, que engloba vírus, trojans e afins, exige interação do usuário. Um vírus nunca se instala sozinho (caso contrário não seria um vírus, mas sim um worm), se instala porque alguém executou o arquivo que chegou por e-mail ou por um programa P2P, por exemplo.
No Windows, esta tarefa ficaria por conta do antivírus, antispyware & cia. Entretanto, como ainda não temos uma quantidade expressiva destas pragas no Linux, apenas o firewall em geral já é suficiente. Digo por enquanto, pois conforme o uso do sistema em desktops cresça, é natural que o número de vírus e pragas em geral para a plataforma também cresça, obrigando-nos a tomar mais cuidados.
Caso eventualmente os vírus e trojans tornem-se um problema no Linux, com certeza surgirão várias opções de antivírus, mas, mesmo antes que isso aconteça, existe um conjunto de cuidados simples que podem manter seu micro seguro desde já.
O Linux é reconhecidamente um sistema multiusuário, onde as permissões de arquivos e executáveis impedem que um usuário danifique arquivos ou configurações de outro, ou modifique as configurações do sistema. Embora isso torne as coisas mais complicadas em diversas situações, também cria uma barreira de segurança adicional bastante interessante.
Ao invés de rodar todos os programas e executar todo tipo de arquivo com seu usuário principal, crie um segundo login (ou até mais de um) e o utilize para executar arquivos suspeitos ou programas que possam ter problemas de segurança, como, por exemplo, clientes de IRC e navegadores.
Para isso, abra um terminal e use o comando “su” para logar-se usando o segundo usuário, como em “su joao”. Depois de fornecer a senha, todos os programas executados dentro do terminal serão executados pelo outro usuário. Se por acaso você executar qualquer programa malicioso, apenas o usuário separado é afetado, sem comprometer seus arquivos pessoais, muito menos os arquivos do sistema. Em caso de problemas, basta deletá-lo e criar outro.
Em distribuições baseadas no Debian, o sistema vem configurado para não permitir que outros usuários executem programas gráficos dentro de uma sessão gráfica já aberta. Ao tentar rodar qualquer programa gráfico, você recebe uma mensagem como:
Xlib: connection to “:0.0” refused by server
Xlib: No protocol specified
konqueror: cannot connect to X server :0.0
Isso é solucionado por um utilitário chamado “sux“, que substitui o su, transferindo também as credenciais do X. Basta instalar o pacote “sux” (usando o apt-get, ou outro gerenciador de pacotes disponível) e usá-lo para trocar o usuário, como em: “sux joao”.
