Unix foi criticado por seu modelo inicial de “superusuário” versus “todo mundo” na execução de programas (especialmente programas administrativos) e no agrupamento das propriedades do “dono”, “grupo” e “outros” (ou seja, todos os outros do mundo) com as capacidades de “leitura”, “escrita” e/ou “execução” no arquivo. Enquanto isso era relativamente simples, mas também uma estrutura de permissão elegante, funcionou bem durante alguns anos, com o tempo as “Access Control Lists” ou “ACLs” foram habilitadas, permitindo às pessoas criarem classes de privilégios de execução e acesso a arquivos e diretórios em um nível mais refinado.

Quando o Unix deixou a Bell Labs e entrou para o meio acadêmico, nas universidades, ele passou pela clássica “prova de fogo”, com os estudantes tentando invadir o sistema e os desenvolvedores tentando mantê-los fora. O Unix se tornou o sistema operacional para o estudo sério de ciência da computação e, portanto, (em muitos casos) para estudos sérios de segurança do computador.

Arquitetura do Linux:

Como eu mencionei antes, a arquitetura do Linux segue de perto a arquitetura dos sistemas Unix. Um kernel monolítico relativamente pequeno com bibliotecas e utilitários que acrescentam funcionalidade a ele. Isso por si só agrega valor a segurança, pois permite que o usuário final desligue uma série de serviços (tanto de máquina quanto de rede) que não precisa, que funcionando no sistema cria mais possibilidades de ataque. Por exemplo, a grande maioria dos sistemas desktops atuam como cliente para os serviços, não como um servidor. A desativação destes serviços significa que outras pessoas através da rede não podem se conectar a eles. Nos primórdios do Linux diversas distribuições eram disponibilizadas com os serviços ativados no momento da instalação. Esta foi uma impressão errada de que ter os serviços funcionando seria mais fácil administrar, mas os especialistas em seguranças rapidamente apontaram que ter os serviços em execução no momento da instalação (antes da aplicação dos patches necessários), também deixaria os sistemas, mesmo que por pouco tempo, abertos a ataque. Agora a maioria, senão todas, as distribuições deixam estes serviços desligados e você é instruído a habilitá-los na hora certa, espero que somente depois de ter aplicado os patches necessários.

Outro exemplo é o conceito de remover os compiladores e outras ferramentas de desenvolvimento de software do sistema, uma vez que estas ferramentas dão aos crackers maiores possibilidades para explorar o sistema. Remover estas ferramentas significa que o cracker terá que utilizar outros métodos para “quebrar” a segurança. Vários pacotes FOSS (Free and Open Source Software) foram adicionado a esta funcionalidade básica ao longo dos anos, dando ao Linux uma segurança ainda maior.

O primeiro é “PAM” ou “Pluggable Authentication Modules”. Em qualquer sistema, “autenticação” significa que você se identificou de tal forma que o sistema lhe dará acesso aos serviços. Assim que você entra com seu nome de usuário e sua senha, você está sendo “autenticado” tipicamente pelo nome de usuário e senha no arquivo /etc/passwd e pelo programa login. Da mesma forma o ftpd, e outros programas de “serviço”, irá autenticá-lo da mesma maneira. Se você estiver em uma rede, no entanto, poderá ser autenticado por inúmeros métodos, que podem ser LDAP, DCE, Kerberos ou mesmo os métodos mais recentes, e inúmeros programas podem ter que ser alterados para refletir o novo método de autenticação. O PAM foi fornecido para permitir que novos métodos de autenticação possam ser aplicados a todos os programas do sistema que precisa de autenticação sem ter que mudar e integrar cada novo método de autenticação.

Outro método de autenticação mencionado anteriormente foi “Access Control List”, ou “ACL”. Uma ACL concede “acesso” para um arquivo ou diretório com base em uma extensão das permissões tradicionais do Unix “dono/grupo/outros” e “rwx” mencionada acima. Desde que as ACLs estejam implementadas como parte da estrutura do sistema de arquivos, você tem que ter certeza que seu kernel tenha sido construído para suportá-las, que o sistema de arquivos que você está usando oferece suporte a elas, e que o sistema de arquivos foi montado com as ACLs ligadas.

Entretanto, uma vez realizado tudo isto, você pode atribuir permissões a vários usuários em uma base de usuários individuais, vários grupos em uma base de grupo-por-grupo, e assim por diante.Isso permitirá você facilmente criar um grupo de operadores que podem iniciar ou parar um banco de dados ou fazer backups, mas não conseguir desligar todo o sistema, por exemplo. Finalmente, você tem que estar ciente de que nem todos os utilitários do Linux suportam ACLs. Se você está copiando arquivos de um diretório para outro com o comando cp você deve usar as opções “-p” (preserve) ou “-a” (archive) no comando. Alguns dos comandos robusto do Unix como, cpio, tar e outros, não suportam a cópia das ACLs, e portanto as ACLs seriam perdida.

Sistemas de Arquivos Criptografados:

