Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Capítulo 2. Protegendo sua Rede

2.1. Segurança da Estação de Trabalho

Proteger um ambiente Linux se inicia com a estação de trabalho. Seja trancando uma máquina pessoal ou protegendo um sistema corporativo, uma política de segurança bem feita começa com o computador individual. Uma rede de computadores é tão segura quanto seu nó mais vulnerável.

2.1.1. Avaliando a Segurança da Estação de Trabalho

Quando avaliar a segurança de uma estação de trabalho do Red Hat Enterprise Linux, considere o seguinte:
  • Segurança da BIOS e do carregador de Boot — É possível que um usuário não autorizado acesse a máquina fisicamente e inicialize como um usuário único ou modo de recuperação sem uma senha?
  • Segurança da Senha — Quão seguros estão as senhas das contas de usuários na máquina?
  • Controles Administrativos — Quem possuirá uma conta no sistema e quanto controle administrativo possuirão?
  • Serviços de Redes Disponíveis — Quais serviços estão escutando por pedidos da rede e eles deveriam estar rodando?
  • Firewalls Pessoais — Qual tipo de firewall seria necessário?
  • Ferramentas de Comunicação com Segurança Avançada — Quais ferramentas devem ser usadas para se comunicar entre estações de trabalho e quais deveriam ser evitadas?

2.1.2. Segurança da BIOS e do Carregador de Boot

A proteção por senha da BIOS (ou equivalente à BIOS) e do carregador de boot podem prevenir que usuários não autorizados que possuem acesso físico aos sistemas de realizarem o boot usando mídias removíveis ou obter privilégios root através do modo de usuário único. As medidas de segurança que você deve tomar para se proteger de tais ataques dependem tanto da sensibilidade da informação na estação de trabalho e da localização da máquina.
Por exemplo, se uma máquina é usada em uma exposição e não possui nenhuma informação sensível, então pode não ser crítico prevenir tais ataques. Entretanto, se um notebook de um empregado com chaves pessoais SSH e sem encriptação da rede da empresa é deixado desacompanhado na mesma exposição, isso poderia ser uma brecha de segurança maior com ramificações em toda a empresa.
Se a estação de trabalho está localizada em um lugar onde somente pessoas autorizadas ou de confiança possuem acesso, então proteger a BIOS ou o carregador do boot pode não ser necessário.

2.1.2.1. Senhas da BIOS

As duas razões primárias para proteger a BIOS de um computador com senha são[11]:
  1. Prevenindo Mudanças às Configurações da BIOS — Se um invasor possui acesso à BIOS, ele pode configura-la para fazer o boot de um disquete ou CD-ROM. Sendo possível entrar no modo de recuperação ou modo de usuário único, que permite iniciar processos arbitrários no sistema ou copiar dados sensíveis.
  2. Prevenindo Inicialização do Sistema — Algumas BIOS permitem proteção por senha do processo de boot. Quando ativados, um invasor é forçado a entrar com uma senha antes que a BIOS inicie o carregador de boot.
Porque os métodos para configurar a senha da BIOS podem variar entre os fabricantes de computador, consulte o manual do computador para instruções especificas.
Se você esquecer a senha da BIOS, ela pode ser zerada com os jumpers na placa mãe ou retirando a bateria do CMOS. Por esta razão, é uma boa prática trancar a caixa do computador se possível. Entretanto, consulte o manual do computador ou da placa mãe antes de tentar desconectar a bateria do CMOS.
2.1.2.1.1. Protegendo Plataformas que não são X86
Outras arquiteturas usam programas diferentes para realizar tarefas de baixo nível mais ou menos equivalentes à essas das BIOS em sistemas x86. Por exemplo, computadores Intel® Itanium™ usam a Extensible Firmware Interface (EFI) shell.
Para instruções sobre proteger com senha programas como a BIOS em outras arquiteturas, consulte as instruções do fabricante.

2.1.2.2. Senhas do Carregador de Boot

As razões primárias para proteger com senha um carregador de boot de Linux são as seguintes:
  1. Impedir Acesso ao Modo de Usuário Único — Se invasores podem inicializar o sistema no modo de usuário único, eles são logados automaticamente como root sem serem questionados pela senha root.
  2. Impedir Acesso ao Console GRUB — Se a máquina usa o GRUB como seu carregador de boot, um invasor pode usar a interface do editor GRUB para mudar sua configuração ou pegar informações usando o comando cat.
  3. Impedir Acesso à Sistemas Operacionais Inseguros — Se o sistema possui sistema de boot duplo, um invasor pode selecionar um sistema operacional no momento do boot (por exemplo, o DOS), que ignora controles de acesso e permissões de arquivos.
O Red Hat Enterprise Linux 6 é lançado com o carregador de boot do GRUB na plataforma x86. Para uma visão detalhada do GRUB, consulte o Guia de Instalação da Red Hat.
2.1.2.2.1. Protegendo o GRUB com senha
Você pode configurar o GRUB para tratar os dois primeiros problemas listados na Seção 2.1.2.2, “Senhas do Carregador de Boot” adicionando uma senha direcionada ao seu arquivo de configuração. Para fazer isso, primeiro adicione uma senha forte, abra o shell, autentique-se como root e então digite o seguinte comando: 
/sbin/grub-md5-crypt
Quando questionado, digite a senha do GRUB e pressione Enter. Isto retorna um hash MD5 da senha.
Depois, edite o arquivo de configuração do GRUB /boot/grub/grub.conf. Abra o arquivo e abaixo da linha timeout na seção principal do documento, adicione a seguinte linha: 
password --md5 <password-hash>
Substitua <password-hash> com o valor retornado pelo /sbin/grub-md5-crypt[12].
A próxima vez que o sistema inicializar, o menu do GRUB impede o acesso ao editor ou interface de comando sem primeiro pressionar p seguido pela senha do GRUB.
Infelizmente, esta solução não previne que um invasor inicialize por um sistema operacional não seguro em um ambiente de boot duplo. Para isto, uma parte diferente do arquivo /boot/grub/grub.conf deve ser editada.
Busque pela linha title do sistema operacional que você quer proteger e adicione uma linha com a diretiva lock imediatamente embaixo dela.
Para o sistema DOS, a estrofe deve iniciar similarmente ao seguinte: 
title DOS lock

