IP Security

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Tutorial - Gerência de Redes Segurança em TCP/IP 
por Suzana Strauch - dez/96 
 
1. Segurança na Internet - Unix 
 
 Sintomas Suspeitos 
 Sempre Melhorar os Mecanismos de Proteção 
 O que vale a pena proteger 
 
2. Situação Atual 
 Autenticação Fraca 
 IP Spoofing 
 Vulnerabilidade dos Serviços 
Telnet 
Rlogin 
Finger 
FTP 
Mail 
 Protocolos sem proteção contra monitoração 
 Vírus, Vermes, Cavalos de Tróia 
 
3. Mecanismo de Defesa 
 Auditoria e Autenticação 
 Registro 
 Criptografia 
 
4. Formas de Proteção 
 Firewalls e Proxies 
 Wrappers 
 Protocolos SSL, PGP 
 
5. Ferramentas para Verificação de Segurança no Unix 
 COPS 
 TRIPWIRE 
 SATAN 
 TIGER 
 ISS 
6. Bibliografia 
7. Links Interessantes 
1. Segurança na Internet – Unix 
Quando falamos em segurança na Internet, nos referimos principalmente ao sistema operacional 
Unix, por diversos motivos, entre eles foi o Unix o 
ambiente em que a Internet se originou e ainda hoje é 
o sistema operacional mais utilizado na rede. O Unix 
por ter sido desenvolvido em universidade com o 
objetivos acadêmicos e para ligar máquinas dentro 
de um mesmo campus, não se preocupou com todos 
os pontos de segurança. 
 
Sintomas Suspeitos 
Entre os sintomas mais frequentes de intrusos no sistema estão: 
 Novas contas de usuários 
 A volta da utilização de contas com pouco uso ou há muito tempo sem uso 
 Mudanças de tamanho e data em alguns arquivos (principalmente nos arquivos de log) 
 Número muito grande de logins sem sucesso 
 Baixa de desempenho inexplicada do sistema, etc. 
Melhorias nos Mecanismos de Proteção 
Os mecanismos de proteção que são apresentados neste trabalho, solucionam alguns dos problemas 
de segurança atuais, mas não podem prever os ataques que ainda poderão surgir. Por este motivo o 
administrador da rede tem que estar constantemente avaliando os seus mecanismos de segurança, 
verificando a sua eficiência e atualizando-se sempre com os novos ataques que surgem. 
A segurança de um sistema esta intimamente ligada a seu administrador, pois muitos dos furos que 
serão abordados se devem a má configuração do sistema ou não atualização de um software que 
tinha um bug e deveria ter sido substituído. 
O que vale a pena proteger 
Antes da configuração das regras que determinarão a segurança do sistema ligado a Internet é 
necessária que seja feito um planejamento, avaliando os seguintes pontos: 
 Determinar o que deve ser protegido 
 Determinar que nível de segurança é necessário 
 Avaliar a questão custo x benefícios 
Por exemplo, uma agência de publicidade que esteja ligada a Internet, tem que proteger muito o 
seus trabalhos, pois uma propaganda que irá veicular na mídia na semana seguinte, não pode de 
maneira alguma chegar nas mãos da concorrência. 
Já em uma universidade, não é necessária tanta segurança, pois seus trabalhos geralmente são 
colocados à disposição de outras universidades. 
Autenticação Fraca 
O Unix guarda as informações de todos os usuários do sistema no arquivo /etc/passwd. Este arquivo 
contém o username, o nome real, informação para a identificação e informações básicas sobre a 
conta de cada usuário no sistema. O arquivo é organizado da seguinte forma: cada linha do arquivo 
contém o registro de um usuário, e os registros são divididos em campos separados pelo caracter (:). 
Por exemplo: 
root:fi3sED95ibqR6:0:1:System Operator:/:/bin/csh 
daemon:*:1:1::/tmp: 
uucp:OORoMN9FyZfNE:4:4::/usr/spool/uucppublic:/usr/lib/uucp/uucico 
jsilva:eH5/.mj7NB3dx:181:100:José Silva:/u/jsilva:/bin/csh 
As três primeiras contas, root, daemon e uucp, são contas do sistema e a última é conta de usuário. 
Os campos de cada linha tem o seguinte significado: 
jsilva Username 
eH5/.mj7NB3dx senha do usuário cifrada 
181 número identificador do usuário (UID) 
100 número identificador do grupo ao qual usuário pertence (GID) 
José Silva nome real do usuário 
/u/jsilva/ diretório home do usuário 
/bin/csh shell do usuário 
O objetivo da senha é de autenticar o usuário. Em muitas versões do Unix caso um usuário tente 
acessar um sistema e entre com a senha errada diversas vezes consecutivamente, a conta deste 
usuário é bloqueada. Isto evita com que uma pessoa fique tentando acertar a senha de outro, e, caso 
isto aconteça, deve-se avisar ao administrador que alguém está tentando quebrar uma conta. 
A senha é cifrada com uma função one-way a qual cifra a senha com blocos de zero. O resultado da 
função crypt( ) é armazenado no arquivo /etc/passwd. Quando tentamos entrar no sistema o 
programa /bin/login cifra a senha digitada pelo usuário com a mesma função, e compara o resultado 
com o que temos armazenados no arquivo /etc/passwd, se forem iguais permite a entrada do usuário 
no sistema. 
O algoritmo do crypt( ) usado é baseado no DES (Data Encryption Standard). 
O ataque mais usado na rede é chamado de Ataque do Dicionário que foi criado por Robert Morris 
(coincidência ou não, filho de Robert Morris da NSA que foi um dos pesquisadores que 
desenvolveu crypt( ) ). O ataque consiste na cifragem das palavras de um dicionário através da 
função crypt( ), e comparações com os arquivos de senhas de usuários. Desta forma, quando uma 
palavra do dicionário cifrada coincidisse com a senha cifrada de um usuário, o atacante teria obtido 
uma senha. 
Para dificultar este ataque foi criado o chamado salt, que é um número randômico gerado na hora 
em que o usuário esta inserindo ou alterando a sua senha. O número gerado pode estar entre 0 e 
4095 e é cifrado juntamente com a senha, o que impede a utilização de um dicionário genérico para 
todos os usuários. O atacante agora, tem que cifrar cada palavra do dicionário com o salt de cada 
usuário. 
Embora cada usuário tenha seu username, o Unix internamente representa cada usuário por um 
número, o UID (User Identifier). Os UIDs são números de 16 bits e geralmente os UIDs entre 0 e 9 
são usados para funções do sistema. Os UIDs para os usuários começam geralmente em 20 ou 100. 
O Unix guarda a relação entre username e UID no arquivo /etc/passwd, após a senha cifrada temos 
o UID do usuário. 
O UID [GAR94] é o identificador real do usuário para o sistema operacional, o username é 
utilizado apenas por ser mais conveniente para os usuários. Se dois usuários possuírem o mesmo 
UID, o Unix os veria como um mesmo usuário, mesmo eles tendo username e senhas diferentes. 
Todo o usuário do Unix pertence a um ou mais grupos, e estes grupos, como os identificadores de 
usuário, também possuem identificador de grupo, o GID (Group Identifier). O administrador do 
sistema cria os grupos e especifica quais arquivos, diretórios ou dispositivos os usuários deste grupo 
vão ter acesso. No /etc/passwdé armazenado o GID do grupo primário do usuário. Os dados do 
grupo são armazenados no arquivo /etc/group. 
IP Spoofing 
O IP spoofing consiste na troca do IP original por outro, podendo assim se passar por outro host. 
Através de IP Spoofing um intruso pode se aproveitar de hosts confiáveis armazenados no 
arquivo .rhosts, e entrar em máquinas via rlogin, por exemplo, onde não é exigido senha. 
O famoso ataque de Kevin Mitnick à rede particular de Tsutomo Shimomura, um especialista em 
segurança de sistemas, em dezembro de 1994, foi baseado no ataque descrito acima. Mitnick, além 
da rede de Shimomura, através de um modem e celular, invadiu diversos outros sistemas, como 
universidades, empresas e órgãos públicos. 
Existe também o chamado Host Name Spoofing, mais fácil de programar que o IP Spoofing, que é 
quando um DNS retorna um nome falso para um dado IP. Pode ser utilizado para atacar alguns 
sistemas que possuem serviços baseados em autenticação pelo nome do host. 
Vulnerabilidade dos Serviços da Internet 
Esta parte analisa a vulnerabilidade
dos serviços da Internet, avaliando seus pontos fracos e 
soluções encontradas. 
 
TELNET 
Os programas telnet e telnetd provêm serviço de terminal virtual 
remoto, ou seja através deste serviço o usuário entra em uma máquina 
remota, através da rede, e trabalha nela como se estivesse sentado num 
terminal, diretamente conectado a ela. 
O grande problema deste serviço é que para a identificação do usuário 
na máquina remota, trafegam pela rede o username e a senha em claro, 
sem qualquer método de criptografia. 
 
RLOGIN 
O rlogin e o rlogind provêm um serviço de terminal remoto, muito semelhante ao telnet. Existem 
duas diferenças básicas entre o telnet e o rlogin: 
 no rlogin o username é automaticamente transmitido no início da conexão, não sendo 
necessário ao usuário digitar o seu username. 
 o rlogin não exige senha caso a conexão venha de um host confiável ou de um username 
