EOS-Linux é Open Source

Atualmente sou mantenedor do EOS-Linux, trabalho esse que divido com minhas funções na BRC, é um projeto muito bacana e inovador... um linux criado do zero sem depender de nada... que pode ficar com a cara que vc quiser... é muito facil e prático trabalhar com ele... basta conhecer um pouco de gerenciamento de pacotes e shell Script.

duvidas e/ou sugestões podem me procurar

"Criado a partir do zero, o EOS® segue o projeto do e-book Linux®
From Scratch como referência e inicialmente concebido para ser a
plataforma das soluções comerciais da BRconnection®, mas agora está
aberto para uso irrestrito.

Seu instalador é
inovador – não utiliza outros como referência – e facilita a vida de
profissionais que pouco conhecem de desenvolvimento, ou seja, qualquer
um com conhecimentos básicos em shell script pode desenvolver roteiros
de instalação de acordo com as necessidades específicas de cada
projeto."

Fonte: http://www.brc.com.br/index.php?option=com_content&task=view&id=731&Itemid=405&lang=pt_BR

Site EOS: http://eos.brc.com.br


Felipe Santos - Rasputin
MSN: flph2@hotmail.com
Gtalk: felipe.nix@gmail.com

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