Atenção

A linha password deve estar presente na seção principal do arquivo /boot/grub/grub.conf para este método para funcionar propriamente. Caso contrário, um invasor pode acessar a interface do editor GRUB e remover a linha bloqueada.
Para criar uma senha diferente para um kernel em particular ou sistema operacional, adicione a linha lock à estrofe, seguida pela linha da senha.
Cada estrofe protegida com uma senha única deve iniciar com as linhas similares ao exemplo seguinte: 
title DOS lock password --md5 <password-hash>

2.1.3. Segurança da Senha

As senhas são o método primário que o Red Hat Enterprise Linux usa para verificar a identidade do usuário. Isto é porque a segurança de senha é tão importante para a proteção do usuário, da estação de trabalho e da rede.
Por motivos de segurança, o programa de instalação configura o sistema para usar o Secure Hash Algorithm 512 (SHA512) e senhas shadow. É altamente recomendado que você não altere essas configurações.
Se senhas shadow não são selecionadas durante a instalação, todas as senhas são armazenadas como um hash de uma via no arquivo de leitura pública /etc/passwd, que faz o sistema vulnerável à ataques de quebra de senhas offline. Se um invasor pode ter acesso à máquina como um usuário normal, ele pode copiar o arquivo /etc/passwd para sua própria máquina e rodar quaisquer programas de quebra de senha. Se houver uma senha insegura no arquivo, é somente um questão de tempo até que o invasor a descubra.
Senhas shadow eliminam este tipo de ataque armazenando as senhas hash no arquivo /etc/shadow, que pode ser lido somente pelo usuário root.
Isto força um invasor em potencial tentar quebrar senhas remotamente, autenticando-se em um serviço de rede na máquina, como SSH ou FTP. Este tipo de ataque de força bruta é muito mais lento e deixa rastros óbvios, já que centenas de tentativas de login são gravadas nos arquivos do sistema. É claro que se o invasor iniciar um ataque no meio da noite em um sistema com senhas fracas, o invasor pode ter ganhado o acesso antes do amanhecer e editado os arquivos de log para encobrir seus rastros.
Além das considerações de formato e armazenamento existe a questão do conteúdo. A coisa mais importante que um usuário pode fazer para proteger sua conta contra um ataque de quebras de senha é criar uma senha forte.

2.1.3.1. Criando Senhas Fortes

Quando criar uma senha segura, é uma boa idéia seguir essas diretrizes:
  • Não Use Somente Palavras ou Números — Nunca use somente números ou palavras em uma senha.
    Alguns exemplos inseguros incluem o seguinte:
    • 8675309
    • juan
    • hackme
  • Não Use Palavras Reconhecíveis — Palavras como nomes próprios, palavras de dicionário ou mesmo termos de programas de televisão ou novelas devem ser evitados, mesmo se finalizados com números.
    Alguns exemplos inseguros incluem o seguinte:
    • john1
    • DS-9
    • mentat123
  • Não Use Palavras em Línguas Estrangeiras — Programas de quebra de senha muitas vezes tentam listas de palavras que incluem dicionários de muitas línguas. Contar com línguas estrangeiras para senhas não é seguro.
    Alguns exemplos inseguros incluem o seguinte:
    • cheguevara
    • bienvenido1
    • 1dumbKopf
  • Não Use Terminologia Hacker — Se você acha que é elite porque você usa terminologia hacker — também conhecida como a escrita l337 (LEET) — em sua senha, pense novamente. Muitas listas de palavras incluem a escrita LEET.
    Alguns exemplos inseguros incluem o seguinte:
    • H4X0R
    • 1337
  • Não Use Informações Pessoais — Evite usar qualquer informação pessoal em suas senhas. Se o invasor conhece sua identidade, a tarefa em adivinhar sua senha se torna mais fácil. A seguir está uma lista de tipos de informações a serem evitadas quando criar uma senha:
    Alguns exemplos inseguros incluem o seguinte:
    • Seu Nome
    • Nomes de animais de estimação
    • Os nomes dos membros da família
    • Qualquer data de aniversário
    • Seu número de telefone ou código postal
  • Não Inverta Palavras Reconhecíveis — Verificadores de senhas bons sempre invertem as palavras comuns, então inverter uma senha fraca não a faz mais segura.
    Alguns exemplos inseguros incluem o seguinte:
    • R0X4H
    • nauj
    • 9-DS
  • Não Escreva Sua Senha — Nunca guarde sua senha em papel. É mais seguro memoriza-la.
  • Não Use a Mesma Senha para Todas as Máquinas — É importante fazer senhas separadas para cada máquina. Desta maneira se um sistema é comprometido, todas suas máquinas não estarão imeditatamente em risco.
