Tecnologia de criptografia WPA é quebrada em minutos no Japão
Postador por Francisco Coelho
Cientistas japoneses exploram brecha identificada em 2008 para quebrar popular tecnologia que garante segurança de dados em roteadores.
Dois cientistas japoneses criaram um método que quebra a tecnologia de criptografia Wi-FI Protected Access (WPA) em questão de minutos, o que pode colocar em risco roteadores que usam a popular ferramenta de segurança. Toshihiro Ohigashi, da Universidade de Hiroshima, e Masakaty Morii, da Universidade de Kobe, conseguiram a façanha há duas semanas, no evento Joint Workshop on Information Security, em Taiwan. Mais detalhes serão apresentados em conferência no Japão, que deve acontecer no dia 24 de setembro. Quem faz o ataque consegue ler tráfego criptografado em WPA, que circula em uma rede. Especialistas em segurança já tinham alertado para essa possibilidade em novembro do ano passado, mas os japoneses levaram a teoria à prática e mostraram que a quebra de segurança pode ocorrer em minutos. Os sistemas de criptografia em roteadores sem fio têm um longo histórico de problemas. O sistema WEP (Wired Equivalent Privacy), lançado em 1997, foi quebrado poucos anos depois e hoje é considerado completamente inseguro. Já existe, no entanto, alternativa para o WPA. É o WPA 2, que existe desde março de 2006. "Apesar da alternativa mais segura, ainda existe uma grande base instalada pelo mundo que não migrou para o novo sistema", afirma o diretor de marketing da organização Wi-Fi Alliance, Kelly Davis-Felner. A Wi-Fi Alliance é a entidade responsável por estabelecer padrões de redes sem fio para a indústria. Para o CEO da empresa de segurança Errata Security, Robert Graham, a nova prática de quebra de segurança não chega a ser um motivo de desespero, mas é preocupante. "Os softwares de segurança existentes no mercado são capazes de barrar esse ataque se o roteador não o fizer, mas a quebra da segurança é o suficiente para os profissionais de tecnologia dispensarem o sistema WPA", diz. A alteração do tipo de segurança no roteador é simples e pode ser configurado por qualquer pessoa que tenha acesso administrativo à interface do equipamento.
Por IDG News Service
Equipamentos de ponto de acesso da Cisco podem expor redes a ataques
Postador por Francisco Coelho
A AirMagnet, empresa norte-americana que desenvolve soluções de segurança para redes sem fio, descobriu que pontos de acesso da Cisco, aparelhos que propagam o sinal da rede, podem permitir que um hacker direcione tráfego para fora de uma organização, podendo dar a pessoas não autorizadas o acesso para toda a rede corporativa.
O porta-voz da Cisco, Ed Tan, disse que a empresa foi alertada pela AirMagnet e que está investigando o problema. “Não vamos nos pronunciar sobre a vulnerabilidade até que as investigações sejam finalizadas e que tenhamos uma medida corretiva que atenda todos os nossos consumidores”.
Na raiz do problema está a ação de adicionar novos pontos de acesso na rede. Alguns equipamentos da Cisco, quando incluídos na infraestrutura, entram em contato com os equipamentos já existentes automaticamente, mas não escondem os endereços IP e MAC (Media Access Control). Captar essa informação pelo ar é simples e isso pode ser feito por ferramentas gratuitas que existem na internet.
Com base nessa informação, uma pessoa poderia atacar o servidor com uma negação de serviço e tornar indisponível uma seção inteira da rede. Para isso, o criminoso precisaria estar no local da rede.
O maior potencial de risco é que o cracker consiga conectar o ponto de acesso a outro equipamento fora da empresa, ganhando acesso a toda a rede corporativa. “Seria quase como criar uma porta dos fundos apenas usando um aparelho barato de ponto de acesso”, afirma o diretor de produto da AirMagnet, Wade Williamson.
A vulnerabilidade afeta todos os pontos de acesso de menor porte da Cisco, o que equivale à maioria dos aparelhos de ponto de acesso que a empresa lançou desde 2005.
Por IDG News Service
Super Bluetooth
Postador por Lincoln Carvalho
O Super Bluetooth foi desenvolvido em java com a finalidade de ter mais interação entre celulares, serve para você conseguir dados de outros celulares via bluetooth. Uma vez conectado a um outro telefone através de Bluetooth você pode:- Ler as mensagens
- Ver a lista de contatos
- Mudar o perfil
- Fazer o telefone tocar mesmo estando em modo silencioso
- Fazer downloads dos ringtones (para o seu celular)
- Reiniciar o telefone
- Desligar o telefone
- Restaurar os valores de origem
- Mudança de toque Volume
- E aqui vem a melhor "Fazer Ligações dos outro celular" Entre outros.
Esse software foi criado com a intenção de ajudar usuários quem utilizam mais de um celular para interagir os celulares apenas por um.
Configuração Mínima: Celular com bluetooth
Obs: Verificar se seu celular é compativel com o programa.
Não nos responsabilizamos pelo uso inadequado desse programa.Curso Completo em Video - Redes Wireless [Geek Cursos]
Postador por Tiago Damasceno
Com essa vídeo aula você aprenderá como fazer uma rede wireless, uma das tecnologias mais modernas quando o assunto é redes. Além disso, a parte teórica explica com detalhe padrões e significados sobre redes wireless e outros tipos de rede. Redes Wireless - Curso completo em vídeo + Tutoriais passo a passo Monte e Configure sua Própria rede sem fio!!!
Principais Conceitos
Curso Redes de Computadores - Campus
Postador por Tiago Damasceno
Redes de computadores, quarta edição, é a introdução ideal às redes de hoje e amanhã.
Este best-seller clássico foi completamente atualizado para às redes de
refletir as tecnologias mais novas e mais importantes de redes, com ênfase
especial em redes sem fios, incluindo 802.11, Bluetooth™, comunicação sem fios
ad hoc, i-mode e WAP. Porém as redes fixas não foram de banda larga, redes
ignoradas, com cobertura de ADSL, Internet via cabo, Ethernet de gigabit, redes
não hierárquicas, NAT e MPLS.
Além disso, existe grande quantidade de material novo sobre aplicações, inclusive mais de 60 páginas sobre a Web, e ainda rádio na Internet, voz sobre IP e vídeo por demanda. Por fim, a cobertura de segurança de redes foi revista e expandida para preencher um capítulo inteiro.
Autor, educador e pesquisador, Andrew S. Tanenbaum, vencedor do ACM Karl V.
Karlstrom Outstanding Educator Award, explica cuidadosamente como as redes do lado de dentro, desde o hardware subjacente na camada física até funcionam a camada de aplicação de nível superior. Tanenbaum focaliza todos estes temas e
muitos outros:
de protocolos, HDLC, SLIP e PPP)
larga e comutação)
QoS, lPv4 e IPv6)
desempenho de redes)
apresenta muitos exemplos extraídos da Internet e de redes sem fios.
DOWNLAOD BANDONGO
DOWNLAOD ZSHARE
DOWNLOAD MEGAUPLOAD
Redes Wireless - Como bular e prevenir-se de ataques!
Postador por Tiago Damasceno
Este E-Book é um tutorial, que explica como invadir uma rede wireless para poder utiliza da mesma. Porém este tutorial também te ajuda a previnir sua rede destes ataque.
É muito explicado com imagens e links de onde baixar os programas necessários
DOWNLOAD MEGAUPLOAD
DOWNLOAD SENDSPACE
DOWNLOAD BITROAD
DOWNLOAD FILEFACTORY
DONWLAOD RAPIDSHARE
DONWLOAD ZSHARED
[TUTORIAL] Criando VPN Avançada com OpenVPN - PARTE 02
Postador por Tiago Damasceno
Clique aqui para ler a PARTE 01
Usar chaves estáticas permite criar VPNs rapidamente, interligando duas máquinas. A facilidade de configuração faz com que esta modalidade seja a mais utilizada, embora as limitações sejam claras.
Vamos agora criar uma configuração mais elaborada, utilizando certificados X509. Este método é chamado de PKI (Public Key Infraestructure) e permite criar VPNs mais complexas, envolvendo vários servidores e vários clientes, além de oferecer uma maior segurança.
Para isso, criaremos uma "entidade certificadora", que será usada para gerar os certificados usados pelo servidor e pelos clientes. Falar em uma "entidade certificadora" dá a impressão de que precisaremos contratar uma empresa especializada para gerar os certificados, mas, na verdade, tudo é feito internamente, usando scripts fornecidos junto com o OpenVPN.
Durante o processo, é gerado um certificado mestre (um arquivo, que pode ser tanto armazenado pelo próprio servidor quanto por outra máquina da rede) que é usado para gerar os certificados usados pelas máquinas. O uso dos certificados permite que o servidor verifique a identidade dos clientes e também que os clientes verifiquem a identidade do servidor, evitando a possibilidade do uso de ataques "man-in-the-middle", onde alguém substitui o servidor por outra máquina, configurada para capturar as credenciais dos clientes quando eles tentam estabelecer a conexão.
Os certificados podem ser criados rapidamente, conforme for necessário conectar mais máquinas à VPN. Quando é necessário bloquear o acesso a uma determinada máquina (um funcionários que se desligou da empresa, por exemplo), basta revogar o certificado para que o servidor deixe de aceitar a conexão.
CRIANDO CERTIFICADOS
Para criar os certificados, utilizaremos o easy-rsa, um conjunto de scripts incluídos no pacote do OpenVPN. Na maioria das distribuições, os scripts estão disponíveis dentro da pasta "/usr/share/doc/openvpn/examples/easy-rsa". Se a pasta não existir na sua instalação, use os comandos abaixo para localizar a pasta:
# updatedb
# locate easy-rsa
Duas localizações comuns são as pastas "/usr/share/doc/packages/openvpn/easy-rsa" e "/usr/share/doc/openvpn-2.0/easy-rsa". No Fedora, especificamente, é usada a pasta "/usr/share/openvpn/easyrsa" e no CentOS é usada a pasta "/usr/share/doc/openvpn-2.0.9/easy-rsa/" (onde o 2.0.9 é a versão do pacote).
O primeiro passo é copiar todo o diretório para dentro da pasta "/etc/openvpn" (você pode usar outro diretório se preferir). Isso evita que nossa configuração seja apagada ao atualizar o pacote do OpenVPN no futuro. No Debian o comando seria:
# cp -a /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn/
No Fedora, onde a localização da pasta é diferente, o comando seria:
# cp -a /usr/share/openvpn/easyrsa /etc/openvpn/
Isso criará o diretório "/etc/openvpn/easy-rsa", contendo os seguintes arquivos:
2.0 build-key build-req make-crl revoke-full
build-ca build-key-pass build-req-pass openssl.cnf sign-req
build-dh build-key-pkcs12 clean-all README.gz vars
build-inter build-key-server list-crl revoke-crt
Em outras distribuições basta verificar qual é a pasta onde estão os exemplos e ajustar o comando de acordo.
A partir daí, toda a configuração será feita dentro do novo diretório:
# cd /etc/openvpn/easy-rsa
Comece editando o arquivo "vars" usando seu editor de textos preferido:
# joe vars
No final do arquivo, você encontra um conjunto de parâmetros usados para gerar as chaves (país, estado, cidade, empresa, etc.), que devem ser editados, como em:
export KEY_COUNTRY=BR
export KEY_PROVINCE=SP
export KEY_CITY="Guarulhos"
export KEY_ORG="GDH"
export KEY_EMAIL="morimoto@guiadohardware.net"
Em seguida, usamos o comando "source" para carregar as variáveis contidas dentro do arquivo "vars" e em seguida executamos os scripts "clean-all" e "build-ca". O primeiro script limpa qualquer sobra de configuração anterior, enquanto o segundo gera o certificado raiz, usando o openssl. Como os scrips estão dentro do diretório atual, usamos o "./" ao executá-los:
# source vars
# ./clean-all
# ./build-ca
Generating a 1024 bit RSA private key
...................++++++
.....................++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [BR]:
State or Province Name (full name) [SP]:
Locality Name (eg, city) [Guarulhos]:
Organization Name (eg, company) [GDH]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address [morimoto@guiadohardware.net]:
Isso criará a pasta "/etc/openvpn/easy-rsa/keys", contendo os seguintes arquivos:
ca.crt ca.key index.txt serial
O arquivo "ca.crt" contém o certificado raiz. Ele jamais deve sair do servidor, já que qualquer um que tenha acesso a ele poderá gerar certificados adicionais que, essencialmente, permitirão que qualquer um se conecte à VPN. A necessidade de manter esse arquivo secreto faz com que alguns administradores prefiram gerar as chaves em uma máquina desconectada da rede (apenas com acesso local) e copiar manualmente os certificados gerados para o servidor e as demais máquinas.
Depois de criar o certificado raiz, podemos passar para o para o passo seguinte, que é gerar os certificados para o servidor e para os clientes.
Para gerar o certificado do servidor, usamos o script "build-key-server", especificando como parâmetro o nome do arquivo que será gerado ("servidor" no exemplo). O nome é apenas para identificação dos hosts, você pode usar os nomes que preferir:
# cd /etc/openvpn/easy-rsa/
# ./build-key-server servidor
Ele começa confirmando as informações que serão incluídas no certificado (país, cidade, empresa, etc.), da mesma forma que ao rodar o build-ca. Em um certo ponto, ele perguntará pelo atributo "Common Name", onde você deve fornecer o nome do servidor, como em:
Common Name (eg, your name or your server's hostname) []:Etch
Em seguida, ele oferece a opção de incluir um "challenge password", uma senha que será solicitada cada vez que o certificado for usado. Ela aumenta a segurança, mas em compensação reduz bastante a praticidade, já que você precisará digitar a senha cada vez que o certificado for utilizado, o que pode se tornar incrivelmente inconveniente em um servidor administrado remotamente. Se quiser manter as coisas simples, deixe o campo em branco:
A challenge password []:
Antes de terminar, ele confirma se você deseja assinar o certificado e pede mais uma confirmação antes de aplicar a alteração. Responda "y" em ambas, caso contrário a geração do certificado é abortada:
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Em seguida, geramos as chaves que serão usadas pelos clientes, usando o script "build-key". Você pode gerar chaves para vários clientes em sequência, especificando nomes diferentes, como em:
# ./build-key cliente1
# ./build-key cliente2
Cada vez que o comando é executado, o script mostra a saída do comando do openssl usado para gerar a chave e confirma os parâmetros do certificado, como ao rodar o "build-key-server":
Generating a 1024 bit RSA private key
.++++++
.......................++++++
writing new private key to 'cliente1.key'
Se ele simplesmente for executado instantaneamente, sem exibir o indicador ou qualquer mensagem de erro, é sinal de que alguma coisa está errada, provavelmente com a atribuição das variáveis usada pelo script. Nesse caso, experimente rodar novamente o comando "source vars" e executar o script novamente, como em:
# source vars
# ./build-key cliente1
Não se esqueça de preencher a opção "commonName" com o nome da máquina (ou outro nome definido por você, diferente em cada chave). Deixando o campo em branco a chave não é gerada. No final não esqueça de responder as perguntas "Sign the certificate?" e "1 out of 1 certificate requests certified, commit?" com o valor "y".
Common Name (eg, your name or your server's hostname) []:cliente1
...
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Diferente do "build-key-server", ele não oferece a opção de proteger a chave usando uma senha. Se você quiser que os usuários precisem digitar uma senha antes de poderem efetuar a conexão usando o certificado, gere as chaves usando o script "build-key-pass" em vez do "build-key". Ele confirma todos os parâmetros (assim como o build-key-server) e oferece a opção incluir a senha:
# ./build-key-pass cliente2
Em seguida, usamos o script "build-dh" (sem parâmetros). Ele gera os parâmetros Diffie Hellman, que reforçam a segurança, permitindo que o servidor e os clientes troquem as chaves (de forma segura) no momento da conexão, confirmando suas identidades:
# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time
....................................+...........+...............
O comando demora quase um minuto para gerar os parâmetros, mostrando um indicador de progresso durante o processo. Em caso de problemas, certifique-se de que está rodando os comandos a partir do diretório "/etc/openvpn/easy-rsa", rode o comando "source vars" para carregar as variáveis e tente novamente.
O processo de geração das chaves gera um conjunto de arquivos ".csr". Estes arquivos correspondem às requisições para a assinatura das chaves, que é feita durante o processo de criação. Eles podem ser removidos no final do processo:
# rm *.csr
Você ficará então com um conjunto de arquivos similar a esse dentro do diretório "/etc/openvpn/easy-rsa/keys":
ca.crt cliente1.key cliente2.key index.txt servidor.crt
ca.key cliente2.crt cliente3.crt index.txt.attr servidor.key
cliente1.crt cliente2.csr cliente3.key serial
Caso esteja curioso, estes scripts nada mais fazem do que executar os comandos correspondentes do OpenSSL, usando os parâmetros definidos no arquivo "vars". O script "build-key", por exemplo, executa os comandos:
cd $KEY_DIR && \
openssl req -days 3650 -nodes -new -keyout $1.key -out $1.csr -config $KEY_CONFIG && \
openssl ca -days 3650 -out $1.crt -in $1.csr -config $KEY_CONFIG && \
chmod 0600 $1.key
Note que é usado o parâmetro "-days 3650", que faz com que as chaves tenham validade de 10 anos. Se a sua VPN ainda estiver em uso até lá, não se esqueça de trocar as chaves antes do 3650° dia, caso contrário sua VPN parará de funcionar após completar o décimo aniversário. :)
Falta agora fazer a instalação das chaves, tanto no servidor quanto nos clientes. Para o servidor, crie o diretório "/etc/openvpn/keys" e copie para ele os arquivos "ca.crt", "servidor.crt" e "servidor.key", como em:
# cd /etc/openvpn/easy-rsa/keys
# mkdir /etc/openvpn/keys
# cp -a ca.crt servidor.crt servidor.key /etc/openvpn/keys/
Copie também o arquivo "dh1024.pem" (o número 1024 corresponde ao comprimento da chave e pode mudar de acordo com a configuração), ele contém os parâmetros Diffie Hellman, e é gerado ao rodar o script "build-dh":
# cp -a dh1024.pem /etc/openvpn/keys/
O passo final é fazer a cópia dos certificados para os clientes, usando o SFTP ou outra ferramenta de transferência de arquivos.
Todos os clientes devem possuir o arquivo "ca.crt", o arquivo "dh1024.pem" e os arquivos .crt e .key correspondentes a ele. O cliente1 receberia os arquivos "ca.crt", "dh1024.pem", "cliente1.crt" e "cliente1.key"; o cliente2 receberia os arquivos "ca.crt", "dh1024.pem", "cliente2.crt" e "cliente2.key", e assim por diante.
Nos clientes Linux, crie o diretório "/etc/openvpn/keys", e copie os três arquivos para ele. Se eles estiverem com o servidor SSH ativo (e você tiver a senha de root, pode fazer a cópia a partir do próprio servidor, usando o SFTP, como em:
# sftp root@192.168.1.21
Password:
sftp> mkdir /etc/openvpn/keys
sftp> cd /etc/openvpn/keys
sftp> put ca.crt
sftp> put dh1024.pem
sftp> put cliente1.crt
sftp> put cliente1.key
No caso dos clientes Windows, os quatro arquivos devem ser copiados para o diretório "keys", dentro do diretório de instalação do OpenVPN, como em "C:\Arquivos de programas\OpenVPN\config\keys". Assim como no caso dos clientes Linux, é necessário criar o diretório manualmente:
O uso de chaves torna necessário que os relógios das máquinas estejam sincronizados. No Linux, você pode acertar o relógio da máquina via web usando o comando:
# ntpdate -u pool.ntp.org
No Windows, marque a opção "Sincronizar automaticamente com um servidor de horário na Internet", disponível no Painel de Controle > Data e hora > Horário na Internet".
Ajustando a configuração
A parte mais complicada em usar certificados é a configuração inicial, que acabamos de fazer. Uma vez que os certificados já estão criados e instalados nos clientes, tudo fica mais simples.
Vamos começar com uma configuração básica, similar à VPN que criamos inicialmente utilizando chaves estáticas. Nesse exemplo, estou utilizando o sistema TAP (em vez do TUN, como no exemplo anterior) e estou utilizando os certificados anteriormente criados. A diferença entre o TUN e o TAP é que no TUN o tráfego da rede é roteado (o que elimina os pacotes de broadcast), enquanto no TAP tudo é transmitido, incluindo pacotes de broadcast e pacotes de outros protocolos de rede (como o IPX/SPX).
O arquivo "/etc/openvpn/server.conf" no servidor ficaria:
dev tap
ifconfig 10.0.0.1 255.255.255.0
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key
Veja que agora usamos a linha "tls-server" e especificamos a localização dos 4 arquivos com os certificados que instalamos nos passos anteriores. A linha "ifconfig" especifica o endereço IP que será usado pelo servidor, juntamente com a máscara de subrede.
A configuração no arquivo "/etc/openvpn/client.conf" nos clientes ficaria:
remote guiadohardware.no-ip.org
dev tap
tls-client
ifconfig 10.0.0.2 255.255.255.0
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
Criados os arquivos de configuração no servidor e no cliente, reinicie o serviço em ambas as máquinas, para que o daemon leia a nova configuração e estabeleça a conexão:
# /etc/init.d/openvpn restart
Se a VPN não funcionar, ou se você receber um "Starting virtual private network daemon: client(FAILED)" ao reiniciar o serviço, experimente ativar o OpenVPN manualmente (no cliente), usando o comando:
# openvpn --config client.conf
Isso faz com que ele exiba as mensagens geradas pelo programa durante a inicialização, o que pode ajudá-lo a identificar o problema. Pode ser que ele não esteja conseguindo contactar o servidor no endereço especificado (ou o firewall pode estar bloqueando a porta especificada na configuração), pode existir algum erro na configuração, ou pode ter havido algum problema durante a geração ou a cópia das chaves, por exemplo.
Nos clientes Windows, a configuração é quase idêntica, mudando apenas as linhas com a localização das chaves. Se você as colocou dentro da pasta "keys", no diretório de configuração, o arquivo "client.ovpn" ficaria como no screenshot abaixo:
Para permitir que vários clientes se conectem simultaneamente à VPN, é necessário fazer algumas mudanças na configuração. A principal delas é que em vez de especificar manualmente o endereço IP usado pelo servidor e pelo cliente usando o comando "ifconfig" como em "ifconfig 10.0.0.2 10.0.0.1", passamos a especificar uma faixa de endereços IP para a VPN e deixamos que o servidor atribua endereços para os clientes conforme eles se conectam.
Isso é mais simples do que parece. Na configuração do servidor utilizaremos a linha "server" (deixando de usar a linha do ifconfig), especificando a faixa de endereços e a máscara, como em:
server 10.0.0.0 255.255.255.0
É importante enfatizar que a faixa de endereços utilizada na VPN deve ser diferente da faixa de endereços utilizada na rede local à qual o servidor está ligado, que, por sua vez, também deve ser diferente da faixa de endereços de rede local utilizada pelo cliente.
Originalmente o cliente tem acesso apenas ao próprio servidor. Para permitir que ele possa acessar os demais hosts da rede local, adicionamos uma linha adicional, que faz com que o servidor inclua uma regra de roteamento na configuração do cliente, no momento da conexão. Ela especifica a faixa de endereços e a máscara usada na rede local:
push "route 192.168.1.0 255.255.255.0"
Com a regra, o cliente passará a usar o endereço IP do servidor na VPN como roteador para os pacotes destinados à faixa de endereços especificada. Essa linha substitui o comando "route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.1 dev tun0" (executado no cliente) que usamos no tópico sobre VPNs com chaves estáticas.
Na configuração do cliente, adicionamos a linha "pull" (push = empurrar, pull = puxar), para que ele aceite as configurações fornecidas pelo servidor. Com isso, o cliente recebe automaticamente um endereço aleatório dentro da faixa "10.0.0.x", sem que você precise especificar a configuração de cada um manualmente:
pull
Aqui temos um exemplo de configuração completa do servidor, utilizando a interface tun, especificando uma porta UDP alternativa e utilizando as novas opções:
proto udp
port 22222
dev tun
server 10.0.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key
A configuração correspondente para o cliente seria:
remote guiadohardware.no-ip.org
proto udp
port 22222
client
pull
dev tun
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
Com essa configuração, o servidor passa a ser capaz de receber conexões a partir de vários clientes simultaneamente. O OpenVPN é capaz de gerenciar todas as conexões utilizando a mesma porta.
Para adicionar um novo cliente à VPN, você precisaria apenas gerar um novo certificado, usando o comando "./build-key" e copiar os quatro arquivos para dentro da pasta "/etc/openvpn/keys" (além de instalar o OpenVPN, naturalmente). Em resumo, os comandos para gerar um novo certificado são:
# cd /etc/openvpn/easy-rsa/
# source vars
# ./build-key novocliente
A configuração é a mesma que foi usada para o primeiro cliente, mudando apenas os arquivos dos certificados. Com isso, cada cliente recebe um endereço diferente dentro da faixa "10.0.0.x" e pode acessar o servidor através do endereço "10.0.0.1".
É necessário também ativar, no servidor, a regra de firewall que roteia os pacotes provenientes dos clientes da VPN para a interface de rede local. Como agora estamos utilizando endereços atribuídos automaticamente e não mais endereços estáticos, especificamos a faixa de endereços, em vez de especificar diretamente o endereço usado pelo cliente:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -s 10.0.0.0/24 -A POSTROUTING -o eth0 -j MASQUERADE
Estes dois comandos precisam ser executados pelo servidor a cada boot. Você pode incluí-los no seu script de firewall, ou em algum dos scripts de inicialização do sistema.
Uma opção útil ao usar vários clientes é a opção "ifconfig-pool-persist". Ela faz com que o OpenVPN passe a armazenar uma lista cos os endereços IP usados por cada clientes da VPN e faça o possível para atribuir sempre os mesmos endereços em futuras conexões dos clientes. Isso não impede que os endereços mudem, mas torna as mudanças muito menos freqüentes. Esta opção é incluída apenas na configuração do servidor, especificando um arquivo de texto onde a lista será salva, como em:
ifconfig-pool-persist /etc/openvpn/ipp.txt
O arquivo é criado e atualizado automaticamente pelo OpenVPN, a única exigência é que ele deve ser criado dentro do diretório "/etc/openvpn" ou outra pasta à qual o usuário "openvpn", usado pelo daemon tenha acesso.
Uma opção que aumenta a segurança dos clientes é a "remote-cert-tls server" que faz com que os clientes verifiquem o certificado do servidor no momento da conexão. Ela é mais uma opção destinada a proteger os clientes contra ataques man-in-the-middle. Esta opção é adicionada apenas na configuração dos clientes:
remote-cert-tls server
Uma observação importante é que esta opção é suportada apenas pelo OpenVPN versão 2.1 (final) em diante. Se o cliente usar uma versão anterior (como o OpenVPN 2.1_rc4, usado no Debian Etch), a opção muda para "ns-cert-type server":
ns-cert-type server
Você pode verificar qual é a versão do OpenVPN usada e assim descobrir qual das duas opções deve ser utilizada usando o comando:
# openvpn --version
Usar a opção "remote-cert-tls server" em um cliente com uma versão antiga do OpenVPN faz com que o serviço simplesmente deixe de funcionar até que você a substitua pela "ns-cert-type server".
Outro problema comum é com relação ao uso da banda pelos usuários da VPN. Se uma única conexão web é dividida entre o uso da VPN e o acesso à web, você vai provavelmente querer restringir o uso de banda da VPN, para evitar que cópias de grandes arquivos e outras atividades que envolvam grande uso de banda saturem a conexão.
Isso é feito usando a opção "shaper", que limita o banda total de saída usada pela VPN a um determinado volume de tráfego. Se você usa um link ADSL com 512 kbits (ou seja, 64 kbytes) de upload, você poderia restringir o uso de banda pela VPN a 50 kbytes, por exemplo, de forma a deixar pelo menos uma pequena porção da banda reservada para outros usos.
A opção "shaper" pode ser incluída na configuração do servidor (para que seja aplicada ao tráfego de saída somado de todos os clientes conectados a ele), na configuração dos clientes (limitando assim o tráfego de saída permitido por cada um) ou em ambos. Basta especificar o limite desejado, em bytes, como em:
shaper 51200
Você pode também limitar o número de clientes simultâneos que será aceitos pelo servidor usando a opção "max-clients", especificando o número de clientes desejados, como em:
max-clients 10
Uma última opção, que pode ser usada para proteger sua VPN contra ataques DoS e oferecer uma camada adicional de segurança é a opção "tls-auth".
Com ela, uma chave compartilhada é usada para criar uma segunda camada de encriptação, sobre os pacotes já encriptados usando os certificados. O servidor só aceita pedidos de conexão encriptados com a chave compartilhada, o que faz com que pedidos de conexão de pessoas não autorizadas (que não terão a chave) sequer sejam processados pelo servidor.
Para utilizar a opção, é necessário criar uma chave estática, usando o comando "openvpn --genkey --secret", o mesmo que utilizamos no inicio para gerar a chave estática usada na nossa VPN inicial. Este arquivo pode ser armazenado no diretório "/etc/openvpn/keys", junto com os arquivos dos certificados:
# cd /etc/openvpn/keys
# openvpn --genkey --secret chave.key
O arquivo gerado deve ser então copiado para todos os clientes. O próximo passo é adicionar a opção, tanto na configuração do servidor quanto na dos clientes, especificando a localização do arquivo, como em:
tls-auth /etc/openvpn/keys/chave.key
Note que, nesse caso, a chave não permite acessar a VPN. Ela é apenas um pré-requisito para poder enviar requisições de conexão para o servidor. Além dela, é necessário ter os 4 arquivos com o certificado e as chaves, como nos exemplos anteriores.
Aqui temos um exemplo final de configuração para o servidor, utilizando todas as opções que vimos até aqui:
# /etc/openvpn/server.conf
proto udp
port 22222
dev tun
server 10.0.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
comp-lzo
keepalive 10 120
persistkey
persisttun
float
ifconfig-pool-persist /etc/openvpn/ipp.txt
max-clients 10
shaper 51200
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key
tls-auth /etc/openvpn/static.key
Aqui vai o arquivo de configuração correspondente para os clientes:
# /etc/openvpn/client.conf
remote guiadohardware.no-ip.org
proto udp
port 22222
client
pull
dev tun
comp-lzo
keepalive 10 120
persistkey
persisttun
float
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente1.crt
key /etc/openvpn/keys/cliente1.key
tls-auth /etc/openvpn/static.key
Se você já está com o servidor OpenVPN ativo, precisa apenas reiniciar o serviço para que a nova configuração entre em vigor, como em:
# /etc/init.d/openvpn restart
ou:
# service openvpn restart
Se você receber um "Starting virtual private network daemon: server(FAILED).", verifique todas as opções e cheque se os arquivos dos certificados foram gerados e copiados corretamente.
Como comentei anteriormente, o conteúdo do arquivo de configuração nos clientes Windows é exatamente o mesmo, mudando apenas as linhas com as localizações dos arquivos com os certificados.
No Windows são usadas barras invertidas ao indicar a localização de arquivos e isso se aplica também à configuração do OpenVPN, entretanto as barras invertidas são também usadas como caracteres de escape no shell, por isso, ao indicas localizações de arquivos na configuração do OpenVPN no Windows, você deve duplicar todas as barras invertidas e colocar a localização entre aspas, como em:
static "C:\\Arquivos de programas\\OpenVPN\\keys\\static.key"
Um último truque é que, em um servidor com várias conexões, ou no caso de uma rede com vários servidores de VPN (onde os clientes podem se conectar a qualquer um dos servidores para obter acesso à rede), você pode criar um sistema simples de redundância e de balanceamento de carga especificando os endereços de todos os servidores na configuração dos clientes (criando várias linhas "remote") e adicionando a opção "remote-random", como em:
remote guiadohardware.no-ip.org
remote gdhn.com.br
remote gdhpress.com.br
remote-random
Isso faz com que o cliente escolha aleatoriamente entre os três endereços especificados a cada conexão, tentando os outros dois caso o primeiro esteja inacessível. Como cada cliente escolherá um servidor diferente a cada conexão, a carga acabará sendo dividida igualmente entre os servidores.
Revogando Certificados
ma parte importante do gerenciamento dos certificados no OpenVPN é a revogação dos certificados que não devem mais ser utilizados. Imagine o caso de um notebook que foi roubado, ou de um funcionário que foi demitido, por exemplo. Se os certificados não forem revogados, qualquer um em posse deles poderá (a menos que você inclua uma senha ao gerar os certificados) se conectar à VPN e assim ter acesso à rede interna da empresa.
O processo de revogação dos certificados consiste em criar um arquivo contendo a lista dos certificados revogados e configurar o servidor para utilizá-lo. A partir daí, não importa mais se os arquivos do certificado revogados sejam distribuídos, já que eles não terão mais serventia alguma.
Para criar a lista, acesse o diretório "/etc/openvpn/easy-rsa" no servidor (ou na máquina que estiver usando para gerar os certificados) e carregue as variáveis do arquivo "vars":
# cd /etc/openvpn/easy-rsa
# source vars
Execute o comando "revoke-full", especificando o certificado que será revogado, como em:
# ./revoke-full cliente1
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Revoking Certificate 08.
Data Base Updated
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
cliente1.crt: /C=BR/ST=SP/O=GDH/CN=cliente1/emailAddress=foo@bar.com
error 23 at 0 depth lookup:certificate revoked
A mensagem "error 23" indica que o certificado foi revogado com sucesso, ou seja, ela não é exatamente uma mensagem de erro e sim uma confirmação.
O comando gera o arquivo "crl.pem", dentro do diretório "/etc/openvpn/easy-rsa/keys". O próximo passo é copiar o arquivo para o diretório "/etc/openvpn/keys" do servidor. Para que ele passe a ser utilizado pelo OpenVPN, adicione o parâmetro "" na configuração do servidor, especificando a localização do arquivo, como em:
crl-verify /etc/openvpn/keys/crl.pem
Para que a alteração entre em vigor, reinicie o OpenVPN:
# /etc/init.d/openvpn restart
Com isso, o cliente perde imediatamente o acesso à VPN e passa a receber um erro "TLS Error: TLS handshake failed" ao tentar se conectar novamente.
Para revogar mais chaves, repita o processo, não se esquecendo de copiar o arquivo atualizado para a pasta "/etc/openvpn/keys" do servidor a cada alteração. Se você está gerando as chaves usando o próprio servidor, pode também especificar diretamente o arquivo na pasta "/etc/openvpn/easy-rsa/keys" na opção; assim você elimina a necessidade de copiar manualmente o arquivo a cada alterãção:
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
Para que o OpenVPN leia o arquivo atualizado, use o parâmetro "reload" do serviço. Isso atualiza a configuração sem derrubar os clientes conectados:
# /etc/init.d/openvpn reload
Criando bridges
A configuração que vimos até agora faz com que o tráfego seja roteado através da VPN. Isso melhora o desempenho da VPN, pois elimina a transmissão do tráfego de broadcast e de qualquer outro protocolo de rede que não seja o TCP/IP. A desvantagem é que, sem a transmissão do tráfego de broadcast, recursos como a navegação no ambiente de redes (nos clientes Windows) ou a instalação automática de impressoras compartilhadas através do Cups (nos clientes Linux) deixem de funcionar.
Se você está disposto a sacrificar parte do link para que a VPN se comporte como uma rede local, como se todos os micros estivessem conectados ao mesmo switch, existe a opção de criar um bridge, unindo a interface virtual da VPN e a interface da rede local. Com isso, o servidor passa a usar o mesmo endereço, tanto na rede local quanto na VPN e os clientes conectados à VPN podem receber um endereço dentro da faixa usada na rede local e não apenas acessarem, mas também serem acessados pelos demais micros.
Para isso, precisaremos de um pacote adicional, o bridge-utils, que deve ser instalado no servidor. Este é um pacote padrão, que está disponível em todas as principais distribuições e pode ser instalado usando o gerenciador de pacotes, como em:
# apt-get install bridge-utils
ou:
# yum install bridge-utils
Em seguida, precisamos fazer algumas alterações na configuração do servidor. A primeira delas é a criação de dois scripts, um para ativar e o outro para desativar o bridge. Estes scripts serão executados juntamente com o OpenVPN, na ativação e desativação do serviço.
O primeiro deles é o script "/etc/openvpn/bridge-start", que contém os comandos que ativam o bridge. Veja que este script contém uma série de parâmetros (que coloquei em negrito), que precisam ser alterados de acordo com a configuração do servidor:
#!/bin/bash
# /etc/openvpn/bridge-start
br="br0"
tap="tap0"
eth="eth0"
eth_ip="192.168.1.101"
eth_gw="192.168.1.1"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.1.255"
for t in $tap; do
openvpn --mktun --dev $t
done
brctl addbr $br
brctl addif $br $eth
for t in $tap; do
brctl addif $br $t
done
for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
ifconfig $eth 0.0.0.0 promisc up
ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast
route add default gw $eth_gw dev $br
iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT
A variável "eth" inclui o device da placa de rede e a "eth_ip" contém o endereço utilizado pelo servidor (nesse exemplo o servidor utiliza um endereço de rede interna, pois acessa através de uma conexão compartilhada, onde apenas a porta do OpenVPN é roteada para ele). A variável "eth_gw" inclui o gateway da rede (utilizado pelo servidor) enquanto a "eth_netmask" e "eth_broadcast" incluem a máscara e o endereço de broadcast da rede. Os três comandos finais incluem regras no firewall para permitir o tráfego nas interfaces.
Em seguida temos o script "/etc/openvpn/bridge-stop", responsável por desativar o bridge. Diferente do primeiro, os parâmetros são fixos, mudando apenas em configurações especiais:
#!/bin/bash
# /etc/openvpn/bridge-stop
br="br0"
tap="tap0"
ifconfig $br down
brctl delbr $br
for t in $tap; do
openvpn --rmtun --dev $t
done
Depois de criar os dois scripts, transforme-os em executáveis usando o comando "chmod +x", como em:
# chmod +x /etc/openvpn/bridge-start
# chmod +x /etc/openvpn/bridge-stop
Em seguida, temos as mudanças na configuração do servidor. A primeira mudança é que o bridge utiliza a interface "tap" em vez da "tun" (o tap transmite pacotes de broadcast e o tun não), por isso substituímos a linha "dev tun" por "dev tap0".
A linha "server 10.0.0.0 255.255.255.0" dos exemplos anteriores deixa de ser usada, dando lugar ao parâmetro "server-bridge", que contém um conjunto mais extenso de parâmetros:
server-bridge 192.168.1.101 255.255.255.0 192.168.1.210 192.168.1.220
O primeiro parâmetro (192.168.1.101) inclui o endereço IP do servidor, seguido pela máscara. Os dois endereços seguintes (192.168.1.210 192.168.1.220) especificam uma faixa de endereços que será fornecida aos clientes remotos. Diferente dos exemplos anteriores, usamos uma faixa de endereços dentro da faixa usada na rede local, por isso é importante que você reserve uma faixa de endereços que não seja usada por outros micros da rede e que esteja fora da faixa de endereços fornecidos pelo servidor DHCP.
A linha 'push "route 192.168.1.0 255.255.255.0"' (que define a regra de roteamento que permite aos clientes remotos acessarem a rede local) também deixa de ser usada, já que com o bridge eles passam a ter acesso direto à rede, sem necessidade deu usar roteamento.
Aqui temos um exemplo de arquivo de configuração completo para o servidor:
proto udp
port 22223
dev tap0
server-bridge 192.168.1.254 255.255.255.0 192.168.1.210 192.168.1.220
comp-lzo
keepalive 10 120
ifconfig-pool-persist /etc/openvpn/ipp.txt
tls-server
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
Na configuração dos clientes, a única mudança é a substituição da linha "dev tun" por "dev tap" (note que, diferente do servidor, usamos "dev tap" e não "dev tap0"). Temos aqui um exemplo de configuração completo. Veja que continuamos usando a linha "pull", que faz com que o cliente obtenha a configuração de rede a partir do servidor:
remote guiadohardware.no-ip.org
proto udp
port 22223
client
pull
dev tap
comp-lzo
keepalive 10 120
tls-client
dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/cliente2.crt
key /etc/openvpn/keys/cliente2.key
ns-cert-type server
Depois de ajustada a configuração, falta apenas ativar o bridge. Para isso, desativamos o serviço do OpenVPN, executamos o script que ativa o bridge e, por último, ativamos novamente o serviço do OpenVPN:
# /etc/init.d/openvpn stop
# chmod +x /etc/openvpn/bridge-start
# /etc/init.d/openvpn start
Se você estiver acessando o servidor remotamente, vai perceber que ele ficará alguns segundos sem responder. Isso acontece por que o sistema precisa "aprender" os endereços dos hosts ligados a cada uma das interfaces que compõe o bridge. Entretanto, se ele não voltar depois de uns 30 segundos, é provável que você deixou algum parâmetro incorreto na configuração, que acabou desconectando o servidor da rede. Nesse caso você vai precisar reiniciar o servidor, ou se logar localmente nele para ver o que deu errado.
Depois de ativado o bridge, o servidor ficará com três interfaces de rede. A interface "eth0" ficará sem endereço definido, assim como a interface "tap0", usada pela VPN. Uma terceira interface, a "br0" ficará com a configuração da rede, substituindo ambas. Isso acontece por que a "br0" é justamente a interface virtual do bridge, que combina o tráfego da rede local e da VPN, fazendo com que todos os dados que chegam em uma, sejam retransmitidos na outra.
Ao usar o bridge, não é usado o roteamento de pacotes, por isso não é necessário rodar o comando "echo 1 > /proc/sys/net/ipv4/ip_forward" no servidor, nem nenhum comando adicional no cliente. O sistema simplesmente passa a escutar as duas interfaces e encaminhar todo o tráfego de uma interface para a outra, tratando as duas interfaces como se fossem uma só.
No cliente a configuração é mais simples, você precisa apenas reiniciar o serviço do OpenVPN para que a alteração na configuração entre em vigor e a VPN seja restabelecida:
# /etc/init.d/openvpn restart
Uma vez que o cliente remoto se conecta à bridge, será criada a interface "tap0", utilizando um dos endereços da faixa definida na configuração do servidor, como em "192.168.1.220". Rodando o comando "route" (no cliente), você verá que o sistema automaticamente incluiu uma rota, associando a interface tap à rede "192.168.1.0".
A partir daí, o cliente pode acessar normalmente todos os demais micros da rede local, incluindo outros clientes remotos, e também ser acessado por eles. A única grande limitação é a velocidade do link. Você perceberá que ao utilizar a VPN através de uma conexão discada ou outro link lento, o acesso a compartilhamentos de arquivos e outros recursos ficará realmente muito lento.
Outra dica é que pode demorar alguns minutos até que outros micros da rede tenham acesso ao cliente, pois o sistema precisa receber conexões dos endereços antes de colocá-los na tabela. É normal que você não consiga acessar um cliente que acabou de se conectar à rede (o bridge ainda não aprendeu sobre ele) e consiga se conectar normalmente alguns minutos depois. Veja só:
$ ssh 192.168.1.210
ssh: connect to host 192.168.1.210 port 22: No route to host
$ ssh root@192.168.1.210 # (dois minutos depois)
The authenticity of host '192.168.1.210 (192.168.1.210)' can't be established.
RSA key fingerprint is ba:73:11:cd:e5:c5:c2:08:46:6e:d8:c4:02:f8:62:90.
Are you sure you want to continue connecting (yes/no)?
Se você tiver muitos micros com o Windows 95/98/ME na rede, o desempenho da VPN também será bastante penalizado pelo tráfego do protocolo NetBIOS (o compartilhamento de arquivos e impressoras). A melhor solução para minimizar o problema é configurar o servidor de arquivos da rede como servidor WINS e configurar todos os clientes para utilizá-lo.
O uso do servidor WINS é também a solução se você quiser que os clientes remotos tenham acesso aos compartilhamentos com a VPN utilizando interfaces tun, onde o tráfego é roteado.
Depois de testar a conexão, você pode automatizar a execução dos scripts para ativar e desativar o bridge adicionando as duas linhas abaixo ao arquivo de configuração do servidor:
up /etc/openvpn/bridge-start
down /etc/openvpn/bridge-stop
Com isso, o bridge passa a ser ativado automaticamente durante o carregamento do OpenVPN, sem que você precise executar comandos adicionais.
Usando esta configuração, o bridge deve ser ativado automaticamente durante a inicialização do servidor e (se você está mantendo o serviço do OpenVPN ativo nos clientes, em vez de conectar manualmente) eles devem se conectar à VPN automaticamente assim que alguma conexão estiver disponível.
Como todo o tráfego da VPN é encriptado e os certificados privados não são transmitidos durante o estabelecimento da conexão, você pode usar a VPN sem medo, mesmo ao acessar através de redes inseguras, como redes wireless públicas ou redes de terceiros.
CRÉDITOS/AUTORIA: Carlos E. Morimoto EM 04/04/2008
[TUTORIAL] Criando VPN Básica com OpenVPN - PARTE 01
Postador por Tiago Damasceno
Utilizando o OpenVPN venho disposnibilizar um tutorial ensinando como se configurar uma VPN básica em sua primeira parte, logo em seguida em outro post, disponibilizarei a configuração da mesma em modo avançado
Então vamos lá!!!
Uma VPN (Virtual Private Network, ou rede virtual privada) é, como o nome sugere, uma rede virtual, criada para interligar duas redes distantes, através da Internet. Você pode até mesmo imprimir em impressoras da rede remota, da mesma forma que faria com uma impressora local. Nesse tutorial aprenderemos criar VPNs usando o OpenVPN. Além de ser mais simples de configurar que a maioria das outras soluções de VPN e ser bastante seguro e flexível, ele possui versões Linux e Windows, o que permite criar túneis interligando máquinas rodando os dois sistemas sem grandes dificuldades.
Uma VPN (Virtual Private Network, ou rede virtual privada) é, como o nome sugere, uma rede virtual, criada para interligar duas redes distantes, através da Internet. Usar uma VPN permite que você compartilhe arquivos e use aplicativos de produtividade e de gerenciamento, como se todos os micros estivessem conectados à mesma rede local. Você pode até mesmo imprimir em impressoras da rede remota, da mesma forma que faria com uma impressora local.
Antigamente, a única forma de interligar redes em dois locais diferentes era usar linhas de frame-relay. Para quem não é dessa época, uma linha de frame-relay oferece um link dedicado de 64 kbits entre dois pontos (a matriz e a filial de uma empresa, por exemplo), com um custo mensal fixo. Você pode combinar várias linhas frame-relay em uma única conexão, de acordo com a necessidade, o problema nesse caso é o preço. Atualmente existem outras opções de conexões dedicadas e de conexões de alta disponibilidade, oferecidas pelas operadoras, mas elas ficam fora do orçamento da maioria das pequenas e médias empresas.
Usando uma VPN, você pode obter todos os benefícios de ter uma conexão dedicada entre dois pontos usando conexões via ADSL ou cabo, que são muito mais baratas. Dependendo do volume de uso da rede, você pode tanto utilizar a conexão que já tem, quanto utilizar uma segunda conexão apenas para a VPN. Além de interligar duas ou mais redes, a VPN pode (dependendo da configuração) ser acessada também por funcionários trabalhando remotamente.
Todos dados que trafegam através da VPN são encriptados, o que elimina o risco inerente à transmissão via Internet. Naturalmente, nenhuma VPN pode ser considerada "100% segura", já que sempre existe um pequeno risco de alguém conseguir obter acesso aos servidores, de forma a roubar as chaves de encriptação (por exemplo), mas, em uma VPN bem configurada o risco é realmente muito pequeno. É muito mais provável que um funcionário descontente sabote a rede interna, ou envie informações sigilosas para fora, do que algum invasor consiga efetivamente obter acesso à rede via Internet.
Nesse tópico estudaremos como criar VPNs usando o OpenVPN. Além de ser mais simples de configurar que a maioria das outras soluções de VPN e ser bastante seguro e flexível, ele possui versões Linux e Windows, o que permite criar túneis interligando máquinas rodando os dois sistemas sem grandes dificuldades.
Outras vantagens são que ele pode ser usado por clientes conectando através de uma conexão compartilhada via NAT (apenas o servidor precisa de portas abertas) e a boa tolerância contra conexões ruins, ou ao uso de conexões com IP dinâmico. A VPN pode ser configurada para ser restabelecida de forma automática em caso de interrupção na conexão, o que torna o link bastante confiável.
O OpenVPN pode ser configurado para utilizar chaves estáticas, que oferecem um nível mediano de segurança, em troca de uma configuração mais simples, ou para utilizar certificados X509, onde a configuração é um pouco mais complexa, mas em compensação a segurança é muito maior (bem superior à da maioria das soluções comerciais). Isso permite que você escolha a melhor relação entre praticidade e segurança de acordo com a situação.
Instalando
No final da instalação ele exibirá uma mensagem, perguntando se o OpenVPN deve ser desativado antes de ser atualizado ("Would you like to stop openvpn before it gets upgraded?"). Responda que sim.
No OpenSuSE, abra o Yast e, dentro da seção de gerenciamento de pacotes, faça uma busca pelo pacote "openvpn". A busca resulta em dois resultados "openvpn", que é o pacote em que estamos interessados e "openvpn-devel", que contém o código fonte. Basta selecionar o pacote e concluir a instalação.
No Fedora, a instalação pode ser feita usando o yum. Ele se encarregará de instalar também os pacotes "openssl" e "lzo", que contém as bibliotecas usadas pelo OpenVPN para encriptar e compactar o tráfego da rede:
No CentOS é necessário adicionar o repositório do RPMForge já que (até o CentOS 5.1), o pacote OpenVPN não faz parte dos repositórios oficiais. Você pode adicionar o repositório seguindo as instruções disponíveis aqui: http://wiki.centos.org/Repositories/RPMForge.
O primeiro passo é instalar a chave GPG do repositório:
Com a chave instalada, baixe o pacote RPM do repositório. Este pacote instala o arquivo com a configuração do repositório dentro da pasta "/etc/yum/repos.d". Verifique o link do pacote para a versão do CentOS que está utilizando na página com as instruções. No caso do CentOS 5.1, versão 32 bits, por exemplo, o pacote é o "rpmforge-release-0.3.6-1.el5.rf.i386.rpm". Se você está fazendo a configuração via linha de comando, pode baixar o pacote usando o wget, como em:
Em seguida, instale o pacote usando o comando "yum localinstall", como em:
A partir daí, você pode instalar o pacote do OpenVPN usando o yum, assim como no Fedora:
No Mandriva, basta instalar o pacote "openvpn" usando urpmi. Assim como no Fedora, ele também se encarrega de instalar as dependências:
Se você estiver utilizando uma distribuição que não inclua o pacote nos repositórios, ou se a versão disponível for muito antiga, você pode também instalar a partir do pacote com o código fonte, disponível no: http://openvpn.net/index.php/downloads.html
Depois de instalar o pacote, o próximo passo é carregar o módulo tun do Kernel, que é utilizado pelo OpenVPN para criar interfaces virtuais. Cada VPN criada se comporta como se fosse uma nova interface de rede, conectada à rede de destino. Imagine que a VPN se comporta como se existisse um cabo de rede gigante ligando esta interface virtual à rede do outro lado do túnel.
Adicione a linha "tun" no final do arquivo "/etc/modules" para que o módulo passe a ser carregado automaticamente durante o boot:
Estes três passos, ou seja, a instalação do OpenVPN, o carregamento do módulo e a adição da linha no final do arquivo devem ser executados tanto no servidor quanto nos clientes.
Depois de concluída a instalação, você pode criar um túnel simples, não encriptado, usando os comandos abaixo. Este túnel não pode ser considerado uma "VPN" já que não é seguro, mas serve como um "hello word" dentro da configuração do OpenVPN.
Presumindo que as duas máquinas estejam ligadas em rede e não exista nenhum firewall no caminho, use o comando abaixo no cliente, especificando o endereço do servidor:
Faça o mesmo no servidor, especificando agora o endereço do cliente:
Rode o comando "ifconfig" no cliente e você verá que foi criada uma interface de rede virtual, a "tun0", com o endereço "10.0.0.1":
No exemplo, o servidor recebe o endereço "10.0.0.2". Você pode testar a conectividade usando o ping ou qualquer outra ferramenta:
Como comentei, o OpenVPN possui também uma versão Windows, que está disponível no http://openvpn.se.
Esta versão inclui um instalador gráfico e funciona em todas as versões do Windows a partir do Windows 2000. Ela inclui também o driver tun/tap, que é instalado automaticamente, você precisa apenas prestar atenção nas mensagens de instalação. Em um certo ponto, será exibida uma mensagem avisando que o driver TAP/Win32 não passou pelo processo de certificação de compatibilidade com o Windows. Responda "Continuar assim mesmo" para efetuar a instalação, do contrário o OpenVPN não funcionará.
O processo de certificação dos drivers para o Windows é um processo caro e demorado, onde os fabricantes de componentes submetem os drivers de dispositivo à Microsoft para que eles sejam certificados. Este é um processo que não está ao alcance de projetos independentes, como o OpenVPN, daí a exibição da mensagem.
De qualquer forma, isso não significa que o software seja instável ou inseguro, muito pelo contrário. Se a certificação da Microsoft fosse um indicador de qualidade, softwares como o IIS e o IE não teriam tantas falhas e brechas de segurança.
Criando VPNs usando chaves estáticas
Nesse modo, você gera uma arquivo de texto no servidor, contendo a chave de encriptação e precisa apenas copiá-la para o cliente e fazer uma configuração rápida para criar a VPN. Se você quer apenas criar uma VPN doméstica, ou criar uma VPN temporária entre duas redes, esta é a configuração recomendada.
O grande problema em utilizar uma chave estática é que, como o nome sugere, a mesma chave é utilizada sessão após sessão, sem nunca mudar. Com isso, existe uma pequena possibilidade um atacante obstinado conseguir quebrar a VPN usando um ataque de força bruta. Como a chave é um arquivo de texto, que é armazenado tanto no cliente quanto no servidor, existe também a possibilidade de alguém conseguir copiá-lo, caso tenha acesso físico a uma das máquinas. Outra limitação é que usando uma chave estática o servidor suportará a conexão de um único cliente por VPN.
Para VPNs com vários clientes, ou em redes empresariais, onde a segurança é prioridade, é recomendável utilizar uma estrutura baseada em certificados X509, como veremos no tópico seguinte.
Vamos então à configuração de nossa primeira VPN. Para este exercício inicial, recomendo que utilize duas máquinas da rede local, que não tenham firewall ativo. Depois de entender melhor como o sistema funciona, passaremos para uma configuração mais elaborada.
O primeiro passo é gerar o arquivo com a chave, no servidor. O arquivo deve ser gerada dentro do diretório "/etc/openvpn" (o diretório padrão de configuração), de forma que acessamos o diretório antes de executar o comando que gera a chave:
# openvpn --genkey --secret static.key
Isso gerará o arquivo "static.key", que contém a chave de encriptação que será usada para criar a conexão. Ele é um arquivo de texto simples, que contém uma chave de 2048 bits, como em:
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
0600d007988a59c6f7895884d336d445
2679fd3d2c0b9e0b777b4da92ab97043
... (mais 13 linhas)
e871ed9077185a2a6904e67cd0869e15
-----END OpenVPN Static key V1-----
Este arquivo deve ser copiado para a pasta "/etc/openvpn" do cliente, usando (por exemplo) o SFTP. Você pode usar também um pendrive, ou outra mídia de uso local, mas não é recomendável enviá-lo por meios não seguros (e-mail por exemplo), já que qualquer um que tenha acesso ao arquivo, poderá se conectar à sua VPN ou desencriptar todo o tráfego transmitido através dela.
Para acessar o servidor (a partir do cliente) via SFTP, use o comando "sftp ip" para se conectar e em seguida use os comandos "cd /etc/openvpn" e "get static.key" para fazer a cópia, como em:
# cd /etc/openvpn
# sftp root@192.168.1.101
sftp> get static.key
Com o arquivo contendo a chave presente nas duas máquinas, falta criar os arquivos de configuração que serão usados pelo OpenVPN. Neste exemplo, criarei o arquivo "/etc/openvpn/server.conf" no servidor e o arquivo "/etc/openvpn/client.conf" no cliente. Os nomes podem ser diferentes, mas os arquivos devem ser criados dentro da pasta "/etc/openvpn" e devem terminar com a extensão ".conf"
O arquivo "/etc/openvpn/server.conf", no servidor, fica com o seguinte conteúdo:
ifconfig 10.0.0.1 10.0.0.2
secret static.key
A linha "ifconfig 10.0.0.1 10.0.0.2" inclui os endereços que serão usados pelas interfaces virtuais da VPN, no servidor e no cliente. No exemplo o servidor utilizará o endereço "10.0.0.1" e o cliente o endereço "10.0.0.2". Você pode utilizar outros endereços se preferir. O importante é que os endereços utilizados na VPN devem ser sempre diferentes dos endereços usados na rede local.
A linha "secret static.key" especifica o arquivo com a chave de encriptação, que criamos no passo anterior. Não esqueça de alterar a linha caso o nome do arquivo seja diferente.
Em seguida vem o arquivo "/etc/openvpn/client.conf", que deve ser criado no cliente:
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret static.key
A primeira linha especifica o endereço IP do servidor. No exemplo estou utilizando um endereço de rede local, já que estamos apenas testando a VPN, mas em um exemplo real de uso você utilizaria o endereço IP de Internet do servidor ou (ao utilizar uma conexão com IP dinâmico) um domínio virtual utilizado por ele. Se você ainda não tem um, acesse o no-ip.com ou o dyndns.org e faça o registro.
Com os arquivos de configuração criados, inicializar a VPN é incrivelmente simples. Você precisa apenas reiniciar o serviço "openvpn" tanto no cliente quanto no servidor, usando o comando:
Ao ser iniciado, o serviço procura por arquivos ".conf" dentro do diretório "/etc/openvpn" e inicia as VPNs configuradas automaticamente. Isso não apenas simplifica a configuração, mas faz com que a VPN passe a ser automaticamente restabelecida a cada boot. Para desativá-la, basta parar o serviço:
Você pode também ativar o OpenVPN manualmente, usando (como root) o comando:
(onde o "client.conf" é o arquivo de configuração que será usado)
Este comando manual permite acompanhar as mensagens de inicialização e de conexão, o que ajuda a descobrir o que está errado em casos em que a VPN não funciona, embora a configuração pareça estar correta.
Se a VPN é usada pelos clientes apenas esporadicamente, você pode criar um ícone no desktop, ou um pequeno script contendo o comando, para que o usuário possa se conectar à VPN apenas quando precisar. Outra opção é instalar o kvpnc (http://home.gna.org/kvpnc/), um cliente gráfico que pode ser usado para se conectar a VPNs baseadas em diversos protocolos, incluindo o OpenVPN:
Depois de estabelecida a VPN, o cliente passará a ter uma nova interface de rede, a "tun0", com o endereço IP "10.0.0.2", que funciona como um link ponto-a-ponto com a interface "tun0" no servidor, que recebe o endereço "10.0.0.1". Teste a conexão usando o ping, ou acessando algum serviço disponível no servidor, como em:
Depois do teste inicial, você pode fazer um teste realizando a conexão via Internet (você pode usar uma conexão discada ou outra conexão temporária no cliente para fazer o teste).
Para isso, você vai precisar apenas alterar a configuração no cliente, adicionando o endereço de internet do servidor, como em:
dev tun
ifconfig 10.0.0.2 10.0.0.1
secret static.key
Não se esqueça de reiniciar o OpenVPN para que a alteração entre em vigor:
Portas
Diferente de outras soluções de VPN, o OpenVPN utiliza uma única porta de entrada, mesmo que sejam utilizadas várias VPNs simultaneamente. Isso facilita bastante a configuração do firewall ou do roteamento de portas no servidor.No OpenVPN 2.x é utilizada por padrão a porta 1194 UDP que, deve estar aberta no firewall do servidor (versões antigas, anteriores à 2.0-beta16 utilizavam a porta 5000 UDP). Se o servidor acessa através de uma conexão compartilhada, é necessário configurar o gateway da rede (ou o modem ADSL) para encaminhar a porta para ele.
Como de praxe, é possível alterar a porta padrão usada pelo OpenVPN, desde que você especifique a nova porta tanto na configuração do servidor quanto do cliente. Para isso, usamos a opção "proto udp", seguida pela porta desejada, que deve ser incluída tanto na configuração do servidor quanto na do cliente, como em:
port 22222
É possível também usar uma porta TCP. Nesse caso, usamos a opção "proto tcp-server" na configuração do servidor e a opção "proto tcp-client" na configuração do cliente, como em:
port 22222
e:
port 22222
O grande problema em utilizar o TCP no OpenVPN é que o desempenho da VPN será perceptivelmente pior do que se utilizada uma porta UDP.
Isso ocorre porque no UDP os pacotes são transmitidos diretamente, sem nenhum overhead, o que garante o melhor desempenho. No UDP não existe correção de erros nem retransmissão de pacotes perdidos, mas isso não é um problema no caso do OpenVPN, pois ele é o responsável apenas pela criação do link de dados. Sobre ele temos o protocolo TCP/IP, e as diferentes camadas do sistema operacional, que se encarregam dessa tarefa.
Ao utilizar uma porta TCP, o próprio OpenVPN é obrigado a fazer a checagem e a retransmissão de pacotes, respeitando o modo de funcionamento do protocolo. Isso aumenta bastante a latência da conexão e faz com que cada vez que um pacote é perdido, o OpenVPN precise parar a transmissão de todos os pacotes subsequentes até que a retransmissão seja feita. Quanto maior for o volume de dados que trafegam pela VPN, mais desvantajoso é o uso do TCP no caso do OpenVPN, de forma que é mais recomendável utilizar uma porta UDP sempre que possível.
Estabilizando e otimizando a conexão
Usando a configuração simplificada do exemplo anterior, você notará que a VPN não será muito estável, pois qualquer interrupção na comunicação entre as duas máquinas derrubará o link, até que você reinicie o serviço do OpenVPN (no cliente), forçando a reconexão, como em:
Vamos então a um conjunto de parâmetros de configuração que permitem estabilizar a VPN, fazendo com que o OpenVPN passe a monitorar a conexão e restabelecê-la automaticamente sempre que necessário.
O primeiro, e mais importante, é o parâmetro "keepalive", que faz com que o servidor e o cliente monitorem a conexão, enviando pings periódicos um para o outro e reiniciem a VPN automaticamente caso não recebam resposta dentro de um período determinado. Esta opção é especialmente importante em VPNs usadas através de links ADSL ou qualquer outro tipo de conexão que não seja completamente estável. Um exemplo de uso seria:
O primeiro número especifica o intervalo dos pings e o segundo o timeout, depois do qual a VPN é reiniciada. Nesse caso, o ping é enviado a cada 10 segundos sem atividade e a VPN é reiniciada depois de 120 segundos sem respostas. Caso o link seja interrompido, o cliente tenta restabelecer a VPN periodicamente, até que tenha sucesso. Esta linha deve ser incluída tanto na configuração do servidor quanto na do cliente.
Opcionalmente, você pode incluir a linha "inactive", para especificar um tempo máximo para as tentativas de reconexão. Se quiser que o cliente desista depois de uma hora, por exemplo, inclua a linha:
O parâmetro "comp-lzo" faz com que o OpenVPN passe a compactar os dados transmitidos através do túnel (é necessário que o pacote "lzo" esteja instalado). O algoritmo usado pelo OpenVPN é bastante leve, por isso o uso adicional de processamento, tanto no servidor quando nos clientes é pequeno. A compressão dos dados não faz milagres, mas é uma boa forma de melhorar o desempenho da VPN ao utilizar links lentos ou congestionados. Esta é outra opção que deve ser incluída tanto no servidor quanto nos clientes para que seja usada:
Outras duas opções úteis para tornar a VPN mais confiável e mais resistente a problemas de conectividade são a "persistkey" e a "persisttun". Elas fazem com que o daemon mantenha a interface tun aberta e as chaves carregadas quando é reiniciado (quando a VPN é restabelecida depois de uma queda de conexão, por exemplo), o que torna mais rápida a restauração do link e evita problemas diversos:
persisttun
Outra opção útil ao utilizar conexões com IP dinâmico é a opção "float", que permite que o túnel continue aberto mesmo que o endereço IP da outra máquina mude. Em situações normais, a mudança de IP faria com que a conexão fosse encerrada e o túnel fosse interrompido até que fosse reiniciado (seja manualmente ou seja pelo uso da opção keepalive). A opção "float" torna o processo mais transparente, já que o OpenVPN passa a monitorar as mudança de endereços, mantendo o túnel aberto enquanto houver conexão entre as duas partes. Essa opção também deve ser incluída tanto na configuração do servidor quanto na do cliente:
Temos aqui um exemplo mais incrementado de configuração do servidor, onde a porta é especificada manualmente e são usados os parâmetros que acabamos de ver:
proto udp
port 22222
keepalive 10 120
comp-lzo
persistkey
persisttun
float
ifconfig 10.0.0.1 10.0.0.2
secret static.key
A configuração no cliente é praticamente a mesma, com a adição da linha "remote", que especifica o endereço do servidor e da mudança na linha "ifconfig", onde a ordem dos endereços são trocados:
dev tun
proto udp
port 22222
keepalive 10 120
comp-lzo
persistkey
persisttun
float
ifconfig 10.0.0.1 10.0.0.2
secret static.key
Roteando os pacotes
Originalmente, o cliente terá acesso apenas ao próprio servidor. Para que ele tenha acesso aos demais hosts da rede, é necessário realizar mais alguns passos adicionais.O primeiro é ativar o roteamento de pacotes no servidor, de forma que ele passe a encaminhar os pacotes recebidos do cliente para a interface de rede local. Mesmo que o servidor possua uma única placa de rede, a VPN é vista pelo sistema como uma interface separada, de forma que, do ponto de vista do sistema operacional, a VPN e a rede local são duas placas de rede separadas.
O roteamento é feito usando dois comandos (executados no servidor):
# iptables -t nat -s 10.0.0.2 -A POSTROUTING -o eth0 -j MASQUERADE
O primeiro ativa o roteamento de pacotes no Kernel e o segundo orienta o sistema a encaminhar os pacotes recebidos a partir do endereço IP do cliente (10.0.0.2, no exemplo) para a interface de rede local (eth0, no exemplo). Estes dois comandos precisam ser adicionados em algum dos scripts de inicialização do sistema para que sejam executados a cada boot.
O próximo passo é executar o comando abaixo no cliente, de forma que ele passe a consultar o servidor ao tentar acessar endereços dentro da faixa usada pela rede local:
Note que o comando especifica a faixa de endereços usada na rede local (192.168.1.0, no exemplo), a máscara, o endereço IP do servidor, do outro lado da VPN e a interface virtual usada pela VPN (tap0).
A partir daí o cliente conseguirá acessar outros micros da rede, montar compartilhamentos ou até mesmo imprimir em impressoras compartilhadas. É importante notar, entretanto, que se o cliente também estiver conectado a uma rede local (acessando através de uma conexão compartilhada, por exemplo), ela deve utilizar uma faixa de endereços diferentes.
Configuração no Windows
A configuração da versão Windows do OpenVPN é bastante similar à da versão Linux, com exceção de alguns detalhes e algumas adaptações feitas devido às diferenças entre os dois sistemas. Depois de baixar o pacote no http://opnvpn.se e instalar o programa, acesse a opção "OpenVPN configuration file directory", dentro da pasta "OpenVPN" que será criada no iniciar:
O atalho leva à pasta "config" dentro do diretório de instalação do programa, onde irão a chave de encriptação e o arquivo de configuração, de forma similar à pasta "/etc/openvpn" que temos no Linux.
Se você pretende usar a máquina Windows como servidor, pode usar a opção "Generate a static OpenVPN key", usando o atalho dentro do menu iniciar. Isso gerará um arquivo "key.txt" dentro do diretório de configuração, que precisa então ser copiado para o cliente.
Se, por outro lado, você quer usar a máquina Windows para se conectar a um servidor Linux, comece copiando o arquivo "static.key" do servidor para dentro da pasta de configuração:
É necessário criar também um arquivo de configuração, com a extensão "ovpn" (usando o bloco de notas), onde são especificadas as opções de configuração. O conteúdo do arquivo é exatamente o mesmo que usaríamos em um cliente Linux:
Depois de copiar a chave e gerar o arquivo de configuração, clique com o botão direito sobre ele e use a opção "Start OpenVPN on this config file" para ativar a VPN:
Isso abrirá uma janela do prompt do MS-DOS mostrando o progresso da conexão:
Assim como no Linux, a VPN aparece como uma nova interface de rede, que recebe o endereço IP definido na configuração:
Depois de testar a conexão, é possível fazer com que ela seja inicializada automaticamente ativando o serviço do OpenVPN, que passa então a monitorar o diretório de configuração, carregando automaticamente os arquivos de configuração colocados dentro dele, assim como no Linux.
Para isso, acesse o "Painel de Controle > Ferramentas Administrativas > Serviços" e mude a configuração do "OpenVPN Service" de "Manual" para "Automático":
CRÉDITOS/AUTORIA: Carlos E. Morimoto EM 04/04/2008
Comodo EasyVPN Beta
Postador por Tiago Damasceno
O EasyVPN é uma rede virtual privada (VPN) peer-to-peer e um cliente de mensagens instantâneas capaz de estabelecer conexões VPN direta e segura entre computadores, simulando uma rede local através da Internet. O EasyVPN funciona em uma ampla variedade de redes e configurações, mesmo aquelas por trás de Network Address Translations (NAT).
LEI MAIS PARA SABER MAIS!!!
Ele vem completo, com um mensageiro instantâneo e controle remoto do desktop, que permite aos usuários enviar e receber mensagens instantâneas, incluindo arquivos criptografados e acessar a outros computadores.
A versão beta do EasyVPN foi lançada na semana passada no fórum da Comodo e agora está disponível para download público.
EasyVPN - x86
EasyVPN - x64
Apostila: Métodos de Proteção da Rede Wireless
Postador por Tiago Damasceno
Excelente apostila, Métodos de Proteção da Rede Wireless, veja em leia mais o conteúdo:
* Protocolos Utilizados
* Riscos e Vulnerabilidades
* Segurança Física
* Configurações de Fábrica
* Localização de Pontos de Acesso
* Mapeamento
* Mapeamento Passivo
* Mapeamento Ativo
* Geração de Mapas
* Vulnerabilidades de Protocolos
* WEP
* WPA
* Problemas com Redes Mistas
* Tipos de Ataque
* Escuta de Tráfego
* Endereçamento MAC
* Homem-do-Meio (man-in-the-middle)
* Quebras de Chaves WEP
* Negação de Serviço (DoS - Denial of Service)
* Proposta de implementação de uma Rede Sem fio Segura
* CONSIDERAÇÕES FINAIS
* Conclusão
* E muito mais…
* Tamanho: 1.3 MB
* Idioma: Português
* Formato: PDF
* Páginas: 65
DOWNLOAD MEDIAFIRE
DOWNLOAD DIRETO
DOWNLOAD RAPIDSHARE
