Instalação Openswan 2.6 + Klips

Bom dia pessoal, a alguns dias estou utilizando a versão 2.6.18 do Openswan para testes, devido algumas alterações em versões anteriores 2.6.X se não me engano, não é mais necessário ficar aplicando patch para utilizar Klips no Openswan, basta compila-lo com alguns parâmetros e na hora de configurar adicionar o parâmetro protostack=klips dentro do conf, além de disponibilizar uma nova stack baseada no Klips (Creio EU que seu sucessor) chamada mast

--- Obtido da Manpage do ipsec.conf ---

protostack
decide which protocol stack is going to be used. Valid values are "auto", "klips", "netkey" and "mast". The "mast" stack is a variation for the klips stack.

-------

Com isso segue um tutorial bem básico de como compilar o Openswan + Klips utilizando a versão 2.6.18 do Openswan sem aplicar patch

- Requisitos:
libgmp e libgmp-devel
bison
flex
gawk


- Primeiro de tudo, descompactar o pacote do openswan...
#tar -zxvf openswan-2.6.18.tar.gz

Após isso executar o Make para fazer o build do openswan e dos modulos

#make KERNELSRC=/usr/src/linux-2.6.18 module programs

com o término do make se utilizar kernel 2.6 execute:

#make KERNELSRC=/usr/src/linux-2.6.18/build minstall install



com isso o openswan já estará instalado e com o klips ativado e com suporte a mast e netkey, caso habilitado no kernel, a jogada é bem simples..

protostack=klips
ou
protostack=netkey
ou
protostack=mast

Basta restartar o ipsec para alterar entre eles...

Obs.: se for utilizar netkey, utilize-o com kernel 2.6.6 ou superior... é conhecido que as versões anteriores possuem bugs na pilha IPSEC

Mascaramento IPSEC

Hoje na lsita de discussão a qual sou criador (Openswan-BR), houve um questionamento quanto a mascaramento de ipsec, se era necessário criar um mascaramento para que as estações se comunicassem pela VPN, o post de hoje é a resposta desse e-mail que acei legal explicar o motivo e quando é utilizado um mascaramento + IPSEC sem causar problemas nem precisar de NAT-T

Na verdade não se deve fazer isso... se o mascaramento for efetuado após a encriptação, creio eu que o unico
caso de ser necessário um mascaramento que conheço é quando ambas subnets são
iguais, ou por questões gerenciais (algumas empresas solicitam um range
específico para se fechar a vpn para evitar duplicidade), então devido
a isso se faz necessário fechar o túnel com a rede estipulada e criar
mascaramentos e Dnat para os acessos necessários.


Ex.:

Rede A = 192.168.0.0/24
ips de acesso rede B = 172.16.0.1 (outra ponta estipulou apenas um ip para conexão)

a conf do túnel fica:


leftsubnet=172.16.0.1/32
rigthsubnet=192.168.0.0/24

além disso é necessário criar uma interface que responda por esse ip e suas respectivas regras de mascaramento e DNAT


ifconf eth0:0 172.16.0.1

iptables -t nat -I PREROUTING -d 172.16.0.1 -p tcp --dport 80 -l DNAT --to 10.0.0.1 - Dnat para o servidor real


iptables -t nat -I POSTROUTING -s 10.0.0.1 -j SNAT --to 172.16.0.1 - Snat para o ip permitido no túnel.


(Detalhe,
note que todo o mascaramento foi efetuado antes de passar pelo ipsec,
sendo assim o pacote so é criptografado após o mascaramento, caso seja
efetuado o contrário, mascarar a saida do ipsec, o resultado não terá
sucesso, pois o dado ja estará encriptado e com um novo cabeçalho
criado para o túnel)


ex.:

Cabeçalho antes do IPSEC:

+----------------------------------------------+

| Cabeçalho IP | Cabeçalho TCP | Dados |
+----------------------------------------------+


Cabeçalho apos o IPSEC em modo transport: Cabeçalho IPSEC apenas é
adicionado para protoger os cabeçalhos de camadas superiores (
Transporte até Aplicação) devido a isso so pode ser utilizado no
Gateway IPSEC

