CRIPTOGRAFIA - FESP

CRIPTOGRAFIA
A história da criptologia é um passeio no campo da criatividade humana. A
criptologia foi usada por governantes e pelo povo, em épocas de guerra e em
épocas de paz. Faz parte da história humana porque sempre houve fórmulas
secretas, informações confidenciais e interesses os mais diversos que não
deveriam cair no domínio público ou na mão de inimigos.
Desde quando existe a criptologia? Quais as pessoas famosas que gostavam de
criptologia? Quais as pessoas que ficaram famosas com a criptologia? Quem
usava criptologia?
Dê uma olhada na linha do tempo. Tem muita coisa interessante. Não se esqueça
de que as guerras e a necessidade de manter ou conquistar novos territórios
sempre foram "vitaminas" para a Criptologia. E guerra e disputa é o que nunca
faltou na história da humanidade!
ÉPOCAS DA HISTÓRIA
É comum se dividir a História em fases, épocas e períodos seguindo os mais
variados critérios. Um deles é dividir a História em Idade Antiga, Idade Média,
Idade Moderna e Idade Contemporânea, porém esta é uma sistematização
arbitrária.
Para Toynbee, é possível encontrar unidades mais simples dentro do vasto
complexo de personalidades e fatos sociais que se sucedem sem solução de
continuidade. São as sociedades e, num sentido mais amplo, as civilizações que
ditam a História. Haveria 21 civilizações, distintas das culturas primitivas de
curta duração, das quais ainda hoje cinco sobrevivem.
Já que o critério é arbitrário, vamos fazer o nosso: analisaremos o período antes
de Cristo, depois com a Idade Média e finalmente com as histórias recente e
atual.
ANTES DE CRISTO ou CRIPTOLOGIA NA ANTIGUIDADE
O período antes de Cristo até o ano de 476 é conhecido como ANTIGUIDADE ou
IDADE ANTIGA. Abrange as civilizações dos assírios, egípcios, hebreus, hititas,
persas e outros, que viveram nas vizinhanças do mar Mediterrâneo, com o modo
de produção asiático. As culturas das antigas Grécia e Roma, às vezes chamadas
de civilizações clássicas, são também consideradas parte da Antiguidade, com o
modo de produção escravista.
Os antigos babilônios foram grandes matemáticos e se interessavam pela
astronomia. Até hoje usamos seu método de divisão por 60 na contagem do
tempo em segundos e minutos. Nosso calendário provém do que era usado pelos
egípcios e que depois foi modificado pelos romanos. Ainda hoje as obras de

cientistas gregos, como Euclides, Arquimedes e Aristóteles, são consultadas.
Ignora-se quando e quem inventou o primeiro alfabeto, mas é certo que veio de
uma das culturas antigas. Os fenícios, ao que tudo indica, o teriam difundido pelo
mundo mediterrâneo.
E daí? Já existia criptologia na Idade Antiga? Como ciência oficializada, a
resposta é não. Como aplicação prática, sim!
IDADE MÉDIA ou CRIPTOLOGIA MEDIEVAL
Classicamente, a Idade Média vai de 476, data da queda do Império Romano, até
1453, data da queda de Constantinopla. Do início da idade média até Carlos
Magno, que funda o Santo Império Romano, católico e feudal, há um longo
período de transição.
A Idade Média é marcada pelas migrações e invasões bárbaras, a expansão do
islamismo, a fundação do império de Carlos Magno, a organização feudal, a
Cavalaria e as Ordens Militares, as Cruzadas, a organização da Igreja Católica e
o prestígio temporal dos papas, heresias e Inquisição, a formação das
monarquias feudais e o início das monarquias modernas do Ocidente, a luta
entre o Império e o papado, a guerra dos Cem anos, a Magna Charta Libertatum,
documento fundamental das liberdades modernas, o Cisma do Ocidente, a
formação das monarquias da Europa Oriental, as invasões dos mongóis e a queda
de Constantinopla, em 1453, que marca o seu fim.
Apesar das proibições (e até perseguições) no chamado período das trevas, a
criptologia era uma necessidade, e o movimento renascentista, com início ao
redor de 1300, trouxe grandes novidades.
CRIPTOLOGIA RECENTE
A história recente é a época das grandes invenções, dos descobrimentos
marítimos, da Renascença. Fatos marcantes foram a centralização monárquica e
o absolutismo, as guerras religiosas, a nova política econômica, o surgimento do
Direito das gentes, o advento da ciência moderna, o classicismo literário e o
desenvolvimento artístico, a formação das potências modernas e a expansão
colonial.
Em 1789 ocorre a Revolução Francesa seguida pela era napoleônica, pela luta
pelo Estado nacional e constitucional, pelas revoluções democráticas e pelo
aparecimento da questão social e pelo imperialismo colonial. É a época das
grandes invenções, principalmente relacionadas à comunicação: o telégrafo e o
rádio mudam radicalmente o papel da criptologia.
A CRIPTOGRAFIA ATUAL
Em 1900 o desenvolvimento tecnológico continua e as duas Grandes Guerras
aumentam exponencialmente a importância da criptologia. Seus efeitos são
sentidos tanto na criptografia quanto na criptoanálise.

O computador tem um impacto ainda maior que os já causados pelo telégrafo e
pelo rádio - a criptologia distancia-se dos conceitos tradicionais para entrar
numa nova era.
+- (1900 a.c)
A história acontece numa vila egípcia perto do rio Nilo chamada Menet Khufu.
No túmulo de Khnumhotep II, homem de grande importância, alguns hieróglifos
foram substituídos por outros mais "importantes e bonitos". Kahn considera este
fato como o primeiro exemplo documentado de escrita cifrada.
± 1500 a.C.
A criptografia da Mesopotâmia ultrapassou a egípcia, chegando a um nível
bastante avançado. O primeiro registro do uso da criptografia nesta região está
numa fórmula para fazer esmaltes para cerâmica. O tablete de argila que contém
a fórmula tem apenas cerca de 8 cm x 5 cm e foi achado às margens do rio Tigre.
Usava símbolos especiais que podem ter vários significados diferentes. (Kahn)
Nesta época, mercadores assírios usavam "intaglios", que são peças planas de
pedra com inscrições de símbolos que os identificavam. O moderno comércio
com assinaturas digitais estava inventado!
Esta também foi a época em que culturas como a do Egito, China, Índia e da
Mesopotâmia desenvolveram a esteganografia:
* Tatuagens com mensagens na cabeça de escravos. Infelizmente era preciso
esperar o cabelo crescer para esconder a mensagem. A decifração era feita no
barbeiro...
* Marcas na parte interna de caixas de madeira usadas para transportar cera. As
marcas eram escondidas com cera nova. Para decifrar, bastava derreter a cera.
* Mensagens colocadas dentro do estômago de animais... e também de humanos.
600 a 500 a.C.
Escribas hebreus, escrevendo o Livro de Jeremias, usaram a cifra de substituição
simples pelo alfabeto reverso conhecida como ATBASH. As cifras mais
conhecidas da época são o ATBASH, o ALBAM e o ATBAH, as chamadas cifras
hebraicas. (Kahn)
Se é que realmente existiu, o scytalae espartano ou bastão de Licurgo era um
bastão de madeira ao redor do qual se enrolava firmemente uma tira de couro ou
pergaminho, longa e estreita. Escrevia-se a mensagem no sentido do
comprimento do bastão e, depois, desenrolava-se a tira com as letras

embaralhadas.
século 400 a.C
Textos gregos antigos, de Enéas, o Tático, descrevem vários métodos de ocultar
mensagens. Este cientista militar e criptógrafo inventou um telégrafo hidro-ótico,
um sistema de comunicação à distância. Dois grupos, separados por uma
distância em que ainda era possível reconhecer a luz de uma tocha e que
quisessem enviar mensagens deviam possuir dois vasos iguais. Os vasos tinham
um abertura no fundo, fechada por uma rolha, e eram preenchidos com água.
Um bastão, que tinha mensagens inscritas, era colocado em pé dentro do vaso.
Ao sinal de uma tocha, as rolhas eram retiradas simultaneamente. Quando o
nível da água estivesse na altura da mensagem que se queria transmitir, outro
sinal luminoso era enviado para que as rolhas fossem recolocadas.
± 300 a.C.
rtha-sastra, um livro atribuído a Kautilya, foi escrito na Índia. Cita diversas cifras
criptográficas e recomenda uma variedade de métodos de criptoanálise (o
processo de quebrar códigos) para obter relatórios de espionagem. Os processos
são recomendados para diplomatas.
Euclides de Alexandria, matemático grego que viveu aproximadamente de 330
a.C. a 270 a.C., compilou e sistematizou o que havia na época sobre geometria e
teoria dos números. É o famoso texto "Elementos", o livro mais publicado na
história da humanidade (não é a Bíblia, como se costuma dizer). Euclides nem de
longe poderia imaginar a tremenda influência que sua obra teria nos dias da
moderna criptologia feita por computador.
Erastótenes de Cirene, filósofo e geômetra grego, viveu de 276 a.C. a 194 a.C.
Conhecido como criador de um método para identificar números primos,
chamado de crivo de Erastótenes, e por ter calculado o diâmetro da Terra com
surpreendente precisão.
± 200 a.C.
Políbio, um historiador grego nascido em Megalópolis e que viveu de 204 a.C. a
122 a.C., escreveu vários livros sobre o Império Romano. Descreveu também
uma cifra de substituição que converte os caracteres da mensagem clara em
cifras que, apesar de não ser da sua autoria, ficou conhecida como Código de

Políbio.
± 130 a.C.
Em Uruk, na região do atual Iraque, era comum os escribas transformarem seus
nomes em números dentro do emblema que identificava seus trabalhos. A
prática, provavelmente, era apenas para divertir os leitores e não estava
relacionada à segurança.
50 a.C.
O imperador romano Júlio César usou uma cifra de substituição para aumentar a
segurança de mensagens governamentais. César alterou as letras desviando-as
em três posições - A se tornava D, B se tornava E, etc. Às vezes, César reforçava
sua cifragem substituindo letras latinas por letras gregas.
O Código de César é o único da Antiguidade que continua sendo usado até hoje.
Atualmente denomina-se qualquer cifra baseada na substituição cíclica do
alfabeto de Código de César.
79 d.C.
A fórmula Sator ou quadrado latino é encontrado em escavações feitas em
Pompéia, inscrito numa coluna. Ocorre também num amuleto de bronze,
originário da Ásia Menor, datado do século V. As palavras rotas arepo tenet
opera sator parecem ter o efeito mágico de nunca desaparecem... persistem até
hoje como um enigma de transposição.
200 d.C.
O Papiro de Leiden, um texto que detalha como fazer poções especiais, possui
texto cifrado nos trechos cruciais das receitas. Exemplos destas "receitas
mágicas" são as que supostamente fazem com que um homem ame uma mulher
ou que provoquem uma doença de pele incurável. Só para informar, as receitas
não funcionam
400 d.C.

Kama-Sutra, escrito por Vatsayana, classifica a criptografia como a 44ª e 45ª das
64 artes que as pessoas deveriam conhecer e praticar:
* A arte de saber escrever em cifras e de escrever palavras de uma forma
peculiar.
* A arte de falar mudando as formas da palavra, conhecida como criptolalia.
A LINHA DO TEMPO DA CRIPTOGRAFIA RECENTE.
1466
Leon Battista Alberti (1404-1472) era amigo de Leonardo Dato, um secretário
pontificial que o aproximou da criptologia. Alberti inventou e publicou a primeira
cifra polialfabética, criando um disco de cifragem para simplificar o processo,
conhecido como Disco de Alberti (que foi reeditado como um brinquedo chamado
"Captain Midnight Decoder *** Ao que tudo indica, esta classe de cifra não foi
quebrada até os anos de 1800. Alberti também tem muitos escritos sobre o
estado da arte de cifras, além da sua própria invenção. Usou seu disco para
facilitar a obtenção de criptogramas. Estes sistemas eram muito mais fortes do
que a nomenclatura usada pelos diplomatas da época e foram aplicados durante
muitos séculos.
O "Trattati in cifra" de Leon Battista Alberti foi publicado em Roma, na Itália, em
1470. Continha "especialmente teorias e processos de cifragem, métodos de
decifração e dados estatísticos" (Galland).
1473-1490
Um manuscrito [...] de Arnaldus de Bruxella usa cinco linhas de cifras para
ocultar a parte crucial da operação da alquimia que fazia a pedra filosofal."
(Kahn)
1474
Em 1474, Sicco Simonetta publicou "Regulae ad extrahendum litteras zifferatas
sine exemplo", um pequeno trabalho ressaltando "métodos de decifração e
fornececendo dados estatísticos consideráveis" (Galland). "A data do pequeno
ensaio de Simonetta sobre cifras é importante porque se tratava de um período
no qual a criptologia se tornou prática universal, quando cifras simples
evoluíram para criptogramas complicados." (Thompson).
1518
Johannes von Heydenberg aus Trittenheim/Mosel, ou Johannes Trithemius (1462-
1516), escreveu o primeiro livro impresso de criptologia. Inventou uma cifra

esteganográfica na qual cada letra era representada por uma palavra obtida de
uma sucessão de colunas. A série de palavras resultantes ficava parecida com
uma oração legítima. Também descreveu cifras polialfabéticas na forma de
tabelas de substituição retangulares que, na época, já tinham se tornado padrão.
Introduziu a noção da troca de alfabetos a cada letra.
Trithemius escreveu, porém não publicou, sua Steganographia, a qual circulou
como manuscrito por mais de cem anos, sendo copiada por muitas pessoas que
desejavam extrair os segredos que se pensava que continha. A verdadeira
história do feiticeiro que conjurava espíritos e praticava magia negra você
encontra em "O Segredo do Terceiro Livro". Altamente interessante, recomendo
a leitura.
A Polygraphiae libri sex de Trithemius, a qual incluía sua tabela de substituição
Tabula Recta Caesar, foi publicada em 1518, apesar de haver dúvidas quanto à
data correta. Foi reimpressa em 1550, 1564, 1571 e 1600. Uma tradução em
Francês apareceu em 1561 e em 1564. (Galland)
1526
ohannes von Heydenberg aus Trittenheim/Mosel, ou Johannes Trithemius (1462-
1516), escreveu o primeiro livro impresso de criptologia. Inventou uma cifra
esteganográfica na qual cada letra era representada por uma palavra obtida de
uma sucessão de colunas. A série de palavras resultantes ficava parecida com
uma oração legítima. Também descreveu cifras polialfabéticas na forma de
tabelas de substituição retangulares que, na época, já tinham se tornado padrão.
Introduziu a noção da troca de alfabetos a cada letra.
Trithemius escreveu, porém não publicou, sua Steganographia, a qual circulou
como manuscrito por mais de cem anos, sendo copiada por muitas pessoas que
desejavam extrair os segredos que se pensava que continha. A verdadeira
história do feiticeiro que conjurava espíritos e praticava magia negra você
encontra em "O Segredo do Terceiro Livro". Altamente interessante, recomendo
a leitura.
A Polygraphiae libri sex de Trithemius, a qual incluía sua tabela de substituição
Tabula Recta Caesar, foi publicada em 1518, apesar de haver dúvidas quanto à
data correta. Foi reimpressa em 1550, 1564, 1571 e 1600. Uma tradução em
Francês apareceu em 1561 e em 1564. (Galland)
1526
O livro Opus novum ... principibus maxime vtilissimum pro cipharis, de Jacopo
Silvestri, é impresso. A obra discute seis métodos de cifras, inclusive a cifra de
César, para a qual ele recomenda o uso de um disco de cifragem. Opum novum
foi escrito para ser um manual prático de criptologia que "claramente pretendia
alcançar um vasto círculo de leitores". (Arnold)
Na figura ao lado, observe que o alfabeto-chave de Silvestri não possuía as letras
j, v, w e y. "No disco, as três marcas que sucedem o Z representam: & para et;
um símbolo usado comumente no Latim medieval para significar us ou um no
final de palavras (p.ex., plurib& = pluribus), ou com, con, cum ou cun no início

de palavras (p.ex., &cedo = concedo); e um símbolo usado para rum, a
terminação do genitivo plural latino (illo& = illorum). O zig-zag no centro da
figura deve corresponder a uma pequena manivela para girar os discos móveis".
(Arnold)
1533
Heinrich Cornelius Agrippa von Nettelsheim (1486-1535) publica o De occulta
philosophia, em Colônia, na Alemanha. No livro 3, capítulo 30, descreve sua cifra
de substituição monoalfabética, hoje conhecida como Cifra Pig Pen. A tradução
literal do nome é Porco no Chiqueiro e vem do fato de que cada uma das letras
(os porcos) é colocada numa "casa" (o chiqueiro). Na época, a cifra parece ter
tido importância pois, alguns anos mais tarde, Vigenère a reproduz no seu
Traicté des chiffres, ou secretes manieres d'escrire (Paris, 1586, f. 275 v).
Aparentemente, esta cifra foi utilizada pela sociedade secreta dos francomaçons.
1540
Giovanni Battista Palatino publicou seu Libro nvova d'imparare a scrivere ... Con
vn breue et vtile trattato de le cifere. Foi reimpresso em 1545, 47, 48, 50, 53, 56,
61, 66, 78 e 1588. Uma versão revisada foi impressa em 1566, 78 e 88
A CIFRA DE CÉSAR.
Apesar de a criptologia estar bastante avançada na época, em 50 a.C. César
usava um sistema bastante simples de substituição. Suetônio, escritor romano
que viveu no início da era cristã (69 d.C.), em Vida dos Césares, escreveu a
biografia dos imperadores romanos, de Júlio César a Domiciano.
Conta que Júlio César usava na sua correspondência particular um código de
substituição no qual cada letra da mensagem original era substituída pela letra
que a seguia em três posições no alfabeto: a letra A era substituída por D, a B
por E, e assim sucessivamente
Hoje em dia, porém, a denominação de Código de César é utilizada para
qualquer cifra na qual cada letra da mensagem clara seja substituída por outra
deslocada um número fixo de posições, não necessariamente três. Um exemplo é
o código que, ainda segundo Suetônio, era usado por Augusto, onde a letra A era
substituída por B, a B por C e assim sucessivamente.
Como o alfabeto romano possui 26 letras, é possível obter 26 alfabetos cifrantes
diferentes, dos quais um (o do deslocamento zero) não altera a mensagem
original. Cada um destes alfabetos cifrantes é conhecido como Alfabeto de César.

CARACTERÍSTICAS
• Origem: Usada pelo imperador romano Júlio César em 50 a.C.
• Classe: Substituição Simples.
• Tipo: Monoalfabética (porque usa apenas UM alfabeto cifrante)
Monogrâmica (porque trata cada UM dos caracteres individualmente).
• Características: Reversível porque, aplicando-se o mesmo método no texto
cifrado obtém-se novamente a mensagem original.
• Segurança: Baixíssima
• Uso: Aplicável apenas em textos muito curtos.
• Criptoanálise: Uma simples criptoanálise baseada na característica
estatística da língua é suficiente para decifrar o texto.
A substituição original do código de César encontra-se na tabela abaixo:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
D E F G H I J K L M N O P Q R S T U V W X Y Z A B C
Apesar da sua simplicidade (ou exatamente devido a ela), esta cifra foi utilizada
pelos oficiais sulistas na Guerra de Secessão americana e pelo exército russo em
1915.
A cifra ROT13, que surgiu em 1984 na USENET, baseia-se numa substituição na
posição 13 (A por N, B por O, etc).
Com o uso de dois discos concêntricos contendo todas as letras do alfabeto, a
substituição se torna extremamente simples. Estes discos já foram utilizados
como brinquedo que fazia a alegria de muitas crianças (... e de adultos também).
O que é Esteganografia ?
O termo esteganografia vem do grego e significa "escrita coberta". É um ramo
particular da criptologia que consiste, não em fazer com que uma mensagem seja
ininteligível, mas em camuflá-la, mascarando a sua presença. Ao contrário da
criptografia, que procura esconder a informação da mensagem, a esteganografia
procura esconder a EXISTÊNCIA da mensagem.
Contrariamente à criptografia, que cifra as mensagens de modo a torná-las
incompreensíveis, a esteganografia esconde as mensagens através de artifícios
usando imagens ou um texto que tenha sentido, mas que sirvam apenas de
suporte (como o alfabeto biliteral de Francis Bacon ou as famosas cartas de
George Sand). A idéia é a mesma das grelhas de Cardano e do "barn code":
mesclar a mensagem numa outra, onde apenas determinadas palavras devem ser
lidas para descobrir o texto camuflado.
O primeiro uso confirmado da esteganografia está em "As Histórias" de Heródoto
e remonta ao século V a.C.: um certo Hístio, querendo fazer contato secreto com
seu superior, o tirano Aristágoras de Mileto, escolheu um escravo fiel, raspou
sua cabeça e escreveu na careca a mensagem que queria enviar. Esperou que os

cabelos crescessem e mandou o escravo ao encontro de Aristágoras com a
instrução de que deveriam raspar seus cabelos.
Ainda nas "As Histórias" de Heródoto consta que, para informar os espartanos de
um ataque iminente dos persas, o rei Demaratos utilizou um estratagema muito
especial: pegou tabletes, retirou-lhes a cera, gravou na madeira a mensagem
secreta e recobriu os tabletes novamente com cera. Deste modo, os tabletes,
aparentemente virgens, não chamaram a atenção e chegaram até as mãos dos
gregos. O problema foi que os gregos não imaginavam que a cera que tinham
importado continha mais do que apenas cera. Foi Gorgo, a mulher de Leônidas,
quem teve a idéia de raspar a cera e bisbilhotar o fundo das caixinhas que a
transportava - leu a mensagem, avisou os gregos e garantiu a vitória sobre os
persas.
Na China antiga também se usava a esteganografia. Escreviam-se mensagens
sobre seda fina e o pequeno retalho era transformado numa bolinha que era
recoberta por cera. Para transportar a mensagem, obrigavam um mensageiro
engolir a bolinha, ir até o destinatário e entregá-la depois de... éééécccaaaa.
No século XVI, o cientista italiano Giovanni Porta descobriu como esconder uma
mensagem num ovo cozido: escrevia sobre a casca do ovo cozido com uma tinta
contendo uma onça de alume (± 29 g) diluída em cerca de meio litro de vinagre.
A solução penetrava na casca e se depositava sobre a superfície branca do ovo.
Depois, bastava o destinatário abrir o ovo para ler a mensagem.
O historiador da Grécia antiga, Enéias, o Tático, teve a idéia de enviar uma
mensagem secreta fazendo minúsculos furos em certas letras de um texto
qualquer. A sucessão destas letras marcadas fornecia o texto secreto. Dois mil
anos mais tarde, remetentes ingleses empregaram o mesmo método, não para
garantir o segredo de suas cartas, mas para evitar o pagamento de taxas de
correio muito caras. Na realidade, antes da reforma do serviço postal ao redor de
1850, enviar uma carta custava cerca de um shilling para cada cem milhas de
distância. Os jornais, no entanto, eram isentos. Graças a furinhos de agulha, os
ingleses espertos enviavam suas mensagens gratuitamente transformando folhas
de jornal em verdadeiras peneiras Este procedimento também foi utilizado pelos
alemães durante a Primeira Guerra Mundial. Durante a Segunda Guerra, eles
aperfeiçoaram o método marcando letras de jornais com tintas "invisíveis" ao
invés de fazerem furos.
Os espiões alemães da Segunda Guerra utilizavam micropontos para fazer com
que suas mensagens viajassem discretamente. Eram fotografias do tamanho de
um ponto (.) que depois eram ampliadas para que a mensagem aparecesse
claramente. Era uma espécie de microfilme colocado numa letra, num timbre,
etc.
Em 1999, Catherine Taylor Clelland, Viviana Risca e Carter Bancroft publicaram
na revista Nature "Hiding messages in DNA microdots" (escondendo mensagens
em micropontos de DNA). Como qualquer material genético é formado por
cadeias de quatro nucleotídeos (Adenina, Citosina, Guanina e Timina), podemos
comparar estas cadeias a um alfabeto de quatro letras: A, C, G e T. Além disso,
como os cientistas atualmente podem fabricar cadeias de DNA com um conjunto

predeterminado de nucleotídeos, nada os impede de atribuir a um grupo de três
nucleotídeos uma letra do alfabeto, um número ou sinais de pontuação (por
exemplo, "A"=CGA, "B"=CCA, etc) e compor uma "mensagem genética". Para
disfarçar as pistas, pode-se misturar algumas outras sequências aleatórias de
nucleotídeos. Para complicar as coisas, o resultado é apenas visível ao
microscópio eletrônico. Uma possível aplicação deste método esteganográfico
seria, por exemplo, uma empresa que produz uma nova espécie de tomate e
inclui sua marca de fábrica nas moléculas do tomate afim de evitar imitações.
Códigos
Códigos podem ser protocolos de comunicação, ou seja, um "conjunto de
convenções que rege o tratamento e, especialmente, a formatação de dados num
sistema de comunicação". Existem códigos abertos (como o código Morse) e
códigos secretos.
Códigos também podem ser uma coletânea de substitutos para letras, palavras
ou frases inteiras. Geralmente são colocados em livros, os chamados livros de
códigos ou nomenclaturas, como duas listas em ordem alfabética. Numa delas o
texto claro está em ordem alfabética (para facilitar a cifragem), seguido dos
substitutos. Na outra, os códigos estão em ordem alfabética (para facilitar a
decifração), seguidos do texto claro correspondente.
CIFRAS DE BLOCO
As cifras de bloco operam em blocos de tamanho fixo, geralmente de 64 ou 128
bits. Para cifrar mensagens cujo comprimento ultrapasse o tamanho do bloco,
existem vários modos de operação. A maioria apenas confere
confidencialidade; algumas proporcionam confidencialidade e autenticação. Este
texto é um resumo dos principais modos de operação das cifras de bloco.
ECB - Electronic codebook
O modo de operação mais simples é o electronic codebook - ECB (livro de código
eletrônico). A mensagem clara é fracionada em blocos de tamanho fixo e cada
bloco é cifrado isoladamente. No final, a mensagem cifrada é obtida pela
concatenação dos blocos cifrados.

A desvantagem deste método é que blocos de texto claro iguais produzem
também blocos cifrados iguais, ou seja, o método não esconde o padrão dos
dados. Este modo de operação não acrescenta nada à confidencialidade
proporcionada pela cifra. A comparação do resultado da aplicação de uma cifra
de bloco nos dados de uma imagem gráfica, usando diversos modos de operação,
mostra de forma clara a contribuição à confidencialidade proporcionada pelos
modos de operação.
O modo ECB também pode fazer com que protocolos sem proteção de
integridade se tornem ainda mais vulneráveis a ataques, principalmente a
ataques de replay (veja em Criptoanálise/Tipos de ataque).

CBC - Cipher-block chaining
No modo de operação cipher-block chaining - CBC (corrente de blocos), é feita
uma operação XOR entre cada novo bloco de texto claro com o bloco cifrado
obtido na etapa imediatamente anterior. Desta forma, cada um dos blocos
cifrados depende de todos os blocos de texto claro anteriores.
O CBC é um dos modos de operação mais utilizados. Sua maior desvantagem é
ser sequencial. Como não pode ser usado em paralelo (pois sempre depende do
resultado anterior), seu uso dificulta o processamento de blocos em paralelo, o
que melhoraria o desempenho do método.

PCBC - Propagating cipher-block chaining
O modo de operação propagating cipher-block chaining - PCBC (corrente de
blocos em propagação) foi projetado para propagar ou esparramar melhor que o
CBC pequenas alterações no texto cifrado. É usado quase que exclusivamente no
Kerberos e no WASTE. As rotinas de cifragem e decifração são as seguintes:
O vetor de inicialização é
CFB - Cipher feedback e OFB - output feedback
O modo Output Feedback (OFB) transforma uma cifra de bloco num gerador de
números pseudo-aleatórios. O texto cifrado realimenta a cifra de bloco e este
processo é repetido para produzir um fluxo de bits pseudo-randômicos. O fluxo
de bits é totalmente determinado pelo algoritmo, pela chave, por um vetor de
inicialização e pelo número de bits que realimentam a cifra em cada etapa. O
fluxo de bits pode então servir para fazer uma operação XOR com o texto claro
afim de produzir o texto cifrado, transformando efetivamente a cifra de bloco
numa cifra de fluxo.
O modo Cipher Feedback (CFB) difere do OFB apenas porque o texto cifrado
(depois da etapa XOR) realimenta o método ao invés da saída da cifra de bloco
(antes da etapa XOR). Uma cifra de bloco operando no modo CFB não pode ser
usada como um gerador de números randômicos.
Com o cipher feedback um bloco de fluxo de chave é calculado cifrando-se o
bloco de texto cifrado anterior.

O modo output feedback gera o próximo bloco de fluxo de chave cifrando o bloco
de fluxo de chave anterior:

O algoritmo DES ilustrado
Conheça todos os detalhes da origem e da concepção do DES, o primeiro
exemplar da modernidade. O artigo sobre criptologia "The DES Algorithm
Illustrated" de Grabbe, do qual tomei conhecimento através do meu amigo Dr.
César Bravo, e "The Code Book" de Singh serviram de base para esta série sobre
o DES.
O National Bureau of Standards paquera o Gênio da Garrafa
O algoritmo DES (Data Encryption Standard) já foi o algoritmo de encriptação
mais usado no mundo. Durante muitos anos, e para muitas pessoas, "fazer código
secreto" e DES foram sinônimos.

Em 15 de Maio de 1973, durante o reinado de Richard Nixon, o National Bureau
of Standards (NBS) publicou uma notícia no Federal Register solicitando
formalmente propostas de algoritmos criptográficos para proteger transmissões
e armazenamento de dados. A notícia explicava porque a encriptação era um
assunto importante.
Nas últimas décadas houve um aumento acelerado no acervo e na comunicação
de dados digitais do governo, da indústria e de outras organizações do setor
privado. Com frequência, o conteúdo destes dados transmitidos e armazenados é
de alto valor e/ou alta sensibilidade. Hoje em dia são comuns as transmissões de
dados de transferências de fundos de alguns milhões de dólares (entre agências
bancárias), da compra ou venda de ações (entre bolsas de valores e corretoras),
de mandados de prisão ou registros de prisão e condenação (entre agências de
serviços policiais), de reservas e emissões de passagens aéreas (entre
companhias aéreas e agências de turismo) e de registros de saúde e dados de
pacientes (entre médicos e centros de tratamento).
O crescente volume, valor e confidencialidade destes registros regularmente
transmitidos e armazenados por agências comerciais e governamentais acabou
destacando o problema e a preocupação com a exposição destes dados ao acesso
e uso não autorizados. O mau uso pode ocorrer sob a forma de roubo ou
desfalques de registros de dados representando dinheiro, modificações
maliciosas de balanços comerciais ou a interceptação e mau uso de informações
confidenciais sobre pessoas. A necessidade de proteção torna-se então aparente
e urgente.
Reconhecidamente, a encriptação (também conhecida por embaralhamento,
cifragem ou transformação de privacidade) representa a única maneira de
proteger tais dados durante uma transmissão e um modo de proteger o conteúdo
de dados armazenados em vários meios, contanto que se possa criar e validar
uma encriptação forte o suficiente e que seja passível de ser integrada num
sistema. O National Bureau of Standards solicitava técnicas e algoritmos para a
encriptação de dados por computador. Também solicitava técnicas para
implementar a função criptográfica: gerar, avaliar e proteger chaves
criptográficas; manter arquivos codificados com chaves que expiram; fazer
atualizações parciais em arquivos encriptados e misturar dados encriptados com
claros para permitir marcações, contagens, roteamentos, etc. O Bureau, no seu
papel de estabelecer padrões e de auxiliar o governo e a indústria no acesso à
tecnologia, se encarregaria de avaliar os métodos de proteção para preparar as
linhas de ação.
O NBS ficou esperando por respostas. Nenhuma apareceu até 6 de Agosto de
1974, três dias antes da renúncia de Nixon, quando a IBM apresentou um
algoritmo candidato que ela havia desenvolvido internamente, denominado
LUCIFER.
HORST FEISTEL e o algoritmo LUCIFER
Horst Feistel chegou como imigrante alemão aos Estados Unidos em 1934.
Estava prestes a se tornar um cidadão estadunidense quando os EUA entraram

na guerra. Para Feistel, alemão, isto significou uma imediata prisão domiciliar, a
qual se estendeu até 1944. Mesmo após alguns depois do incidente, Feistel
manteve-se distante da criptologia para evitar levantar suspeitas das
autoridades. Porém, quando estava no Cambridge Research Center da Força
Aérea Americana, não resistiu e começou a pesquisar cifras. Imediatamente
começou a ter problemas com a National Security Agency, a NSA, organização
responsável pela segurança das comunicações militares e governamentais, que
também se incumbe de interceptar e decifrar mensagens estrangeiras. Até hoje,
mais que qualquer outra organização do mundo, a NSA é a que emprega o maior
número de matemáticos, a que compra a maior quantidade de hardware e a que
intercepta mais mensagens. Pode ser considerada a líder mundial da bisbilhotice
e da quebra de sigilo.
A NSA não se importava com o passado de Feistel, queria apenas ter o
monopólio da pesquisa em criptografia e parece que acabou conseguindo fazer
com que o projeto de pesquisa de Feistel fosse cancelado. Em 1960, o
pesquisador, perseguido, foi para a Mitre Corporation, mas a NSA continuou
fazendo pressão e forçou-o a abandonar seu trabalho pela segunda vez. Feistel
acabou indo para o Thomas J. Watson Laboratory da IBM, perto de Nova Iorque,
onde, por alguns anos, conseguiu prosseguir com suas pesquisas sem ser caçado.
Foi neste laboratório que, no início de 1970, ele desenvolveu o sistema Lucifer. E
foi este o sistema apresentado à NBS.
Após avaliar o algoritmo com a ajuda da National Security Agency (ironia do
destino), o NBS adotou o algoritmo LUCIFER com algumas modificações sob a
denominação de Data Encryption Standard (DES) em 15 de Julho de 1977. O
DES foi rapidamente adotado na mídia não digital, como nas linhas telefônicas
públicas. Depois de alguns anos, a International Flavors and Fragrances, por
exemplo, estava utilizando o DES para proteger as transmissões por telefone das
suas preciosas fórmulas ("With Data Encryption, Scents Are Safe at IFF" na
Computerworld 14, No. 21, 95 de 1980).
Neste meio tempo, a indústria bancária, a maior usuária de encriptação depois
do governo, adotou o DES como padrão para o mercado bancário atacadista. Os
padrões do mercado atacadista da indústria bancária são estabelecidos pelo
American National Standards Institute (ANSI). A norma ANSI X3.92, adotada em
1980, especifica o uso do algoritmo DES.
O governo dos EUA, durante os cerca de 20 anos de reinado do DES, forçava a
indústria a limitar sua criptografia ao DES (e até a formas mais fracas) sem
revelar como esta cifra era fácil de quebrar. A aceitação desta política,
praticamente sem contestação, colocou toda a infraestrutura de importância
crítica em risco.

Para provar a falta de segurança do DES, a Electronic Frontier Foundation - EFF
construiu o primeiro hardware para crackear mensagens codificadas por este
método. Na quarta-feira, 17 de Julho de 1998, o EFF DES Cracker, construído
com menos que US$ 250.000, venceu um concurso lançado pelo RSA Laboratory,
o "DES Challenge II", e a equipe recebeu o prêmio de US$ 10.000. A máquina
precisou de menos que 3 dias para completar o desafio, ultrapassando a marca
de 39 dias anteriormente conseguida através de um processamento maciço de
várias dezenas de milhares de computadores em rede.
Seis meses mais tarde, no dia 19 de Janeiro de 1999, uma terça-feira, a
Distributed.Net, uma coalisão mundial de entusiastas do computador,
trabalhando com um EFF DES Cracker e uma rede distribuída de cerca de
100.000 PCs na Internet, quebrou novamente o recorde. Para vencer o concurso
DES Challenge III da RSA precisou apenas de 22 horas e 15 minutos. No andar
térreo da Conferência sobre Segurança de Dados & Expo da RSA, um encontro
sobre segurança de dados e criptografia de grande importância que é realizado
em San José, California, o sistema estava testando 245 bilhões de chaves por
segundo quando a chave correta foi encontrada.
Estava decretado o fim do DES e provada a incompetência do governo
estadunidense em avaliar riscos e estabelecer políticas de segurança adequadas.
A EFF publicou um livro, "Cracking DES - Secrets of Encryption Research,
Wiretap Politics & Chip Design - How federal agencies subvert privacy", onde
conta em detalhes todos os aspectos deste projeto que bateu de frente com a
administração dos EUA. Nos capítulos 5, 6 e 7 está o código fonte do software
usado. O governo norte-americano, apoiando-se na lei que proíbe a expostação
de software de criptografia, proibiu que este material fosse publicado na Internet
em servidores que estivessem em território dos EUA. Não tem problema...
O Departamento de Engenharia Elétrica da Universidade Católica de Leuven, na
Bélgica, escaneou o material e o disponibilizou em EFF DES Cracker Source
Code. Caso você tenha dificuldade em fazer o download, procure na seção de
Downloads da Aldeia, na categoria Criptologia / Criptoanálise. Lá também está a
preciosidade.

Fontes
• "The DES Algorithm Illustrated", de J. Orlin Grabbe. Grabbe é o autor do
"International Financial Markets", internacionalmente conhecido como um
especialista em derivativos. Atua em criptografia, segurança de transações
bancárias e dinheiro eletrônico. Sua home page está em
http://orlingrabbe.org/.
• Simon Singh, autor de vários livros de sucesso, também escreveu "The
Code Book", livro sobre criptologia rico em detalhes históricos e
extremamente didático.
• Cracking DES no site da EFF.
O DES trabalha com bits ou números binários - os 0s e 1s dos computadores
digitais. Cada grupo de 4 bits corresponde a um valor hexadecimal, cuja base é
16. O binário "0001" corresponde ao número hexadecimal "1", o binário "1000" é
igual ao número hexadecimal "8", "1001" é igual ao hexadecimal "9", "1010" é
igual a o hexadecimal "A" e "1111" é igual ao hexadecimal "F".
O DES funciona encriptando grupos de 64 bits de mensagem, o que significa 16
números hexadecimais. Para realizar a encriptação, o DES utiliza "chaves" com
comprimento aparente de 16 números hexadecimais, ou comprimento aparente
de 64 bits. Entretanto, no algoritmo DES, cada oitavo bit da chave é ignorado, de
modo que a chave acaba tendo o comprimento de 56 bits. Mas, para todos os
efeitos, o DES é organizado baseando-se no número redondo de 64 bits (16
dígitos hexadecimais).
Por exemplo, se tomarmos a mensagem clara hexadecimal 8787878787878787 e
a encriptarmos com a chave DES hexadecimal 0E329232EA6D0D73, obteremos
o texto cifrado hexadecimal 0000000000000000. Se o criptograma for decifrado
com a mesma chave secreta, o resultado será o texto claro original
8787878787878787 hexadecimal.
Este exemplo é limpo e metódico porque nosso texto claro tinha o comprimento
de exatos 64 bits. O mesmo seria verdade caso nosso texto claro tivesse um
comprimento múltiplo de 64 bits. Mas a maioria das mensagens não cairá nesta
categoria. Não serão um múltiplo exato de 64 bits (isto é, um múltiplo exato de
16 números hexadecimais).
Por exemplo, considere a seguinte mensagem: "Criptologia sempre NumaBoa".
Esta mensagem clara possui 28 bytes (56 dígitos hexadecimais) de comprimento.
Neste caso, para encriptar a mensagem, seu comprimento precisa ser ajustado
com a adição de alguns bytes extras no final. Depois de decifrar a mensagem,
estes bytes extras são descartados. É lógico que existem vários esquemas
diferentes para adicionar bytes. Aqui nós iremos adicionar apenas zeros no final,
de modo que a mensagem total seja um múltiplo de 8 bytes (ou 16 dígitos
hexadecimais, ou 64 bits).
O texto claro "Criptologia sempre NumaBoa" é, em hexadecimal,
43 72 69 70 74 6F 6C 6F
67 69 61 20 73 65 6D 70
72 65 20 4E 75 6D 61 42

6F 61 0D 0A
Note que os primeiros 54 dígitos hexadecimais representam a mensagem em
Português, enquanto que "0D" é o hexadecimal para Retorno (Carriage Return) e
"0A" é o hexadecimal para Quebra de Linha (Line Feed), indicando que o arquivo
de mensagem chegou ao fim. Completamos então a mensagem com alguns zeros
no final para obter um total de 64 dígitos hexadecimais:
43 72 69 70 74 6F 6C 6F
67 69 61 20 73 65 6D 70
72 65 20 4E 75 6D 61 42
6F 61 0D 0A 00 00 00 00
Se cifrarmos agora a mensagem clara em blocos de 64 bits (16 dígitos
hexadecimais), usando a mesma chave DES "0E329232EA6D0D73", obtemos o
seguinte texto cifrado:
A1 BF 4C 8C 1F 44 6A 4C
CA 4D E4 28 6E DE 99 50
F5 59 66 2B B5 09 D9 3C
4B A7 70 FA E2 4B B3 C2
Se você tem algum conhecimento da criptografia clássica, não vai ser difícil
perceber que o DES utiliza somente cifras tradicionais como a substituição e a
transposição. A diferença é que, com a ajuda do computador, não se trabalha
mais com letras e sim com bits. Os princípios, porém, são os mesmos.
O DES é uma cifra de bloco, o que significa que atua sobre blocos de texto claro
de determinado tamanho (64 bits) e retorna blocos de texto cifrado do mesmo
tamanho. Portanto, o DES resulta numa permutação entre os 2 64 (leia como "2

elevado a 64") arranjos possíveis de 64 bits, cada um deles podendo ser 0 ou 1.
Cada bloco de 64 bits é dividido em dois blocos de 32 bits, um sub-bloco
esquerdo L e um sub-bloco direito R (esta divisão é usada apenas em certas
operações).
Exemplo: Seja M o texto claro da mensagem M = 0123456789ABCDEF, onde M
está no formato hexadecimal (base 16). Reescrevendo M em formato binário
obtemos o bloco de texto de 64 bits:
1111
M = 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110
L = 0000 0001 0010 0011 0100 0101 0110 0111
R = 1000 1001 1010 1011 1100 1101 1110 1111
O primeiro bit de M é "0" e o último bit é "1". Lemos da esquerda para a direita.
O DES atua sobre blocos de 64 bits usando tamanhos de chave de 56 bits. Na
realidade, as chaves são armazenadas com 64 bits mas, passando por um
processo que "retira" 8 bits, são reduzidas para 56 bits. Estes 8 bits estão
presentes nas chaves para garantir a integridade das mesmas, ou seja, o último
bit de cada um dos 8 bytes da chave é um bit verificador, chamado de bit de
paridade. Bits de paridade indicam quantos bits estão setados (têm valor 1) nos
sete primeiros bits do byte. Quando este número for par (daí paridade), o último
bit recebe o valor 1, caso contrário, recebe o valor 0. Por exemplo, o byte
00010011 possui 2 bits setados nos primeiros sete bits, por isso o byte é
completado com 1; o byte 00110100 possui três bits setados nos primeiros sete
bits, por isso o byte é completado com 0. Apesar dos bits de paridade serem
retirados, nos cálculos a seguir vamos sempre numerar os bits de 1 a 64, indo da
esquerda para a direita.
Exemplo: seja K a chave hexadecimal K = 133457799BBCDFF1. Isto nos dá a
chave binária (substituindo 1 = 0001, 3 = 0011, etc agrupados em oito bits):
K = 00010011 00110100 01010111 01111001 10011011 10111100 11011111 11110001
Passo 1: A partir da chave de 56 bits, criar 16 subchaves de 48 bits
A chave de 64 bits é permutada de acordo com a tabela a seguir, PC-1. Observe
que nesta tabela os bits de paridade foram excluídos (os bits 8, 16, 24, 32, 40,
48, 56 e 64 estão ausentes) portanto, esta operação só é efetuada depois da
verificação de integridade da chave. Como a primeira entrada da tabela é "57",
isto significa que o 57º bit da chave original K torna-se o primeiro bit da chave
permutada K+. O 49º bit da chave original transforma-se no segundo bit da
chave permutada. O 4º bit da chave original é o último bit da chave permutada.
Observe que apenas 56 bits da chave original aparecem na chave permutada.
PC-1
---------------------------------------
57 49 41 33 25 17 9
1 58 50 42 34 26 18
10 2 59 51 43 35 27
19 11 3 60 52 44 36
63 55 47 39 31 23 15

7 62 54 46 38 30 22
14 6 61 53 45 37 29
21 13 5 28 20 12 4
---------------------------------------
Exemplo: Da chave original de 64 bits
K = 00010011 00110100 01010111 01111001 10011011 10111100 11011111
11110001
obtemos a permutação de 56 bits
K+ = 1111000 0110011 0010101 0101111 0101010 1011001 1001111 0001111
A seguir, dividimos esta chave em duas metades, esquerda C 0
e direita D 0
, onde
cada metade tem 28 bits.
Exemplo: Da chave permutada K+ obtemos
C 0
= 1111000 0110011 0010101 0101111
D 0
= 0101010 1011001 1001111 0001111
Com C 0
e D 0
definidas, criamos dezesseis blocos C n
e D n
, 1

casos, um único deslocamento à esquerda significa uma rotação dos bits uma
posição para a esquerda de modo que, após um deslocamento à esquerda, os bits
nas 28 posições sejam os bits que previamente estavam nas posições 2, 3, ..., 28,
1.
Exemplo: Do par original C 0
e D 0
obtemos:
C 0 = 1111000011001100101010101111
D 0 = 0101010101100110011110001111
C 1 = 1110000110011001010101011111
D 1 = 1010101011001100111100011110
C 2 = 1100001100110010101010111111
D 2 = 0101010110011001111000111101
C 3 = 0000110011001010101011111111
D 3 = 0101011001100111100011110101
C 4 = 0011001100101010101111111100
D 4 = 0101100110011110001111010101
C 5 = 1100110010101010111111110000
D 5 = 0110011001111000111101010101
C 6 = 0011001010101011111111000011
D 6 = 1001100111100011110101010101
C 7 = 1100101010101111111100001100
D 7 = 0110011110001111010101010110
C 8 = 0010101010111111110000110011
D 8 = 1001111000111101010101011001
C 9 = 0101010101111111100001100110
D 9 = 0011110001111010101010110011
C 10 = 0101010111111110000110011001
D 10 = 1111000111101010101011001100
C 11 = 0101011111111000011001100101
D 11 = 1100011110101010101100110011
C 12 = 0101111111100001100110010101

D 12 = 0001111010101010110011001111
C 13 = 0111111110000110011001010101
D 13 = 0111101010101011001100111100
C 14 = 1111111000011001100101010101
D 14 = 1110101010101100110011110001
C 15 = 1111100001100110010101010111
D 15 = 1010101010110011001111000111
C 16 = 1111000011001100101010101111
D 16 = 0101010101100110011110001111
Agora montamos as chaves K n
, para 1

K 6 = 011000 111010 010100 111110 010100 000111 101100 101111
K 7 = 111011 001000 010010 110111 111101 100001 100010 111100
K 8 = 111101 111000 101000 111010 110000 010011 101111 111011
K 9 = 111000 001101 101111 101011 111011 011110 011110 000001
K 10 = 101100 011111 001101 000111 101110 100100 011001 001111
K 11 = 001000 010101 111111 010011 110111 101101 001110 000110
K 12 = 011101 010111 000111 110101 100101 000110 011111 101001
K 13 = 100101 111100 010111 010001 111110 101011 101001 000001
K 14 = 010111 110100 001110 110111 111100 101110 011100 111010
K 15 = 101111 111001 000110 001101 001111 010011 111100 001010
K 16 = 110010 110011 110110 001011 000011 100001 011111 110101
Em relação às subchaves é só. Agora vamos dar uma olhada na mensagem.
Passo 2: Codificar cada bloco de 64 bits de dados
Existe uma permutação inicial IP dos 64 bits de dados da mensagem M. Isto
rearranja os bits de acordo com a seguinte tabela, onde as entradas da tabela
mostram o novo arranjo de bits a partir da ordenação inicial. O 58º bit de M
torna-se o primeiro bit de IP. O 50º bit de M passa a ser o segundo bit de IP. O
7º bit de M será o último bit de IP.
IP
-----------------------------------------
58 50 42 34 26 18 10 2
60 52 44 36 28 20 12 4
62 54 46 38 30 22 14 6
64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1
59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5
63 55 47 39 31 23 15 7
-----------------------------------------
Exemplo: Aplicando a permutação inicial ao bloco de texto M citado
anteriormente obtemos
M = 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100
1101 1110 1111
IP = 1100 1100 0000 0000 1100 1100 1111 1111 1111 0000 1010 1010 1111
0000 1010 1010
Aqui, o 58º bit de M é "1" e se torna o primeiro bit de IP. O 50º bit de M também

é "1" e torna-se o segundo bit de IP. O 7º bit de M é "0", o qual se torna o último
bit de IP.
Em seguida dividimos o bloco permutado IP numa metade esquerda L 0
de 32
bits e numa metade direita R 0
de 32 bits.
Exemplo: Obtemos L 0
e R 0
de IP
L 0 = 1100 1100 0000 0000 1100 1100 1111 1111
R 0 = 1111 0000 1010 1010 1111 0000 1010 1010
Agora prosseguimos com 16 iterações, para 1

32 1 2 3 4 5
4 5 6 7 8 9
8 9 10 11 12 13
12 13 14 15 16 17
16 17 18 19 20 21
20 21 22 23 24 25
24 25 26 27 28 29
28 29 30 31 32 1
----------------------------------
Portanto, os primeiros três bits de E(R n-1
) são os bits das posições 32, 1 e 2 de
R n-1
, enquanto que os dois últimos bits de E(R n-1
) são os bits da posição 32 e 1.
Exemplo: Calculamos E(R 0
) de R 0
da seguinte maneira:
R 0 = 1111 0000 1010 1010 1111 0000 1010 1010
E(R 0 ) = 011110 100001 010101 010101 011110 100001 010101 010101
(Note que cada bloco de 4 bits originais foi expandido para um bloco de 6 bits de
saída).
A seguir, no cálculo de f, fazemos um XOR na saída E(R n-1
) com a chave K n
. O
motivo de se utilizar o XOR lógico é porque este é reversível. Se A xor B = C,
então A xor C = B e B xor C = A. A reversibilidade é importante para podermos
reverter o processo quando quisermos decifrar a mensagem cifrada.
Exemplo: Para K 1
, E(R 0
), temos
K n + E(R n-1 )
K 1 = 000110 110000 001011 101111 111111 000111 000001 110010
E(R 0 ) = 011110 100001 010101 010101 011110 100001 010101 010101
K 1 +E(R 0 ) = 011000 010001 011110 111010 100001 100110 010100 100111
Ainda não terminamos o cálculo da função f. Até este ponto, expandimos R n-1
de
32 para 48 bits, usando a tabela de seleção E, e XORamos o resultado com a
chave K n
. Com este processo obtivemos 48 bits ou oito grupos de 6 bits. Agora
fazemos uma coisa meio estranha com cada grupo de seis bits: usamo-os como
endereços em tabelas denominadas "S boxes", ou "caixas S". Cada grupo de seis
bits nos dará um endereço numa caixa S diferente. Um número de 4 bits estará
localizado neste endereço. Este número de 4 bits irá substituir os 6 bits originais.
O principal resultado é que os oito grupos de 6 bits são transformados em oito
grupos de 4 bits (as saídas de 4 bits das caixas S) num total de 32 bits.
Escrevemos o resultado anterior, que tem 48 bits, na forma:

K n
+ E(R n-1
) = B1B2B3B4B5B6B7B8
onde cada B i
é um grupo de seis bits. Agora calculamos
S 1
(B 1
)S 2
(B 2
)S 3
(B 3
)S 4
(B 4
)S 5
(B 5
)S 6
(B 6
)S 7
(B 7
)S 8
(B 8
)
onde S i
(B i
) se refere à iésima saída da caixa S.
Repetindo, cada uma das funções S 1
, S 2
, ..., S 8
, pega um bloco de 6 bits como
entrada e devolve um bloco de 4 bits como saída. A tabela para determinar S 1
é
mostrada e explicada abaixo:
Função S1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
1 | 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
2 | 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
3 | 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
Se S 1
é a função definida nesta tabela e B é um bloco de 6 bits, então S 1
(B) é
determinada da seguinte maneira: O primeiro e o último bit de B representam
um número na base 2 com valor decimal entre 0 e 3 (ou binário 00 a 11). Que
este número seja i. Os 4 bits centrais de B representam um número na base 2
com valor decimal entre 0 e 15 (ou binário de 0000 a 1111). Que este número
seja j. Procure o número na tabela localizado na j-ésima coluna e na i-ésima
linha. É um número que varia de 0 a 15 e é unicamente representado por um
bloco de 4 bits. Este bloco é a saída S 1
(B) de S 1
para a entrada B. Por exemplo,
para o bloco de entrada B = 011011, o primeiro bit é "0" e o último é "1",
indicando a linha 01. Os quatro bits centrais são "1101". Este é o equivalente
binário do decimal 13, de modo que a coluna será a de número 13. Na linha 1,
coluna 13, aparece 5. Isto determina a saída; 5 é o binário 0101, de modo que a
saída é 0101. Portanto, S 1
(011011) = 0101.
As tabelas definindo as funções S 2
, ..., S 8
são as seguintes:
Função S2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
1 | 3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
2 | 0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
3 | 13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
Função S3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
1 | 13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
2 | 13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
3 | 1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12

Função S4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
1 | 13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
2 | 10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
3 | 3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
Função S5
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
1 | 14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
2 | 4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
3 | 11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
Função S6
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
1 | 10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
2 | 9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
3 | 4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
Função S7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
1 | 13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
2 | 1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
3 | 6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
Função S8
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
| --------------------------------------------------------------
0 | 13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
1 | 1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
2 | 7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
3 | 2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
Exemplo: Para a primeira rodada, obtemos como saída das oito caixas S:
K 1
+ E(R 0
) = 011000 010001 011110 111010 100001 100110 010100 100111
S 1
(B 1
)S 2
(B 2
)S 3
(B 3
)S 4
(B 4
)S 5
(B 5
)S 6
(B 6
)S 7
(B 7
)S 8
(B 8
) = 0101 1100 1000 0010
1011 0101 1001 0111
O estágio final do cálculo de f é fazer uma permutação P da saída da caixa S
para obter o valor final de f:
f = P(S 1
(B 1
)S 2
(B 2
)...S 8
(B 8
))

A permutação P é definida pela tabela a seguir. P devolve uma saída de 32 bits a
partir de uma entrada de 32 bits permutando os bits do bloco de entrada.
Exemplo: Da saída das oito caixas S
P
------------------
16 7 20 21
29 12 28 17
1 15 23 26
5 18 31 10
2 8 24 14
32 27 3 9
19 13 30 6
22 11 4 25
------------------
S 1
(B 1
)S 2
(B 2
)S 3
(B 3
)S 4
(B 4
)S 5
(B 5
)S 6
(B 6
)S 7
(B 7
)S 8
(B 8
) = 0101 1100 1000 0010
1011 0101 1001 0111
obtemos
f = 0010 0011 0100 1010 1010 1001 1011 1011
Agora possuimos todos os elementos necessários para calcular R 1
, ou seja, R 1
=
L 0
+ f(R 0
,K 1
)
L 0 = 1100 1100 0000 0000 1100 1100 1111 1111
f(R 0 , K 1 ) + 0010 0011 0100 1010 1010 1001 1011 1011
R 1 = 1110 1111 0100 1010 0110 0101 0100 0100
Na próxima rodada obteremos L 2
= R 1
, que é o sub-bloco que acabamos de
calcular, e depois precisamos calcular R 2
= L 1
+ f(R 1
, K 2
) e assim
sucessivamente por 16 rodadas. No final da décima sexta rodada temos os subblocos
L 16
e R 16
. Invertemos então a ordem dos dois sub-blocos num bloco de 64
bits, ou seja, R 16
L 16
, e aplicamos a permutação final IP -1 definida na seguinte
tabela:
IP -1
---------------------------------------------
40 8 48 16 56 24 64 32
39 7 47 15 55 23 63 31
38 6 46 14 54 22 62 30
37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28
35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26
33 1 41 9 49 17 57 25
---------------------------------------------

É isto aí, a saída do algoritmo possui o bit 40 do bloco de pre-saída como seu
primeiro bit, bit 8 como seu segundo bit, e assim sucessivamente, até o bit 25 do
bloco de pre-saída como seu último bit.
Exemplo: Se processarmos todos os 16 blocos usando o método definido
previamente, obteremos, na 16ª rodada
L 16
= 0100 0011 0100 0010 0011 0010 0011 0100
R 16
= 0000 1010 0100 1100 1101 1001 1001 0101
Invertendo a ordem destes dois blocos e aplicando a permutação final em
R 16
L 16
= 00001010 01001100 11011001 10010101 01000011 01000010
00110010 00110100
IP -1 = 10000101 11101000 00010011 01010100 00001111 00001010 10110100
00000101
o que, em formato hexadecimal, é 85E813540F0AB405.
Portanto, a forma cifrada de M = 0123456789ABCDEF é C =
85E813540F0AB405.
Decifrar é simplesmente o inverso de cifrar, seguindo os mesmos passos acima
descritos porém invertendo a ordem das sub-chaves aplicadas.
MODOS DE OPERAÇÃO DO DES
O algoritmo DES transforma um bloco de mensagem M de 64 bits num bloco
cifrado C. Se cada bloco de 64 bits for cifrado individualmente, então o modo de
encriptação é denominado Electronic Code Book (ECB). Existem outros dois
modos de cifragem DES, os modos Chain Block Coding (CBC) e Cipher Feedback
(CFB), os quais tornam cada bloco cifrado dependente de todos os outros blocos
de mensagem anteriores através de uma operação inicial de XOR.
QUEBRANDO O DES
Antes que o DES fosse adotado como padrão nacional (estadunidense), durante o
período em que o NBS estava solicitando comentários sobre o algoritmo
proposto, os criadores da criptografia de chave pública, Martin Hellman e
Whitfield Diffie, registraram algumas objeções quanto ao uso do DES como
algoritmo de encriptação. Hellman escreveu: "Whit Diffie e eu ficamos
preocupados com o fato de que o padrão de encriptação de dados proposto,
enquanto provavelmente seguro em relação a assaltos comerciais, pode ser
extremamente vulnerável a ataques efetuados por uma organização de
inteligência" (carta ao NBS, 22 de Outubro de 1975).
Diffie e Hellman planejaram então um ataque de "força bruta" ao DES ("força
bruta" significa aplicar sequencialmente as 2 56 chaves possíveis até encontrar a
chave correta que decifra a mensagem cifrada). Propuseram o uso específico de
"computadores paralelos usando um milhão de chips para testar um milhão de

chaves cada um" por segundo e estimaram o custo de uma máquina deste tipo
em US$ 20 milhões.
Um salto para 1998. Sob a direção de John Gilmore do EFF, uma equipe gastou
menos do que US$ 250.000 para construir uma máquina que analisou todo o
espaço de chaves de 56 bits do DES e precisou, em média, 4.5 dias para
completar a tarefa. Em 17 de Julho de 1998 eles anunciaram que haviam
quebrado uma chave de 56 bits em 46 horas. O computador, chamado de Deep
Crack, usa 27 placas, cada uma com 64 chips, e é capaz de testar 90 bilhões de
chaves por segundo.
Apesar disso, em 8 de Junho de 1998, Robert Litt, principal representante
procurador geral do Departamento de Justiça dos Estados Unidos, negou que
fosse possível o FBI quebrar o DES: "Deixe-me colocar o problema técnico no
contexto: foram precisos 14.000 computadores Pentium trabalhando durante
quatro meses para decifrar uma única mensagem... Não estamos falando apenas
do FBI e da NSA [precisando de um poder de processamento maciço], estamos
falando a respeito de cada departamento de polícia."
Respondeu o especialista em criptografia Bruce Schneier: "... o FBI ou é
incompetente ou está mentindo, ou ambos". Schneier continua: "A única solução
neste caso é pegar um algoritmo com uma chave maior; não existe silício
suficiente na galáxia ou tempo suficiente antes do sol se apagar para quebrar
com força bruta o triple-DES" (Crypto-Gram, Counterpane Systems, 15 de Agosto
de 1998).
TRIPLE-DES
O triple-DES é apenas o DES com duas chaves de 56 bits aplicadas. Dada uma
mensagem em texto claro, a primeira chave é usada para cifrar a mensagem em
DES. A segunda chave é usada para decifrar o DES da mensagem cifrada. Como
a segunda chave não é a correta para decifrar, esta decifração apenas embaralha
ainda mais os dados. A mensagem duplamente embaralhada é, então, cifrada
novamente com a primeira chave para se obter o criptograma final. Este
procedimento em três etapas é chamado de triple-DES ou triplo DES.
Triple-DES é apenas o DES efetuado três vezes com duas chaves usadas numa
determinada ordem. O triple-DES também pode ser feito usando-se três chaves
diferentes, ao invés de apenas duas. No primeiro caso, o espaço das chaves é de
2 112 , no segundo, é de 2 168 .
Cifras de fluxo
A grande maioria dos algoritmos criptográficos atuais são cifras de bloco. As
cifras de fluxo, que convertem o texto claro em texto cifrado bit a bit, ainda são
objeto de pesquisa e têm uma aplicação prática muito discreta. O motivo é que
as cifras de fluxo dependem de geradores randômicos de chaves que, apesar da
aparente simplicidade, são difíceis de implementar através de software ou de

hardware.
Um hash, também chamado de "digesto", é uma espécie de "assinatura" ou
"impressão digital" que representa o conteúdo de um fluxo de dados. Com certa
frequência os hashes são chamados de checksum, o que provoca alguma
confusão com os verdadeiros checksums, os quais têm aplicações e cálculos
totalmente diferentes. Um hash pode ser comparado com um selo de embalagem
que indica clara e inequivocamente se a embalagem já foi aberta ou violada.
Via única
Hashes não são cifragens, são digestos! As cifragens transformam os dados do
texto claro num criptograma e vice-versa, ou seja, é uma operação de duas
vias. Além disso, o tamanho do criptograma geralmente é igual ao comprimento
do texto claro. Hashes, por sua vez, transformam os dados do texto (claro ou
cifrado) num pequeno digesto, de tamanho fixo, numa operação de via única.
Uma operação de via única não tem volta, ou seja, não é possível obter o texto
claro a partir de um resultado hash.
Saída de comprimento fixo
Os hashes produzem "selos de segurança" de comprimento fixo, não importa o
comprimento do fluxo de dados ou do arquivo que representem. Qualquer
alteração efetuada no arquivo, por mínima que seja, altera substancialmente o
resultado hash. Isto ocorre porque, mesmo se apenas um dos bits do arquivo for
alterado, muitos bits do resultado serão afetados. Este comportamento é
conhecido como efeito avalanche.
O efeito avalanche fica bastante claro quando observamos o impacto da mudança
de apenas um bit no resultado hash. Para exemplificar, vamos usar os caracteres
ASCII "A" e "a". Note que apenas o sexto bit (contando da direita para a
esquerda e iniciando pelo bit zero) é diferente:
Caracter ASCII ASCII
(decimal) (binário)
----------------------------------
A 65 0100 0001
a 97 0110 0001
Usando o algoritmo MD5, o resultado hash obtido para os textos "Aldeia
NumaBoa" e "aldeia NumaBoa", cuja diferença reside num único bit, é
completamente diferente:
Aldeia NumaBoa
aldeia NumaBoa
3cdb658425ee484e4bff3d4583f6f851
9c1f41ef263026b0283676d63df21fd1
Transformando o valor hexadecimal do hash dos dois textos nos seus
correspondentes binários, o efeito avalanche fica evidente pois a alteração de
apenas um bit no texto ocasionou a alteração de 62 bits do resultado hash:
3cdb6584 0011 1100 1101 1011 0110 0101 1000 0100

9c1f41ef 1001 1100 0001 1111 0100 0001 1110 1111
x.x. .... xx.. .x.. ..x. .x.. .xx. x.xx
12 bits diferentes
25ee484e 0010 0101 1110 1110 0100 1000 0100 1110
263026b0 0010 0110 0011 0000 0010 0110 1011 0000
.... ..xx xx.x xxx. .xx. xxx. xxxx xxx. 20 bits diferentes
4bff3d45 0100 1011 1111 1111 0011 1101 0100 0101
283676d6 0010 1000 0011 0110 0111 0110 1101 0110
.xx. ..xx xx.. x..x .x.. x.xx x..x ..xx
83f6f851 1000 0011 1111 0110 1111 1000 0101 0001
3df21fd1 0011 1101 1111 0010 0001 1111 1101 0001
x.xx xxx. .... .x.. xxx. .xxx x... ....
16 bits diferentes
14 bits diferentes
Aplicações práticas do hash
Se os dados originais não podem ser recuperados a partir do hash gerado pelos
mesmos, então para que servem os hashes? Apesar de parecer contraditório, é
exatamente esta característica que possibilita o uso de algoritmos hash sempre
que uma autenticação ou uma validação seja necessária. Dentre as inúmeras
aplicações destacam-se as seguintes:
Integridade de arquivos
Qualquer tipo de arquivo, por exemplo um arquivo de texto ou um programa de
computador, é um fluxo de dados que produz um resultado hash único. Quando
um arquivo é disponibilizado para download, não existe a garantia de que o
arquivo baixado seja idêntico ao original. Basta que ocorra um pequeno
problema durante a transmissão que altere os dados recebidos para que a
"cópia" não seja perfeita. Uma das maneiras de poder verificar se o arquivo
baixado é idêntico ao disponibilizado é conhecer o hash do arquivo original. Após
o download é possível calcular o hash do arquivo baixado e, se os dois hashes
forem idênticos, a integridade da cópia é comprovada. É importante lembrar que
hashes parecidos ou "quase iguais" indicam sempre que os dados que os
produziram são diferentes, e nunca parecidos ou quase iguais!
Segurança de senhas
Guardar senhas em texto claro é dar chance para o azar. Se um arquivo de
senhas for roubado ou um banco de dados com registros de senhas for hackeado,
o estrago pode ser enorme. Como um hash não é reversível e, para serem
usadas, as senhas precisam ser conferidas, é muito mais prudente armazenar os
resultados hash das senhas do que as próprias senhas. O uso de uma senha
pressupõe que um usuário a digite. Tendo a senha como entrada, é fácil e rápido
calcular o resultado hash da senha fornecida e compará-lo com o valor
arquivado. Se forem idênticos, a senha confere, mostrando que o usuário
conhecia uma senha válida. Este procedimento reduz sensivelmente os riscos
porque o único momento em que a senha pode ser roubada é enquanto está

sendo digitada e antes de ser transformada em hash.
Assinaturas digitais
Para se obter uma assinatura digital válida são necessárias duas etapas. A
primeira é criar um hash do documento. Este hash identifica unicamente e
inequivocamente o documento do qual ele se originou. A seguir, o assinante
submete o hash a um método criptográfico usando sua chave privada. Como o
hash criptografado só pode ser recuperado usando a chave pública do assinante,
isto comprova a identidade da pessoa que assinou - é a chamada assinatura
digital - e como o hash recuperado identifica o documento, a assinatura está
associada unicamente a este documento.
Vulnerabilidades
Pelo que foi visto até agora, o cenário parece perfeito: usando métodos que
produzam hashes de 128 bits, o número de hashes possíveis atinge um valor
astronômico. São, nada mais, nada menos do que 2 128 = 3,4 x 10 38 possíveis.
Mais exatamente, as possibilidades somam
340.282.366.920.938.463.463.374.607.431.768.211.456 hashes de 128 bits
Apesar deste valor enorme, como o número de conjuntos de dados é
praticamente infinito, a possibilidade de que dois conjuntos de dados diferentes
produzam o mesmo hash não pode ser ignorada. Esta coincidência de resultados
é conhecida como colisão. Existem duas formas básicas de se diminuir a
ocorrência de colisões: aumentando o número de bits do resultado hash e
criando algoritmos que produzam hashes menos vulneráveis. Existem algumas
medidas que avaliam as vulnerabilidades. As principais são mostradas a seguir.
Resistência a colisões
A resistência a colisões mede a dificuldade de encontrar duas entradas que
produzam o mesmo resultado hash. O valor hash pode ser qualquer um, o
objetivo é encontrar duas entradas diferentes que forneçam um resultado
idêntico.
Se for possível obter o mesmo resultado hash para duas entradas diferentes, as
assinaturas digitais deixam de ser confiáveis. Imagine um "compromisso de
compra" que possa ser substituído por outro sem que o valor hash se modifique.
Se os documentos forem trocados por alguém com más intenções poderemos ter
surpresas bastante desagradáveis. Um dos ataques mais conhecidos para
encontrar colisões é o ataque do aniversário. Se você estiver interessado, leia o
texto Paradoxo do Aniversário que se encontra na Confraria do Segredo, em
Curiosidades.

Colisão: procura de dois textos que produzam um mesmo hash qualquer
Neste caso, a assinatura digital também não pode garantir a autenticidade do
documento. Pior do que isto, a assinatura digital coloca nossa anuência no
documento! Como já foi visto, a alteração de um simples bit costuma alterar
substancialmente o resultado hash. Vai aqui uma sugestão: antes de colocar a
sua assinatura digital, faça uma pequena alteração "cosmética" no documento
que será assinado. Basta adicionar um espaço ou retirar uma vírgula. Como os
dois documentos, o correto e o fraudulento, precisam ser preparados com
antecedência para produzirem o mesmo hash, pegamos o fraudador de calças
curtas se alterarmos o documento e, consequentemente, seu valor hash no
último instante
Resistência de pre-imagem
A resistência de pre-imagem mede a dificuldade de criar um conjunto de dados
que resulte num determinado valor hash, sem conhecer o texto que o originou.
Pre-imagem: criação de determinado valor hash sem conhecer o texto original
Se a resistência de pre-imagem for pequena, será mais fácil criar um texto
qualquer cujo hash seja igual a um conhecido. Imagine o caso das senhas. Se,
conhecendo o valor hash de uma delas, for possível criar uma senha qualquer
que resulte num hash idêntico, a segurança de um sistema que faça a
autenticação exclusivamente com hashes de senhas estará seriamente
comprometido. Mesmo digitando a senha "fabricada", o resultado será aceito.
Resistência de segunda pre-imagem
A resistência de segunda pre-imagem mede a dificuldade de criar um conjunto
de dados que resulte num determinado valor hash, conhecendo o texto que o
originou.

Segunda pre-imagem: criação de determinado valor hash conhecendo o texto
original
Assim como a resistência de pre-imagem, se a resistência de segunda preimagem
for baixa, a criação de um conjunto de dados que resulte num hash
conhecido torna-se mais fácil. É comum encontrarmos software para download
acompanhado de seus valores hash, portanto, é fácil obter a matéria prima que
pode ser fraudada. Se alguém com más intenções alterar o software, mas
conseguir preservar seu resultado hash, os usuários que fizerem o download do
"safadoware" não terão como identificar o software adulterado e potencialmente
perigoso!
As funções hash
Funções hash são funções que recebem dados de comprimento arbitrário,
comprimem estes dados e devolvem um número fixo de bits, o resultado hash. Se
uma função deste tipo satisfizer requisitos adicionais, ela pode ser usada em
aplicações criptográficas como, por exemplo, proteger a autenticidade de
mensagens enviadas através de canais inseguros. A idéia básica é que o
resultado hash forneça uma identidade única para uma mensagem e que a
proteção de uma pequena identidade é mais fácil de ser obtida do que a proteção
da mensagem como um todo.
Os códigos de autenticação de mensagens (MAC - message authentication codes)
têm relação com as funções hash. Estes também são funções que comprimem
uma entrada de comprimento arbitrário num número fixo de bits, mas o processo
depende de uma entrada secundária de comprimento fixo, a chave. É por este
motivo que os MACs também são chamados de funções hash com chave. Em
aplicações práticas, a chave que orienta os cálculos de um MAC precisa ser
mantida em segredo.
Funções hash criptográficas
Para uma função (sem chave) hash, o requisito para que o resultado hash sirva
como identidade única para uma mensagem é que seja impossível ou
impraticável encontrar pares de mensagens que colidam (isto é, mensagens que
produzam hashs iguais). Em algumas aplicações, no entanto, é suficiente que,
para cada resultado hash, seja impraticável encontrar a mensagem
correspondente; ou que, dada uma mensagem, seja impraticável encontrar outra

mensagem que produza o mesmo hash. De acordo com estas premissas, existem
duas definições informais para dois tipos diferentes de funções hash.
Um hash de via única (one way hash) é uma função que satisfaz as seguintes
condições:
1. A entrada X pode ter um comprimento arbitrário e o resultado h(X) possui
um número fixo de n bits.
2. Dados h e um input X, o cálculo de h(X) precisa ser 'fácil'.
3. A função precisa ser de via única, ou seja, para um dado Y na imagem de h,
seja 'difícil' achar uma mensagem X de modo que h(X) = Y (resistência de
preimagem) e, dados X e h(X), seja 'difícil' encontrar uma mensagem X'
diferente de X onde h(X') = h(X) (resistência da segunda preimagem).
Uma função hash resistente a colisões é uma função h que satisfaz as
seguintes condições:
1. A entrada X pode ter um comprimento arbitrário e o resultado h(X) possui
um número fixo de n bits.
2. Dados h e um input X, o cálculo de h(X) é 'fácil'.
3. A função é de via única, isto é, é resistente à preimagem e à segunda
preimagem.
4. A função precisa ser resistente a colisões: isto significa que é 'difícil'
encontrar duas mensagens distintas que produzam o mesmo resultado
hash.
Num código de autenticação de mensagem MAC, o cálculo (portanto, o resultado
MAC) depende de uma entrada secundária, a chave secreta. O propósito
principal é que o adversário, sem conhecer esta chave, não seja capaz de forjar o
resultado MAC de qualquer mensagem, mesmo se muitas mensagens e seus
MACs correspondentes forem conhecidos. Um código de autenticação de
mensagem ou MAC é uma função h que satisfaz as seguintes condições:
1. A entrada X pode ter um comprimento arbitrário e o resultado h(K,X)
possui um comprimento fixo de n bits. A função possui como entrada
secundária uma chave K com um número fixo de k bits.
2. Dados h, K e uma entrada X, o cálculo de h(K,X) precisa ser 'fácil'.
3. Dada uma mensagem X (mas com K desconhecido), o cálculo de h(K,X)
precisa ser 'difícil'.
Aplicações de funções hash e de MACs
Funções hash e MACs têm as mais diversas aplicações. Entre outras, podem ser
utilizadas na autenticação de mensagens, assinaturas digitais, datação
(timestamping) de documentos e sistemas de senhas.
Autenticação de mensagens com hash
O problema da proteção da autenticidade de informações tem dois aspectos: a
integridade dos dados e a autenticação da origem dos dados. A integridade dos

dados é a garantia de que os dados não tenham sido alterados, sem autorização,
desde o momento em que foram criados, transmitidos ou armazenados por uma
fonte autorizada. Já a autenticação da origem dos dados é um tipo de
autenticação que garante a fonte (origem) dos dados. Por definição, a
autenticação da origem dos dados inclui a integridade dos dados (informação
que tenha sido modificada com autorização tem uma nova fonte).
Digamos que um remetente queira enviar uma mensagem para determinado
destinatário através de um canal de comunicação inseguro. Para garantir que o
destinatário esteja recebendo a mensagem da fonte correta e que a mensagem
não foi modificada durante a transmissão, o remetente cria um hash da
mensagem e transmite esta pequena sequência de bits através de um canal
autêntico. Um canal autêntico não é necessariamente um canal seguro, ele pode
ser interceptado e o segredo não é garantido. O telefone, por exemplo, é um
canal deste tipo onde a autenticação é feita através do reconhecimento da voz.
Depois disso, o remetente pode enviar a mensagem através de um canal
inseguro. O destinatário, por sua vez, usando o mesmo algoritmo hash, cria um
resultado hash para a mensagem recebida e o compara com o hash que lhe foi
enviado. Se os dois hashes coincidirem, o destinatário tem a certeza de que a
mensagem não foi alterada durante o trajeto.
Autenticação hash combinada com criptografia
Uma outra forma de enviar mensagens autenticadas é adicionar o hash à
mensagem clara e cifrar o conjunto com algum método criptográfico cuja chave
seja conhecida tanto pelo remetente quanto pelo destinatário. O destinatário
decifra o conjunto, obtendo o hash e a mensagem. Este método precisa de um
canal autêntico e com privacidade para poder transmitir a chave do método
criptográfico.
Autenticação de mensagens com MAC
Neste caso, o remetente cria um resultado MAC usando uma chave. Depois,
adiciona este MAC à mensagem e a envia através de um canal inseguro. Também
aqui existe a necessidade de usar um canal autêntico e com privacidade para
transmitir a chave do algoritmo MAC.
Otimização de assinaturas digitais
Esquemas de assinatura digital são um tipo diferente de primitivo criptográfico.
São usados para a proteção da autenticidade, só que, adicionalmente, oferecem o
serviço de não repúdio. Isto significa que é impossível para um remetente negar
a autoria de uma mensagem autenticada. Assinaturas digitais baseiam-se em
criptografia de chave pública.
Por exemplo, o usuário A possui o par de chaves SA e PA, onde SA é a chave
privada (secreta) e PA é a chave pública. Inicialmente ele comprime sua
mensagem M com a função hash h. O resultado hash h(M) é usado como entrada
do algoritmo de assinatura. Este algoritmo depende da chave privada SA e

calcula um valor assinatura SA
( h(M) ), que pode ser expresso como s(M). O
usuário associa a assinatura s(M) à mensagem M e envia o conjunto através de
um canal inseguro. O destinatário separa a assinatura s(M) e a usa como entrada
do algoritmo de verificação. Este algoritmo depende da chave pública PA e
calcula o valor ver PA
( s(M) ). A assinatura e o algoritmo de verificação são
projetados de tal forma que, se o par de chaves PA e SA estiver correto, o
resultado hash h(M) corresponde à mensagem M. O destinatário calcula o hash
da mensagem, compara os dois hashes e, se coincidirem, tanto a assinatura,
quanto a mensagem, são autênticas.
Aplicações como funções de via única (one-way)
Funções de via única são parecidas com as funções hash de via única - a
diferença é que a entrada tem um comprimento fixo. Estas funções podem ser
obtidas de vários modos, por exemplo, a partir de funções hash criptográficas ou
de cifras de bloco.
Nos sistemas de identificação baseados em senhas, ao invés de armazenar a
senha, armazena-se para cada usuário o resultado de uma função de via única.
Para verificar se uma senha informada pelo usuário (identificação) está correta,
o sistema aplica a função de via única na senha fornecida e compara o resultado
obtido com o resultado armazenado.
Uma outra aplicação, também muito útil para identificações, é a chamada
confirmação de conhecimento. Neste caso, as partes provam que conhecem um
segredo S sem revelar o segredo. Para isto, basta cada um enviar para o outro
uma função de via única de S.
Funções de via única também podem ser aplicadas para calcular uma sequência
de chaves que são usadas para proteger sessões de comunicação sucessivas.
Começando com uma chave mestra K0, a chave da primeira sessão é calculada
como K1 = f(K0), a da segunda sessão como K2 = f(K1) e assim sucessivamente.
Um exemplo típico é a derivação de chaves usada em sistemas de pagamento em
terminais de pontos de venda onde a divulgação de uma chave atualmente ativa
não pode comprometer a segurança de transações anteriores. Esta propriedade é
chamada de segurança futura. Outro exemplo é a geração de senhas num
sistema de senhas de uso único. Neste caso, cria-se uma sequência de senhas
que serão usadas na ordem inversa da criação. Aplicando-se a função de via
única a uma das senhas, o resultado precisa coincidir com a senha anterior. A
propriedade de via única impede que um adversário, que conheça a senha atual,
possa calcular qualquer uma das senhas futuras.
Datação digital
A datação digital é um serviço que fornece uma autenticação temporal. Em
particular, uma datação digital fornece provas da existência de certos
fragmentos de informação antes da data e da hora indicada na datação. Isto tem
aplicação na proteção de direitos de propriedade intelectual e em procedimentos
seguros de auditoria. Por exemplo:

• Um pesquisador que queira provar um "primeiro a inventar" ou "primeiro a
informar".
• Uma empresa que queira provar a integridade de seus registros
eletrônicos, mostrando que estes não foram manipulados ou tiveram suas
datas alteradas.
A datação também é vital para serviços de não-repúdio confiáveis. Em
documentos assinados que tenham um ciclo de validade longo, várias
verificações podem ser necessárias. Entretanto, o ciclo de validade de
assinaturas digitais é limitado por várias razões:
• A chave privada da assinatura pode se tornar comprometida.
• O certificado que prova o elo entre o usuário e sua chave pública tem prazo
de validade.
• O algoritmo criptográfico usado no esquema da assinatura pode ser
quebrado.
Estes problema pode ser contornado se um serviço seguro de datação for
utilizado. Um usuário que cria uma assinatura num documento e requisita uma
datação da informação assinada prova que a assinatura foi gerada antes da
marca temporal indicada na datação, ou seja, antes de qualquer incidente
eventualmente venha a invalidar a sua assinatura.
A segurança das funções hash
Em termos práticos, a segurança das funções criptográficas hash pode ser
medida apenas em relação à sua resistência a ataques. Normalmente os
adversários procuram uma preimagem, segunda preimagem ou colisão em
funções hash ou produzem dados forjados para um MAC.
Ataque randômico
Este é o tipo de ataque mais óbvio. O adversário simplesmente seleciona uma
entrada ao acaso e espera pelo resultado hash. Dado o hash de uma mensagem
h(M), o adversário tenta criar um outro documento, M', de modo que h(M) =
h(M'). Se a função hash possuir um comportamento 'randômico', sua
probabilidade de sucesso é considerável (cerca de 50%). Na prática, o ataque
pode ser efetuado em paralelo, usando a computação distribuída num grande
número de máquinas com uma chance não desprezível de se obter uma
preimagem ou uma segunda preimagem.
Ataque do aniversário
Este ataque se baseia na idéia de que num grupo de 23 pessoas a probabilidade
de que, pelo menos, duas pessoas façam aniversário no mesmo dia é maior do
que 50%. Intutitivamente, a impressão geral é que o grupo de pessoas deveria
ser muito maior para que isto acontecesse, motivo pelo qual esta constatação é
chamada de paradoxo do aniversário.
Este tipo de ataque é mais sutil do que o anterior e baseia-se num problema

padrão da estatística. Quantas pessoas precisam estar numa sala para que a
chance de uma delas fazer aniversário no mesmo dia que você seja maior do que
50%? A resposta é 253. Agora, se a pergunta for "Quantas pessoas precisam
estar numa sala para que a chance de duas delas comemorarem aniversário no
mesmo dia seja maior do que 50%?", o resultado é surpreendente baixo. Com
apenas 23 pessoas na sala, a chance de que duas façam aniversário no mesmo
dia é maior do que 50%. É que, apesar do número baixo de pessoas, existem
mais de 500 pares diferentes de pessoas na sala. Caso você tenha interesse em
saber como os cálculos são efetuados, visite a seção de curiosidades da Confraria
do Segredo.
Achar alguém com um aniversário específico é análogo ao primeiro ataque;
achar duas pessoas com o mesmo aniversário randômico é análogo a este
segundo ataque, também conhecido como ataque do aniversário.
Imagine que determinada função hash siga todas as propriedades citadas acima
e que a melhor forma de atacá-la seja através da força bruta. Se esta função
criar um resultado hash de m bits, encontrar uma mensagem que resulte no hash
procurado requer 2 m mensagens randômicas. Agora, encontrar duas mensagens
que produzam o mesmo hash requer apenas 2 m/2 mensagens randômicas. Um
computador que seja capaz de processar um milhão de mensagens por segundo
levaria 600.000 anos para encontrar uma segunda mensagem para determinado
hash de 64 bits. A mesma máquina pode achar um par de mensagens que
resultam num hash de 64 bits igual em cerca de uma hora!
Resta saber como um ataque do aniversário pode ser usado para fins escusos.
Imagine que um safado prepare dois contratos, um favorável para o bonzinho e
outro no qual o bonzinho transfere todos os seus bens para o safado. De posse
destes dois documentos, o safado faz várias pequenas alterações nos dois
documentos: troca espaço por espaço-backspace-espaço, insere um ou dois
espaços antes das quebras de linha, etc. Introduzindo (ou não) estas pequenas
alterações em cada uma de 32 linhas de texto, o safado consegue gerar 2 32
documentos diferentes. Depois disto, o safado compara os hashes dos
documentos até encontrar um par, tarefa perfeitamente possível de ser realizada
se o resultado hash tiver apenas 64 bits. Encontrando estes dois documentos, um
do contrato bom e outro do contrato alterado, o safado pede para o bonzinho
assinar o documento bom usando um protocolo no qual ele apenas assina o valor
hash. Quando lhe convier, o safado troca os contratos e não há cristão que possa
provar que não seja o documento original assinado pelo bonzinho
Este cenário não tem nada de surreal, é perfeitamente possível de ocorrer. E
tudo por conta do ataque do aniversário aplicado a funções hash de 64 bits. Por
este motivo, a maioria das funções produzem hashes de pelo menos 128 bits. Isto
força qualquer atacante a utilizar, no mínimo, 2 64 documentos randômicos para
encontrar dois cujos hashes tenham o mesmo valor. Mas como é possível obter
hashes com mais de 64 bits? Dentre os métodos propostos, o seguinte é bastante
eficiente:
1. Gerar o valor hash de uma mensagem, usando uma função hash de via
única.

2. Concatenar a mensagem e o hash obtido.
3. Gerar um novo hash da mensagem com o hash concatenado.
4. Criar um valor hash maior que consiste da valor hash gerado na etapa 1
concatenado ao hash gerado na etapa 3.
5. Repetir as etapas 1 a 3 o quanto se desejar.
As funções hash mais conhecidas
• SNEFRU é uma função hash de via única desenvolvida por Ralph Merkle
que cria resultados hash de 128 ou de 256 bits.
• N-HASH é um algoritmo inventado por pesquisadores da Nippon Telephone
and Telegraph, os mesmos que inventaram o FEAL. Usa blocos de 128 bits
de mesnagem e produz um resultado hash também de 128 bits.
• MD4, onde MD vem de message digest, é uma função hash de via única
desenvolvida por Ron Rivest que também produz um valor hash de 128
bits.
• MD5 é uma versão melhorada do MD4. Também de Ron Rivest, produz um
resultado hash de 128 bits.
• SHA, o Secure Hash Algorithm, foi desencolvido pelo NIST e pela NSA.
Produz um hash de 160 bits, também chamado de message digest.
• RIPE-MD foi desenvolvido para o projeto RACE da Comunidade Européia.
Seu algoritmo é uma variação do MD4.
• HAVAL é uma função hash de via única de tamanho variável inventada por
Yulian Zheng, Josef Pieprzyk e Jennifer Seberry. É uma modificação do
MD5.
SHA-1
O SHA-1 (Secure Hash Algorithm - Algoritmo Hash Seguro) foi aprovado pelo
governo dos EUA em 1995 para ser usado por todos os departamentos e
agências federais na autenticação de documentos digitais.
O que é o SHA-1
O SHA-1 é um padrão usado para calcular a representação condensada de uma
mensagem ou arquivo de dados. Partindo de uma mensagem menor do que 2 64
bits, o SHA-1 produz uma saída de 160 bits chamada de digesto da mensagem.
Este digesto pode ser a entrada para o DSA (Digital Signature Algorithm -
Algoritmo de Assinatura Digital), o qual gera ou faz a verificação da assinatura
da mensagem. Criar uma assinatura para o digesto, ao invés de criar uma para a
mensagem, costuma melhorar a eficiência do processo porque o digesto da
mensagem habitualmente é muito menor do que a mensagem. Tanto o
verificador, quanto o criador, precisam usar o mesmo algoritmo hash para gerar
e verificar uma assinatura digital.

O SHA-1 foi considerado seguro porque é impraticável encontrar uma mensagem
que corresponda a um determinado digesto ou encontrar duas mensagens
diferentes que produzam o mesmo digesto. Qualquer alteração feita numa
mensagem em trânsito, com grande probabilidade dará como resultado um
digesto diferente e a assinatura não poderá ser confirmada. O SHA-1 é uma
revisão técnica do SHA - foi adicionada uma operação de deslocamento circular
para a esquerda para aumentar a segurança oferecida por este padrão. O SHA-1
foi baseado em princípios semelhantes aos usados no algoritmo MD4, criado pelo
professor do MIT, Ronald L. Rivest.
Aplicações do SHA-1
O SHA-1 pode ser aplicado, juntamente com o DSA, em e-mails, transferências
eletrônicas de fundos, distribuição de software, armazenamento de dados e
outras aplicações que requeiram garantia de integridade de dados e
autenticação da origem dos dados. O SHA-1 também pode ser utilizado sempre
que for necessário gerar uma versão condensada de uma mensagem.
O MD5 foi desenvolvido por Ron Rivest em 1991. É basicamente o MD4 com um
"cinto de segurança" - os cálculos são um pouco mais lentos mas, em
compensação, é muito mais seguro.
Da mesma forma que outras funções hash, o MD5 é usado em assinaturas
digitais onde um texto longo precisa ser "comprimido" de forma segura antes de
ser cifrado com uma chave privada (secreta) por um criptossistema de chave
pública. Foi projetado para máquinas de 32 bits, podendo ser facilmente
programado de forma compacta. O autor colocou o algoritmo no domínio público
em abril de 1992.
Como o texto sobre a função hash MD4 é bastante minucioso e o MD5 é muito
parecido, não há a necessidade de entrar em muitos detalhes. Caso você tenha
dúvidas, complemente a leitura com o texto MD4.
Descrição do algoritmo MD5
O entrada do MD5 é um fluxo de dados (mensagem) que pode ter um número
arbitrário de bits, representado por b, um número inteiro positivo que varia de
zero até o infinito. Para obter o digesto da mensagem, seus bits, representados
por m0, m1, ..., m{b-1}, onde b = número de bits da mensagem, são submetidos
a diversas operações. Este processo é dividido em cinco etapas ou passos.
Base64 *

Base64 é um sistema numérico posicional cuja base é 64 (da mesma forma que o
sistema decimal é um sistema posicional de base 10). É a maior potência de base
2 que pode ser representada usando-se apenas caracteres ASCII. Devido a esta
característica, a Base64 é usada, entre outras coisas, como codificação de
transferência de e-mails. Todas as variações mais conhecidas pelo nome de
Base64 usam caracteres de A a Z, a-z e 0-9 (nesta ordem) para os primeiros 62
dígitos, mas os símbolos usados para os dois últimos variam consideravelmente
de acordo com o sistema. Vários outros métodos de codificação, como o
UUEncode e as versões mais atuais do BinHex, usam um conjunto diferente de
64 caracteres para representar 6 dígitos binários - só que estes métodos nunca
são chamados de Base64.
O formato MIME
O formato MIME talvez seja o mais conhecido dos Base64. É um esquema de
codificação que transforma binários em texto, ou seja, transforma uma sequência
qualquer de bytes numa sequência de caracteres ASCII que podem ser
impressos. O MIME foi projetado para codificar a transferência de conteúdo de
e-mails através da Internet. Os únicos caracteres utilizados são os do alfabeto
latino maiúsculo e minúsculo (A-Z e a-z), os numerais (0-9) e os símbolos + e /.
Além disso, o símbolo = é um sufixo especial.
Como transformar binários em MIME
A sequência MIME é:
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
Digamos que se queira "mimeficar" SOL. Neste caso, procura-se o valor ASCII de
cada um dos caracteres, transforma-se estes valores em valores binários, tomase
os valores dos bits seis a seis e transforma-se estes valores novamente em
valores ASCII. Acompanhe na tabela abaixo:
Conteúdo S O L
ASCII (bytes) 83 79 76
Binário 0 1 0 1 0 0 1 1 0 1 0 0 1 1 1 1 0 1 0 0 1 1 0 0
Índice 20 52 61 12
Sabendo que,
na Base64, as
letras A-Z
correspondem
às posições de
0 a 25, as
Código Base64 U 0 9 M
letras a-z ficam nas posições 26 a 51 e que os dígitos 0-9 ocupam as posições de
52 a 61, fica fácil deduzir que o valor 20 corresponde à letra U, o valor 52
corresponde a zero e assim por diante. Neste caso, o correspondente Base64 de
SOL é U09M. Também fica fácil perceber que a codificação MIME é maior do
que o texto original porque, para cada três caracteres originais obtemos quatro
caracteres MIME.
Neste exemplo existem exatos 3 bytes. Nos casos em que o texto original é
composto por um número de bytes que não seja múltiplo de 3, usa-se a seguinte
regra:

número de bytes / 3 dá resto 2 -> adiciona-se o sinal = no final
número de bytes / 3 dá resto 1 -> adiciona-se dois sinais == no final
Introdução aos dispositivos criptográficos
Antes de existir uma mensagem secreta é necessário que exista uma mensagem
clara. A mensagem clara pode ser escondida de tantas formas diferentes quantas
forem criadas pela imaginação humana. Para isto podem ser usados artifícios
que envolvam sons, imagens, símbolos, sinais ou qualquer outra coisa que possa
ser percebida pelos sentidos. Se quisermos, até o gosto de uma refeição ou o
cheiro de um perfume pode ser usado para transmitir uma mensagem secreta.
O fator primordial, analisando a criptologia por este aspecto, são os CINCO
SENTIDOS: visão, audição, tato, olfato e paladar (o sexto sentido deixamos para
a criptanálise ). Todos eles podem ser receptores de mensagens secretas. As
máquinas e os dispositivos podem ser utilizados quando um dos sentidos falha ou
quando quisermos facilitar a percepção de mensagens secretas. Esta é uma das
suas aplicações.
Você deve se lembrar do caso do gás Sarin no metrô de Tóquio. Não que o gás
tenha sido uma mensagem secreta... era secreto porque era invisível! O olfato
humano não detecta o Sarin, ou seja, não recebe a mensagem de perigo. O
"dispositivo" usado pela equipe de socorro foi algo insólito: canários. Utilizaram
a extrema sensibilidade deste pássaro como um detector do gás. Foi muito
estranho ver como o pessoal do socorro entrava nas estações subterrâneas
carregando gaiolas, só que, se o pássaro tivesse um troço... o socorrista voltava
correndo para o ar livre!
Para que um receptor possa receber uma mensagem, a ação de um transmissor
é obrigatória, pois é o transmissor que vai tentar alertar ou fornecer informações
a um dos cinco sentidos do receptor. O agente humano pode usar a fala e os
gestos ou pode fazer uso de máquinas e dispositivos que facilitem e/ou melhorem
a transmissão. Pode-se simplesmente falar em código, mas, para vencer a
distância, também podemos falar em código pelo telefone. Pode-se batucar uma
mensagem secreta ou então usar o telégrafo. Podemos entregar bits gravados
num disquete ou enviá-los pela Internet.
Para que a mensagem secreta enviada pelo transmissor possa chegar ao receptor
é preciso colocá-la num substrato qualquer e escolher um meio de transporte.
Se eu falar algumas palavras em código para um ouvinte-receptor que esteja ao
meu lado, a mensagem é constituída por ondas sonoras (o substrato) que se
propagam pelo ar (o meio)... e depois se perdem. Se eu fizer alguns gestos para
um receptor que esteja me vendo de longe, a mensagem é constituída pelas
"figuras" no espaço que os gestos (o substrato) representam. Mas também é
possível desenhar (meio) mensagens em pedras (substrato), escrevê-las (meio)
em papel (substrato) ou gravá-las (meio) em fitas ou discos magnéticos (meio),
todos processos diferentes, mas que funcionam perfeitamente.
E onde entram os dispositivos criptográficos? São úteis sempre que se queira
agilizar, diminuir a ocorrência de erros e facilitar ou automatizar qualquer

processo criptográfico, seja na elaboração, na transmissão, na recepção ou na
decifração.
OS DISPOSITIVOS MAIS ANTIGOS
O uso de dispositivos ou máquinas criptográficas existe desde a Antiguidade. O
mais antigo dispositivo de criptografia talvez seja o Bastão de Licurgo, uma
"máquina" de criptografia datada de 487 a.C. e descrita nas transposições. Outro
artefato muito interessante, datado de 200 a.C. é o telégrafo ótico de Políbio,
cuja descrição você encontra nas substituições tomográficas.
AS MÁQUINAS DA RENASCENÇA
Foi apenas na Renascença, a partir de 1300, que começaram a surgir os
primeiros dispositivos criptográficos de importância. Os primeiros foram os
discos de cifragem, inventados nesta época. Como exemplo pode-se citar o Disco
de Alberti (substituições) e a Grelha de Cardano (esteganografia).
AS MÁQUINAS RECENTES
A sofisticação dos dispositivos criptográficos foi aumentando a medida que a
construção de máquinas em geral, o descobrimento de novos materiais e a
engenharia foram evoluindo. Métodos criptográficos mais elaborados também
acabaram gerando a necessidade de máquinas auxiliares, desde as menores e
mais simples até engenhosos "dinossauros" mecânicos. Existem alguns exemplos
muito interessantes que são descritos nesta seção de dispositivos criptográficos:
• Régua de Saint-Cyr
• Cilindros Cifrantes
• O princípio dos rotores
• Máquina das Diferenças
A máquina das diferenças foi inventada por Charles Babbage e foi incluída nesta
lista porque a considero a tataravó do computador
AS MÁQUINAS E DISPOSITIVOS ATUAIS
Nem é preciso dizer que o principal dispositivo da atualidade é o computador.
Mas não é o único e muito menos o primeiro. Nesta mesma seção são referidos
alguns exemplos.
A Régua de Saint-Cyr
Este instrumento deve seu nome à academia militar francesa situada na cidade
de Saint-Cyr onde, entre 1880 e o início do século XX, serviu para instruir
estudantes de criptologia. Foi o holandês Auguste Kerckhoff, figura de destaque

na criptologia, quem batizou esta régua com o nome de Saint-Cyr.
O instrumento, parecido com as antigas réguas de cálculo, é relativamente
simples. É composto por uma tira longa de papel ou cartolina, denominada
"estator" ou parte fixa, a qual contém um alfabeto ordenado clássico, e por uma
segunda tira, móvel e mais comprida do que a primeira, contendo dois alfabetos
sucessivos. Tradicionalmente, o alfabeto claro é colocado na parte fixa.
AS APLICAÇÕES
Fig. 1 - A Régua de Saint-Cyr
Esta régua permite fazer substituições monoalfabéticas do tipo do Código de
César. Basta deslocar a parte móvel o número de letras que corresponde ao
deslocamento desejado. Para cifrar o texto, troca-se a letra da parte fixa pela
letra correspondente da parte móvel. De acordo com a Fig.1, cujo módulo é 5,
quando se cifra NUMABOA, obtém-se SZRFGTF. Para decifrar, faz-se o
contrário: troca-se a letra da parte móvel pela letra correspondente da parte fixa.
Com um pouco de prática, a régua de Saint-Cyr também pode ser usada nas
substituições polialfabéticas. Neste caso, a cada troca de alfabeto cifrante,
desloca-se a parte móvel de modo a obter o módulo desejado. No caso da cifra de
Vigenère, por exemplo, desloca-se a parte móvel a cada letra do texto claro de
modo que a "letra da vez" da palavra-chave esteja posicionada abaixo da letra A
da parte fixa.
Fig. 2 - N da parte fixa alinhado com o A da parte
móvel
letra pelo T.
Por exemplo, para cifrar
GRANDE IDEIA com a
palavra-chave
NUMABOA,
primeiramente desloca-se
a parte móvel para
alinhar o N com o A da
parte fixa (Fig. 2). A
seguir, procura-se o G na
parte fixa e substitui-se a

Fig. 3 - U alinhado com A
Para substituir a segunda letra posiciona-se a parte móvel da régua de modo que
o U fique alinhado com o A da parte fixa. Depois se localiza o R no alfabeto claro
e troca-se pelo L (Fig. 3). Desloca-se novamente a parte móvel para alinhar o M
com o A da parte fixa e se substitui o A por M, e assim sucessivamente. O
resultado obtido será TLMNES IQYUA.
É um vai e vem da parte móvel que dá gosto, mas, apesar disto, a margem de
erro é muito menor do que trabalhar com as Carreiras de Vigenère.
Cilindros cifrantes
Os cilindros cifrantes são constituídos por vários discos com um orifício central,
montados sobre um eixo. Devem poder rodar de forma independente e, na sua
superfície mais externa, possuem alfabetos permutados. O cilindro é montado
com discos que possuam sequências de letras diferentes.
O número de cilindros corresponde
ao número de letras que podem ser
cifradas em cada etapa. Por exemplo,
se um cilindro possuir 10 discos, uma
mensagem clara de 25 letras deverá
ser cifrada em 3 etapas: 2 blocos de
10 letras e 1 bloco de 5 letras.
A cifragem é efetuada girando-se os
discos de modo que o bloco de texto
claro seja legível numa linha do
cilindro. Para introduzir um fator
randômico no processo, o que
Fig. 1 - Cilindro cifrante M-94B com alguns
discos retirados do eixo
aumenta a segurança do método, escolhe-se aleatoriamente um bloco do texto
cifrado de qualquer outra linha do cilindro. As linhas do cilindro são
denominadas de "generatrix". A primeira linha abaixo do texto claro é a primeira
geratriz, a segunda linha abaixo do texto é a segunda geratriz e assim por diante.
A decifração é feita de modo inverso: os discos são girados de forma que uma
linha reproduza o texto cifrado e, depois, localiza-se uma outra linha que
contenha o texto claro. Na regra, existe apenas uma linha que mostra o texto
decifrado.

Com este tipo de cilindros é possível
obter cifras usando-se alfabetos
independentes através de um
procedimento fácil e pouco sujeito a
erros. Ao contrário das tabelas, de
produção trabalhosa e que exigem
muita concentração para serem
utilizadas, os discos rotantes são
práticos, com um porém: só fornecem
Fig. 2 - Foto de um cilindro M-94 usado alfabetos que "andam par e passo"
pelo exército dos EUA de 1922 a 1943 com o alfabeto primário.
Os discos podem ser colocados no eixo em diversas sequência e esta disposição
funciona como uma chave. O número de chaves utilizáveis é constituído por
todas as possíveis permutações dos discos e pode ser aumentado se houver
discos sobressalentes. Portanto, o conjunto de chaves pode ser ampliado com
facilidade.
Por outro lado, os alfabetos únicos gravados na superfície dos discos não são
apropriados como chaves. Eles podem cair em mãos erradas se um cilindro for
obtido pelo inimigo. Além do mais, não é fácil alterar a disposição das letras dos
discos.
UM POUCO DE HISTÓRIA
Apesar de haver exemplares mais antigos, os cilindros cifrantes são uma
invenção tipicamente do século XIX. Foram utilizados pelos militares no século
XX, até a Segunda Guerra Mundial.
Fredrik GRIEPENSTIERNA (1728-1804) construíu um dispositivo cifrante
cilíndrico para o rei Gustavo III da Suécia em 1786. Seu sistema, no entanto, é
um pouco diferente do acima descrito.
Thomas Jefferson (1743-1826), de 1801 a 1809 terceiro presidente dos Estados
Unidos, desenvolveu em 1795 um dispositivo com 36 discos, mas que nunca
chegou a ser utilizado.
A idéia só se tornou realmente atual depois que Kasiski demonstrou com que
facilidade as cifras polialfabéticas periódicas podiam ser quebradas e depois que
Kerckhoff deixou claro como a dependência dos alfabetos pode ser explorada.
Étienne BAZERIES (1846-1931) construíu em 1891 um dispositivo com 20 discos
e sugeriu que a força militar francesa o utilizasse. Como, logo após, De Viaris
quebrou o sistema, o dispositivo nunca chegou a ser usado.
Em 1893, Arthur Hermann sugeriu o uso de dispositivos rotantes equivalentes.
Estes acabaram sendo utilizados a partir da Primeira Guerra pelo exército dos
EUA.
Em 1922, conforme sugestão de Friedman, o exército dos EUA passou a utilizar o
dispositivo M-94, de 25 discos, em diversas variações e com vários
aperfeiçoamentos (por exemplo, o M-138-A com 30 discos originários de um

estoque de 100) até o fim da Segunda Grande Guerra. O sistema destes
dispositivos foram em parte quebrados pelos alemães (Rohrbach).
PEÇA RARA
Fig. 3 - Cilindro cifrante do
Museu Criptológico
Nacional da NSA. Acreditase
ser o dispositivo mais
antigo do gênero.
Este dispositivo de cifragem e decifragem foi
adquirido pela NSA no início dos anos 80. Imaginouse
inicialmente tratar-se de um modelo do "Jefferson
cipher wheel", porém a conexão não foi provada.
Sabe-se que estes dispositivos já haviam sido
descritos em épocas muito mais remotas, por
exemplo, por Francis Bacon em 1605. Além disso,
parecem ter sido muito comuns nas "black
chambers" de governos europeus.
Tudo indica que este cilindro cifrante tenha sido
projetado para o idioma francês, que era a língua
usada na diplomacia até o final da Primeira Guerra
Mundial. Sua origem é West Virginia e desconhece-se como tenha chegado até
lá.
O princípio dos rotores
Máquinas de cifragem com rotores trabalham com uma sequência de
substituições monoalfabéticas, alternadas a cada letra do texto claro. Esta troca
de alfabeto cifrante a cada letra é efetuada por um "rotor". Para entender o
princípio de funcionamento destas máquinas, vamos inicialmente ver como
funciona um rotor.
O princípio da substituição
Fig. 1 - Disco rotor
com contatos (face de
saída)
Um rotor é constituído por um
disco que possui contatos na
borda externa em ambas as
faces. O número de contatos é
igual ao número de letras que o
alfabeto do disco possui. Os
contatos da face A estão
ligados aos contatos da face B
de forma irregular. Por
exemplo, o contato 1 é ligado
ao 5, o 2 ao 18, etc. Como
consequência dos contatos
trocados obtém-se uma
substituição monoalfabética
Fig. 2 - Disco rotor com
contatos (face de entrada)

que ocorre da seguinte maneira:
• Numa das faces - a face de entrada - os contatos são ligados a um teclado.
Na outra face - a face de saída - os contatos são ligados a pequenas
lâmpadas identificadas por uma letra ou são ligados a uma impressora ou
outro dispositivo de impressão.
• Na face de entrada cada uma das teclas do teclado está ligada a um
contato. Como as ligações entre os contatos da face de entrada e os da face
de saída estão trocados, a saída é de letras diferentes das correspondentes
à face de entrada.
Na tabela abaixo está um
exemplo fictício do que pode
ocorrer. A primeira linha
corresponde às letras do
teclado. A segunda linha
contém a sequência dos
contatos da face de entrada,
nesta etapa do exemplo
ligados aos contatos das
letras correspondentes do
Fig. 3 - Contatos trocados no teclado. A terceira contém a
rotor da máquina Enigma sequência das ligações entre
os contatos da face de entrada e os da face de saída e,
finalmente, a quarta linha indica a letra cifrada, resultado
da substituição.
No exemplo foi ressaltada a letra "a" do teclado, ligada ao contato da letra "A" na
face de entrada. Esta, por sua vez, está ligada ao contato que corresponde à letra
"K" na face de saída. Como resultado, a letra "a" é substituída pela letra "K".
Da mesma forma podemos verificar que a letra "i", por exemplo, será substituída
pela letra "H", a "e" por "C" e assim por diante.
Teclado a b c d e f g h i j k l m n o p q r s t u v w x y z
Entrada A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Saída Q W E R T Z U I O P A S D F G H J K L Y X C V B N M
CIFRA A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Tabela exemplo de substituição por rotor
O princípio da rotação
Fig. 4 - Contatos
trocados no rotor
Hebern
Após a substituição de uma letra, o rotor é girado para ocupar uma nova posição.
Desta forma é obtida uma substituição polialfabética.
Substituindo as letras por números (o que não altera o processo), vamos analisar
o exemplo acima depois do rotor ter rodado uma posição: a letra "a" do teclado
se encontra agora no contato Z=25, a letra "b" do teclado no contato A=00 e
assim sucessivamente. Observe as tabelas abaixo:

Posição Inicial
Avanço de 1 Posição
a — 00 + 16
A
b 01 | 22 B
c 02 | 04 C
d 03 | 17 D
e 04 | 19 E
f 05 | 25 F
g 06 | 20 G
h 07 | 08 H
i 08 | 14 I
j 09 | 15 J
k
10 + 00 — K
l 11 18 L
m 12 03 M
a — 25 + 12 A
b 00 | 16 B
c 01 | 22 C
d 02 | 04 D
e 03 | 17 E
f 04 | 19 F
g 05 + 25 — G
h 06 20 H
i 07 08 I
j 08 14 J
k 09 15 K
l 10 00 L
m 11 18 M
Na posição inicial, a letra "a" do teclado foi substituída pela letra "K". Após o
avanço de uma posição do rotor, a mesma letra "a" passa a ser substituída por
"G".
O alfabeto primário, o qual descreve a posição inicial do rotor, encontra-se na
linha 0. Os alfabetos acompanhantes são chamados de alfabetos "rotantes".
Os alfabetos rotantes, como de costume, podem ser escolhidos progressivamente
ou através de uma chave.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z -> claro
---------------------------------------------------
0 K X V M C N O P H Q R S Z Y I J A D L E G W B U T F -> primário
1 G L Y W N D O P Q I R S T A Z J K B E M F H X C V U
2 V H M Z X O E P Q R J S T U B A K L C F N G I Y D W
3 X W I N A Y P F Q R S K T U V C B L M D G O H J Z E
4 F Y X J O B Z Q G R S T L U V W D C M N E H P I K A
5 B G Z Y K P C A R H S T U M V W X E D N O F I Q J L
6 M C H A Z L Q D B S I T U V N W X Y F E O P G J R K
7 L N D I B A M R E C T J U V W O X Y Z G F P Q H K S
8 T M O E J C B N S F D U K V W X P Y Z A H G Q R I L
9 M U N P F K D C O T G E V L W X Y Q Z A B I H R S J
10 K N V O Q G L E D P U H F W M X Y Z R A B C J I S T
11 U L O W P R H M F E Q V I G X N Y Z A S B C D K J T
12 U V M P X Q S I N G F R W J H Y O Z A B T C D E L K
13 L V W N Q Y R T J O H G S X K I Z P A B C U D E F M
14 N M W X O R Z S U K P I H T Y L J A Q B C D V E F G
15 H O N X Y P S A T V L Q J I U Z M K B R C D E W F G
16 H I P O Y Z Q T B U W M R K J V A N L C S D E F X G
17 H I J Q P Z A R U C V X N S L K W B O M D T E F G Y

18 Z I J K R Q A B S V D W Y O T M L X C P N E U F G H
19 I A J K L S R B C T W E X Z P U N M Y D Q O F V G H
20 I J B K L M T S C D U X F Y A Q V O N Z E R P G W H
21 I J K C L M N U T D E V Y G Z B R W P O A F S Q H X
22 Y J K L D M N O V U E F W Z H A C S X Q P B G T R I
23 J Z K L M E N O P W V F G X A I B D T Y R Q C H U S
24 T K A L M N F O P Q X W G H Y B J C E U Z S R D I V
25 W U L B M N O G P Q R Y X H I Z C K D F V A T S E J
Algumas considerações fazem-se necessárias. Observe que cada diagonal da
tabela, da esquerda para a direita e de cima para baixo, contém um alfabeto
padrão. Além disso, as representações possíveis de uma letra não estão
uniformemente distribuídas.
Como na coluna correspondente à letra "A" do alfabeto claro não aparecem todas
as letras, os inícios das linhas não são apropriadas para orientarem a escolha de
um alfabeto através de uma chave. Devido a isto, é mais fácil escolher o número
da linha, uma vez que este corresponde às letras do alfabeto (0=A, 1=B, ...,
25=Z).
Hardware de Encriptação
Hardware de encriptação é um peça de hardware criada especificamente para
manipular processos criptográficos. Pode ser um chip especial colocado na placa
mãe, um disco rígido especial ou uma placa acessória.
Alguns dispositivos apenas aceleram os processos de cifragem,
independentemente do método utilizado. Chips dedicados gerenciam e atendem
unicamente os processos criptográficos liberando a CPU desta tarefa, o que
representa um ganho significativo na performance de encriptações e
decifragens. Estes chips geralmente são otimizados para alguns tipos específicos
de chaves mas, ainda assim, são muito rápidos mesmo que uma chave não seja
do tipo otimizado. Um HD com dispositivo de encriptação faz a
cifragem/decifração automaticamente toda vez que houver escrita/leitura de
dados neste disco. Normalmente este tipo de dispositivo não permite escolher a
chave ou o comprimento de chave. Existem também placas especiais de
encriptação, projetadas especialmente para certos tipos/comprimentos de chave.
Costumam ser utilizadas em tarefas específicas, como a encriptação SSL, e são
incrivelmente rápidas. Para o usuário comum, o chip na placa mãe geralmente é
a melhor escolha (muitas placas mãe VIA já vêm com um chip deste tipo).
A segurança oferecida por qualquer sistema de encriptação depende unicamente
da sua chave. As placas aceleradoras e os HDs geralmente são fornecidos com
chaves e comprimentos de chave bastante seguros. O inconveniente destes
sistemas, além de serem mais caros, é que não se pode fazer upgrades. Se a
chave ou o comprimento de chave deixarem de fornecer a segurança desejada,
os dispositivos precisam ser trocados. Já o chip onboard aceita qualquer chave
que você fornecer. Com as chaves otimizadas, o processamento é mais rápido e,
com as não otimizadas, apenas um pouco mais demorado.

A criptologia é uma ciência que se ocupa da criptografia e da criptoanálise. A
criptografia é o estudo dos métodos e das técnicas de cifragem. A criptoanálise,
por sua vez, se ocupa do estudo das formas de se "quebrar" sistemas. É coisa de
hacker
Criptoanálise é a ciência de quebrar uma mensagem cifrada. Veja bem, quebrar
não é o mesmo que decifrar. Decifrar é obter a mensagem original quando se
conhece o sistema e usando a chave também conhecida. Quebrar é hackear o
sistema e descobrir a chave.
Desde que existe a criptografia também existiram os hackers de plantão.
Durante a Idade Média, época de extrema paradeira e de uma desvairada
perseguição aos "demônios" da criptografia na Europa, a civilização árabeislâmica
deu uma enorme contribuição: foi o berço da criptoanálise. De 700 a
1200, incríveis estudos estatísticos e figuras de destaque como al-Khalil, al-Kindi,
Ibn Dunainir e Ibn Adlan marcaram época. Na Idade Moderna, merecem
destaque o holandês Kerckoff e o alemão Kasiski.
Uma vez que a criptoanálise se ocupa em quebrar sistemas, é óbvio que um dos
temas relevantes seja a segurança. É natural intuir que, quanto mais seguro for
um sistema, mais difícil será quebrá-lo. Porém, como medir o nível de
segurança? Existem sistemas a prova de hackers? Para ter uma idéia do que vem
a ser segurança, traduzi um artigo do guru da atualidade, Bruce Schneier que
rebatizei com o título O seguro morreu de bits. Já que você caiu nesta página,
aproveite a oportunidade e dê uma lida para avaliar a complexidade do assunto.
TEXTO RETIRADO DO SITE
http://www.numaboa.com

IPSEC
IPsec is a suite of protocols for securing network connections, but the details
and many variations quickly become overwhelming. This is particularly the case
when trying to interoperate between disparate systems, causing more than one
engineer to just mindlessly turn the knobs when attempting to bring up a new
connection.
One of the first things that one notices when trying to set up IPsec is that there
are so many knobs and settings: even a pair of entirely standards-conforming
implementations sports a bewildering number of ways to impede a successful
connection. It's just an astonishingly-complex suite of protocols.
One cause of the complexity is that IPsec provides mechanism, not policy: rather
than define such-and-such encryption algorithm or a certain authentication
function, it provides a framework that allows an implementation to provide
nearly anything that both ends agree upon.
In this section, we'll touch on some of the items in the form of a glossary, with a
compare-and-contrast to show which terms relate to which other terms. This is
not even remotely complete.
AH versus ESP
"Authentication Header" (AH) and "Encapsulating Security Payload" (ESP)
are the two main wire-level protocols used by IPsec, and they authenticate
(AH) and encrypt+authenticate (ESP) the data flowing over that connection.
They are typically used independently, though it's possible (but uncommon)
to use them both together.
Tunnel mode versus Transport mode
Transport Mode provides a secure connection between two endpoints as it
encapsulates IP's payload, while Tunnel Mode encapsulates the entire IP
packet to provide a virtual "secure hop" between two gateways. The latter is
used to form a traditional , where the tunnel generally creates a secure
tunnel across an untrusted Internet.
MD5 versus versus versus versus versus blah blah blah
Setting up an IPsec connection involves all kinds of crypto choices, but this
is simplified substantially by the fact that any given connection can use at
most two or (rarely) three at a time.
Authentication calculates an Integrity Check Value (ICV) over the packet's
contents, and it's usually built on top of a cryptographic hash such as MD5
or SHA-1. It incorporates a secret key known to both ends, and this allows
the recipient to compute the ICV in the same way. If the recipient gets the
same value, the sender has effectively authenticated itself (relying on the
property that cryptographic hashes can't practically be reversed). AH
always provides authentication, and ESP does so optionally.
Encryption uses a secret key to encrypt the data before transmission, and
this hides the actual contents of the packet from eavesdroppers. There are

quite a few choices for algorithms here, with DES, 3DES, Blowfish and AES
being common. Others are possible too.
versus manual keys
Since both sides of the conversation need to know the secret values used in
hashing or encryption, there is the question of just how this data is
exchanged. Manual keys require manual entry of the secret values on both
ends, presumably conveyed by some out-of-band mechanism, and IKE
(Internet Key Exchange) is a sophisticated mechanism for doing this online.
Main mode versus aggressive mode
These modes control an efficiency-versus-security tradeoff during initial IKE
key exchange. "Main mode" requires six packets back and forth, but affords
complete security during the establishment of an IPsec connection, while
Aggressive mode uses half the exchanges providing a bit less security
because some information is transmitted in cleartext.
We'll certainly face more options as we unwrap IPsec.
The IP Datagram
Since we're looking at IPsec from the bottom up, we must first take a brief
detour to revisit the IP Header itself, which carries all of the traffic we'll be
considering. Note that we are not trying to provide comprehensive coverage to
the IP header — there are other excellent resources for that (the best being
TCP/IP Illustrated, vol 1).

ver
This is the version of the protocol, which is now 4=IPv4
hlen
IP Header length, as a four-bit number of 32-bit words ranging from 0..15. A
standard IPv4 header is always 20 bytes long (5 words), and IP Options — if
any — are indicated by a larger hlen field up to at most 60 bytes. This
header length never includes the size of payload or other headers that
follow.
TOS
Type of Service
This field is a bitmask that gives some clues as to the type of service this
datagram should receive: optimize for bandwidth? Latency? Low cost?
Reliability?
pkt len
Overall packet length in bytes, up to 65535. This count includes the bytes of
the header, so this suggests that the maximum size of any payload is at least
20 bytes less. The vast majority of IP datagrams are much, much smaller.
ID
The ID field is used to associate related packets that have been fragmented
(large packets broken up into smaller ones).
flgs
These are small flags that mainly control fragmentation: one marks the
packet as ineligible for fragmentation, and the other says that more
fragments follow.
frag offset
When a packet is fragmented, this shows where in the overall "virtual"
packet this fragment belongs.
TTL
This is the Time to Live, and is decremented by each router that passes this
packet. When the value reaches zero, it suggests some kind of routing loop,
so it's discarded to prevent it from running around the Internet forever.
proto
This represents the protocol carried within this packet, and it's going to be
central to most of our discussions. Though the datagram itself is IP, it
always encapsulates a subsidiary protocol (TCP, UDP, ICMP, etc. — see the
chart below) within. It can be thought of as giving the type of the header
that follows.
header cksum
This holds a checksum of the entire IP header, and it's designed to detect
errors in transit. This is not a cryptographic checksum, and it doesn't cover
any part of the datagram that follow the IP header.
src IP address
The 32-bit source IP address, which the recipient uses to reply to this
datagram. Generally speaking, it's possible to spoof these addresses (i.e., lie
about where the datagram is coming from).
dst IP address
The 32-bit destination IP address, which is where the packet is intended to
arrive.

IP Options
These are an optional part of the IP header that contains application-specific
information, though they are not commonly used for routine traffic. The
presense of IP options is indicated by a hlen greater than 5, and they (if
present) are included in the header checksum.
Payload
Each protocol type implies its own format for what follows the IP header,
and we've used TCP here just to show an example.
These proto codes are defined by IANA — the Internet Assigned Numbers
Authority — and there are many more than would ever be used by any single
installation, but most will ring a bell with a network-savvy technician. These
representative types are taken from the IANA website listing protocols:
Some IP protocol codes
Protocol
Protocol Description
code
1 ICMP — Internet Control Message Protocol
2 IGMP — Internet Group Management Protocol
4 IP within IP (a kind of encapsulation)
6 TCP — Transmission Control Protocol
17 UDP — User Datagram Protocol
41 IPv6 — next-generation TCP/IP
47 GRE — Generic Router Encapsulation (used by PPTP)
50 IPsec: ESP — Encapsulating Security Payload
51 IPsec: AH — Authentication Header
We'll be studying the last two in detail.
AH: Authentication Only
AH is used to authenticate — but not encrypt — IP traffic, and this serves the
treble purpose of ensuring that we're really talking to who we think we are,
detecting alteration of data while in transit, and (optionally) to guard against
replay by attackers who capture data from the wire and attempt to re-inject that
data back onto the wire at a later date.
Authentication is performed by computing a cryptographic hash-based message
authentication code over nearly all the fields of the IP packet (excluding those
which might be modified in transit, such as TTL or the header checksum), and
stores this in a newly-added AH header and sent to the other end.

This AH header contains just five interesting fields, and it's injected between the
original IP header and the payload. We'll touch on each of the fields here, though
their utility may not be fully apparent until we see how they're used in the larger
picture.
next hdr
This identifies the protocol type of the following payload, and it's the
original packet type being encapsulated: this is how the IPsec header(s) are
linked together.
AH len
This defines the length, in 32-bit words, of the whole AH header, minus two
words (this "minus two words" proviso springs from the format of IPv6's
RFC 1883 Extension Headers, of which AH is one).
Reserved
This field is reserved for future use and must be zero.
Security Parameters Index
This is an opaque 32-bit identifier that helps the recipient select which of
possibly many ongoing conversations this packet applies. Each AH-protected
connection implies a hash algorithm (MD5, SHA-1, etc.), some kind of secret
data, and a host of other parameters. The SPI can be thought of as an index
into a table of these settings, allowing for easy association of packet with
parameter.
Sequence Number
This is a monotonically increasing identifier that's used to assist in
antireplay protection. This value is included in the authentication data, so
modifications (intentional or otherwise) are detected.
Authentication Data
This is the Integrity Check Value calculated over the entire packet —
including most of the headers — The recipient recomputes the same hash;
Mismatched values mark the packet as either damaged in transit, or not
having the proper secret key. These are discarded.
Transport Mode
The easiest mode to understand is Transport Mode, which is used to protect an

end-to-end conversation between two hosts. This protection is either
authentication or encryption (or both), but it is not a tunneling protocol. It has
nothing to do with a traditional VPN: it's simply a secured IP connection.
In AH Transport Mode, the IP packet is modified only slightly to include the new
AH header between the IP header and the protocol payload (TCP, UDP, etc.), and
there is a shuffling of the protocol code that links the various headers together.
This protocol shuffling is required to allow the original IP packet to be
reconstituted at the other end: after the IPsec headers have been validated upon
receipt, they're stripped off, and the original protocol type (TCP, UDP, etc.) is
stored back in the IP header. We'll see this chain of next header fields again and
again as we examine IPsec.
When the packet arrives at its destination and passes the authentication check,
the AH header is removed and the Proto=AH field in the IP header is replaced
with the saved "Next Protocol". This puts the IP datagram back to its original
state, and it can be delivered to the waiting process.

Tunnel Mode
Tunnel Mode forms the more familiar functionality, where entire IP packets are
encapsulated inside another and delivered to the destination.
Like Transport mode, the packet is sealed with an Integrity Check Value to
authenticate the sender and to prevent modification in transit. But unlike
Transport mode, it encapsulates the full IP header as well as the payload, and
this allows the source and destination addresses to be different from those of the
encompassing packet: This allows formation of a tunnel.
When a Tunnel-mode packet arrives at its destination, it goes through the same

authentication check as any AH-type packet, and those passing the check have
their entire IP and AH headers stripped off. This effectively reconstitutes the
original IP datagram, which is then injected into the usual routing process.
Most implementations treat the Tunnel-mode endpoint as a virtual network
interface — just like an Ethernet interface or localhost — and the traffic entering
or leaving it is subject to all the ordinary routing decisions.
The reconstituted packet could be delivered to the local machine or routed
elsewhere (according to the destination IP address found in the encapsulated
packet), though in any case is no longer subject to the protections of IPsec. At
this point, it's just a regular IP datagram.
Though Transport mode is used strictly to secure an end-to-end connection
between two computers, Tunnel mode is more typically used between gateways
(routers, firewalls, or standalone VPN devices) to provide a Virtual Private
Network (VPN).
Transport or Tunnel?
Curiously, there is no explicit "Mode" field in IPsec: what distinguishes Transport
mode from Tunnel mode is the next header field in the AH header.
When the next-header value is IP, it means that this packet encapsulates an
entire IP datagram (including the independent source and destination IP
addresses that allow separate routing after de-encapsulation). This is Tunnel
mode.

Any other value (TCP, UDP, ICMP, etc.) means that it's Transport mode and is
securing an endpoint-to-endpoint connection.
The top-level of the IP datagram is structured the same way regardless of mode,
and intermediate routers treat all flavors IPsec/AH traffic identically without
deeper inspection.
We'll note that a host — as opposed to a gateway — is required to support both
Transport and Tunnel modes, but when creating a host-to-host connection, it
seems a little superfluous to use Tunnel mode.
Furthermore, a gateway (router, firewall, etc.) is only required to support Tunnel
mode, though supporting Transport mode is useful only when creating an
endpoint to the gateway itself, as in the case of network management functions.
Authentication Algorithms
AH carries an Integrity Check Value in the Authentication Data portion of the
header, and it's typically (but not always) built on top of standard cryptographic
hash algorithms such as MD5 or SHA-1.
Rather than use a straight checksum, which would provide no real security
against intentional tampering, it uses a Hashed Message Authentication Code
(HMAC) which incorporates a secret value while creating the ICV. Though an
attacker can easily recompute a hash, without the secret value he won't be able
to recreate the proper ICV.
HMAC is described by RFC 2104, and this illustration shows how the message
data and secret contribute to the final Integrity Check Value:

We'll note that IPsec/AH doesn't define what the authentication function must be,
it instead provides a framework which allows any reasonable implementation
agreed to by both ends to use. It's possible to use other authentication functions,
such as a digital signature or an encryption function as long as both sides
provide for it.
AH and NAT — Not Gonna Happen
Though AH provides very strong protection of a packet's contents because it
covers everything that can be possibly considered immutable, this protection
comes at a cost: AH is incompatible with NAT (Network Address Translation).

NAT is used to map a range of private addresses (say, 192.168.1.X) to and from a
(usually) smaller set of public address, thereby reducing the demand for
routable, public IP space. In this process, the IP header is actually modified on
the fly by the NAT device to change the source and/or destination IP address.
When the appropriate source or header IP address is changed, it forces a
recalculation of the header checksum. This has to be done anyway, because the
NAT device typically serves as one "hop" in the path from source to destination,
and this requires the decrement of the TTL (Time To Live) field.
Because the TTL and header checksum fields are always modified in flight, AH
knows to excludes them from coverage, but this does not apply to the IP
addresses. These are included in the Integrity Check Value, and any modification
will cause the check to fail when verified by the recipient. Because the ICV
incorporates a secret key which is unknown by intermediate parties, the NAT
router is not able to recompute the ICV.
This same difficulty also applies to PAT (Port Address Translation), which maps
multiple private IP addresses into a single external IP address. Not only are the
IP addresses modified on the fly, but the UDP and TCP port numbers (and
sometimese even to payload). This requires much more intelligence on the part
of the NAT device, and more extensive modifications to the whole IP datagram.
For this reason, AH — whether in Tunnel or Transport mode — is entirely
incompatible with NAT, and it may only be employed when the source and
destination networks are reachable without translation.
We'll note that this particular difficulty doesn't apply to ESP, as its

authentication and encryption do not incorporate the IP header being modified
by NAT. Nevertheless, NAT does impose some challenges even on ESP.
NAT translates IP addresses on the fly — but it has to keep track of which
connections are flowing through it so that replies can be properly associated
with sources. When using TCP or UDP, this is commonly done with port numbers
(whether rewritten on the fly or not), but IPsec provides no hook to allow this.
At first one might suspect the SPI, which appears to be a useful identifier, but
because the SPI is different in both directions, the NAT device has no way to
associate the returning packet with the outgoing connection.
Addressing this requires special facilities for NAT traversal, something not
covered in this paper.
ESP — Encapsulating Security
Payload
Adding encryption makes ESP a bit more complicated because the encapsulation
surrounds the payload rather than preceeds it as with AH: ESP includes header
and trailer fields to support the encryption and optional authentication. It also
provides Tunnel and Transport modes which are used in by-now familar ways.
The IPsec RFCs don't insist upon any particular encryption algorithms, but we
find DES, triple-DES, AES, and Blowfish in common use to shield the payload
from prying eyes. The algorithm used for a particular connection is specified by
the Security Association (covered in a later section), and this SA includes not
only the algorithm, but the key used.
Unlike AH, which provides a small header before the payload, ESP surrounds the
payload it's protecting. The Security Parameters Index and Sequence Number

serve the same purpose as in AH, but we find padding, the next header, and the
optional Authentication Data at the end, in the ESP Trailer.
It's possible to use ESP without any actual encryption (to use a NULL algorithm),
which nonetheless structures the packet the same way. This provides no
confidentiality, and it only makes sense if combined with ESP authentication. It's
pointless to use ESP without either encryption or authentication (unless one is
simply doing protocol testing).
Padding is provided to allow block-oriented encryption algorithms room for
multiples of their blocksize, and the length of that padding is provided in the pad
len field. The next hdr field gives the type (IP, TCP, UDP, etc.) of the payload in
the usual way, though it can be thought of as pointing "backwards" into the
packet rather than forward as we've seen in AH.
In addition to encryption, ESP can also optionally provide authentication, with
the same HMAC as found in AH. Unlike AH, however, this authentication is only
for the ESP header and encrypted payload: it does not cover the full IP packet.
Surprisingly, this does not substantially weaken the security of the
authentication, but it does provide some important benefits.
When an outsider examines an IP packet containing ESP data, it's essentially
impossible to make any real guesses about what's inside save for the usual data
found in the IP header (particularly the source and destination IP addresses).
The attacker will certainly know that it's ESP data — that's also in the header —
but the type of the payload is encrypted with the payload.
Even the presense or absense of Authentication Data can't be determined by
looking at the packet itself (this determination is made by using the Security
Parameters Index to reference the preshared set of parameters and algorithms
for this connection).
However, it should be noted that sometimes the envelope provides hints that the

payload does not. With more people sending inside ESP over the internet, the
taggings are in the outside header and is fairly obvious what traffic is VoIP
signaling (IP precedence 3) and what is RTP traffic (IP precedence 5). It's not a
sure thing, but it might be enough of a clue to matter in some circumstances.
ESP in Transport Mode
As with AH, Transport Mode encapsulates just the datagram's payload and is
designed strictly for host-to-host communications. The original IP header is left
in place (except for the shuffled Protocol field), and it means that — among other
things — the source and destination IP addresses are unchanged.

ESP in Tunnel Mode
Our final look of standalone ESP is in Tunnel mode, which encapsulates an entire
IP datagram inside the encrypted shell:
Providing an encrypted Tunnel Mode connection is getting very close to the
traditional VPN that springs to mind when most of us think about IPsec, but we
have to add authentication of one type or another to complete the picture: this is
covered in the following section.
Unlike AH, where an onlooker can easily tell whether traffic is in Tunnel or
Transport mode, this information is unavailable here: the fact that this is Tunnel
mode (via next=IP) is part of the encrypted payload, and is simply not visible to
one unable to decrypt the packet.

Putting it all together: Building a
real VPN
With coverage of the Authenticating Header and Encapsulating Security Payload
complete, we're ready to enable both encryption and authentication to build a
real VPN. The whole purpose of a Virtual Private Network is to join two trusted
networks across an untrusted intermediate network, as is by stringing a very
long Ethernet cable between the two. This is commonly used to connect branch
offices with company headquarters, allowing all users to share sensitive
resources without fear of interception.
Clearly, a secure VPN requires both authentication and encryption. We know
that ESP is the only way to provide encryption, but ESP and AH both can provide
authentication: which one do we use?

The obvious solution of wrapping ESP inside of AH is technically possible, but in
practice is not commonly used because of AH's limitations with respect to
Network Address Translation. By using AH+ESP, this tunnel could never
successfully traverse a NAT'ed device.
Instead, ESP+Auth is used in Tunnel mode to fully encapsulate the traffic on its
way across an untrusted network, protected by both encryption and
authentication in the same thing.
Traffic protected in this manner yields nearly no useful information to an
interloper save for the fact that the two sites are conntected by a VPN. This
information might help an attacker understand trust relationships, but nothing
about the actual traffic itself is revealed. Even the type of encapsulated protocol
— TCP, UDP, or ICMP — is hidden from outsiders.

What's particularly nice about this mode of operation is that the end-user hosts
generally know nothing about the VPN or other security measures in place. Since
a VPN implemented by a gateway device treats the VPN as yet another interface,
traffic destined for the other end is routed normally.
This packet-in-a-packet can actually be nested yet more levels: Host A and Host
B can establish their own authenticated connection (via AH), and have this
routed over the VPN. This would put an AH inner packet inside an enclosing
ESP+Auth packet.
Update - it's important to use authentication even if encryption is used, because
encrypt-only implementations are subject to effective attack as described in the
paper Cryptography in Theory and Practice: The Case of Encryption in IPsec; see
the Resources section for more information.
Touching on Other Matters
IPsec is a very complex suite of protocols, and this Tech Tip cannot possibly give
proper justice to more than a small part of it. In this section we'll mention a few
areas that beg for more coverage.
Security Associations and the SPI
It seems self-evident that if two endpoints or gateways are going to establish a
secure connection, some kind of shared secret is required to seed the
authentication function and/or key the encryption algorithm. The matter of just
how these are secrets are established is a substantial topic to be addressed
elsewhere, and for the purposes of this discussion we shall just assume that the
keys have magically landed where they belong.
When an IPsec datagram — either AH or ESP — arrives at an interface, just how
does the interface know which set of parameters (key, algorithm, and policies) to
use? Any host could have many ongoing conversations, each with a different set
of keys and algorithms, and something must be able to direct this processing.
Unsure!
It's been pointed out that the SADB only uses the protocol type and SPI to select
an entry, not the partner IP address; we simply don't know.
This might depend on whether the association is configured with main mode or
aggressive mode, but we welcome clarifications.
This is specified by the Security Association (SA), a collection of connectionspecific
parameters, and each partner can have one or more Security
Associations. When a datagram arrives, three pieces of data are used to locate
the correct SA inside the Security Associations Database (SADB):
• Partner IP address

• IPsec Protocol (ESP or AH)
• Security Parameters Index
In many ways this triple can be likened to an IP socket, which is uniquely
denoted by the remote IP address, protocol, and port number.
Security Associations are one way, so a two-way connection (the typical case)
requires at least two. Furthermore, each protocol (ESP/AH) has its own SA in
each direction, so a full AH+ESP VPN requires four Security Associations. These
are all kept in the Security Associations Database.
A tremendous amount of information is kept in the SADB, and we can only touch
on a few of them:
• AH: authentication algorithm
• AH: authentication secret
• ESP: encryption algorithm
• ESP: encryption secret key
• ESP: authentication enabled yes/no
• Many key-exchange parameters
• Routing restrictions
• IP filtering policy
Some implementations maintain the SPD (Security Policy Database) with
command-line tools, others with a GUI, while others provide a web-based
interface over the network. The amount of detail maintained by any particular
implementation depends on the facilities offered, as well as whether it's
operating in Host or Gateway mode (or both).
Key Management
Finally, we briefly visit the very complex matter of key management. This area
includes several protocols and many options, and the bulk of this will be covered
in a future paper. This section is necessarily highly incomplete.
IPsec would be nearly useless without the cryptographic facilities of
authentication and encryption, and these require the use of secret keys known to
the participants but not to anyone else.
The most obvious and straightforward way to establish these secrets is via
manual configuration: one party generates a set of secrets, and conveys them to
all the partners. All parties install these secrets in their appropriate Security
Associations in the SPD.
But this process does not scale well, nor is it always terribly secure: the mere act
of conveying the secrets to another site's SPD may well expose them in transit. In
a larger installation with many devices using the same preshared key,
compromise of that key makes for a very disruptive re-deployment of new keys.
IKE — Internet Key Exchange — exists to allow two endpoints to properly set up
their Security Associations, including the secrets to be used. IKE uses the
ISAKMP (Internet Security Association Key Management Protocol) as a

framework to support establishment of a security association compatible with
both ends.
Multiple key-exchange protocols themselves are supported, with Oakley being
the most widely used. We'll note that IPsec key exchange typically takes place
over port 500/udp.
Texto retirado do Site
http://www.unixwiz.net/techtips/iguide-ipsec.html

NAT
Com o crescimento exponencial da utilização da Internet, começa a haver a
possibilidade de uma escassês de endereços IP válidos, ou seja, endereços que
sejam roteáveis na Internet. Nesse contexto, torna-se útil um protocolo que
permita que o crescimento da utilização da rede global não seja freado e
que, ao mesmo tempo, não esgote os endereços que são previstos pelo IPV4
( Internet Protocol Version 4) .
O NAT, que é o protocolo abordado nesse trabalho, vem sendo
largamente utilizado por muitos administradores de rede para atender a essa
demanda.
A razão pela qual o NAT é tão importante é, como já dissemos, que o IPV4
fornece um número limitado de endereços (existem 4 octetos, totalizando 32
bits de endereçamento). Com o advento da RFC 1918, foram criadas regras
que permitiam a utilização de endereços não-roteáveis nas redes locais, evitando
que toda e qualquer máquina que quisesse se conectar a uma rede tivesse que
ser reconhecida por um único e exclusivo endereço em toda a Internet. Com
isso, criam-se redes isoladas. Ainda há a necessidade de essas redes se
comunicarem. É aí que entra a tradução de endereços.
O NAT normalmente em um roteador ou em um firewall, que são
dispositivos que recebem conexões de diferentes redes em seus terminais, como
podemos ver no desenho abaixo:

Figura 1: roteador interligando a Rede Pública e a Rede Local
Figura 2: Firewall interligando 2 Redes Locais à Rede Pública
Nota-se que nas 2 figuras existem 253 máquinas na rede local querendo acessar
a rede pública ou válida.
Em uma situação normal - sem NAT - , haveria a necessidade de 255
endereços válidos para prover esse acesso.
Com a tradução de endereços, esse problema passa a não existir. É possível
atribuir-se endereços não-roteáveis à rede interna e traduzir esses
endereços para um único ou mais endereços válidos.
Entenda-se por endereços não-roteáveis aqueles definidos pela IANA
(Internet Assigned Numbers Authority) para serem utilizados em redes locais.
Segundo a RFC 1918, seguem estes endereços:
Classe de Endereçamento
A
Faixa de Endereços
10.0.0.0 - 10.255.255.255

B
C
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
tabela 1: alocação segundo a IANA de endereços não-roteáveis segundo a RFC
1918
Os ISPs ( Internet Service Providers) são os que mais tiram vantagens dessa
solução, pois evita que eles tenham que registrar uma grande quantidade de
endereços no IANA. Além disso, as empresas podem e gerenciar o seu próprio
plano de endereçamento IP, utilizando e pagando por um número reduzido de Ips
válidos.
Conexões IP – Uma breve revisão
Antes de detalhar o funcionamento do NAT, faz-se necessária uma análise
do funcionamento de uma conexão IP.
Existem 65535 portas de conexão (o número de portas disponíveis é
determinado pelo valor máximo que se consegue gerar a partir dos 16 bits
alocados ao port number do pacote IP). As primeiras 1023 são reservadas aos
serviços mais comuns de comunicação, conhecidos pela sigla WKS ( Well
Known Services), como por exemplo o Telnet, ftp, gopher, www e outros. Por
serem resevados, não podem ser utilizados por outros processos clientes.
Considere-se uma conexão entre 2 computadores, A e B. O
computador A, ao teclar telnet servidorB.com, faz com que o sistema
operacional deste selecione uma porta acima da porta 1023 (digamos 1025)
para abrir a seção de Telnet. Daí, o computador A conecta B na porta 23 - esta é
a porta reservada pelo IANA para seções telnet. Entretanto, a informação que
segue no pacote IP informa a B que o endereço de origem do telnet abriu a
conexão na porta 1025. Esta definição desmistifica a idéia de que uma conexão
entre 2 máquinas se faz apenas em uma porta - no caso do exemplo acima,
porta 23.
Este ítem serve como base para a definição de Port Address Translation (PAT), a
ser tratada adiante.
Funcionamento:
Tome-se como exemplo a rede exibida abaixo:

Figura 3: Usuários Locais querendo acesso ao servidor 200.244.37.76
Nessa rede, os usuários da rede local 10.40.1.0/24 pretendem acessar o servidor
do site de busca Cadê, que possui um endereço roteável (válido) 200.244.37.76.
O administrador dessa rede seguiu a RFC 1918
mas agora encontra um problema: como sua rede 10.40.1.0 /24 - não roteável -
vai acessar o servidor do Cadê ? A resposta é óbvia: fazendo um NAT, no caso do
exemplo, no Firewall. Conforme foi mencionado anteriormente, este poderia ser
feito no roteador sem problemas.
Com o NAT habilitado, o usuário ao chamar a página Web em questão no seu
browser, fará com que a sua máquina envie um pacote endereçado a
200.244.37.76. O endeço IP da origem (por exemplo 10.40.1.10) e a porta de
origem ( por exemplo a 1500) estão no pacote, assim como o endereço de
destino(200.244.37.76) e a porta de destino(80).Quando o pacote chega ao
Firewall, ele o deencapsulará e o reescreverá.O pacote que ele enviará para a
Rede Pública conterá o endereço da interface do Firewall que está a ela
conectada - ou um outro endereço previamente acertado que seja roteável - como
endereço de origem, a porta de origem alocada de uma lista de portas livres
no Firewall e o resto do pacote será uma cópia do pacote original.

Figura 4: Funcionamento do NAT saindo da rede local
O Firewall também vai adicionar uma entrada em uma tabela de tradução onde
mapeará a requisição de seção, ou seja, ele relaciona o endereço interno que
fez a requisição e sua porta com o endereço e a porta a serem utilizadas como
tradução. Segue abaixo um modelo dessa tabela:

Figura 5: tabela de tradução de endereços do Firewall
Esta informação é de vital importância para o próximo passo da comunicação
entre as máquinas. Quando o servidor www.cade.com.br responder à requisição,
este responderá ao Firewall e não diretamente a máquina na Rede Interna. O
pacote, ao chegar no Firewall, será alterado por este, respeitando a
tabela de tradução acima. No exemplo, o pacote chega ao Firewall com
endereço de destino 200.182.30.1 e porta de destino igual a 45000. O Firewall
consulta a tabela e verifica que este equivale ao endereço 10.40.1.10 na porta
1500, fazendo, então, as alterações necessárias.

Figura 6: Funcionamento do NAT recebendo o retorno da rede externa
TIPOS DE NAT
É possível se praticar 3 formas de tradução de endereços. São elas:
NAT Estático
NAT Dinâmico
PAT - Port Address Translation
NAT Estático:
Como o próprio nome indica, o NAT estático define um endereço fixo de tradução
de uma máquina da Rede Local para a Rede Pública.
Esse tipo de NAT é muito utilizado quando se quer ocultar o endereçamento
interno de uma máquina para a Rede Pública e também torná-la visível para a
mesma. Veja o exemplo abaixo:

Verifica-se que existem 2 servidores alocados na rede chamada DMZ
(Rede não-militarizada).
Essa rede é normalmente configurada para abrigar servidores que apresentam
maiores riscos de serem atacados por usuários externos. A primeira máquina é o
servidor Web e a segunda é um servidor de mensagens.
Ambas precisam ter endereços declarados na Rede Pública e, por isso, podem
ser vistos por qualquer usuário - por isso a preocupação com a questão de
segurança sobre essas máquinas é redobrada. Ao se colocar as mesmas em
uma rede separada da rede principal (Rede Local), caso um usuário malintencionado
consiga "atacar"a máquina e ganhar acesso à rede, este terá acesso
a uma rede sem máquinas que contenham informações de maior importância.
Nessa situação, é feito um NAT Estático da máquina Web de 10.40.3.3 para
200.182.30.9. Um usuário do UOL, por exemplo, com o IP 200.192.188.9, para
acessar o servidor Web, vai acessar uma "máquina virtual" que responderá
pelo endereço de NAT acima mencionado. O mesmo é feito para o servidor de
Mensagens ( 10.40.3.4 para 200.182.30.10).
- NAT dinâmico:
Este conceito de tradução, em oposição ao anterior, diz que a tradução só deve
ocorrer quando houver uma solicitação que demande tradução. Nesta técnica,
trabalha-se com uma faixa de endereços que ficam à disposição do
dispositivo tradutor (Firewall ou Roteador) para realizar a conversão de
endereços. A cada requisição feita, ele consulta essa faixa e utiliza-se do
primeiro endereço livre que
encontar. Este modelo é considerado o mais flexível, pois permite uma série
de diferentes soluções para fazer a conversão. Existem 3 modelos de NAT
dinâmico:
- Conversão 1x1: este modelo de NAT é pouco utilizado pois não
auxilia no controle da utilização de endereços públicos. Ele diz que cada
máquina solicitante da rede interna terá um endereço de tradução na rede
pública. Apenas apresenta a vantagem de "esconder" o endereçamento
interno.

Figura 8: um exemplo de NAT Dinâmico 1x1
- Conversão N x M ( N > M): este modelo é utilizado quando a quantidade de
endereços na rede interna é maior que o número de endereços presentes na
faixa . É um misto entre a conversão 1x1 e o PAT (a ser definido em
seguida). O tradutor, ao receber as requisições, vai utilizar os endereços da
faixa como se estivesse fazendo uma conversão 1x1. Ao esgotarem-se os
endereços , ele começa a fazer Port Address Translation - PAT.
Esse modelo é bastante empregado quando há a necessidade de se interligar
2 redes que estejam seguindo a RFC 1918. Segue abaixo, um exemplo da sua
utilização:

Figura 9: um exemplo de NAT Dinâmico N x M
Nesse exemplo, há a interligação de 2 redes locais, via um link de dados: uma no
Rio de Janeiro(Matriz) e outra em São Paulo (Filial). As máquinas da Matriz
pretendem acessar as máquinas da filial via NAT.
Na figura acima, pode-se notar que existem menos endereços na faixa de
endereços do NAT (rede 192.168.1.0 com máscara 255.255.255.0) do que
na Rede Local Matriz (rede 10.40.1.0 com máscara 255.255.248.0). Se todas
as máquinas forem fazer as requisições para a rede 192.x.x.x ao mesmo tempo,
a máquina 10.40.1.254 será a última a conseguir ter associado o seu IP
diretamente a um endereço da faixa. A máquina seguinte, 10.40.2.1,
necessitará realizar um Port Address Translation.
- Conversão Nx1 ou PAT: este modelo , por ser bastante empregado, será
melhor detalhado no próximo ítem.
- Port Address Translation:
O Port Address Translation - PAT - é o tipo de NAT que mais economiza
endereços válidos

(roteáveis) pois a tradução é feita no modelo N para 1, ou seja, todos os
endereços da Rede Local são traduzidos para um único endereço válido. Esse
tipo de NAT é, na verdade, um caso especial do NAT dinâmico pois neste caso,
assim como no anterior, as traduções são feitas sob demanda, ou seja, só existe a
tradução quando houver uma requisição realizada.
Este modelo apresenta uma limitação para o número máximo de conexões
simultâneas. Como é sabido, há uma limitação do número de portas de
comunicação - já mencionado anteriormente. Por existir um total de 65535
portas disponíveis para comunicação, só é possível, em teoria, se traduzir
um número menos que 65000 endereços simultâneos ( não se pode contar com
as portas dos serviços WKS para a tradução).
Essa limitação não chega a ser uma desvantagem para o modelo pois,
exceto em casos de redes extremamente grandes, 65000 conexões simultâneas é
um número bastante aceitável.
Abaixo, segue um exemplo do modelo:
Figura 10: um exemplo de Port Address translation

No exemplo, temos usuários alocados na rede 10.40.1.0/24 - Rede Interna -
querendo acessar o site www.cade.com.br . O administrador de rede tem
aproximadamente 250 usuários em sua rede
local querendo acessar a Internet porém o ISP (Internet Service Provider) só lhe
forneceu um range de endereços 200.182.30.0 /29 - o que le dá apenas 3
endereços válidos. Com essa escassês de endereços, a única solução para
garantir acesso simultâneo a todos é o PAT. Nesse exemplo, todos saem com o
endereço 200.182.30.1.
Abaixo, segue um exemplo da tabela de tradução do dispositivo tradutor
(Roteador ou Firewall), baseado em PAT. Considera-se a tabela com 10 conexões
simultâneas.
Figura 11: tabela de tradução para PAT com 10 conexões simultâneas
Nota-se que todas as traduções são feitas para um único endereço e que as
portas não podem ser repetidas. Foram marcados 2 casos especiais nessa
tabela, um indicado com a cor vermelha e outro com a cor azul. O primeiro caso
mostra que a máquina 10.40.1.2 está tentando abrir mais de uma conexão
com a Rede Pública (por exemplo, ele pode estar acessando - no exemplo - 3
endereços Web distintos). Veja que o dispositivo tradutor (Firewall ou Roteador)
irá tratar essa situação sem dar importância ao fato das requisições virem da
mesma máquina. Para ele, são solicitações de seções independentes. No segundo

caso, ocorre a coincidência de 2 máquinas distintas abrirem conexões
utilizando a mesma porta de origem. Mais uma vez, o dispositivo tradutor tratará
as requisições sem maiores problemas, pois, apesar de possuirem a mesma
porta de origem, tem IPs de origem distintos.
Vantagens:
Conectividade bi-direcional transparente entre redes com diferentes
endereçamentos
Eliminam se gastos associados a mudança de endereços de
servidores/rede
Economia de endereços roteáveis do IPV4
Facilita o desenho/implementação de Redes
Aumenta a proteção das redes locais
1. Conectividade bi-direcional transparente entre redes com diferentes
endereçamentos:
Essa característica faz com que seja transparente para os elementos de rede que
não estejam diretamente
envolvidos com a tradução a utilização do NAT. Para eles, o pacote IP que sofreu
NAT é um pacote omo outro qualquer. É importante ressaltar que apenas o
elemento tradutor "sabe" que o endereço foi alterado.
2. Eliminam se gastos associados a mudança de endereços de
servidores/rede:
Como foi dito no início do trabalho, sem a existência da RFC1918 e do NAT,
qualquer máquina que quisesse ser visualizada na Rede Pública deveria possuir
endereços válidos. Nessa situação, qualquer alteração no endereçamento de
uma simples máquina implicaria em replicar a mudança em TODAS as máquinas
roteáveis. Isso demandaria um gasto muito alto com tempo e mão-de-obra
necessários para configurar as máquinas.
Imagine-se aqui um exemplo em que um administrador de rede resolver mudar o

seu ISP. Na situação exposta acima, para mudar o seu provedor, o administrador
deveria mudar o endereço de todas as máquinas de sua rede. Com o NAT,
basta fazer a alteração em um único ponto (elemento tradutor) e este será
incumbido da responsabilidade de fornecer o IP à máquina solicitante -seguindo
a RFC1918- o IP da nova faixa de IPs fornecida pelo novo provedor.
3. Economia de endereços roteáveis do IPV4:
Como foi dito acima, há uma melhor gerência do endereçamento IP com o NAT.
Custuma-se dizer que passa a haver uma utilização racional de endereços. Com a
redução da faixa de endereços solicitada ao ISP, há uma redução no custo dos
links.
3. Facilita o desenho/implementação de Redes:
Devido ao uso racional de IPs, há uma menor preocupação com a criação dos
mapas de endereçamento de rede, facilitando a implementação/interligação das
mesmas.
4. Aumenta a proteção das redes locais:
O NAT evita que se precise publicar o endereçamento interno das redes locais
nas redes públicas. Assim, fica mais difícil para um usuário mal-intencionado
montar qualquer tipo de ataque direto à Rede Interna.
Um intruso precisa tentar um ataque direto ao endereço de NAT antes de
conseguir atacar a Rede Local.
Além dessa vantagem, é possível se implementar filtros de pacote nos 2
elementos que possibilitam a tradução. No próximo ítem, será dado um
exemplo do uso do Firewall como tradutor e filtro de pacotes.
Desvantagens:
Impossibilidade de se rastrear o caminho do pacote
Aumento do processamento no dispositivo tradutor
Impossibilidade de se rastrear o caminho do pacote

Com a utilização da tradução, fica impossível se utilizar o comando traceroute
para se identificar o caminho que o pacote segue até
encontrar o seu destino, pois o elemento tradutor não permite a tradução
reversa (resposta da rede externa para a local) com resposta indicando
"esgotado tempo limite" - TTL (Time to Live).
O traceroute é um comando muito utilizado para se verificar conectividade entre
2 pontos. Caso não se consiga conectividade entre 2 pontos, é possível, com esse
comando, se identificar onde o pacote está "parando" por falta de rotas ou
problemas de interligação.
Aumento do processamento no dispositivo tradutor
Como foi dito acima, o NAT requer que a máquina que fará a tradução altere
o pacote IP. Essa manobra exige que a máquina deixe dedicado para
essa tarefa parte do seu potencial de processamento. Por essa razão, há
que se ter cuidado na escolha do tradutor. Deve-se atentar para a demanda
extra de processamento.
Nesse sentido, os fabricantes de equipamentos utilizam-se de 2 linhas de
produtos para realizar a tradução. São elas:
- tradução via software: existe uma aplicação que funciona em um
servidor que faz o papel de tradutor. A tradução, nesse caso é feita via
software.
- tradução via hardware: nesse caso, é desenvolvido um hardware
específico para desempenhar aquela função. O sistema é desenvolvido de forma
a otimizar a performance do equipamento ao desempenhar a tradução.
A escolha da linha de produtos que irá atender a uma certa demanda depende da
necesside, ou seja, a escolha certa do produto varia de caso a caso. A utilização
da tradução via hardware permite uma maior velocidade na tradução e, muitas
vezes, um gasto menor na implantação; porém existem limitações com relação à
flexibilidade do equipamento. Já com a tradução via software, ocorre o contrário.
A tradução é feita com maior lentidão, os recursos utilizados não são
otimizados, porém permite uma grande
flexibilidade no seu uso diário. Por funcionar "sobre" um sistema operacional, é
possível se utilizar este
último para incorporar novas funcionalidades à aplicação, por exemplo.
Utilização do NAT em conjunto com listas de acesso:
Como foi dito inicialmente, há uma grande preocupação com a proteção das

edes locais. Essa preocupação
é justificada pelo fato de nessas redes estarem localizados, por muitas vezes,
servidores que contém dados
de elevada importância (pesquisas científicas, dados de clientes, etc) e
servidores que estejam em produção.
Caso essas máquinas sejam invadidas por usuários mal-intencionados e os
dados das mesmas forem corrompidos, muitos interesses serão seriamente
afetados.
Sabe-se que o NAT tem a vantagem de ocultar o endereçamento interno das
redes e que, para ganhar acesso a uma máquina, um usuárioexterno terá que
fazer um ataque direto a 2 endereço - primeiro o de tradução e depois o real.
Porém, a simples utilização do NAT não garante a segurança da rede. Os ataques
podem ser efetuados em qualquer uma das 65535 portas existentes em um
computador.
Veja um exemplo em que a utilização do NAT não protege a rede: imagine que
um usuário A da rede interna resolva acessar a Internet. Ele inicia um telnet na
rede pública. Após alguns minuto, ele termina o comando e fecha a janela de
comunicação. Até esse ponto, tudo parece estar bastante normal, porém, o que
não se percebe facilmente é que o dispositivo tradutor terá, por um pequeno
porém significativo período de tempo a conexão do usuário A armazenada em
suas tabelas de tradução. É nesse curto intervalo de tempo que um usuário malintencionado
pode se aproveitar e tentar acessar a rede interna. Caso ele envie
um pacote IP na porta onde o usuário A teria a resposta da sua conexão de
Telnet, este será aceito. Dessa forma, usuários da rede pública podem enviar
pacotes IP para a rede interna contendo dados que possam danificar algum
componente na rede ( derrubar um servidor, etc). É nesse contexto que atuam os
filtros de pacotes.
Por uma questão de conveniência, os 2 elementos mencionados neste trabalho
como tradutores de endereço (firewall e roteador) realizam o papel de filtro de
pacotes. Eles só permitem que passem por eles pacotes que contenham
caracter'siticas que estejam descritas no filtro ( por exemplo, só se aceitam
conexões na porta 80 para o servidor B ou só se aceitam conexões provenientes
de um endereço específico da rede pública, etc).
Segue agora um exemplo prático. É muito comum a presença de servidores web.
Este serviço, como foi dito, está enquadrado nas WKS - porta 80.Assim sendo,
nenhuma outra porta deve estar liberada para o acesso,ou seja, qualquer
tentativa de conexão em outra porta que não esta pode ser considerada como
tentativa de invasão.

Figura 12: um usuário acessa a porta 80 do Servidor Web com autorização do
Firewall
No exemplo acima um úsuário com IP público tenta acessar o servidor Web na
porta 80. Para acessá-lo, primeiro ele faz uma requisição para o endereço virtual
(200.182.30.9). Este manda a informação para o Firewall e este verificará se
tem alguma regra que permita pacotes para o servidor web na porta
80. No exemplo, o firewall terá essa regra e permitirá a passagem do pacote
por ele. O resto do
processo funciona como um NAT normal.
No próximo exemplo, o mesmo usuário vai tentar acessar a porta 1433 no mesmo
servidor.

Figura 13: o Firewall rejeita a tentativa de conexão na porta 1433
O funcionamento é o mesmo mostrado anteriormente, sendo que o Firewall, ao
verificar que não existem regras que permitam o acesso ao servidor Web na
porta 1433 irá descartar o pacote que chegou a ele, não permitindo a conexão.
Conclui-se que a utilização da tradução de endereços - NAT - permite que
se utilize o espaço de endereçamento fornecido pelo IPV4 de uma forma
mais inteligente e racional, em conjunto com as especificações propostas na
RFC1918.
Além da questão pura do endereçamento, ele permite que se aumente a
segurança das redes locais contra possíveis investidas de usuários externos com
o objetivo de comprometer a estrutura de dados que é mantida localmente.
Este aumento da segurança é obtido graças ao fato de usuários externos
ficarem impossibilitados de conhecer o endereçamento local.
Por essas e outras razões, acredita-se que o NAT venha a ser cada vez mais
utilizado pelos administradores de rede em todo o mundo.
Bibliografia:

1) Commer, Douglas E.
Internetworking with TCP/IP - volume I
Prentice Hall - 1995
ISBN 0-13-216987-8 (V.1)
2) Soares, Luiz Fernando G. (Luiz Fernando Gomes)
Redes de Computadores: das LANs, MANs e WANs às Redes ATM
Campus - 1995
ISBN 85-7001-954-8
Páginas Web
http://www.kentrox.com/support/KB/Common/Public/GENL475.htm
http://alumni.caltech.edu/~dank/peer-nat.html
http://www.dalantech.com/nat.shtml
http://www.bsdtoday.com/2001/May/Features478.html
http://www.networkmagazine.com/article/printableArticle?doc_id=PIT20000629
S0020
http://www.technet.com
http://www.cisco.com.br
http://www.checkpoint.com
1) Cite 2 vantagens de se utilizar o NAT?
R: Pode-se citar como a primeira vantagem o fato de permitir a utilização de
endereços roteáveis na rede pública de forma racional. Uma segunda vantagem
seria a possibilidade de ocultar o endereçamento das redes locais,
dificultando o acesso de usuários mal-intencionados à rede local.
2) Quais as 3 formas de se realizar um NAT?
R: Existem 3 formas de se realizar um NAT:
- NAT Estático

- NAT Dinâmico
- PAT - Port Address Translation
3)Como funciona o PAT (Port Address Translation)?
R: Quando a solicitação de uma máquina da rede interna chega ao elemento
tradutor, este altera o cabeçalho do pacote retirando do campo entitulado
"endereço de origem" o endereço da rede
local e colocando um endereço da rede pública. A tradução de todas as
requisições é feita para um único endereço. Por essa razão, há a necessidade
de se ter um outro elemento que isole as diferentes solicitações. Isto é feito
se mudando o endereço da porta de origem. O elemento tradutor armazena
essas mudanças em uma área chamada TABELA DE TRADUÇÃO. Esta será
consultada para se fazer o NAT reverso ( da rede externa para a interna).
4) Cite 1 desvantagem de se realizar NAT?
R: a utilização do NAT impossibilita a utilização do comando traceroute que
permite se verificar o caminho que um pacote percorre desde a origem até o seu
destino.
5) Em qual situação se enquadra a utilização de um NAT Estático?
R: o NAT Estático é utilizado quando se deseja declarar um servidor
da rede local na rede pública. Exemplos de máquinas que comumente
sofrem NAT estático na maioria das redes são os servidores de
Mensagens (Mail) e os servidores Web (porta 80). O usuário externo não
acessa diretamente a máquina, e sim um endereço virtual.
RETIRADO DO SITE: http://www.gta.ufrj.br/grad/01_2/nat/

Diretrizes do design
FIREWALL
Este módulo considera os requisitos para um firewall interno em uma rede
corporativa, os tipos de dispositivos que podem atender a esses requisitos e as
opções disponíveis para a implantação. Infelizmente, as invasões em redes de
usuários internos e externos têm se tornado um evento regular, o que significa
que as empresas devem instalar uma proteção. O firewall tem o seu preço e cria
um obstáculo ao fluxo do tráfego. Por isso, você deve certificar–se de que o
firewall tenha sido criado para ser o mais econômico e eficiente possível.
Arquitetura de rede
Geralmente, a arquitetura de rede de uma empresa possui três zonas:
•Rede de limite
Essa rede está voltada diretamente para a Internet por meio de um roteador
que fornece uma camada de proteção inicial na forma de filtragem básica de
tráfego de rede. Ela alimenta dados pela rede de perímetro por meio de um
firewall de perímetro.
•Rede de perímetro
Essa rede, geralmente chamada de DMZ (zona desmilitarizada) ou rede de
borda, vincula usuários de entrada a servidores Web ou a outros serviços. Em
seguida, os servidores Web os vinculam às redes internas por meio de um
firewall interno.
•Redes internas
As redes internas vinculam os servidores internos, como o SQL Server e os
usuários internos.
Em uma empresa, normalmente existem dois firewalls diferentes — o firewall de
perímetro e o firewall interno. Embora as tarefas desses firewalls sejam
semelhantes, a ênfase dada é diferente, já que o firewall de perímetro concentra–
se no fornecimento de uma limitação aos usuários externos não confiáveis,
enquanto o firewall interno se concentra em impedir que os usuários externos
acessem a rede interna e em limitar as atividades dos usuários internos. Para
obter mais informações sobre o design de firewall de perímetro, consulte "Design
de firewall de perímetro".
As redes estão descritas na Figura 1

Figura 1
Arquitetura de rede de uma empresa
Entradas do design
O firewall verifica os pacotes IP que chegam e bloqueia os que detecta como
invasores. Alguns bloqueios podem ser feitos reconhecendo, por padrão, que
determinados pacotes são ilegais. Uma outra opção é configurar o firewall para
bloquear determinados pacotes. O protocolo TCP/IP foi criado há muitos anos,
sem qualquer conceito de entrada ilegal ou invasão de computadores, portanto,
possui muitos pontos fracos. Por exemplo, o protocolo ICMP foi projetado para
ser um mecanismo de sinalização no TCP/IP, no entanto, está vulnerável a
abusos, podendo ter problemas, como ataques DoS (Negação de Serviço). Um
firewall interno possui requisitos mais precisos que um firewall de perímetro.
Isso ocorre porque é mais difícil controlar o tráfego interno, uma vez que o seu
destino legítimo pode ser qualquer servidor na rede interna.
Existem muitos tipos de firewall, diferenciados, em parte, pelo preço, mas
também pelos recursos e pelo desempenho. Geralmente, o firewall mais caro é o
que possui maior capacidade e mais recursos. Posteriormente, neste módulo, os
firewalls serão agrupados em classes para serem diferenciados, no entanto,
antes de escolher um firewall, você deve identificar quais são as suas
necessidades. Observe as considerações a seguir:
•Orçamento
•Recursos existentes
•Disponibilidade
•Escalabilidade
•Recursos necessários

Orçamento
Qual é o orçamento disponível? Todos os firewalls do ambiente de rede devem
oferecer um serviço da mais alta qualidade e ser, ao mesmo tempo, econômicos.
No entanto, esteja ciente de como a sua empresa pode ser prejudicada se o
firewall for muito limitado pelo fator preço. Considere o custo do tempo de
inatividade na sua empresa caso o serviço seja suspenso devido a um ataque de
negação de serviço.
Recursos existentes
Existem recursos existentes que possam ser usados para reduzir custos? Talvez
já existam firewalls no ambiente que possam ser reutilizados e roteadores que
possam ter um conjunto de recursos de firewall instalado.
Disponibilidade
A sua empresa precisa que o firewall esteja permanentemente disponível? Se
você oferecer um recurso de servidor Web público que precise estar sempre
disponível, será necessário que o firewall funcione ininterruptamente.
Independentemente do firewall, sempre há uma probabilidade de falha. Então,
como você pode minimizar esse problema? A disponibilidade de um firewall pode
ser melhorada por meio de dois métodos:
•Componentes redundantes
A duplicação de alguns componentes com maior probabilidade de falha, como a
fonte de alimentação, aumenta a resistência do firewall, uma vez que seu
funcionamento não é afetado mediante a falha de um componente.
Normalmente, os firewalls de baixo custo não dispõem de opções redundantes,
pois estas, além de caras, não acrescentam nada ao seu poder de
processamento.
•Dispositivos duplicados
A duplicação do dispositivo do firewall proporciona um sistema totalmente
resistente, mas novamente a um custo considerável, uma vez que ele também
exige um cabeamento de rede totalmente duplicado e conectividade dupla nos
roteadores ou switches aos quais o firewall se conecta. No entanto, dependendo
do firewall, é possível duplicar a taxa de transferência para compensar.
Teoricamente, todos os firewalls, do menor ao maior, podem ser duplicados,
mas na prática é necessário um mecanismo de alternância de software que
firewalls menores podem não conter.
Escalabilidade
Quais são os requisitos de taxa de transferência dos firewalls? A taxa de
transferência pode ser considerada em termos de bits por segundo e de pacotes
transferidos por segundo. Se esta for a primeira vez que você lida com isso,

talvez não saiba quais são as taxas de transferência e, mesmo que tudo dê certo,
a taxa de transferência da Internet pode aumentar rapidamente. Como você
poderá lidar com um aumento? Você deve selecionar uma solução de firewall que
possa aumentar de acordo com o aumento da taxa de transferência. O firewall
pode aumentar com a adição de mais componentes ou você pode instalar outro
firewall paralelamente?
Recursos necessários
São necessários quais recursos de firewall? Com base em avaliações de risco
relativas aos serviços prestados na empresa, você pode determinar quais tipos de
recurso de firewall são necessários para proteger seus computadores. Há
necessidade de VPNs (Redes Virtuais Privadas), já que o design é afetado?
Início da página
Defesa e ataques contra o sistema
Esta seção apresenta um resumo dos ataques ao sistema mais conhecidos,
juntamente com as razões para usar o serviço do firewall como uma primeira
linha de defesa.
Ataques externos
Com freqüência, a Internet é usada como ferramenta por pessoas que desejam
prejudicar empresas ou roubar segredos comerciais para obter vantagem
competitiva. Se você instalar um firewall de perímetro e verificar o log de
invasões, ficará surpreso pelo volume. A maioria das invasões é apenas para ver
se a máquina responde e quais serviços estão sendo executados. Isso pode
parecer inofensivo, mas se o atacante descobrir a sua máquina, ele poderá
atacar o seu serviço e identificar seus pontos fracos.
Ataques internos
Nem todos os ataques são provenientes da Internet. Você também deve proteger
dados sigilosos de usuários internos que estão na rede corporativa. A maioria das
empresas possui dados sigilosos que devem ser protegidos contra determinados
usuários na rede interna, inclusive funcionários, fornecedores, empreiteiros e
clientes.
Ameaças de invasão
As ameaças de invasão podem tomar muitas formas, e descrevê–las aqui serviria
apenas a uma finalidade restrita, pois são criadas ameaças novas todos os dias.
Algumas invasões, como efetuar ping em um endereço de servidor, podem
parecer inofensivas. No entanto, depois de descobrir a presença de um servidor,

o hacker poderá tentar um ataque mais sério. Isso significa que todas as invasões
devem ser consideradas potencialmente prejudiciais. Eis algumas das principais
invasões:
•Sniffers de pacotes
Um sniffer é um aplicativo de software ou um dispositivo de hardware que se
conecta à LAN e captura informações de quadros Ethernet. A intenção original
desses sistemas foi solucionar problemas e analisar o tráfego da Ethernet ou
investigar detalhadamente os quadros para examinar pacotes IP individuais. Os
sniffers operam em modo promíscuo, ou seja, eles escutam todos os pacotes
que passarem pelo cabo físico. Muitos aplicativos, como o Telnet, enviam
informações sobre nome de usuário e senha em texto não criptografado que
pode ser exibido pelos sniffers. Isso significa que um hacker pode acessar
muitos aplicativos utilizando um sniffer.
A ação do sniffer não pode ser impedida por um firewall, uma vez que ele não
gera tráfego de rede, e muitos dos invasores que podem estar utilizando um
sniffer são os seus próprios usuários, dentro de um firewall. É possível baixar
facilmente um software sniffer grátis pela Internet, e seus usuários podem
executá–lo em PCs, examinando os pacotes à medida que passam. Se você
estiver executando sistemas operacionais Microsoft® Windows® nos PCs,
normalmente os usuários irão precisar de direitos de acesso de administrador
para executar um sniffer, o que limita o número de usuários que podem tentar
uma ação como essa. No entanto, os usuários com direitos de administrador,
que podem ser muitos, conseguem executar um sniffer. Além do acesso a dados
confidenciais, eles podem ver senhas em texto não criptografado, como
mencionado anteriormente. Como muitas pessoas usam a mesma senha para os
aplicativos, os invasores podem deduzir quais serão as senhas codificadas e
obter conseguir acesso. Existem várias medidas para combater a ação do
sniffer. A principal medida é usar senhas criptografadas (mas este tópico não
será abordado neste módulo).
•Spoofing de IP
O spoofing de IP ocorre quando o endereço de origem de um pacote IP é
alterado para ocultar a identidade do remetente. O roteamento na Internet usa
apenas o endereço de destino para enviar um pacote, ignorando o endereço de
origem. Por isso, um hacker consegue enviar um pacote destrutivo para o seu
sistema, ocultando a origem para que você não saiba de onde ele veio. O
spoofing não é necessariamente destrutivo, mas sinaliza que uma invasão está
próxima. O endereço pode estar fora de sua rede (para ocultar a identidade do
invasor) ou pode ser um de seus endereços internos confiáveis com acesso
privilegiado. O spoofing, em geral, é usado por ataques de negação de serviço,
descritos posteriormente neste módulo.
•Ataques de negação de serviço
Os ataques de DoS (negação de serviço) são um dos mais difíceis de evitar. Eles
são diferentes dos outros tipos de ataque porque não causam dano permanente
à rede. Em vez disso, eles tentam interromper o funcionamento da rede,
bombardeando um computador específico (dispositivo de servidor ou de rede)

ou degradando a taxa de transferência de conexões de rede até chegar ao ponto
em que o desempenho é tão lento, que provoca irritação dos clientes e a perda
de negócios para a empresa. O DDoS (ataque de negação de serviço
distribuído) é um ataque iniciado em vários computadores, que concentra o
bombardeamento no seu sistema. Os computadores de ataque não iniciam o
ataque sozinho, mas se infiltram devido à vulnerabilidades em sua própria
segurança.
•Ataques contra a camada de aplicativo
Os ataques à camada de aplicativo normalmente são os mais divulgados e,
geralmente, aproveitam os pontos fracos já conhecidos de aplicativos, como em
servidores Web e de bancos de dados. O problema, particularmente para os
servidores Web, é que eles são criados para serem acessados por usuários
públicos desconhecidos e não confiáveis. A maioria dos ataques é feita contra
deficiências já conhecidas no produto. Isso significa que a melhor defesa é
instalar as últimas atualizações dos fabricantes. O terrível worm Slammer do
SQL (Structured Query Language) afetou 35.000 sistemas em muito pouco
tempo desde seu lançamento em janeiro de 2003. O worm explorou um
problema conhecido no Microsoft® SQL Server 2000, para o qual a Microsoft
tinha emitido uma correção em agosto de 2002. Esse worm aproveitou o fato de
que muitos administradores não haviam aplicado a atualização recomendada e
não tinham adquirido firewalls adequados (que poderiam descartar os pacotes
destinados à porta usada pelo worm). O firewall é apenas uma barreira nessas
situações. Os fabricantes recomendam que as atualizações sejam aplicadas a
todos os produtos, particularmente para impedir ataques à camada de
aplicativo.
•Varredura de rede
A varredura de rede é a verificação de redes para descobrir endereços IP
válidos, nomes DNS (Sistema de Nome de Domínio) e portas IP antes de se
iniciar um ataque. A varredura de rede em si não é prejudicial. No entanto,
descobrir quais endereços estão em uso pode ajudar alguém a iniciar um
ataque hostil. Se você procurar um firewall nos logs, verificará que a maioria
das invasões é dessa natureza. As investigações comuns incluem o exame das
portas de escuta dos protocolos TCP e UDP, bem como de outras portas de
escuta bastante conhecidas, como as usadas pelo Microsoft SQL Server,
NetBIOS, HTTP e por servidores SMTP. Todas essas investigações buscam uma
resposta, que informa ao hacker que o servidor existe e executa um desses
serviços. Muitos desses exames podem ser impedidos pelo roteador de limite ou
um firewall, mas desligar alguns dos serviços pode restringir a capacidade de
diagnóstico de rede.
Início da página
Definição do dispositivo
Um firewall é um mecanismo para controlar o fluxo do tráfego IP entre duas

edes. Os dispositivos de firewall costumam operar no L3 do modelo OSI, embora
alguns modelos também possam operar em níveis superiores.
Um firewall interno, em geral, proporciona os seguintes benefícios:
•Defender os servidores internos contra ataques de rede.
•Aplicar restrições às diretivas de uso e acesso à rede.
•Monitorar o tráfego e gerar alertas ao detectar padrões suspeitos.
É importante observar que os firewalls reduzem apenas alguns tipos de riscos de
segurança. Um firewall geralmente não evita o dano que pode ser causado a um
servidor com uma vulnerabilidade de software. Os firewalls devem ser
implementados como parte da ampla arquitetura de segurança de uma empresa.
Início da página
Recursos de firewall
Dependendo dos recursos que um firewall pode suportar, o tráfego será
permitido ou bloqueado por meio de várias técnicas. Essas técnicas oferecem
diferentes graus de proteção com base na capacidade do firewall. Os recursos de
firewall a seguir estão listados em ordem crescente de complexidade:
•Filtros de entrada de adaptador de rede
•Filtros estáticos de pacotes
•NAT (Conversão de Endereço de Rede)
•Inspeção com informações de estado
•Inspeção no nível de circuito
•Filtragem da camada de aplicativo
Em geral, os firewalls que oferecem recursos complexos também oferecem
suporte para os recursos mais simples. No entanto, você deve ler atentamente as
informações do fornecedor ao escolher um firewall, pois podem existir diferenças
sutis entre a capacidade implícita e a real de um firewall. A seleção de um
firewall normalmente envolve o questionamento sobre os recursos e o teste para
garantir que o produto possa de fato ter um desempenho segundo as
especificações.
Filtros de entrada de adaptador de rede
A filtragem de entrada do adaptador de rede examina os endereços de origem ou
de destino e outras informações no pacote de entrada, assim como bloqueia ou

permite que esse pacote prossiga. Essa filtragem aplica–se apenas ao tráfego de
entrada e não pode controlar o tráfego de saída. Ela compara os endereços IP e
os números de porta para UDP e TCP, bem como o protocolo do tráfego, TCP,
UDP e GRE (Generic Routing Encapsulation). A filtragem de entrada para o
adaptador de rede permite uma negação rápida e eficiente de pacotes de entrada
padrão que atendem aos critérios configurados no firewall. No entanto, ela pode
ser facilmente contornada, uma vez que compara apenas os cabeçalhos do
tráfego IP e trabalha com base na hipótese básica de que o tráfego sendo filtrado
segue os padrões IP e não é capaz de escapar da filtragem.
Filtros estáticos de pacotes
Os filtros estáticos de pacotes são parecidos com os filtros de entrada de
adaptador de rede no sentido de que eles simplesmente fazem correspondência
com cabeçalhos de IP para determinar se será ou não permitida a passagem do
tráfego pela interface. No entanto, os filtros estáticos de pacotes permitem o
controle sobre as comunicações de entrada e de saída com uma interface. Além
disso, normalmente os filtros estáticos de pacotes permitem uma função
adicional sobre a filtragem do adaptador de rede que é a de verificar se o bit
ACK (Acknowledged) está definido no cabeçalho IP. O bit ACK informa sobre a
possibilidade de o pacote ser uma solicitação nova ou uma solicitação de retorno
de uma solicitação original. Ele não verifica se o pacote foi originalmente
enviado pela interface que o recebe, apenas verifica se o tráfego que chega à
interface parece ser de retorno com base nas convenções dos cabeçalhos IP.
Essa técnica aplica–se apenas ao protocolo TCP e não ao UDP. Assim como a
filtragem de entrada do adaptador de rede, a filtragem estática de pacotes é
muito rápida, mas sua capacidade é limitada, podendo ser evitada por um
tráfego com habilidades específicas.
Conversão de endereço de rede
No intervalo de endereços IP mundial, determinados intervalos são designados
como endereços particulares. Esses intervalos de endereços devem ser usados
na empresa e não possuem significado na Internet. Como o tráfego destinado a
qualquer um desses endereços IP não pode ser roteado pela Internet, a
atribuição de um endereço particular a seus dispositivos internos oferece–lhes
alguma proteção contra invasões. No entanto, esses dispositivos internos
freqüentemente precisam acessar a Internet e, por isso, a NAT converte o
endereço particular em um endereço da Internet.
Embora a NAT não seja estritamente uma tecnologia de firewall, ocultar o
endereço IP real de um servidor impede que os atacantes obtenham informações
valiosas sobre o servidor.
Inspeção com informações de estado
Na inspeção com informações de estado, todo o tráfego de saída é registrado em

uma tabela de estado. Quando o tráfego de conexão volta para a interface, a
tabela de estado é verificada para garantir que o tráfego tenha sido originado
nessa interface. A inspeção com informações de estado é um pouco mais lenta do
que a filtragem estática de pacotes. No entanto, ela garante que o tráfego poderá
passar apenas se corresponder aos requisitos do tráfego de saída. A tabela de
estado contém itens como endereço IP de destino, endereço IP de origem, a
porta que está sendo chamada e host originador.
Determinados firewalls podem armazenar mais informações (como os fragmentos
IP enviados e recebidos) na tabela de estado enquanto outros armazenam menos.
O firewall pode verificar se o tráfego é processado quando todas ou somente
algumas informações fragmentadas retornam. Cada fornecedor de firewall
implementa o recurso de inspeção com informações de estado de forma
diferente. Por isso, você deve ler atentamente a documentação do firewall. O
recurso de inspeção com informações de estado geralmente ajuda a reduzir o
risco causado pelo reconhecimento de rede e pelo spoofing de IP.
Inspeção no nível de circuito
Com a filtragem no nível de circuito é possível inspecionar sessões em oposição
às conexões ou pacotes. Uma sessão pode incluir várias conexões. Assim como a
filtragem dinâmica de pacotes, as sessões são estabelecidas apenas em resposta
à solicitação de um usuário. A filtragem do nível de circuito oferece suporte
embutido para protocolos com conexões secundárias, como FTP e fluxo de mídia.
Normalmente, ela ajuda a reduzir o risco apresentado pelo reconhecimento de
rede, DoS e ataques de spoofing de IP.
Filtragem da camada de aplicativo
O nível mais sofisticado de inspeção do tráfego de firewall é a filtragem no nível
do aplicativo. Filtros de aplicativo de boa qualidade permitem a análise do fluxo
de dados de um determinado aplicativo e fornecem um processamento específico
ao aplicativo. Esse processamento inclui a inspeção, a triagem ou o bloqueio, o
redirecionamento e a modificação de dados à medida que passam pelo firewall.
Este mecanismo é usado para proteger contra, por exemplo, comandos SMTP
sem segurança ou ataques contra DNS interno. Normalmente, podem ser
adicionadas ao firewall ferramentas de terceiros para triagem de conteúdo, como
detecção de vírus, análise léxica e categorização de sites.
O firewall na camada de aplicativo pode inspecionar muitos protocolos diferentes
com base no tráfego que passa por ele. Diferentemente de um firewall de proxy
que em geral inspeciona o tráfego na Internet, como HTTP, download de FTP e
SSL, o firewall na camada de aplicativo possui um controle muito maior sobre a
maneira como qualquer tráfego passa por ele. Por exemplo, um firewall de
camada de aplicativo pode permitir somente a passagem do tráfego de UDP que
se origina no limite do firewall. Se for preciso que um host da Internet examine a
porta em relação a um firewall com informações de estado para ver se ele
permitiu o tráfego DNS no ambiente, o exame da porta provavelmente mostrará

que a famosa porta associada ao DNS estava aberta, no entanto, uma vez que o
ataque é armado, o firewall com informações de estado recusará as solicitações
porque não foram originadas internamente. Um firewall na camada de aplicativo
pode abrir portas de forma dinâmica com base na possibilidade de o tráfego se
originar internamente.
O recurso do firewall na camada de aplicativo ajuda a reduzir o risco
apresentado pelo spoofing de IP, DoS, alguns ataques na camada de aplicativo,
reconhecimento de rede e ataques de vírus e cavalos de Tróia. A desvantagem de
um firewall na camada de aplicativo é que ele exige uma capacidade de
processamento muito maior e, normalmente, são mais lentos na passagem do
tráfego do que os firewalls com informações de estado ou de filtragem estática.
O mais importante ao usar firewalls na camada de aplicativo é determinar sua
atividade nessa camada.
A filtragem de camada de aplicativo é amplamente usada para proteger os
serviços expostos publicamente. Se a sua empresa possuir uma loja online que
coleta números de cartão de crédito e outras informações pessoais sobre os
clientes, será prudente tomar as precauções de mais alto nível para proteger
esses dados. O recurso de camada de aplicativo garante que o tráfego que está
passando por uma porta seja apropriado. Diferentemente dos firewalls de filtro
de pacote ou de inspeção com informações de estado, que simplesmente
verificam a porta e os endereços IP de origem e de destino, os firewalls que
oferecem suporte ao recurso de filtragem de camada de aplicativo podem
inspecionar os dados e os comandos que passam de um lado para o outro.
A maioria dos firewalls que oferecem suporte ao recurso de camada de aplicativo
possui apenas a filtragem de camada de aplicativo para o tráfego de texto não
criptografado, como um serviço de mensagens com reconhecimento de proxy,
HTTP e FTP. É importante lembrar que um firewall que oferece suporte a esse
recurso pode controlar o tráfego que entra e sai do ambiente. Outra vantagem
desse recurso é a capacidade de inspecionar o tráfego DNS para que procure
comandos específicos ao DNS à medida que passa pelo firewall. Essa camada
adicional de proteção garante que os usuários ou os invasores não irão
dissimular informações em tipos de tráfego permitidos.
Início da página
Classes de firewall
A seção a seguir apresenta várias classes de firewalls, cada uma fornecendo
determinados recursos de firewall. É possível usar classes de firewall específicas
para responder a solicitações específicas no design de uma arquitetura de TI.
O agrupamento de firewalls em classes permite a abstração do hardware em
relação às solicitações do serviço. As solicitações de serviço podem ser
comparadas aos recursos da classe. Contanto que um firewall se encaixe em uma
classe específica, ele poderá oferecer suporte a todos os serviços dessa classe de
firewalls.

As diversas classes são as seguintes:
•Classe 1 – Firewalls pessoais
•Classe 2 – Firewalls de roteador
•Classe 3 – Firewalls de hardware low–end
•Classe 4 – Firewalls de hardware high–end
•Classe 5 – Firewalls de servidor high–end
É importante compreender que há sobreposição de algumas dessas classes. Isso
ocorre naturalmente porque a sobreposição permite que um tipo de solução de
firewall estenda várias classes. Muitas classes também podem ser atendidas por
mais de um modelo de hardware do mesmo fornecedor, de modo que a empresa
possa escolher um modelo adequado às suas necessidades atuais e futuras. Além
do preço e do conjunto de recursos, os firewalls podem ser classificados com
base no desempenho (ou taxa de transferência). No entanto, os fabricantes não
fornecem nenhum dado de taxa de transferência para a maioria das classes de
firewalls. Nos locais em que eles são fornecidos (geralmente para dispositivos de
firewall de hardware), nenhum processo de medida padrão é adotado, o que
dificulta a comparação entre os fabricantes. Por exemplo, uma medida é o
número de bps (bits por segundo), mas como o firewall na verdade está
transportando pacotes IP, essa medida não terá sentido se o tamanho do pacote
usado para medir a taxa não for incluído.
As subseções a seguir definem detalhadamente as classes de firewall.
Início da página
Classe 1—Firewall pessoal
Um firewall pessoal é definido como um serviço de software executado em um
sistema operacional que oferece ao PC (Computador Pessoal) a capacidade de
um firewall simples. Com o crescimento do número de conexões permanentes
com a Internet (em oposição às conexões dial–up), o uso de firewalls pessoais
aumentou.
Embora o firewall pessoal tenha sido criado para proteger um único computador
pessoal, ele também é capaz de proteger uma rede pequena, se o computador no
qual ele estiver instalado compartilhar a conexão de Internet com outros
computadores da rede interna. No entanto, o desempenho de um firewall pessoal
é limitado e degradará o desempenho do computador pessoal no qual se
encontra instalado. Os mecanismos de proteção normalmente são menos
eficientes do que uma solução de firewall dedicada, pois eles, em geral, se
limitam a bloquear endereços IP e de porta, embora a necessidade de proteção
em um computador pessoal seja menor.
Os firewalls pessoais podem vir gratuitamente em um sistema operacional ou a

um custo muito baixo. Eles são adequados para a finalidade pretendida, mas não
devem ser considerados para uso corporativo, mesmo que para pequenas filiais
satélite, devido à limitação de desempenho e funcionalidade. No entanto, eles
são ideais para usuários móveis em computadores laptop.
A tabela a seguir mostra os recursos que podem estar disponíveis em firewalls
pessoais. Eles podem variar muito no que se refere a capacidade e preço. No
entanto, a falta de um recurso específico, especialmente em um laptop, pode não
ter muita importância.
Tabela 1: Classe 1—Firewalls pessoais
Atributo do firewall
Recursos básicos que
contam com suporte
Valor
A maioria dos firewalls pessoais tem suporte para filtros
estáticos de pacotes, NAT e de inspeção com
informações de estado, enquanto alguns têm suporte
para filtragem de inspeção no nível de circuito e/ou na
camada de aplicativo.
Configuração
Bloquear ou permitir
endereços IP
Bloquear ou permitir
números de protocolo
ou de porta
Bloquear ou permitir
mensagens ICMP de
entrada
Controlar o acesso de
saída
Proteção do aplicativo
Alertas audíveis ou
visíveis
Arquivo de log de
ataques
Alertas em tempo real
Suporte a VPN
Automática (opção manual também disponível)
Sim
Sim
Sim
Sim
Possivelmente
Possivelmente
Possivelmente
Depende do produto
Geralmente não
Gerenciamento remoto Geralmente não

Atributo do firewall
Suporte do fabricante
Opção de alta
disponibilidade
Número de sessões
simultâneas
Valor
Varia muito (depende do produto)
Não
de 1 a 10
Capacidade de
atualização modular
(hardware ou software)
De nenhuma a limitada
Faixa de preço
Acessível (gratuito em alguns casos)
Vantagens
As vantagens dos firewalls pessoais são:
•Preço acessível
Quando for necessário apenas um número limitado de licenças, os firewalls
pessoais serão uma opção econômica. Um firewall pessoal está integrado a
versões do Windows XP. Produtos adicionais que funcionam com outras versões
do Windows ou outros sistemas operacionais estão disponíveis gratuitamente
ou a um preço acessível.
•Fáceis de configurar
Os produtos de firewall pessoal tendem a ter configurações básicas que
funcionam facilmente, com opções de configuração simples e diretas.
Desvantagens
As desvantagens dos firewalls pessoais são:
•Difíceis de gerenciar de modo centralizado
Os firewalls pessoais precisam ser configurados em cada cliente, o que adiciona
sobrecarga ao gerenciamento.
•Possuem somente controle básico
A configuração tende a ser uma combinação de filtragem estática de pacotes e
bloqueio baseado em permissões somente de aplicativos.
•Limitações de desempenho
Os firewalls pessoais são criados para proteger um único PC. Usá–los em um
computador pessoal que serve como roteador para uma pequena rede levará a
uma degradação do desempenho.

Início da página
Classe 2—Firewall de roteador
Os roteadores geralmente oferecem suporte a um ou mais recursos de firewall
abordados anteriormente; eles podem ser subdivididos em dispositivos low–end
criados para conexões com a Internet e em roteadores tradicionais high–end. Os
roteadores low–end oferecem recursos básicos de firewall para bloquear e
permitir endereços IP específicos e números de portas, bem como usar NAT para
ocultar endereços IP internos. Eles geralmente oferecem o recurso de firewall
como padrão, otimizado para bloquear invasões da Internet e, embora não
precisem de configuração, eles podem ser refinados com mais configurações.
Os roteadores high–end podem ser configurados para restringir o acesso
impedindo as invasões mais óbvias, como os pings, e implementando outras
restrições de endereço IP e de porta por meio do uso de ACLs (Listas de Controle
de Acesso). Outros recursos de firewall podem estar disponíveis para
proporcionar uma filtragem de pacote com informações de estado em alguns
roteadores. Em roteadores high-end, a capacidade do firewall é semelhante ao
de um dispositivo de firewall de hardware, a um custo menor, porém, também
com baixa taxa de transferência.
Tabela 2 Classe 2—Firewall de roteador
Atributo do firewall
Recursos básicos que
contam com suporte
Valor
A maioria dos firewalls de roteador oferece suporte a
filtros estáticos de pacotes. Normalmente, os roteadores
low-end têm suporte para NAT, e os roteadores high-end
podem ter suporte para a filtragem de inspeção com
informações de estado e/ou na camada de aplicativo.
Configuração
Bloquear ou permitir
endereços IP
Bloquear ou permitir
números de protocolo
ou de porta
Bloquear ou permitir
mensagens ICMP de
entrada
Controlar o acesso de
saída
Geralmente automática em roteadores low-end (com
opções manuais). Freqüentemente manual em roteadores
high-end
Sim
Sim
Sim
Sim

Atributo do firewall Valor
Proteção do aplicativo Possivelmente
Alertas audíveis ou
visíveis
Arquivo de log de
ataques
Geralmente
Em muitos casos
Alertas em tempo real Em muitos casos
Suporte para VPN
Gerenciamento
remoto
Freqüentemente em roteadores low-end, não tão comum
em roteadores high-end. Há disponibilidade de servidores
ou dispositivos separados. dedicados a esta tarefa.
Sim
Suporte do fabricante Normalmente limitado em roteadores low-end e bom em
roteadores high-end.
Opção de alta
disponibilidade
disponível
Número de sessões
simultâneas
Capacidade de
atualização modular
(hardware ou
software)
Faixa de preço
Ponto mínimo: não
Ponto máximo: sim
10 – 1.000
Ponto mínimo: não
Ponto máximo: limitado
Baixo a alto
Vantagens
As vantagens dos firewalls de roteador são:
•Solução de baixo custo
A ativação de um recurso de firewall de roteador existente não pode adicionar
nenhum custo ao preço do roteador e não requer hardware adicional.
•A configuração pode ser consolidada
A configuração de firewalls de roteador pode ser realizada quando o roteador
for configurado para operações normais, minimizando assim o esforço de

gerenciamento. Essa solução é ideal para escritórios satélite, já que o hardware
de rede e o gerenciamento são simplificados.
•Proteção do investimento
A configuração e o gerenciamento de firewalls de roteador são conhecidos pela
equipe operacional, não exigindo um novo treinamento. O cabeamento da rede
é simplificado porque nenhum outro hardware foi instalado, o que também
simplifica o gerenciamento da rede.
Desvantagens
As desvantagens dos firewalls de roteador são:
•Funcionalidade limitada
Em geral, os roteadores low–end oferecem somente recursos básicos de
firewall. Normalmente, os roteadores high–end oferecem recursos de firewall
de nível superior, porém, pode ser necessária uma configuração significativa.
Muito dessa configuração se faz pela adição de controles que são facilmente
esquecidos, dificultando, de alguma forma, a configuração correta.
•Possuem somente controle básico
A configuração tende a ser uma combinação de filtragem estática de pacotes e
bloqueio baseado em permissões somente de aplicativos.
•Impacto no desempenho
O uso de um roteador como um firewall prejudica o desempenho do roteador e
torna a função de roteamento lenta, o que é sua principal tarefa.
•Desempenho do arquivo de log
O uso de um arquivo de log para capturar atividades incomuns pode reduzir
drasticamente o desempenho do roteador, especialmente quando ele já estiver
sendo atacado.
Início da página
Classe 3—Firewall de hardware low–end
No ponto mínimo do mercado de firewall de hardware encontram–se as unidades
Plug and Play, exigindo uma configuração menor ou nenhuma configuração.
Esses dispositivos freqüentemente incorporam uma funcionalidade de switch
e/ou de VPN. Os firewalls de hardware low–end são adequados para as pequenas
empresas e para uso interno em empresas maiores. Eles costumam oferecer
recursos de filtragem estática e funcionalidade básica de gerenciamento remoto.
Os dispositivos oferecidos por fabricantes maiores podem executar o mesmo
software que os dispositivos high–end, proporcionando um caminho de
atualização, caso necessário.

Tabela 3 Classe 3—Firewall de hardware low–end
Atributo do firewall
Recursos básicos que
contam com suporte
Configuração
Bloquear ou permitir
endereços IP
Valor
A maioria dos firewalls de hardware low–end tem
suporte para filtros estáticos de pacotes e NAT e pode
ter suporte para a filtragem de inspeção com
informações de estado e/ou na camada de aplicativo.
Automática (opção manual também disponível)
Sim
Bloquear ou permitir
números de protocolo ou
de porta
Sim
Bloquear ou permitir
mensagens ICMP de
entrada
Controlar o acesso de
saída
Proteção do aplicativo
Alertas audíveis ou
visíveis
Arquivo de log de
ataques
Alertas em tempo real
Suporte para VPN
Gerenciamento remoto
Suporte do fabricante
Opção de alta
disponibilidade
disponível
Número de sessões
simultâneas
Capacidade de
Sim
Sim
Geralmente não
Geralmente não
Geralmente não
Geralmente não
Às vezes
Sim
Limitada
Geralmente não
> 10–7500
Limitada

Atributo do firewall
atualização modular
(hardware ou software)
Faixa de preço
Valor
Acessível
Vantagens
As vantagens dos firewalls de hardware low–end são:
•Baixo custo
Os firewalls low–end podem ser adquiridos por um baixo custo.
•Configuração simples
Quase nenhuma configuração é necessária.
Desvantagens
As desvantagens dos firewalls de hardware low–end são:
•Funcionalidade limitada
Em geral, os firewalls de hardware low–end oferecem somente funcionalidades
básicas de firewall. Eles não podem ser executados ao mesmo tempo devido à
redundância.
•Taxa de transferência baixa
Os firewalls de hardware low–end não foram criados para lidar com conexões
com alta taxa de transferência, o que pode causar gargalos.
•Suporte limitado do fabricante
Como são itens de baixo custo, o suporte do fabricante costuma ser limitado a
Emails e/ou a um site.
•Capacidade de atualização limitada
Geralmente, não pode haver atualizações de hardware, embora normalmente
existam atualizações periódicas de firmware disponíveis.
Início da página
Classe 4—Firewall de hardware high–end
No ponto máximo do mercado de firewall de hardware, existem produtos
altamente resistentes e de alto desempenho, adequados à empresa ou ao
provedor de serviços. Em geral, eles oferecem a melhor proteção, sem afetar o
desempenho da rede.

A resistência é alcançada adicionando–se um segundo firewall, executado como
uma unidade de espera ativa que mantém a tabela das conexões atuais por meio
da sincronização automática com informações de estado.
Redes conectadas à Internet precisam usar firewalls, pois as invasões são
constantes. A tentativa de ataques DoS, roubos e corrupção de dados ocorrem o
tempo todo. Deve–se considerar a implantação de unidades de firewall de
hardware high–end em escritórios centrais ou matrizes.
Tabela 4: Classe 4—Firewall de hardware high–end
Atributo do firewall
Recursos básicos que
contam com suporte
Valor
A maioria dos firewalls de hardware high–end tem
suporte para filtros estáticos de pacotes e NAT e pode
ter suporte para a filtragem de inspeção com
informações de estado e/ou na camada de aplicativo.
Configuração
Bloquear ou permitir
endereços IP
Geralmente manual
Sim
Bloquear ou permitir Sim
números de protocolo ou
de porta
Bloquear ou permitir
mensagens ICMP de
entrada
Controlar o acesso de
saída
Proteção do aplicativo
Alertas audíveis ou
visíveis
Arquivo de log de
ataques
Alertas em tempo real
Suporte a VPN
Gerenciamento remoto
Suporte do fabricante
Sim
Sim
Potencialmente
Sim
Sim
Sim
Potencialmente
Sim
Bom

Atributo do firewall
Opção de alta
disponibilidade
disponível
Número de sessões
simultâneas
Capacidade de
atualização modular
(hardware ou software)
Faixa de preço
Valor
Sim
> 7500–500.000
Sim
Elevado
Vantagens
As vantagens dos firewalls de hardware high–end são:
•Alto desempenho
Os produtos de firewall de hardware foram criados para uma única finalidade e
oferecem altos níveis de bloqueio contra invasões, juntamente com uma
degradação mínima do desempenho.
•Alta disponibilidade
Os firewalls de hardware high–end podem ser conectados uns aos outros para
obter a disponibilidade e o balanceamento de carga ideais.
•Sistemas modulares
O hardware e o software podem ser atualizados de acordo com os novos
requisitos. As atualizações de hardware podem incluir portas Ethernet
adicionais, ao passo que as atualizações de software podem incluir a detecção
de novos métodos contra invasão.
•Gerenciamento remoto
A funcionalidade de gerenciamento remoto dos firewalls de hardware high–end
é melhor que a de seus equivalentes low–end.
•Resistência
Os firewalls de hardware high–end podem ter recursos de disponibilidade e
resistência, como o modo de espera ativo com uma segunda unidade.
•Filtragem de camada de aplicativo
Diferentemente dos firewalls low–end, que em geral fazem apenas a filtragem
na camada 3 e, possivelmente, na camada 4 do modelo OSI, os firewalls de
hardware high–end fornecem filtragem nas camadas de 5 a 7 para os
aplicativos já conhecidos.

Desvantagens
As desvantagens dos firewalls de hardware high–end são:
•Alto custo
Os firewalls de hardware high–end costumam ser caros. Embora possam ser
adquiridos por $100, o custo de um firewall corporativo é muito superior e, com
freqüência, tem como base o número de sessões simultâneas, a taxa de
transferência e os requisitos de disponibilidade.
•Configuração e gerenciamento complexos
Como esta classe de firewalls conta com capacidade muito maior do que os
firewalls low–end, sua configuração e seu gerenciamento também são mais
complexos.
Início da página
Classe 5—Firewall de servidor high–end
Os firewalls de servidor high–end adicionam capacidade de firewall a um
servidor high–end, fornecendo proteção robusta e rápida em sistemas de
hardware e software padrão. Esta abordagem se beneficia do uso de hardware
ou software conhecido. Isso proporciona um número reduzido de itens de
inventário, treinamento e gerenciamento simplificados, confiabilidade e
capacidade de expansão. Muitos firewalls de hardware high–end são
implementados em plataformas de hardware com padrão de mercado que
executam sistemas operacionais padrão (porém ocultos) e, portanto, possuem
pouca diferença, tecnicamente e em desempenho, com relação a um firewall de
servidor. No entanto, como o sistema operacional ainda está visível, o recurso de
firewall de servidor pode ser atualizado e ficar mais resistente por meio de
técnicas como o agrupamento.
Como o firewall de servidor é executado em um sistema operacional
normalmente usado, é possível adicionar mais software, recursos e
funcionalidade ao firewall de vários fornecedores (não de apenas um, como
ocorre com o firewall de hardware). O conhecimento do sistema operacional
também pode proporcionar uma proteção de firewall mais eficaz, pois para
algumas das outras classes é preciso ter bastante experiência para executar a
configuração de forma total e correta.
Esta classe é adequada caso haja grande investimento em uma determinada
plataforma de hardware ou software, pois usar a mesma plataforma para o
firewall simplifica seu gerenciamento. O recurso de cache dessa classe também
pode ser muito eficaz.
Tabela 5: Classe 5—Firewall de servidor high–end
Atributo do firewall
Recursos que contam
Valor
A maioria dos firewalls de servidor high–end tem

Atributo do firewall
com suporte
Configuração
Bloquear ou permitir
endereços IP
Valor
suporte para filtros estáticos de pacotes e NAT e pode
ter suporte para a filtragem de inspeção com
informações de estado e/ou na camada de aplicativo.
Geralmente manual
Sim
Bloquear ou permitir Sim
números de protocolo ou
de porta
Bloquear ou permitir
mensagens ICMP de
entrada
Controlar o acesso de
saída
Proteção do aplicativo
Alertas sonoros/visuais
Arquivo de log de
ataques
Alertas em tempo real
Suporte a VPN
Gerenciamento remoto
Suporte do fabricante
Opção de alta
disponibilidade
disponível
Número de sessões
simultâneas
Capacidade de
atualização modular
(hardware ou software)
Outros
Sim
Sim
Potencialmente
Sim
Sim
Sim
Potencialmente
Sim
Bom
Sim
acima de 50.000 (em vários segmentos de rede)
Sim
Sistema operacional usado com freqüência

Atributo do firewall
Valor
Faixa de preço
Elevado
Vantagens
As vantagens dos firewalls de servidor são:
•Alto desempenho
Quando executados em um servidor de tamanho adequado, esses firewalls
podem oferecer altos níveis de desempenho.
•Integração e consolidação de serviços
Os firewalls de servidor podem usar os recursos do sistema operacional no qual
são executados. Por exemplo, o software de firewall executado no sistema
operacional do Windows Server 2003 pode aproveitar a funcionalidade do
balanceamento de carga de rede embutida no sistema operacional. Além disso,
o firewall pode servir como servidor VPN, usando novamente a funcionalidade
do sistema operacional do Windows Server 2003.
•Disponibilidade, resistência e escalabilidade
Como esse firewall é executado em um hardware de PC padrão, ele possui
todos os recursos de disponibilidade, resistência e escalabilidade da plataforma
do PC no qual é executado.
Desvantagens
As desvantagens dos firewalls de servidor são:
•Exigem hardware high–end
Para obter um alto desempenho, a maioria dos produtos de firewall de servidor
exige hardware high–end no que se refere à CPU (unidade de processamento
central), memória e interfaces de rede.
•Suscetíveis a vulnerabilidades
Como os produtos de firewall de servidor são executados em sistemas
operacionais conhecidos, eles estão suscetíveis às vulnerabilidades presentes
no sistema operacional e em outros softwares executados no servidor. Embora
esse também seja o caso dos firewalls de hardware, seus sistemas operacionais
geralmente não são tão conhecidos pelos invasores quanto a maioria dos
sistemas operacionais de servidor.
Uso do firewall interno
Um firewall interno existe para controlar o acesso a e proveniente da rede

interna. Os tipos de usuário são:
•Confiáveis
Funcionários da empresa, que podem ser usuários internos saindo para a zona
de perímetro ou para a Internet; usuários externos, como os funcionários de
filiais; usuários remotos ou usuários que trabalham em casa.
•Parcialmente confiáveis
Parceiros comerciais da empresa para os quais existe um nível de confiança
maior do que para usuários não confiáveis. No entanto, este com freqüência é
um nível inferior de confiança do que o existente para os funcionários da
empresa.
•Não confiáveis
Por exemplo, usuários do site público da empresa.
Os usuários não confiáveis da Internet devem, teoricamente, acessar apenas os
servidores Web na sua zona de perímetro. Caso precisem acessar seus servidores
internos para, por exemplo, verificar os níveis de estoque, o servidor Web
confiável fará a pesquisa em nome deles. Portanto, os usuários não confiáveis
nunca devem ter permissão para ultrapassar o firewall interno.
Há vários pontos que devem ser considerados ao selecionar a classe de firewall a
ser usada nessa capacidade. A tabela a seguir realça essas questões.
Tabela 6. Pontos para escolha da classe do firewall interno
Questão
Capacidades de firewall
necessárias, conforme
especificado pelo
administrador de
segurança
Características típicas de um firewall implementado
nesta capacidade
É um equilíbrio entre o grau de segurança necessário
versus o custo do recurso e a degradação potencial do
desempenho que o aumento na segurança pode causar.
Enquanto muitas empresas desejam aproveitar a
máxima segurança oferecida por um firewall que atende
a esta capacidade, outras não querem aceitar a redução
no desempenho associada. Para sites que não sejam de
comércio eletrônico com volume muito alto, por
exemplo, são permitidos níveis inferiores de segurança
com base nos níveis superiores de taxa de transferência
obtidos pelo uso de filtros estáticos de pacotes em vez
da filtragem na camada de aplicativo.
Se o dispositivo será um depende do desempenho exigido, da confidencialidade
dispositivo físico dos dados e da freqüência da necessidade de acesso
dedicado, oferecerá pela zona de perímetro.
outra funcionalidade ou
será um firewall lógico
em um dispositivo físico
Requisitos da
Normalmente, usa–se alguma forma de registro; no

Questão
Características típicas de um firewall implementado
nesta capacidade
capacidade de
entanto, um mecanismo de monitoramento de evento
gerenciamento para o também é necessário. Você pode optar por não permitir
dispositivo de acordo a administração remota aqui para impedir que um
com o especificado pela usuário mal–intencionado administre o dispositivo
arquitetura de
remotamente.
gerenciamento da
empresa
Os requisitos de taxa de
transferência
provavelmente serão
determinados pelos
administradores de
rede e de serviços na
empresa
Eles irão variar para cada ambiente, mas a capacidade
do hardware no dispositivo ou servidor e os recursos de
firewall usados irão determinar a taxa geral de
transferência de rede.
Requisitos de
disponibilidade
Novamente, este ponto depende dos requisitos de
acesso dos servidores Web. Se eles devem
principalmente manipular as solicitações de informações
atendidas pelo fornecimento de páginas da Web, o fluxo
para as redes internas será lento. No entanto, altos
níveis de disponibilidade serão necessários no caso do
comércio eletrônico.
Regras para firewall interno
Os firewalls internos monitoram o tráfego entre as zonas de confiança de
perímetro e as internas. Os requisitos técnicos para os firewalls internos são
consideravelmente mais complexos do que aqueles para os firewalls de
perímetro, devido à complexidade dos tipos de tráfego e dos fluxos entre essas
redes.
Esta seção faz referência aos "bastion hosts". Bastion hosts são servidores
localizados na rede de perímetro que fornecem serviços a usuários internos e
externos. Exemplos de bastion hosts incluem os servidores Web e os servidores
VPN. Normalmente, o firewall interno necessitará da implantação das seguintes
regras, por padrão ou por configuração:
•Bloquear todos os pacotes por padrão.
•Na interface do perímetro, bloqueie os pacotes de entrada que parecem ter sido
originados a partir de um endereço IP interno para impedir o spoofing.
•Na interface interna, bloqueie os pacotes de saída que parecem ter sido
originados a partir de um endereço IP externo para restringir um ataque

interno.
•Permitir consultas baseadas em UDP e respostas dos servidores DNS internos
para o bastion host do DNS Resolver.
•Permitir consultas baseadas em UDP e respostas do bastion host do DNS
Resolver para os servidores DNS internos.
•Permitir consultas baseadas em TCP dos servidores DNS internos ao bastion
host do DNS Resolver, inclusive as respostas para essas consultas.
•Permitir consultas baseadas em TCP do bastion host do DNS Resolver para os
servidores DNS internos, inclusive as respostas para essas consultas.
•Permitir transferências de zonas entre o bastion host do servidor DNS externo e
os hosts de servidores DNS internos.
•Permitir Email de saída do servidor de Emails SMTP interno para o bastion host
SMTP de saída.
•Permitir Email de entrada do bastion host SMTP de entrada para o servidor de
Emails SMTP interno.
•Permitir que o tráfego que se origina no back–end nos servidores VPN
alcancem os hosts internos e as respostas retornem para os servidores VPN.
•Permitir o tráfego de autenticação para os servidores RADIUS na rede interna e
que as respostas retornem aos servidores VPN.
•Permitir que o acesso de saída da Web dos clientes internos passe por um
servidor proxy e as respostas retornem a eles.
•Suportar tráfego de autenticação de domínio do Microsoft Windows 2000/2003
entre segmentos de rede tanto para o domínio de perímetro como para o
domínio interno.
•Suportar pelo menos cinco segmentos de rede.
•Realizar inspeção de pacotes com informações de estado entre todos os
segmentos de rede que unem (firewall na camada de circuito – camadas 3 e 4).
•Suportar recursos de alta disponibilidade como failover com informações de
estado.
•Rotear tráfego por todos os segmentos de rede conectados sem usar a
conversão de endereço de rede.
Início da página

Requisitos do hardware
Os requisitos de hardware para um firewall são diferentes para firewalls
baseados em software e em hardware, da seguinte forma:
•Firewalls baseados em hardware
Esses dispositivos geralmente executam código especializado em uma
plataforma de hardware personalizada. Esses firewalls são, em geral, escalados
(com preço determinado) com base no número de conexões que podem aceitar
e na complexidade do software que devem executar.
•Firewalls baseados em software
Também são configurados com base no número de conexões simultâneas e na
complexidade do software de firewall. Existem calculadoras que podem
computar a velocidade do processador, o tamanho da memória e o espaço em
disco necessário para um servidor com base no número de conexões
suportadas. Você deve considerar outro software que possa ser executado no
servidor do firewall, como o software de balanceamento de carga e VPN. Além
disso, considere os métodos para colocar o firewall em escala para cima e para
fora. Esses métodos incluem o aumento da capacidade do sistema ao adicionar
mais processadores, memória e placas de rede e, ainda, ao usar vários sistemas
e o balanceamento de carga para espalhar a tarefa do firewall em todos eles.
Alguns produtos utilizam o SMP (Multiprocessamento Simétrico) para aumentar
o desempenho. O serviço de Balanceamento de carga de rede do Windows
Server 2003 pode oferecer tolerância a falhas, alta disponibilidade, eficiência e
aprimoramentos no desempenho para alguns produtos de firewall.
Início da página
Disponibilidade
Para aumentar a disponibilidade do firewall, este pode ser implementado como
um único dispositivo de firewall com ou sem componentes redundantes ou como
um par redundante de firewalls, incorporando algum tipo de failover e/ou
mecanismo de balanceamento de carga. As vantagens e desvantagens dessas
opções são apresentadas nas subseções a seguir.
Firewall único sem componentes redundantes
A figura a seguir apresenta a descrição de um firewall único, sem componentes
redundantes:

Figura 2
Firewall único, sem componentes redundantes
Vantagens
As vantagens de se ter um firewall único incluem:
•Baixo custo
Como existe somente um firewall, os custos de hardware e licenciamento são
baixos.
•Gerenciamento simplificado
O gerenciamento é simplificado, pois há somente um firewall para o site ou
para a empresa.
•Uma única fonte de log
Todo o log de tráfego é centralizado em um dispositivo.
Desvantagens
As desvantagens de um firewall único sem redundância são:
•Ponto único de falha
Existe um ponto único de falha para o acesso de entrada e/ou saída.
•Possibilidade de gargalo no tráfego
Um firewall único poderia causar um gargalo no tráfego, dependendo do
número de conexões e da taxa de transferência necessária.

Firewall único com componentes redundantes
A figura a seguir apresenta a descrição de um firewall único com componentes
redundantes:
Figura 3
Firewall único, com componentes redundantes
Vantagens
As vantagens de se ter um firewall único incluem:
•Baixo custo
Como existe somente um firewall, os custos de hardware e licenciamento são
baixos. O custo dos componentes redundantes, como uma fonte de alimentação,
não é alto.
•Gerenciamento simplificado
O gerenciamento é simplificado, pois há somente um firewall para o site ou
para a empresa.
•Uma única fonte de log
Todo o log de tráfego é centralizado em um dispositivo.
Desvantagens
As desvantagens de se ter um firewall único incluem:
•Ponto único de falha

Dependendo do número de componentes redundantes, pode ainda existir um
ponto único de falha para o acesso de entrada e saída.
•Custo
O custo é mais alto do que o de um firewall sem redundância e também pode
exigir uma classe superior de firewall para poder conseguir incorporar a
redundância.
•Possibilidade de gargalo no tráfego
Um firewall único poderia causar um gargalo no tráfego, dependendo do
número de conexões e da taxa de transferência necessária.
Firewalls tolerantes a falhas
Um conjunto de firewall tolerante a falhas inclui um mecanismo para duplicar
cada firewall como na figura a seguir.
Figura 4

Firewalls tolerantes a falhasVantagens
As vantagens de um conjunto de firewalls tolerantes a falhas são:
•Tolerância a falhas
Usar pares de servidores ou dispositivos pode ajudar a fornecer o nível
necessário de tolerância a falhas.
•Log de tráfego central
O log de tráfego é mais confiável quando um ou ambos firewalls podem
registrar atividade para o outro parceiro ou para um servidor separado.
•Possibilidade de compartilhamento de estado
Dependendo do produto, os firewalls nesse conjunto conseguem compartilhar o
estado de sessões.
Desvantagens
As desvantagens de um conjunto de firewalls tolerantes a falhas são:
•Maior complexidade
A instalação e o suporte deste tipo de solução são mais complexos devido à
natureza de vários caminhos do tráfego de rede.
•Configuração complexa
Os conjuntos separados de regras de firewall podem levar a falhas de
segurança e problemas de suporte se não forem configurados corretamente.
•Maior custo
Como há a necessidade de pelo menos dois firewalls, o custo aumenta no
conjunto de um único firewall.
Configurações do firewall tolerante a falhas
Ao implementar um conjunto de firewalls tolerantes a falhas (geralmente
conhecido como cluster), existem duas abordagens principais, conforme descrito
nas seções a seguir.
Conjunto ativo/passivo de firewall tolerante a falhas
Em um conjunto ativo/passivo de firewall tolerante a falhas, um dispositivo
(também conhecido como nó ativo) manipula todo o tráfego, enquanto o outro
dispositivo (o nó passivo) não encaminha o tráfego nem executa a filtragem, mas
permanece ativo, monitorando o estado do nó ativo. Normalmente, cada nó
comunica a sua disponibilidade e/ou o estado da sua conexão ao nó parceiro.
Geralmente, essa comunicação recebe o nome de pulsação, pois cada sistema
avisa o outro, várias vezes por segundo, para garantir que as conexões estejam

sendo manipuladas pelo nó parceiro. Se o nó passivo não receber uma pulsação
do nó ativo em um intervalo específico superior ao definido pelo usuário,
indicando que o nó ativo falhou, então, o nó passivo assumirá a função de ativo.
A figura a seguir apresenta a descrição de um conjunto ativo/passivo de firewall
tolerante a falhas.
Figura 5
Conjunto ativo/passivo de firewall tolerante a falhas
Vantagens
As vantagens de um conjunto ativo/passivo de firewall tolerante a falhas são:
•Configuração simples
Esta configuração é mais simples de se fazer e solucionar do que a opção a
seguir, ativo/ativo, porque apenas um único caminho de rede está ativo a todo o
momento.
•Carga de failover previsível
Como toda a carga de tráfego alterna para o nó passivo em failover, o tráfego
que o nó passivo deve gerenciar poderá ser facilmente planejado.

Desvantagens
As desvantagens de um conjunto ativo/passivo de firewall tolerante a falhas são:
•Utilização ineficiente
O conjunto ativo/passivo de firewall tolerante a falhas é ineficiente porque o nó
passivo não fornece uma função útil à rede durante a operação normal e não
aumenta a taxa de transferência.
Conjunto ativo/ativo de firewall tolerante a falhas
Em um conjunto ativo/ativo de firewall tolerante a falhas, dois ou mais nós
ouvem ativamente todas as solicitações enviadas para um endereço IP virtual
que cada nó compartilha. A carga é distribuída entre os nós por meio de
algoritmos exclusivos para o mecanismo de tolerância a falhas em uso ou por
meio de uma configuração estática baseada no usuário. Qualquer que seja o
método, o resultado é que cada nó filtra ativamente um tráfego diferente. No
caso de um nó falhar, os nós sobreviventes distribuem o processamento da carga
que tinha sido assumida anteriormente pelo nó que falhou. A figura a seguir
apresenta a descrição de um conjunto ativo/ativo de firewall tolerante a falhas:

Figura 6
Conjunto ativo/ativo de firewall tolerante a falhas
Vantagens
As vantagens de um conjunto ativo/ativo de firewall tolerante a falhas incluem:
•Maior eficiência
Como todos os firewalls estão fornecendo um serviço à rede, o uso deles é mais
eficiente.
•Taxa de transferência maior
Durante a operação normal, esta configuração pode manipular níveis superiores
de tráfego se comparada à configuração ativo/passivo, já que todos os firewalls
podem fornecer o serviço à rede simultaneamente.
Desvantagens
As desvantagens de um conjunto ativo/ativo de firewall tolerante a falhas são:
•Sujeito a possíveis sobrecargas
Se um nó falhar, os recursos de hardware no(s) nó(s) restante(s) poderão ser
insuficientes para atender ao requisito de taxa de transferência total. É
importante planejar-se adequadamente para isso, entendendo que a degradação
do desempenho provavelmente irá ocorrer, já que os nós sobreviventes
assumem a carga de trabalho adicional, quando um nó falha.
•Maior complexidade
Como o tráfego de rede pode passar por várias rotas, a solução de problemas
torna–se mais complexa.
Início da página
Segurança
A segurança de produtos de firewall é de suma importância. Embora não existam
padrões para a segurança de firewall, o fornecedor independente ICSA
(International Computer Security Association) executa um programa de
certificação para testar a segurança de produtos de firewall disponíveis
comercialmente. A ICSA testa um número significativo de firewalls disponíveis
no mercado atual. Para obter mais informações, consulte a seguinte URL:
www.icsalabs.com (em inglês)
É preciso ter cuidado para garantir que um firewall alcance os padrões de
segurança necessários e uma maneira para fazer isso é escolher um firewall que
conquiste a certificação ICSA. Além disso, deve existir um histórico para o
firewall escolhido. Há vários bancos de dados de vulnerabilidade de segurança

disponíveis na Internet. Você deve verificá–los para obter informações sobre as
vulnerabilidades do produto que pretende comprar. Infelizmente, todos os
produtos (baseados em hardware e software) têm bugs. Além de determinar a
quantidade e a gravidade dos bugs do produto que pretende comprar, também é
importante avaliar a capacidade de resposta do fornecedor para as
vulnerabilidades expostas.
Início da página
Escalabilidade
Essa seção trata sobre o requisito de escalabilidade de uma solução de firewall.
A escalabilidade de firewalls é determinada basicamente pelas características de
desempenho dos dispositivos usados. É prudente selecionar um tipo de firewall
que será escalado para atender às situações que enfrentará na prática. Há duas
maneiras básicas para se alcançar a escalabilidade:
•Escala vertical (ascendente)
Se o firewall for um dispositivo de hardware ou uma solução de software
executada em um servidor, a variação de graus de escalabilidade poderá ser
atingida com o aumento da quantidade de memória, da capacidade de
processamento da CPU e da taxa de transferência de interfaces de rede. No
entanto, há um limite para cada dispositivo ou servidor no que se refere à
distância em que pode ser escalada verticalmente. Por exemplo, se você
comprar um servidor com suporte para quatro processadores e começar com
dois, será possível adicionar apenas mais dois processadores.
•Escala horizontal (lateral)
Uma vez que um servidor tenha sido escalado verticalmente até o seu limite, a
escala horizontal passará a ser importante. A maioria dos firewalls (baseados
em hardware e software) pode ser escalada lateralmente usando alguma forma
de balanceamento de carga. Em uma situação como essa, vários servidores são
organizados em um cluster e vistos como um pelos clientes na rede. Esse caso é
essencialmente o mesmo do cluster ativo/ativo descrito na seção
"Disponibilidade", neste módulo. A tecnologia usada para oferecer essa
funcionalidade pode ou não ser a mesma que a descrita anteriormente, e
dependerá do fornecedor.
A escala vertical de firewalls pode ser difícil. No entanto, alguns fabricantes de
firewall de hardware oferecem soluções de escala lateral por meio das quais os
seus dispositivos podem ser empilhados para operar como uma única unidade de
carga equilibrada.
Alguns softwares baseados em firewalls foram criados para fornecer uma escala
ascendente, usando vários processadores. O multiprocessamento é controlado
pelo sistema operacional subjacente, e o software de firewall não precisa
conhecer os demais processadores. No entanto, é possível que nem todos os
benefícios dos vários processadores sejam alcançados a menos que o software de
firewall possa operar em um modo de multitarefas. Esta abordagem permite uma

escala em dispositivos simples ou redundantes em oposição aos firewalls
baseados em hardware ou do tipo dispositivo, que normalmente devem seguir as
limitações de hardware neles embutidas no momento da fabricação. A maioria
dos firewalls do tipo dispositivo é classificada pelo número de conexões
simultâneas que os dispositivos podem manipular. É freqüente a necessidade de
substituição dos dispositivos de hardware se os requisitos de conexão excederem
o que está disponível para o modelo de escala fixa do dispositivo.
Como já foi abordado, a tolerância a falhas pode estar embutida em um sistema
operacional de servidor de firewall. Para um firewall de hardware, a tolerância a
falhas representará, provavelmente, um custo extra.
Início da página
Consolidação
Consolidação significa incorporar o serviço de firewall em outro dispositivo ou
incorporar outros serviços no firewall. Os benefícios da consolidação são:
•Preço de compra menor
Ao incorporar o serviço de firewall em outro serviço, por exemplo, em um
roteador, o custo de um dispositivo de hardware será evitado, embora ainda
seja necessário comprar o software de firewall. Da mesma forma, se for possível
incorporar outros serviços no firewall, o custo de hardware adicional será
evitado.
•Custos reduzidos de inventário e gerenciamento
A redução no número de dispositivos de hardware faz com que os custos
operacionais sejam reduzidos. Uma vez que a necessidade de atualizações de
hardware é menor, o cabeamento fica simplificado e o gerenciamento torna–se
mais simples.
•Melhor desempenho
Dependendo da consolidação alcançada, o desempenho pode ser melhor. Por
exemplo, a incorporação de cache de servidor Web no firewall pode afastar a
necessidade de dispositivos adicionais e os serviços se comunicam em alta
velocidade, e não por um cabo Ethernet.
Entre os exemplos de consolidação, estão:
•Adição de serviços de firewall a um roteador
A maioria dos roteadores pode ter um serviço de firewall incorporado. Os
recursos desse serviço de firewall podem ser muito simples em roteadores de
baixo custo, mas os roteadores high–end geralmente terão um serviço de
firewall muito eficiente. É provável que você tenha pelo menos um roteador
conectando os segmentos da Ethernet na sua rede interna. Você economizará
com a incorporação do firewall nele. Mesmo que você implemente dispositivos
de firewall específicos, a implantação de alguns recursos de firewall nos

oteadores poderá ajudar a limitar as invasões internas.
•Adição de serviços de firewall ao switch interno
Dependendo do switch interno selecionado, é possível adicionar o firewall
interno como "blade", reduzindo custos e melhorando o desempenho.
Ao considerar a consolidação de outros serviços no mesmo servidor ou
dispositivo que ofereça o serviço de firewall, você deverá ter cuidado para
garantir que o uso de um determinado serviço não comprometa a
disponibilidade, a segurança ou a facilidade de gerenciamento do firewall.
Também é importante considerar o desempenho, já que a carga gerada por
serviços adicionais irá degradar o desempenho do serviço de firewall.
Uma abordagem alternativa para consolidar serviços no mesmo dispositivo ou
servidor que hospeda o serviço de firewall é consolidar um dispositivo de
hardware de firewall como uma "blade" em um switch. Essa abordagem
normalmente custa menos do que um firewall autônomo de qualquer tipo e pode
aproveitar os recursos de disponibilidade do switch, como as fontes de
alimentação duplas. Uma configuração como essa também é mais fácil de ser
gerenciada por não envolver um dispositivo separado. Além disso, esta solução
normalmente é executada com mais rapidez porque usa o barramento no switch,
que é mais veloz que um cabeamento externo.
Início da página
Padrões e diretrizes
A maioria dos protocolos de Internet que usa a versão 4 do protocolo IP (IPv4)
pode ser protegida por um firewall. Isso inclui os protocolos de nível inferior,
como o TCP e o UDP, e os protocolos de nível superior, como o HTTP, o SMTP e
o FTP. Ao analisar o produto de firewall que pretende adquirir, verifique se ele
realmente oferece suporte ao tipo necessário de tráfego. Alguns firewalls
também podem interpretar o GRE, que é o protocolo de encapsulamento para o
protocolo PPTP (Point–to–point Tunneling Protocol), usado em algumas
implementações de VPN.
Alguns firewalls têm filtros da camada de aplicativo embutidos para protocolos,
como HTTP, SSL, DNS, FTP, SOCKS v4, RPC, SMTP, H. 323 e POP (Post Office
Protocol).
Deve–se considerar também o futuro do protocolo TCP/IP e IPv6, bem como se
esse será um requisito obrigatório para qualquer firewall, mesmo se o IPv4
estiver sendo usado no momento.
Início da página
Resumo
Este módulo apresentou um método prático para a seleção bem–sucedida de

produtos de firewall. Esse método abrange todos os aspectos do design de
firewall, inclusive os diversos métodos de avaliação e classificação necessários
para escolher uma solução.
Nenhum firewall é 100% seguro. A única maneira de se garantir que a rede não
será atacada eletronicamente pelo lado de fora é implementar uma barreira
entre ele e todos os outros sistemas e as outras redes. O resultado seria uma
rede segura quase inutilizável. Os firewalls permitem implementar um nível
adequado de segurança, quando sua rede é conectada a uma rede externa ou são
unidas duas redes internas.
As estratégias do firewall e os processos de design apresentados neste módulo
devem ser considerados apenas como parte de uma estratégia geral de
segurança. Um firewall sólido possui valor limitado se existirem pontos fracos
em outras partes da rede. A segurança deve ser aplicada em todo componente da
rede e a política de segurança que encaminha os riscos inerentes ao ambiente
deve ser definida para cada componente.

VPN
1. Histórico
O termo VPN esteve associado no passado a serviços remotos de
conectividade, como o a rede de telefonia pública comutada (RTPC) ou os PVCs
(Permanent Virtual Circuits/Channel) do Frame Relay, mas hoje já está associado
ao uso de infra-estruturas públicas de comunicação para simular redes privadas
IP. Antes da utilização deste novo conceito de VPN, as corporações gastavam
grandes quantias de recursos para montar complexas redes privadas, chamadas
Intranets, entre suas diversas unidades. Essas redes utilizavam serviços caros,
como linhas privadas, Frame Relay e ATM para incorporar filiais à rede interna
da companhia. Para escritórios ou usuários móveis, eram utilizados servidores de
acesso remoto (com modens e linhas de discagem gratuita como o 0800) ou
conexões RDSI (Rede Digital de Serviços Integrados). Ao mesmo tempo,
empresas pequenas ou médias, que não tem recursos para manter conexões
dedicadas tão caras, utilizavam serviços de comutação de circuito de baixa
velocidade.
A medida em que a Internet tornou-se mais e mais acessível, e a capacidade de
transmissão disponível aumentou, as companhias passaram a migrar suas
Intranet para a web, criando as chamadas Extranets, ligando usuários internos e
externos. Apesar do baixo custo e a grande disponibilidade da Internet, há um
problema fundamental: a segurança das informações que trafegam na rede.
As VPN aparecem para superar o problema de segurança. Usando protocolos
de tunelamento e procedimentos de encriptação, a integridade e autenticidade
dos dados é garantida. Como as operações ocorrem sobre uma rede pública, a
implementação e manutenção de uma VPN custa significativamente menos do
que os serviços dedicados descritos no primeiro parágrafo.
Apesar de as primeiras VPNs que surgiram necessitarem de especialistas para
serem colocadas em funcionamento, a tecnologia desenvolveu-se a um nível em
que sua implantação é simples e adequada a negócios de quaisquer tamanhos,
incluindo pequenas empresas antes afastadas deste tipo de solução.
Utilizando a Internet, as companhias podem conectar suas filiais, parceiros de
negócio e clientes à rede corporativa. Usuários móveis dispõem de comunicações
seguras, bastando para isso fazer uma ligação para um provedor de serviço de
Internet (ISP, Internet Service Provider). Com VPNs, as empresas reduzem de
forma imediata o custo com as ligações de longa distância (principalmente as
companhias com atuação internacional), aluguel de linhas privadas e
equipamentos de conexão, como banco de modens e servidores de autenticação.

2. Tecnologias
A Internet é uma rede pública compartilhada, com protocolos abertos de
transmissão. Assim, VPNs devem possuir meios de encapsular pacotes
(tunelamento), encriptação e autenticação, de forma a permitir que dados
importantes cheguem aos seus destinos sem que sejam vistos ou modificados por
terceiros.
2.1 Firewall
O firewall é um importante mecanismo de segurança para qualquer usuário da
Internet. Disponível em software ou hardware especializado, previne que
usuários e dados não autorizados entrem ou saiam da rede da empresa, através
de regras que especificam quais protocolos, locais ou destinos são permitidos ou
proibidos. No entanto, eles não oferecem proteção aos dados após estes saírem
da rede interna da empresa para a Internet; assim que os dados passam pelo
firewall, nomes de usuário, senhas, números de contas, endereços de servidores
e outras informações particulares estão visíveis aos hackers. Túneis VPN, feitos
pelo uso de algoritmos de encriptação, fornecem a capacidade de se utilizar uma
rede pública e compartilhada como a Internet para a transmissão segura de
informações após elas deixarem a área protegida pelo firewall.
2.2 Túneis
É o que faz com que as Redes Privadas Virtuais sejam realmente privadas.
Mesmo utilizando a Internet, uma rede pública, podemos dizer que estamos na
verdade na rede privada da empresa, devido à privacidade fornecida pelos
túneis. Apesar do termo túnel parecer se referir a um caminho fixo entre a
origem e o destino, ele se comporta como qualquer outro tráfego na Internet,
que pode passar por diferentes caminhos para chegar a um destino. O que faz da

transmissão VPN um túnel é o fato de apenas o destino, no final do túnel, poder
ver a informação original.
As tecnologias de tunelamento encriptam e encapsulam um determinado
protocolo de rede dentro de um pacote IP. Desta forma, ele pode ser roteado,
filtrado e serem aplicados dispositivos para controle de custo da mesma forma
que é feitos com WAN tradicionais.
2.3 Encriptação
Encritação é a técnica de desordenar e colocar novamente em ordem a
informação. A informação original é chamada de texto claro (clear-text) enquanto
que a desordenada é chamada de texto codificado (cipher-text). Em cada lado de
um túnel VPN está um dispositivo VPN, em hardware ou software; o dispositivo
do emissor encripta a informação para texto codificado antes de enviá-la através
do túnel, e o dispositivo no receptor decripa a informação de volta para texto
claro.
Os algoritmos de encriptação são funções matemáticas que estabelecem a
relação entre a mensagem encriptada e a mensagem original, com a
possibilidade de utilização de outros parâmetros. Os primeiros algoritmos de
encriptação que surgiram garantiam a segurança mantendo em segredo a forma
como a informação era desordenada; este método foi muito utilizado nas
primeira e segunda guerra mundial. No entanto, a partir do momento em que o
método era descoberto, toda a informação que tivesse sido enviada por ele
tornava-se vulnerável. Assim, passou-se a pesquisar algoritmos em que a
segurança seria garantida de outra forma que não o segredo sobre o algoritmo; a
resposta foi a utilização de chaves para segurança de algoritmos públicos e
testados, como o DES (Data Encryption Standard).
DES e 3DES
O DES utiliza chaves simétricas de 56 bits para encriptar blocos de 64 bits de

dados. Apesar deste método fornecer mais de 72.000 trilhões de possíveis
combinações de chaves, que levariam pelo menos 10 anos para que um
computador comum rodasse todas estas combinações, utilizando-se um conjunto
de máquinas podemos quebrá-lo em menos de um minuto. Desenvolveu-se então
o 3DES, que encripta a informação mais de uma vez; no 3DES, a mensagem é
encriptada com uma chave, seus resultado decriptado com outra, então
encriptado novamente com a chave original, para ser enviada ao destinatário,
que realiza as mesmas operações de forma inversa; apenas ao fim das três
operações é que teremos a mensagem original. Essa técnica faz com que o
tamanho efetivo da chave aumento de 56 para 168 bits.
Figura 1: Encriptação utilizando 3DES
2.4 Chaves
A chave é um código secreto utilizado por algoritmos de encriptação para criar
versões únicas do texto codificado; isto faz com que uma mensagem, ao ser
encriptada com chaves diferentes, apresente textos codificados diferentes.
De forma intuitiva, podemos dizer que a segurança da transmissão será
diretamente proporcional ao tamanho de chave utilizado. Utilizando uma chave
de 16 bits, um atacante terá que fazer no máximo 65536 tentativas antes de
revelar a combinação; para computadores, esta seria uma tarefa praticamente
imediata. É por este motivo que os produtos VPN hoje utilizam chaves de 168
bits, criando um número de combinações que necessitariam de alguns séculos
para serem descobertas por computadores.
Apesar da tentação para utilizar a chave com o maior número de bits possível,
devemos levar em consideração que quanto maior a chave, maior será o tempo
levado pelo dispositivos VPN para encriptar e decriptar as mensagens. Deve-se
utilizar um tamanho de chave adequado para a importância da informação que se
quer transmitir.
Uma política mais eficiente é de utilizar chaves não muito grandes, mas

trocadas periodicamente. O período de tempo em que uma determinada chave é
utilizada é chamado de crypto-period. As chaves podem ser trocadas de acordo
com um determinado nível de transmissão de dados, no início de cada nova
sessão ou quando o tráfego for baixo.
Chaves simétricas
Significa que a mesma chave é utilizada em cada terminação de um túnel para
encriptar e decriptar as informações. Como a chave simétrica é compartilhada
pelas duas partes, devem ser tomadas as medidas adequadas de forma a manter
a chave secreta; por este motivo são também chamadas de “chaves secretas”.
Estas chaves são mais difíceis de serem distribuídas, já que elas devem
permanecer secretas. Uma técnica denominada “divisão de chave” pode ser
empregada para reduzir o potencial de revelação da chave durante a troca, o que
permite a utilização de canais públicos, como a Internet. A distribuição da chave
também pode ser feita manualmente, utilizando papéis ou mídias removíveis
(como disquetes e CDs).
Chaves assimétricas
Chaves assimétricas são um pouco mais complicadas, mas muito mais fáceis
de gerenciar. Elas permitem que a informação seja encriptada por uma chave e
decriptada por outra. As duas chaves utilizadas nesse cenário são chamadas de
chave pública, que é distribuída, e chave privada, que deve ser mantida em
segredo. Com chaves assimétricas, os parceiros no negócio trocam suas chaves
públicas para se comunicar, mas mantém suas chaves privadas em segredo.
Criptografia assimétrica

Gerenciamento de chaves
Configurar previamente chaves secretas em pequenas VPNs não necessita de
automação por software ou grandes investimentos em infra-estrutura.
Entretanto, redes grandes beneficiam-se da implementação de uma infraestrutura
de chaves públicas (Public Key Infrastructure, PKI) para criar,
distribuir e emitir certificados digitais para cada usuário. Certificados digitais
são procedimentos que verificam a associação entre uma chave pública e a
identidade de um usuário, impedindo a falsificação de identidade. Pode-se
utilizar os serviços de Autoridades Certificadoras fornecidos por terceiros, ou
usar uma própria; estes serviços são especialmente importantes para grandes
companhias que precisam gerenciar uma grande quantidade de chaves, tanto de
seus usuários quanto de seus parceiros e clientes.
2.5 Autenticação
Por meio da autenticação, o destinatário de um dado pode determinar se o
emissor é realmente quem ele diz ser (autenticação de usuário ou dispositivo) ou
se o dado foi redirecionado ou corrompido no caminho entre a origem e o destino
(autenticação de dados).
Autenticação usuários ou dispositivos
Numa comunicação entre A e B, A recebe uma mensagem assinada por B; A
então escolhe um número aleatório e ecripta utilizando uma chave que somente
B será capaz de decodificar. B então decripta o número aleatório e re-encripta
utilizando uma chave que somente A será capaz de decodificar. Quando A recebe
o número aleatório de volta, ele pode garantir que é realmente B que está na
outra ponta da comunicação.
Autenticação de dados
Para verificar que pacotes de dados chegaram inalterados, os sistemas VPN
geralmente utilizam uma técnica que envolve funções de hash. Esta função cria
uma espécie de impressão digital do dado original. Ela calcula um número único
para a mensagem em questão, chamado de hash, formado por uma cadeia fixa ou
variável de bits. O emissor então anexa este número ao pacote de dados antes da
etapa de encriptação. Quando o destinatário recebe e decripta este dado, ele
pode calcular o hash da mensagem recebida de forma independente. O resultado
é então comparado com o valor anexado pelo emissor; se os dois não

coincidirem, então é assumido que os dados foram alterados no caminho.
Assinatura Digital
Conferindo a Assinatura Digital de uma pessoa
3. Protocolos de tunelamento e encriptação
IPSec é o protocolo padrão da Internet para tunelamento, encriptação e
autenticação. Ele foi projetado para proteger o tráfego da rede levando em
consideração os seguintes aspectos: controle de acesso, integridade da conexão,
autenticação da origem dos dados, proteção contra reenvio de pacotes e
privacidade no tráfego de dados.
O protocolo permite dois modos de operação. No modo túnel, tudo que estiver
após o cabeçalho IP é protegido. No modo túnel, todo o pacote é protegido e um
novo cabeçalho é gerado. Uma abordagem mais detalhado do IPSec pode ser
encontrada na página seguinte.
Além do IPSec, o Layer 2 Tunneling Protocol (L2TP) é utilizado para
tunelamento. Neste caso, os pacotes de qualquer protocolo que não possa ser
encaminhado na Internet (como IPX, SNa ou AppleTalk) são encapsulados num
quadro L2TP, que por sua vez é colocado em uma pacote IP para roteamento até
o final do túnel L2TP. Porém, devemos utilizar outros protocolos sobre o L2TP

para garantir a segurança dos dados. Uma análise mais profunda sobre o L2TP é
feita mais adiante.
4. Políticas de segurança
As políticas de segurança definem privilégios de acesso aceitáveis, que podem
depender de diversos fatores, como: cargo na empresa, projetos em que o
funcionário trabalha, necessidades de informação e nível de confiança. Além
disso, as políticas devem ser suficientemente granulares para permitir a
diferenciação dependendo da organização, servidores, grupos e até mesmo níveis
de usuários. Devemos levar em conta que estamos traçando uma linha de divisão
entre o acesso limitado e a computação colaborativa; as políticas devem proteger
os recursos no maior nível possível, ou seja, aquele que não prejudique a
produtividade dos empregados.
5. Aplicações VPN
5.1 Acesso remoto
Profissionais de negócios que viajam freqüentemente ou que trabalham em
casa utilizam VPN para acessar a rede interna da empresa e realizar suas
tarefas. Não importa onde eles estão, o acesso seguro à empresa está a apenas
uma ligação telefônica para um ISP. Esta solução também é útil para os casos em
que importantes funcionários da empresa precisam estar longe por um bom
período de tempo.
Acesso remoto antes das VPNs
A conexão de usuários móveis ou remotos era tradicionalmente conseguida
utilizando serviços comutados. Pequenos escritórios que não pudessem arcar
com os custos de uma conexão permanente à Intranet corporativa utilizariam
linhas discadas.
As tarifas de longa distância são os maiores custos deste tipo de
conectividade. Outros custos incluem investimentos em Servidores de Acesso
Remoto na matriz e pessoal especializado para configurar e manter os
servidores.

Acesso remoto após as VPNs
Usuários remotos podem estabelecer conexões discadas para ISP locais, e
conectar, via Internet, a um servidor VPN na sede da empresa. Utilizando as
conexões rápidas existentes atualmente (DSL ou a cabo), empregados podem
acessar os recursos corporativos em velocidades maiores do que 500 kbps. Na
maior parte das vezes, isto é como se o funcionário estivesse dentro da sede da
empresa, permitindo um trabalho rápido e eficiente.
Neste tipo de aplicação, os benefícios proporcionados pela VPN incluem a
substituição das ligações de longa distância ou serviços 0800, a eliminação da
necessidade de Servidores de Acesso Remoto modens, e o acesso a todos os
dados e aplicativos da empresa (não somente email e servidores de transferência
de arquivos). Estudos mostram que a economia gerada nas ligações de longa
distância pagam os custos de instalação da VPN em alguns meses, o que é
seguido pela diminuição recorrente das despesas.
5.2 Intranet
O mercado hoje muitas vezes exige que empresas estabeleçam escritórios
regionais ou internacionais. A opção sempre foi usar linhas privadas ou o mesmo
tipo de acesso discado de usuários móveis. Além das perdas com infra-estrutura,
as empresas ainda devem levar em consideração as perdas de oportunidade
associadas à ineficiência no acesso às informações ou aplicações centralizadas.
Intranet antes das VPNs
Para conectar escritórios às sedes, o primeiro passo era equipar cada
escritório com um roteador que o conectasse a um roteador de backbone de uma
LAN ou WAN. Os roteadores remotos também conectavam os escritórios com
outras localidades remotas. Todos estes roteadores eram freqüentemente
conectados por uma rede de linhas privadas ou serviço de Frame Relay.
O custo dessa configuração inclui os roteadores de backbone e de cada
escritório e tarifas dos serviços de telecomunicações, mais significativamente as
de longa distância.

Intranet após as VPNs
Usando uma solução VPN para esta aplicação, o backbone WAN e o hardware
associado são substituídos pela Internet. Cada escritório adicional acarretará o
custo de uma conexão à Internet, do tipo DSL, RDSI ou a cabo. Também
eliminamos a necessidade dos roteadores de backbone e sua administração,
configuração e suporte. O Retorno de Investimento (ROI) nesta aplicação
também é rápido e provê economias recorrentes.
6. Produtos VPN
6.1 Repassando as responsabilidades a um ISP
Uma das opções para implementação de VPN é repassar as responsabilidades
sobre gerenciamento para um ISP. É adequado para empresas que não possuam
trabalhadores qualificados para esta área ou que não queiram perder o foco de
seu negócio.
É preciso levar em consideração os locais em que o ISP está presente, a
existência de equipamentos redundantes, funcionários qualificados e um suporte
adequado.
6.2 Assumindo a responsabilidade na própria companhia
Ao implementar VPNs, há quatro áreas principais que devem ser levadas em
consideração: o serviço de Internet, o servidor com as políticas de segurança, o
sistema de PKI e o dispositivo VPN que será utilizado.
Os dispositivos se dividem em duas categorias, os independentes e os
integrados a outros produtos. Estes dispositivos são:
Roteador: adicionando suporte a VPN no roteador pode manter os custos de
atualização baixos. As funcionalidades podem ser adicionadas tanto por software
ou por placas de expansão.
Firewall: a utilização de firewall para a criação de VPNs é uma solução prática

para redes pequenas e com baixo volume de tráfego. No entanto, devido ao
processamento realizado pelos firewall, eles não são adequados para
tunelamento em empresas com alto volume de tráfego.
Independentes: são projetados especificamente para tunelamento, encriptação
e autenticação de usuários, e geralmente são mais fáceis de instalar do que a
implementação em roteadores e firewalls. Há uma grande variedade de
dispositivos com diferentes taxas de dados e capacidade de gerenciar conexões
simultâneas.
Software: softwares para criação e gerenciamento de túneis VPN estão
disponíveis para serem usados entre pares de dispositivos ou entre um usuário
remoto e um dispositivo VPN. Estes softwares são boas opções de baixo custo
para poucos túneis que não precisem processam muito tráfego; o software pode
rodar em servidores já existentes.
7. Qualidade de Serviço (QoS)
A Internet é um ambiente complexo com uma enorme mistura de dados e
aplicações em tempo real, que se movem em diferentes direções através de infraestruturas
desconhecidas. Deve-se esperar encontrar gargalos e
congestionamento. QoS geralmente trata de alocação de banda, prioridade e
controle sobre a latência da rede. Mas a Internet é uma rede “sem conexão” que
não provê garantias, apenas o melhor esforço. Quando transmitimos informações
de missão críticas, que devem chegar ao destinatário com o menor atraso
possível, QoS torna-se uma parte importante das implementações VPN. IPv6, a
próxima versão do protocolo IP, deve mudar muitos destes fatores ao incluir
provisões para QoS diretamente ao protocolo, mas ele ainda não é plenamente
utilizado. É este o motivo para separar os requisitos de QoS dos requisitos de
VPN, se é que a qualidade de serviço é importante para a empresa. Em outras
palavras, deve-se escolher um ISP com um nível de qualidade de serviço
adequado e então escolher a solução VPN mais adequada.

L2TP - Layer 2 Tunneling Protocol
Protocolo para Tunelamento na
Camada de Enlace
1. Introdução
L2TP é uma extensão do PPP (Point-to-Point Protocol), unindo características de
outros dois protocolos proprietários: o L2F (Layer 2 Forwarding) da Cisco e o
PPTP (Point-to-Point Tunneling Protocol) da Microsoft. É um padrão da IETF
(Internet Engineering Task Force), que conta com a participação da Cisco e do
PPTP fórum, entre outros líderes de mercado.
O L2TPv3, analisado neste trabalho é uma atualização da RFC2661 (L2TPv2), e
foi originalmente definido como um método para tunelamento para quadros PPP
através de uma rede de comutação de pacotes. Surgiu então a necessidade de
atualizar o método, para que ele incluísse todos os encapsulamentos da camada
2 que necessitassem de tunelamento através de redes de comutação de pacotes.
Entre as mudanças para a versão 3, temos: retirada de todas as partes
específicas ao PPP do cabeçalho L2TP, garantindo assim a generalização para
outras aplicações, e a mudança para um formato que possibilitasse o
desencapsulamento de forma mais rápida.
O L2TP fornece a flexibilidade e escalabilidade do IP com a privacidade do
Frame Relay ou ATM (Asynchronous Transfer Mode), permitindo que serviços de
rede sejam enviados em redes roteadas IP. As decisões são tomadas nas
terminações dos túneis ou VPNs, e comutadas sem a necessidade de
processamento nos nós intermediários.
As seguintes vantagens são oferecidas pelo L2TP:
o
o
o
o
permite o transporte de protocolos que não o IP, como o IPX (Internetwork
Packet Exchange, da Novell/Xerox) e o SNA, assim como outros protocolos
dos terminais;
mecanismo simples de tunelamento para implementar funcionalidades de
LAN e IP de forma transparente, possibilitando serviços de VPN IP de
forma bastante simples;
simplifica a interação entre as redes do cliente e do provedor;
fácil configuração para o cliente.

2. Funcionamento
Nesta seção, analisaremos um tunelamento baseado em interfaces, onde todo o
tráfego entre duas redes de um cliente é encapsulado em pacotes IP e enviado
por uma rede IP. Os roteadores internos da rede IP tratam o tráfego como
qualquer outro, e não precisam de informações sobre as redes do cliente. Este
processo é chamado de tunelamento da camada 2.
Como mostrado na figura 1, os roteadores R1 e R2 fornecem o serviço L2TP.
Estes roteadores comunicam-se por protocolo IP, através do caminho composto
pela interface Int2, a rede IP e a interface Int3. Neste exemplo, os roteadores R3
e R4 comunicam-se por interfaces POS (Packet-over-SONET) utilizando um túnel
L2TP. O túnel Tu1 é estabelecido entre as interfaces Int1 de R1 e Int4 de R2.
Qualquer pacote que chegue na interface Int1 de R1 é encapsulado pelo L2TP e
enviado pelo túnel Tu1 para R2. R2 então desencapsula o pacote e o transmite na
interface Int4 para R4. Quando R4 precisa enviar um pacote para R3, o mesmo
caminho, de forma inversa, é seguido.
Podemos fazer algumas observações a respeito da operação do L2TP:
o todos os pacotes recebidos na interface Int1 serão redirecionados para R4.
R3 e R4 não vêem a rede que está entre eles;
o o mesmo método é utilizado para interfaces Ethernet: qualquer pacote
recebido da LAN1 por R1 na interface E1 será encapsulado pelo L2TP e
enviado pelo túnel Tu2 até a interface E2 de R2, ao que será transmitido
para a LAN2.
o o mesmo vale para Frame-Relay: qualquer pacote recebido pela LAN1 por
R1 em uma sub-interface será encapsulado pelo L2TP e enviado por um
túnel até a sub-interface de R2, onde será transmitido na LAN2.

Funcionamento do L2TP
3. Cabeçalhos L2TP
Quando dados entram por uma interface de entrada de um túnel L2TP, eles são
encapsulados por um cabeçalho adicional L2TP, como mostrado na figura 2. O
cabeçalho L2TP é composto pelos seguintes parâmetros:
• Cabeçalho para entrega (Delivery header): o cabeçalho necessário para
transmitir os pacotes L2TP através da rede. Este é um cabeçalho IPv4, com
20 octetos;
• Cabeçalho L2TP: contém as informações necessárias para identificar de
maneira única um túnel no local em que ele será desencapsulado, e contém
12 octetos;
• Informações (payload): o que será transportado pelo L2TP, podendo ser
tanto um quadro da camada de enlace quanto um pacote da camada de
rede.
A parte do L2TP pode ser decomposta nos seguintes campos:
• Identificador do túnel: identifica o túnel no sistema que desencapsula o
pacote. O valor da identificação do túnel é escolhido de forma a otimizar a
otimizar a identificação sistema que o desencapsulará. Este sistema pode
então escolher trabalhar com um número menor de bits neste campo;
trabalhando com 10 bits, por exemplo, serão possíveis 1023 túneis, já que
o identificador zero é reservado para uso pelo protocolo.
• Cookie: uma assinatura contendo 8 octetos, que é compartilhada entre as
duas extremidades do túnel L2TP. Este cookie reduz as chances de que
dois tráfegos sejam misturados após o desencapsulamento devido a erros
de configuração; as assinaturas nos roteadores de origem em destino
devem coincidir, ou os dados serão descartados.

Encapsulamento L2TP
O L2TP comporta o tunelamento de dados dos seguintes quadros:
o
o
o
o
o
Frame Relay
Ethernet: todo o quadro é encapsulado no roteador de origem, para
posterior desencapsulamento no destino, e nenhum campo do quadro é
analisado
VLAN (802.1q): tanto as baseadas em portas quanto as baseadas na
marcação de quadros
HDLC (High-Level Data Link Control)
PPP: o L2TP não influencia na negociação ou manutenção da ligação
O protocolo L2TP pode ser dividido em duas partes: uma responsável por iniciar
a conexão e outra responsável pelo tunelamento dos quadros da camada 2.
A sinalização do L2TP é responsável por negociar os parâmetros da parte de
controle, identificadores de sessão, cookies, autenticação e a troca de
parâmetros de configuração.
3.1 Ordenação dos quadros
Apesar do ordenamento dos quadros da camada 2 ser garantido por alguma
tecnologia desta camada (pela natureza do enlace, com um linha serial), ou pelo
próprio protocolo, os quadros podem ser perdidos, duplicados ou reordenados
enquanto ele passam pela como pacotes da rede IP; se o protocolo da camada 2
não fornece um mecanismo de reordenamento de maneira explícita, o L2TP pode
ser configurado para ordenar seus pacotes de acordo com um mecanismo
descrito na RFC.
IPSec - Protoclo de Segurança IP
O Protocolo de Segurança IP (IP Security Protocol, mais conhecido pela sua
sigla, IPSec) visa a ser o método padrão para o fornecimento de privacidade,
integridade e autenticidade das informações transferidas através de redes IP.
A Internet tem mudado a maneira como negócios são feitos, mas até mesmo o
rápido crescimento da Internet tem sido atingido pela inerente falta de
segurança, por ser uma rede pública. Algumas das principais ameaças a que ela
está sujeita são:
o
perda de privacidade na troca de dados: os dados podem ser vistos por

o
o
o
terceiros;
perda da integridade dos dados: em algum local no caminho entre a origem
e o destino, os dados podem ser modificados por terceiros;
falsificação de identidade: a origem dos dados pode ser forjada, fazendo
com que pessoas assumam o papel de outras;
ataques de negação de serviço (Denial of Service, DoS): muitas vezes feitos
através da união de diversas máquinas, que fazem requisições excessivas
de um determinado serviço, tornando-o indisponível aos outros usuários.
O IPSec tem como objetivo tratar de todas estas ameaças na própria camada de
rede (camada Internet do modelo TCP/IP), para que não sejam necessárias
modificações nos terminais (host) ou aplicativos. Um dos meios para se
conseguir isto, por exemplo, é através da implementação de IPSec nos
roteadores de borda, por onde passa todo o tráfego externo de uma
empresa/instituição; desta forma, a segurança atuaria de forma transparente
para o usuário.
O IPSec é voltado para a encriptação de camada IP, e seu padrão define alguns
formatos de pacote novos: Autenticação de Cabeçalho (Authentication Header,
AH) para fornecer a integridade dos pacotes entre origem e destino, e o
Encapsulamento Seguro da Informação (Encapsulating Security Payload, ESP). O
gerenciamento de chaves, associações de segurança (Security Associations, SA)
e os parâmetros para a comunicação IPSec entre dois dispositivos são
negociados através do IKE (Inernet Key Exchange, anteriormente chamado de
Internet Security Association Key Management Protocol ou ISAKMP/Oakley). O
IKE utiliza Certificados Digitais (que garantem a identidade de uma pessoa,
evitando a falsificação de identidades) para autenticação de dispositivos,
permitindo a criação de grandes redes seguras. Sem o suporte dos Certificados
Digitais, as soluções IPSec não seriam escaláveis para a Internet. Todos estes
elementos serão explicados ao longo do texto. Atualmente, o protocolo já é
encontrado em roteadores, firewalls e em sistemas operacionais Windows e
UNIX.
Começaremos com a motivação para o desenvolvimento do IPSec, para depois
entrar em detalhes de seus mecanismos de segurança.
1. Fundamentos
Uma rede, para ser considerada segura, deve basear-se numa forte política de
segurança, que defina a liberdade de acesso à informação para cada usuário,
assim como a localização dos mecanismos de segurança na rede. Há várias
soluções para se construir uma infra-estrutura segura para a Internet, Extranets,
Intranets e redes para acesso remoto, que oferecem autenticação do usuário,
acompanhamento de suas ações e privacidade dos dados. Privacidade,
integridade e autenticidade são conseguidas através encriptação na camada de

ede, certificação digital e autenticação de dispositivos, palavras-chave quando
falamos de IPSec, ou mais genericamente, de mecanismos de segurança em
redes públicas.
2. Mudança na comunicação das empresas
A Internet está modificando rapidamente a forma como são feitos os negócios. Ao
mesmo tempo em que a velocidade de comunicação aumenta, seu custo diminui.
Há um grande espaço para o aumento de produtividade, aproveitando esta
situação, através das seguintes topologias, também mostradas na figura 1:
- Extranet: as companhias podem facilmente estabelecer enlaces com seus
fornecedores, clientes ou parceiros. Até pouco tempo atrás, isto era feito através
de linhas privadas (dedicadas) ou ligações telefônicas (de baixa velocidade). A
Internet permite uma comunicação instantânea, de alta velocidade e sempre
disponível.
- Intranet: a maior parte das empresas utiliza WANs (Wide-Area Networks) para
conectar as redes de sua sede e filiais. Esta solução é cara, e apesar de seu custo
ter caído nos últimos anos, ainda há uma grande margem de redução de custos
pelo uso da Internet.
- Usuários remotos: a Internet fornece uma alternativa de baixo custo para a
conexão destes usuários às redes corporativas. Em vez de a empresa ter que
manter bancos de modens e arcar com os custos das ligações telefônicas (muitas
vezes interurbanas ou até internacionais), elas podem permitir que seus usuários
acessem sua rede através da Internet. Com uma ligação local a um provedor de
acesso à Internet (Internet Service Provider, ISP), um usuário pode ter acesso à
rede corporativa.

Compartilhamento da rede interna de uma empresa
Estas e outras aplicações da Internet estão mudando a forma com as empresas
se comunicam. A Internet fornece uma infra-estrutura pública de comunicações
que faz com que tudo isso se torne possível. No entanto, há fraquezas geradas
por esta infra-estrutura compartilhada: segurança, qualidade de serviço e
confiabilidade. Neste momento aparece o IPSec como peça-chave no
fornecimento de segurança nas comunicações de rede.
3. Qual a função do IPSec?
Como visto nos itens anteriores, a Internet apresenta grandes vantagens, mas
também alguns riscos. Sem os mecanismos adequados de controle, os dados
estão sujeitos a diversos tipos de ataques. Estes ataques são:
3.1 Perda de privacidade
O atacante pode observar dados confidenciais enquanto eles atravessam a
Internet. Esta é uma das principais ameaças ao comércio pela Internet hoje. Sem
encriptação, todas as mensagens enviadas podem ser lidas por pessoas não
autorizadas, como mostrado na figura 2. Estas técnicas são chamadas de
“sniffing”, e os programas utilizados para isso de “sniffers”; até usuários com
pouco conhecimento já são capazes de bisbilhotar o conteúdo que trafega na
rede.

Pessoas não autorizadas podem bisbilhotar o conteúdo de mensagens
3.2 Perda de integridade dos dados
Mesmo que os dados não sejam confidenciais, também devemos nos preocupar
com a integridade deles. Por exemplo, uma pessoa pode não se importar que
alguém veja suas mensagens do dia a dia, mas certamente se preocupará se os
dados puderem ser alterados; uma ordem para a promoção de um funcionário
geralmente não precisa ser secreta, mas quem a enviou estará realmente
preocupado ser ela puder ser trocada por uma outra indicando uma demissão. O
mesmo vale para mensagens secretas, já que o emissor deseja que seus bits não
sejam alterados no caminho, o que poderia causar uma alteração no significado
da mesma. Mecanismos de integridade dos dados garantem que a mensagem
chega ao destino como saiu da origem.
3.3 Falsificação de identidade (Identity spoofing)
Além da proteção do dado, também devemos ter a garantia de que uma pessoa é
realmente quem ela diz ser. Como mostrado na figura 3, um atacante pode tentar
se passar por uma outra pessoa, para ter acesso a informações confidenciais.
Muitos sistemas ainda confiam no endereço IP para identificar um usuário de
forma única; no entanto, este sistema já é facilmente enganado.
Uma pessoa se passa por diretor da empresa, obtendo acesso à
informações confidenciais

3.4 Negação de serviço (DoS)
Ao migrar para a Internet, uma organização deve tomar as medidas necessárias
para garantir que seus sistemas estarão disponíveis aos usuários. Aproveitando
brechas de segurança, atacantes fazem com que computadores da empresa
sejam levados ao limite, até o ponto em que parem de oferecer o serviço que
deveriam. Mesmo que o atacante não consiga acesso a informações
privilegiadas, ele sem dúvida causará danos à empresa.
4. IPSec: Visão
4.1 Abordando o problema
Não há respostas simples para a segurança na Internet. Todas as soluções
necessitam de muitos elementos, incluindo uma boa política de segurança,
padrões que definam o que deve ser protegido, um conjunto de procedimentos
que detalham como implementar as políticas e um conjunto de tecnologias que
forneçam a proteção.
Confidencialidade, integridade e autenticidade são os serviços-chave para a
proteção contra as ameaças descritas na seção anterior. Com a encriptação
garantimos a privacidade dos dados, com uma forte autenticação feita na
camada de rede podemos garantir a origem dos dados.
4.2 O que é IPSec
IPSec não é o mecanismo de encriptação ou autenticação, mas sim o que vem
gerenciar estes. Em poucas palavras, é um framework (um conjunto de diversas
ferramentas, compondo um sistema) de padrões abertos que visa a garantir uma
comunicação segura em redes IP. Baseado em padrões desenvolvidos pela IETF
(Internet Engineering Task Force, organização que desenvolve os padrões da
Internet), o IPSec busca garantir confidencialidade, integridade e autenticidade
nas comunicações de dados em uma rede IP pública.
Encriptação e autenticação podem ser implementadas tanto na camada de rede,
quanto na de enlace ou aplicação. Antes do IPSec, as redes adotavam soluções
parciais, que resolviam apenas parte dos problemas. Por exemplo, a utilização de

SSL (Secure Sockets Layer, que simulam túneis seguros entre aplicativos)
fornece encriptação no nível de aplicação, muito usado em navegadores de
Internet, por exemplo, para acesso à serviços bancários. Uma das deficiências da
encriptação no nível de aplicação é que ela protege somente os dados enviados
pela aplicação que a está usando, mas não de todas as outras. Cada sistema ou
aplicativo deve estar adaptado a SSL, para que uma segurança geral possa ser
garantida. Atualmente, a maior parte dos aplicativos não utiliza SSL.
Já em instituições militares, o que vem sendo usado há anos é a encriptação no
nível do enlace de dados. Neste esquema, todas as comunicações estarão
protegidas por dispositivos de encriptação colocados em cada fim do enlace.
Apesar de oferecer excelente cobertura, este tipo de encriptação necessita de um
par de dispositivos de encriptação a cada enlace, o que pode ser inviável;
também não é adequado para a Internet, já que apenas os enlaces dentro de um
sistema autônomo estarão ao alcance das empresas/instituições.
O IPSec implementa encriptação e autenticação na camada de rede, fornecendo
uma solução de segurança fim-a-fim, ao contrário da anterior (enlace), que é
ponto-a-ponto. O IPSec pode ser implementado nos roteadores ou no sistema
operacional dos terminais, assim os aplicativos não precisam de alterações para
poder utilizar comunicações seguras. Como os pacotes encriptados têm o mesmo
formato de pacotes IP comuns, eles podem ser roteados sem problemas em
qualquer rede IP, e sem qualquer alteração nos equipamentos de rede
intermediários. Os únicos dispositivos de rede que precisam ser alterados são os
do início e fim das comunicações IPSec, reduzindo assim os custos de
implementação e gerenciamento.
A figura 4 mostra onde a encriptação atua nas diferentes camadas.

Encriptação na camada de enlace, na de rede e na aplicação.
4.3 Tecnologias
IPSec combina diversas tecnologias diferentes de segurança em um sistema
completo que provê confidencialidade, integridade e autenticidade, empregando
atualmente:
• mecanismo de troca de chaves de Diffie-Hellman;
• criptografia de chave pública para assinar as trocas de chave de Diffie-
Hellman, garantindo assim a identidade das duas partes e evitando ataques
do tipo man-in-the-middle (onde o atacante se faz passar pela outra parte
em cada um dos sentidos da comunicação);
• algoritmos de encriptação para grandes volumes de dados, como o DES
(Data Encryption Standard);
• algoritmos para cálculo de hash (resto de uma divisão, de tamanho fixo)
com utilização de chaves, com o HMAC, combinado com os algoritmos de
hash tradicionais como o MD5 ou SHA, autenticando os pacotes;
• certificados digitais assinados por uma autoridade certificadora, que agem
como identidades digitais.

4.4 Detalhes do IPSec
Na realidade, além das tecnologias mencionadas no item anterior, o IPSec
também se refere a diversos outros protocolos (mencionados nas RFCs 2401-
2411 e 2451) para proteger datagramas IP. Estes padrões são:
• Protocolo de Segurança IP, que define que informações adicionar ao
pacote IP para permitir o controle da confidencialidade, autenticidade e
integridade, assim como a forma em que os dados devem ser encriptados;
• Internet Key Exchange (IKE), que negocia Associações de Segurança
(Security Association, SA) entre duas entidades e realiza a troca de chaves.
O uso da IKE não é obrigatório, mas a configuração manual de Associações
de Segurança é difícil e trabalhosa, torna-se impossível para comunicações
seguras em larga escala.
Pacotes IPSec
É definido um novo conjunto de cabeçalhos a serem adicionados em datagramas
IP. Os novos cabeçalhos são colocados após o cabeçalho IP e antes do cabeçalho
da camada superior (como o dos protocolos de transporte TCP ou UDP). Estes
novos cabeçalhos é que dão as informações para proteção das informações
(payload) do pacote IP:
• Authentication Header (AH): este cabeçalho, ao ser adicionado a um
datagrama IP, garante a integridade e autenticidade dos dados, incluindo
os campos do cabeçalho original que não são alterados entre a origem e o
destino; no entanto, não fornece confidencialidade. É utilizada uma função
hash com chave, ao invés de assinatura digital, pois o mecanismo de
assinatura digital é bem mais lento e poderia reduzir a capacidade da rede.
• Encapsulating Security Payload (ESP): este cabeçalho protege a
confidencialidade, integridade e autenticidade da informação. Se o ESP for
usado para validar a integridade, ele não inclui os campos invariantes do
cabeçalho IP.
AH e ESP podem ser usados separadamente ou em conjunto, mas para a maioria
das aplicações apenas um deles é suficiente. Para os dois cabçalhos, o IPSec não
especifica quais algoritmos de segurança devem ser utilizados, mas dá uma
relação dos possíveis algoritmos, todos padronizados e bastante difundidos.
Inicialmente, quase todas as implementações trabalham com MD5 (da RSA Data
Security) e o Secure Hash Algorithm (SHA, do governo dos EUA) para
integridade e autenticação. O DES é o algoritmo mais comumente usado para a
encriptação dos dados, apesar de muitos outros estarem disponíveis, de acordo
com as RFCs, como o IDEA, Blowfish e o RC4.

Modos de operação
O IPSec fornece dois modos de operação, como mostrado nas figuras 5 e 6.
No modo de transporte, somente a informação (payload) é encriptada, enquanto
o cabeçalho IP original não é alterado. Este modo tem a vantagem de adicionar
apenas alguns octetos a cada pacote, deixando que dispositivos da rede pública
vejam a origem e o destino do pacote, o que permite processamentos especiais
(como de QoS) baseados no cabeçalho do pacote IP. No entanto, o cabeçalho da
camada 4 (transporte) estará encriptado, limitando a análise do pacote. Passando
o cabeçalho sem segurança, o modo de transporte permite que um atacante faça
algumas análises de tráfego, mesmo que ele não consiga decifrar o conteúdo das
mensagens.
No modo de tunelamento, todo o datagrama IP original é encriptado e passa a
ser o payload de um novo pacote IP. Este modo permite que um dispositivo de
rede, como um roteador, aja como um Proxy IPSec (o dispositivo realiza a
encriptação em nome dos terminais). O roteador de origem encripta os pacotes e
os envia ao longo do túnel IPSec; o roteador de destino decripta o datagrama IP
original e o envia ao sistema de destino. A grande vantagem do modo de
tunelamento é que os sistemas finais não precisam ser modificados para
aproveitarem os benefícios da segurança IP; além disto, esse modo também
protege contra a análise de tráfego, já que o atacante só poderá determinar o
ponto de início e de fim dos túneis, e não a origem e o destino reais.
Cabeçalho genérico para o modo de transporte
Exemplo de um cabeçalho do modo túnel
Como definido pelo IETF, o modo de transporte só pode ser utilizado quanto
tanto a origem quanto o destino “entendem” IPSec. Na maior parte dos casos, é
mais fácil trabalhar com o modo de tunelamento, o que permite a implementação

do IPSec sem que sistemas operacionais ou aplicativos nos terminais e
servidores precisem ser alterados.
Associações de Segurança (Security Association, SA)
Como visto, o IPSec fornece diversas opções para executar a encriptação e
autenticação na camada de rede. Quando dois nós desejam se comunicar com
segurança, eles devem determinar quais algoritmos serão usados (se DES ou
IDEA, MD5 ou SHA). Após escolher os algoritmos, as chaves de sessão devem ser
trocadas. Como vemos, há uma certa quantidade de informações que precisam
ser negociadas. A Associação de Segurança é o método utilizado pelo IPSec para
lidar com todos estes detalhes de uma determinada sessão de comunicação. Uma
SA representa o relacionamento entre duas ou mais entidades que descreve
como estas utilizarão os serviços de segurança para se comunicarem. As SAs
também podem ser utilizadas por outras entidades, como IKEs, para descrever
os parâmetros de segurança entre dois dispositivos IKE.
As SAs são unidirecionais, o que significa que para cada par de sistemas que se
comunicam, devemos ter pelo menos duas conexões seguras, uma de A para B e
outra de B para A. As SAs são identificadas de forma única pela associação entre
um número aleatório chamado SPI (Security Parameter Index) e o endereço IP
de destino. Quando um sistema envia um pacote que requer proteção IPSec, ele
olha as SAs armazenadas em seus banco de dados, processa as informações, e
adiciona o SPI da SA no cabeçalho IPSec. Quando o destino IPSec recebe o
pacote, ele procura a SA em seus banco de dados de acordo com o endereço de
destino a de SPI, e então processa o pacote da forma necessária. As SAs são
simplesmente o relatório das políticas de segurança que serão usadas entre dois
dispositivos.
Protocolo de gerenciamento de chaves (Internet Key Management
Protocol, IKMP)
O IPSec assume que as SAs já existem para ser utilizado, mas não especifica
como elas serão criadas. O IETF decidiu dividir o processo em duas partes: o
IPSec fornece o processamento dos pacotes, enquanto o IKMP negocia as
associações de segurança. Após analisar as alternativas disponíveis, o IETF
escolheu o IKE como o método padrão para configuração das SAs para o IPSec.
O IKE cria um túnel seguro e autenticado entre duas entidades, para depois
negociar SAs para o IPSec. Este processo requer que duas entidades se
autentiquem entre si e estabeleçam chaves compartilhadas.

Autenticação
As duas partes devem ser autenticadas entre si. O IKE é bastante flexível e
suporta diversos tipos de autenticação. As duas entidades devem escolher o
protocolo de autenticação que será utilizado através de negociação. Neste
momento, os seguintes mecanismos são implementados:
• chaves compartilhadas já existentes: a mesma chave é instalada em cada
entidade. Os dois IKEs autenticam-se enviando ao outro um hash com
chave de um conjunto de dados que inclui a chave compartilhada existente.
Se o receptor conseguir criar o mesmo hash usando sua chave já existente,
ele sabe que os dois IKE possuem a mesma chave, autenticando assim a
outra parte;
• criptografia de chave pública: cada parte gera um número aleatório, e
encripta este número com a chave pública da outra parte. A capacidade de
cada parte computar um hash com chave contendo o número aleatório da
outra parte, decriptado com a chave privada local, assim como outras
informações disponíveis pública e privadamente, autentica as duas partes
entre si. Este método permite que as transações sejam negadas, ou seja,
uma das partes da troca pode, plausivelmente, negar que tenha feito parte
da troca. Somente o algoritmo de chave pública RSA é suportado
atualmente.
• assinatura digital: cada dispositivo assina digitalmente um conjunto de
dados e o envia para a outra parte. Este método a similar ao anterior, mas
ele não permite que uma entidade repudie a participação na troca. Tanto o
algoritmo de chave pública RSA quanto o DSS (Digital Signature Standard)
são suportados atualmente.
Tanto a assinatura digital quanto a criptografia de chave pública necessitam o
uso de certificados digitais para validar o mapeamento entre a chave pública e a
chave privada. O IKE permite que certificados sejam acessados
independentemente (por exemplo, através do DNSSEC), ou que dois dispositivos
troquem explicitamente os certificados como parte do IKE.
Troca de chaves
As duas partes devem possuir uma chave de sessão compartilhada para poderem
encriptar o túnel IKE. O protocolo de Diffie-Hellman é usado para que as
entidades concordem em uma chave de sessão. A troca é autenticada como
descrito acima para prevenir contra ataques do tipo “man-in-the-middle”.

Utilizando o IKE com o IPSec
A autenticação e a troca de chaves criam a SA entre os IKEs, um túnel seguro
entre os dois dispositivos. Um dos lados do túnel oferece um conjunto de
algoritmos, e o outro deve aceitar uma das ofertas ou rejeitar a conexão. Quando
os dois lados concordam com os algoritmos que serão utilizados, eles devem
produzir as chaves que serão utilizadas pelo IPSec no AH ou ESP, ou os dois. A
chave compartilhada pelo IPSec é diferente da compartilhada pelos IKEs; ela
pode ser obtida pelo método de Diffie-Hellman novamente, para garantir o sigilo,
ou atualizando a criada pela troca original para gerar a SA IKE, fazendo o hash
com outro número aleatório. O primeiro método, apesar de fornecer maior
segurança, é mais lento. Após esse passos, a SA IPSec é estabelecida.
Como mostrado na figura 8, o IPSec usa o IKE para iniciar uma SA. O primeiro
pacote de A para B que deve ser encriptado inicia o processo. O processo IKE
monta um túnel seguro entre B e A, onde a SA IPSec será negociada. A então
pode usar esta SA para enviar dados de forma segura para B.
Uso do IKE pelo IPSec
Juntando todos os passos descritos anteriormente, temos o seguinte exemplo. B
quer iniciar uma comunicação segura com A, enviando o primeiro pacote de
dados. Quando o roteador de B recebe este pacote, ele olha suas políticas de
segurança e vê este pacote deve ser encriptado; a política de segurança, que
deve ser configurada anteriormente, também diz que o outro ponto do túnel
IPSec será o roteador de A. O roteador de B procura se já há alguma SA IPSec
com o roteador. Se ainda não existe, ele pede uma para o IKE; se os dois
roteadores já compartilham uma SA IKE, a SA IPSec pode ser rapidamente
gerada. Se ainda não compartilham uma SA IKE, ela deve ser criada antes que
possa ser negociada uma SA IPSec. Como parte deste processo, os dois
roteadores trocam certificados digitais, que estão assinados por alguma
autoridade certificadora que os roteadores de A e B confiam. Quando a sessão
IKE é ativada, os dois roteadores podem então negociar a SA IPSec; quando esta
última é ativada, significa que os dois roteadores concordaram num algoritmo de
encriptação (por exemplo o DES) e um de autenticação (como o MD5), e agora
compartilham de uma chave de sessão. Agora o roteador de B pode encriptar o
pacote IP que B que enviar a A, colocá-lo em um novo pacote IPSec enviá-lo ao

oteador de A. Quando o roteador de A recebe o pacote IPSec, ele faz uma busca
na SA IPSec, e então processa o pacote e envia o datagrama original para A.
Note que todos os passos são feitos pelos roteadores de A e B, deixando o
processo transparente aos usuários.
Na prática a política de segurança pode ser bastante flexível: os roteadores
podem decidir quais pacotes devem ser encriptados ou autenticados, de acordo
com alguma combinação entre os endereços de origem e destino, portas e
protocolo de transporte. Cada um dos tipos de comunicação pode ser autenticado
e encriptado separadamente, com chaves diferentes.

VPN - Virtual Private
Network
Rede Privada Virtual
Introdução
“Virtual Private Network” ou Rede Privada Virtual, é uma rede privada
construída sobre a infra-estrutura de uma rede pública, normalmente a
Internet. Ou seja, ao invés de se utilizar links dedicados ou redes de pacotes
(como Frame Relay ou X.25) para conectar redes remotas, utiliza-se a infraestrutura
da Internet.
O conceito de VPN surgiu da necessidade de se utilizar redes de comunicação
não confiáveis para trafegar informações de forma segura. As redes públicas são
consideradas não confiáveis, tendo em vista que os dados que nelas trafegam
estão sujeitos a interceptação e captura. Em contrapartida, estas redes públicas
tendem a ter um custo de utilização inferior aos necessários para o
estabelecimento de redes proprietárias, envolvendo a contratação de circuitos
exclusivos e independentes.
A principal motivação no uso das VPNs é a financeira, como alternativa para
redução dos custos de comunicação de dados, oferecendo transporte de pacotes
IPs de modo seguro através de Internet, com o objetivo de conectar vários sites .

Com o explosivo crescimento da Internet, o constante aumento de sua área de
abrangência, e a expectativa de uma rápida melhoria na qualidade dos meios de
comunicação associado a um grande aumento nas velocidades de acesso e
backbone, esta passou a ser vista como um meio conveniente para as
comunicações corporativas. No entanto, a passagem de dados sensíveis pela
Internet somente se torna possível com o uso de alguma tecnologia que torne
esse meio altamente inseguro em um meio confiável. Com essa abordagem, o uso
de VPN sobre a Internet parece ser uma alternativa viável e adequada. No
entanto, veremos que não é apenas em acessos públicos que a tecnologia de VPN
pode e deve ser empregada.
Aplicativos desenvolvidos para operar com o suporte de uma rede privada não
utilizam recursos para garantir a privacidade em uma rede pública. A migração
de tais aplicações é sempre possível, no entanto, certamente incorreria em
atividades dispendiosas e exigiriam muito tempo de desenvolvimento e testes. A
implantação de VPN pressupõe que não haja necessidade de modificações nos
sistemas utilizados pelas corporações, sendo que todas as necessidades de
privacidade que passam a ser exigidas sejam supridas pelos recursos adicionais
que sejam disponibilizados nos sistemas de comunicação.
Tipos de VPN
Existem vários tipos de implementação de VPN's. Cada uma tem suas
especificações próprias, assim como características que devem ter uma atenção
especial na hora de implementar.
Entre os tipos de VPN, destacam-se três principais:
Intranet VPN
Extranet VPN

Acesso Remoto VPN
Intranet VPN
Em uma Intranet VPN, que pode, por exemplo facilitar a comunicação entre
departamentos de uma empresa, um dos quesitos básicos a considerar é a
necessidade de uma criptografia rápida, para não sobrecarregar a rede (que tem
de ser rápida).
Outro requisito essencial é a confiabilidade que garanta a prioridade de
aplicações críticas, como por exemplo, sistemas financeiros, banco de dados. E
por último, é importante a facilidade de gerenciamento, já que numa rede
interna, tem-se constantes mudanças de usuários, seus direitos,etc.
Acesso Remoto VPN
Uma VPN de acesso remoto conecta uma empresa à seus empregados que
estejam distante fisicamente da rede. Neste caso torna-se necessário um
software cliente de acesso remoto. Quanto aos requisitos básicos, o mais
importante é a garantia de QoS(Quality of Service), isto porque, geralmente
quando se acessa remotamente de um laptop, você está limitado à velocidade do
modem. Outro item não menos importante é uma autenticação rápida e eficiente,
que garanta a identidade do usuário remoto. E por último, um fator importante, é
a necessidade de um gerenciamento centralizado desta rede, já que ao mesmo
tempo, pode-se ter muitos usuários remotos logados, o que torna necessário que
todas as informações sobre os usuários, para efeitos de autenticação por
exemplo, estejam centralizadas num único lugar.
Extranet VPN
Extranet VPN's são implementadas para conectar uma empresa à seus sócios,
fornecedores, clientes, etc... Para isso é necessário uma solução aberta,para
garantir a interoperabilidade com as várias soluções que as as empresas
envolvidas possam ter em suas redes privadas. Outro ponto muito importante a
se considerar é o controle de tráfego, o que minimiza o efeitos dos gargalos
existentes em possíveis nós entre as redes, e ainda garante uma resposta rápida
e suave para aplicações críticas.
Abaixo, uma figura que melhor ilustra uma Intranet VPN.
Modelo de uma VPN

Funções Básicas
A utilização de redes públicas tende a apresentar custos muito menores que os
obtidos com a implantação de redes privadas, sendo este, justamente o grande
estímulo para o uso de VPNs. No entanto, para que esta abordagem se torne
efetiva, a VPN deve prover um conjunto de funções que garanta
Confidencialidade, Integridade e Autenticidade.
Confidencialidade
Tendo em vista que estarão sendo utilizados meios públicos de
comunicação, a tarefa de interceptar uma seqüência de dados é
relativamente simples. É imprescindível que os dados que trafeguem
sejam absolutamente privados, de forma que, mesmo que sejam
capturados, não possam ser entendidos.
Integridade
Na eventualidade dos dados serem capturados, é necessário garantir que estes
não sejam adulterados e re-encaminhados, de tal forma que quaisquer tentativas
nesse sentido não tenham sucesso, permitindo que somente dados válidos sejam
recebidos pelas aplicações suportadas pela VPN.
Autenticidade

Somente usuários e equipamentos que tenham sido autorizados a
fazer parte de uma determinada VPN é que podem trocar dados
entre si; ou seja, um elemento de uma VPN somente reconhecerá
dados originados em por um segundo elemento que seguramente
tenha autorização para fazer parte da VPN.
Dependendo da técnica utilizada na implementação da VPN, a privacidade das
informações poderá ser garantida apenas para os dados, ou para todo o pacote
(cabeçalho e dados). Quatro técnicas podem ser usadas para a implementação de
soluções VPN:
Modo Transmissão
Somente os dados são criptografados, não havendo mudança no
tamanho dos pacotes. Geralmente são soluções proprietárias,
desenvolvidas por fabricantes.
Modo Transporte
Somente os dados são criptografados, podendo haver mudança no
tamanho dos pacotes. É uma solução de segurança adequada, para
implementações onde os dados trafegam somente entre dois nós da
comunicação.
Modo Túnel Criptografado
Tanto os dados quanto o cabeçalho dos pacotes são criptografados,
sendo empacotados e transmitidos segundo um novo endereçamento
IP, em um túnel estabelecido entre o ponto de origem e de destino.
Modo Túnel Não Criptografado
Tanto os dados quanto o cabeçalho são empacotados e
transmitidos segundo um novo endereçamento IP, em um túnel
estabelecido entre o ponto de origem e destino. No entanto,
cabeçalho e dados são mantidos tal como gerados na origem, não
garantindo a privacidade.

Para disponibilizar as funcionalidades descritas anteriormente, a
implementação de VPN lança mão dos conceitos e recursos de criptografia,
autenticação e controle de acesso.
Criptografia
A criptografia é implementada por um conjunto de métodos de tratamento e
transformação dos dados que serão transmitidos pela rede pública. Um conjunto
de regras é aplicado sobre os dados, empregando uma seqüência de bits (chave)
como padrão a ser utilizado na criptografia. Partindo dos dados que serão
transmitidos, o objetivo é criar uma seqüência de dados que não possa ser
entendida por terceiros, que não façam parte da VPN, sendo que apenas o
verdadeiro destinatário dos dados deve ser capaz de recuperar os dados
originais fazendo uso de uma chave.
São chamadas de Chave Simétrica e de Chave Assimétrica as tecnologias
utilizadas para criptografar dados.
Chave Simétrica ou Chave Privada
É a técnica de criptografia onde é utilizada a mesma chave para criptografar e
decriptografar os dados. Sendo assim, a manutenção da chave em segredo é
fundamental para a eficiência do processo.
Chave Assimétrica ou Chave Pública
É a técnica de criptografia onde as chaves utilizadas para
criptografar e decriptografar são diferentes, sendo, no entanto
relacionadas. A chave utilizada para criptografar os dados é formada
por duas partes, sendo uma pública e outra privada, da mesma forma
que a chave utilizada para decriptografar.
Algoritmos para Criptografia
DES - Data Encryption Standard
É um padrão de criptografia simétrica, adotada pelo governo dos
EUA em 1977.

Triple-DES
O Triple-DES é uma variação do algoritmo DES, sendo que o
processo tem três fases: A seqüência é criptografada, sendo em
seguida decriptografada com uma chave errada, e é novamente
criptografada.
RSA - Rivest Shamir Adleman
É um padrão criado por Ron Rivest, Adi Shamir e Leonard
Adleman em 1977 e utiliza chave pública de criptografia, tirando
vantagem do fato de ser extremamente difícil fatorar o produto de
números primos muito grandes.
Diffie-Hellman
Foi desenvolvido por Diffie e Hellman em 1976. Este algoritmo
permite a troca de chaves secretas entre dois usuários. A chave
utilizada é formada pelo processamento de duas outras chaves uma
pública e outra secreta.
Integridade
A garantia de integridade dos dados trocados em uma VPN pode ser fornecida
pelo uso de algoritmos que geram, a partir dos dados originais, códigos binários
que sejam praticamente impossíveis de serem conseguidos, caso estes dados
sofram qualquer tipo de adulteração. Ao chegarem no destinatário, este executa
o mesmo algoritmo e compara o resultado obtido com a seqüência de bits que
acompanha a mensagem, fazendo assim a verificação.
Algoritmos para Integridade
SHA-1 - Secure Hash Algorithm One
É um algoritmo de hash que gera mensagens de 160 bits, a partir
de uma seqüência de até 2 64 bits.

MD5 - Message Digest Algorithm 5
É um algoritmo de hash que gera mensagens de 128 bits, a partir
de uma seqüência de qualquer tamanho.
Autenticação
A Autenticação é importante para garantir que o originador dos dados que
trafeguem na VPN seja, realmente, quem diz ser. Um usuário deve ser
identificado no seu ponto de acesso à VPN, de forma que, somente o tráfego de
usuários autenticados transite pela rede. Tal ponto de acesso fica responsável
por rejeitar as conexões que não sejam adequadamente identificadas. Para
realizar o processo de autenticação, podem ser utilizados sistemas de
identificação/senha, senhas geradas dinamicamente, autenticação por RADIUS
(Remote Authentication Dial-In User Service) ou um código duplo.
A definição exata do grau de liberdade que cada usuário tem dentro do
sistema, tendo como conseqüência o controle dos acessos permitidos, é mais
uma necessidade que justifica a importância da autenticação, pois é a partir da
garantia da identificação precisa do usuário que poderá ser selecionado o perfil
de acesso permitido para ele.
Protocolos para VPN
IPSec
IPSec é um conjunto de padrões e protocolos para segurança relacionada com
VPN sobre uma rede IP, e foi definido pelo grupo de trabalho denominado IP
Security (IPSec) do IETF (Internet Engineering Task Force).
O IPSec especifica os cabeçalhos AH (Authentication Header) e ESP

(Encapsulated Security Payload), que podem se utilizados independentemente ou
em conjunto, de forma que um pocote IPSec poderá apresentar somente um dos
cabeçalhos (AH ou ESP) ou os dois cabeçalhos.
Authentication Header (AH)
Utilizado para prover integridade e autenticidade dos dados
presentes no pacote, incluindo a parte invariante do cabeçalho, no
entanto, não provê confidencialidade.
Encapsulated Security Payload (ESP)
Provê integridade, autenticidade e criptografia à área de dados do
pacote.
A implementação do IPSec pode ser feita tanto em Modo Transporte como em
Modo Tunel.

L2TP e PPTP
Estes são protocolos utilizados em VPDNs (Virtual Private Dial Networks), ou
seja, proporcionam o acesso de usuários remotos acessando a rede corporativa
através do pool de modems de um provedor de acesso.
Vale aqui uma discussão preliminar a respeito da diferença entre túneis
"iniciados pelo cliente" e túneis "iniciados pelo provedor de acesso" :
Túneis "iniciados pelo cliente" são também chamados de "voluntários", onde os
túneis são criados por requisições do usuário para ações específicas e túneis
"iniciados pelo provedor de acesso" são chamados de "compulsórios", já que são
criados pelo provedor não proporcionando ao usuário nenhuma escolha e/ou
intromissão.
L2TP é um protocolo de túnelamento "compulsório". Essencialmente um
mecanismo para repassar o usuário a outro nó da rede.
No momento da interligação do usuário remoto com o provedor de acesso,
após a devida autenticação e carga de uma configuração, um túnel é
estabelecido até um ponto de terminação ( um roteador por exemplo ) prédeterminado,
onde a conexão PPP é encerrada.
Já o PPTP, um protocolo "voluntário", permite que os próprios sistemas dos
usuários finais estabeleçam um túnel a uma localidade arbitrária sem a
intermediação do provedor de acesso.
Enquanto L2TP e PPTP soam bastante parecido, existem diferenças sútis
quanto a sua aplicação. Existem diferenças na determinação de quem possuí o
controle sobre o túnel e porque precisa ter.
Na situação onde é utilizado o protocolo PPTP, o usuário remoto tem a
possibilidade de escolher o destino do túnel. Este fato é importante se os
destinos mudam com muita frequência, e nenhuma modificação se torna
necessária nos equipamentos por onde o túnel passa. É também siginificativo o
fato de que túneis PPTP são transparentes aos provedores de acesso. Nenuma
ação se torna necessária além do serviço comum de prover acesso a rede.
Usuários com perfis diferenciados com relação a locais de acesso – diferentes

cidades, estados e países – se utilizam com mais frequencia do protocolo PPTP
pelo fato de se tornar desnecessária a intermediação do provedor no
estabelecimento do túnel. É somente necessário saber o número local para
acesso que o software no laptop realiza o resto.
Onde se utiliza L2TP, temos um comportamento diferente de usuários e de
provedores. Agora o controle está nas mãos do provedor e ele está fornecendo
um serviço extra ao somente provimento do acesso. Esta é uma certa
desvantagem para o usuário e vantagem para o provedor : este serviço extra
pode ser cobrado.
A escolha de qual protocolo utilizar é um baseado na determinação da posse
do controle: se o controle deve ficar nas mãos do provedor ou do usuário final.
Nível de Segurança
A especificação da VPN a ser implantada deve tomar por base o grau de
segurança que se necessita, ou seja, avaliando o tipo de dado que deverá

trafegar pela rede e se são dados sensíveis ou não. Dessa definição depende a
escolha do protocolo de comunicação, dos algoritmos de criptografia e de
Integridade, assim como as políticas e técnicas a serem adotadas para o controle
de acesso. Tendo em vista que todos esses fatores terão um impacto direto sobre
a complexidade e requisitos dos sistemas que serão utilizados, quanto mais
seguro for o sistema, mais sofisticados e com capacidades de processamento
terão de ser os equipamentos, principalmente, no que se refere a complexidade e
requisitos exigidos pelos algoritmos de criptografia e integridade.
Os habilitadores das tecnologias de segurança são de conhecimento comum e
são apresentados os mesmos abaixo :
• CHAP Challenge Handshake Authentication Protocol
• RADIUS Remote Authentication Dial-in User Service
• Certificados digitais
• Encriptação de Dados
Os três primeiros visam autenticar usuários e controlar o acesso a rede. O
último visa prover confidencialidade e integridade aos dados transmitidos.

TCPDUMP
TCPDUMP(1)
NOME
tcpdump- captura o tráfego em uma rede
SINOPSE
tcpdump [ -adeflnNOpqRStvxX ] [ -c contagem ] [ -F arquivo ] [ -i interface ] [ -m
módulo ] [ -r arquivo ] [ -s tamanho ] [ -T tipo ] [ -w arquivo ] [ -E algo:secret ]
[ expressão ]
DESCRIÇÃO
Tcpdump imprime a saída dos cabeçalhos dos pacotes na interface de rede que
combinam com a expressão booleana.
No SunOS com nit ou bpf: Para rodar tcpdump você necessita ter permissão de
acesso a /dev/nit ou /dev/bpf*.
No Solaris com dlpi: Você precisa ter acesso de leitura/escrita ao pseudo
dispositivo de rede, por exemplo /dev/le.
No HP-UX com dlpi: Você necessita ser root ou ter este instalado com setuid
para root.
No IRIS com snoop: Você necessita ser root ou ter este instalado com setuid para
root.
No Linux: Você necessita ser root ou ter este instalado com setuid para root.
No Ultrix e Digital UNIX: Somente o super-usuário tem permissão de utilizar o
modo de operação promíscuo usando pfconfig(8), qualquer usuário pode rodar o
tcpdump.
No BSD: Você necessita ter acesso de leitura em /dev/bpf*.
OPÇÕES:
-a Espera para converter endereços de rede e broadcast para nomes.
-c Sai após receber contagem de pacotes.
-d Captura os pacotes compilados com o código do pacote em um formato
humanamente legível para a saída padrão e sai.
-dd Captura os pacotes com o código do pacote como um fragmento de programa
em C.
-ddd Captura os pacotes com o código do pacote como números decimais
(precedidos de um contador).
-e Imprime a camada de link do cabeçalho na linha capturada.

-E Use algo:secreto para decriptar pacotes IPsec ESP.
Algoritmos costumam ser des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc,
ou nenhum. O padrão é des-cbc.
A habilidade de descriptar pacotes só estará presente se o tcpdump for
compilado com suporte a criptografia habilitado. secreto é o texto ASCII para a
chave ESP secreta.
Nós não tentaremos um valor binário arbitrário neste momento.
A opção assume a RFC2406 do ESP, não a RFC1827 também do ESP.
A opção é somente para propósitos de depuração, e o uso desta opção com uma
chave secreta TRULY é desencorajada.
Pela apresentação da chave secreta do IPsec na linha de comando você consegue
deixar isto visível para outros, via ps(1) e em outras ocasiões.
-f Imprime a saída dos endereços internet numéricamente no lugar de
simbólicamente (essa opção tenta descobrir sérios problemas em servidores YP
utilizando Sun -- usualmente causa um loop eterno na conversão de não-locais
números internet).
-F Utiliza o arquivo para a entrada de um filtro de expressão.
Qualquer expressão adicional passada via linha de comando é ignorada.
-i Escute na interface. Se não especificado o tcpdump irá procurar a lista de
interfaces do sistema, interfaces ativas (excluindo a de loopback).
Em sistemas Linux com kernels 2.2 ou superiores, um argumento ``any'' para
interfaces pode ser usado para capturar pacotes de todas as interfaces.
Note que as capturas em ``any'' (todos) os dispositivos não poderá ser feita no
modo promíscuo.
-l Deixe a linha de saída "bufferizada". Usualmente se você quizer ver os dados
enquanto são capturados.
Ex: ``tcpdump -l | tee dat'' ou ``tcpdump -l > dat & tail -f dat''.
-n Não converter endereços (Ex: endereços de hosts e números de portas, etc)
para nomes.
-N Não imprime a qualificação do domínio dos nomes de host. Ex: se você passar
esta flag para o tcpdump, ele imprimirá ``nic'' ao invés de ``nic.ddn.mil''.
-m Carrega as definições do módulo SMI MIB do arquivo módulo. Esta opção
pode ser usada em diversas vezes para carregar severos módulos MIB no
tcpdump.
-O Não execute o otimizador de códigos de pacote. Isso usualmente só será
utilizado se você suspeitar de uma falha no otimizador.
-p Não coloca a interface em modo promíscuo. Note que esta interface pode
precisar entrar em modo promíscuo por alguma outra razão; então, `-p' não
poderá ser usado como uma abreviação para `ether host {local-hw- addr} ou

ether broadcast'.
-q Saída rápida (quieta?). Imprime menos informações do protocolo em saídas de
linhas mais curtas.
-r Lê os pacotes do arquivo (isso é criado com a opção -w). A entrada padrão será
utilizada se o arquivo for ``-''.
-s Sniffa tamanho de bytes de arquivo deste pacote.
O default é 68 (com SunOS's NIT, o mínimo é atualmente 96). 68 bytes é
adequado para IP, ICMP, TCP e UDP porém pode truncar informações de
protocolos de pacotes DNS e NFS (olhe na frente). Os pacotes serão truncados
porque um tamanho limitado foi indicado e a saída será ``[|proto]'', onde proto é
o nome do nível do protocolo onde a truncagem ocorreu.
Note que aumentar muito o tamanho pode causar uma delonga no tempo para
processar estes pacotes e, efetivamente, diminuir a quantidade de pacotes
capturados.
Isso pode causar perda de pacotes. Você deve limitar o tamanho dos pacotes
para o menor possível onde você conseguirá obter a informação que lhe
interessar. Coloque o tamanho em 0 para que o tcpdump capture os pacotes
completos, independente dos seus tamanhos.
-T Força que os pacotes selecionados pela "expressão" sejam interpretados pelo
tipo especificado. Atualmente, os tipos conhecidos são cnfp (Protocolo Cisco
NetFlow), rpc (Chamadas de procedimento remotas), rtp (Protocolo de
aplicações em tempo real), rtcp (Protocolo de controle de aplicações em tempo
real), snmp (Protocolo simples de gerenciamento de redes), vat (Aplicação de
Visual Audio), e wb (Placa Branca distribuída).
-R Assume que pacotes ESP/AH são baseados em especificações antigas
(RFC1825 a RFC1829). Se especificado, o tcpdump não irá imprimir o campo de
prevensão. No entanto, este não é um campo de versão na especificação do
protocolo ESP/AH, portanto o tcpdump não poderá deduzir a versão do
protocolo.
-S Imprimir o absoluto, em lugar do relativo, número de sequência TCP.
-t Não imprimir o timestamp na linha capturada.
-tt Imprimir um não formatado timestamp na linha capturada.
-v Detalhamento da saída (não muito). Por exemplo, o tempo de vida,
identificação, tamanho total e opções do cabeçalho IP serão impressos. Também
se habilita opções adicionais de checagem da integridade dos pacotes como
verificação do checksum dos cabeçalhos IP e ICMP.
-vv Saída mais detalhada. Por exemplo, campos adicionais serão impressos em
pacotes NFS de resposta.

-vvv Saída mais detalhada ainda. Por exemplo, as opções telnet SB ... SE serão
impressas totalmente. Com -X as opções do telnet serão impressas em HEX
muito bem.
-w Escreve os pacotes capturados no arquivo no lugar de selecioná-los e imprimílos.
Isso poderá ser impresso utilizando-se a opção -r. A saída padrão será
utilizada se o arquivo for ``-''.
-x Imprime este pacote (menos seu cabeçalho de camada de link) em
hexadecimal. Tamanho em bytes será impresso (opção -s).
-X Se imprime em hexa, imprime em ASCII também. Se a opção -x também for
selecionada, o pacote será impresso em hexa/ascii.
Isso é muito útil para analizar novos protocolos. Se a opção -x não estiver
selecionada, algumas partes de alguns pacotes serão impressas em hexa/ascii.
expressão
Seleciona quais pacotes serão capturados. Se nenhuma expressão for passada,
todos os pacotes da rede serão capturados.
Se informada, apenas os pacotes que tiverem a expressão como sendo verdadeira
(combinarem com a expressão) serão capturados.
A expressão consiste em uma ou mais primitivas.
Primitivas usualmente consistem em um identificador (nome ou número)
precedidas de um ou mais qualificadores. Existem 3 diferentes qualificadores:
type indica qual identificador (nome ou número) ele se refere. Os tipos possíveis
são: host, net e port.
Exemplos:
``host foo''
``net 128.3''
``port 20''
Se nenhum qualificador type for especificado, host será assumido.
dir indica a direção em que a transferência ocorrerá, para e/ou do identificador.
As direções possíveis são src, dst, src or dst e src and dst
Exemplos:
``src foo''
``dst net 128.3''
''src or dst port ftp-data''
Se nenhum qualificador dir for especificado, src or dst será assumido. Para
camadas de link ``null'' (Ex: protocolos de ponto a ponto como o slip) os
qualificadores de entrada e saída devem ser utilizados para especificar a direção
desejada.
proto Qualificador restrito a estipular um tipo particular de protocolo. As opções
existentes de protocolo são:

ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp e udp.
Ex:
``ether src foo''
``arp net 128.3''
``tcp port 21''
Se não estipulado, todos os protocolos existentes em opção serão assumidos.
Ex:
``src foo'' inclui
``(ip or arp or rarp) src foo''
``net bar'' inclui
``(ip or arp or rarp) net bar'' e
``port 53'' inclui
``(tcp or udp) port 53''.
[`fddi' é atualmente um apelido para `ether'; isso seria idêntico a mensionar ``o
nível de link de dados usado nesta específica interface de rede.''
Cabeçalhos FDDI possuem campos iguais ao Ethernet, de endereços de origem e
destino, e também tipo de pacotes, então você pode filtrar estes campos FDDI
analogamente como você faz com estes campos Ethernet.
Cabeçalhos FDDI também contém outros campos, porém você não poderá
especificá-los em uma expressão de filtro.
Similarmente, `tr' é um apelido para `ether'; o parágrafo anterior sobre os
cabeçalhos FDDI também se aplica a cabeçalhos Token Ring.]
Em adição a isto, existe algumas outras diretivas especiais que não foram
mencionadas: gateway, broadcast, less, greater e expressões aritméticas. Todas
elas serão descritas mais adiante.
Expressões de filtragem mais complexas podem ser feitas utilizando-se
expressões como and, or e not combinadas com as diretivas.
Ex:
``host foo and not port ftp and not port ftp-data''.
Para facilitar, listas de qualificadores idênticos podem ser omitidas.
Ex:
``tcp dst port ftp or ftp-data or domain''
é exatamente o mesmo que:
``tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain''.
Primitivas (diretivas) permitidas são:
dst host host
Verdadeiro se o campo de destino de pacotes IPv4/v6 for host, este pode ser
endereço ou nome.
src host host
Verdadeiro se o campo de origem de pacotes IPv4/v6 for host.

host host
Verdadeiro se o campo de origem ou destino de pacotes IPv4/v6 for host.
Qualquer uma destas expressões de host podem ser precedidas por diretivas tais
como ip, arp, rarp, ou ip6, assim:
ip host host
isso é o equivalente a:
ether proto ip and host host
Se host for um nome com múltiplos endereços IP, eles serão checados para a
correlação.
ether dst ehost
Verdadeiro se o endereço de destino ethernet for ehost. Ehost pode ser um nome
de /etc/ethers ou um número (veja ethers(3N) para o formato numérico).
ether src ehost
Verdadeiro se o endereço de origem ethernet for ethos.
ether host ehost
Verdadeiro se o endereço de origem ou de destino ethernet for ehost.
gateway host
Verdadeiro se o host usado no pacote for um gateway. Ex: o endereço de origem
ou destino ethernet seja um host diferente do endereço de origem ou destino IP.
Host precisa ser um nome e ser encontrado tanto em /etc/hosts quanto
/etc/ethers.
(Uma expressão equivalente seria:
ether host ehost and not host host
que poderia ser usada com nomes ethernet ou números para host / ehost.)
Esta syntax por enquanto não funciona com configurações IPv6.
dst net net
Verdadeiro se o endereço de destino IPv4/v6 do pacote for um número de rede.
Net pode ser um nome de /etc/networks ou um número de rede (veja networks(4)
para maiores detalhes).
src net net
Verdadeiro se o endereço de origem IPv4/v6 do pacote for um número de rede.
net net
Verdadeiro se o endereço de origem ou destino IPv4/v6 do pacote for um número
de rede.
net net mask mask
Verdadeiro se o endereço IP combinar com a rede de mascará especificada. Pode
ser qualificada com src ou dst. Esta syntax também não foi implementada para
redes IPv6.

net net/len
Verdadeiro se o endereço IPv4/v6 combinar com a rede que possua netmask len
bits. Pode ser qualificada com src ou dst.
dst port port
Verdadeiro se o pacote for ip/tcp, ip/udp, ip6/tcp ou ip6/udp e sua porta de
destino seja port.
A porta pode ser um número ou um nome usado em /etc/services (veja tcp(4P) e
udp(4P)).
Se um nome for usado, tanto o número da porta quanto o protocolo serão
checados.
Se um número ou um nome ambíguo for utilizado, somente o número da porta
será checado.
Ex:
dst port 513
Irá imprimir tanto tcp/login quanto udp/who
e
port domain
Irá imprimir tanto tcp/domain quanto udp/domain
src port port
Verdadeiro se o pacote tiver a porta de origem port.
port port
Verdadeiro se a porta de origem ou de destino do pacote for port. Todas as
expressões de porta anteriores podem ser precedidas com diretivas tcp ou udp,
assim:
tcp src port port
Irá capturar apenas pacotes tcp com porta de origem port.
less length
Verdadeiro se o pacote tiver um tamanho menor ou igual a length. Isso seria o
equivalente a:
len = length.
ip proto protocol
Verdadeiro se o pacote for um pacote IP (veja ip(4P)) com protocolo de tipo
protocol. Protocol pode ser um número ou um dos nomes: icmp, icmp6, igmp,
igrp, pim, ah, esp, udp ou tcp.
Note que os identificadores tcp, udp e icmp também são diretivas que podem ser
passadas via backslash (l), isso seria no C-Shell.
Perceba que esta primitiva não observa a regra de protocolo do cabeçalho.

ip6 proto protocol
Verdadeiro se o pacote for um pacote IPv6 com protocolo de tipo protocol.
Observe que esta primitiva não observa a regra de protocolo do cabeçalho.
ip6 protochain protocol
Verdadeiro se o pacote for um pacote IPv6, e conter um cabeçalho de protocolo
com tipo protocol na regra de protocolo do cabeçalho.
Por exemplo:
ip6 protochain 6
combina com qualquer pacote IPv6 com o protocolo TCP definido na regra do
cabeçalho que especifica o protocolo.
O pacote pode conter, por exemplo, cabeçalho de autenticação, roteamento, hopby-hop,
tanto IPv6 quanto TCP. O código BPF emitido por esta primitiva é
complexo e não será otimizado pelo otimizador BPF do tcpdump, porque isto
ficaria muito lento.
ip protochain protocol
Equivalente ao ip6 protochain protocol, porém este é válido para IPv4.
ether broadcast
Verdadeiro se o pacote for um pacote ethernet de broadcast. A diretiva ether é
opcional.
ip broadcast
Verdadeiro se o pacote for um pacote de broadcast IP. Isso irá checar tanto por
tudo-zero quanto tudo-um como convenção para broadcast, e olhará para a
máscara de subrede local.
ether multicast
Verdadeiro se o pacote for um pacote ethernet de multicast. A diretiva ether é
opcional.
Isto é uma abreviação de ``ether[0] & 1 != 0''.
ip multicast
Verdadeiro se o pacote for um pacote IP multicast.
ip6 multicast
Verdadeiro se o pacote for um pacote IPv6 multicast.
ether proto protocol
Verdadeiro se o pacote for um pacote ethernet com tipo protocol.
Protocol pode ser um número ou um dos seguintes nomes:
ip, ip6, arp, rarp, atalk, aarp, dec-net, sca, lat, mopdl, moprc, ou iso.
Observe que estes identificadores também são diretivas que podem ser passados
via backslash (l).
[ No caso do FDDI (ex: ``fddi protocol arp''), a identificação do protocolo vêm do
cabeçalho 802.2 Logical Link Control (LLC), e isto poderá usualmente estar no
topo da camada do cabeçalho FDDI.

O tcpdump assumirá, enquanto filtra o identificador de protocolo, que todos os
pacotes FDDI incluem um cabeçalho LLC e que este cabeçalho estará no formato
SNAP. O mesmo se aplica ao Token Ring.]
decnet src host
Verdadeiro se o endereço de origem DECNET for host, isto poderá ser um
endereço na forma ``10.123'', ou um nome de host DECNET.
[O suporte a nomes de host DECNET só está disponível em sistemas Ultrix
configurados para rodar DECNET.]
decnet dst host
Verdadeiro se o endereço de destino DECNET for host.
decnet host host
Verdadeiro se o endereço de destino ou de origem DECNET for host.
ip, ip6, arp, rarp, atalk, aarp, decnet, iso
Abreviações para:
ether proto p
onde p é um dos protocolos mencionados anteriormente.
lat, moprc, mopdl
Abreviações para:
ether proto p
onde p é um dos protocolos mencionados anteriormente.
Perceba que o tcpdump atualmente não possui "know how" para estes
protocolos.
vlan [vlan_id]
Verdadeiro se o pacote for um pacote VLAN IEEE 802.1Q Se [vlan_id] for
especificado, somente será verdadeiro o pacote que obedeça a especificação
[vlan_id].
Observe que esta é a primeira diretiva vlan encontrada nas mudanças em
expressão com offsets de decodificação para definir que este pacote é um pacote
VLAN.
tcp, udp, icmp
Abreviações para:
ip proto p or ip6 proto p
onde p é um dos protocolos mencionados anteriormente.
iso proto protocol
Verdadeiro se o pacote for um pacote OSI com tipo de protocolo protocol.
Protocol pode ser um número ou um dos seguintes nomes: clnp, esis ou isis.
clnp, esis, isis
Abreviações para:
iso proto p

onde p é um dos protocolos mencionados anteriormente. Observe que o tcpdump
faz um trabalho incompleto para selecionar estes protocolos.
expr relop expr
Verdadeiro se a relação holds, onde relop é um dos seguintes: >, =,

Negação deve ser precedida. Alternação e concatenação necessitam de
precedência e associam esquerda com direita.
Se um identificador for passado sem uma diretiva, a mais recente diretiva será
assumida.
Por exemplo:
not host vs and ace
será igual à:
not host vs and host ace
mas não pode ser confundido com:
not ( host vs or ace )
Argumentos de expressão podem ser passados ao tcpdump como um simples
argumento, ou como múltiplos argumentos.
Geralmente, se a expressão contiver metacaracteres de SHELL, será mais fácil
passar como um simples argumento entre aspas.
Múltiplos argumentos são concatenados com espaços antes de serem analizados.
EXEMPLOS
Para imprimir todos os pacotes vindos de ou para o departamento sundown
tcpdump host sundown
Para imprimir o tráfego entre helios e hot ou ace:
tcpdump host helios and ( hot or ace )
Para imprimir todos os pacotes IP entre ace e qualquer host exceto helios:
tcpdump ip host ace and not helios
Para imprimir todo tráfego entre hosts locais e hosts em Berkeley:
tcpdump net ucb-ether
Para imprimir todo tráfego ftp para a internet através do gateway snup:
(Observe que a expressão está entre parênteses para prevenir que o shell
interprete o que está entre parênteses)
tcpdump 'gateway snup and (port ftp or ftp-data)'
Para imprimir o tráfego para redes fora da rede local (se você for gateway para
outra rede, esta regra pode não prever isto em sua rede local).
tcpdump ip and not net localnet
Para imprimir pacotes de início e final de conexões (SYN e FIN) TCP envolvendo
hosts não-locais.
tcpdump 'tcp[13] & 3 != 0 and not src and dst net localnet'
Para imprimir pacotes IP maiores do que 576 bytes enviados através do gateway
snup:
tcpdump 'gateway snup and ip[2:2] > 576'

Para imprimir pacotes de broadcast ou multicast IP que não estão sendo
enviados via broadcast ou multicat ethernet
tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'
Para imprimir todos os pacotes ICMP que não sejam echo request/reply
(não sejam ping's)
tcpdump 'icmp[0] != 8 and icmp[0] != 0'
RETIRADO DO SITE
http://www.slacklife.com.br/article.php?sid=872

Introducing tcpdump
packet capture is the real-time collection of data as it travels over a network. For
our purposes, a packet is any message that has been encapsulated in various
headers that uses the IP protocol to communicate. And tcpdump is a tool that
does the capturing. It has a lot of switches and so the command line can become
messy. Because of this I decided to structure the tutorial mostly by example. For
a more systematic approach you can read the man page.
decomposing a sample packet
Let us start off by looking at one such packet as displayed by tcpdump:
1023873914.125606 fulton.ssh > spider.1145: P 3066603742:3066603806(64) ack 1646168027 win 1
4510 0068 7e87 4000 4006 3862 c0a8 011e
c0a8 0128 0016 0479 b6c8 a8de 621e 87db
5018 4470 1813 0000 e492 152f 23c3 8a2b
4ee7 dbf8 0d48 88e8 0110 2b01 4295 39f4
52c9 a05b 31d7 e3ae 1c62 2dbd d955 d604
b5d2 63d1 8fbc 4ab7 1615 b382 571c 70e0
a368 a03f 425b 6211
What we see here does not accurately represent the structure of the packet at
all. The "upper" portion is a summary of what's going on. The "lower" portion
(the rows and columns), though, is the actual stuff on the wire (in "hex"). What I
discovered is that the ethernet frame header (that encapsulates the IP packet) is
not shown here. I determined it to be consistently 14 bytes in length (6 bytes
each for destination and source mac addresses and 2 bytes for the "ethertype").
Here is a breakdown:
• The black stuff is the time the packet came across our network card (not
part of the packet)
• The dark blue stuff is the source & source port and destination &
destination port of the communication taking place.
• The red stuff are TCP flags
• The olive stuff is the byte sequence/range
• The light blue stuff is the window size of bytes that the source (sender) is
currently prepared to receive
• The green stuff is the TCP type of service
Important: packet structure and information is dependent on the nature of the
packet. This example packet involves TCP, SSH, and is part of the middle of the
session. Learn more about TCP and IP by reading RFC793 and RFC791
respectively.
Here is a quick reference for TCP flags:

TCP Flag
Flag in
tcpdump
Flag Meaning
SYN s Syn packet, a session
establishment request. The
first part of any TCP
connection.
ACK ack Ack packet, used to
acknowledge the receipt of
data from the sender. May
appear in conjunction with
other flags.
FIN f Finish flag, used to indicate
the sender's intention to
terminate the connection to
the receiving host.
RESET r Indicates the sender's
intention to immediately
abort the existing connection.
PUSH p Signals the immediate push of
data from the sending host to
the receiving host. For
interactive applications such
as telnet, the main issue is
the quickest response time,
which this "push" flag signals.
URGENT urg Urgent data should take
precedence over other data.
For example, a Ctrl-C to
terminate a FTP download.
Placeholder .
If the connection does not
have a syn, finish, reset, or
push flag set, this placefolder
flag will be found after the
destination port. Note that it
also appears in conjunction
with the ack flag.
Back to our sample packet...
So the first line is "hidden" in the hexadecimal portion of the output. The first
line happens to contain information that resides within the packet headers (here
IP and TCP headers). Of course you already know that a typical IP header is 20
bytes in length and TCP is another 20 bytes right? And you also know that 2
digits in hex is equivalent to one byte right? Sure, so that means that the headers

lie within the first 20 chunks of hex. Here I put the IP header in yellow and the
TCP header in cyan:
4510 0068 7e87 4000 4006 3862 c0a8 011e
c0a8 0128 0016 0479 b6c8 a8de 621e 87db
5018 4470 1813 0000 e492 152f 23c3 8a2b
4ee7 dbf8 0d48 88e8 0110 2b01 4295 39f4
52c9 a05b 31d7 e3ae 1c62 2dbd d955 d604
b5d2 63d1 8fbc 4ab7 1615 b382 571c 70e0
a368 a03f 425b 6211
Let's see, that's 20 chunks for the headers so we have 32 left for data. Well we
see in olive that there are 64 bytes of data so there's the remaining 32 chunks.
Pretty good.
Now we will satisfy ourselves with decoding just a few choice bytes:
The second chunk represents the total length of the thing in bytes. In our head
we calculate that 0068 is 104 in decimal (6x16+8). So, again, we score because
there's our 52 chunks again. Yes!
The second half of chunk number 5 is the protocol we're using to carry the IP
data. Bingo! It shows 6 and that means TCP:
# grep tcp /etc/protocols
tcp 6 TCP # transmission control protocol
The last 2 chunks (4 bytes) of the IP header (chunks 9 & 10) represent the
destination address. Since host spider is known to be using 192.168.1.40 we can
check this out:
c0 = (12 x 16) + (0 x 1) = 192
a8 = (10 x 16) + (8 x 1) = 168
01 = ( 0 x 16) + (1 x 1) = 1
28 = ( 2 x 16) + (8 x 1) = 40
Yep. Looks good.
Finally, let's look in the TCP header and decode the source port. We see in dark
blue that we're in the midst of a SSH session, port 22. Source port is assigned
bytes 1 & 2:
0016 = 22 (perfect)
So that ends our look at the anatomy of a sample packet. Let's move on to the
business of issueing the tcpdump command.
We can run tcpdump by simply typing:
# tcpdump
basic usage

Resulting in:
23:29:04.050167 spider.3224 > 66-28-147-032.servercentral.net.6020: . ack 36517 win 16044
23:29:04.059645 66-28-147-032.servercentral.net.6020 > spider.3224: P 36517:37969(1452) ack
23:29:04.092955 daffy.pmatulis.homeunix.net.netbios-ns > 192.168.1.255.netbios-ns: nbt-query
23:29:04.093587 daffy.pmatulis.homeunix.net.netbios-ns > 192.168.1.255.netbios-ns: nbt-query
23:29:04.093836 mudra.pmatulis.homeunix.net.netbios-ns > daffy.pmatulis.homeunix.net.netbios
23:29:04.095028 mudra.pmatulis.homeunix.net.netbios-ns > daffy.pmatulis.homeunix.net.netbios
23:29:04.097645 daffy.pmatulis.homeunix.net.netbios-ns > 192.168.1.255.netbios-ns: nbt-regis
23:29:04.098410 mudra.pmatulis.homeunix.net.netbios-ns > daffy.pmatulis.homeunix.net.netbios
23:29:04.143267 66-28-147-032.servercentral.net.6020 > spider.3224: P 37969:39421(1452) ack
23:29:04.145122 spider.3224 > 66-28-147-032.servercentral.net.6020: . ack 39421 win 13140
This is a sample of traffic on my network. From this we discover some of
tcpdump's default behaviour. For instance, it attempts to resolve fully qualified
domain names. It also displays a timestamp in a different format from what we
saw in our first sample packet. And most importantly, it does not look past the
headers (hex is nowhere to be seen).
Often, we want to take a sample of traffic and save it somewhere. We accomplish
this in standard Unix fashion:
# tcpdump > textfile
Proceed like this if you want to view the capture as it is being saved:
# tcpdump -l | tee textfile
That's fine but we will now really begin our study of tcpdump. We will do this by
acquainting ourselves with the concept of tracefiles (or dumpfiles). Tracefiles are
binary versions of the traffic samples. They require less processing power (and
space) as no parsing is required to give us legible text files (so, yes, tracefiles are
always created by tcpdump, whether internally or externally). The data is raw
(and quite unintelligible by humans). Here is how to save a tracefile:
# tcpdump -w tracefile &
Presumably we will one day want to use that tracefile so here we go:
# tcpdump -r tracefile
This will produce legible output as if we ran tcpdump with no switches at all. So
remember, the "w" and "r" switches are useless by themselves; each implies the
other.
intermediate usage
Let us proceed to the next level by taming tcpdump; so far he's been quite wild.
There are 4 approaches at our disposal. They involve telling tcpdump:
1. how to behave (program control)
2. what packet information to show

3. what traffic to capture (packet filtering)
4. how to display that packet information (data formatting)
1. controlling tcpdump
The switches we have seen so far (l,w,r) fall in this catagory. Here are a few
more:
# tcpdump -i xl0 -c 100 -s 400
Ok, so that tells tcpdump to listen on the xl0 network interface, capture only the
first 100 packets that come across it, and suck up the first 400 bytes of data from
each packet (which includes the 14 bytes from the ethernet frame). The
corresponding defaults are: the "lowest" interface (example: eth0 and not eth1);
an indefinite number of packets; and 96 bytes.
2. what packet information to show
For the traffic that is captured we have a say in what information is shown. A few
things you can try are to tell tcpdump to be "quiet", "verbose", or "very verbose".
The corresponding switches are "-q", "-v", and "-vv" and, quite frankly, they are
no big deal. The switches that are more interesting are "-e" and "-x". The former
tells tcpdump to display the source and destination mac/ethernet addresses and
the latter tells it to show us the payload of a packet in hexadecimal. This last
switch is one of the more important switches available to us and it is what we
used to display that first packet in the tutorial. Here are some examples:
Let's say we're just interested in the mac addresses:
# tcpdump -qec1
00:57:06.154240 0:a0:4d:3:e0:1d 0:50:be:2b:44:8f 60: spider.4454 > fulton.pmatulis.homeunix.
The two mac addresses you see are the source and destination. So here, spider
has mac address 0:a0:4d:3:e0:1d and fulton has mac address 0:50:be:2b:44:8f. I
used the quiet option to cut down on the clutter and requested a count of only 1
packet.
Let's go further and tell tcpdump to include some data in the capture:
# tcpdump -qec1 -x
01:04:18.762895 0:50:ba:2b:44:8f 0:a0:4b:3:e0:1d 118: fulton.pmatulis.homeunix.net.ssh > spi
4510 0068 ca56 4000 4006 ec92 c0a8 011e
c0a8 0128 0016 1166 fe89 6677 1140 5338
5018 4470 9250 0000 3b6e e13e c39e cebe
6ad5 5a78 8d62 090c 7dcf e1f1 37e0 9f64
1c54 0ef7 8534 1ec9 0240 d02d c8a1 e54b
fa3b
A final and very useful switch for controlling tcpdump is to have the packet
payload converted to ASCII. Normally this is used in conjunction with hex (the

"x" switch) even though, when using this ASCII switch, hex is often displayed
whether demanded or not. To display ASCII we employ the "X" switch:
# tcpdump -qec1xX
On another system this gave me info on some Samba exchanges:
21:04:34.339233 0:c:6e:77:68:8d 0:c0:4f:ac:12:3b 107: bureau.danville.ca.2343 > candyman.dan
0x0000 4500 005d 138d 4000 8006 635e c0a8 013f E..]..@...c^...?
0x0010 c0a8 0120 0927 008b 8fba 2130 aa33 e823 .....'....!0.3.#
0x0020 5018 fe64 030d 0000 0000 0031 ff53 4d42 P..d.......1.SMB
0x0030 2b00 0000 0018 43c0 0000 0000 0000 0000 +.....C.........
0x0040 0000 0000 ffff fffe 0000 feff 0101 000c ................
0x0050 004a .J
3. what traffic to capture
We can capture traffic based on:
1. address
2. protocol
3. port
4. packet characteristics
5. combinations thereof
address filtering
• An address can refer to a host, a network, a multicast/broadcast,
or a mac/ethernet address
• An address can be a source or a destination
So if I am interested in all IP traffic involving host mudra:
# tcpdump host mudra
Let's say I want only traffic where mudra is the destination:
# tcpdump dst host mudra
Obviously, if you use names (instead of IP addresses) name resolution
must be set up.
Below we capture IP traffic involving a source ethernet address of
0:a0:3b:3:e1:1d
# tcpdump ether src host 0:a0:3b:3:e1:1d
Note the syntax: ether host {mac address}
Here we will display the first 100 packets involving network
192.168.1.0 with a netmask of 255.255.255.0 and save everything to a

text file (called net_1.0.txt.dump):
# tcpdump -c 100 -l | tee net_1.0.txt.dump net 192.168.1.0 mask
255.255.255.0
Note that the switches must come first.
protocol filtering
• Five common protocols can be specified by name (also called
keywords):
ip
tcp
udp
icmp
igmp
• The remaining protocols must be specified by number.
So if I want to capture all udp related packets:
# tcpdump udp
If I wanted to do the same but save 300 bytes of data per packet to a
tracefile (called udp1000hits.dump) containing the first 1000 hits on
interface vr0 then:
# tcpdump -c 1000 -i vr0 -s 300 -w udp1000hits.dump udp
Here I am telling tcpdump to capture esp related packets:
# tcpdump proto 50
Note the syntax: proto {protocol number} (see /etc/protocols)
port filtering
For example, I am sniffing around my network for any Telnet activity:
# tcpdump port 23
Note the syntax: port {port number} (see /etc/services)
packet characteristics filtering
Remember in the beginning when we were decoding fields in the
headers of a packet? Well we can filter using the same strategy. Here is

the syntax:
tcpdump "{protocol}[{bypass n bytes}] = {number}"
The available protocols are: ip, tcp, udp, icmp, ether, arp, rarp, and
fddi. What "protocol" refers to is a little murky. If we use "ip" then it
represents the IP header. If we use "icmp" (there is no such thing as an
ICMP header) it represents the payload or data portion of the packet.
An indirect way to capture all icmp traffic is like this:
# tcpdump "ip[9]=1"
This works because the transport protocol is given by the tenth byte of
the IP header. And we know that icmp's protocol number is "1".
Now given that host daffy is currently pinging host spider, the following
command will capture only the echo replies of spider:
# tcpdump -x "icmp[0]=0"
04:20:22.056929 spider > daffy.pmatulis.homeunix.net: icmp: echo reply
4500 0054 c20e 0000 8001 f4db c0a8 0128
c0a8 0146 0000 6354 d87b 0000 3d09 a7a8
000d f46d 0809 0a0b 0c0d 0e0f 1011 1213
1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
3435
Focus your attention on the first 2 digits of chunk 11. That's byte 1 of
the data portion of the packet and it is zero. Well the first byte of an
ICMP message is it's type and by golly type "0" means echo reply.
Let's try that again but this time we'll capture only what we need for
the test (the 14 bytes for the frame header, the first 20 bytes for the IP
header, and 1 byte for the ICMP type). We'll test for echo requests on
the part of daffy this time (echo request is type "8"):
# tcpdump -x -s 35 "icmp[0]=8"
04:56:12.618507 daffy.pmatulis.homeunix.net > spider: [|icmp]
4500 0054 8c8e 0000 ff01 ab5b c0a8 0146
c0a8 0128 08
Pretty good. Exactly as expected.
Something else that's fun is to filter on TCP flags. The key here is to

find where the flags are located in the TCP header. Well, they are found
at byte 14 (we need to bypass 13 bytes). Therefore, we can do the
following if we want to identify all packets containing the RESET flag
(which must necessarily also contains the ACK flag):
# tcpdump -x "tcp[13]=20"
Why? Well first, its actually only the last 6 bits of byte 14 that supply
flag information:
|U|A|P|R|S|F|
|R|C|S|S|Y|I|
|G|K|H|T|N|N|
Therefore ACK and RST gives us a byte of 00010100. I think the first
two bits are always zero (?). Converting binary to decimal (we do not
use hex [which would of been 14 or 0x14]) gives us "20".
Sometimes it may be useful to identify (datagram) fragments. In this
case we filter on fields in the IP header where information regarding
fragmentation is stored. Without elaborating on fragmentation theory,
suffice it to say that if there is no "fragment offset" listed in the IP
header then that packet is either not a fragment or it is the datagram's
very first fragment.
The offset is given by bytes 7 and 8 with the exception of the first 3 bits:
reserved (always zero?), "do not fragment" (DF), and "more fragments
to follow" (MF). Any one datagram will therefore have these two bytes
looking like this:
type bytes 7 and 8
non-fragment 0?00000000000000
first fragment 0010000000000000
intervening
fragment
001xxxxxxxxxxxx
last fragment 000xxxxxxxxxxxx
Where ? may be "1" or "0" and the string of x's contains at least one "1".
So if we can do a bitwise AND operation on those two bytes with the
following binary number then we know our datagram is of the first two
types providing the result is zero:
0001111111111111
So this will sniff non-fragments or "frag zeroes" (initial fragments):

# tcpdump "ip[6:2] & 0001111111111111=0"
Why? Well we bypass 6 bytes and examine the next two (bytes 7 and 8).
We then perform the AND operation and specify a result of zero.
In hexadecimal the expression becomes:
# tcpdump "ip[6:2] & 0x1fff=0"
compound filtering
Compound filtering is where we combine multiple filtering options in
the same tcpdump command. This is very common on real networks. I
can either specify exactly what I want or specify what I don't what. We
do this through the use of three operators:
1. Negation -- (not or !)
2. Concatenation -- (and or &&)
3. Alternation -- (or or ||)
An example: Say I am working with tcpdump remotely by SSH and I
want to take a sample capture of my network traffic and store it in a
tracefile. Now I don't want to contaminate my capture with the remote
session traffic itself so here is what I must do:
# tcpdump -w tracefile not port 22
But wait. This is no good. What if there is SSH activity on my network
to begin with? Hmmm. I will tell tcpdump to forget about SSH activity
between me (spider) and the remote host (fulton):
# tcpdump -w tracefile not port 22 and host spider and host fulton
Good idea but the syntax is all wrong. This is the correct command:
# tcpdump -w tracefile not (port 22 and host spider and host fulton)
We're saying to ignore anything that makes the entire contents of the
parentheses true. This means packets that involve port 22 AND host
spider AND host fulton will be ignored. But still, tcpdump will complain.
The real final command is this:
# tcpdump -w tracefile not "(port 22 and host spider and host fulton)"
One big bonus is that we can specify the filtering expression in a filter file. We
work with such files using the "-F" switch:

# cat > filterfile
dst host spider and "(udp or proto 51)" and not "(src host daffy or src host fulton)"
Ctrl-D
# tcpdump -F filterfile
So we can save compound filters that interest us and capture traffic with ease.
By the way, the above command captures all IP traffic involving host spider as
destination but not involving host daffy nor host fulton as sources. A second
protocol must be either UDP or AH.
4. how to display packet information
The fourth and final approach at taming tcpdump is specifying how our data is to
be displayed. It is important to realize that our filter (or the lack of one)
determines what data is actually captured. After that, we tell tcpdump how to
output that data. We have already looked at how to output certain kinds of data
(subsection 2). In this section, we look at how to format that output.
We can format data output in the following ways:
1. "-a " -- force all name resolution (the default)
2. "-n " -- remove all name resolution
3. "-N " -- remove domain name resolution
4. "-f " -- remove all remote host name resolution
5. "-t " -- remove timestamp
6. "-tt " -- no timestamp formatting (use epoch time)
7. "-ttt " -- format timestamp with day and month
So there's nothing spectacular here. The most we can say is that removing name
resolution can speed things up. Removing timestamps also unclutters the screen
quite well. I leave it up to you, dear reader, to experiment with these formatting
options.
Let me end with two more examples.
Let's say I am working at my desk and I want to keep tabs at what bastards are
bombarding my firewall with junk. I could issue the following command and take
a look from time to time:
# tcpdump -i tun0 -nq \
not "(port 22 and host spider)" \
and not "(port 53 or 80 or 110 or 119 or 443)" \
and dst host 216.209.50.188
on my system the interface is 'tun0'
so as not to have my ssh session interfer
so as not to show valid packets
if this is the IP currently assigned to t
What if I am interested in what my firewall is actually sending out onto the
internet? I can remove some known good outgoing traffic and observe the rest
(which ideally should not exist):
# tcpdump -i tun0 -nq \
and not port '(20 or 21 or 25 or 53 or 80 or 110 or 119 or 123 or 443)' \
and not icmp \

and src host 216.209.50.188
I became alarmed when I was seeing outgoing traffic to Microsoft ports 135 and
445. After some frantic research I discovered that I was indeed sending
responses back to internet hosts but it was due to the way my OpenBSD firewall
was set up. It was resetting connections instead of allowing them to time out.

OPENVPN TUTORIAL
Server (PC1) Configuration:
urpmi openvpn
cd /etc/openvpn/
cp -r /usr/share/openvpn/easy-rsa/ /etc/openvpn/
in case of self build rpm, replace the last command from above by:
cp -r /usr/share/doc/openvpn-2.x.x/easy-rsa/ /etc/openvpn/
Then:
cp /usr/share/openvpn/sample-config-files/server.conf /etc/openvpn/
or, in case of self build rpm, replace the last command from above by:
cp /usr/share/doc/openvpn-2.x.x/sample-config-files/server.conf /etc/openvpn/
cd /etc/openvpn/easy-rsa
or, if openvpn version is >= 2.1.x:
cd /etc/openvpn/easy-rsa/1.0/
Now edit the /etc/openvpn/easy-rsa/vars file and set the KEY_COUNTRY,
KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Don't leave any
of these parameters blank.
Next, initialize the PKI:
source vars
./clean-all
./build-ca
Each time you need to create new keys using easy-rsa, launch the source vars
command first.
The ./clean-all command is to be used only the first time, because it deletes
the ca and all keys.
Answer to the interactive questions when building the CA and answer yes when
prompted to auto sign the certificate.
The above command creates a certificate of authority: /etc/openvpn/easyrsa/keys/ca.crt
and /etc/openvpn/easy-rsa/keys/ca.key.
Then, create a /keys/server.key:
./build-key-server $SERVER
replace $SERVER with the name you want to give to the server certificate.
the command could be:
./build-key-server server

create a client key (for PC2):
./build-key client1 ( or any name other than "client1" )
And create a client key to revoke ( for revocation list ):
./build-key revokekey ( or any name other than "revokekey" )
and run :
./revoke-full revokekey
This builds a /etc/openvpn/easy-rsa/keys/crl.pem file.
ln keys/crl.pem /etc/openvpn/
Beware, create a hardlink as shown above (ln without the -s option).
OpenVPN needs to have the crl.pem file in a world readable directory because
OpenVPN executes as nobody:nogroup once launched , and it checks this file on
each client connection . You do not wish to set /etc/openvpn/easy-rsa/keys/ world
readable.
Build the Diffie-Hellman parameters for the server side:
./build-dh
Then edit the server configuration file and modify the following elements in
/etc/openvpn/server.conf this way:
(before change -->> after change)
ca ca.crt -->> ca /etc/openvpn/easy-rsa/keys/ca.crt
cert server.crt -->> cert /etc/openvpn/easy-rsa/keys/server.crt
key server.key -->> key /etc/openvpn/easy-rsa/keys/server.key
dh dhxxx.pem -->> dh /etc/openvpn/easy-rsa/keys/dhxxx.pem
Replace the above /etc/openvpn/easy-rsa by the correct path (i.e
/etc/openvpn/easy-rsa/1.0/ for openvpn >= 2.0).
Add the following lines:
# CRL (certificate revocation list) verification
crl-verify /etc/openvpn/crl.pem
And continue with these changes:
;user nobody -->> user nobody
;group nobody -->> group nogroup
Don't forget to delete the : and to change nobody to nogroupin the lines just
above.
Save the file.

Now, you may desire to configure the server to push the routes of your lan to the
client. If you have the following configuration:
_________
| OpenVPN |
WAN(IP=81.82.83.84)---| Server |---LAN(192.168.0.X/255.255.255.0)
|_________|
you will configure /etc/openvpn/server.conf as follows:
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.0.0 255.255.255.0"
If you wish to redirect the gateway threw the vpn uncomment the following line:
push "redirect-gateway"
and you may also wish to push DNS and WINS servers:
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option WINS 10.8.0.1"
Also, the clients will by default only see the server. If you wish the clients to see
each other, uncomment the following line:
client-to-client
Select a cryptographic cipher:
Last but not least, default encryption is cipher BF-CBC (Blowfish 128 bits)
If you wish to use another cryptographic cipher, or more then 128 bits, read the
following. Otherwize if the default is OK for you, go to the next section :
Configure Shorewall, or to the Client (PC2) Configuration, or back to the Table of
contents.
In the following section of /etc/openvpn/server.conf:
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC # Blowfish (default)
;cipher AES-128-CBC # AES
;cipher DES-EDE3-CBC # Triple-DES

Leaving everything commented (as is), is identical as uncommenting the
following line:
cipher BF-CBC
# Blowfish (default)
The result is the same.
But you may wish to use another type of encryption such as this one:
cipher AES-256-CBC
With the above line, you will the have 256-bit version of AES (Advanced
Encryption Standard).
When using another encryption type then the default cipher BF-CBC, you will
need to set the same on the client side.
To obtain a list of the different types of encryption supported by openvpn, type
the following command:
openvpn --show-ciphers
The displayed result will look like this:
The following ciphers and cipher modes are available
for use with OpenVPN. Each cipher shown below may be
used as a parameter to the --cipher option. The default
key size is shown as well as whether or not it can be
changed with the --keysize directive. Using a CBC mode
is recommended.
DES-CBC 64 bit default key (fixed)
IDEA-CBC 128 bit default key (fixed)
RC2-CBC 128 bit default key (variable)
DES-EDE-CBC 128 bit default key (fixed)
DES-EDE3-CBC 192 bit default key (fixed)
DESX-CBC 192 bit default key (fixed)
BF-CBC 128 bit default key (variable)
RC2-40-CBC 40 bit default key (variable)
CAST5-CBC 128 bit default key (variable)
RC5-CBC 128 bit default key (variable)
RC2-64-CBC 64 bit default key (variable)
AES-128-CBC 128 bit default key (fixed)
AES-192-CBC 192 bit default key (fixed)
AES-256-CBC 256 bit default key (fixed)
if you want to change the default keysize chose a cipher mode with variable key
size from the list above, and do as the following example in
/etc/openvpn.server.conf:
cipher BF-CBC
keysize 512
But don't forget to set the same in the client configuration file.

Now, start the server:
service openvpn start
Run : ifconfig
You can see a new interface tun0 : this is the vpn interface
Note on pkcs#11: (you can skip this part if not interested and go to the next
part: Configure Shorewall, or go back to the Table of contents).
With the Beta 2.1 of OpenVPN and on a cooker or Mandriva 2007 you can
generate pkcs11 certificates.
2006 can work with these certitficates, but not generate them.
To generate pkcs#11 certificates on a cooker or Mandriva 2007 use one of the
apropriate openvpn-2.1 rpms here:
RPMs
And then do as follows:
urpmi opensc engine_pkcs11 openct openvpn-2.1_beta14-1.i586.rpm
service openct start
Then :
cp -r /usr/share/doc/openvpn-2.1_beta14/easy-rsa/ /etc/openvpn/
cd /etc/openvpn/easy-rsa/2.0/
In /etc/openvpn/easy-rsa/2.0/ edit openssl.cnf and modify this section:
[ engine_section ]
#
# If you are using PKCS#11
# Install engine_pkcs11 of opensc (www.opensc.org)
# And uncomment the following
# verify that dynamic_path points to the correct location
#
#pkcs11 = pkcs11_section
[ pkcs11_section ]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
MODULE_PATH = $ENV::PKCS11_MODULE_PATH
PIN = $ENV::PKCS11_PIN
init = 0
to make it like this:
[ engine_section ]
#
# If you are using PKCS#11
# Install engine_pkcs11 of opensc (www.opensc.org)
# And uncomment the following
# verify that dynamic_path points to the correct location
#
pkcs11 = pkcs11_section

[ pkcs11_section ]
engine_id = pkcs11
#dynamic_path = /usr/lib/engines/engine_pkcs11.so
dynamic_path = /usr/lib/openssl/engines/engine_pkcs11.so
#MODULE_PATH = $ENV::PKCS11_MODULE_PATH
MODULE_PATH = /usr/lib/opensc-pkcs11.so
#PIN = $ENV::PKCS11_PIN
init = 0
Do not forget to comment out pkcs11 = pkcs11_section as shown above.
Now, do as with the normal pki (as described previously), but from
/etc/openvpn/easy-rsa/2.0/ instead of /etc/openvpn/easy-rsa/ or
/etc/openvpn/easy-rsa/1.0/.
If you wish to create a certificate directly in a usb token, use the --pkcs11 option
to the easy-rsa scripts.
But I'd recommend to build certificates localy, and to place the keys in the usb
token manualy.
To do so, do as follows:
Initialise the usb token if it has not been done:
pkcs15-init --erase-card -T
pkcs15-init --create-pkcs15 -T
pkcs15-init --store-pin --auth-id 0 --label "YourLabelToTheKey"
To store a CA do as follows:
pkcs15-init --store-certificate keys/ca.crt --authority --label "Mandriva CA" --id
"D1:FB:AF:27:EB:B7:34:99:52:20:D2:33:19:C0:E8:69:51:7A:ED:B6" --auth-id 0
In the above example, I decided to use the key's fingerprint as an id, but you can
use omit this and automatic default id's will be set (i.e. id "46" is a standard).
The --auth-id 0 is compulsary parameter.
How did I previously read the id of my CA? Well with this command:
openssl x509 -noout -text -in keys/ca.crt | less
Do the same the read the other certificates ids.
To store a public key do as follows:
pkcs15-init --store-certificate keys/client1.crt --label "Client1" --id
"DC:EF:ED:19:74:73:DA:44:B6:A4:EE:F5:8B:1F:C5:43:33:2D:1F:A0" --auth-id 0
To store a private key, first store the public key as explained above, and then
store the private key as follows:
pkcs15-init --store-private-key keys/client1.key --public-key-label "Client1" --
label "Client1 Private Key" --id
"DC:EF:ED:19:74:73:DA:44:B6:A4:EE:F5:8B:1F:C5:43:33:2D:1F:A0" --auth-id 0

Important : the --id has to be the exact same as the one you used to store the
client1.crt
(here:DC:EF:ED:19:74:73:DA:44:B6:A4:EE:F5:8B:1F:C5:43:33:2D:1F:A0)
Now, to access the key with openvpn you can use the following commands:
openvpn --show-pkcs11-slots /usr/lib/opensc-pkcs11.so
openvpn --show-pkcs11-objects /usr/lib/opensc-pkcs11.so 0
Note this part of the output (example from my test key):
You can access this token using
--pkcs11-slot-type "label" --pkcs11-slot "OpenSC Card (PKyves)" options.
And note also the subject for the client1 keyring. which in my example is:
Object
Type:
Certificate
CKA_ID:
dc ef ed 19 74 73 da 44 b6 a4 ee f5 8b 1f c5 43
33 2d 1f a0
CKA_LABEL:
Client1
subject:
/C=FR/ST=Ile-de-
France/L=Paris/O=Mandriva/CN=client1/emailAddress=ybourhis@mandriva.com
serialNumber: 03
notBefore:
060621144856Z
after having noted these down, I will modifie the client's configuratin file
(/etc/openvpn.client.conf) by removing the cert and key lines, and I'll replace
them with what follows:
pkcs11-providers /usr/lib/opensc-pkcs11.so
pkcs11-slot-type "label"
pkcs11-slot "OpenSC Card (PKyves)"
pkcs11-id-type subject
pkcs11-id "/C=FR/ST=Ile-de-
France/L=Paris/O=Mandriva/CN=client1/emailAddress=ybourhis@mandriva.com"
Now, each time the client is started, the PIN key will be asked before connection.
Next, Configure Shorewall or go back to the Table of contents
Client (PC2) Configuration:
urpmi openvpn
cd /etc/openvpn/
cp -r /usr/share/openvpn/sample-config-files/client.conf /etc/openvpn/
in case of self build rpm, replace the last command from above by:
cp -r /usr/share/doc/openvpn-2.x.x/sample-config-files/client.conf /etc/openvpn/

You will need some PKI Certificates from the server.
Go back to PC1(server) and type:
scp /etc/openvpn/easy-rsa/keys/ca.crt user@ip:/etc/openvpn/
scp /etc/openvpn/easy-rsa/keys/client1.crt root@PC2ip:/etc/openvpn/
scp /etc/openvpn/easy-rsa/keys/client1.key root@PC2ip:/etc/openvpn/
Where PC2ip is the client's IP.
Then, Go back to PC2
On PC2 (client), edit the client's /etc/openvpn/client.conf configuration file
and bring the following changes:
(before change -->> after change)
remote server -->> remote "server ip" port ( ex: remote 192.168.1.100
1194 )
The default port is 1194
:user nobody -->> user nobody
:group nobody -->> group nogroup
ca ca.crt -->> ca /etc/openvpn/ca.crt
cert client1.crt -->> cert /etc/openvpn/client1.crt
key client1.key -->> key /etc/openvpn/client1.key
:ns-cert-type server -->> ns-cert-type server
save it !
Also, if you do not use the default cipher BF-CBC Blowfish 128 bits encryption,
add the same as on the server side.
i.e.:
cipher AES-256-CBC
or like this:
cipher BF-CBC
keysize 512
Now, start the client:
Service openvpn start
Run : ifconfig
You can see a new interface tun0 : this is the vpn interface
Next, Configure Shorewall or go back to the Table of contents
Shorewall Configuration:
If you have shorewall installed and running, you need to allow connections to the

vpn.
References : Official Shorewall Open VPN Howto
First, declare the VPN zone in /etc/shorewall/zones as follows if you have
shorewall 2.x.x:
#ZONE DISPLAY COMMENTS
vpn VPN Remote subnet
Or as follows in /etc/shorewall/zones if you have shorewall 3.x.x:
#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
vpn ipv4
In /etc/shorewall/interfaces add the tun0 interface:
#ZONE INTERFACE BROADCAST OPTIONS
vpn tun0
and define the following in /etc/shorewall/tunnels :
# TYPE ZONE GATEWAY GATEWAY
# ZONE
generic:udp:1194 net 0.0.0.0/0 vpn
You can also do the following:
# TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpn net 0.0.0.0/0 vpn
But I prefer the generic:udp:1194 syntax because as you can see in
/etc/openvpn/server.conf or /etc/openvpn/client.conf, you can easily define
any port and protocol (udp or tcp).
With the generic:udp:1194 syntax you easily reflect the server configuration.
the openvpn syntax is only for the standard openvpn protocol on udp port 1194.
Now edit /etc/shorewall/policy and add policies as follows:
#SOURCE DEST POLICY LOG LEVEL
loc vpn ACCEPT
vpn loc ACCEPT
Where loc is the interface to the local network.
If you configure shorewall on a "Standalone" Client, you would rather do the
following:
#SOURCE DEST POLICY LOG LEVEL
fw vpn ACCEPT
vpn fw ACCEPT

Also, on the server side, the clients on the LAN will receive traffic on the
LAN(i.e. 192.168.0.0/255.255.255.0) from the VPN(i.e. 10.8.0.0/255.255.255.0).
But, there is no way the LAN clients will guess how to reply to
10.8.0.0/255.255.255.0 unless they have the route to this network.
You have 3 solutions :
Reconfigure the DHCP server of your LAN to add routes to the
10.8.0.0/255.255.255.0 zone, but that's not trivial.
Use a Bridged server, to do so, OpenVPN also needs to be reconfigured, as
described in this howto : Open-VPN Ethernet Bridging HowTo.
Or the most simple way is to NAT the VPN zone to your LAN from the server. To
do so, edit /etc/shorewall/masq (on the OpenVPN server) as follows:
#INTERFACE SUBNET ADDRESS PROTO PORT(S) IPSEC
eth0 10.8.0.0/24
This above example is supposing eth0 is on your LAN.
Now, restart Shorewall :
service shorewall restart
Back to the Table of contents
PAM Authentication with Open VPN
References : Using alternative authentication methods with Open VPN
You may which to add PAM authentication to Open VPN.
To do so, add the following in /etc/openvpn/server.conf :
# tell the OpenVPN server to validate the username/password
# entered by clients using the login PAM module
plugin /usr/lib/openvpn/openvpn-auth-pam.so /etc/pam.d/login
Create the users and give each one a password:
useradd client1 -M -s /bin/false
passwd client1
Changing password for user client1.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
The -M option of useradd is to create no /home/client1 directory. The -s
/bin/false is to give no shell to the user on the server for security reasons
because we only want to have PAM checking the login and password, and that is
all.
Restart the server:

service openvpn restart
Then, the client must also prompt for the user login and password. To do so, add
the following in /etc/openvpn/client.conf :
# This will direct the OpenVPN client to query the user for a username/password,
# passing it on to the server over the secure TLS channel:
auth-user-pass
Restart the Client:
service openvpn restart
Type your login and password when prompted to do so.
Each time you start the client, you will be prompted for a login and password. So
you may wish to launch it manually instead of at boot time.
To see if it is launched at boot type the following :
chkconfig --list openvpn
If you see this :
openvpn 0:off 1:off 2:on 3:on 4:on 5:on 6:off
run :
chkconfig openvpn off
If you see this:
openvpn 0:off 1:off 2:off 3:off 4:off 5:off 6:off
You have nothing to do.
To then launch the client run:
service openvpn start
and stop it with:
service openvpn stop
ALSO, you may have multiple clients, in which case you will want to launch only
specific ones manually and the others at boot time.
To do so, run :
chkconfig openvpn on
And change the .conf extension to something else such as .config.
OpenVPN's init script only launches whatever ends by .conf and which is in
/etc/openvpn.
To manually launch a client you will need to type this kind of command:
openvpn --daemon --config /etc/openvpn/clientconf.config

Where /etc/openvpn/clientconf.config is the name you gave to the client file but it
can be something else.
To stop the client, list on which PID it is runing:
ps ax
25305 ? S

where $USER is your username on the machine), create a file (i.e. call it
rpmsetup)and paste this script in it : RPM Setup Script (for i586 arch).
Make it executable:
chmod a+x rpmsetup
And launch it:
./rpmsetup
Then, download the OpenVPN tarball and the GnuPG signaturehere :
http://openvpn.net/download.html
Import James Yonan's (OpenVPN Author) signature:
gpg --recv-keys 1FBF51F3
Verify the package:
gpg --verify openvpn-2.1_beta14.tar.gz.asc
(replace openvpn-2.1_beta14.tar.gz.asc by the version you are testing)
extract the tarball:
tar -xvzf openvpn-2.1_beta14.tar.gz
modify the openvpn-2.1_beta14/openvpn.spec file and when you see:
%if "%{_vendor}" == "MandrakeSoft"
%{!?without_lzo:BuildRequires: liblzo1-devel >= 1.07}
%{!?without_lzo:Requires: liblzo1 >= 1.07}
%else
%{!?without_lzo:BuildRequires: lzo-devel >= 1.07}
%{!?without_lzo:Requires: lzo >= 1.07}
add requires for the Mandriva distribution this way:
%if "%{_vendor}" == "MandakeSoft"
%{!?without_lzo:BuildRequires: liblzo1-devel >= 1.07}
%{!?without_lzo:Requires: liblzo1 >= 1.07}
%else
%if "%{_vendor}" == "Mandriva"
%{!?without_lzo:BuildRequires: liblzo2_2-devel >= 2.01}
%{!?without_lzo:Requires: liblzo2_2 >= 2.01}
%else
%{!?without_lzo:BuildRequires: lzo-devel >= 1.07}
%{!?without_lzo:Requires: lzo >= 1.07}
create a new tarball with the modifications:
mv openvpn-2.1_beta14.tar.gz openvpn-2.1_beta14.tar.gz.orig
tar -cvzf openvpn-2.1_beta14.tar.gz openvpn-2.1_beta14
and finally build your rpm (as a user):
rpmbuild -tb openvpn-2.1_beta14.tar.gz

Eventually install (as root) the missing dependencies and relaunch (as a user) the
rpmbuild.
You will find your new rpm in /home/$USER/rpm/RPMS/i586/ (i.e. openvpn-
2.1_beta14-1.i586.rpm) and now you just need to distribute it to the other
machines for testing.

NOTAS DE AULAS
CRIPTOGRAFIA
Existem diversos campos a serem estudados para garantir a segurança de uma
rede.
O ítem abordado no momento trata da confidencialidade da informação,
abordando o tema da criptografia..
A Criptografia também conhecido como CIFRAGEM converte dados legíveis em
algo sem sentido, com a capacidade de recuperar os dados originais
(DECIFRAGEM) a partir des dados sem sentido.
A criptografia tem, fundamentalmente, quatro objetivos básicos:
a)confidencialidade da mensagem: só o destinatário autorizado deve ser capaz de
extrair o conteúdo da mensagem da sua forma encriptada. Além disso, a
obtenção de informações sobre o conteúdo da mensagem (como uma distribuição
estatística de certos caracteres) não deve ser possível, uma vez que, se o for, se
torna mais fácil à análise criptográfica;
b)integridade da mensagem: o destinatário deverá ser capaz de determinar se a
mensagem foi alterada durante a transmissão;
c)autenticação do remetente: o destinatário deverá ser capaz de identificar o
remetente e verificar que foi mesmo ele quem enviou a mensagem;
d)não-repúdio do remetente: não deverá ser possível ao remetente negar o envio
da mensagem.
Proporciona confidencialidade (garantir que apenas quem autorizado pode ler os
dados) e a autenticação/integridade (garantir que os dados têm a origem
correcta e que não foram alterados entre origem e destino).
Não existem mecanismos de cifragem/decifragem 100% eficazes, numa
abordagem puramente teórica é imediato que qualquer chave pode ser quebrada
pela força bruta (supondo que dispõe de um exemplar de uma mesma mensagem
original e cifrada, e o algoritmo é conhecido, basta tentar com todas as chaves
possíveis até acertar).
A solução é entrar no dominio prático e atender às capacidades do equipamento
de processamento actual de modo a usar algoritmos e chaves que não possam
ser descobertas em tempo útil. O tempo necessário para quebrar uma chave pela
"força bruta" depende do número de chaves possiveis (número de bits da chave)
e do tempo de execução do algoritmo.
Por exemplo:

abcdefghijklmnopqrstuvxz
Foi muito bom conhecer o professor de matematica.
gpj nvjup cpn dpmifdfs p qspgfttps ef nbufnbujdb.
A mensagem original é modificado utilizando um algoritmo que é aplicado sobre
esta mensagem.
Alguns jargões:
* algoritmo - Conjunto de passos para atingir um objetivo.
* crifagem (criptografar, codificar, encriptar) - Converte qualquer informações
sigilosas em algo sem sentido
* decifragem (decodificar, desencriptar, decriptografar) - Caminho contrário
* chave de criptografia - informação que modifica o comportamento de um
algoritmo
* texto claro - Arquivo que observado a olho nu, faz algum sentido
* texto cifrado - Arquivo que observado a olho nu, não faz qualquer sentido. Um
algoritmo utiliza uma chave transformar um texto simples em um texto cifrado.
* Algoritmo forte - Algoritmos que suportam um ataque o maior tempo possível.
Quando o algoritmo for quebrado, a informação já não tem tanto valor.
* Invasor - Alguém do qual voce quer proteger suas informações
* Criptoanalista- Estudo sobre a quebra de sistemas criptográficos, isto é,
procura fraquesas dos algoritmos
* Criptógrafo - Desenvolve sistemas de criptografia.
CHAVE DE CRIPTOGRAFIA (CHAVE DE SESSÃO).
Um algoritmo sempre produz o mesmo resultado. Uma vez descoberto o
algortimo, o segredo também está descoberto. Desta forma é necessário que o
algoritmo seja mantido em sigilo. Sabemos que é difícil manter em segredo um
algoritmo. Mesmo que não seja divulgado este algoritmo, muitos Hackers de
Plantão podem utilizar a engenharia reversa (analisa o codigo executável) para
obter o fonte) para obter este algoritmo.
O algoritmo utilizado no exemplo acima é substitui uma letra por outra. Neste
caso, a letra que foi substituida corresponde a letra seguinte.
O algortimo é relativamente simples. Se alguem descobrir o funcionamento do
algoritmo, então poderá decifrar qualquer texto que foi criptografado com este
algoritmo.
Por mais tentemos manter o algoritmo sob sigilo, alguém pode utilizar a
engenharia reversa a partir de um código executável para montar o algoritmo. É
muito dificil manter o sigilo de um algoritmo, por isso normalmente o algoritimo
é público e o tempo de vida de um algoritmo depende do tamanho de sua chave.

Podemos melhorar o algoritmo. Em vez de simplesmente substituir o caracter
por um adiante, podemos colocar um parametro (um valor númerico de tre
digitos) para o algoritmo para que o resultado da substituição seja diferente
dependendo do parametro passado.
Por exemplo.
Se passarmos o valor 1 para o algoritmo, o caracter atual ser substituido por um
adiante (a por b, b por c e assim sucessivamente). Se passarmos o valor dois
então o caracter atual será substituido por dois caracteres adiante. (a por c, b
por d, c por e e assim sucessivamente). Desta forma, o mesmo algoritmo nunca
produzirá a mesma saída partindo de uma mesma entrada com diferentes
parametros passados.
abcdefghijklmnopqrstuvxz
Foi muito bom conhecer o professor de matematica.
gpj nvjup cpn dpmifdfs p qspgfttps ef nbufnbujdb. (com o parametro 1).
hqk oxkvq dqm eqnjgegt q rtqhguuqt fg ocvgocvkec. (com o parametro 2).
O algoritmo funciona da mesma forma porém produz diferentes resultados
conforme o parametros passado.
Este parametro é conhecido como chave de criptografia para o algortimo cripto
(nome de batismo inventado por mim).
Logicamente se descobrirem como funciona o algoritmo é fácil descobrir a
chave. Basta fazer um loop de 1 ate 999 e ir executando o algoritmo com cada
valor.
Ou ainda podemos utilizar valores aleatorios entre 1 e 999 para tentar descobrir
o valor da chave. Com certeza vamos acabar descobrindo a chave.
Esta forma de descobrir a chave é chamado de força bruta. Você vai testando
todas as chaves possíveis até descobrir a verdadeira.
Se o algoritmo utilizar chaves de tamanho pequeno como no nosso caso (10 bits)
é fácil gerar todas as combinações possíveis e testar cada chave dentro de um
período de tempo razoável. Este processo é relativamente rápido se for no nosso
caso.
A força de um algortimo está no tamanho de sua chave.
Algoritmos que utilizam chaves grandes podem dificultar a geração de uma
chave dentro de um período de tempo razoável.
Uma chave com 128 bits podem gerar
340282366920938463463374607431768211456 chaves.
uma chave com 256 bits podem gerar

11579208923731619542357098500868790785326998466564056403945758400
7913129639936 chaves.
A medida que o tamanho da chave aumenta, o número de chaves geradas
também aumentam, dificultando ainda mais a geração das chaves.
Além do método de força bruta, existem outras variantes, como por exemplo um
dicionário.
Normalmente os algoritmos são publicos.
Uma vez que o texto foi cifrado com uma chave, é necessário utilizar a mesma
chave para obter o texto original. Este método de cifragem é conhecido como
cifragem com chave simétrica. Se a chave for perdida, não será mais possível
obter o texto original, a não ser que seja utiliza o metodo de força bruta ou outro
método.
Utilizamos a cifragem para enviar mensagem entre dois pontos para evitar que a
informação seja interceptada.
Assim, é necessário que o emissor e o receptor conheçam a chave de cifragem,
Este conhecimento pode ser realizado através de um encontrol formal ou através
de um telefonema, ou até mesmo através de uma correspondencia. O problema
existirá se alguem ouvir ou interceptar esta mensagem.
GERENCIAMENTO DA CHAVE DE SESSÃO.
A chave utilizada para cifrar a informação é chamado de chave de sessão.
Uma vez descoberto esta chave, a confidencialidade está comprometida.
Para proteger esta chave podemos utilizar o conceito de Chave de criptografia da
chave (KEK).
A ídéia básica é utilizar uma outra chave para cifrar a chave de sessão. O usuário
informa uma chave e utiliza um gerador de chave aleatória (PRNG). Este dois são
mesclados por um procedimento que irá gerar uma chave. Esta chave será
utilizado para cifrar a chave de sessão. Após a cifragem, a chave pode ser
descartada. O que deve ser mantido é a chave original e o numero gerado pelo
PRNG. A partir destes dois elementos podemos gerar a chave que foi utilizar
para cifrar a chave original.
Podemos utilizar também outros meios, como token e outros meios de
armazenamento.
Quando dois elementos necessitam conhecer a chave de cifragem, basta
comunicar através de email, telefone ou pessoalmente. O problema aumenta
quando o número de pessoas envolvidas no processo aumentam rapidamente, e
também quando a chave possui uma validade por um curto período de tempo.
Quando for necessário alterar ou informar a chave a todos, podemos convocar
todos para um grande churrasco e aproveitar o momento para confraternização.

TIPOS DE CIFRAGEM.
Cifragem por Bloco.(Ver texto abaixo)
Cifragem por Fluxo.(Ver texto abaixo)
Variantes da cifragem de Bloco.
ECB - Eletronic Code Book
CBC - CIPHER-BLOCK CHAINING
PCBC - PROPAGATING CIPHER-BLOCK CHAINING.
Qual é melhor ?
Não existe o termo melhor.
- A implementação do algoritmo de cifragem por fluxo é mais simples (30 linhas
de código) do que a cifragem de blocos (centenas de linhas de código).
- A cifragem por fluxo é mais rápida que a cifragem de blocos.
- A cifragem de blocos permite a reutilização de chaves, a cifragem de fluxo não
permite (?????).
- Padronização. Todo mundo utiliza dois algoritmos DES e AES
Algoritmos de chave Simétrica.
DES - Data Encription Standard
- Desenvolvido pela IBM em Maio de 1973 sob no nome de Lucifer e depois
padronizado sob no nome de DES.
- Utiliza chave de 56 bits em blocos de 64 bits.
- Objetivo é dificultar a obtencao da chave de cifragem embora o algoritmos seja
publico.
- Evolucao: 3DES e DESX
- Outros algortimos RC2 e RC4 (ambos da RSA)
- Cifragem por bloco
IDEA - International Data Encription Algoritm
- Desenvolvido Zurique (Suiça) em 1990
- Possui chave de 128 bits.
RC2 -
- Desenvolvido por Ronald Rivest
- Mantido em segredo pela RSA.
- Em 1996 foi revelado por uma mensagem anonima na USENET
- Utiliza chave de 1 a 2048 bits
RC4
- Inventado em 1987 pelas RSA.
- Algoritmo de cifragem de fluxo
- O algoritmo nunca foi divulgado

- Já foi quebrado
- É muito utilizado hoje em dia
- Faz parte do protocolo SSL.
RC5
- Inventado em 1994 pelA RSA.
- Permite que o tamanho da chave, o tamanho do bloco de dados e o número de
vezes que a criptografia será realizada seja definida pelo usuário.
BLOWFISH
- Algoritmo de criptografia em bloco, rápido, compacto e simples
- Permite criptografia com chave variável de até 448 bits
- Dominio publico.
AES
- Enfraquecimento do DES provocou a chamada mundial para busca de um novo
algoritmo de cifragem
- Novo algoritmo deve ter:
. cifrador de chave simétrica mais rapido e mais forte que o 3DES
. utilizar chaves de 128, 192 e 256 bits
. ser de dominio publico
. possuir vida útil de 20 a 30 anos.
- Em 1999 ficaram 5 algoritmos: MARS, RC6, Rijndel, Serpente e Twofish.
- Em 2000 Rijndel foi declarado novo padrão de criptografia.
- Cifragem por bloco
Algoritmos de chave Assimétrica.
Na criptografia assimétrica, as chaves são pares de uma combinação de ?chave
privada? e ?chaves públicas?. A parte pública da chave pode ser distribuída de
uma forma realmente pública, sem comprometer a parte privada, que deve ser
mantida em segredo pelo seu proprietário. Uma encriptação feita com uma chave
pública pode somente ser desfeita através da chave privada correspondente.
O algoritmo de cifragem por chave publico/privada, utiliza relação matemática
entre dois números primos.
Apesar da forte seguranca que existe neste algoritmo, o problema é a troca de
chave entre os computadores que desejam utilizar este algoritmo.
Se alguem interceptar a comunicacao durante a troca de chave então toda
seguranca estaria comprometida.
Algumas solucões foram apresentadas para o problema de troca de chave. Foram
desenvolvidos algoritmos assimétricos, que recebem este nome por utilizarem
duas chaves distintas: uma para cifragem e outra para decifragem.
- Utilizam chaves distintas para cifragem (A) e decifragem (B)
- Mensagens cifradas com uma chave A, só podem ser decifrados com um chave
(B)

- A descoberta de uma chave deve ser inviável mesmo conhecendo a outra
- Por padrão, após a geraçao das duas chaves, uma é chamada de publica e outra
de privada
- A chave pública é distribuida para todos que desejam enviar uma mensagem
segura para o proprietario gerador da chave.
- Após a cifragem do texto, este somente pode ser decifrado com a respectiva
chave privada.
- A chave privada é guardada com a maior segurança possível e nunca é
distribuída a ninguem.
- A chave publica é derivada da chave privada.
- A chave publica é distribuida a todos que querem enviar uma mensagem para o
proprietário da chave.
- A chave privada é mantida sob sigilo
- O algoritmo mais utilizado é o RSA.
Considerando que o usuário A necessita enviar uma mensagem para B utilizando
o algoritmo de chave publica/privado. Neste caso, A possui o seu par de chaves e
B possui outro para de chaves. O usuário A deve possuir a chave publica de B e
este deve possuir a chave publica de A.
O usuário utiliza a chave publica de B para cifrar a mensagem a ser enviada.
Quando o usuário B receber a mensagem, deve utilizar a sua chave privada para
decifrar a mensagem. Caso queira enviar uma resposta para o remetente, deverá
utilizar a chave publica de A para cifrar a mensagem, e este deverá utilizar a sua
chave privada para decifrar a resposta.
Se alguem conseguir obter a chave privada de alguma das partes, todo processo
de comunicação estará comprometido.
ALGORITMOS DE CHAVE ASSIMÉTRICA:
Diffie-Hellman
- Não né um algoritmo de criptografia
- Sistema para troca de chaves entre duas partes
ElGamal
- É um sistema criptográfico baseado no protocolo de troca de chaves de Diffie-
Hellman
- Utilizado para cifrar mensagens e servir de base para assinatura digital
DSS - Digital Signature Standard - Padrão de Assinatura Digital
- Desenvolvido pela NSA (Agencia nacional de segurança)
- Baseado no algoritmo DSA (Digital Signature Algorithm)
- Permite a utilização de qualquer tamanho de chave
RSA (Ronv Rivest, Adi Shamir, Leonard Adleman) .
- O mais popular algoritmo de criptografia com chave simétrica

- O mais fácil de implementar e compreender
- Utiliza criptografia em bloco
- Necessário alto poder computacional para quebrar a chave
- Nunca foi aprovado e nem reprovado pelos criptologistas
- Quando implementado em Hardware ele é 1000 vezes mais lento que o DES
- Em software o DES é 100 vezes mais rápido que ele
- Chave de qualquer tamanho dependendo da implementação.
Assim, as principais vantagens da criptografia simétrica são:
a)velocidade, pois os algoritmos são muito rápidos, permitindo cifrar uma grande
quantidade de dados em pouco tempo;
b)as chaves são relativamente pequenas e relativamente simples, permitindo
gerar cifradores extremamente robustos;
c)atinge aos objetivos de confidencialidade e de privacidade, mantendo os dados
seguros.
Enquanto desvantagens, pode-se citar:
a)a chave secreta deve ser compartilhada, o que pode complicar a gerência de
chaves;
b)não permite autenticação do remetente, uma vez que qualquer pessoa poderá
enviar uma mensagem criptografada com qualquer chave que esteja em seu
domínio;
c)não permite o não-repúdio do remetente, o que é decorrência direta do item
anterior.
Pode-se dizer que as principais vantagens da criptografia assimétrica são:
a)a chave secreta não é compartilhada, uma vez que basta a chave pública ? de
conhecimento geral ? para a troca segura de mensagens;
b)provê autenticação, já que é possível validar assinatura com a chave privada
através da chave pública, partindo-se do princípio que a chave privada não foi
distribuída (uma vez que isso não é necessário) para ninguém;
c)permite o não-repúdio, pois é possível verificar as chaves;
d)é escalável, possibilitando que exista uma hierarquia de controle e distribuição
de chaves, que pode ser facilmente ampliada.
Em contrapartida, existem pelo menos duas grandes desvantagens:
a)é lenta, pois os algoritmos, pela sua natureza matemática, são
computacionalmente intensivos;
b)requer uma autoridade de certificação, para que se possa garantir a identidade
e ter-se chaves públicas confiáveis.
A criptografia assimétrica não substitui a criptografia simétrica. O que importa é
reconhecer e identificar as limitações de cada método, de forma a usá-los de uma
maneira complementar para prover a segurança necessárias às partes
envolvidas.
UNINDO A CRIPTOGRAFIA SIMÉTRICA À ASSIMÉTRICA

Uma vez que os algoritmos simétricos são mais rápidos e, dessa forma, mais
propícios à cifragem de grandes volumes de informação e os esquemas
assimétricos de criptografia são mais apropriados para distribuir chaves e
garantir autenticação e não-repúdio, pode-se, através de uma combinação das
duas técnicas, distribuir grandes volumes de informações criptografados com
chaves simétricas e, estas por sua vez, distribuídas com criptografia de chaves
públicas.