4. Serviços e Procedimentos Seguros

Este capítulo guia o leitor através de uma série de tópicos os quais deveriam ser observados para tornar um site seguro. Cada seção aborda um serviço ou uma capacidade de segurança que pode ser necessária para proteger a informação e os sistemas de um site. Os tópicos são apresentados em razoável alto-nível para a introdução do leitor aos conceitos.

Ao longo do capítulo você encontrará referências significativas à criptografia. Está fora do escopo deste documento aprofundar-se em detalhes concernentes à criptografia, mas o leitor interessado pode obter mais informações através de livros e artigos listados na seção de referência deste documento.

4.1 Autenticação

Por muitos anos, o método prescrito para a autenticação de usuários tem passado pelo uso de senhas padrão reutilizáveis. Originalmente, estas senhas eram usadas por usuários em términais para autenticarem-se em um computador central. Na época não existiam redes (interiormente ou externamente), sendo mínimo o risco de revelação da senha de texto claro. Atualmente sistemas são conectados através de redes locais, e estas redes locais são conectadas mais adiante e à Internet. Usuários estão se logando de toda parte o globo; suas senhas reutilizáveis são frequentemente transmitidas através destas mesmas redes em texto claro, de modo que qualquer um (que esteja na escuta) possa capturar. E, sem dúvida, o Centro de Coordenação CERT* e outras equipes de reação estão vendo um grande número de incidentes envolvendo visualizadores de pacotes (sniffers) os quais estão capturando as senhas de texto claro.

Com o advento de tecnologias mais recentes, como senhas de uso único (por exemplo, S/Key), PGP, e dispositivos de autenticação baseados em tokens, as pessoas estão usando strings tipo senhas como tokens e números identificadores pessoais secretos. Se estes tokens e identificadores pessoais numéricos secretos não forem apropriadamente selecinados e protegidos, a autenticação será facilmente subvertida.

4.1.1 Senhas de uso único

Como mencionado acima, dado os atuais ambientes de rede, é recomendado que sites relacionados com a segurança e a integridade de seus sistemas e redes considerem mudanças em relação às senha padrão reutilizáveis. Tem ocorrido muitos incidentes envolvendo programas de rede que são tranformados em cavalos Tróia (por exemplo, telnet e rlogin) e programas visualizadores de pacotes de rede. Estes programas capturam trios de nomes de máquina, conta e senha em texto claro. Intrusos podem usar a informação capturada para acesso subseqüente às máquinas e contas. Isto é possível porque 1) a senha é usada várias vezes (conseqüentemente o termo "reutilizável") e 2) a senha passa através da rede em texto claro.

Foram desenvolvidas algumas técnicas de autenticação orientadas à este problema. Entre estas técnicas estão tecnologias de desafio-resposta que provêem senhas que são usadas uma só vez (comumente chamadas de senhas de única vez). Há vários produtos disponíveis, a decisão de usar um produto é responsabilidade de cada organização, e cada organização deveria realizar sua própria avaliação e seleção.

4.1.2 Kerberos

Kerberos é um sistema de segurança de rede distribuído que provê autenticação através de redes inseguras. Caso sejam requisitados pela aplicação, integridade e criptografia também podem ser providos. Kerberos foi desenvolvido originalmente no Instituto de Massachusetts de Tecnologia (MIT) nos anos oitenta. Há duas principais versões do Kerberos, versão 4 e 5 que são, para propósitos práticos, incompatíveis.

Kerberos usa um banco de dados de chaves simétricas, utilizando um centro de distribuição de chaves (KDC - Key Distribution Center) que é conhecido como o servidor Kerberos. São concedido "ingressos" eletrônicos para usuários ou serviços (conhecidos como "principais") depois de apropriada comunicação com o KDC. Estes ingressos são usados para autenticação entre principais. Todos os ingressos incluem um selo de tempo o qual limita o período de tempo para o qual o ingresso é válido. Portanto, os clientes e o servidor Kerberos devem possuir uma fonte de tempo segura e estarem aptos à manter o controle de tempo com precisão.

O lado prático de Kerberos é sua integração com o nível de aplicação. Aplicações típicas como FTP, telnet, POP e NFS têm sido integradas com o sistema Kerberos. Há uma variedade de implementações que possuem níveis variados de integração. Por favor veja o FAQ do Kerberos disponível via http://www.ov.com/misc/krb-faq.html para a mais recente informação.

4.1.3 Escolhendo e Protegendo Tokens e Indentificadores Pessoais Numéricos Secretos

Quando da seleção de tokens secretos, deve-se escolhê-los cuidadosamente. Como a seleção de senhas, eles devem ser robustos contra esforços de força bruta para adivinhá-los. Isto é, eles não devem ser palavras únicas em qualquer idioma, qualquer acrônimo comum, industrial ou cultural, etc. Idealmente, eles devem ser mais longos que curtos e consistir de frases que combinem letras minúsculas e maiúsculas, dígitos e outros caracteres.