+--------------------------------------------------------------------------------+
| Cabeçalho IP | Cabeçalho IPSEC | Cabeçalho TCP | Dados |
+----------------------------------------------------------------------+

Cabeçalho após IPSEC em modo túnel: Cabeçalho IPSEC protege todo o pacote
anterior e adiciona um novo cabeçalho IP (Encapsula) dessa forma
podendo ser utilizado em um Lan-To-Lan


+--------------------------------------------------------------------------------------------------+
| Cabeçalho IP | Cabeçalho IPSEC | Cabeçalho IP | Cabeçalho TCP | Dados |
+----------------------------------------------------------------------------------------+


Devido a isso caso seja alterado o pacote após o encapsulamento do ipsec o
pacote como um todo será alterado, impossibilitando a comunicação da
VPN, ja com o mascaramento antes do pacote ser encapsulado e possivel
pois um novo cabeçalho IP é criado no Modo Tunnel.

Métodos de Negociação do IPSEC

ISAKMP-SA (Internet Security Association Key Management Protocol Security Association)

É um “ID” obtido atraves do ip, id, email e DN (caso utilizados), esse id e criado automaticamente pelo isakmp durante a negociação da Fase I somados com a chave RSA/PSK utilizada.

Para que a Fase 1 seja negociada com sucesso e necessário que se utilize um método de negociação que pode ser Main Mode ou Aggressive Mode

Main Mode

Para que a Fase um seja estabelecida com sucesso é necessário que uma série de requisições seja enviada entre os Gateways vpn, o metodo normal dessa negociação ser feita chama-se Main Mode.

Esse Método possui uma latência maior, pois depende do envio e recebimento de vários pacotes para a negociação, devido a essa maior quantidade de requisições efetuadas sua segurança é maior.

Aggressive Mode

Muitos Fabricantes Utilizam esse modo de nogociação devido ter uma menor latência, pois envia menos requisições para estabelecer a fase 1, ISAKMP-SA, que é menor, esse modo é chamado de Aggressive Mode e reduz a quantidade de pacotes enviados, esse metodo requer mais CPU, pois tarefas relaionadas ao Diffie Hellman precisam ser concluídas antes do primeiro pacote ser reenviado. Devido a esse problema este método de negociação está sujeito a um Denial of Service, enviando ao IPSEC simples pacotes solicitando uma ISAKMP-SA

Main Mode X Aggressive Mode

A grande Vulnerabilidade do Aggressive Mode devido a redução de requisições efetuadas o hash da chave PSK é enviado antes da Encriptação ser habilitada, esse pacote pode ser capturado e uma ferramenta de brute force ou de dicionário pode obter a Chave utilizada. Já no Main mode o hash só é enviado após a encriptação ser habilitada

Com Aggressive Mode o pacote inicial da negociação contém todos os dados necessários para a fase 1, dessa forma o IPSEC remoto apenas verifica se pode efetuar ou não a solicitação. Dessa forma também está vulnerável a um ataque man-in-the-middle, caso esse pacote seja interceptado, um atacante pode obter uma conexão VPN válida.

Agressive Mode consome menos recursos de rede, devido fazer menos requisições porem requer mais CPU por ter que processar a SA inteira antes de terminar a Fase I

Main Mode consome mais recursos de rede, por enviar mais requisições, por outro lado consome menos cpu, por processar a SA aos poucos, conforme as requisições são recebidas/enviadas

VPN SSL através de Browser

Semana passada estava testando uma solução chamada SSL-explorer, uma
ferramenta que prove acesso remoto criptografado (ssl) , através de
browser, com ele basta o administrador configurar o que deseja
"compartilhar/publicar" e criar as politicas para seus usuários, após
isso o usuário remoto necessita apenas de um acesso https (443/tcp), ou
a porta que desejar configurar, para acessar recursos da rede como
servidores de FTP, Terminal Service, SSH, Compartilhamento Windows,
servidores de arquivos, etc... vale a pena dar uma olhada....

http://sourceforge.net/projects/sslexplorer

BackTrack 3 Final - Released

