Conceitos básicos de segurança no Linux 1: Autenticação

Já houve muitas discussões, algumas bastante acaloradas, sobre a segurança de sistemas na seção de comentários do DistroWatch Weekly (DWW) nos últimos meses. Algumas pessoas até argumentam contra o que a maioria considera a segurança básica do Linux. Por causa disso, eu recebi vários pedidos para escrever um artigo completo e com referências sobre os conceitos básicos de segurança no Linux. É claro que existem livros inteiros dedicados à segurança no Linux, e quando comecei a escrever ficou claro que um artigo só não bastaria para cobrir o assunto. Considere o artigo desta semana como um ponto de partida para uma pequena e intermitente série de artigos sobre a segurança no Linux.

Limitei o escopo deste e de futuros artigos do DistroWatch sobre segurança para que ele fizesse sentido para os usuários domésticos e de pequenas empresas ou, em outras palavras, para ambientes com apenas um punhado de sistemas e usuários. A maior parte do que será descrito a seguir se aplica ao BSD, ao OpenSolaris ou a qualquer sistema operacional UNIX ou semelhante ao UNIX, embora os nomes de arquivos, comandos específicos e a sintaxe possam ser um pouco diferentes. Para simplificar as coisas, vou me ater aos sistemas Linux.

Antes de descrever o básico da autenticação no Linux, as discussões recentes deixaram muito claro que eu devo começar definindo o que entendo como segurança. Também tenho que responder à pergunta mais básica de todas, que seria o porquê de termos que nos preocupar com esse assunto. Alguns leitores do DWW afirmam ter ignorado completamente a segurança sem ter um problema sequer a relatar por muitos anos. Essas declarações certamente são autênticas. Isso não significa que o potencial para problemas reais não exista. Kurt Seifried, em seu Linux Administrator’s Security Guide, escreveu: “Basta cometer um erro ou deixar uma única falha em aberto para que um atacante entre. Isso, obviamente, significa que a maioria dos sites será invadida mais dia, menos dia.” Ele acrescenta: “Todas as medidas técnicas de segurança acabarão falhando ou se tornando vulneráveis diante de um atacante. É por isso que você precisa de múltiplas camadas de proteção.”

O livro Practical UNIX and Internet Security oferece uma definição bem simples e direta de segurança: “Um computador é seguro quando você pode confiar que ele e seu software se comportarão como você espera.” Há muitas definições mais técnicas e detalhadas por aí, mas essa realmente resume tudo. Se alguém faz uso de seu(s) sistema(s) para atingir seus próprios objetivos sem seu consentimento, essa condição não é mais atendida. O uso sem sua autorização pode originar-se de um amigo ou de um parente que não deseje causar mal algum, de um companheiro de trabalho ou de um estranho do outro lado do mundo.

Quando eu falo em segurança, uma das perguntas que me fazem com frequência é por que alguém iria querer atacar um sistema doméstico ou de uma pequena empresa. Na semana passada, a Linux Pro Magazine Online publicou um relatório descrevendo cem servidores Linux com péssima segurança na Rússia usados como parte de uma botnet para distribuir malware para sistemas Windows. Tenha em mente que muitos sistemas desktop domésticos são mais poderosos do que servidores com alguns anos de idade. Combine a potência do hardware de hoje às conexões contínuas de banda larga em alta velocidade das quais muitos de nós nos servimos, e você vai entender como quase qualquer sistema pode ser um alvo interessante.

Contas e senhas

A primeira e mais simples linha de defesa é uma senha. Em seu livro, Securing & Optimizing Linux: The Ultimate Solution, Gerhard Mourani escreve: “Muitas pessoas mantêm suas valiosas informações e arquivos em um computador, e a única coisa que impede terceiros de terem acesso a isso tudo é a sequência de oito caracteres que chamamos de senha. Uma senha indecifrável, ao contrário do que dizem por aí, não existe. Com tempo e recursos em mãos, qualquer senha pode ser adivinhada por meio de engenharia social ou força bruta.” Alguns usuários do Linux vão além, rodando distribuições que não têm senha ou que usam uma senha conhecida e disponível publicamente para uma conta com privilégios ou de root. Isso é praticamente a mesma coisa que pôr um tapete de boas-vindas para uma pessoa com acesso físico ao sistema e que esteja disposta a invadi-lo. Uma vulnerabilidade em um serviço que se comunique pela Internet pode, de fato, deixar um sistema desses aberto para literalmente qualquer um que conheça a falha e a senha. Ao escrever sobre os mais variados tipos de padrões inseguros, Kurt Seifried diz: “Esse é um dos problemas que geram problemas de segurança que não têm mais fim desde o primeiro dia.”

Mourani lista quatro regras básicas para uma boa senha. Três delas se aplicam mesmo a sistemas domésticos e a pequenos escritórios:

• Seu tamanho deve ser de no mínimo seis caracteres, de preferência oito, com pelo menos um número e um caractere especial.