As seguintes diretrizes lhe ajudarão a criar uma senha forte:
  • Faça a Senha com no Mínimo 8 Dígitos — Quanto mais longa a senha, melhor. Se usar senhas MD5, ela deve ser de 15 ou mais dígitos . Com senha DES, use a extensão máxima (oito caracteres).
  • Misture Maiúsculas e Minúsculas — O Red Hat Enterprise Linux diferencia maiúsculas de minúsculas, então misture as letras para aumentar a força da senha.
  • Misture Letras e Números — Adicionar números às senhas, especialmente quando adicionados no meio (não só no início ou no final), pode aumentar a força da senha.
  • Inclua Caracteres Não Alfa Numéricos — Caracteres especiais como &, $, e > podem melhorar muito a força de uma senha (isto não é possível se usar senhas DES).
  • Escolha uma Senha que Você pode se Lembrar — A melhor senha do mundo não faz nada se você não lembra-la; use acrônimos ou outros dispositivos mnemônicos para ajudar a memorizar senhas.
Com estas regras, pode parecer difícil criar uma senha que atenda todos esses critérios de uma senha eficiente e evitar as peculiaridades de uma ruim. Felizmente, existem alguns passos que você pode tomar para gerar uma senha segura, fácil de lembrar.
2.1.3.1.1. Metodologia para Criação de Senhas Seguras
Existem muitos métodos que pessoas usam para criar senhas seguras. Um dos métodos mais populares envolvem acrônimos. Por exemplo:
  • Pense em uma frase fácil de se lembrar, como esse em inglês:
    "over the river and through the woods, to grandmother's house we go."
  • Depois, transforme a frase em um acrônimo (incluindo a pontuação).
    otrattw,tghwg.
  • Adicione complexidade substituindo números e símbolos por letras no acrônimo. Por exemplo, substitua 7 pelo t e o símbolo (@) pelo a:
    o7r@77w,7ghwg.
  • Adicione mais complexidade colocando em maiúsculo pelo menos uma letra, tal como H.
    o7r@77w,7gHwg.
  • Finalmente, não use o exemplo da senha acima em qualquer sistema, nunca.
Enquanto criar senhas seguras é imperativo, gerencia-las propriamente também é importante, especialmente para administradores de sistemas dentro de grandes organizações.

2.1.3.2. Criando Senhas de Usuários Dentro de Uma Organização