BackTrack 3 Final - Release Information

Released yesterday exclusively on pauldotcom.com



Muts, Martin and I have slaved for weeks and months, together with the

help of many remote-exploit'ers to bring you this fine release. As

usual, this version overshadows the previous ones with extra cool

things.



SAINT

SAINT has provided BackTrack users with a functional version of SAINT,

pending a free request for an IP range license through the SAINT

website, valid for 1 year.



Maltego

The guys over at Paterva have created a special version of Maltego

v2.0 with a community license especially for BackTrack users. We would

like to thank Paterva for co-operating with us and allowing us to

feature this amazing tool in BackTrack.



Nessus

Tenable would not allow for redistribution of Nessus on BackTrack 3.



Kernel

2.6.21.5. Yes, yes, stop whining....We had serious deliberations

concerning the BT3 kernel. We decided not to upgrade to a newer kernel

as wireless injection patches were not fully tested and verified. We

did not want to jeopardize the awesome wireless capabilities of BT3

for the sake of sexiness or slightly increased hardware

compatibilities. All relevant security patches have been applied.



Tools

As usual, updated, sharpened, SVN'ed and armed to the teeth. This

release we have some special features such as spoonwep, fastrack and

other cool additions.



Availability

For the first time we distribute three different version of Backtrack 3

- CD version

- USB version

- VMWare version



BackTrack 3 final download page is here:

http://remote-exploit.org/backtrack_download.html





Final Requests

We request the community to not mirror or torrent this release, or

otherwise distribute it online without our knowledge.

We are trying to gather statistics about bt3 downloads. If you would

like to mirror BT3 then please:



1) Think again! Traffic generated by BT3 downloads is CRAZY.

2) Please contact us before doing so.

3) Send us monthly statistics of downloads for the iso.



If you would like to add a link to BackTrack downloads to your

website, please use:



http://www.remote-exploit.org/backtrack_download.html as the download link.





Rants

Problems, fixes, bugs, opinions - should all end up in our Remote

Exploit community forums, and our wiki:



http://forums.remote-exploit.org

http://wiki.remote-exploit.org

Openswan-BR

Pessoal, á partir de hoje inicio uma lista de discussão sobre Openswan, chamada Openswan-BR, a intenção é reunir usuários e interessados em VPN e Openswan/Freeswan, com intuíto de tirar dúvidas e compartilhar informações em geral sobre VPN

Aos interessados segue as informações:



Página do Grupo

http://br.groups.yahoo.com/group/openswan-br

Endereços de e-mail do grupo

Enviar mensagem:	openswan-br@yahoogrupos.com.br
Entrar no grupo:	openswan-br-subscribe@yahoogrupos.com.br
Sair do grupo:	openswan-br-unsubscribe@yahoogrupos.com.br
Proprietário da lista:	openswan-br-owner@yahoogrupos.com.br

Parâmetros úteis do ipsec.conf (openswan)

Esse post visa apenas demonstrar algumas opções interessantes do ipsec.conf,, como por exemplo alterar algoritmos de criptografia, integraidade, etc...

Algoritmos de Criptografia e integridade Fase I:
ike=3des-md5
ike=3des-sha1
ike=aes-md5
ike=aes-sha1

para setar o dhgroup adicionar um -modp1024 por exemplo

ike=3des-md5-modp1024


Algoritmos de Criptografia e integridade Fase II (ESP):
(Detalhe, deve haver suporte no kernel para os algoritimos utilizados, geralmente 3des e AES ja vem por padrão na maioria das distros, mas no caso de blowfish, serpent, etc... é necessário habilitar)

esp=3des-md5
esp=3des-sha1
esp=aes-md5
esp=aes-sha1


PFS

Desabilitar
pfs=no

Habilitar
pfs=yes


Tipo de autenticação (RSA, PSK, etc..)
RSA
authby=rsasig

PSK
autby=secret


Status do túnel
Opção utilizada para setar em que estado o tunel iniciará.

Inicia automaticamente
auto=start

Somente adiciona o túnel mas não inicia a conexão
auto=add