confiável 
Host Confiáveis (Trusted Hosts) 
Se um host confia em um outro, então os usuários que tenham o mesmo username em ambos os 
hosts podem se logar de um host em outro sem ter que digitar a senha. 
Usuários Confiáveis (Trusted Users) 
Usuários confiáveis são como os hosts confiáveis só que se referem a usuários. Se for designado a 
um usuário em outro computador como um usuário confiável para a sua conta, então ele pode logar-
se na sua conta sem ter que digitar a senha. 
Hosts e usuários confiáveis tem vantagens, principalmente em ambientes fechados, pois fica muito 
mais rápido passar de uma máquina para a outra. Praticamente, os hosts confiáveis fazem com que 
uma vez o usuário identificado frente a uma máquina, está identificado frente a toda a rede, 
passando de uma máquina a outra sem ter que digitar a senha novamente. O rlogin varre o 
arquivo /etc/hosts.equiv e depois o arquivo ~/.rhosts. 
/etc/hosts.equiv 
Este arquivo contém a lista de hosts confiáveis para o seu computador. Cada linha do arquivo 
contém um host confiável. 
Exemplo: ouro.inf.ufrgs.br prata.inf.ufrgs.br platina.inf.ufrgs.br ~/.rhosts 
Este arquivo no diretório home do usuário contém a lista de hosts em que o usuário confia. Por 
exemplo, o arquivo ~raquel/.rhosts na máquina sirius.inf.ufrgs.br contém as seguintes linhas: 
canopus.inf.ufrgs.br auriga.inf.ufrgs.br 
Com este arquivo .rhosts a usuária rachel na máquina canopus ou auriga pode se logar na máquina 
sirius na conta rachel sem ter que digitar novamente a sua senha. 
O arquivo .rhost também pode ter o par [máquina, username], estendendo a confiança para outros 
usernames. 
canopus.inf.ufrgs.br cohen Neste caso, o usuário conhecido da máquina canopus pode se logar na 
conta da rachel sem a sua senha. 
Hosts e usuários confiáveis tem sido responsáveis por diversos problemas de segurança, uma vez 
que uma máquina for invadida por um intruso, todas as que confiam naquela também estão 
comprometidas. 
Além disso, os arquivos .rhosts estão sendo utilizados pelos intrusos, que adicionam o seu username 
no arquivo para facilitar a sua entrada no sistema no futuro. 
 
FINGER 
O finger quando executado sem parâmetros retorna as informações armazenadas no 
arquivo /etc/passwd de todos os usuários logados no sistema no momento, como por exemplo o 
nome completo, o username, o horário de login, etc. 
Quando executado com argumentos, o programa procura no /etc/passwd e retorna informação 
detalhada de cada usuário que tiver o primeiro, último nome ou username especificado pelo usuário. 
Através do finger podemos saber quem esta logado em uma determinada máquina, como por 
exemplo: finger @chui.inf.ufrgs.br. 
O finger roda na máquina local, e o fingerd é o responsável por implementar que o serviço fique 
disponível para toda a rede. 
O finger facilita aos intrusos obter uma lista de usuários do sistema, aumentando com isto a chance 
de quebra do sistema. Por esta razão muitos sistemas desabilitaram a utilização do finger. 
O finger foi uma das maneiras que o verme da Internet de Robert Morris utilizou para invadir os 
sistemas. O programa original do fingerd continha as seguintes linhas de código [GAR91]: 
char line[512]; 
line[0] = ‘\0’; gets(line); 
Como a função gets( ) não verifica o tamanho da linha era permitido a um programa mal 
intencionado ultrapassar os 512 bytes e causar um overflow, interrompendo a execução do fingerd e 
com isso abrindo um shell e dando o programa acesso irrestrito ao servidor. 
O verme da Internet atacou diversas máquinas em 2 de novembro de 1988. 
O problema foi facilmente resolvido trocando-se a função gets( ) por fgets( ), pois esta última não 
permite que o buffer de entrada cause um overflow. 
fgets (line, sizeof(line), stdin); 
 
FTP (File Transfer Protocol) 
O serviço FTP permite que usuários transfiram arquivos facilmente de um sistema para outro, 
através da rede. 
O FTP apresenta o mesmo problema de segurança do telnet, trafegar username e senha pela rede 
sem nenhuma proteção. 
O FTP pode ser configurado para trabalhar também com acesso anônimo, ou seja, qualquer pessoa, 
mesmo que não tenha conta naquela máquina pode depositar e copiar arquivos dela. O FTP 
anônimo é muito utilizado para a distribuição de documentos e softwares através da rede. Deve ser 
tomado muito cuidado na configuração de um servidor de FTP anônimo para que o acesso seja 
restrito aos arquivos determinados incluindo restrições de acesso. Outra atenção é que o servidor de 
FTP não fique sendo depósito de documentos indesejados como arquivos de intrusos, etc, por este 
motivo é aconselhável criar um diretório separado para a colocação de arquivos com espaço 
limitado. 
Através do arquivo /etc/ftpusers eu posso impedir que os usuários especificados utilizem o serviço 
FTP. 
 
MAIL 
Através do protocolo SMTP (Simple Mail Transfer Protocol) qualquer usuário envia uma 
mensagem de uma máquina para outra através da rede. O mail é o serviço mais difundida da 
Internet. 
O sendmail, uma das implementações mais difundidas do SMTP, atua tanto como servidor como 
cliente. 
O sendmail já é conhecido como fonte de problemas de segurança. Uma das vulnerabilidades do 
sendmail [GAL96] envolve em fazer o servidor executar o corpo de uma mensagem como uma 
shell script. O script pode fazer qualquer coisa que um usuário comum do sistema possa fazer, 
incluindo enviar o arquivo de senhas do sistema para o atacante. O sendmail praticamente não 
possui validação dos dados e permite também que seja enviado um mail par um arquivo. 
O sendmail possui algumas contas que devem ser desabilitadas pelo administrador do sistema 
como, por exemplo, as contas “wizard”, “kill”, “debug”. A configuração do sendmail fica no 
arquivo /usr/lib/sendmail.cf. 
O verme da Internet de 1988 utilizou-se do modo de depuração do sendmail para obter acesso 
irrestrito ao sistema invadido. O sendmail possui este modo de depuração, o que faz com que depois 
de instalado o sendmail deve ser recompilado com o modo de depuração desligado. 
Como visto, o sendmail é o serviço mais fraco no nível de segurança e um dos mais utilizados. 
Protocolos sem proteção contra monitoração 
Em muitas redes, como por exemplo, as redes Ethernet, os pacotes são transmitidos para todos os 
computadores conectados ao mesmo meio físico. Geralmente os computadores são programados 
para ouvir somente os pacotes endereçados a eles. Mas, é possível reprogramar o computador 
forçando ele a ouvir todos os pacotes transmitidos e gravá-los. 
Em serviços como ftp e telnet em que o username e a senha trafegam em claro (ou seja nenhum 
método de critografia é utilizado) fica muito fácil obter estes dados. 
Existem também programas especiais, os sniffers, para capturar os primeiros 100 caracteres 
enviados em ambas as direções durante uma conexão, o que é suficiente para capturar o username e 
senha. 
Vírus, Vermes e Cavalos de Tróia
Vírus 
São programas que se inserem dentro de outros programas, fazendo com que quando estes 
programas sejam executados, o vírus também seja executado. Os vírus quando executados tentam 
fazer novas cópias de seu código. A maioria dos vírus que conhecemos foram desenvolvidos para 
máquinas com sistemas operacionais fracos em termos de segurança como o MS-DOS. 
 
Vermes 
Os vermes são programas que podem rodar independentemente e trafegam de máquina a máquina 
através das conexões da rede. Os vermes podem ter partes rodando em diferentes máquinas. Os 
vermes não modificam os outros programas embora possam carregar com eles o código de um 
vírus, por exemplo. 
Para o desenvolvimento de um verme são requeridos um ambiente de rede e um autor que tenha 
familiariedade com os serviços da rede e com o sistema operacional, isto foi o que aconteceu com o 
verme da Internet de 1988, desenvolvido por Robert Morris. A proteção contra um verme é a 
mesma para o acesso não autorizado, se temos um ambiente já protegido consequentemente o 
verme também não irá conseguir entrar. 
 
Cavalos de Tróia 
Os cavalos de Tróia parecem com programas que o usuário quer rodar - um jogo, editor, etc. 
Enquanto os programas parecem estar executando normalmente, ele esta fazendo outra, como 
deletando seus arquivos, formatando o disco, etc. 
3. Mecanismo de Defesa 
 Auditoria e Autenticação 
 Registro 
 Criptografia 
Auditoria e Autenticação 
Auditoria 
Auditoria de segurança visa inspecionar e testar a adequação dos sistemas de controle. Verifica se 
as regras de segurança determinadas para o sistema estão sendo cumpridas e aconselha mudanças 
no controle. 
 