Se uma organização possui um grande número de usuários, os administradores de sistema possuem duas opções básicas disponíveis para forçar o uso de boas senhas. Eles podem criar senhas para o usuário ou eles podem deixar os usuários criarem suas próprias senhas e verificando que as senhas são de qualidade aceitável.
Criar senhas para os usuários garante que as senhas sejam boas, mas se torna uma tarefa assustadora conforme a organização cresce. Também aumenta o risco dos usuários escreverem suas senhas em papel.
Por estas razões, a maioria dos administradores de sistemas preferem que os usuários criem suas próprias senhas, mas ativamente verificar que as senhas sejam boas e em alguns casos, forçar os usuários a muda-las periodicamente através de expiração de senha.
2.1.3.2.1. Forçando Senhas Fortes
Para proteger a rede de intrusões é uma boa idéia para os administradores de sistema verificar que as senhas usadas dentro de uma organização sejam fortes. Quando os usuários são perguntados para criar ou mudar senhas, eles podem usar a aplicação de linha de comando passwd, que é o Pluggable Authentication Modules (PAM) checando se a senha é muito curta ou de outra maneira fácil de quebrar. Esta verificação é realizada usando o modulo PAM pam_cracklib.so. Já que o PAM é personalizável, é possível adicionar mais de um verificador de integridade de senhas, como pam_passwdqc (disponível em http://www.openwall.com/passwdqc/) ou escrever um módulo novo. Para uma lista de módulos PAM disponíveis, consulte o http://www.kernel.org/pub/linux/libs/pam/modules.html. Para mais informações sobre o PAM, consulte Gerenciando Sign-On Únicos e Cartões Smart.
A verificação de senha que é realizada no momento de sua criação não descobre senhas ruins tão efetivamente quanto rodar um programa de quebra de senhas.
Muitas programas de quebra de senhas estão disponíveis e que rodam no Red Hat Enterprise Linux, apesar de que nenhum está no pacote do sistema operacional. Abaixo está uma lista breve de alguns dos programas mais populares de quebra de senha:
  • John The Ripper — Um rápido de flexível programa de quebra de senhas. Permite o uso de múltiplas listas de palavras e é capaz de quebrar senhas por força bruta. Está disponível online em http://www.openwall.com/john/.
  • Crack — Talvez o mais conhecido programa de quebra de senhas, o Crack é também muito rápido, embora não tão fácil de usar como o John The Ripper. Pode ser encontrado em http://www.crypticide.com/alecm/security/crack/c50-faq.html.
  • Slurpie — O Slurpie é similar ao John The Ripper e o Crack, mas é desenhado para rodar em múltiplos computadores simultaneamente, criando um ataque de quebra de senhas distribuído. Ele pode ser encontrado online junto com uma série de outras ferramentas de avaliação de ataque à segurança em http://www.ussrback.com/distributed.htm.

Atenção

Sempre obtenha uma autorização escrita antes de tentar quebrar senhas dentro de uma organização.
2.1.3.2.2. Frases Secretas
Frases secretas e senhas são um pilar na segurança na maioria dos sistemas de hoje. Infelizmente, tais técnicas como biometria e autenticação de dois fatores ainda não se tornaram o caminho principal em muitos sistemas. Se senhas serão usadas para proteger um sistema, então o uso de frases secretas devem ser consideradas. Frases secretas são mais longas do que senhas e fornecem melhor proteção do que uma senha mesmo quando implementadas sem caracteres padrões como números e símbolos.
2.1.3.2.3. Expiração de Senha
Expiração de senha é uma outra técnica usada por administradores de sistemas para se defender contra senhas ruins dentro de uma organização. Expiração de senha significa que depois de um especificado período (normalmente 90 dias), o usuário é questionado para criar uma nova senha. A teoria por trás disto é que se um usuário é forçado a mudar sua senha periodicamente, uma senha descoberta é somente útil ao invasor por um período de tempo limitado. A desvantagem da expiração de senha, entretanto, é que usuários são mais inclinados a escrever suas senhas no papel.
Existem dois programas primários usados para especificar a expiração no Red Hat Enterprise Linux: o comando chage ou a aplicação User Manager (system-config-users).
A opção -M do comando chage especifica o número máximo de dias que a senha é válida. Por exemplo, para definir que a senha de um usuário expire em 90 dias, use o seguinte comando: 
chage -M 90 <username>
No comando acima, substitua o <username> com o nome do usuário. Para desativar a expiração de senha, é normal usar um valor de 99999 depois da opção -M (isto é equivale a mais ou menos 273 anos).
Você pode também usar o comando chage em modo interativo para modificar múltiplas expirações de senhas e detalhes de conta. Use o comando seguinte para entrar no modo interativo: 
chage <username>
O exemplo seguinte é exemplo de sessão interativa usando este comando: 
[root@myServer ~]# chage davido 
Changing the aging information for davido 
Enter the new value, or press ENTER for the default 
Minimum Password Age [0]: 10
Maximum Password Age [99999]: 90 
Last Password Change (YYYY-MM-DD) [2006-08-18]: 
Password Expiration Warning [7]: 
Password Inactive [-1]: 
Account Expiration Date (YYYY-MM-DD) [1969-12-31]: 
[root@myServer ~]#
Consulte a página man sobre o chage para mais informações sobre as opções disponíveis.
Você pode também usar a aplicação gráfica User Manager (Gerenciador de Usuários) para criar políticas de expiração de senhas, conforme a seguir. Nota: você precisa de privilégios de Administrador para realizar este procedimento.
  1. Clique no menu System (Sistema) no painel, depois em Administration (Administração) e então clique em Users and Groups (Usuários e Grupos) para exibir o Gerenciador de Usuários. Alternativamente, digite o comando system-config-users no shell.
  2. Clique na aba Users (Usuários) e selecione o usuário requerido na lista de usuários.
  3. Clique em Properties (Propriedades) na barra de ferramentas para exibir as caixa de diálogo das Propriedades do Usuário (ou escolha Properties (Propriedades) no menu File (Arquivo)).
  4. Clique na aba Password Info (Informações de Senha) e marque a caixa de verificação Enable password expiration (Ativar expiração de senha).
  5. Digite o valor requerido no campo Days before change required (Dias antes da mudança requerida) e clique OK.
Especificando as opções de expiração de senha

Figura 2.1. Especificando as opções de expiração de senha

2.1.4. Controles Administrativos

Quando administrar uma máquina doméstica, o usuário deve realizar algumas tarefas como usuário root ou adquirindo privilégios root pelo programa setuid, como o sudo ou su. Um programa setuid é um que opera com a ID de usuário (UID) do proprietário do programa em vez do usuário operar o programa. Tais programas são denotados por um s na seção proprietário de uma lista de formato longo, como no exemplo a seguir: 
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

Nota

O s pode ser maiúsculo ou minusculo. Se aparecer como maiúsculo, significa que o bit de permissão subjacente não foi definido.
Para os administradores de sistemas de uma organização, entretanto, as escolhas podem ser feitas como o quanto de acesso administrativo os usuários dentro da organização podem ter em suas máquinas. Através do módulo PAM chamado pam_console.so, algumas atividades normalmente reservadas somente para o usuário root, como reinicialização e montagem de mídia removíveis são permitidas para o primeiro usuário que logar no console físico (consulte Gerenciando Sign-On Únicos e Cartões Smart para mais informações sobre o módulo pam_console.so). Entretanto, outras tarefas importantes de administração do sistema, como alterar definições de rede, configurar um mouse novo ou montar dispositivos de rede não são possíveis sem privilégios administrativos. Como resultado, administradores de sistema devem decidir quanta acessibilidade os usuários em sua rede devem receber.

2.1.4.1. Permitindo Acesso Root

Se os usuários dentro de uma organização são confiáveis e entendedores de informática, então permitir acesso root a eles pode não ser um problema. Permitindo acesso root aos usuários significa que atividades menores, como adicionar dispositivos ou configurar interfaces de rede, podem ser manuseadas pelos usuários individuais, deixando os administradores de sistema livres para lidar com a segurança da rede e outras questões importantes.
Por outro lado, dar acesso root a usuários individuais podem levar às seguintes questões:
  • Desconfiguração da Máquina — Usuários com acesso root pode desconfigurar suas máquinas e necessitar de assistência para resolver o problema. Ainda pior, eles podem abrir brechas de segurança sem perceber.
  • Executando Serviços Inseguros — Usuários com acesso root podem rodar servidores inseguros em suas máquinas, como FTP ou Telnet, colocando nomes de usuários e senhas potencialmente em risco. Estes serviços transmitem estas informações pela a rede em texto puro.
  • Executar Anexos de Email como Root — Ainda que raro, vírus em e-mails que afetam o Linux existem. O único momento entretanto que eles são uma ameaça é quando eles são executados pelo usuário root.

2.1.4.2. Desabilitando Acesso ao Root

Se um administrador não está confortável em permitir que os usuários autentiquem-se como root por estas e outras razões, a senha root deve ser mantida em segredo e acessar o nível de execução um ou modo de usuário único deve ser desativado através de proteção de senha do carregador de boot (consulte a Seção 2.1.2.2, “Senhas do Carregador de Boot” para mais informações sobre este tópico).
A Tabela 2.1, “Métodos para Desabilitar a Conta Root” descreve maneiras que um administrador pode assegurar ainda mais que logins root sejam desativados:

Tabela 2.1. Métodos para Desabilitar a Conta Root

Método Descrição Efeitos Não afeta
Alternado o shell do root. Edite o arquivo /etc/passwd e mude o shell de /bin/bash para /sbin/nologin.
Impede acesso ao shell do root e registra nos logs quaisquer tentativas.
Os seguintes programas são impedidos de acessar a conta root:
· login
· gdm
· kdm
· xdm
· su
· ssh
· scp
· sftp
Programas que não requerem o uso do shell, como clientes FTP, clientes de email e muitos programas setuid.
Os seguintes programas não são impedidos de acessar a conta root:
· sudo
· clientes FTP
· clientes de E-mail
Desativar o acesso root por qualquer dispositivo de console (tty). Um arquivo /etc/securetty impede o login de root em quaisquer dispositivos anexados ao computador.
Impede acesso à conta root pelo console ou rede. Os programas seguintes são impedidos de acessar a conta root:
· login
· gdm
· kdm
· xdm
· Outros serviços de rede que abram o tty
Programas que não logam como root mas realizam tarefas administrativas através do setuid ou outros mecanismos.
Os seguintes programas não são impedidos de acessar a conta root:
· su
· sudo
· ssh
· scp
· sftp
Desativando logins root SSH. Edite o arquivo /etc/ssh/sshd_config e defina o parâmetro PermitRootLogin para no.
Impede o acesso root pela suíte de ferramentas OpenSSH. Os seguintes programas são impedidos de acessar a conta root:
· ssh
· scp
· sftp
Isto somente impede o acesso root à suítes de ferramentas OpenSSH.
Use o PAM para limitar acesso root aos serviços. Edite o arquivo para o serviço alvo no diretório /etc/pam.d/. Tenha certeza que o pam_listfile.so é requerido para autenticação. [a]
Impede o acesso root aos serviços de rede que estão atentos ao PAM.
Os seguintes serviços são impedidos de acessar a conta root:
· clientes FTP
· clientes de E-mail
· login
· gdm
· kdm
· xdm
· ssh
· scp
· sftp
· Quaisquer serviços atentos ao PAM.
Programas e serviços que não estão atentos ao PAM.
2.1.4.2.1. Desativando o Shell do Root
Para impedir usuários de logar diretamente como root, o administrador do sistema pode definir o shell da conta root para /sbin/nologin no arquivo /etc/passwd. Isso impede o acesso à conta root através de comando que requerem um shell, como os comandos su e o ssh

Importante

Programas que não requerem acesso ao shell, como clientes de e-mail ou o comando sudo, podem ainda acessar a conta root.
2.1.4.2.2. Desativando Logins Root
Para limitar ainda mais o acesso à conta root, os administradores pode desativar os logins root no console editando o arquivo /etc/securetty. Este arquivo lista todos os dispositivos em que o usuário root é permitido logar. Se o arquivo não existir, o usuário root pode se autenticar através de qualquer dispositivo de comunicação no sistema, seja pelo console ou uma interface de rede bruta. Isto é perigoso, porque um usuário pode se autenticar em sua máquina pela rede. Por padrão, o arquivo /etc/securetty do Red Hat Enterprise Linux somente permite ao usuário root se autenticar no console fisicamente anexado à máquina. Para impedir o root de se autenticar, remova o conteúdo deste arquivo, digitando o seguinte comando: 
echo > /etc/securetty

Atenção

Um arquivo em branco /etc/securetty não impede o usuário root de se autenticar remotamente usando a suíte de ferramentas OpenSSH porque o console não é aberto até depois da autenticação.
2.1.4.2.3. Desativando Logins Root SSH
Logins root pelo protocolo SSH são desativados por padrão no Red Hat Enterprise Linux 6; entretanto, se esta opção foi ativada, ela pode ser desativada novamente editando o arquivo de configuração do daemon SSH (/etc/ssh/sshd_config). Mude a linha que contém: 
PermitRootLogin yes
para ficar como: 
PermitRootLogin no
Para essas mudanças terem efeito, o daemon SSH deve ser reiniciado. Isto pode ser feito pelo seguinte comando: 
kill -HUP `cat /var/run/sshd.pid`
2.1.4.2.4. Desativando o Root de usar o PAM
O PAM, pelo módulo /lib/security/pam_listfile.so, permite uma grande flexibilidade em negar contas específicas. O administrador pode usar este módulo para referenciar uma lista de usuários que não estão permitidos de se autenticar. Abaixo está um exemplo de como o módulo é usado pelo servidor FTP vsftpd no arquivo de configuração do PAM /etc/pam.d/vsftpd, o caractere \ no final da primeira linha no exemplo seguinte não é necessário se a diretiva está em uma linha): 
auth required /lib/security/pam_listfile.so item=user \ 
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
Isto instrui o PAM para consultar o arquivo /etc/vsftpd.ftpusers e negar acesso ao serviço para qualquer usuário listado. O administrador pode mudar o nome deste arquivo e manter listas separadas para cada serviço ou usar uma lista central para negar acesso à múltiplos serviços.
Se o administrador quer negar acesso à múltiplos serviços, uma linha similar pode ser adicionada aos arquivos de configuração do PAM, como /etc/pam.d/pop e o /etc/pam.d/imap para clientes de e-mail ou o /etc/pam.d/ssh para cliente SSH.
Para mais informações sobre o PAM, consulte Gerenciando Sign-On Únicos e Cartões Smart.