Somente adiciona roteamento para o túnel, não carrega configurações nem inicia conexão
auto=route

Inicialização manual do túnel
auto=manual



Bom esse é um pequeno exemplo de alterações comuns para se criar um túnel, mais opções em: http://linux.die.net/man/5/ipsec.conf

mais opções úteis

VPN com duas ou mais Chaves RSA

Artigo explicando a configuração de dois túneis de VPN,
cada um usando uma chave RSA diferente, no caso um túnel utiliza chave RSA de 512 bits

e outro RSA de 1024 bits, para isso basta apenas utilizar a autenticação por id
utilizando os campos leftid e rightid para especificar qual chave pertence a qual túnel.



arquivo .conn do primeiro túnel:



conn teste1-teste2

authby=rsasig

auto=start

leftid=@teste1

rightid=@teste2
leftnexthop=200.1.1.1

rightnexthop=200.2.2.1

leftsubnet=192.168.1.0/24

rightsubnet=192.168.0.0/24

left=200.1.1.2

right=200.2.2.2
leftrsasigkey=0sAQNbO8LOc4zPQCW0itF1C3GjqWEYUMy0e/St6ZdR19s/auuKUyVicybYPUrbnzWh4V4U31B3A5NxXrnzh6gkSpwr

rightrsasigkey=0sAQPdXmWCOW3MObRypBZNjMsKqPjbtmIto+KxmTnJZWIVPtPUoN0NJWZjkE34LGhJw78D5QxZQP5HMVwdHmvJpQ5p



campos a serem utilizados:



leftid=@teste1

rightid=@teste2


segundo túnel:



conn harrier-sanobiol

authby=rsasig

auto=start

leftid=@teste1
rightid=@teste3
leftnexthop=200.1.1.1
rightnexthop=200.3.3.1

leftsubnet=192.168.1.0/24

rightsubnet=192.168.100.0/24

left=200.1.1.2

right=200.3.3.2
leftrsasigkey=0sAQPO5JQI8e/RoeszHQbF5SQGA0f1bVGcVdV9sY6bVDx/KLjaRaCmC5psJwwJEqnBEPJUJqEkHEr1MYcLYpjAxEMBwE9xoZ
CR0SkZM6DEd8kXcSY0fkhF2p+4V0QQqORL/BzVM8adyJTXQNWECXeM93EW7OLVS49gagRQXUxPCD6GSw==

rightrsasigkey=0sAQN6uP+o9ovN5SptfMOkTRPY4Xss0XGkbVyqygdMhYfJ0YY/p1GJvrqbOkBRF7KW6A/xo24g4nmVAPndb2Wsblks9RXgSd
XWONaODtRw54LUJfu1wVqo+y8dI0weC2PyeDHiVwqJaznjN8Wi9n1wn7CyUdp1cq9iuvHUDbFgMVNtNw==



campos a serem utilizados:



leftid=@teste1
rightid=@teste3



configuração do arquivo /etc/ipsec.secrets





@teste1 @teste2: RSA {

# RSA 512 bits harrier.lasa.ind.br Wed Oct 4 12:27:43 2006

# for signatures only, UNSAFE FOR ENCRYPTION

#pubkey=0sAQNbO8LOc4zPQCW0itF1C3GjqWEYUMy0e/St6ZdR19s/auuKUyVicybYPUrbnzWh4V4U31B3A5NxXrnzh6gkSpwr

Modulus:
0x5b3bc2ce738ccf4025b48ad1750b71a3a9611850ccb47bf4ade99751d7db3f6aeb8a5325627326d83d4adb9f35a1e15e14df50770393715eb9f387a8244a9c2b

PublicExponent: 0x03

# everything after this point is secret

PrivateExponent:
0x0f34a077bdeccd355b9e1722e8d73d9b46e5840d777369fe1cfc43e2f94f353c492ced41fe544361e592b2f5ab585d7b9c317068f834aaa5855c105cdf1b2da7

Prime1: 0xaf1bd80c9831cecae117a11117f93ecafc4efae8ddcec108616529f71db50f7d

Prime2: 0x8560eb8cd447c3c1fac308cc199671ad6f67b3185488b0753865fb83cbf27ac7

Exponent1: 0x74bd3ab31021348740ba6b60baa629dca834a745e93480b040ee1bfa13ce0a53

Exponent2: 0x58eb47b3382fd7d6a72cb088110ef6739f9a77658db075a37aeea7ad32a1a72f

Coefficient: 0x9c59bb371d79f5d9aa3f66ea8beb242a8f3cba14afb776976ecc43dbcb6f29d6

}