Uma vez escolhida, a proteção destes tokens secretos é muito importante. Alguns são usados como identificadores numéricos para dispositivos de hardware (como cartões de token) e estes não devem ser escritos abaixo ou colocados em mesmo local do dispositivo com os quais são associados. Outros, como uma chave do PGP, devem ser protegidos de acesso não autorizado.

Uma última palavra neste assunto. Quando da utilização de produtos de criptografia, como PGP, tome cuidado em determinar o comprimento apropriado da chave e assegurar que seus usuários estejam treinados para fazer igualmente. Como avanços de tecnologia, o comprimento seguro mínimo de chave continua crescendo. Tenha certeza de que seu site mantenha o mais recente conhecimento na tecnologia de forma que você possa assegurar que qualquer criptografia em uso esteja provendo a proteção que você acredita que ele realmente esteja.

4.1.4 Garantia da Senha

Enquanto a necessidade de eliminar o uso de senhas padrão reutilizáveis não pode ser exagerada, é reconhecido que algumas organizações ainda podem estar usando-as. É recomendado que estas organizações mudem para o uso de uma melhor tecnologia. Enquanto isso, nós temos o seguinte conselho para ajudar com a seleção e manutenção de senhas tradicionais. Mas lembre-se, nenhuma destas medidas provê proteção contra revelação devido a programas de visualização de pacotes.

(1) A importância de senhas robustas - Em muitos (se não a maioria) casos de penetração de sistema, o intruso precisa ganhar acesso à uma conta no sistema. Uma maneira em que esta meta é tipicamente alcançada é adivinhando a senha de um usuário legítimo. Isto é freqüentemente realizado através da execução de programa automático de quebra de senhas, o qual utiliza um dicionário muito grande contra o arquivo de senhas do sistema. O único modo de resguardar-se contra a descoberta de senhas desta maneira é pela seleção cuidadosa de senhas que não podem ser facilmente adivinhado (i.e., combinações de números, letras e caráter de pontuação). Senhas também devem ser tão compridas quanto suportado pelo sistema e toleradas pelo usuário.

(2) Troca de senhas padrão - Muitos sistemas operacionais e programas de aplicação são instalados com contas e senhas padrão. Estas devem ser mudadas imediatamente para algo que não possa ser adivinhado ou quebrado.

(3) Restringindo acesso ao arquivo de senhas - em particular, um site deseja proteger a porção de senha codificada do arquivo para que os pretendentes a intrusos não os tenham disponíveis para a quebra. Uma técnica efetiva é usar senhas de sombra onde o campo de senha do arquivo padrão contém uma senha boba ou falsa. O arquivo contendo as senhas legítimas é protegido em outro lugar do sistema.

(4) Envelhecimento de senhas - Quando e como expirar senhas ainda é um assunto de controvérsia entre a comunidade de segurança. Geralmente é aceito que uma senha não deve ser mantida uma vez que uma conta não se encontra mais em uso, mas é ardentemente debatido se um usuário deve ser forçado a mudar uma boa senha que está em uso ativo. Os argumentos para a troca de senhas relaciona-se à prevenção do uso continuo de contas penetradas. Entretanto, a oposição reivindica que mudanças de senha freqüentes conduza usuários a escreverem suas senhas em áreas visíveis (como colá-las em um terminal) ou selecionarem senhas muito simples as quais sejam fáceis de adivinhar. Também deve ser declarado que um intruso provavelmente usará uma senha capturada ou adivinhada mais cedo do que tarde. Neste caso o envelhecimento da senha provê pequena ou nenhuma proteção, pois ela estará ainda válida no período em que o intruso estiver usando-a, isto é, logo depois que a obtiver.

Enquanto não há resposta definitiva a este dilema, uma política de senhas deve abordar a questão e prover diretrizes sobre com que freqüência um usuário deve mudar a senha. Certamente, uma mudança anual em sua senha não é difícil para a maioria dos usuários e você deve considerar esta requisição. É recomendado que senhas sejam mudadas pelo menos sempre que uma conta privilegiada seja compromissada, exista uma mudança pessoal crítica (especialmente se for um administrador!) ou quando uma conta seja comprometida. Ainda, se a senha de uma conta privilegiada é comprometida, todas as senhas no sistema devem ser alteradas.

(5) Bloqueio de contas e senhas - Alguns sites acham útil desabilitar contas depois de um número pré-definido de não sucedidas tentativas de autenticação. Se seu site decidir empregar este mecanismo, é recomendado que o mecanismo não avise a si mesmo. Depois de

desabilitar, até mesmo se a senha correta for apresentada, a mensagem exibida deve permanecer como a de uma tentativa não sucedida de login. A implementação deste mecanismo requererá que usuários legítimos contatem seus administradores de sistema para pedir que sua conta seja reativada.