2.1.4.3. Limitando o Acesso Root

Mais do que completamente negar acesso ao usuário root, o administrador pode querer permitir acesso somente por programas setuid, como o su ou sudo.
2.1.4.3.1. O Comando su
Quando um usuário executa o comando su, ele é questionado pela senha root e depois da autenticação, recebe a linha de comando do root.
Uma vez autenticado pelo comando su, o usuário se torna o usuário root e possui acesso administrativo absoluto ao sistema[13]. Além disso, uma vez que um usuário se tornou root, é possível para ele usar o comando su para mudar para qualquer outro usuário no sistema sem ser questionado por uma senha.
Pela razão deste programa ser tão poderoso, os administradores dentro de uma organização podem desejar limitar o acesso a este comando.
Uma das maneiras mais simples de fazer isso é adicionar usuários ao grupo administrativo especial chamado wheel. Para fazer isso, digite o seguinte comando como root: 
usermod -G wheel <username>
No comando anterior, substitua o <username> com o nome de usuário que você quer adicionar ao grupo wheel.
Você pode também usar o Gerenciador de Usuários para modificar afiliações de grupos, conforme a seguir. Nota: você precisa de privilégios de Administrador para realizar este procedimento.
  1. Clique no menu System (Sistema) no painel, depois em Administration (Administração) e então clique em Users and Groups (Usuários e Grupos) para exibir o Gerenciador de Usuários. Alternativamente, digite o comando system-config-users no shell.
  2. Clique na aba Users (Usuários) e selecione o usuário requerido na lista de usuários.
  3. Clique em Properties (Propriedades) na barra de ferramentas para exibir as caixa de diálogo das Propriedades do Usuário (ou escolha Properties (Propriedades) no menu File (Arquivo)).
  4. Clique na aba Groups (Grupos), marque a caixa de seleção para o grupo wheel, e então clique em OK. Veja a Figura 2.2, “Adicionando usuários ao grupo "wheel".”
