Todos os sites devem definir um amplo plano de segurança, que deve ser de mais alto nível que as políticas discutidas no capítulo 2, e deve ser projetado como um framework de objetivos amplos nos quais políticas específicas se enquadrarão.
É importante ter esse framework de tal maneira que políticas individuais possam ser consistentes dentro de todo o contexto da arquitetura de segurança do site. Por exemplo, ter uma política forte em relação ao acesso pela Internet e ter baixas restrições no uso do modem é inconsistente dentro de uma filosofia de fortes restrições no que diz respeito ao acesso externo.
Um plano de segurança deve definir: a lista de serviços de rede que serão providos; quais áreas da organização proverão os serviços; quem terá acesso aos serviços; como o acesso será provido; quem administrará esses serviços; etc.
O plano também deve indicar como incidentes serão tratados. Capítulo 5 provê uma discussão profunda neste tópico, mas é importante que cada site defina classes de incidentes e reações correspondentes. Por exemplo, sites com firewalls devem setar um número de tentativas de ataque suportado antes de tomar uma ação? Níveis de ação devem ser definidos para todos os ataques e respostas. Sites com firewalls devem determinar se uma simples tentativa de conexão a um host constitui um incidente ou não. E em relação à procura sistemática de sistemas?
Para sites conectados à Internet, o número significativo de incidentes relatados em relação à segurança pode se fazer esquecer dos incidentes internos à rede. Da mesma maneira, organizações não conectadas à Internet devem ter planos fortes e bem definidos de política de segurança interna.
Existem muitos serviços que um site deve prover para seus usuários, alguns dos quais podem ser externos. Há uma variedade de razões para isolar os serviços em hosts dedicados. Há também razões de performance em muitos casos, e uma discussão detalhada será feita neste documento.
Os serviços que um site deve prover terão, em muitos casos, níveis diferentes de acesso e modelos de confiança. É melhor colocar serviços que são essenciais à segurança ou operação do site em máquinas dedicadas com acesso limitado do que em uma máquina que provê serviço(s) menos seguro(s), ou que requer acesso por parte dos usuários, que podem acidentalmente burlar a segurança.
É também relevante distinguir entre hosts que operam em diferentes modelos e confiança (isto é, todos os hosts da rede interna versus hosts da rede externa).
Alguns dos serviços que são potencialmente separáveis são discutidos na sessão 3.2.3. É importante lembrar que segurança é tão forte quanto a corrente é em relação ao menor elo. Muitos dos ataques conhecidos nos anos recentes têm sido feitos por exploração de vulnerabilidades nos sistemas de correio eletrônico. Os intrusos não querem acesso ao correio eletrônico, mas usar as suas vulnerabilidades para ganhar acesso a outros sistemas.
Se possível, cada serviço deve estar sendo executado em máquinas diferentes que têm como o único objetivo prover aquele serviço. Assim, fica mais fácil isolar intrusos e limitar falhas potenciais.
Existem 2 filosofias diametricamente opostas que podem ser adotadas quando se define um plano de segurança. Ambas as alternativas são modelos legítimos a se adotar, e a escolha entre uma ou outra depende do site e suas necessidades de segurança.
A primeira opção é retirar todos os serviços e então habilitá-los seletivamente, considerando-os caso a caso. Isto pode ser feito no nível de host ou rede, o mais apropriado. Este modelo, referenciando como "bloquear tudo", é geralmente mais seguro do que o outro, descrito no próximo parágrafo. Porém, a configuração requer mais trabalho e compreensão dos serviços. Permitir somente serviços conhecidos para uma melhor análise de um particular serviço/protocolo e o projeto de um mecanismo de segurança cabem no nível de segurança do site.
O outro modelo, referenciado como "permitir tudo", é mais fácil de implementar, mas é geralmente menos seguro que o outro. Simplesmente ligar todos os serviços (a nível de host) e permitir a todos os protocolos que trafeguem na rede (a nível de roteador). Como os buracos de segurança ficam aparentes, eles são restritos aos níveis de host e rede.
Cada um dos modelos pode ser aplicado a diferentes porções do site, dependendo dos requerimentos das funcionalidades, do controle administrativo, da política de segurança, etc. Por exemplo, a política pode ser usar "permitir tudo" quando se trata de estações de uso geral, mas "bloquear tudo" quando se trata de servidores de informações, como servidores de email. Da mesma forma, "permitir tudo" pode ser empregado no tráfego entre subredes internas, mas "bloquear tudo" pode ser adotado na comunicação com a Internet.
Deve-se tomar cuidados quando se mistura as duas filosofias. Tomar cuidado somente com usuários externos pode não ser a melhor filosofia, pois usuários internos à rede podem não ser confiáveis. E a partir do momento que um usuário externo entra na rede (passando por um firewall) ele tem acesso a tudo, pois não há isolamento interno.
Há uma grande variedade de serviços que podem ser providos, tanto internamente quanto na Internet. Gerenciar segurança é, em muitos casos, gerenciar o acesso a serviços internos ao site e como o acesso interno a serviços externos se dará.
Os serviços tendem a se disseminar como ondas na Internet. Através dos anos muitos sites criaram servidores de: FTP anônimos, gopher, wais, WWW, etc, seguindo a moda quando eles se tornaram populares, mas sem levar em conta a necessidade real deles. Deve-se avaliar cada novo serviço em relação à sua necessidade real, esquecendo-se do modismo.
É bom ter-se em mente que a complexidade de segurança pode crescer exponencialmente com o número de serviços providos. Roteadores-filtros precisam ser modificados para suportar novos protocolos. Alguns protocolos são inerentemente difíceis de se filtrar seguramente (como RPC e UDP), assim abrindo-se novas portas ao mundo interno. Serviços providos pela mesma máquina podem interagir de modos catastróficos, por exemplo, FTP anônimo com WWW permite que um atacante coloque um arquivo na área de FTP e faça com que o servidor HTTP o execute.
Muitos administradores de rede protegem bem seus hosts, mas poucos são os que fazem a tarefa de proteger a rede. Existe razão para isso. Geralmente o objetivo são dados de servidores, pois os atacantes não tirarão proveito atacando os dados da rede, embora isso não desmereça a necessidade de sua proteção, pois um ataque comum nos dados da rede é a procura por senhas de logins alheios. Mas a proteção da infra-estrutura também diz respeito à gerência de rede (SNMP), serviços (DNS, NFS, NTP, WWW, ...) e segurança propriamente dita (autenticação e restrições de acesso).
A infra-estrutura também pede proteção dos erros humanos. Quando um administrador não configura bem um host, ele pode oferecer um mau serviço. Isto pode afetar somente os usuários daquele host, e ao menos que seja um servidor primário daquele serviço, o número de usuários afetados será limitado. Entretanto, se um roteador está mal configurado, todos os usuários que usarem a rede serão afetados.
Existem muitos ataques nos quais as redes se tornam vulneráveis. O ataque clássico é o "denial of service". Neste caso, a rede é levada a um estado no qual não consegue mais transmitir dados de usuários legítimos. Há duas maneiras de como isso pode ser feito: atacando os roteadores e enchendo a rede com tráfego estranho. Note-se que o termo roteador é usado para representar toda a classe de equipamentos de interconexão, nos quais se incluem firewalls. servidores-proxy, etc.
Um ataque num roteador é feito para impedi-lo de reencaminhar pacotes, ou transmiti-los de forma errada. Isso pode ser feito devido a uma má configuração, a injeção de atualização de informação de roteamento expúria, ou através de um "flood atack" , ou seja, o roteador é bombardeado com pacotes não roteáveis, fazendo sua performance decair. Um "flood atack" em uma rede é similar em relação a um roteador, exceto que os pacotes são broadcast. Um ataque ideal deste tipo seria a injeção de um único pacote que requeresse que todas as estações o retransmitissem, ou gerar pacotes de erro, cada um também repetido pelas outras estações. Um ataque deste tipo bem feito pode gerar uma explosão exponencial de transmissões.
Um outro ataque é o "spoofing". Neste caso, pacotes expúrios com informações erradas sobre roteamento são enviados a um ou mais roteadores fazendo com que eles roteem errado. Este ataque difere do primeiro somente no propósito do roteamento. No ataque anterior, o objetivo era deixar o roteador inutilizável, um estado facilmente detectado pelos usuários da rede. No "spoofing" os pacotes são enviados a algum host onde eles podem ser monitorados e depois reenviados a seu destino correto, tendo seu conteúdo alterado ou não.
A solução para a maioria desses casos é proteger os pacotes de atualização de roteamento dos protocolos como RIP-2 e OSPF. Existem 3 níveis de proteção: senha textual, checksum criptografado e criptografia. Senhas textuais oferecem proteção mínima contra intrusos que não têm acesso à rede física. Também protegem roteadores mal configurados (ou seja, roteadores ainda não configurados e que não deveriam rotear pacotes). A vantagem de senhas é que elas têm um baixo overhead, tanto em tempo de transmissão como de CPU. Checksums protegem contra a injeção de pacotes daninhos, até mesmo se o intruso tem acesso à rede física. Combinado com um número de seqüência, ou outro identificador único, o checksum pode também detectar ataques de retransmissão, onde uma informação mais antiga está sendo retransmitida, seja por um intruso ou roteador mal configurado. O melhor é prover criptografia completa, de atualizações de roteamento sequenciados ou univocamente identificados. Isso impede um intruso de determinar a topologia da rede. A desvantagem da criptografia é o overhead envolvido no processamento.
Tanto RIP-2 (RFC 1723) como OSPF (RFC 1583) suportam senhas textuais nas suas especificações básicas de projeto. E existem extensões para cada protocolo suportar o algoritmo de criptografia MD5.
Infelizmente não há proteção adequada a um ataque por "flooding" ou contra um host ou roteador que esteja inundando a rede , mas felizmente esse ataque é óbvio quando ocorre e geralmente pode ser terminado de forma relativamente fácil.
Existem muitos tipos de serviços e cada um tem seus próprios requisitos de segurança, que vão variar dependendo do uso do serviço. Por exemplo, um serviço que poderia ser usado dentro de um site (NFS) requer mecanismos de proteção diferentes de outros serviços usados externamente à rede. Pode ser suficiente proteger o servidor de acesso externo, mas um servidor WWW, que provê documentos que devem ser vistos por usuários da Internet, requer uma forte proteção, para impedir que se modifique o banco de dados da Web por pessoas externas à rede.
Serviços internos (usados pelos usuários do site) e serviços externos (deliberadamente permitidos para uso por usuários da internet) terão, de uma maneira geral, requerimentos de proteção diferentes dos já descritos. É bom isolar os serviços internos em um conjunto de servidores diferente do conjunto de servidores de serviços externos, ou seja, é bom não se deixar todos os serviços no mesmo(s) host(s). Na realidade, muitos sites vão além e têm um conjunto de subredes (ou até redes diferentes) que são acessíveis de fora do site e outro conjunto acessível somente de dentro do site. Naturalmente há firewalls inter conectando estes conjuntos. Um grande cuidado deve-se tomar a fim de garantir o funcionamento correto da firewall.
Há bastante interesse em se usar intranets para conectar com diferentes partes da organização (divisões da companhia). Enquanto este documento diferencia rede interna de rede externa (privada e pública), sites com intranets devem estar atentos que eles precisarão considerar 3 separações e tomar ações apropriadas quando projetando e oferecendo serviços. Um serviço provido a uma intranet não deve se tornar público, nem completamente privado como um serviço de uma sub-unidade da organização. Entretanto, o serviço pode precisar de um suporte próprio, separadamente tanto dos serviços e rede internos e externos.
Uma forma de serviço externo que merece uma atenção especial é o acesso anônimo, ou guest (não autenticado). É importante manter esses acessos isolados de hosts e sistemas de arquivos que não devem ser vistos por usuários externos. Outro cuidado especial diz respeito ao acesso anônimo com permissão de escrita. Um site deve ser legalmente responsável pela informação por ele tornada pública, portanto informações colocadas por anônimos devem ser monitoradas.
Agora iremos considerar alguns dos mais populares serviços: servidor de nomes, servidor de senhas, servidor de proxy/autenticação, correio eletrônico, WWW, transferência de arquivos e NFS. Considerando que são os serviços mais frequentemente usados, são os pricipais alvos de ataques. E um ataque em um destes serviços pode produzir um desastre além das intensões do serviço em si.