@teste1 @teste3 : RSA {

# RSA 1024 bits harrier.lasa.ind.br Thu Feb 1 13:15:38 2007

# for signatures only, UNSAFE FOR ENCRYPTION

#pubkey=0sAQPO5JQI8e/RoeszHQbF5SQGA0f1bVGcVdV9sY6bVDx/KLjaRaCmC5psJwwJEqnBEPJUJ
qEkHEr1MYcLYpjAxEMBwE9xoZCR0SkZM6DEd8kXcSY0fkhF2p+4V0QQqORL/BzVM8adyJTXQNWECXeM93EW7OLVS49gagRQXUxPCD6GSw==

Modulus: 0xcee49408f1efd1a1eb331d06c5e524060347f56d519c55d57db18e9b543c7f28b8da45a0a60b9a
6c270c0912a9c110f25426a1241c4af531870b6298c0c44301c04f71a19091d1291933a0c477c9177126347e4845da9fb857
4410a8e44bfc1cd533c69dc894d740d58409778cf77116ece2d54b8f606a04505d4c4f083e864b

PublicExponent: 0x03

# everything after this point is secret

PrivateExponent: 0x227b6e017da7f845a7332f8120fb8601008bfe3ce2ef63a394f2ed19e35f6a86c979b6457101ef12
068201831c4ad828635bc58604b728dd9681e5c42020b5d55355baa77ca180c172e3d1136ac511112cd26db3f9c2084b47
64f9be86e06b5352eb60106065ae2c8e9572c2b15e00f8cb1ae7c262263f6fc37bf5eb8caa3dfb

Prime1: 0xe850b71db94fd7120d70a0c01c9c2cc26d91371fd2e677f545d96f58afd39b65241c64b21ec1c573a
2ea5d4d63b3d3dc45a8044a2e13d91c6ca6246a77a657bb

Prime2: 0xe3fc5a96eb78f58e5a6c198fda8e8447abb4b4f09867f5ff650cc6d90b35dcc3bf9321896770fcc1db
18fb9a010f9765e4996273146714494ecf645f449abab1

Exponent1: 0x9ae07a13d0dfe4b6b3a06b2abdbd732c490b7a1537444ff8d93b9f907537bcee1812edcc14812e4d1746
e8de4277e292d91aad86c96290bd9dc41846fa6ee527

Exponent2: 0x97fd91b9f250a3b43c48110a91b4582fc7cdcdf5baeff954ee088490b223e8827fb76bb0efa0a8813cbb52
66ab5fba43edbb96f762ef62db89df983f8311d1cb

Coefficient: 0x526ae7bd4ddce50a59a2d41b86ee1c6102327b60947e417a3eb720cf90296b14a0d436b37771c7beed4622d
a7344b942bfef38c395b4b0136e8dad142b79a705

}