Criptografar seus dados deve ser parte de sua política de segurança em um mundo de dispositivos USB, unidades portáteis e laptops roubados, e o Linux permite que você criptografe arquivos individuais, sistemas de arquivos, partições swap e mesmo sistemas de arquivos dentro de arquivos individuais. Alguns desses métodos de criptografia também trabalham com sistemas de arquivos em nível de usuário, o que significa que você pode configurá-los enquanto o sistema está funcionando.

Loop-AES usa uma técnica de loop-back para permitir que o dispositivo de bloco faça a criptografia sem ter que mudar nada no kernel. Técnicas de loop-back também são úteis para sistemas de arquivos mantidos em um único arquivo, assim este método pode ser usado para criar um sistema de arquivos criptografado que está contido em um único arquivo em sua máquina.

DM-Crypt usa a funcionalidade de mapeamento de dispositivos (também útil para o RAID via software, snapshotting e outros recursos) do kernel para criptografar arquivos.

Cryptofs é um sistema de arquivos em espaço do usuário (FUSE) que permite montar um sistema de arquivos em um diretório, e em seguida todos os arquivos armazenados nesse diretório são criptografados, incluindo o nome do arquivo.

Quando você desmontar o sistema de arquivos, os arquivos são criptografados e não serão de-criptografados até o sistema de arquivos ser montado novamente usando a mesma chave.

Existem outros métodos para criptografar arquivos e sistemas de arquivos, tais como EncFS e TrueCrypt. Além disso, recentemente, um administrador de sistema Microsoft Windows inicializou um Live CD Linux em uma de suas máquinas e ficou surpreso ao verificar que o Linux pode ler e escrever no sistema de arquivos do Microsoft Windows, apesar de ter definido os diretórios como privado sob o sistema operacional da Microsoft. Expliquei-lhe que era um sistema operacional diferente e a menos que ele criptografasse todos os dados em seu disco, ele devia esperar que alguém usando um sistema operacional diferente em sua máquina fosse capaz de ver, alterar e excluir dados no seu sistema de arquivos do Microsoft Windows.

SELinux:

A maioria dos métodos de autenticação de controle de acesso são arbitrários. O dono do objeto (seja um programa ou dado) pode alterar as permissões para outras pessoas e grupos. Anos atrás, a Agência de Segurança Nacional (NSA) criou um projeto para aplicar “Mandatory Access Control” (MAC) dentro do kernel Linux. Este projeto ficou conhecido como “Security Enhanced Linux” ou “SELinux”. O MAC reforça as políticas de segurança que limitam o que um usuário ou programa pode fazer, e quais arquivos, portas, aparelhos e diretórios um programa ou usuário pode acessar.

SELinux tem três modos: “Desabilitado”, “Permissivo” e “Execução”.

No modo “Desabilitado” nada é feito. Neste modo você tem as políticas configuradas e prontas, mas não ativas. O modo “Permissivo” registra as violações da política em arquivos de log para que você possa verificar ou monitorar. No modo “Execução” qualquer violação da política de segurança será contida. SELinux utiliza cerca de 5 a 10% do desempenho do sistema quando no modo de Execução ou Permissivo.

Da mesma forma, o SELinux pode ser executado em uma política de “Orientada” ou “Estrita”. A política “Orientada” significa que os controles MAC apenas se aplicam a determinados processos. A “Estrita” significa que os controles MAC se aplicam a todos os processos. As pessoas devem ser advertidas de que o uso indiscriminado da política “Estrita” do SELinux pode tornar o sistema praticamente inutilizável para alguns usuários. Tem que haver um compromisso de manter o sistema seguro, mas permitindo que os usuários façam o seu trabalho. Argumenta-se que o SELinux é um “exagero” em um sistema de um único usuário, mas com modernos exploits e o poder do “sistemas de um único usuário”, podemos encontrar mais e mais aplicações do SELinux em um desktop de um único usuário.

AppArmor:

AppArmor é um outro sistema para “Mandatory Access Control”, mas que se baseia mais em uma base de programa-por-programa do que o SELinux e permite que você misture e aplique políticas do tipo “Execução” e “Permissivo” no sistema ao mesmo tempo. Através do “perfil” de cada programa, o AppArmor pode limitar o que um programa pode fazer e quais arquivos ele pode acessar, gravar ou executar. Algumas pessoas acham que o AppArmor é mais fácil de configurar e controlar do que o SELinux.

Tornando Arquivos "Imutáveis":

Se alguém invade seu sistema, ele pode alterar vários arquivos de controle, como o arquivo passwd. Você pode impedir isto tornando o arquivo “imutável”. Quando um arquivo é “imutável” ele não pode ser alterado, seja por escrita, exclusão, renomeado ou hard links, até mesmo pelo superusuário.

Primeiro o arquivo tem que voltar a ter permissões “normais”, e então ele pode ser alterado. O comando usado para fazer um arquivo tanto imutável quanto voltá-lo ao normal é chattr, e tem a sintaxe desta forma: chattr +i .