Autenticação 
Quando dois usuários de uma rede (Alice e Bob) precisam se comunicar de forma segura, ambos 
precisam ter certeza de que estão se comunicando com a pessoa certa. Para isto os usuários 
precisam estar autenticados, provando serem eles mesmos e não uma terceira pessoa (Eve) tentando 
se passar por Alice ou por Bob. 
Para esta autenticação existem os KDCs (Key Distribuction Center) centrais de distribuição de 
chaves, os quais possuem chaves compartilhadas com Alice e com Bob para assim poder autenticá-
los. 
Assim quando Alice requisita uma comunicação segura com Bob, o Trent (como é chamado o 
KDC) autentica os usuários e gera uma chave para a comunicação entre eles. Por este motivo, é 
imprescindível que o Trent seja um servidor confiável. 
Esta notação de nomes: Alice, Bob, Eve, Trent, etc é usual para explicar protocolos criptográficos. 
Kerberos 
O Kerberos é uma implementação de um KDC, desenvolvida no MIT (Massachusetts Institute of 
Technology) utilizando o conceito de algoritmo de chave pública. 
O Kerberos é um protocolo de autenticação projetado para Unix e redes TCP/IP. Um serviço 
Kerberos situado na rede atua com um árbitro. Kerberos provê autenticação segura na rede 
permitindo com que uma pessoa acesse diferentes máquinas na rede. O Kerberos é baseado em 
criptografia de chave única (foi implementado com o DES, mas outros algoritmos também podem 
ser usados). 
No modelo Kerberos temos duas entidades na rede: o cliente e o servidor. Os clientes podem ser 
usuários ou software independente que precisam fazer download em arquivos, enviar mensagens, 
acessar bancos de dados, etc. 
O Kerberos mantém uma base de dados com as chaves de seus clientes. No caso dos clientes serem 
usuários a chave secreta pode ser uma senha cifrada. Serviços de rede que requerem autenticação, 
bem como os clientes que usem estes serviços registram suas chaves secretas com o Kerberos. 
Sabendo a chave secreta de todos, o Kerberos pode criar mensagens que convençam uma entidade 
da identidade de outra. 
Como o Kerberos trabalha: 
Um cliente requisita um ticket para um Ticket-Granting Service (ticket TGS) para o serviço 
Kerberos. Este ticket é enviado para o cliente cifrado com a chave secreta deste cliente. Para usar 
um serviço particular, o cliente requisita um ticket para aquele serviço para o Ticket-Granting 
Server (TGS). Assumindo que tudo está em ordem, o TGS envia o ticket de volta ao cliente. O 
cliente apresenta o ticket para o servidor como um autenticador. Novamente, se não há nada errado 
com as credenciais do cliente, o servidor deixa o cliente ter acesso ao serviço. 
Dados Biométricos 
Os dados biométricos estão sendo trabalhados como uma maneira confiável de autenticação, 
reconhecer a identidade de uma pessoa através de características fisiológicas como impressão 
digital ou padrão da Íris, ou em base em alguma coisa do seu comportamento como o padrão dos 
toques de digitação ou escrita manual. 
Registro 
Consiste em registrar os dados para que, no caso de uma invasão, possam ser recuperados os 
registros e descobrir a identidade do intruso. O Unix possui alguns registros de log, mas não possui 
um mecanismo para facilitar a busca de dados nestes arquivos de log. 
Arquivos de Log do Unix 
/usr/adm/lastlog 
Neste arquivo o Unix guarda o último login de cada usuário. A data e horário do último login é 
mostrada quando o usuário se loga. Este arquivo é consultado quando um comando finger é 
requisitado. 
/etc/utmp usr/adm/wtmp 
O arquivo /etc/utmp guarda os dados de quem está logado no sistema no momento. O 
arquivo /usr/adm/wtmp mantém tanto o login como o logout. O que cada um deste arquivos contém 
varia de acordo com o Unix que está sendo usado, geralmente são informações como: o nome do 
terminal, username, o nome do host de onde a conexão foi originada, o horário que o usuário se 
logou, o ID do processo, etc. 
Os comandos who( ), users( ) e finger( ) utilizam as informações do arquivo /etc/utmp, enquanto o 
comando last( ), o qual mostra o tempo em que o usuário esteve logado, utiliza o 
arquivo usr/adm/wtmp. 
/usr/adm/acct 
Neste arquivo o Unix pode armazenar todos os comandos de cada usuário. Este arquivo pode ser 
utilizado quando se desconfia de que estejam ocorrendo problemas de segurança, para uma 
auditoria nos comandos executados pelos usuários suspeitos. 
Criptografia 
Os algoritmos criptográficos podem ser classificados em dois tipos: os de chave única e os de chave 
pública e privada. 
Os algoritmos de chave única, também chamados de algoritmos de chave simétrica, caracterizam-se 
por utilizar a mesma chave tanto para a cifragem como para a decifragem dos dados. 
Os algoritmos de chave pública e privada, também chamados de algoritmos de chave assimétrica, 
utilizam-se de duas chaves: uma secreta só conhecida por pessoas autorizadas e outra pública que 
pode ser divulgada. 
Por exemplo, em uma rede, a chave pública de cada host é divulgada a todos os hosts que tenham 
acesso à rede. Para cifrar uma informação, utiliza-se a chave pública do destinatário. Quando este 
recebe a mensagem cifrada, ele utiliza a sua chave secreta para decifrar e obter a mensagem 
original. 
O algoritmo mais conhecido de chave única é o DES e o de chave pública e privada é o RSA. 
4. Formas de Proteção 
 Firewalls e Proxies 
 Wrappers 
 Protocolos SSL, PGP 
Firewalls 
Os firewalls previnem a rede local contra os perigos da rede externa. 
Um firewall frequentemente é instalado no ponto que a rede local é conectada a Internet. Todo o 
tráfego que entra ou sai para Internet passa pelo firewall. 
Graças a isso ,o firewall controla todo o fluxo entre a rede local e a Internet e assim pode conferir se 
o tráfego é aceitável. 
Quanto a um tráfego ser aceitável ou não isto depende da segurança configurada para esta rede. 
Logicamente um firewall é um separador, um analizador. A implementação física de um firewall 
varia muito. O mais comum é um firewall ser constituído por um conjunto de componentes de 
hardware - um roteador, um computador ou a uma combinação de roteadores, computadores e redes 
com softwares apropriados. Existem diversas maneiras
de configurar estes equipamentos, esta 
configuração depende da segurança que quer ser dada para a rede. 
Vantagens 
Por ser um concentrador de todo o tráfego da rede local para a Internet é nele que estão colocadas 
todas as medidas de segurança. É mais eficiente e econômico colocar todas as medidas de segurança 
e tecnologias em apenas um local da rede do que tê-las espalhadas pela rede. 
Muitos dos serviços que a Internet oferece são inerentemente inseguros. O firewall obriga a 
segurança no site, permitindo somente serviços aprovados passar através dele, os serviços que 
tinham suas regras setadas. 
O firewall provê um excelente local para se coletar informações a respeito da utilização do sistema 
e da rede. 
 
Desvantagens 
Firewalls oferecem uma excelente proteção contra os perigos da rede, mas não é uma solução 
completa para segurança. Certos perigos estão fora do controle do firewall. 
Um firewall não pode proteger a sua rede interna de usuários internos ao sistema, nem proteger 
contra conexões que não são feitas através dele. 
Este assunto foi abordado no Tutorial sobre Firewalls por Marco Aurélio Spohn. 
Material relacionado: Firewalls - Ferramentas e os produtos comercias Bellcore, CheckPoint 
Software Tecnologies Ltd. (Firewalls), Firewall Security Corporation . 
 
Proxy 
Outro mecanismo que geralmente são utilizados juntamente com os firewalls são os proxies. Os 
proxies fazem a interface entre a rede interna e externa, fazendo o mapeamento dos números Ips 
internos para acessar a rede externa. Este assunto é mais bem abordado no Tutorial sobre Proxy por 
Ulisses Giorgi. 
1 Introdução 
Os proxies são principalmente usados para permitir acesso à Web através de um firewall (fig. 1). 
Um proxy é um servidor HTTP especial que tipicamente roda em uma máquina firewall. O proxy 
espera por uma requisição de dentro do firewall, a repassa para o servidor remoto do outro lado do 
firewall, lê a resposta e envia de volta ao cliente. 
 
Figura 1: Visão geral de um Proxy 
O Proxy está rodando ou em um servidor firewall ou qualquer outro servidor interno que tenha 
acesso total a internet - ou em uma máquina dentro do firewall fazendo conexões com o mundo 
exterior através de SOCKS ou qualquer outro software firewall. 
Normalmente, o mesmo Proxy é usado por todos os clientes em uma subrede. Isto torna possível 
para ele fazer caching eficiente de todos os documentos requisitados. 
A habilidade que o Proxy tem no uso do cache, o torna atrativo para aqueles que não estão dentro 
do firewall. Configurar um servidor Proxy é fácil e os mais populares programas clientes Web já 
tem suporte a essa ferramenta. Sendo assim, torna-se simples a tarefa de configurar um grupo de 
trabalho inteiro para usar o serviço de cache do Proxy. Isto reduz os custos com tráfego de rede 
porque muitos documentos que são requisitados são lidos do cache local. 
A metodologia atual é baseada em um código de gateway escrito por Tim Berners-Lee como parte 
do libwww ( WWW commom Library). Kevin Altis, Ari Luotonen e Lou Montulli foram os 
principais contribuidores para a padronização do Proxy. 
Lou Montulli, autor de Lynx, fez as primeiras mudanças no libwww em colaboração com Kevin 
Altis. Ari Luotonen mantém o CERN httpd. 
Obs.: se você está usando uma tela com configuração VGA, pode-se , já que a figura não caberá na 
tela, clicá-la para que apareça em uma janela separada. 
1.1 Porque um nível de aplicação proxy? 
Um nível de aplicação proxy faz um firewall seguramente permeável para os usuários na 
organização sem criar um furo na segurança onde hackers poderiam entrar na rede da organização. 
Para clientes Web, as modificações necessárias para suportar um nível de aplicação proxy são 
menores (leva-se apenas 5 minutos para adicionar suporte proxy para o Emacs Web Browser). 
Não há necessidade de compilar versões especiais de clientes Web com bibliotecas firewall, o 
cliente "out-of-the-box" pode ser configurado para ser um cliente proxy. Em outras palavras, 
quando se usa proxy não necessitamos customizar cada cliente para suportar um tipo ou método 
especial de firewall: o proxy, em si, é um método padrão para acessar firewalls. 
Usuários não têm que ter clientes FTP, Gopher e WAIS separados (muito menos modificados) para 
acessar um firewall - um simples cliente Web com um servidor proxy trata todos esse casos. O 
proxy também padroniza a aparência de clientes Gopher e FTP. 
O proxy permite que os programadores esqueçam as dezenas de milhares de linhas de código 
necessárias para suportar cada protocolo e se concentrem em coisas mais importantes - é possível 
ter clientes "peso-leve" que somente compreendam HTTP (nenhum suporte nativo aos protocolos 
FTP, Gopher, etc) - outros protocolos são manuseados transparentemente pelo proxy. Usando 
HTTP entre o cliente e o proxy, nenhuma funcionalidade é perdida, pois FTP, Gopher e outros 
protocolos Web são bem mapeados para o HTTP. 
1.1 Porque um nível de aplicação proxy? (cont.) 
Clientes sem DNS (Domain Name Service) também podem usar a Web. O endereço IP do proxy é a 
única informação realmente necessária. Organizações usando endereços, por exemplo, classe A 
(como 10.*.*.*), em suas redes particulares podem ainda acessar a internet contanto que o proxy 
seja visível tanto para a rede particular como para a Internet. 
Proxy permite um alto nível de log das transações de clientes, incluindo endereço IP, data e 
hora, URL, contagem de bytes e código de sucesso. Qualquer campo (seja de meta-informação ou 
seja comum) em uma transação HTTP é um candidato para log. Isto não é possível com log no nível 
IP ou TCP. 
Também é possível fazer a filtragem de transações de clientes no nível do protocolo de aplicação. O 
proxy pode controlar o acesso a serviços por métodos individuais, servidores e domínios, etc. 
Outra feature interessante do proxy é a cache. O uso de cache é mais efetivo no servidor proxy do 
que em cada cliente. Isto salva espaço em disco, desde que somente uma cópia é guardada, como 
também permite um uso de "cache inteligente", onde os documentos freqüentemente referenciados 
por muitos clientes são guardados por um periodo mais longo de tempo pelo cache manager. 
O uso de cache também torna possível acessar algumas páginas mesmo que servidores estejam fora 
do ar. Essa facilidade torna o serviço melhor, visto que recursos remotos como um site FTP 
ocupados que são frequentemente inacessíveis remotamente podem ser agora acessíveis através do 
cache local. Pode-se citar uma infinidade de usos que podemos fazer com o cache: fazer uma 
demonstração de algum lugar com uma baixa velocidade de conexão, ler documentos com a 
máquina não conectada (obviamente após colocar todos os documentos no cache local), etc. 
Em geral, autores de clientes Web não tem razão para usar versões de firewalls em seus códigos. O 
Proxy é mais simples para configurar do que SOCKS e trabalha em todas as plataformas, não 
somente UNIX. 
2.0 Detalhes Técnicos 
Quando uma requisição HTTP normal é feita por um cliente, o servidor pega somente o path e a 
"porção chave" da URL requisitada (Fig. 2); outras partes, como o especificador de protocolo 
"http:" e o nome do servidor são obviamente claros para o servidor HTTP remoto. O path 
requisitado especifica um documento ou um script CGI no sistema de arquivos local do servidor; ou 
ainda algum outro recurso disponível daquele servidor. 
Quando um usuário entra: 
 