• Ela não pode ser trivial; uma senha trivial é aquela que é fácil de adivinhar e geralmente se baseia no nome do usuário ou de um parente, em seu emprego ou em outras características pessoais.

• Ela deve ter um período de validade, exigindo que uma nova senha seja escolhida após um período específico.

Todas as grandes distribuições Linux têm ferramentas que impõem senhas fortes e validade das mesmas. Muitos usuários não usam essas ferramentas porque é inconveniente usar senhas longas e não triviais que mudam periodicamente. A segurança é, por natureza, inconveniente. Cabe a cada um de nós decidir até que ponto a inconveniência é válida para termos um sistema seguro.

Conta de root

A conta de root (ou conta de superusuário) é a conta presente em todos os sistema *nix que geralmente não tem absolutamente nenhuma restrição. O root pode fazer qualquer coisa. Por esse motivo, geralmente é recomendável não fazer login e usar o sistema como root, a não ser que isso seja absolutamente necessário.

A primeira pessoal da qual você se protege ao não utilizar o sistema como root é de você mesmo. Eu trabalhei para um banco local por seis meses antes de ocorrer uma fusão. Um dos administradores de sistemas profissionais deles, um homem com anos de experiência, escreveu um script para apagar arquivos antigos em um servidor. Por motivos óbvios, o script precisava ser rodado como root. Ele cometeu um mísero erro de sintaxe no script que fez com que o mesmo rodasse no sistema de arquivos raiz, e não em um dos sistemas de arquivos em que ele deveria rodar. Para piorar, ele ignorou os procedimentos de controle de alterações apropriados, porque pensou que era só uma manutenção trivial. O script rodou durante a noite, e começou a fazer seu trabalho de remover grandes partes do sistema operacional, que eram mais antigas do que a data configurada no script, efetivamente arrasando um servidor de produção. A moral da história é que mesmo profissionais veteranos cometem erros, e às vezes as consequências são desastrosas. Rodando como root, você pode facilmente causar danos ao sistema, sem aviso. É por isso que algumas distribuições Linux, como o Ubuntu, não permitem logins como root por padrão.

Nem é preciso dizer que regras para senhas fortes devem se aplicar à conta de root em primeiríssimo lugar. Se o acesso root remoto for permitido, intencionalmente ou por causa de uma vulnerabilidade de segurança, uma senha forte pode atrasar uma invasão por tempo suficiente para que ela seja detectada e impedida. Também há um sem número de aplicativos para a Internet, como navegadores web, que possuem vulnerabilidades que efetivamente permitem acesso remoto usando a conta do usuário que estiver executando o aplicativo. Se esse usuário for o root, as falhas de segurança se tornam muito mais perigosas. É por isso que alguns aplicativos do Linux apresentam avisos simples e diretos sobre os riscos de rodá-los como root.

Todas as distribuições Linux, mesmo as menores, possuem ferramentas que permitem a concessão temporária de privilégios de root a usuários comuns. A mais comum é o su, abreviação de superuser (superusuário), e o sudo, abreviação de “superuser do” (executar como superusuário). O comando sudo oferece a capacidade de registrar em log o que você fizer como root. Ele também oferece a maneira mais simples de conceder um subconjunto de privilégios de root a alguém que precise realizar tarefas específicas que exijam privilégios de root, mas que não precisem de controle total e absoluto do sistema, o que o torna ideal para redes de pequenas empresas. Um tutorial detalhado sobre o su e o sudo será publicado em breve no DistroWatch Weekly.

Autenticação básica no Linux: como ela funciona

Em todo sistema Linux há três arquivos que oferecem o nível mais básico de autenticação para o sistema local:

Cada usuário do sistema tem um identificador único de usuário, o UID, associado ao seu nome de usuário (OBSERVAÇÃO: é possível atribuir dois nomes de usuário a um mesmo UID, criando uma mesma conta com dois nomes que podem ser usados para fazer login). Cada usuário pertence a pelo menos um grupo de usuários, e cada grupo tem um identificados único de grupo (GID) associado ao nome do grupo.

O arquivo /etc/passwd é um arquivo de texto simples. Ele pode ser editado com qualquer editor de texto executado como root, e contém sete campos para cada usuário, separados por dois pontos:

• o nome de usuário

• um x minúsculo (geralmente)

• o ID do usuário (UID)

• o grupo padrão do usuário

• o nome completo do usuário e, opcionalmente, informações adicionais em texto puro sobre ele

• o diretório home do usuário

• o shell padrão do usuário

O shell padrão é particularmente importante para contas do sistema. Muitas ferramentas de sistema e alguns aplicativos exigem suas próprias contas de usuário para serem executadas corretamente. No entanto, você não vai querer que alguém seja capaz de fazer login em nome dessa tarefa. Sendo assim, um shell falso (geralmente /bin/false) é usado. Se não houver um shell válido, o usuário não pode fazer login.