Usando o comando chattr com o parâmetro “a” em vez do “i” faz com que o arquivo só possa ter informações adicionadas. Isso é útil para arquivos de log, onde você deseja que o sistema adicione novas informações, não apagando as informações antigas. Depois que o comando chattr for executado em um arquivo, mesmo o usuário root não pode alterar ou apagar o arquivo até que o arquivo seja alterado com as permissões anteriores, com “-i” ou “-a”.

Novamente, você tem que verificar se o sistema de arquivos que você está usando suporta esta funcionalidade. Os sistemas de arquivos Ext2 e Ext3 suportam.

Logs:

Sistemas Unix e Linux têm arquivos de log. Esses arquivos registram diferentes tipos de eventos, desde inicialização e finalização de um processo até mensagens explícitas sobre o seu servidor de email ou sua base de dados. A maioria dos sistemas Unix e Linux tem a possibilidade de encaminhar os vários níveis de informações desde “bom saber” para “crítica” para um repositório central. Os administradores de sistemas podem criar filtros e scripts para ajudá-los a monitorar esses arquivos de log, identificando atividades que indiquem pessoas acessando o sistema. Estes arquivos, claro, devem ser protegidos utilizando o comando chattr, mencionado acima, com
a opção “+a”.

Sistemas de Detecção de Intrusão

Existem vários Sistemas de Detecção de Intrusão (IDS) disponíveis para Linux. SNORT (http://www.snort.org/) é um deles. O SNORT utiliza um conjunto de regras para determinar as intrusões.

Backups:

Apesar de todo seu trabalho, tempo, suor e lágrimas, eventualmente, seu sistema será
comprometido. Agora você tem que descobrir quando ele foi comprometido, como foi
comprometido e estar pronto para recuperar o que foi danificado sem permitir que outros possíveis vírus e trojans permaneçam no seu sistema.

Com muito trabalho, você pode ser capaz de usar ferramentas para varrer seu sistema à procura desses vírus e trojans. Ou você pode re-instalar a partir de um CD-ROM original, ou imagem ISO em boas condições, e mais todos os patches associados. A forma final é ter um bom nível de backup de todo o sistema de produção que você tem e atualizar periodicamente o backup para ter certeza de ter todos os patches de segurança que ocorreram desde a última atualização. Se você puder determinar com precisão quando seu sistema estava comprometido, você poderá restaurar o sistema a partir de um desses backups. Caso contrário, você terá que instalar a partir do código-fonte.

Resumo:

Estou certo de que muitos dos profissionais de segurança vão olhar para este texto e dizer: “Realmente fundamental”. Outras pessoas podem olhar para algumas destas características e dizer: “Como posso manter-me atualizado de todas essas políticas e comandos em um sistema tão complexo como o Unix ou Linux?”. A resposta é que provavelmente você não conseguirá se manter atualizado de todas estas considerações sobre o sistema e é aí que as políticas de segurança entram em jogo. Faça com que cada sistema fique tão seguro quanto os serviços e informações armazenadas nele, permitindo que você ainda realize seu trabalho.

Além de estudar os recursos listados acima, você também deve olhar o site da sua distribuição específica. Porque há muitas maneiras de fazer a criptografia de arquivos, compilar um kernel, e garantir a segurança de um sistema, e sua distribuição pode ter desenvolvido uma arquitetura de segurança geral que complementa suas políticas e fazem a segurança do sistema de uma maneira muito mais fácil.

Comentário deste Blog( The HackerBuster)

Ótimo artigo escrito pelo nosso querido John. Artigo recente que fala sobre muitos procedimentos e ferramentas para implementação de Hardening Linux ( Principalmente em servidores). Entretanto ele mesmo deixa uma pergunta no ar “Como posso manter-me atualizado de todas essas políticas e comandos em um sistema tão complexo como o Unix ou Linux?”.

Todas as recomendações e ferramentas citadas por ele em seu artigo, podem ser estudadas e analisadas no curso de "Fortalecimento (Hardening) de Servidores Linux".

Não é Marketing ou Merchandising sobre o artigo do conceituado John Maddog e sim uma oportunidade para todos os analistas de segurança e administradores de rede, estarem preparados para o Mercado de Trabalho, que hoje está pedindo urgência por profissionais de segurança e sistemas Unix/Linux.

O Curso "Fortalecimento (Hardening) de Servidores Linux" da Clavis Segurança da Informação já é referência em qualidade no Rio de Janeiro e no Brasil. Em sua 7ª edição o curso agrega muito bem a parte teórica com a parte Hand's-On. Muito bem avaliado por seus alunos, o curso apresenta processos de mapeamento das ameaças, mitigação dos riscos e execução das atividades corretivas, com o objetivo de preparar a infra-estrutura para enfrentar quaisquer tentativas de ataque.

A Próxima turma de "Fortalecimento (Hardening) de Servidores Linux" será realizada no Rio de Janeiro nos dias 5, 12 e 19 de fevereiro de 2011(sábado).

Aproveitem a oportunidade e comecem o ano de 2011 preparados para o Mercado de Trabalho. Quem sabe você não poderá ser o próximo "Artista de Segurança Linux". :) !!!