Para auxiliar na seleção de ferramentas para a avaliação de vulnerabilidade, é útil estabelecer uma metodologia de avaliação de vulnerabilidade. Infelizmente, não há nenhuma metodologia pré-definida ou aprovada pelo setor no momento, porém bom senso e as melhores práticas podem agir suficientemente como guias.

Qual é o alvo? Nós estamos verificando um servidor, ou verificando nossa rede inteira e tudo que há nesta rede? Somos internos ou externos à empresa? As respostas à estas questões são importantes, pois ajudam a determinar não apenas quais ferramentas selecionar, mas também a maneira como são utilizadas.

Para aprender mais sobre o estabelecimento de metodologias, consulte os seguintes sites:

Nmap é uma ferramenta popular incluída no Red Hat Enterprise Linux que pode ser usada para determinar o layout de uma rede. O Nmap já existe há muitos anos e é provavelmente a ferramenta mais utilizada na coleta de informações. Há uma página man excelente que oferece uma descrição detalhada de suas opções e usos. Administradores podem usar o Nmap em uma rede para encontrar sistemas host e portas abertas nestes sistemas.

O Nmap é um primeiro passo eficaz na avaliação de vulnerabilidade. Você pode mapear todas as máquinas dentro de sua rede, e inclusive passar uma opção que permite ao Nmap tentar identificar o sistema operacional rodando numa determinada máquina. O Nmap é uma boa base para estabelecer normas de uso de serviços seguros e para parar serviços não usados.

nmap foo.example.com

Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

O Nessus é um scanner de segurança 'full-service'. Sua arquitetura plug-in permite que usuários o personalizem para seus sistemas e redes. Assim como qualquer scanner, o Nessus é tão bom quanto o banco de dados de assinaturas com o qual ele conta. Felizmente, o Nessus é freqüentemente atualizado e conta com relatório completo, escaneamento do host e buscas de vulnerabilidades em tempo real. Lembre-se que podem haver falsos positivos e falsos negativos, mesmo numa ferramenta tão poderosa e freqüentemente atualizada como o Nessus.

Para mais informações sobre o Nessus, consulte o site oficial no endereço:

http://www.nessus.org/

O Nikto é um excelente scanner de scripts CGI. O Nikto não tem apenas a capacidade de verificar vulnerabilidades CGI, mas também de fazê-lo de maneira evasiva, para enganar sistemas de detecção de intrusão. Acompanha uma documentação excelente que deve ser revisada cuidadosamente antes de executar o programa. Se você tem servidores Web servindo scripts CGI, o Nikto pode ser um excelente recurso para checar a segurança destes servidores.

Mais informações sobre o Nikto podem ser encontradas no seguinte endereço:

http://www.cirt.net/code/nikto.shtml

O VLAD é um scanner de vulnerabilidades desenvolvido pela equipe RAZOR na Bindview, Inc., que verifica a lista das dez questões mais comuns de segurança da SANS (questões do SNMP, compartilhamento de arquivos, etc.). Vale a pena investigar o VLAD, apesar de não ter tantas funcionalidades quanto o Nessus.

Mais informações sobre o VLAD podem ser encontradas no site da equipe RAZOR no seguinte endereço:

http://www.bindview.com/Support/Razor/Utilities/

Dependendo do seu objetivo e recursos, existe uma grande disponilidade de ferramentas. Há ferramentas para redes sem fio, redes Novell, sistemas Windows, sistemas Linux entre outros. Outra parte essencial ao executar avaliações é incluir uma revisão de segurança física, controle de pessoal ou avaliação da rede de voz/PBX. Conceitos novos como o escaneamento war walking no perímetro das estruturas físicas de sua empresa para encontrar vulnerabilidades da rede sem fio são conceitos emergentes que você pode considerar e, se necessário, incorporá-los às suas avaliações. Imaginação e exposição são os únicos limites para planejar e conduzir avaliações de vulnerabilidade.

Há diversos grupos distintos de indivíduos que encontram e exploram vulnerabilidades em redes e sistemas. Estes grupos são normalmente descritos de acordo com a tonalidade do chapéu que "vestem" ao realizar suas investigações de segurança, e essa tonalidade indica suas intenções.

O hacker de chapéu branco é aquele que testa redes e sistemas para examinar a performance e a vulnerabilidade à potenciais intrusões. Geralmente, hackers de chapéu branco violam seus próprios sistemas ou sistemas de um cliente que os empregou especificamente para executar uma auditoria de segurança. Pesquisadores acadêmicos e profissionais da área de consultoria de segurança são dois exemplos de hackers de chapéu branco.

Um hacker de chapéu preto é sinônimo de um cracker. Em geral, crackers são menos focados em programação e no aspecto acadêmico de violar sistemas. Eles geralmente contam com programas de quebra de segurança e exploram vulnerabilidades conhecidas em sistemas para descobrir informações importantes para ganho pessoal ou para danificar o sistema ou rede alvos.

O hacker de chapéu cinza, por outro lado, tem as habilidades e intenções de um hacker de chapéu branco na maioria dos casos, mas por vezes utiliza seu conhecimento para propósitos menos nobres. Um hacker de chapéu cinza pode ser descrito como um hacker de chapéu branco que às vezes veste um chapéu preto para atingir seus próprios objetivos.

Hackers de chapéu cinza tipicamente se enquadram em outro tipo de ética, que diz ser aceitável violar sistemas desde que o hacker não cometa roubo ou viole a privacidade. Alguns argumentam, no entanto, que o ato de invadir um sistema por si só já é anti-ético.

Independentemente da intenção do intruso, é importante saber quais as fraquezas que um cracker geralmente tentará explorar. O resto do capítulo concentra-se nestas questões.

Uma rede mal configurada é um ponto de entrada básico para usuários não autorizados. Deixar uma rede local baseada na confiança aberta e vulnerável à uma rede altamente insegura como a Internet, é o mesmo que deixar uma porta entreaberta em uma vizinhança perigosa — talvez nada aconteça por um período, mas eventualmente alguém explorará a oportunidade.

Uma instalação completa do Red Hat Enterprise Linux contém mais de mil pacotes de aplicações e bibliotecas. No entanto, a maioria dos administradores de servidor optam por não instalar todos os pacotes da distribuição; preferindo ao invés disso instalar os pacotes básicos, incluindo diversas aplicações para servidor.

A maioria das aplicações de servidor inclusas em uma instalação padrão são sólidas unidades de software testadas exaustivamente. Tendo sido utilizadas em ambientes de produção por muitos anos, seus códigos vem tendo sido constantemente refinados e muitos dos erros (bugs) foram encontrados e consertados.

Entretanto, não existe software perfeito e sempre há espaço para mais aprimoramento. Além disso, programas mais novos freqüentemente não são rigorosamente testados como se espera, porque chegaram recentemente a ambientes de produção ou porque talvez não sejam tão populares quanto outros programas de servidor.