http://mycompany.com/information/ProxyDetails.html 
 
O browser converte para: 
 
GET /information/ProxyDetails.html 
 
 
Figura 2: Uma transação HTTP normal 
O cliente faz a requisição ao servidor HTTP especificando apenas o recurso relativo àquele servidor 
(nenhum protocolo ou nome de servidor é colocado na URL). 
2.0 Detalhes Técnicos (cont.) 
Quando um cliente envia uma
mensagem para um servidor proxy a situação é um pouco diferente. 
O cliente sempre usa HTTP para transações com o proxy, mesmo quando acessa um recurso 
oferecido por um servidor remoto usando outro protocolo, como Gopher e FTP. 
Entretando, ao invés de especificar somente o pathname e possíveis palavras que complementariam 
a procura para o proxy (como ocorre em uma requisição normal), todo a URL é especificada (fig.3 e 
4). Desta forma o proxy tem todas as informações necessárias para fazer a requisição para o 
servidor remoto especificado na URL. 
Nada melhor que um exemplo para clarear as coisas: se o usuário digitasse a seguinte URL: 
 
http://mycompany.com/information/ProxyDetails.html 
 
O browser, sabendo da existência do proxy, converteria para a seguinte requisição: 
 
GET http://mycompany.com/information/ProxyDetails.html 
 
O browser conecta-se então ao servidor e o proxy providencia a conexão com a Internet. Nesse 
caso, o Proxy converteria a requisição para: 
 
GET /information/ProxyDetails.html 
 
 
Figura 3: Uma transação HTTP com Proxy. 
O cliente faz uma requisição ao Proxy usando HTTP, mas especificando toda a URL; o Proxy se 
conecta ao servidor remoto e pede o recurso relativo àquele servidor sem especificar protocolo ou o 
nome do servidor na URL. 
2.0 Detalhes Técnicos (cont.2) 
 
Figura 4: Transação FTP com Proxy. 
O cliente faz a requisição ao Proxy usando HTTP (embora o recurso seja um FTP). O Proxy analisa 
a URL recebida e percebe que deve abrir uma conexão FTP. O resultado (o arquivo, no caso) é 
enviado para o cliente usando HTTP. 
Deste ponto o Proxy age como um cliente para conseguir o documento: ele chama o mesmo 
protocolo libwww que um cliente deveria chamar para que o documento fosse obtido. Entretanto, a 
"apresentação" do documento no Proxy é através de HTTP, independente do protocolo que foi 
usado para consegui-lo. Um comando list, por exemplo, é retornado como um documento HTML. 
2.1 O Lado do Cliente 
A maioria dos clientes WWW é construída no topo de libwww, a WWW Common Library, que 
trabalha com os diferentes protocolos de comunicação usados na Web: HTTP, FTP, 
Gopher, News e WAIS. 
O suporte do proxy é feito automaticamente por clientes usando a libwww. Variáveis de ambiente 
são usadas para controlar a biblioteca. Existe uma variável de ambiente individual para cada 
protocolo de acesso; ex.: http_proxy, ftp_proxy, gopher_proxy e wais_proxy. Essas variáveis são 
configuradas para apontar para o proxy que deve servir as requisições desse protocolo, por 
exemplo: 
 ftp_proxy=http://www_proxy.domain:911/ 
 export ftp_proxy 
Normalmente um único servidor Proxy trata todos os protocolos, mas, como vimos, não tem que ser 
assim. 
Quando a variável de ambiente para certo protocolo é definida, o código libwww faz que a conexão 
sempre seja feita para o Proxy e não diretamente com o servidor remoto. 
A última versão de libwww (2.15 de abril de 1994) suporta as chamadas "lista de exceções" que são 
localizações que devem ser atingidas sem o auxílio do Proxy. Isso é extremamente útil quando o 
acesso trata-se de servidores locais, onde o acesso pode ser feito sem nenhum Proxy. 
Outra diferença no protocolo é que, como já exposto, a URL requisitada pelo cliente deve ser 
completa se for uma operação com o Proxy. Essas são as únicas diferenças entre uma transação 
HTTP normais e uma com Proxy. A simplicidade do suporte Proxy faz com que mesmo clientes 
não baseados em libwww possam facilmente suportá-lo. 
O suporte Proxy é implementado somente pata HTTP/1.0 no lado do servidor: todos os clientes 
devem usar esse protocolo. Isto não é um problema porque libwww faz isto automaticamente e a 
maioria dos clientes (se não todos) já tem sido atualizada para HTTP/1.0 
2.2 O Lado do Servidor 
O proxy deve ser capaz de agir tanto como um servidor como um cliente. Ele age como um servidor 
quando aceita requisições HTTP de clientes conectados a ele e age como cliente quando se conecta 
com servidores remotos para conseguir retornar (ou atualizar) os documentos para seus clientes. Os 
campos do cabeçalho passados para o proxy pelo cliente são usados sem modificações quando o 
proxy se conecta ao servidor remoto de forma que o cliente não perde qualquer funcionalidade 
quando existe um proxy como intermediário. 
Um proxy "completo" deveria falar todos os protocolos Web (os mais inportantes são HTTP, FTP, 
Gopher, WAIS e NTTP). Proxies que somente lidam com um único protocolo Internet, como o 
HTTP, também são uma possibilidade mas um cliente Web deveria então requerer acesso a outro 
proxy quando quisesse usar outro protocolo (para isso que existem as variáveis de ambiente 
explicadas em 2.1). 
2.2 CERN httpd: servidor HTTP 
CERN httpd, que é um dos sofwares servidores HTTP, tem uma única arquitetura sendo que ele é 
atualmente o único servidor HTTP que é construído no topo da WWW Commom Library. Diferente 
de outros servidores HTTP, CERN httpd é capaz de falar todos os protocolos Web - os clientes 
podem falar, desta forma, todos os protocolos implementados por libwww. 
CERN httpd é capaz de rodar como um protocolo gateway desde sua versão 2.00 de março de 1993, 
mas features adicionais foram adicionadas somente na versão 2.15, onde ele se tornou um proxy 
"completo" (full proxy). Nesta última versão ele aceita URLs completas. O mesmo servidor pode 
agora agir como um proxy para vários protocolos desde que os clientes passem para ele toda a URL, 
permitindo, dessa forma, que o proxy saiba qual protocolo usar quando interagir com o servidor 
destino. O CERN httpd pode também agir como um servidor HTTP normal devolvendo arquivos 
locais. 
O servidor foi bastante melhorado durante a primavera de 1994. A implementação original não 
passava a informação de autorização de acesso para o servidor remoto que é essencial para 
documentos protegidos. O corpo das mensagens que são apresentadas com os métodos POST e 
PUT não eram enviadas em versões anteriores a 2.15 que consertou essa falha. 
É também possível compilar uma versão especial do CERN httpds que usa SOCKs - isto significa 
que o proxy não tem que rodar em uma máquina firewall: pode falar com o mundo através de 
SOCKS. Note que isso significa usar SOCKS apenas no httpd e não nos programas clientes. 
No FTP o modo passivo (PASV) é suportado, no caso de algum administrador querer impedir 
conexões que cheguem na porta 1023. Entretando, nem todos os servidores FTP suportam PASV 
que causa uma volta ao modo normal. 
2.3 Cache 
A idéia básica no cache é simples: armazenar os documentos retornados em um arquivo local para 
uso posterior de forma que não seja necessário se conectar ao servidor remoto na próxima vez que o 
documento seja requisitado (figuras 5 e 6). 
 