detalhe: cada chave antes do parâmetro : RSA { tem a especificação de quais ids a chave responde



@teste1 @teste2: RSA {

@teste1 @teste3: RSA {



com isso se a outra ponta se identificar como @teste2
será utilizada a primeira chave RSA, caso se identifique como
@teste3 será utilizada a segunda chave RSA


Em caso de Dúvidas
gtalk/email: felipe.nix@gmail.com
msn: flph2@hotmail.com

VPN com ip dinâmico utilizando o Openswan

Esse post visa explicar como proceder para criar uma VPN onde uma das pontas possui ip dinâmico e a outra ip Válido.


Lado com ip válido:

A idéia é criar a VPN ipsec como se o lado com ip dinamico fosse um cliente fazendo uma discagem para o lado com ip fixo, servidor.

Devido a isso o parâmetro auto=add faz com que no lado com ip fixo o tunel seja iniciado porém não faça uma tentativa de conexão, apenas fique escutando as requisições.

já o Parâmetro right=%any estipula que a conexão poderá ser feita de qualquer origem, o controle será feito atráves da chave PSK utilizada (também pode ser feito com RSA trocando o parametro authby=secret para authby=rsasig)

exemplo de configuração da conexão (parte do arquivo /etc/ipsec.conf)

conn fixo-din
auto=add
authby=secret
left=200.1.1.2
rigth=%any
leftnexthop=200.1.1.1
rightnexthop=
leftsubnet=192.168.0.0/24
rightsubnet=192.168.1.0/24



Lado com ip dinâmico

na configuração abaixo o parâmetro left=%defaultroute faz com que o ip da interface não seja declarado, de tal forma que ele assuma o ip atrelado a interface que está o gateway default para iniciar a conexão,


conn fixo-din

auto=start
authby=secret
left=%defaultroute
rigth=200.1.1.2
leftnexthop=
rightnexthop=200.1.1.1
leftsubnet=192.168.1.0/24
rightsubnet=192.168.0.0/24

Top 10 de "Cagadas" com uma mídia de armazenamento

A empresa de recuperação de dados Kroll Ontrack, como faz todos os anos, anunciou a sua lista de desastres de 2007. A empresa cita os dez casos de recuperação de dados mais inusitados e engraçados, como o de um fotógrafo que derramou repelente dentro do HD tomado por formigas, do pescador que foi parar dentro d'água junto com seu laptop, e o da mulher que colocou seu pendrive na máquina de lavar. Em todos os casos, os dados foram recuperados com sucesso.

Confira a lista e veja os 10 casos mais curiosos deste ano:

10. Lavado - Este ano, uma mulher ligou para a Kroll Ontrack dizendo que havia "lavado seus dados". Seu pendrive USB foi lavado na máquina e ela não conseguia ler os dados.

9. Papai atrapalhado - Chegando com pressa do trabalho para alimentar a filha, um pai esqueceu do pendrive no bolso de sua camisa. Quando ele se debruçou para pegar a menina, o dispositivo caiu no prato de purê de maçã.

8. Mordendo a isca - Um pescador levou seu notebook para jogar enquanto ficava no barco esperando por uma fisgada. Quando um peixe beliscou a isca e o pescador se levantou, ele e o laptop pararam dentro d'água.

7. Fotógrafo em pânico - Um fotógrafo de casamento estava prestes a sentir a fúria de uma noiva quando descobriu, dois dias depois da cerimônia, que ele sobrescreveu as fotos do casamento dela com as de outro evento. Felizmente, a empresa conseguiu recuperar as fotos da noiva furiosa.

6. Muito ácido - Um cientista derramou ácido em um HD externo durante um experimento. Ele achou que os dados haviam sido queimados, mas foram todos recuperados.

5. Confusão no trabalho - Durante uma discussão profissional na Austrália, um diretor jogou seu pendrive no colega. O dispositivo caiu no chão e ficou em pedaços.

4. Fogo do inferno - Um incêndio destruiu a maior parte dos dados de um escritório, restando apenas alguns CDs. Os discos tinham derretido e estavam grudados na caixa, uma situação nova para os engenheiros da Ontrack.

3. Busca por uma vida quieta - Um cientista britânico estava cansado de ouvir os barulhos do seu HD, então ele abriu um buraco no aparelho e derramou óleo lá dentro. O barulho parou. O HD também.

2. Pára-quedas -Para testar a funcionalidade de um pára-quedas, uma câmera foi presa a ele e largada de um avião. O pára-quedas não abriu e a máquina ficou em pedaços. Os dados do cartão de memória foram recuperados.

1. Invasão de formigas -Ao descobrir que formigas haviam invadido seu HD externo, um fotógrafo tailandês tirou a tampa do HD e colocou repelente de insetor lá dentro. As formigas sumiram, e os dados também - mas foram recuperados.

Métodos de Negociação do IKE - (Main Mode, Aggressive Mode e Quick Mode)

The Many Modes of IPSec With IKE
IKE is a key management protocol designed for the secure exchange of encryption keys used by other encryption and authentication schemes. The IPSec draft requires the support of DES and 3DES for data encryption, and MD5 and SHA-1 for authentication. IKE is the framework that negotiates security association (SA) and keys.

Within IKE, two modes are used. Main Mode provides identity protection for the hosts initiating the IPSec session, but takes slightly longer to complete. Aggressive Mode provides no identity protection, but is quicker. All IPSec devices must support Main Mode; Aggressive Mode is optional. Note that the IPSec SA is negotiated independently of the IKE SA.

Main Mode An IKE session begins with the initiator sending a proposal or proposals to the responder. The proposals define what encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy should be enforced, for example. Multiple proposals can be sent in one offering. The first exchange between nodes establishes the basic security policy; the initiator proposes the encryption and authentication algorithms it is willing to use. The responder chooses the appropriate proposal (we'll assume a proposal is chosen) and sends it to the initiator. The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA. The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (Quick Mode) begins.

Aggressive Mode Aggressive Mode squeezes the IKE SA negotiation into three packets, with all data required for the SA passed by the initiator. The responder sends the proposal, key material and ID, and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder ID pass in the clear.

Quick Mode IPSec negotiation, or Quick Mode, is similar to an Aggressive Mode IKE negotiation, except negotiation must be protected within an IKE SA. Quick Mode negotiates the SA for the data encryption and manages the key exchange for that IPSec SA.

Fonte:

Network Computing - Making IPSEC for You By Mike Fratto

NIC.br disponibiliza NTP

Gostariamos de anunciar que o novo serviço de NTP do NIC.br,
o NTP.br,está em funcionamento.

O serviço fornece a Hora Legal Brasileira através
dos servidores: a.ntp.br, b.ntp.br e c.ntp.br.

Manter o relógio dos computadores sempre correto
é algo que tem assumidouma importância crescente.
Relógios incorretos geram reflexos no funcionamento
de diversos softwares e sistemas e na segurança dos
computadores, redes e da própria Internet.
O NTP corretamente configurado resolve isso de
forma bastante eficaz, gastando pouquíssimos
recursos de processamento e de rede.

O NTP.br vem ajudar a suprir a carência de
bons servidores NTP públicos no Brasil,
complementando outros projetos existentes.
Como diferenciais, podemos apontar:
- fornece a Hora Legal Brasileira,
baseando-se em relógios atômicos do Observatório Nacional,
mas localizados em diferentes datacenters;
isso torna o NTP.br independente do GPS estadunidense,
no qual baseia-se grande parte dos servidores públicos;

- os servidores têm redundância de hardware e rede
e estão localizados em datacenters com ótima
conectividade à Internet, estando aptos a
suportar milhares de consultas por segundo.

Convidamos a todos a visitar o site do projeto em:
http://www.ntp.br.
Nele há informações sobre o protocolo NTP
detalhes sobre o NTP.br, há tutoriais de
instalação e configuração e é possível monitorar o
funcionamento do serviço através de gráficos.

Dúvidas, sugestões, comentários, elogios e críticas podem ser
encaminhados para ntp@nic.br.

TOP 10 de vulnerabilidades WEB críticas - OWASP-BR

Senhores(as);

É com grande prazer que anuncio a versão traduzida do documento OWASP
TOP 10 2007 para nosso bom e velho português.

Para quem não tem conhecimento, o TOP 10 contém as 10
vulnerabilidades mais críticas encontradas em aplicações WEB para o
ano de 2007. Para cada uma das vulnerabilidades é apresentada uma
descrição, forma de identificação e proteção, entre outras
informações.

O link para o documento é:
http://www.owasp.org/images/4/42/OWASP_TOP_10_2007_PT-BR.pdf

Parabenizo o esforço de todos que cooperaram com a tradução e revisão
dos textos!!!

Aproveito o momento para convidar todos a conhecerem e participarem
das atividades da OWASP-BR : http://www.owasp.org/index.php/Brazil

Equipe OWASP-BR