Desenvolvedores e administradores de sistemas freqüentemente encontram erros exploráveis em aplicações de servidor e publicam a informação em sites de rastreamento de erros e relacionados à segurança, como a lista de discussão 'Bugtraq' (http://www.securityfocus.com) ou o site do CERT, 'Computer Emergency Response Team' (http://www.cert.org). Apesar destes mecanismos serem maneiras efetivas de alertar a comunidade sobre vulnerabilidades de segurança, é responsabilidade dos administradores atualizarem seus sistemas prontamente. Isto porque os crackers têm acesso aos mesmos serviços de rastreamento de vulnerabilidades e utilizarão estas informações para violar sistemas desatualizados sempre que puderem. Uma boa administração de sistemas requer vigilância, constante rastreamento de erros, e manutenção apropriada para assegurar um ambiente computacional mais seguro.

Consulte a Seção 1.4, “Atualizações de Segurança” para mais informações sobre como manter um sistema atualizado.

Administradores que não atualizam seus sistemas representam uma das grandes ameaças à segurança de servidores. De acordo com o System Administration Network and Security Institute (SANS), a causa principal da vulnerabilidade na segurança de computadores é "delegar a manutenção de segurança à pessoas não treinadas e não prover nem treinamento nem tempo para que o trabalho seja executado."^[1] Isto se aplica tanto a administradores inexperientes quanto a administradores super-confiantes ou desmotivados.

Alguns administradores não atualizam seus servidores e estações de trabalho, enquanto outros não monitoram as mensagens de registro do kernel do sistema ou tráfego de rede. Outro erro comum é deixar senhas ou chaves padrão de serviços inalteradas. Por exemplo, alguns bancos de dados têm senhas de administração padrão porque seus desenvolvedores assumem que o administrador de sistemas irá alterá-las imediatamente após a instalação. Se um administrador de banco de dados deixar de alterar esta senha, até mesmo um cracker inexperiente pode utilizar uma senha padrão conhecida para obter privilégios administrativos ao banco de dados. Estes são apenas alguns dos exemplos de como uma administração desatenta pode levar ao comprometimento de servidores.

Até a empresa mais atenta pode ser vítima de vulnerabilidades se os serviços de rede que elas optarem por usar forem essencialmente inseguros. Por exemplo, há muitos serviços desenvolvidos sob a suposição de que serão utilizados através de redes confiáveis, mas essa suposição deixa de ser verdadeira a partir do momento em que o serviço for disponibilizado através da Internet — que por si só é essencialmente não confiável.

Uma categoria de serviços de rede inseguros e composta por aqueles serviços que requerem nomes de usuário e senha não criptografados para autenticação. Telnet e FTP são dois exemplos deste tipo de serviço. Se um software de farejamento de pacotes está monitorando o tráfego entre o usuário remoto e um destes tipos de serviço, dados como nomes de usuário e senhas podem ser interceptados facilmente.

Tais serviços também podem mais facilmente tornarem-se vítimas do que o setor de segurança chama de ataque man-in-the-middle. Neste tipo de ataque um cracker redireciona o tráfego de rede, levando um servidor de nomes crackeado a apontar para sua máquina ao invés do servidor genuíno. Quando alguém abrir uma sessão remota para este servidor genuíno, a máquina do atacante age como um túnel invisível capturando as informações entre o serviço remoto e o crédulo usuário. Desta maneira um cracker consegue obter senhas administrativas e dados sem que o servidor ou o usuário percebam.

Outra categoria de serviços inseguros são sistemas de arquivos de rede e serviços de informação, como NFS ou NIS, desenvolvidos explicitamente para uso em redes locais mas que, infelizmente, têm seu uso estendido também para redes geograficamente distribuídas (para usuários remotos). O NFS não tem, de acordo com sua configuração padrão, nenhuma autenticação ou quaisquer mecanismos de segurança configurados para prevenir um cracker de montar o modo de compartilhamento e acessar qualquer coisa contida nele. O NIS também tem informações vitais que devem ser conhecidas por cada computador em uma rede, incluindo senhas e permissões de arquivo, em um banco de dados no formato somente-texto ASCII ou DBM (derivado do ASCII). Um cracker que obtém acesso a este banco de dados pode então acessar todas as contas de usuário de uma rede, inclusive a conta do administrador.

Embora um administrador possa ter um servidor completamente seguro e atualizado, não significa que usuários remotos estejam seguros ao acessá-lo. Por exemplo, se o servidor oferece os serviços Telnet e FTP através de uma rede pública, um atacante pode capturar os caracteres de nomes de usuário e senhas enquanto estes são movimentados através da rede, e então usar as informações da conta para acessar a estação de trabalho do usuário remoto.

Mesmo ao utilizar protocolos seguros, como o SSH, um usuário remoto pode estar vulnerável a determinados ataques se ele não mantiver suas aplicações cliente atualizadas. Por exemplo, clientes SSH v.1 (versão 1) são vulneráveis a um ataque X-forwarding de servidores SSH maléficos. Uma vez conectado ao servidor, o atacante pode capturar, sem ser percebido, quaisquer teclas pressionadas e cliques de mouse efetuados pelo cliente através da rede. Este problema foi consertado na versão SSH v.2, mas ainda assim depende do usuário monitorar aplicações com tais vulnerabilidades e atualizá-las quando necessário.

O Red Hat Network permite que a maior parte do processo de atualização seja automatizado. Ele determina quais pacotes RPM são necessários para o sistema, faz o download destes a partir de um repositório seguro, verifica-lhes a assinatura para assegurar que os mesmos não foram corrompidos, e os atualiza. A instalação de pacotes pode ser feita imediatamente ou pode ser agendada durante um determinado período de tempo.

O Red Hat Network requer um Perfil do Sistema para cada máquina a ser atualizada. O Perfil do Sistema contém informação sobre o hardware e o software do sistema. Essa informação é mantida confidencialmente, sendo usada somente para determinar quais atualizações de errata são aplicáveis a cada sistema. Sem o perfil, o Red Hat Network não pode determinar se um sistema precisa de atualizações. Quando uma errata de segurança (ou qualquer tipo de errata) é lançada, o RHN envia um email com a descrição da errata assim como uma lista de sistemas afetados por ela. Para aplicar a atualização, use o Agente de Atualizações Red Hat ou agende a atualização do pacote pelo site http://rhn.redhat.com.

Quando relatórios de erratas de segurança são lançados, são publicados no site de Erratas da Red Hat disponível em http://www.redhat.com/security/. A partir desta página, selecione o produto e a versão de seu sistema, e então selecione segurança no topo da página para exibir apenas os Relatórios de Segurança do Red Hat Enterprise Linux. Se a sinopse de um dos relatórios descreve um pacote usado em seu sistema, clique na sinopse para ver mais detalhes.

A página de detalhes descreve o exploit de segurança e quaisquer instruções especiais a serem executadas para atualizar o pacote e consertar a brecha na segurança.

Para fazer o download do(s) pacote(s) atualizado(s), clique no link para se logar no Red Hat Network, clique no(s) nome(s) do(s) pacote(s) e salve-os no disco rígido. É altamente recomendável que você crie um novo diretório como /tmp/updates e salve ali todos os pacotes baixados.

Todos os pacotes do Red Hat Enterprise Linux são assinados com a chave GPG da Red Hat, Inc. GPG significa GNU Privacy Guard, ou GnuPG, um pacote de software livre usado para garantir a autenticidade de arquivos distribuídos. Por exemplo, uma chave privada (chave secreta) mantida pela Red Hat chaveia o pacote enquanto a chave pública abre e verifica. Se a chave pública distribuída pela Red Hat não confere com a chave privada durante a verificação do RPM, o pacote pode ter sido alterado e, portanto, não é confiável.

O utilitário RPM do Red Hat Enterprise Linux tenta automaticamente verificar a assinatura GPG de um pacote RPM antes de instalá-lo. Se a chave GPG da Red Hat não estiver instalada, instale-a a partir de uma localidade segura e estática, como o CD-ROM de instalação do Red Hat Enterprise Linux.

Assumindo que o CD-ROM esteja montado em /mnt/cdrom use o seguinte comando para importá-la para o chaveiro (um banco de dados do sistema com chaves confiáveis):

rpm --import /mnt/cdrom/RPM-GPG-KEY

Para exibir uma lista com todas as chaves instaladas para verificação de RPMs, execute o seguinte comando:

rpm -qa gpg-pubkey*

Para a chave da Red Hat, o resultado na tela inclui o seguinte:

gpg-pubkey-db42a60e-37ea5438

Para exibir detalhes sobre uma chave específica, use o comando rpm -qi seguido do output do comando anterior, conforme este exemplo:

rpm -qi gpg-pubkey-db42a60e-37ea5438

É extremamente importante verificar a assinatura dos arquivos RPM antes de instalá-los para ter certeza de que eles não foram alterados depois do lançamento dos pacotes pela Red Hat, Inc. Para verificar todos os pacotes baixados de uma só vez, submeta o seguinte comando:

rpm -K /tmp/updates/*.rpm

Para cada pacote, se a chave GPG for verificada com sucesso, o comando retorna gpg OK. Caso contrário, certifique-se de usar a chave pública correta da Red Hat, assim como verificar a fonte do conteúdo. Os pacotes que não passarem na verificação GPG não devem ser instalados, pois podem ter sido alterados por terceiros.

Após verificar as chaves GPG e fazer o download de todos os pacotes associados ao relatório da errata, instale os pacotes como root em uma janela de comandos.

A instalação da maioria dos pacotes pode ser feita com segurança (exceto pacotes do kernel) através do seguinte comando:

rpm -Uvh /tmp/updates/*.rpm

Para pacotes do kernel, use o seguinte comando:

rpm -ivh /tmp/updates/<pacote-de-kernel>

No exemplo anterior, substitua <pacote-de-kernel> pelo nome do RPM do kernel.

Após reinicializar a máquina com sucesso usando o novo kernel, o kernel antigo deve ser removido usando o seguinte comando:

rpm -e <pacote-de-kernel-antigo>

No exemplo anterior, substitua <pacote-de-kernel-antigo> pelo nome do RPM do kernel antigo.

Após fazer o download e instalar as erratas de segurança através da Red Hat Network ou do site de erratas da Red Hat, é importante parar de usar o software antigo e passar a usar o novo. O modo como isso é feito depende do tipo de software que foi atualizado. A lista a seguir aponta as categorias gerais de software e oferece instruções para usar as versões atualizadas após uma atualização de pacotes.

As duas razões principais para proteger o BIOS de um computador através do uso de uma senha são ^[2]:

Como os métodos para definir uma senha para o BIOS variam de acordo com o fabricante do computador, consulte o manual do seu computador para obter instruções específicas.

Se você esquecer a senha do BIOS, ela pode ser restaurada com jumpers na placa-mãe ou desligando a bateria do CMOS. Por esta razão, é aconselhável prevenir (por exemplo, chavear) o acesso aos componentes internos do computador, se possível. Entretanto, consulte o manual do computador ou da placa-mãe antes de tentar desligar a bateria do CMOS.

Veja a seguir as principais razões para proteger um carregador de inicialização Linux com senha:

O Red Hat Enterprise Linux para a plataforma x86 vem com o carregador de inicialização GRUB. Para informações detalhadas sobre o GRUB, consulte o Guia de Instalação Red Hat.

/sbin/grub-md5-crypt

password --md5 <hash-da-senha>

title DOS lock

title DOS lock password --md5 <hash-da-senha>

Ao criar uma senha robusta, é uma boa idéia seguir estas instruções:

As seguintes diretrizes lhe ajudarão a criar uma senha robusta:

Com todas estas regras, parece difícil criar uma senha que siga todos os critérios e evitar as características de uma senha ruim. Felizmente, existem alguns passos simples que podem ser seguidos para gerar uma senha fácil de lembrar e segura.

Se houver um número significativo de usuários em uma organização, os administradores de sistemas têm duas opções básicas para forçar o uso de boas senhas. Eles podem criar senhas para os usuários, ou podem deixar que os usuários criem suas próprias senhas, enquanto verificam se as senhas têm qualidade aceitável.

Criar senhas para os usuários garante que as senhas sejam boas, mas torna-se uma tarefa complicada conforme a empresa cresce. Também aumenta o risco dos usuários anotarem suas senhas.

Por estas razões, a maioria dos administradores de sistema prefere que os usuários criem suas próprias senhas, mas ativamente verificam se as senhas são boas e, em alguns casos, forçam os usuários a trocarem suas senhas periodicamente conforme as senhas vão envelhecendo.

2.1.3.2.2. Vencimento de Senhas

O vencimento de senhas é uma outra técnica usada por administradores de sistema para se combater o uso de senhas fracas dentro de uma empresa. O vencimento de senhas significa que após um determinado tempo (geralmente 90 dias), o usuário é obrigado a criar uma nova senha. Na teoria, se o usuário é forçado a trocar sua senha periodicamente, uma quebra de senha será útil para um intruso somente por um tempo limitado. A desvantagem desta técnica, no entanto, é que usuários tendem a anotar suas senhas.

Existem dois programas principais usados para efetivar o uso do vencimento de senhas no Red Hat Enterprise Linux: o comando chage ou o aplicativo gráfico Gerenciador de Usuários (system-config-users).

A opção -M do comando chage especifica a validade máxima de uma senha (em número de dias). Por exemplo, para fazer com que a senha de um usuário vença em 90 dias, use o seguinte comando:

chage -M 90 <nome-de-usuário>

No comando acima, substitua <nome-de-usuário> pelo nome de usuário correspondente. Para fazer com que a senha nunca vença, é comum usar o valor 99999 após a opção -M (isto equivale a um pouco mais do que 273 anos).

Você também pode usar o comando chage em modo interativo para modificar o vencimento e detalhes de várias senhas ao mesmo tempo. Use o seguinte comando para entrar em modo interativo:

chage <nome-de-usuário>

O trecho a seguir é um exemplo de uma sessão interativa usando este comando:

 [root@interch-dev1 ~]# 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@interch-dev1 ~]# 

Consulte a página man do chage para maiores informações sobre as opções disponíveis.

Você também pode usar o gráfico do aplicativo Gerente de Usuário para criar uma política de vencimento de senha, como se segue. Note: você precisará dos privilégios do Administrador para aplicar este procedimento.

1. Clique no menu Sistema no Painel, escolha Administração e clique em Usuários e Grupos para mostrar o Gerente de Usuário. Como outra alternativa, digite o comando system-config-users na janela de comandos.

2. Clique na aba Usuários, e selecione o usuário requerido na lista de usuários.

3. Clique em Propriedades na barra de ferramentas para mostrar a caixa de diálogo das Propriedades do Usuário ( ou escolha Propriedades no menu Arquivo).

4. Em seguida, clique na aba Informações de Senhas e insira o número de dias antes da senha vencer, conforme mostra a Figura 2.1, “Especificando as opções de vencimento da senha”.

5. Insira o valor solicitado no campo Dias antes da solicitação de mudança e clique em OK.

Ilustração da aba Informações de Senhas.

Figura 2.1. Especificando as opções de vencimento da senha

Se os usuários de uma organização são de confiança e bem treinados em relação ao uso de computadores, permitir que eles gozem de acesso root talvez não seja uma preocupação. Permitir que usuários tenham acesso root significa que atividades corriqueiras, como a adição de dispositivos ou configuração de interfaces de rede, sejam administradas por cada usuário, deixando administradores de sistemas livres para lidar com a segurança de rede e outras questões importantes.

Por outro lado, a permissão de acesso root à usuários individuais pode levantar as seguintes questões:

Se um administrador não confia em deixar que usuários autentiquem-se como root por essas ou outras razões, a senha root deve ser mantida em segredo, e acesso aos modos runlevel one ou usuário individual deve ser desabilitado através da proteção do carregador de inicialização por senha (consulte a Seção 2.1.2.2, “Senhas do Carregador de Inicialização” para maiores informações sobre este tópico).

Tabela 2.1, “Métodos para Desativar a Conta Root” descreve outras iniciativas que um administrador pode usar para ter certeza de que logins como root não são permitidos:

echo > /etc/securetty

# PermitRootLogin yes

 PermitRootLogin no

auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

Ao invés de recusar completamente o acesso ao usuário root, o administrador pode permitir o acesso apenas através de programas setuid, como o su ou o sudo.

2.1.4.3.1. O Comando su

Quando um usuário executa o comando su, o mesmo precisa entrar com a senha root e, após a autenticação, recebe uma solicitação de janela da root.

Uma vez autenticado através do comando su, o usuário é o usuário root e tem acesso administrativo total ao sistema^[4]. Além disso, ao se tornar um usuário root, é possível que ele use o comando su para assumir a identidade de qualquer outro usuário no sistema sem precisar entrar com a respectiva senha.

Como este programa é tão poderoso, administradores dentro de uma empresa talvez queiram limitar quem pode acessá-lo.

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 <nome-de-usuário>

No comando anterior, substitua <nome-de-usuário> pelo nome do usuário sendo adicionado ao grupo wheel.

Você também pode usar o Gerente de Usuário para modificar os membros do grupo, como se segue. Note: você precisará dos privilégios do Administrador para aplicar este procedimento.

1. Clique no menu Sistema no Painel, escolha Administração e clique em Usuários e Grupos para mostrar o Gerente de Usuário. Como outra alternativa, digite o comando system-config-users na janela de comandos.

2. Clique na aba Usuários, e selecione o usuário requerido na lista de usuários.

3. Clique em Propriedades na barra de ferramentas para mostrar a caixa de diálogo das Propriedades do Usuário ( ou escolha Propriedades no menu Arquivo).

4. A seguir, selecione a aba Grupos e clique no grupo wheel, conforme a Figura 2.2, “Adicionando usuários ao grupo "wheel".”.

5. Em seguida, abra o arquivo de configuração do PAM para o su (/etc/pam.d/su) em um editor de texto e remova o comentário # da seguinte linha:

   auth  required /lib/security/$ISA/pam_wheel.so use_uid
   

   Isso permitirá que somente membros do grupo administrativo wheel usem o programa.

Ilustração da seção Grupos

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

Nota

O usuário root é parte do grupo wheel de acordo com a configuração padrão.

sudo <comando>

juan ALL=(ALL) ALL

%users localhost=/sbin/shutdown -h now

Serviços de rede podem representar muitos riscos aos sistemas Linux. Veja abaixo uma lista dos principais problemas:

Para aumentar a segurança, a maioria dos serviços de rede instalados com o Red Hat Enterprise Linux são desligados por meio da configuração padrão. No entanto, há algumas exceções notáveis:

Ao determinar se estes serviços devem ou não ser deixados rodando, é melhor usar o bom senso e pecar pela precaução. Por exemplo, se uma impressora não está disponível, não deixe o cupsd rodando. O mesmo vale para o portmap. Se você não monta volumes NFSv3 ou não usa o NIS (o serviço ypbind), então o portmap deve ser desabilitado.

Ilustração da Ferramenta de Configuração de Serviços

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

Se você não tiver certeza se um serviço é necessário ou não, a Ferramenta de Configuração de Serviços oferece um campo de descrição, ilustrado na Figura 2.3, “Ferramenta de Configuração de Serviços”, que oferece informações adicionais sobre cada serviço.

Mas verificar quais serviços de rede estão disponíveis durante a inicialização não é suficiente. Você também deve verificar quais portas estão abertas e em escuta. Consulte a Seção 2.2.8, “Verificando Quais Portas estão Escutando” para maiores informações.

Alguns protocolos de rede são essencialmente mais inseguros que outros. Estes incluem quaisquer serviços que:

Entre os exemplos de serviços inseguros herdados, incluem rlogin, rsh, telnet, and vsftpd.

Todos os programas remotos de autenticação e shell (rlogin, rsh, e telnet) devem ser evitados em favor do SSH. Consulte a Seção 2.1.7, “Ferramentas de Comunicação com Segurança Aprimorada” para maiores informações a respeito do sshd.

O FTP não é essencialmente tão perigoso à segurança do sistema quanto shells remotos, mas os servidores FTP devem ser configurados e monitorados cuidadosamente para evitar problemas. Consulte a Seção 2.2.6, “Protegendo o FTP” para maiores informações sobre a implementação de medidas de segurança em servidores FTP.

Os seguintes serviços devem ser cuidadosamente implementados e colocados atrás de um firewall:

Maiores informações sobre como implementar medidas de segurança para serviços de rede podem ser encontradas na Seção 2.2, “Segurança do Servidor”.

A próxima seção aborda as ferramentas disponíveis para a configuração de um firewall simples.

Os TCP wrappers são capazes de fazer muitas outras coisas além de simplesmente negar acesso aos serviços. Esta seção ilustra como eles podem ser utilizados para enviar banners de conexão, alertar ataques em hosts específicos e aprimorar a funcionalidade de autenticação. Consulte a página man hosts_options para obter uma lista completa das funcionalidades e linguagem de controle do TCP Wrapper.

 220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Inappropriate use will result in your access privileges being removed. 

 vsftpd : ALL : banners /etc/banners/ 

 ALL : 206.182.68.0 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert 

 in.telnetd : ALL : severity emerg 

Esta seção concentra-se no uso do xinetd para configurar um serviço armadilha e usá-lo para controlar níveis de recursos disponíveis para quaisquer serviços xinetd. Estabelecer limites de recursos para serviços pode ajudar a frustrar ataques de Negação de Serviço (Denial of Service, ou DoS). Consulte as páginas man para o xinetd e o xinetd.conf para uma lista de opções disponíveis.

flags           = SENSOR

deny_time       = 30

disable         = no

É importante usar TCP Wrappers para limitar quais redes ou hosts têm acesso ao serviço portmap já que este não possui uma forma de autenticação própria.

Além disso, use somente endereços IP ao limitar acesso para o serviço. Evite usar estes nomes de host, já que eles podem ser forjados através da adulteração do DNS e outros métodos.

Para restringir ainda mais o acesso ao serviço portmap, é uma boa idéia adicionar regras do iptables ao servidor e restringir o acesso à redes específicas.

Abaixo encontram-se dois exemplos de comandos do iptables. O primeiro permite conexões TCP à porta 111 (usada pelo serviço portmap) a partir da rede 192.168.0.0/24. O segundo permite conexões TCP à mesma porta a partir do host local. Isto é necessário para o serviço sgi_fam usado pelo Nautilus. Todos os outros pacotes são descartados.

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP
iptables -A INPUT -p tcp -s 127.0.0.1  --dport 111 -j ACCEPT

Para limitar o tráfego UDP similarmente, use o seguinte comando.

iptables -A INPUT -p udp -s! 192.168.0.0/24  --dport 111 -j DROP

Como o NIS passa informações confidenciais sem criptografia através da rede, é importante que o serviço seja executado por trás de uma firewall e numa rede segmentada e segura. Toda vez que informações do NIS são passadas através de uma rede insegura, há o risco de serem interceptadas. O design cuidadoso da rede neste aspecto pode ajudar a prevenir sérias violações à segurança.

Qualquer máquina com um domínio NIS pode usar comandos para extrair informações do servidor sem autenticação, desde que o usuário saiba o nome do host DNS e o nome de domínio NIS do servidor.

Por exemplo, se alguém conectar um laptop a uma rede ou violar a rede por fora (e conseguir falsificar um endereço IP interno), o seguinte comando revela o mapa de /etc/passwd:

ypcat -d <NIS_domain> -h <DNS_hostname> passwd

Se este atacante for um usuário root, poderá obter o arquivo /etc/shadow digitando o seguinte comando:

ypcat -d <NIS_domain> -h <DNS_hostname> shadow

Para dificultar o acesso aos mapas NIS a um atacante, crie uma série randômica de caracteres para o nome de host DNS, tal como o7hfawtgmhwg.domain.com. Similarmente, crie um nome diferente de domínio NIS randomizado . Isto dificulta bastante o acesso de um atacante ao servidor NIS.

Se o arquivo /var/yp/securenets estiver vazio, ou não existir (como é o caso logo após uma instalação padrão), o NIS escuta à todas as redes. Uma das primeiras coisas a serem feitas é colocar pares de rede/máscara de rede no arquivo para que o ypserv apenas responda à pedidos de redes apropriadas.

Veja abaixo um exemplo de entrada de um arquivo /var/yp/securenets:

255.255.255.0     192.168.0.0

Essa técnica não oferece proteção contra ataque de spoofing de IP, mas pelo menos impõe limites a quais redes o servidor NIS serve.

Todos os servidores relacionados ao NIS podem ter portas específicas, exceto o rpc.yppasswdd — o daemon que permite a usuários alterarem suas senhas de autenticação. Atribuir portas para os outros dois daemons do servidor NIS, rpc.ypxfrd e ypserv, permite criar regras de firewall para proteger futuramente os daemons do servidor NIS contra intrusos.

Para fazer isto, adicione as seguintes linhas a /etc/sysconfig/network:

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

As seguintes regras do iptables podem ser determinadas para reforçar a qual rede o servidor escuta para estas portas:

iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 834 -j DROP
iptables -A INPUT -p ALL -s! 192.168.0.0/24  --dport 835 -j DROP

Isto significa que o servidor apenas permite conexões às portas 834 e 835 casos os pedidos venham da rede 192.168.0.0/24, independentemente do protocolo.

Uma das desvantagens mais gritantes ao usar NIS para autenticação é que sempre que um usuário se autentica numa máquina, um hash de senha é enviado do mapa /etc/shadow através da rede. Se um intruso obtiver acesso a um domínio NIS e bisbilhotar o tráfego de rede, os hashes de senha e nomes de usuários podem ser discretamente coletados. Com tempo suficiente, um programa de quebra de senhas pode adivinhar senhas fáceis e um atacante pode obter acesso a uma conta válida na rede.

Como o Kerberos usa criptografia de chave secreta, os hashes de senhas nunca são enviados através da rede, tornando o sistema bem mais seguro. Para saber mais sobre o Kerberos, consulte o Seção 2.6, “Kerberos”.

Agora que o NFSv4 tem a habilidade de passar todas as informações criptografadas usando o Kerberos através da rede, é importante que o serviço seja configurado corretamente se estiver atrás de um firewall ou numa rede segmentada. O NFSv2 e NFSv3 ainda passam dados de forma insegura e seus riscos devem ser considerados. Um planejamento cuidadoso da rede neste aspecto pode ajudar a prevenir violações à segurança.

O servidor NFS determina quais sistemas de arquivo e quais hosts exportar para estes diretórios através do arquivo /etc/exports. Cuidado para não adicionar espaços extras ao editar este arquivo.

Por exemplo, a linha a seguir no arquivo /etc/exports compartilha o diretório /tmp/nfs/ com o host bob.example.com com permissões de leitura e escrita.

/tmp/nfs/     bob.example.com(rw)

Por outro lado, esta linha do arquivo /etc/exports compartilha o mesmo diretório com o host bob.example.com com permissão somente-leitura, e o compartilha com o mundo com permissões leitura e escrita devido um único caractere de espaço após o nome de host.

/tmp/nfs/     bob.example.com (rw)

É bom praticar a verificação de quaisquer compartilhamentos NFS usando o comando showmount para checar o que está sendo compartilhado:

showmount -e <nome-de-host>

Por padrão, compartilhamentos NFS alteram o usuário root para o usuário nfsnobody, uma conta de usuário sem privilégios. Isto muda o proprietário de todos os arquivos criados pelo root para nfsnobody, que previne o carregamento de programas com o setuid definido.

Se no_root_squash é usado, os usuários root remotos poderão alterar qualquer arquivo do sistema de arquivo compartilhado e deixar aplicativos infectados por trojans, para que outros usuários os executem inadvertidamente.

Esta diretiva é habilitada por padrão, portanto tenha cuidado ao criar links simbólicos para a raiz dos documentos do servidor Web. Por exemplo, é uma má idéia prover um link simbólico para /.

Esta diretiva é habilitada por padrão, mas pode não ser desejável. Para prevenir que visitantes naveguem pelos arquivos no servidor, remova esta diretiva.

A diretiva UserDir é desabilitada por padrão porque esta pode confirmar a presença de uma conta de usuário no sistema. Para possibilitar a navegação pelos diretórios do usuário no servidor, use as seguintes diretivas:

UserDir enabled
UserDir disabled root

Estas diretivas ativam a navegação em todos os diretórios de usuário, exceto no /root/. Para adicionar usuários à lista de contas desativadas, adicione uma lista de usuários delimitada por espaço na linha UserDir disabled.

Por padrão, o módulo Server-Side Includes (SSI) não pode executar comandos. Não é recomendado alterar esta configuração a não ser que seja absolutamente necessário, já que pode, potencialmente, possibilitar que um atacante execute comandos no sistema.

Certifique-se de conceder permissões de gravação (write) apenas para o usuário root em todos os diretórios contendo scripts ou CGIs. Isto pode ser feito digitando os seguintes comandos:

chown root <nome-do-diretório>
chmod 755 <nome-do-diretório>

Antes de submeter um nome de usuário e senha, é apresentado um banner de saudação a todos os usuários. Por padrão, este banner inclui informações da versão úteis para crackers tentando identificar fraquezas num sistema.

Para alterar o banner de saudação do vsftpd, adicione a seguinte diretiva ao arquivo /etc/vsftpd/vsftpd.conf:

ftpd_banner=<insira_saudação_aqui>

Substitua <insira_saudação_aqui> na diretiva acima pelo texto de sua mensagem de saudação.

Para banners com muitas linhas, é melhor usar um arquivo de banner. Para simplificar o gerenciamento de banners múltiplos, coloque todos os banners em um novo diretório chamado /etc/banners/. O arquivo de banners para conexões FTP, neste exemplo, é /etc/banners/ftp.msg. O exemplo abaixo mostra como este arquivo se parece:

########## Hello, all activity on ftp.example.com is logged. #########

Para referenciar este arquivo de banners de saudação do vsftpd, adicione a seguinte diretiva ao arquivo /etc/vsftpd/vsftpd.conf:

banner_file=/etc/banners/ftp.msg

Também é possível enviar banners adicionais para conexões de entrada usando TCP wrappers conforme descrito na Seção 2.2.1.1.1, “TCP Wrappers e Banners de Conexão”.

A presença do diretório /var/ftp/ ativa a conta anônima.

A maneira mais fácil de criar este diretório é instalar o pacote vsftpd. Este pacote define uma árvore de diretório para usuários anônimos e configura as permissões dos diretórios para somente-leitura para usuários anônimos.

Por padrão, a conta do usuário anônimo não pode escrever em nenhum diretório.

mkdir /var/ftp/pub/upload

chmod 730 /var/ftp/pub/upload

drwx-wx---    2 root     ftp          4096 Feb 13 20:05 upload

anon_upload_enable=YES

Já que o FTP passa nomes de usuário e senhas não criptografados através de redes inseguras para autenticação, é uma boa idéia proibir usuários do sistema acessarem o servidor através de suas contas de usuário.

Para desativar contas de usuário em vsftpd, adicione a seguinte diretiva a /etc/vsftpd/vsftpd.conf:

local_enable=NO

Use TCP Wrappers para controlar o acesso a qualquer daemon do FTP, conforme descrito na Seção 2.2.1.1, “Aumentando a Segurança com TCP Wrappers”.

Devido à natureza de e-mails, um determinado atacante pode facilmente mandar uma enxurrada de correspondência para o servidor e causar um ataque de negação de serviço. Ao determinar limites para as diretivas a seguir em /etc/mail/sendmail.mc, a efetividade de ataques deste tipo é limitada.

Nunca coloque o diretório spool de correspondência, /var/spool/mail/, em um volume NFS compartilhado.

Como o NFSv2 e o NFSv3 não mantém controle sobre IDs de usuário e grupo, dois ou mais usuários podem ter o mesmo UID, e portanto receber e ler a correspondência do outro.

Para ajudar a prevenir exploits locais no servidor Sendmail, é melhor que usuários de mail acessem o Sendmail usando apenas um programa de email. Contas shell não devem ser permitidas no servidor de correspondência e todos os usuários shell do arquivo /etc/passwd devem ser definidos para /sbin/nologin (com a possível exceção do usuário root).

Os aplicativos seguintes são suportados atualmente pelo esquema de registro unificado em Red Hat Enterprise Linux:

Red Hat Enterprise Linux atualmente suporta os seguintes mecanismos de autenticação:

Red Hat Enterprise Linux foi testado com o cartão e leitor e-gate Cyberflex, mas qualquer cartão que seja compatível ao cartão Java 2.1.1 e especificações de Plataforma Global 2.0.1, devem operar corretamente, como qualquer outro leitor que seja suportado pelo PCSC-lite.

Red Hat Enterprise Linux também foi testado com Cartões de Acesso Comuns (CAC). O leitor suportado para CAC é o Leitor SCM SCR 331 USB.

As of Red Hat Enterprise Linux 5.2, Gemalto smart cards (Cyberflex Access 64k v2, standard with DER SHA1 value configured as in PKCSI v2.1) are now supported. These smart cards now use readers compliant with Chip/Smart Card Interface Devices (CCID).

Diversos mecanismos de segurança que existem atualmente, utilizam um grande número de protocolos e armazenamentos credenciais. Alguns exemplos incluem: SSL, SSH, IPsec e Kerberos. O SSO do Red Hat Enterprise Linux enfoca a unificação destes esquemas para suportar os requerimentos listados acima. Isto não significa substituir os Kerberos por certificados X.509v3, e sim uni-los para reduzir a carga, tanto dos usuários de sistemas e administradores como daqueles que os gerenciam.

Para atingir este objetivo , Red Hat Enterprise Linux

Se você tiver problemas para colocar seu cartão inteligente em funcionamento, tente usar o seguinte comando para localizar a fonte do problema:

pklogin_finder debug

Se você executar a ferramenta pklogin_finder no modo depurador, enquanto um cartão inteligente registrado estiver conectado, ela tentará enviar informações sobre a validade dos certificados. Se a tarefa for bem sucedida, ela tentará mapear um ID de registro dos certificados que estiverem no cartão.

Se você tiver seguido os passos de configuração acima mencionados e a autenticação Negotiate ainda não estiver funcionando, você pode habilitar o login verbal do processo de autenticação. Isto pode ajudá-lo a encontrar a causa do problema. Para habilitá-lo, utilize o seguinte procedimento:

Se você conseguir executar o kinit com êxito a partir de sua máquina mas não conseguir autenticá-lo, procure por algo como isto no arquivo de registro:

-1208994096[8d683d8]: entering nsAuthGSSAPI::GetNextToken()
-1208994096[8d683d8]: gss_init_sec_context() failed: Miscellaneous failure
Server not found in Kerberos database

Isto geralmente indica um problema de configuração no Kerberos. Esteja certo de que você possui as entradas corretas na seção [domain_realm] do arquivo /etc/krb5.conf. Por exemplo:

.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM

Se não aparecer nada no registro, é possível que você esteja atrás de um proxy e que o mesmo esteja apagando os cabeçalhos HTTP requeridos pela autenticação Negotiate. Para driblar este problema, você pode tentar conectar ao servidor usando o HTTPS, o que permitirá que as solicitações permaneçam intactas. Então proceda a depuração, utilizando o arquivo de registro, como descrito acima.

Cada aplicativo, ou serviço que use o PAM possui um arquivo no diretório /etc/pam.d/. Cada arquivo neste diretório tem o mesmo nome que o serviço ao qual ele controla o acesso.

O programa que usa o PAM é responsável por definir o seu nome de serviço e instalar o seu próprio arquivo de configuração do PAM no diretório /etc/pam.d/. Por exemplo, o programa login define o seu nome de serviço como login e instala o arquivo de configuração do PAM /etc/pam.d/login.

Existem atualmente quatro tipos de interfaces de módulo PAM. Cada uma destas corresponde a um aspecto diferente do processo de autorização:

Em um arquivo de configuração do PAM, o campo da interface de módulo é o primeiro a ser definido. Por exemplo, uma linha típica em uma configuração pode se parecer com o seguinte:

auth        required        pam_unix.so

Isto instrui o PAM a usar a interface auth do módulo pam_unix.so.

[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth        sufficient        pam_rootok.so
auth        required        pam_console.so
#auth        include        system-auth
account        required        pam_permit.so

Todos os módulos PAM geram um resultado de sucesso ou falha ao serem chamados. Sinalizadores de controle dizem ao PAM o que fazer com o resultado. Módulos podem ser agregados em uma certa ordem, e os sinalizadores de controle determinam a importância do sucesso ou da falha de um módulo específico em relação ao objetivo maior de efetuar a autenticação do usuário ao serviço.

Existem quatro sinalizadores de controle pré-definidos:

Uma nova sintaxe para sinalizadores de controle que permite controle de maior precisão é agora disponível ao PAM.

A man page pam.d e a documentação do PAM, disponível no diretório /usr/share/doc/pam-<número-da-versão>/, onde <número-da-versão> é o número da versão do PAM no seu sistema, descrevem esta nova sintaxe em detalhes.

O nome do módulo fornece ao PAM o nome do módulo plugável contendo a interface de módulo específica. Em versões mais antigas do Red Hat Enterprise Linux, o caminho completo para o módulo era fornecido no arquivo de configuração do PAM. Entretanto, desde a chegada dos sistemas multilib, os quais armazenam módulos PAM de 64 bits no diretório /lib64/security/, o nome do diretório é omitido porque o aplicativo é vinculado à versão certa do libpam, o qual é capaz de encontrar a versão correta do módulo.

O PAM usa argumentos para passar informações a um módulo plugável durante a autenticação para alguns módulos.

Por exemplo, o módulo pam_userdb.so usa informações armazenadas em um arquivo Berkeley DB para autenticar o usuário. O Berkeley DB é um sistema banco de dados de código aberto incorporado a vários aplicativos. O módulo leva um argumento db de forma que o Berkeley DB saiba qual banco de dados usar para o serviço requisitado.

Veja a seguir uma linha pam_userdb.so típica em uma configuração PAM. O <caminho-para-o-arquivo> é o caminho completo para o arquivo de banco de dados Berkeley DB:

auth        required        pam_userdb.so db=<caminho-para-o-arquivo>

Argumentos inválidos são geralmente ignorados e não afetam de maneira nenhuma o sucesso ou a falha do módulo PAM. Alguns módulos, entretanto, podem falhar ao encontrarem argumentos inválidos. A maioria dos módulos relatam erros no arquivo /var/log/secure.

Antes de abandonar um console onde um carimbo de data e hora do PAM esteja ativo, é recomendável que o arquivo de carimbo de data e hora seja destruído. Para fazer isto em um ambiente gráfico, clique no ícone de autenticação no painel. Isto faz com que uma caixa de diálogo apareça. Clique no botão Desistir da Autorização para destruir o arquivo de carimbo de data e hora ativo.

Ilustração da caixa de diálogo de cancelamento de autenticação.

Figura 2.8. Diálogo Cancelamento de Autenticação

Note o seguinte em relação ao arquivo de carimbo de data e hora do PAM:

Consulte a página man do pam_timestamp_check para maiores informações sobre a destruição de um arquivo de carimbo de data e hora usando o pam_timestamp_check.

O módulo pam_timestamp.so aceita várias diretivas. Veja a seguir as duas opções mais utilizadas:

Consulte a Seção 2.4.8.1, “Documentação Instalada” para mais informações sobre como controlar o módulo pam_timestamp.so.

Quando um usuário se autentica em um sistema Red Hat Enterprise Linux, o módulo pam_console.so é invocado pelos programas login ou pelos programas gráficos de autenticação, gdm, kdm, e xdm. Se este usuário for o primeiro a se autenticar no console físico — também chamado de usuário do console — o módulo dá ao usuário a propriedade sobre uma gama de dispositivos normalmente de propriedade do root. O usuário do console torna-se o dono destes dispositivos até que a última sessão local para aquele usuário termine. Após este usuário ter feito o logoff, a propriedade dos dispositivos reverte novamente para o usuário root.

Os dispositivos afetados incluem, entre outros, placas de som, e drives de disquete e de CD-ROM.

Esta facilidade permite que um usuário local manipule estes dispositivos sem obter acesso root, simplificando assim tarefas comuns para o usuário do console.

Você pode modificar a lista de dispositivos controlados pelo pam_console.so editando os seguintes arquivos:

Você pode mudar a permissão de dispositivos que não estejam listados nos arquivos acima, ou sobrescrever os padrões especificados. Ao invés de modificar o arquivo 50-default.perms, você deve criar um novo arquivo (por exemplo, xx-name.perms) e introduzir as modificações necessárias. O nome do novo arquivo padrão deve iniciar com um número maior do que 50 (por exemplo, 51-default.perms). Isto sobrescreverá os valores padrão no arquivo 50-default.perms.

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 
<xconsole>=:0\.[0-9] :0

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

O usuário do console também tem acesso a certos programas configurados no diretório /etc/security/console.apps/.

Este diretório contém arquivos de configuração que possibilitam que o usuário do console possa rodar certos aplicativos em /sbin e /usr/sbin.

Estes arquivos de configuração têm o mesmo nome dos aplicativos que eles configuram.

Um notável grupo de aplicativos aos quais o usuário do console tem acesso são três programas usados para desligar ou reinicializar o sistema:

Uma vez que estes aplicativos usam o PAM, eles fazem com que uma chamada ao módulo pam_console.so seja obrigatória para o seu uso.

Consulte a Seção 2.4.8.1, “Documentação Instalada” para maiores informações.

O TCP Wrappers oferece as seguintes vantagens em relação à outras técnicas de controle de serviços de rede:

O formato do /etc/hosts.allow e do /etc/hosts.deny é idêntico. Cada regra deve ser especificada na sua própria linha. Linhas em branco ou que comecem com uma cerquilha (#) são ignoradas.

Cada regra usa o seguinte formato básico para controlar o acesso aos serviços de rede:

<lista-de-daemons>: <lista-de-clientes> [: <opção>: <opção>: ...]

Veja a seguir uma regra básica de acesso a hosts:

vsftpd : .example.com

Esta regra faz com que o TCP Wrappers procure por conexões ao daemon do FTP (vsftpd) a partir de qualquer host no domínio example.com. Se esta regra aparece no hosts.allow, a conexão é aceita. Se esta regra aparece no hosts.deny, a conexão é rejeitada.

A próxima regra de acesso a hosts é mais complexa e usa dois campos de opção:

sshd : .example.com  \ : spawn /bin/echo `/bin/date` access denied>>/var/log/sshd.log \ : deny

Note que cada campo de opção é precedido pela barra invertida (\). O uso da barra invertida previne a falha da regra devido ao comprimento.

Este exemplo de regra estabelece que se uma conexão ao daemon do SSH (sshd) for tentada a partir de um host no domínio example.com, o comando echo é executado para adicionar a tentativa a um arquivo de registro especial e negar a conexão. Devido ao uso da diretiva opcional deny, esta linha nega o acesso até mesmo se aparecer no arquivo hosts.allow. Consulte a Seção 2.5.2.2, “Campos de Opção” para informações mais detalhadas sobre as opções disponíveis.

ALL: .example.com EXCEPT cracker.example.com

ALL EXCEPT vsftpd: 192.168.0.

Além das regras básicas que permitem e negam acesso, a implementação do TCP Wrappers no Red Hat Enterprise Linux suporta extensões à linguagem de controle de acesso através de campos de opção. O uso de campos de opção em regras de acesso de hosts permite que administradores de sistemas executem uma variedade de tarefas, como alterar o comportamento dos registros, consolidar o controle de acesso, e lançar comandos do shell.

sshd : .example.com : severity emerg

sshd : .example.com : severity local0.alert

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

sshd : .example.com  \
        : spawn /bin/echo `/bin/date` access denied to %h>>/var/log/sshd.log \
        : deny

vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"

O arquivo /etc/xinetd.conf contém opções de configuração gerais que afetam todos os serviços sob o controle do xinetd. É lido quando o serviço xinetd é iniciado pela primeira vez, portanto, para que configurações entrem em vigor, você precisa reiniciar o serviço xinetd. Veja a seguir um exemplo de arquivo /etc/xinetd.conf:

defaults
{
         instances               = 60        
         log_type                = SYSLOG        authpriv
         log_on_success          = HOST PID
         log_on_failure          = HOST
         cps                     = 25 30
}
includedir /etc/xinetd.d

Estas linhas controlam os seguintes aspectos do xinetd:

O diretório /etc/xinetd.d/ contém os arquivos de configuração para cada serviço gerenciado pelo xinetd, e os nomes dos arquivos relacionados ao serviço. Assim como o xinetd.conf, este diretório é lido apenas quando o serviço xinetd é iniciado. Para que quaisquer alterações sejam efetivadas, o administrador deve reiniciar o serviço xinetd.

O formato dos arquivos no diretório /etc/xinetd.d/ usa a mesma convenção do que o /etc/xinetd.conf. A razão principal pela qual a configuração de cada serviço é armazenada em uma arquivo separado é para facilitar a personalização e reduzir o risco de interferência na configuração de outros serviços.

Para entender como estes arquivos são estruturados, considere o arquivo /etc/xinetd.d/krb5-telnet:

service telnet
{
         flags           = REUSE
         socket_type     = stream
         wait            = no
         user            = root
         server          = /usr/kerberos/sbin/telnetd
         log_on_failure  += USERID
         disable         = yes
}

Estas linhas controlam vários aspectos do serviço telnet:

Consulte a página man do xinetd.conf para mais informações sobre o uso destas opções.

Uma série de diretivas está disponível para os serviços protegidos pelo xinetd. Esta seção destaca algumas das opções mais usadas.

service telnet
{
         disable         = no
         flags           = REUSE
         socket_type     = stream
         wait            = no
         user            = root
         server          = /usr/kerberos/sbin/telnetd
         log_on_failure  += USERID
         no_access       = 172.16.45.0/24
         log_on_success  += PID HOST EXIT
         access_times    = 09:45-16:15
}

Conexão fechada pelo host remoto.

Sep  7 14:58:33 localhost xinetd[5285]: FAIL: telnet address from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: START: telnet pid=5285 from=172.16.45.107
Sep  7 14:58:33 localhost xinetd[5283]: EXIT: telnet status=0 pid=5285 duration=0(sec)

service telnet
{
         socket_type                = stream
         wait                        = no
         server                        = /usr/kerberos/sbin/telnetd
         log_on_success                += DURATION USERID
         log_on_failure                += USERID
         bind                    = 123.123.123.123
         redirect                = 10.0.1.13 23
}

A documentação do seu sistema é um bom lugar para começar a procurar por opções de configuração adicionais para o TCP Wrappers, xinetd, xinetd, controle de acesso.

A maioria dos serviços de rede convencionais usa esquemas de autenticação de senhas. Estes esquemas requerem que o usuário se autentique em uma rede fornecendo seu nome de usuário e senha. Infelizmente, o envio de informações de autenticação para diversos serviços, é realizado sem criptografia. Para que um esquema destes seja seguro, a rede deve estar inacessível para pessoas de fora, assim como todos os computadores e usuários da rede devem ser confiáveis.

Mesmo se este for o caso, uma vez que a rede está conectada à Internet, não pode mais ser considerada segura. Qualquer atacante que obtiver acesso à rede pode usar um simples analisador de pacotes (também conhecido como 'packet sniffer') para interceptar nomes de usuários e senhas enviados desta maneira, assim comprometendo as contas de usuários e a integridade de toda a infraestrutura de segurança.

O objetivo principal do design do Kerberos é a eliminação da transmissão de senhas não criptografadas através da rede. Se for usado adequadamente, o Kerberos elimina efetivamente a ameaça que programas tipo packet sniffers representariam à rede caso o Kerberos não fosse usado.

Apesar do Kerberos eliminar uma ameaça severa e comum, pode ser de difícil implementação devido à uma gama de motivos:

Uma conexão host-a-host do IPsec é uma conexão criptografada entre dois sistemas ambos rodando o IPsec com a mesma chave de autenticação. Enquanto a conexão do IPsec estiver ativa, qualquer tráfego na rede entre os dois hosts é criptografado.

Para configurar um conexão host-a-host do IPsec, use os seguintes passos em cada host:

Após configurar a conexão IPsec, a mesma aparece na lista IPsec, conforme ilustrado na Figura 2.10, “Conexão IPsec”.

Conexão IPsec

Figura 2.10. Conexão IPsec

Os seguintes arquivos são criados quando a conexão IPsec for configurada:

Se a criptografia automática também for selecionada, /etc/racoon/racoon.conf também é criado.

Assim que a interface estiver ativa, o /etc/racoon/racoon.conf é modificado para incluir o <ip-remoto>.conf.

O primeiro passo para criar uma conexão é coletar as informações de sistemas e de rede de cada estação de trabalho. Para uma conexão host-a-host, você precisa das seguintes informações:

Por exemplo, suponha que as estações de trabalho A e B queiram se interconectar através de um túnel IPsec. Elas querem se conectar usando uma chave pré-compartilhada com o valor Key_Value01 e os usuários concordam em deixar que o racoon gere automaticamente e compartilhe uma chave de autenticação entre cada host. Usuários de ambos os hosts decidem chamar suas conexões de ipsec1.

Veja a seguir o arquivo de configuração do IPsec da Estação de Trabalho A para uma conexão host-a-host do IPsec com a Estação de Trabalho B. O nome único para identificar a conexão, neste exemplo, é ipsec1, e portanto o arquivo resultante é chamado /etc/sysconfig/network-scripts/ifcfg-ipsec1.

DST=X.X.X.X
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=PSK

A Estação de Trabalho A substituirá X.X.X.X pelo endereço IP da estação de trabalho B, enquanto esta deve substituir X.X.X.X pelo endereço IP da estação de trabalho A. Esta conexão não está configurada para iniciar na inicialização (ONBOOT=no) e usa o método de autenticação de chave pré-compartilhada (IKE_METHOD=PSK).

Veja a seguir o conteúdo do arquivo da chave pré-compartilhada (chamado /etc/sysconfig/network-scripts/keys-ipsec1) que ambas estações de trabalho precisam para autenticarem-se entre si. O conteúdo deste arquivo deve ser idêntico nas duas estações de trabalho, e somente o usuário root deve poder acessar ou gravar (read or write) este arquivo.

IKE_PSK=Key_Value01

[root@myServer ~] # chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsec1 nas duas estações de trabalho. As duas chaves devem ser idênticas para que a conexão funcione apropriadamente.

O próximo exemplo mostra a configuração específica para a conexão da fase 1 ao host remoto. O arquivo é nomeado como X.X.X.X.conf, onde X.X.X.X é substituído pelo endereço IP do host IPsec remoto. Note que este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não deve ser editado diretamente.

remote X.X.X.X
{
         exchange_mode aggressive, main;
         my_identifier address;
         proposal {
                 encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

O arquivo de configuração padrão da fase 1, criado quando uma conexão IPsec é iniciada, contém as seguintes declarações usadas pela implementação IPsec do Red Hat Enterprise Linux:

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf";

[root@myServer ~]# /sbin/ifup <apelido>

[root@myServer ~]# tcpdump -n -i eth0 host <sistemaAlvo>

IP 172.16.45.107 
> 172.16.44.192: AH(spi=0x0954ccb6,seq=0xbb): ESP(spi=0x0c9f2164,seq=0xbb)

Uma conexão IPsec rede-a-rede usa dois roteadores IPsec, um para cada rede, através dos quais o tráfego de rede para as sub-redes privadas é roteado.

Por exemplo, conforme ilustrado na Figura 2.12, “IPsec Rede-a-Rede”, se a rede privativa 192.168.1.0/24 manda tráfego de rede para a rede privativa 192.168.2.0/24, os pacotes passam pela gateway0 até o ipsec0, através da Internet, até o ipsec1, até a gateway1, e então chegam até a sub-rede 192.168.2.0/24.

Roteadores IPsec devem ter endereços IP endereçáveis publicamente, bem como outro dispositivo de Ethernet conectado às suas respectivas redes privativas. O tráfego passa por um roteador IPsec apenas se for destinado ao outro roteador IPsec com o qual uma conexão criptografada existe.

IPsec Rede-a-Rede

Figura 2.12. IPsec Rede-a-Rede

Opções de configuração de rede alternativas incluem um firewall entre cada roteador de IP e a Internet, e um firewall de intranet entre cada roteador IPsec e gateway de sub-rede. O roteador IPsec e a gateway para a sub-rede podem ser um mesmo sistema com dois dispositivos de Ethernet: um com um endereço IP público que age como o roteador IPsec; e um com um endereço IP privativo que age como a gateway para a sub-rede privativa. Cada roteador IPsec pode usar a gateway para sua própria rede privativa ou uma gateway pública para enviar os pacotes para o outro roteador IPsec.

Use o seguinte procedimento para configurar uma conexão IPsec rede-a-rede:

O script de rede para ativar a conexão IPsec cria as rotas de rede automaticamente para enviar pacotes através do roteador IPsec, se necessário.

Por exemplo, suponha que a LAN A (lana.example.com) e LAN B (lanb.example.com) queiram se interconectar através de um túnel IPsec. O endereço de rede da LAN A está no intervalo 192.168.1.0/24, enquanto a LAN B usa o intervalo 192.168.2.0/24. O endereço IP da gateway é 192.168.1.254 para a LAN A e 192.168.2.254 para a LAN B. Os roteadores IPsec estão separados de cada gateway da LAN e usam dois dispositivos de rede: à eth0 é atribuído um endereço IP estático acessível externamente, que acessa à Internet, enquanto a eth1 atua como um ponto de roteamento para processar e transmitir pacotes da LAN de um nó da rede a outros nós da rede remota.

A conexão IPsec entre as redes usa uma chave pré-compartilhada com o valor r3dh4tl1nux, e os administradores de A e B concordam em deixar que o racoon gere automaticamente e compartilhe uma chave de autenticação entre cada um dos roteadores IPsec. O administrador da LAN A decide nomear a conexão IPsec como ipsec0, enquanto o administrador da LAN B nomeia a conexão IPsec como ipsec1.

Veja o conteúdo do arquivo ifcfg para uma conexão IPsec rede-a-rede para a LAN A. O nome único para identificar a conexão neste exemplo é ipsec0, portanto o arquivo resultante é nomeado como /etc/sysconfig/network-scripts/ifcfg-ipsec0.

TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=192.168.1.254
DSTGW=192.168.2.254
SRCNET=192.168.1.0/24
DSTNET=192.168.2.0/24
DST=X.X.X.X

A seguinte lista descreve o conteúdo deste arquivo:

Veja a seguir o conteúdo do arquivo da chave pré-compartilhada, chamado /etc/sysconfig/network-scripts/keys-ipsecX (onde X é 0 para a LAN A e 1 para a LAN B), que as duas redes usam para autenticarem-se entre si. O conteúdo destes arquivos deve ser idêntico e somente o usuário root deve poder acessar ou gravar este arquivo.

IKE_PSK=r3dh4tl1nux

chmod 600 /etc/sysconfig/network-scripts/keys-ipsec1

Para alterar a chave de autenticação a qualquer momento, edite o arquivo keys-ipsecX nos dois roteadores IPsec. As duas chaves devem ser idênticas para que a conexão funcione apropriadamente.

Veja o conteúdo do arquivo de configuração /etc/racoon/racoon.conf da conexão IPsec. Note que a linha include na parte inferior do arquivo é automaticamente gerada e aparece somente se o túnel IPsec está rodando.

# Racoon IKE daemon configuration file.
# See 'man racoon.conf' for a description of the format and entries.
path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";
  
sainfo anonymous
{
        pfs_group 2;
        lifetime time 1 hour ;
        encryption_algorithm 3des, blowfish 448, rijndael ;
        authentication_algorithm hmac_sha1, hmac_md5 ;
        compression_algorithm deflate ;
}
include "/etc/racoon/X.X.X.X.conf"

Veja a seguir o arquivo de configuração específico da conexão à rede remota. O arquivo é nomeado como X.X.X.X.conf (onde X.X.X.X é o endereço IP do roteador IPsec remoto). Note que este arquivo é gerado automaticamente quando o túnel IPsec é ativado e não deve ser editado diretamente.

remote X.X.X.X
{
        exchange_mode aggressive, main;
        my_identifier address;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2 ;
        }
}

Antes de iniciar a conexão IPsec, o encaminhamento de IP deve ser habilitado no kernel. Para habilitar o encaminhamento de IP:

Para iniciar a conexão IPsec, execute o seguinte comando em cada roteador:

[root@myServer ~] # /sbin/ifup ipsec0

As conexões são ativadas e as duas LANs, A e B, agora podem se comunicar. As rotas são criadas automaticamente através do script de inicialização invocado pela execução do ifup na conexão IPsec. Para visualizar uma lista de rotas da rede, execute o seguinte comando:

[root@myServer ~] # /sbin/ip route list

Para testar a conexão IPsec, execute o utilitário tcpdump no dispositivo externamente roteável (eth0 neste exemplo) para visualizar os pacotes de rede sendo transferidos entre os hosts (ou redes) e para verificar se estão criptografados com IPsec. Por exemplo, para verificar a conectividade IPsec da LAN A, use o seguinte comando:

[root@myServer ~] # tcpdump -n -i eth0 host lana.exemplo.com

O pacote deve incluir um cabeçalho AH e deve ser exibido como um pacote ESP. ESP significa que está criptografado. Por exemplo (barras invertidas denotam a continuação de uma linha):

12:24:26.155529 lanb.exemplo.com > lana.exemplo.com: AH(spi=0x021c9834,seq=0x358): \
        lanb.exemplo.com > lana.exemplo.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \
        (ipip-proto-4)

A potência e flexibilidade de Netfilter é implementada usando a ferramenta de administração iptables, uma ferramenta de linha de comando similar na sintáxe aos seus predecendentes, ipchains.

Uma sintáxe semelhante, não significa uma implementação semelhante. No entanto, o ipchains requer um jogo regras intrínsecas para: filtrar caminhos de fontes, filtrar caminhos de destino, filtrar ambas as fontes e portas de conexão de destino.

No entanto, iptables usa o sub-sistema do Netfilter para melhorar a conexão, inspeção e processamento de rede. O iptables inclui registro avançado, ações pré e pós-roteamento, conversão de endereços de rede e encaminhamento de porta; tudo em apenas uma interface de linha de comando.

Esta seção oferece uma visão geral do iptables. Para informações mais detalhadas consulte o Seção 2.9, “IPTables”.

Durante a tela Configuração do Firewall na instalação do Red Hat Enterprise Linux, você teve a opção de habilitar um firewall básico assim como permitir alguns dispositivos básicos, serviços e portas.

After installation, you can change this preference by using the Ferramenta de Configuração do Nível de Segurança.

Para iniciar este aplicativo, use o seguinte comando:

[root@myServer ~] # system-config-securitylevel

Configuração de Nível de Segurança

Figura 2.15. Ferramenta de Configuração do Nível de Segurança