Figura 5: Uso de Cache em Proxies 
O documento requisitado é buscado do servidor remoto e armazenado localmente para uso futuro 
 
 
Figura 6: Análise do cache 
Se uma versão atualizada do documento é achada no cache do proxy nenhuma conexão ao servidor 
remoto é necessária 
2.3 Cache (cont.) 
Existem muitos problemas que necessitam ser resolvidos quando o uso do cache é introduzido. 
Quanto tempo é possível manter um documento no cache e ainda estar seguro que ele está 
atualizado? Como decidir quais documentos valem a pena serem colocados no cache e por quanto 
tempo? 
Expiração de documentos foi prevista pelo protocolo HTTP que contém um objeto espicificando a 
data que o documento já não será válido. Entretanto, existem muito poucos servidores que 
atualmente dão essa informação. Até que ela seja comum (quando a maioria dos servidores Web 
retornarão a data de expiração) nós teremos que confiar em estimativas heurísticas, que nos dão tão 
somente uma estimativa grosseira do tempo de vida do objeto. 
Desde que muitos documentos Web são documentos "vivos",
especificar um tempo de vida para 
eles é geralmente uma tarefa difícil. Um documento pode permanecer um bom período de tempo 
intacto e, repentinamente, ser completamente mudado. Esta mudança pode não ter sido prevista pelo 
autor do documento e não estar bem informada na data de expiração. 
2.4 Inclusões no protocolo 
Quando é essencial que o documento retornado esteja atualizado, é necessário contactar o servidor 
remoto para cada requisição GET. O protocolo HTTP já contém o método HEAD para retornar a 
informação do cabeçalho de um documento, mas não o documento em si. Isto é útil para checar se o 
documento foi modificado desde o último acesso. 
Entretanto, nos casos em que o documento foi alterado, seria muito ineficiente fazer uma segunda 
conexão para o servidor remoto para conseguir executar o comando GET do documento. O 
overhead de fazer a conexão é freqüentemente considerável. 
O protocolo HTTP foi então modificado para conter uma requisição do tipo If-Modified-Since que 
torna possível fazer uma requisição GET condicional. Esta é essencialmente a mesma requisição 
GET exceto pelo cabeçalho que contém a data e hora que o objeto está armazenado no cliente (no 
nosso caso, no cache do proxy). 
Se o documento não foi modificado desde a data e a hora especificada ele não será retornado. O 
cliente receberá como resposta apenas informações relevantes como a nova data de expiração com 
um código de resultado especial. Se, caso contrário, o documento foi modificado, ele será retornado 
como se a requisição fosse um GET normal. 
O GET condicional faz que vários tipos de utilitários se tornem mais eficientes. Ele pode ser usado 
por software de mirroring que tem que fazer refresh de um grande número de arquivos em uma base 
regular. O proxy pode fazer refresh de seu cache durante períodos de inatividade e não apenas 
quando um documento explicitamente expira. 
Embora o GET condicional seja compatível com o antigo, isso de nada adianta. O protocolo HTTP 
é definido de forma que campos de cabeçalho desconhecidos sejam ignorados. Se o servidor HTTP 
remoto não suportar o GET condicional nenhum erro será retornado: ele simplesmente retornará 
todo o arquivo como se a requisição se tratasse de um GET comum. Felizmente todos os grandes 
servidores HTTP já suportam o GET condicional. 
O mecanismo de cache é baseado em disco, que significa que o boot do proxy ou da própria 
máquina nada lhe afetará. Devido a este detalhe, o cache abre novas possibilidades quando o proxy 
e um cliente Web estão na mesma máquina. O proxy pode ser configurado para usar somente o 
cache local, possibilitando a realização de demonstrativos sem uma conexão internet. Você pode até 
desplugar um notebook e levá-lo ao bar. 
Ligação entre Proxies 
O encadeamento de proxies deixa você usar um proxy como um cache local de um departamento de 
uma grande organização. Esses departamentos têm controle sobre o servidor e o cache. Esse 
servidor proxy departamental pode se conectar a um proxy firewall entre a Internet e a organização. 
Esse servidor proxy fala com a Internet como mostrado na figura 7. 
Qualquer restrição de acesso do proxy mais externo tem precedência sobre o mais interno 
(departamental). 
Por exemplo, imagine que o proxy departamental 1 está configurado para aceitar qualquer URL e o 
proxy da organização (organizacional) está configurado para impedir que URLs da França seja 
aceitas. Desta forma, uma requisição do proxy departamental 1 pode ser negado pelo proxy 
organizacional. 
 
 
Fig 7: Encadeamento de proxies 
3.0 O Futuro 
Como o entusiasmo pelos proxies foi somente agora despertado, há muitos detalhes que estão em 
estágios primários, embora a funcionalidade básica já esteja pronta. O cache é uma área muito 
extensa e complexa sendo uma coisa que necessita ser bastante melhorada. O proxy deveria ser 
melhorado para fazer lookahead, retornando todos os documentos que provavelmente serão 
acessados. Por exemplo, todos os documentos referenciados pelo último documento lido pelo 
cliente, juntamente com as figuras associadas, também deveriam ser lidos. 
O protocolo HTTP também deveria ser melhorado para permitir requisições e respostas multi-parte: 
isto permitiria que tanto softwares de cache como de mirroring fizessem refresh de uma grande 
quantidade de documentos em uma simples conexão ao invés de ter que re-conectar ao servidor 
para cada arquivo. Mensagens multi-parte são também necessárias por clientes Web para receber 
todas as imagens do documento com uma única requisição. 
Vários aspectos da arquitetura proxy necessitam ser padronizada. Um número de porta do servidor 
proxy deveria ser assinalado pela autoridade da Internet. No lado do cliente há uma necessidade 
para um mecanismo de "fallback" para proxies, onde o cliente poderia se conectar a um segundo ou 
terceiro servidor proxy se o primeiro falhasse (como DNS). Também um método de procura 
dinâmica para achar o proxy mais próximo é necessário: isto poderia ser feito usando-se um nome 
padrão DNS - www_proxy.my.domain, por exemplo. 
4.0 Conclusões 
Graças ao suporte do padrão proxy pelos clientes e a grande disponibilidade do servidor proxy 
cern_http, qualquer um atrás de um firewall pode agora ter pleno acesso à Internet com mínimos 
esforços e sem comprometer a segurança. Usuários corporativos não precisam mais evitar o acesso 
à Web. 
Considerando o extremo crescimento da Web e sua habilidade de trocar FTP o cache em proxies se 
torna essencial: ele possibilita um ganho de "banda virtual" desde que documentos freqüentemente 
serão retornados do cache local ao invés de um servidor distante. 
Wrappers 
Os wrappers são programas que tem como objetivo o aumento de segurança dos serviços da 
Internet, como finger, telnet, ftp, rlogin, rsh, talk, etc. 
O aumento de segurança proporcionado pelo wrapper varia desde uma maior capacidade de log, 
verificações se um dado host não esta pretendendo ser outro host através de falsificação de IP (IP 
Spoofing), falsificações de nomes de host (Host Name Spoofing), até aumento das restrições de cada 
um dos serviços. 
Como principal exemplo de wrapper temos o TCP_Wrapper, que funciona da seguinte forma: 
quando for solicitado alguma conexão, por exemplo, telnet, ao invés do Inetd executar diretamente 
o telnetd, ele irá executar o wrapper, que fará uma série de validações e armazenará no log o IP do 
host que quer o serviço, para só então executar o telnetd. Desta forma o wrapper fica como o 
guardião do serviço. 
O processo wrapper fica completamente transparente para os diversos serviços de rede, não interage 
com o server nem com o cliente. Desta forma o wrapper fica independente de aplicação, permitido 
que funcione com diversos tipos e versões de programas de rede. 
O fato de estar sendo executado apenas no momento inicial da conexão do server com o cliente, 
torna insignificante a carga por ele gerada no servidor. Finalmente, isto também o torna invisível 
para os usuários externos, que nem saberão que ele existe [DAN96]. 
Novos Protocolos 
Para alguns serviços da Internet foram desenvolvidas algumas soluções, como por exemplo os 
protocolos SSL e PGP. 
PGP 
O PGP (Pretty Good Privacy), destina-se a comunicação segura via e-mail, para isto utiliza-se de 
criptografia de chave pública. 
A mensagem enviada é criptografada com a chave pública do destinatário. Para que o usuário possa 
decifrar a mensagem ele decifra com a sua chave secreta a qual somente ele possui. Desta forma, 
qualquer pessoa que intercepte esta comunicação não conseguirá decifrar a mensagem. 
No PGP temos também a facilidade de poder assinar uma mensagem, assim a mensagem vai cifrada 
com a chave secreta do remetente e o destinatário decifra com a chave pública do remetente. Uma 
mensagem pode ir cifrada e assinada. 
Material relacionado: PGP - Faq e <="" a="">MIT
Distribuction Site for Pretty Good Privacy . 
 
SSL 
O SSL (Secure Socket Layer) foi desenvolvido pela Netscape Communications com o objetivo de 
gerar segurança e privacidade entre duas aplicações. Com o SSL é possível que aplicações 
cliente/servidor se comuniquem de forma segura evitando influências externas, falsificação dos 
dados e “escuta” dos dados em claro. 
O protocolo SSL atua entre o nível de aplicação e transporte da arquitetura Internet. Possui duas 
camadas: “SSL Record Protocol”, que é responsável por encapsular outros protocolos de alto nível 
e a “SSL Handshake Protocol”, que recebe os dados a serem cifrados/decifrados. 
Esta segunda camada é responsável pela autenticação do cliente e/ou servidor, negociação do 
algoritmo criptográfico e suas chaves antes da aplicação receber ou enviar qualquer byte de dados. 
Este protocolo é utilizado pelo BradescoNet para permitir homebanking. 
5. Ferramentas para Verificação de Segurança no Unix 
Muitas das ferramentas aqui apresentadas, não necessitam de privilégios de root para rodar e desta 
forma qualquer usuário pode detectar as falhas do sistema. Assim, estas ferramentas são muito 
utilizadas por intrusos, para descobrir os furos do sistema alvo. 
Esta é a razão por estas ferramentas terem sido muito criticadas. 
 