(6) Uma palavra sobre o finger daemon - O finger daemon exibe, como padrão, informação considerável do sistema e do usuário. Por exemplo, ele pode exibir uma lista de todos os usuários que atualmente usam um sistema ou todo o conteúdos do arquivo .plan de um usuário específico. Esta informação pode ser usada por possíveis intrusos para identificar usernames e adivinhar suas senhas. É recomendado que sites considerem modificar o finger para restringir a informação exibida.

4.2 Confidencialidade

Haverá recursos de informação que seu site desejará proteger da revelação à entidades não autorizadas. Sistemas operacionais possuem freqüentemente mecanismos de proteção de arquivo embutidos que permitem um administrador controlar quem pode acessar ou "ver" o conteúdo de um determinado arquivo. Um modo mais forte de prover confiança é através de criptografia. Criptografia é realizada misturando dados de forma que venha a ser muito difícil e consuma tempo demasiado para que qualquer um que não um receptor ou proprietário autorizado possa obter o texto claro. Os receptores e autorizados e proprietários da informação possuirão as chaves de decriptação correspondentes as quais lhes permitem decodificar facilmente o texto para uma forma legível (texto claro). Nós recomendamos que sites usem criptografia para prover confidencialidade e proteger informação valiosa.

O uso de criptografia é controlado às vezes por regulamentos governamentais e de sites, portanto nós encorajamos que os administradores se informem sobre de leis ou políticas que regulem seu uso antes de emprega-la. Está fora do escopo deste documento discutir os vários algoritmos e programas disponíveis para este propósito, mas nós advertimos contra o uso do programa crypt do UNIX por ter sido facilmente quebrado. Nós também encorajamos todos a dispenderem tempo para analisar a força da criptografia em qualquer algoritmo/produto dado antes de usá-lo. A maioria dos produtos famosos é bem-documentada na literatura, devendo ser esta uma tarefa bastante fácil.

4.3 Integridade

Como um administrador, você desejará ter certeza que informações (por exemplo, arquivos de sistema operacional, dados de companhia, etc.) não tenham sido alteradas de uma maneira não autorizada. Isto significa que você desejará prover alguma garantia sobre a integridade da informação em seus sistemas. Um modo de prover isto é realizar um checksum do arquivo inalterado, armazenar o checksum de maneira offline e periodicamente (ou quando desejado) conferir para ter certeza que o checksum do arquivo online não tenha sido alterado (que indicaria a alteração dos dados).

Alguns sistemas operacionais vêm com programas de checksum, como o programa sum do UNIX. Entretanto, estes podem não prover a proteção que você precisa de fato. Arquivos podem ser modificados arquivos de tal forma que o resultado do programa sum do UNIX seja conservado! Assim, nós sugerimos a utilização de um forte programa de criptografia, como o programa de condensão de mensagem MD5 [ref], para produzir os checksums que você usará para garantir a integridade.

Há outras aplicações onde a integridade precisará ser assegurada, como quando da transmissão de um email entre duas entidades. Existem produtos disponíveis os quais podem prover esta capacidade. Uma vez que você identificar esta capacidade como sendo necessária, você pode identificar tecnologias que proverão isto.

4.4 Autorização

Autorização se refere ao processo de conceder privilégios para processos e, em última análise, para usuários. Isto difere daquela autenticação que é o processo de identificação de um usuário. Uma vez identificados (seguramente), os privilégios, direitos, propriedade e ações permissíveis do usuário são determinados através da autorização.

Listar explicitamente as atividades autorizadas de cada usuário (e processo de usuário) com respeito a todos os recursos (objetos) é impossível em um sistema razoável. Em um sistema real certas técnicas são usadas para simplificar o processo de conceder e verificar autorizações.

Uma abordagem, popularizada em sistemas de UNIX, é associar a cada objeto três classes de usuário: proprietário, grupo e mundo. O proprietário é o criador do objeto ou o usuário associado como proprietário pelo super usuário. As permissões de proprietário (leitura, escrita e execução) aplicam-se somente para o proprietário. Um grupo é uma coleção de usuários que compartilham direitos de acesso sobre um objeto. As permissões de grupo (leitura, escrita e execução) aplicam-se a todos os usuários no grupo (exceto o propritário). O mundo refere-se a todos outros com acesso ao sistema. As permissões de mundo (leitura, escrita e execução) aplicam-se a todos os usuários (menos o proprietário e membros do grupo).

Outra abordagem é associar a um objeto uma lista que explicitamente contém a identidade de todos usuários permitidos (ou grupos). Esta é uma Lista de Controle de Acesso (ACL). A vantagem de ACLs é que elas são

facilmente mantidas (uma lista central por objeto) e é muito fácil verificar visualmente quem tem acesso ao que. As desvantagens são os recursos extras exigidos armazenar tais listas, como também o vasto número de listas requeridas para sistemas grandes.