Adicionando usuários ao grupo "wheel".

Figura 2.2. Adicionando usuários ao grupo "wheel".

Abra o arquivo de configuração do PAM para o su (/etc/pam.d/su) em um editor de textos e remova o comentário # na seguinte linha: 
auth  required /lib/security/$ISA/pam_wheel.so use_uid
Esta mudança significa que somente membros do grupo administrativo wheel podem usar este programa.

Nota

O usuário root é parte do grupo wheel por padrão.
2.1.4.3.2. O Comando sudo
O comando sudo oferece outra abordagem para dar aos usuários o acesso administrativo. Quando usuários confiáveis precedem um comando administrativo com o sudo, eles são questionados pela própria senha. Então, quando eles são autenticados e assumindo que o comando é permitido, o comando administrativo é executado como se ele fosse o usuário root.
O formato básico do comando sudo é como a seguir: 
sudo <command>
No exemplo acima, o <command> seria substituido por um comando normalmente reservado para o usuário root, tal como o mount.

Importante

Usuários do comando sudo devem ter cuidade e sair do comando antes de deixar a máquina, já que o sudo pode executar o comando novamente sem ter a senha pedida dentro de um período de cinco minutos. Esta configuração pode ser alterada pelo arquivo de configuração, /etc/sudoers.
O comando sudo permite um alto grau de flexibilidade. Por exemplo, somente usuários listados no arquivo de configuração /etc/sudoers são permitidos usar o comando sudo e o comando é executado no shell do usuário, não no shell do root. Isto significa que o shell do root pode ser completamente desativado, como mostrado na Seção 2.1.4.2.1, “Desativando o Shell do Root”.
O comando sudo também fornece um registro de auditoria abrangente. Cada autenticação feita é registrada no arquivo /var/log/messages e o comando digitado junto com o nome do usuário é registrado no arquivo /var/log/secure.
Outra vantagem do comando sudo é que um administrador pode permitir usuários diferentes acessar comandos especificos baseados em suas necessidades.
Administradores querendo editar o arquivo de configuração do sudo, /etc/sudoers, devem usar o comando visudo.
Para dar a alguém privilégios administrativos completo, digite visudo e adicione uma linha similar à seguinte na seção de especificação de privilégio do usuário: 
juan ALL=(ALL) ALL
Este exemplo declara que o usuário, juan, pode usar sudo de qualquer host e executar qualquer comando.
O exemplo abaixo ilustra a possível granularidade quando configurar o sudo: 
%users localhost=/sbin/shutdown -h now
Este exemplo declara que qualquer usuário possa emitir o comando /sbin/shutdown -h now desde que ele seja emitido a partir do console.
A página man do sudo possui uma lista detalhada de opções para este arquivo.

2.1.5. Serviços de Rede Disponíveis