COPS 
O COPS é uma ferramenta de segurança para ambientes Unix, ele faz uma série de verificações 
como determinar se arquivos importantes estão em modo inadequado, verificar as senhas fáceis, etc. 
Material relacionado: COPS 
 
TRIPWIRE 
Ao contrário das outras ferramentas, o objetivo do TRIPWIRE é detectar que já houve algum tipo 
de intrusão no sistema. Ele é um analizador de integridade de arquivos e diretórios, um utilitário que 
compara um conjunto de arquivos com informações previamente armazenadas numa base de dados. 
Qualquer diferença é detectada e armazenada num log, incluindo arquivos que foram deletados ou 
criados. Geralmente, ele é executado do cron de tempos em tempos, e permite que se conclua, com 
um bom grau de confiança, que os arquivos binários principais não foram alterados. 
 
SATAN 
Satan (Security Analysis Tool for Auditing Network) é o mais complexo sistema de auditoria para 
sistemas Unix disponível. Ele coleta a maior quantidade possível de informações sobre um host, 
examina os serviços de rede como o finger, o NFS, o NIS, o ftp e o tftp, rexd entre outros. 
As informações que são relatadas pelo SATAN incluem tanto os tipos de serviços disponibilizados 
pelo host, quanto furos potenciais nestes serviços. Estes furos geralmente são causados por erros de 
configuração ou bugs conhecidos dos diversos daemons. Além disto, ele pode não apenas analisar 
diversos hosts individualmente, mas também procurar furos baseados em Trusted Hosts, e este sim 
ter problemas de segurança [DAN96]. O SATAN pode também ser utilizado para verificar a 
topologia de uma rede, serviços oferecidos, tipos de hardware e software, etc. 
 
TIGER 
Muito parecido com o SATAN, o TIGER, é um conjunto de Bourne Shell (bash) scripts, programas 
em C e arquivos de dados que visam fazer uma auditoria de segurança num sistema Unix. 
Sua maior diferença em relação ao SATAN está no fato de que a ênfase do TIGER esta em erros de 
permissões de arquivos, e não na área de serviços de rede, que é o caso do SATAN. 
Basicamente, quando é executado, TIGER procura por um arquivo de configuração (geralmente 
.tigerrc) que irá limitar ou ampliar a quantidade de testes executados dependendo do desejo do 
usuário. Ele então irá executar uma série de scripts e retornará as falhas de segurança encontradas. 
O TIGER sempre tenta descobrir formas que a conta root pode ser comprometida. 
 
ISS 
O ISS (Internet Security Scanner ) é considerada uma versão mais leve do SATAN, e possui uma 
versão comercial, a qual possui algumas vantagens como interface gráfica e análise de segurança 
para servidores WEB.[DAN96] 
Bibliografia 
 [GAL96] GALLEN, Bob & SUTTERFIELD, Lee - Network Security Points of Failure - 
Unix Review. Pg. 47 a 53. Novembro 1996. 
 [GAR94] GARFINKEL, Simson & SPAFFORD, Gene - Practical Unix Security - 
O’Reilly & Associates, Inc. 482 p. Junho 1994. 
 [LIU94] LIU, Cricket et all. - Managing Internet Information Services - O’Reilly & 
Associates, Inc. 630 p. Dezembro 1994. 
 [DAN96] DANDREA, Marcelo M. - Ferramentas para Segurança na Internet - Trabalho 
Individual - CPGCC UFRGS. 1996. 
 [SHI96] SHIMOMURA, Tsutomu & Markoff, John - Contra-Ataque A história da 
captura do pirata cibernético mais procurado nos Estados Unidos - Companhia das 
Letras. 343 p. 1996. 
 [SIY95] SIYAN, Karanjit & HARE, Cris - Internet Firewalls and Network Security - 
New Riders Publishing - 410 p. - 1995. 
 [TAR96] TAROUCO, Liane M. R. - Segurança na Internet - 9 p. 
Links relacionados ao Tutorial 
 
Segurança na Internet 
 Internet Security 
 Network Security 
 CERT 
 Security FAQ 
 
Mecanismos de Defesa 
 General security Tools 
 Unix Network Monitoring Tools 
 Authentication Tools 
 
Firewalls 
 Firewalls - Ferramentas 
 Freestone Toolkit (Firewalls) 
 IP-Filter 
 Firewalls FAQ 
 
Wrappers 
 TCP Wrappers 
 
PGP e SSL 
 PGP Faq 
 <="" a="">MIT Distribuction Site for Pretty Good Privacy 
 SSL 
 
Ferramentas para Verificação de Segurança 
 FTP - SATAN/TCP wrappers/log daemon/rpcbind/portmap 
 SATAN Release Information 
 Auditoria: ISS 
 
Produtos Comerciais 
 Bellcore 
 CheckPoint Software Tecnologies Ltd. (Firewalls) 
 Firewall Security Corporation 
 
Listas 
Bugs de Segurança: 
 bugtraq@crimelab.com 
 ntsecurity@iss.com 
 best-of-security@suburbia.net 
Firewalls: 
 firewalls@greatcircle.com 
 fwtk-users@tis.com 
IP Security 
1. Motivação
 O IP (Internet Protocol), base do conjunto de protocolos TCP/IP, é caracterizado por sua 
simplicidade. Com o objetivo de melhorar a desempenho da rede, deixa de realizar tarefas como 
estabelecimento de conexões, detecção e correção de erros, confirmação de entrega etc. Além disso, 
não provê mecanismos que garantam a autenticidade, integridade e privacidade das comunicações 
realizadas através da rede. Detalhes sobre o funcionamento deste protocolo podem ser encontrados 
em [3]. 
 Esta falta de segurança da atual versão do protocolo (IPv4) dá margem a inúmeras formas de 
ataque, como: negação de serviço, IP spoofing, session hijacking e password sniffing. Para 
compreender bem as dimensões deste problema, é preciso conhecer alguns conceitos chave de 
Segurança da Informação: 
Autenticação 
 A garantia que certa entidade tem de que outra entidade é quem afirma ser. 
Confidencialidade 
 Garantia da privacidade da informação. O acesso a ela é limitado apenas a entidades autorizadas. 
Integridade 
 Garantia de que a informação não foi alterada (intencionalmente ou não). 
 A princípio, o IPv4 não provê nenhum desses serviços de segurança. Visando contornar essas e 
outras fraquezas, foi criado o IPv6 [3][7]. 
 Atualmente em estágio de implantação, seu principal objetivo é aumentar o espaço de endereços 
em relação ao IPv4, resolvendo um grave problema, que é o de escassez de endereços. Além disso, 
visa permitir comunicações mais seguras através de mecanismos baseados em criptografia. Estes 
são fornecidos por uma ferramenta chamada Internet Protocol Security(IPSec). 
 Mesmo sendo desenvolvido tendo como objetivo a implementação na versão 6 do IP, o IPSec foi 
criado de forma a ser possível sua utilização também com o IPv4. 
2. Conceito
 Ao invés de ser um protocolo único, o IPSec é um conjunto de protocolos que fornece uma 
solução completa de segurança para redes TCP/IP como a Internet. Considerado bastante complexo, 
é definido pelas RFCs 2403, 2404, 2405, 2407, 2408, 2411,
2412, 4301 [8], 4302 [9], 4303 [10] e 
4306 [2]. 
 Seus principais protocolos são: 
 Authentication Header, que garante a autenticidade e a integridade da comunicação; 
 Encapsulating Security Payload, que provê privacidade e autenticação; 
 Internet Key Exchange, um mecanismo de troca de chaves. 
 Uma comunicação segura entre dois dispositivos através de uma rede insegura envolve o 
estabelecimento de um caminho seguro. É neste conceito que se baseia o IPSec. Para que isto 
ocorra, é preciso que os comunicantes sigam os seguintes passos: 
 Entrar em acordo quanto aos algoritmos de criptografia e autenticação que serão utilizados; 
 Trocar as chaves secretas que alimentarão os algoritmos de autenticação e criptografia; 
 Enviar os dados através da rede utilizando os métodos acordados. 
 Estas operações envolvem diferentes protocolos do conjunto IPSec. O primeiro passo está ligado 
ao estabelecimento de SAs (Security Associations); o segundo, ao protocolo IKE (Internet Key 
Exchange); e o último, aos protocolos AH (Authentication Header) e ESP (Encapsulation Security 
Payload), que utilizarão as Security Associations criadas. 
Security Associations 
 Um fundamento importante do IPSec são as Security Associations. Uma Security 
Association (SA) é um conjunto de parâmetros que representa uma relação unidirecional entre um 
emissor e um receptor. Entre estes parâmetros, estão: algoritmo de criptografia, chave de 
criptografia, algoritmo de autenticação e chave de autenticação. As informações de uma SA são 
comuns ao receptor e ao emissor. Para uma relação bidirecional, são necessárias duas Security 
Associations. 
 Três parâmetros atuam como identificadores de uma SA: 
 Security Parameters Index, um identificador numérico único de 32 bits, presente nos 
cabeçalhos dos protocolos IPSec; 
 Endereço IP de destino; 
 Identificador de protocolo de segurança, que relaciona a SA ao AH ou ao ESP. 
 Com esses parâmetros, um receptor pode facilmente associar uma mensagem segura IPSec a uma 
SA em sua base de dados de SAs (ou a duas, caso sejam utilizados tanto o AH quanto o ESP). Ele 
poderá então desencriptar a mensagem e/ou verificar as informações de autenticação, de acordo 
com os demais parâmetros. 
 3. Implementação 
 Com o IPSec, a segurança é implementada na camada do IP. Isto faz com que ele seja 