Num passado remoto e quase esquecido, o arquivo /etc/passwd também continha as senhas dos usuários em texto puro. Conforme as redes cresceram, ficou claro que algum tipo de maneira segura de se armazenar senhas em um formato que não pudesse ser lido era uma necessidade absoluta, e como de costume, um incidente de segurança convenceu alguém dessa necessidade. Em 1987, Julianne Haugh teve seu sistema invadido e escreveu a suíte Shadow Password original, que continha os comandos login, passwd e su. As senhas shadow fazem parte do Linux desde 1992, e a suíte cresceu e hoje abriga trinta comandos.

O conceito básico do sistema shadow é fácil de entender. Vou citar Seifried outra vez: “Por muitos anos a solução foi bastante simples e eficaz, bastando fazer um hash das senhas e armazenar esse hash; quando um usuário se autentica, faz-se um hash da senha digitada e, se os hashes combinarem, a senha é, obviamente, a mesma.” Com o passar do tempo, o poder computacional cresceu e ficou mais fácil quebrar até mesmos as senhas com hash; com isso o Linux e outros sistemas UNIX migraram para sistemas de criptografia mais fortes (geralmente o MD5). Além do nome de usuário e da senha com hash, o arquivo /etc/shadow também contém informações sobre o envelhecimento da senha.

Usando o chage para definir o envelhecimento da senha

Todas as grandes distribuições Linux possuem ferramentas gráficas que agem como interfaces para a suíte Shadow Password. Porém, se você estiver rodando uma distribuição mais minimalista ou se preferir gerenciar o envelhecimento da senha pela linha de comando em uma conta existente, a maneira mais fácil de se fazer isso é com o comando chage. Seu uso mais simples permite definir um período após o qual a senha precisa ser trocada. Por exemplo, se eu quiser forçar um usuário (sim, até eu mesmo) a alterar a senha a cada noventa dias, posso fazê-lo com o comando:

trocando “usuário” pelo nome do usuário. Também ajuda configurar um aviso com a opção -W. Digamos que eu queria dar um aviso cinco dias antes da senha vencer. O comando seria:

Qualquer usuário pode verificar quando sua senha vence com o comando:

Pluggable Authentication Modules (PAM)

O PAM geralmente se aplica a redes maiores, mas como vem habilitado por padrão como parte do processo de autenticação em muitas das grandes distribuições Linux, ele merece ser mencionado aqui. Em redes maiores, há vários sistemas (NIS, NIS+ e LDAP, por exemplo) usados para permitir que um usuário utilize uma conta para fazer login em vários sistemas. Também há sistemas de segurança mais avançados que permitem que as senhas sejam alteradas minuto a minuto. Em muitas redes corporativas, quem precisa acessar sistemas seguros recebe uma espécie de chaveiro com uma pequena tela de LCD ou LED que exibe a senha do momento. O que o PAM faz é permitir que os administradores definam regras para como lidar com cada tipo de autenticação e que múltiplos métodos de autenticação possam ser usados e gerenciados em um únicos lugar. Por exemplo, uma regra pode permitir que uma classe de usuários só possa fazer login em certos horários.

Tudo bem, mas o que isso tem a ver com os usuários domésticos? Bom, se você estiver usando o Debian GNU/Linux, o Red Hat/Fedora, o SUSE Linux Enterprise ou uma das muitas distros baseadas nessas, o PAM vem habilitado por padrão no seu sistema e certamente é possível que você o utilize para definir regras para sistemas mesmo em uma rede pequena. O Slackware, por outro lado, nem inclui o PAM, embora alguns de seus derivados, como o Zenwalk Linux, o façam. Um manual do PAM já meio defasado, vindo da Red Hat, pode ser encontrado aqui.

Um bom uso para o PAM em redes domésticas e de pequenas empresas é a imposição de senhas fortes. O PAM inclui um módulo que usa a CrackLib para determinar se uma senha é “forte o suficiente”. O significado de “forte o suficiente” para o seu sistema é algo completamente configurável. Algumas distribuições, incluindo o Red Hat Enterprise Linux e seus clones, o Oracle Enterprise Linux, e o Scientific Linux, habilitam o módulo pam-cracklib por padrão.

Artigos Futuros

Nas próximas partes desta série, vamos dar uma olhada nas etapas básicas que você pode seguir para manter seu servidor seguro, limitando os serviços em execução e o acesso aos serviços que precisam ser executados. Vamos dar uma olhada nas portas de rede, aprender como saber quais estão abertas e quais estão fechadas, e como fechar as que não forem necessárias. Vamos dar uma olhada na segurança do sistema de arquivos do Linux, cobrindo tudo, desde as permissões até a criptografia. Vamos dar uma olhada no firewall incluído no kernel do Linux e em como usá-lo; e, conforme o prometido, vamos falar sobre como conceder privilégios de root com segurança. Para fechar, vamos fazer uma cartilha sobre os logs do sistema e sobre como determinar se algum visitante indesejado esteve em seu sistema.