Enquanto o acesso do usuário aos controles administrativos é uma questão importante para administradores do sistema dentro de uma organização, monitorar quais serviços de rede estão ativos é de suma importância para qualquer um que administra ou opera um sistema Linux.
Muitos serviços no Red Hat Enterprise Linux 6 se comportam como servidores de rede. Se um serviço de rede estiver rodando em uma máquina então a aplicação do servidor (chamada daemon), está aguardando por conexões em uma ou mais portas da rede. Cada um destes servidores devem ser tratados como potencias portas de ataque.

2.1.5.1. Riscos ao Serviços

Serviços de rede podem impor muitos riscos para sistemas Linux. Abaixo segue uma lista de algumas das questões primárias:
  • Denial of Service Attacks (DoS) — Inunda um serviço com pedidos, um ataque de negação de serviço pode fazer um sistema inutilizável conforme ele tenta registrar e responder cada pedido.
  • Distributed Denial of Service Attack (DDoS) — Um tipo de ataque DoS que usa múltiplas máquinas comprometidas (muitas vezes milhares ou mais) para direcionar um ataque coordenado à um serviço, inundando com pedidos e fazendo o serviço inutilizável.
  • Script Vulnerability Attacks — Se um servidor estiver usando scripts para executar ações dentro do servidor, como servidores web geralmente fazem, um invasor pode atacar os scripts impropriamente. Estes ataques de vulnerabilidade de script podem levar à uma condição de buffer overflow ou permitir ao invasor alterar arquivos no sistema.
  • Buffer Overflow Attacks — Serviços que conectam às portas numeradas de 0 a 1023 devem rodar como um usuário administrativo. Se a aplicação tiver um buffer overflow explorável, um invasor poderia ganhar acesso ao sistema como o usuário executando o deaemon. Pela razão que buffer overflow existe, os crackers usam ferramentas automatizadas para identificar sistemas com vulnerabilidades e uma vez que ganharam acesso, eles usam rootkits automatizados para manter o acesso ao sistema.

Nota

A ameaça das vulnerabilidades do buffer overflow é minimizada no Red Hat Enterprise Linux pelo ExecShield, uma segmentação de memória executável e tecnologia de proteção suportada pelos processadores únicos e múltiplos do kernel compatíveis com x86. O ExecShield reduz o risco de buffer overflow separando a memória virtual em segmentos executáveis e não executáveis. Qualquer código de programa que tenta executar fora do segmento executável (tal como um código malicioso injetado a partir de uma exploração de buffer overflow) aciona um defeito de segmentação e o termina.
O Execshield também inclui suporte para a tecnologia No eXecute (NX) em plataformas AMD64 e tecnologia eXecute Disable (XD) em Itanium e sistemas Intel® 64. Estas tecnologias trabalham em conjunto com o ExecShield para impedir códigos maliciosos de rodar na porção de memória virtual executável com uma granularidade de 4KB de código executável, baixando o risco de ataque a partir de explorações stealthy buffer overflow.

Importante

Para limitar a exposição de ataques na rede, todos os serviços que não são usados devem ser desligados.

2.1.5.2. Identificando e Configurando Serviços

Para aumentar a segurança, a maioria dos serviços de rede instalados com o Red Hat Enterprise Linux são desligados por padrão. Existem, entretanto, algumas exceções notáveis:
  • cupsd — O servidor de impressão do Red Hat Enterprise Linux.
  • lpd — Um servidor de impressão alternativo.
  • xinetd — Um super servidor que controla conexões de uma variedade de servidores subordinados, tais como gssftp e telnet.
  • sendmail — O Sendmail Mail Transport Agent (MTA) é ativado por padrão, mas somente escuta por conexões do localhost.
  • sshd — O servidor OpenSSH que é um substituto seguro para o Telnet.
Quando determinar se deixar ou não estes serviços rodando, é melhor usar o bom senso com cautela. Por exemplo, se uma impressora não está disponível, não deixe o cupsd rodando. O mesmo é verdadeiro para o portmap. Se você não montar os volumes NFSv3 ou usar o NIS (o serviço ypbind), então o portmap deve ser desativado.
Ferramentas de Configuração de Serviços

Figura 2.3. Ferramentas de Configuração de Serviços

Se não estiver certo do propósito para um serviço em particular, a Ferramenta de Configuração de Serviços possui um campo de descrição, ilustrado na Figura 2.3, “Ferramentas de Configuração de Serviços”, que fornece informações adicionais.
Verificando quais serviços de rede estão disponíveis para iniciar no momento de boot é somente uma parte da história. Você deve também verificar quais portas estão abertas e escutando. Consulte a Seção 2.2.8, “Verificando Quais Portas Estão Escutando” para mais informações.

2.1.5.3. Serviços Inseguros

Potencialmente, qualquer serviço de rede é inseguro. Isto explica porque desligar serviços não utilizados é tão importante. Explorações de serviços são rotineiramente revelados e corrigidos, sendo muito importante atualizar regularmente pacotes associados com quaisquer serviços de rede. Consulte a Seção 1.5, “Atualizações de Segurança” para mais informações.
Alguns protocolos de rede são inerentemente mais inseguros que outros. Estes incluem quaisquer serviços que:
  • Transmitir Nomes de Usuários e Senhas Sobre uma Rede Sem Encriptação — Muitos protocolos antigos, como Telnet e FTP não fazem encriptação da sessão de autenticação e deveriam ser evitados sempre que possível.
  • Transmitir Dados Sensíveis Sobre uma Rede Sem Encriptação — Muitos protocolos transmitem dados sobre uma rede sem encriptação. Estes protocolos incluem Telnet, FTP, HTTP e SMTP. Muitos sistemas de arquivos de rede, como NFS e SMB também transmitem informações sobre a rede sem encriptação. É a responsabilidade do usuário limitar quais tipos de dados são transmitidos quando usar estes protocolos.
    Serviços de Dump de Memória Remota, como o netdump, transmitem os conteúdos de memória sobre a rede sem encriptação. Dumps de memória podem conter senhas ou, ainda pior, entradas de banco de dados e outras informações sensíveis.
    Outros serviços como o finger e rwhod revelam informações sobre os usuários do sistema.