transparente para as aplicações, que não precisam ter seu código-fonte alterado para garantir 
segurança. Além disso, pode ser facilmente utilizado em conjunto com o UDP, protocolo muito 
usado atualmente em comunicações multimídia. 
 Diferentemente, as soluções de segurança mais comumente adotadas (SSL, TLS, SSH etc.) 
operam nas camadas de transporte ou aplicação. Muitas vezes, estas são utilizadas devido à 
complexidade da arquitetura e dos protocolos do IPSec, que exigem que a pilha TCP/IP seja 
alterada ou estendida, de acordo com a opção de implementação. 
 O IPSec pode ser implementado de diversas maneiras, seja num terminal, em um roteador 
ou firewall (para criar umgateway de segurança) ou em um dispositivo de segurança independente. 
Na RFC 4301 [8], são definidas 3 alternativas de implementação para o IPSec: 
Integração no IP 
 Se baseia na integração dos protocolos do IPSec na implementação nativa do IP, o que é viável 
tanto para um terminal quanto para um gateway de segurança. Pode ser considerada a solução 
padrão, mais elegante. 
 Entretanto, é preciso alterar o código-fonte da implementação IP, o que foi feito no Microsoft 
Windows 2000 (sendo incluído nas versões posteriores) e no Linux Kernel 2.6. Um tutorial simples 
sobre a utilização da pilha IPSec nativa do Ubuntu pode ser encontrado 
em https://help.ubuntu.com/community/IPSecHowTo. 
Bump-in-the-stack (BITS) 
 Consiste em implementar os protocolos IPSec entre a implementação nativa IP e os drivers da 
rede local. Os pacotes passados adiante pela camada do IP são interceptados por uma camada extra 
IPSec, que provê segurança e, depois, encaminha para a interface de rede na camada seguinte. 
 
Figura 1: Ilustração da alternativa de implementação BITS. 
Os cabeçalhos do IPSec são acrescentados após o cabeçalho IP. 
Ilustração adaptada de [3]. 
 Para esta implementação, não é necessário o acesso ao código-fonte da pilha IP. Normalmente, 
quando adotada, esta estratégia é aplicada a terminais da Internet. 
Bump-in-the-wire (BITW) 
 Neste método, é utilizado um hardware adicional, que provê os serviços IPSec. 
Este hardware atua de maneira semelhante ao software BITS, interceptando pacotes IP, 
adicionando segurança e repassando-os na rede. 
 Quando utilizado em conjunto com um roteador ou firewall, pode-se criar um gateway de 
segurança, que permite que diversos computadores numa rede local estabeleçam conexões seguras 
com terminais fora da rede, sem implementarem o IPSec. Mais informações poderão ser obtidas na 
descrição do modo túnel, na seção Modos de Operação. 
 Assim como a opção de implementação BITS, o Bump-in-the-wire não requer o acesso ao código 
da implementação IP nativa. 
 Como será visto mais adiante, as três estratégias de implementação (integrada, BITS e BITW) se 
relacionam com os dois modos de operação do IPSec. 
4. Modos de Operação. 
 São definidos dois modos de operação para o IPSec: Modo Transporte e Modo Túnel. 
Modo Transporte 
 Este modo de operação, que pode ser considerado o mais simples, é utilizado principalmente para 
o estabelecimento de comunicações fim-a-fim seguras entre terminais da Internet. Pode ser visto 
como o envio de pacotes IP comuns, com os respectivos cabeçalhos de transporte e aplicação, 
porém seguros. Esta segurança pode envolver tanto autenticação quanto confidencialidade. 
 
Figura 2: No modo transporte, o cabeçalho do IPSec (AH e/ou ESP) 
é situado entre o cabeçalho IP e sua porção de dados. 
 O modo transporte se baseia no encapsulamento dos protocolos das camadas superiores. Os 
cabeçalhos referentes ao AH e/ou ESP (os dois protocolos responsáveis por fornecer autenticação e 
encriptação) são adicionados após o cabeçalho da Camada de Transporte (TCP/UDP). 
 Acrescido ao pacote após os cabeçalhos AH/ESP, o cabeçalho IP é mantido inalterado, 
possibilitando um roteamento na rede idêntico ao usual. Devido a este fato, apenas a porção de 
dados do pacote pode ser encriptada, provendo confidencialidade. 
 Caso o pacote seja interceptado por terceiros, ainda que os dados enviados estejam 
criptografados, as informações contidas no cabeçalho IP (entre elas endereço de origem e destino) 
poderão ser acessadas. Todavia, como poderá ser visto nas seções posteriores, mesmo que a 
confidencialidade se restrinja à porção de dados nesse modo de operação, a integridade pode ser 
garantida para o pacote como um todo. 
 Há outra constatação acerca deste tipo de operação: como, neste caso, os cabeçalhos AH e ESP 
precisam ser inseridos antes do IP durante o empacotamento da mensagem oriunda da Camada de 
Transporte, este modo está associado à opção de arquitetura integrada, descrita anteriormente. 
Modo Túnel 
 Muito utilizado atualmente para o estabelecimento de VPNs, o modo túnel encapsula 
completamente o pacote IP. Na frente do cabeçalho IP original, são adicionados os cabeçalhos 
IPSec e um novo cabeçalho IP, que permite a formação de um túnel. Desta forma, a segurança será 
sempre aplicada ao pacote original como um todo, e não apenas à porção de dados. 
 
Figura 3: No modo túnel, o pacote IP recebe 
um cabeçalho IPSec e um novo cabeçalho IP. 
 O novo cabeçalho IP é utilizado no roteamento do pacote através da Internet. Chegando a seu 
destino, ocorrerá primeiramente a verificação da autenticação e/ou a desencriptação do restante do 
pacote. No caso de as informações estarem corretas, os cabeçalhos AH
e ESP são removidos e o 
pacote IP original é reconstituído. De acordo com o endereço de destino original, o pacote pode ser 
entregue à máquina local ou roteado novamente na rede. Se for roteado novamente, não estará mais 
sob a proteção do IPSec. 
 Tipicamente, o modo túnel é utilizado quando ao menos um dos pontos da comunicação está 
atrás de um gateway de segurança, que pode ser um roteador ou firewall que implemente o IPSec. 
Cria-se um túnel seguro através de uma rede pública não segura (como a Internet atual). É este o 
princípio das VPNs. 
 Como os cabeçalhos IPSec são acrescidos após o IP ter processado as mensagens das camadas 
superiores, este modo de operação está associado, em geral, às outras duas formas de 
implementação, BITS e BITW. 
 Alguns artigos defendem a existência de apenas um modo de operação, seja devido a questões de 
segurança, seja devido à complexidade do IPSec. Em [4], é sugerida a existência apenas do modo 
transporte, definindo um mecanismo alternativo para a criação de túneis, intitulado IIPtran. Já 
em [6], são analisadas diversas formas de simplificar o IPSec. Entre elas, está (em contraste com o 
outro artigo) a eliminação do modo transporte e do AH. As comunicações seriam realizadas apenas 
no modo túnel, utilizando o ESP para encriptação e autenticação. 
5. Authentication Header 
 O protocolo Authentication Header é utilizado para garantir a autenticidade e a integridade de 
pacotes IP. Sozinho, não provê qualquer confidencialidade. Em alguns programas P2P para 
compartilhamento de arquivos, por exemplo, é realizada a autenticação dos usuários e o teste de 
integridade dos blocos de arquivos enviados. Entretanto, não há privacidade na troca de pacotes. 
 Como o nome sugere, o AH define um cabeçalho, que é acrescentado ao pacote IP. Nele, estarão 
os dados de autenticação que serão verificados pelo receptor da mensagem. Para computar e 
verificar os dados do AH, é usada uma função de hashcomo MD5 e SHA-1. 
 No envio da mensagem, é calculada uma sequência de bits (chamada hash) de acordo com uma 
chave secreta (estabelecida pela Security Association) e o conteúdo do pacote (excetuando campos 
variáveis do IP como TTL). Para isso, é usado um algoritmo de hash, também definido pela SA. Na 
recepção, o hash é recalculado e comparado com o presente no AH. Como apenas os comunicantes 
conhecem a chave utilizada, é possível verificar se o pacote foi alterado, seja devido a erros ou a 
atitudes maliciosas. 
 Adicionalmente, de acordo com a implementação, o AH pode prover serviços de não repúdio 
através do uso de assinaturas digitais. Para mais informações, ver [9]. 
 
Figura 4: Localização do cabeçalho AH no modo transporte. 
A autenticação se aplica a todo o pacote IP. 
 O cabeçalho estará localizado de acordo com o modo de operação. No modo transporte, é 
acrescentado entre o cabeçalho IP e o da Camada de Transporte. Já no modo túnel, ficam entre os 
dois cabeçalhos IP: o novo e o original. 
 
6. Encapsulating Security Payload
 Responsável pelos serviços de confidencialidade do IPSec, o Encapsulating Security Payload se 
baseia no acréscimo de um cabeçalho e uma cauda ao pacote. 
 Este protocolo define a encriptação do pacote como um todo (no modo túnel) ou da porção de 
dados do pacote (no modo transporte). No lado do emissor é realizada a encriptação e, no lado do 
receptor, a desencriptação. Durante o trânsito, as informações encriptadas não poderão ser 
examinadas por terceiros. 
 Tanto para a encriptação, feita pelo emissor, quanto para a desencriptação, feita pelo receptor, são 
utilizados o algoritmo de criptografia e a chave secreta definidos por uma mesma SA. Há várias 
opções de algoritmos, sendo os mais comuns 3DES,Blowfish e AES. 
 Além de prover serviços de confidencialidade, o ESP também provê serviços de autenticação e 
