A Internet usa o Domain Name System (DNS) para realizar resolução de endereço para nomes de host e rede. O Sistema de Informação de Rede (NIS) e NIS+ não são usados na Internet, mas estão sujeitos aos mesmos riscos que o servidor DNS. Resolução nome-endereço é crítica para a operação segura de qualquer rede. Um atacante que pode controlar prosperamente ou personificar um servidor DNS pode alterar o tráfego para subverter proteções de segurança. Por exemplo, tráfego rotineiro pode ser desviado pra um sistema comprometido para ser monitorado; ou, usuários podem ser induzidos a fornecer segredos de autenticação. Uma organização deveria criar sites protegidos, bem conhecidos, para atuar como servidores de nomes secundário e proteger seu DNS mestre de ataques por bloqueio de serviço usando roteadores de filtragem.
Tradicionalmente, DNS não tem nenhuma capacidade de segurança. Em particular, a informação retornada de uma consulta não pode ser conferida para verificar sua modificação ou se ela originou-se do servidor de nome solicitado. Trabalho tem sido feito para incorporar assinaturas digitais no protocolo que, quando utilizado, permitirá que a integridade da informação seja verificada criptograficamente (veja RFC 2065).
3.2.3.2 Servidores de Senha/Chave (NIS(+) e KDC)
Servidores de senha e chave geralmente protegem suas informações vitais (i.e., as senhas e chaves) com algoritmos de encriptação. Porém, mesmo uma senha encriptada em uma única via pode ser determinada por um ataque do dicionário (em que são encriptadas palavras comuns para ver se elas correspondem à encriptação armazenada). É então necessário garantir que esses servidores não são acessíveis por hosts que não planejam usá-los para o serviço, e mesmo estes hosts deveriam somente estar aptos a acessar o serviço (i.e., serviços gerais, tais como Telnet e FTP, não deveriam ser permitidos por ninguém além dos administradores).
3.2.3.3 Servidores de Autenticação/Proxy (SOCKS, FWTK)
Um servidor de procuração fornece várias intensificações de segurança. Ele permite aos sites concentrar serviços através de um host específico para permitir monitoração, esconder a estrutura interna, etc. Esta concentração dos serviços cria um alvo atraente para um intruso potencial. O tipo de proteção necessário para um servidor de procuração depende muito do protocolo em uso pelo proxy e os serviços sendo fornecidos através dele. A regra geral de limitar o acesso somente a estes hosts que precisam dos serviços, e limitar acesso para estes hosts somente para aqueles serviços, é um bom ponto de partida.
3.2.3.4 Correio Eletrônico
Sistemas de correio eletrônico (email) foram, por um longo tempo, uma fonte para intrusos arrombadores porque os protocolos de email estão entre os mais antigos e os serviços mais amplamente utilizados. Também, por sua natureza, um servidor de email requer acesso ao mundo externo; a maioria dos servidores de email aceitam entrada de qualquer origem. Um servidor de email geralmente consiste de duas partes: um agente receptor/emissor e um agente de processamento. Desde que email é entregue a todos os usuários, e é normalmente privado, o agente de processamento tipicamente requer privilégios (root) do sistema pra entregar o mail. A maioria das implementações de email executam ambas porções do serviço, o que signigica ue o agente receptortambém tem privilégios do sistema. Ist abre vários furos de segurança que este documento não descreverá. Existem algmas implementações disponíveis que permitem uma separação dos dois agentes. Tais implementações são geralmente consideradas mais seguras, mas ainda exigem instalação cuidadosa para evitar a criação de um problema de segurança.
3.2.3.5 World Wide Web (WWW)
A Web está crescendo exponencialmente em popularidade devido a sua facilidade de uso e a poderosa habilidade de concentrar serviços de informação. A maioria dos servidores WWW aceitam algum tipo de direção e ação de pessoas acessando seus serviços. O exemplo mais comum é enviar um pedido de um usuário remoto e passar a informação fornecida para um programa executando no servidor para processar o pedido. Alguns desses programas não são escritos com segurança em mente e podem criar furos de segurança. Se um servidor Web está disponível para a comunidade Internet, é especialmente importante que informações confidenciais não sejam colocadas no mesmo host que o servidor. De fato, é recomendado que o servidor tenha um host dedicado que não é confiável pelos outros hosts internos.
Muitos sites podem querer colocar serviço FTP com seu serviço WWW. Mas isto deveria ocorrer somente para servidores de ftp-anônimo que apenas fornecem informações (ftp-get). Operação put no ftp-anônimo, em combinação com WWW, pode ser perigoso (por exemplo, elas poderiam resultar em modificações para as informações que seu site está publicando para a rede) e eles mesmos fazem as considerações de segurança para cada serviço diferente.
3.2.3.6 Transferência de Arquivo (FTP, TFTP)
FTP e TFTP permitem aos usuários receber e enviar arquivos eletrônicos em modo ponto-a-ponto. Porém, FTP requer autenticação, enquanto o TFP não necessita. Por esta razão, TFTP deveria ser evitado tanto quanto possível.
Servidores FTP configurados inadequadamente podem permiter podem permitir aos intrusos copiar, substituir e apagar arquivos à vontade, em qualquer lugar de um host, então é muito importante configurar este serviço corretamente. Acesso a senhas encriptadas e dados proprietários e a introdução de cavalos de Tróia são apenas alguns dos potenciais furos de segurança que podem ocorrer quando o serviço é configurado incorretamente. Servidores FTP deveriam localizar-se em seu próprio host. Alguns sites escolhem colocar FTP com servidor Web, uma vez que os dois protocolos compartilham considerações de segurança comuns. Porém, na prática não é recomendado, especialmente quando o serviço FTP permite o depósito de arquivos (veja seção em WWW acima). Como mencionado nos parágrafos de abertura da seção 3.2.3, serviços fornecidos internamente para seu site não deveriam ser colocados com serviços oferecidos externamente. Cada um deveria ter seu próprio host.
TFP não suporta o mesmo alcance de funções que o FTP e não tem qualquer segurança. Este serviço deveria somente ser considerado para uso interno, e então ele deveria ser configurado de maneira restrita que somente o servidor tem acesso a um conjunto pré-determinado de arquivos (ao invés de todos os os arquivos com permissão de leitura para todos). Provavelmente o uso mais comum do TFTP é pra downloading de arquivos de configuração para um roteador. TFTP deveria residir em seu próprio host, e não deveria ser instalado em hosts suportado FTP externo ou acesso Web.
3.2.3.7 NFS
O Serviço de Arquivo de Rede (NFS) permite aos hosts compartilhar discos comuns. NFS é freqüentemente usado por hosts sem disco que dependem de um servidor de disco para todas as suas necessidades de armazenamento. Infelizmente, NFS não tem nenhuma segurança embutida. É então necessário que o servidor NFS seja acessível somente pelos hosts que estão usando-o para serviço. Isto é obtido especificando para quais hosts o sistema de arquivos está sendo exportado e de que modo (por exemplo, somente leitura, somente escrita, etc.). Sistemas de arquivos não deveriam ser exportados para qualquer host externo à rede local, uma vez que isso irá necessitar que o serviço NFS seja acessível externamente. Idealmente, o acesso externo ao serviço NFS deveria ser bloqueado por um firewall.
3.2.4 Protegendo a Proteção
É surpreendente a freqüencia com que um site negligenciará as fraquezas mais óbvias na sua segurança deixando o próprio servidor de segurança aberto para ataques. Baseado nas considerações discutidas previamente deve estar claro que: o servidor de segurança não deveria ser acessível fora do site; deveria fornecer mínimo acesso, exceto para a função de autenticação, para usuários no site; e não deveria ser localizado com quaisquer outros servidores. Além disso, todo acesso ao nodo, incluindo acesso ao próprio serviço, deveria ser "anotado" para fornecer um "rastro" em caso de uma quebra de segurança.
3.3 Firewalls