Exemplos de serviços inerentemente inseguros incluem rlogin, rsh, telnet e vsftpd.
Todos os logins remotos e programas de shell (rlogin, rsh, e telnet) devem ser evitados em favor do SSH. Consulte a Seção 2.1.7, “Ferramentas de Comunicação Avançadas de Segurança” para mais informações sobre o sshd.
O FTP não é inerentemente perigoso à segurança do sistema como shells remotos, mas servidores FTP deve ser cuidadosamente configurados e monitorados para evitar problemas. Consulte a Seção 2.2.6, “Protegendo o FTP” para mais informações sobre proteger servidores FTP.
Serviços que devem ser cuidadosamente implementados e colocados em firewall incluem:
  • finger
  • authd (este era chamado identd em versões anteriores do Red Hat Enterprise Linux.)
  • netdump
  • netdump-server
  • nfs
  • rwhod
  • sendmail
  • smb (Samba)
  • yppasswdd
  • ypserv
  • ypxfrd
Mais informações sobre proteger serviços de rede estão disponíveis na Seção 2.2, “Segurança do Servidor”.
A próxima seção discute ferramentas para configurar um firewall simples.

2.1.6. Firewalls Pessoais

Depois de que os serviços de redes necessários são configurados, é importante implementar um firewall.

Importante

Você deve configurar os serviços necessários e implementar um firewall antes de conectar à internet ou qualquer outra rede que você não confiar.
Os firewalls impedem pacotes de rede de acessar a interface de rede de sistema. Se um pedido é feito a uma porta que está bloqueada por um firewall, o pedido é ignorado. Se um serviço está escutando em uma dessas portas bloqueadas, ele não recebe os pacotes e está efetivamente desativado. Por esta razão, cuidado deve ser tomado quando configurar um firewall para bloquear o acesso às portas que não estão em uso, enquanto não bloquear acesso às portas usadas pelos serviços configurados.
Para a maioria dos usuários, a melhor ferramenta para configurar um firewall simples é a ferramenta de configuração de firewall gráfica que vem junto com o Red Hat Enterprise Linux: a Firewall Configuration Tool (system-config-firewall) . Esta ferramenta cria regras abrangentes de iptables para um firewall de uso geral usando uma interface de painel de controle.
Consulte a Seção 2.5.2, “Configuração de Firewall Básica” para mais informações sobre usar esta aplicação e suas opções disponíveis.
Para usuários avançados e administradores de servidor, configurar manualmente um firewall com o iptables é provavelmente a melhor opção. Consulte a Seção 2.5, “Firewalls” para mais informações. Consulte a Seção 2.6, “IPTables” para um guia compreensivo do comando iptables.

2.1.7. Ferramentas de Comunicação Avançadas de Segurança

Conforme o tamanho e popularidade da internet cresceu, também cresceram as ameaças de interceptação de comunicação. Ao passar dos anos, ferramentas tem sido desenvolvidas para encriptar comunicações conforme elas são transferidas na rede.
O Red Hat Enterprise Linux 6 vem com duas ferramentas básicas que usam um alto nível de algoritmos de criptografia baseados em criptografia de chave pública para proteger as informações conforme elas viajam na rede.
  • OpenSSH — Uma implementação grátis do protocolo SSH para encriptação de comunicação de rede.
  • Gnu Privacy Guard (GPG) — Uma implementação grátis da aplicação de encriptação PGP (Pretty Good Privacy) para dados.
O OpenSSH é uma maneira segura de acessar uma máquina remota e substituir serviços antigos, sem criptografia como o telnet e rsh. O OpenSSH inclui um serviço de rede chamado sshd e três aplicações clientes de linha de comando:
  • ssh — Um cliente de acesso remoto de console seguro.
  • scp — Um comando de cópia remota seguro.
  • sftp — Um cliente de pseudo ftp seguro que permite sessões de transferência de arquivos seguros.
Consulte o Seção 3.6, “Secure Shell (Shell Segura)” para mais informações relacionadas sobre o OpenSSH.

Importante

Apesar do serviço sshd ser inerentemente seguro, o serviço deve ser mantido atualizado para impedir ameaças de segurança. Consulte a Seção 1.5, “Atualizações de Segurança” para mais informações.
O GPG é uma maneira de proteger comunicações de e-mail privadas. Ele pode ser usado tanto para enviar e-mails com dados sensíveis em redes públicas quanto proteger dados sensíveis em discos rígidos.

[11] Já que as BIOS de sistemas diferem entre fabricantes, algumas podem não suportar proteção por senha de qualquer tipo, enquanto outras podem suportar um certo tipo mas não o outro.
[12] O GRUB também aceita senhas sem encriptação, mas é recomendado que um hash MD5 seja usado para segurança adicional
[13] Este acesso é ainda sujeito às restrições impostas pelo SELinux, se ativado