integridade, de maneira bastante similar ao AH. Todavia, estes não incluem o cabeçalho IP (no caso 
do modo túnel, não incluem o novo cabeçalho IP). 
 Disso conclui-se que, dependendo da implementação, o endereço de origem do pacote poderia ser 
alterado no caminho sem que o receptor note. Ainda assim, a autenticação do restante do pacote 
seria capaz de garantir que o pacote veio de uma pessoa que conhece a chave de autenticação. 
 
Figura 5: Ilustração de um pacote em modo túnel com encriptação 
e autenticação do ESP. O cabeçalho e a cauda ESP envolvem 
o pacote original. No fim, é acrescentado o campo de autenticação. 
 Assim como o AH, o cabeçalho ESP se situa entre os dois cabeçalhos IP no modo túnel e, no 
modo transporte, entre o cabeçalho IP e o da Camada de Transporte. A cauda ESP está sempre 
situada no fim do pacote. 
 7. Internet Key Exchange
Motivação 
 Os serviços de autenticação e encriptação (AH e ESP) dependem da utilização de chaves secretas 
(conhecidas apenas pelos comunicantes) para serem fornecidos pelo IPSec. 
 Caso uma entidade intercepte uma comunicação IPSec em modo transporte, por exemplo, esta 
será incapaz de alterar qualquer parte do pacote sem que seja notada (se estiver sendo utilizado o 
AH) ou ter acesso às informações nele contidas (caso seja utilizado o ESP). Todavia, isto é válido 
apenas se esta entidade não possui acesso ao segredo compartilhado pelos comunicantes. 
 Portanto, é preciso que o acordo quanto às chaves que serão usadas na comunicação seja feito de 
maneira segura. 
 A forma mais trivial de estabelecer uma chave secreta no IPSec é através de configuração 
manual. Os comunicantes escolhem as chaves que serão usadas e registram manualmente as SAs 
necessárias. 
 Esta é uma estratégia bastante prática para cenários pequenos, mas não é escalável, já que seria 
preciso configurar ao menos duas SAs (entrada e saída) para cada par de endereços IP. Para resolver 
este problema e permitir maior flexibilidade no compartilhamento de chaves, foi criado o IKE 
(Internet Key Exchange), um protocolo para gerenciamento automático de chaves que também faz 
parte do IPSec. 
Funcionamento 
 Este protocolo, que pode ser considerado o mais complexo do conjunto IPSec, usa o ISAKMP 
(Internet Security Association Key Management Protocol) como base para criar as SAs nos dois 
lados da comunicação, que serão utilizadas pelos protocolos AH e ESP. 
 O primeiro passa para o estabelecimento das SAs para os comunicantes é a criação de um canal 
seguro. Este é definido por uma SA bidirecional (ao contrário das demais) referente ao IKE. Nela, 
estão contidas informações como a chave secreta e os algoritmos de criptografia que serão usados 
nas negociações subsequentes (para as SAs do AH e do ESP). 
 Para a escolha da chave secreta, é realizada uma série de procedimentos baseada no algoritmo de 
troca de chaves Diffie-Hellman [11]. 
Diffie-Hellman 
 Proposto em 1976, este algoritmo permite o estabelecimento de uma chave secreta compartilhada 
através de um canal de comunicação inseguro. Esta chave poderá ser utilizada, por exemplo, em 
algoritmos de criptografia simétrica. 
 Numa troca de chaves entre duas entidades hipotéticas A e B, ocorre primeiro um acordo quanto a 
um número primo p e a uma raiz primitiva de p, r. 
 
 O número r será uma raiz primitiva de p se 
 
 Os números p e r não são secretos. 
 Em seguida, A e B escolhem um número secreto entre 1 e p-1 (inclusive) cada, XA e XB. 
 Então, A envia para B: 
 
 A chave secreta K, calculada por B, será: 
 
 Analogamente, A poderá calcular a mesma chave secreta a partir de YB, fazendo: 
 
 Desta forma, a partir da escolha de r e p e da troca (sem segurança) de YA e YB, o algoritmo de 
Diffie-Hellman permite o estabelecimento de uma chave secreta, conhecida apenas por A e B. 
 Este algoritmo não autentica os usuários que estão realizando
a troca de chaves, o que o torna 
vulnerável a ataques. Devido a isso, o protocolo IKE inclui mecanismos adicionais para garantir a 
autenticação, baseados na troca de assinaturas digitais. Para mais detalhes, ver [2]. 
 Escolhida a chave secreta e criada a SA para o IKE, ocorre o estabelecimento das demais SAs 
através do canal seguro criado. 
 
 8. Conclusão
 É possível notar que o IPSec é um conjunto bastante complexo de protocolos, com várias opções 
de implementação e, principalmente, de configuração. São necessárias diversas escolhas: modo de 
operação, uso de AH e/ou ESP, algoritmos de encriptação e autenticação, mecanismo para troca de 
chaves etc. 
 Algumas publicações alertam contra os perigos de uma escolha ruim no IPSec. Em [5], são 
descritas diversas formas de ataque a comunicações IPSec que usem somente a encriptação do ESP, 
sem autenticação. Ainda que seja desencorajada na documentação, esta prática representa uma 
dentre várias configurações não seguras que são permitidas. Outro exemplo é a possibilidade de se 
utilizar algoritmos de criptografia considerados fracos atualmente, como o DES. 
 Percebe-se que estas escolhas demandam bastante cuidado e, portanto, devem ser tomadas de 
maneira sensata. É para facilitar a configuração, eliminando algumas opções inseguras, que surgem 
sugestões como as encontradas em [4] e [6]. Devido a estas fraquezas, espera-se que surjam novas 
iterações dos protocolos IPSec. 
 Apesar de possuir problemas e de ter sido desenvolvido para o IPv6, o IPSec é muito utilizado 
atualmente para a implementação de Redes Privadas Virtuais (VPN) sobre o IPv4. De fato, é uma 
ótima alternativa para este fim. Para outras aplicações, a segurança do tráfico IP é em geral 
fornecida pelo protocolo SSL e seu sucessor, TLS. 
9. Perguntas e Respostas
Pergunta: 
O que significam os conceitos autenticação, confidencialidade e integridade? 
Resposta: 
Autenticação - garantia de que uma entidade é, de fato, quem afirma ser; 
Confidencialidade - garantia de que apenas as entidades autorizadas terão acesso à informação; 
Integridade - garantia de que a informação foi preservada. 
 
Pergunta: 
Por que o Authentication Header não provê assinatura quando uma chave secreta é utilizada? 
Resposta: 
Como a chave é conhecida por ao menos 2 pessoas, a mensagem pode ser forjada. Neste caso, o AH 
não garante o não repúdio. 
 
Pergunta: 
O serviço de autenticação do Encapsulating Security Payload não inclui o cabeçalho IP. O endereço 
de origem do pacote pode ser alterado? Como pode ser garantida a autenticação nesse caso? 
Resposta: 
Sim, o endereço de origem e outros campos do cabeçalho IP podem ser alterados. Ainda assim, a 
autenticação do restante do pacote garante que este veio de uma pessoa que conhece a chave de 
autenticação. 
 
Pergunta: 
Alguns autores defendem a existência apenas do modo túnel, com autenticação e encriptação do 
ESP. Como o modo transporte e o AH podem ser substituídos? 
 
 
Resposta: 
Um endereço de destino no novo cabeçalho IP igual ao original fará com que o pacote chegue ao 
destino da mesma forma. O pacote no modo transporte é menor. É possível realizar uma 
compressão nos campos do ESP para reduzir o uso de banda passante. No modo túnel, o ESP 
encripta e autentica todo o pacote original, reduzindo a necessidade do uso conjunto do AH neste 
caso. 
 
Pergunta: 
O Internet Key Exchange, protocolo do IPSec para gerenciamento automático de chaves, utiliza um 
algoritmo baseado na troca de chaves de Diffie-Hellman, mas inclui mecanismos adicionais para a 
autenticação. Por que isso é necessário? Qual o principal tipo de ataque ao qual o Diffie-Hellman é 
vulnerável? 
Resposta: 
Por não prover a autenticação dos comunicantes, o algoritmo de Diffie-Hellman é vulnerável ao 
"ataque do homem no meio", em que a atacante intercepta as mensagens enviadas e forja outras, 
assumindo a identidade das vítimas. 
10. Referências
1. C. Adams, S. Lloyd. Understanding public-key infrastructure: concepts, standards, and 
deployment considerations. Addison-Wesley, Segunda Edição, Janeiro de 2003. 
2. C. Kaufman. Internet Key Exchange (IKEv2) Protocol. RFC 4306, Dezembro de 2005. 
3. C. Kozierok. The TCP/IP guide: a comprehensive, illustrated Internet protocols 
reference. No Starch Press, p. 449-473, 2005. 
4. J. Touch, L. Eggert, Y. Wang. Use of Ipsec Transport Mode for Dynamic Routing. RFC 
3884, Setembro de 2004. 
5. K. Paterson, A. Yau. Cryptography in Theory and Practice: The Case of Encryption in 
IPsec. Cryptology ePrint Archive, Report 2005/416, 2005. 
6. N. Ferguson, B. Schneier. A Cryptographic Evaluation of IPsec. Counterpane Internet 
Security, Dezembro de 2003. 
7. R. Oppliger. Security at the Internet Layer. IEEE, Setembro de 1998. 
8. S. Kent, K, Seo. Security Architecture for the Internet Protocol. RFC 4301, Dezembro de 
2005. 
9. S. Kent. IP Authentication Header. RFC 4302, Dezembro de 2005. 
10. S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303, Dezembro de 2005. 
11. W. Diffie, M. Hellman. New Directions in Cryptography. IEEE Transactions on 
Information Theory, vol. IT-22, Novembro de 1976. 
12. W. Stallings. IP Security. The Internet Protocol Journal, Volume 3, no. 1, Março de 2000.