7
CENTRO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA INSTITUTO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA ADMINISTRAÇÃO E SEGURANÇA DE REDES VPN e Firewall Mauro César de Farias Marinho 2008

Relatório - VPN e Firewall

Embed Size (px)

DESCRIPTION

Introdução sobre VPN e Firewall.Laboratório de Administração e Segurança de Redes.

Citation preview

Page 1: Relatório - VPN e Firewall

CENTRO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA INSTITUTO DE EDUCAÇÃO SUPERIOR DE BRASÍLIA

ADMINISTRAÇÃO E SEGURANÇA DE REDES

VPN e Firewall

 

 

 

 

 

 

 

 

 

 

 

Mauro César de Farias Marinho 

 

 

2008 

Page 2: Relatório - VPN e Firewall

1. Introdução O objetivo deste laboratório é configurar um Firewall e uma rede

VPN com IPSec.

O Firewall, fisicamente posicionado na borda da rede privada ou

até em mais setores considerados críticos dessa rede, é responsável por

autorizar ou barrar a passagem de pacotes de dados tanto de dentro

para fora, como de fora para dentro da rede que se quer proteger.

Regras são configuradas de forma a permitir comunicação apenas para

os serviços necessários e, por fim, barrar os demais. Pode estar

presente em equipamentos de rede como roteadores ou em hosts em

softwares.

Uma VPN ou RPV, como o nome já diz, é uma Rede Privativa

Virtual. Ela simula acessos locais entre sub-redes privadas fisicamente

separadas, utilizando para isso, redes públicas, ou seja, a internet.

Utilizando-se de criptografia em uma ou mais camadas OSI,

dependendo no nível de segurança desejado.

 

Page 3: Relatório - VPN e Firewall

2. Procedimentos Experimentais 

Utilizamos os hosts A(10.10.16.40) e B(10.10.16.14) para execução do roteiro, sendo o A o que sofreu as configurações no firewall.

a) IPTables

1. Verificamos com sucesso a comunicação entre os hosts A e B com o comando ‘ping’ de A para B, vice-versa.

No Host A ping 10.10.16.14

No Host B ping 10.10.16.40

2. No Host A, Executamos o comando “iptables -A INPUT -p icmp -j DROP -s 0.0.0.0/0” que barra qualquer tentativa de comunicação que utiliza o protocolo ICMP, como o ping.

3. Então, para verificar se o firewall de A estava funcionando corretamente, aplicamos um ping para o host A através do host B.

Host B ping 10.10.16.40

Como queríamos, o comando falhou. A não respondeu B. Verificamos com sucesso as regras do firewall de A com o comando “iptables –nL”.

4. Seguindo o roteiro, incluímos a regra para impedir conexões pela porta 113 com o comando “iptables -A INPUT -p tcp --dport 113 -j REJECT –reject-with tcp-reset”.

5. Aplicamos a regra de NAT à tabela do Host A com o comando “iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE”. E verificamos a criação da regra com o seguinte comando: “iptables –t nat –nL”.

6. Por fim, executamos os comando “iptables –F” e “iptables -t nat -F” para limpar as tabelas.

b) IPSec

Com os procedimentos abaixo, configuramos os 2 hosts para se comunicarem de forma segura, com o protocolo IPSec, que implementa criptografia para os pacotes destinados aos Hosts A e B.

1. Inicialmente verificamos a comunicação entre A e B com o comando ping com sucesso. Com o wireshark, capturamos o tráfego de A como referência para comparar com o tráfego a ser capturado quando configurada a rede VPN ou RPV.

2. Instalamos os pacotes ‘racoon’ e ‘ipsec-tools’ em ambos os hosts com o comando apt-get install raccon ipsec-tools.

3. Configuramos o IKE editando o arquivo em /etc/racoon/racoon.conf com o conteúdo abaixo:

Page 4: Relatório - VPN e Firewall

path pre_shared_key "/etc/racoon/psk.txt"; remote anonymous {

exchange_mode aggressive; my_identifier user_fqdn "[email protected]"; proposal {

encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2;

} } sainfo anonymous {

pfs_group 2; encryption_algorithm 3des, blowfish, des, rijndael; authentication_algorithm hmac_sha1, hmac_md5; compression_algorithm deflate;

}

4. Após reiniciado o serviço ‘racoon’, modificamos o SPD(Security Policy Database) para cada host alterando o arquivo /etc/ipsec-tools.conf.

Para o Host A:

spdadd 10.10.16.40 10.10.16.10 any -P in ipsec esp/transport//require spdadd 10.10.16.40 10.10.16.10 any -P out ipsec esp/transport//require

Para o Host B:

spdadd 10.10.16.10 10.10.16.40 any -P in ipsec esp/transport//require spdadd 10.10.16.10 10.10.16.40 any -P out ipsec esp/transport//require

5. Testamos a comunicação entre os hosts com sucesso e capturamos novamente o tráfego pelo wireshark para comparação.

Page 5: Relatório - VPN e Firewall

3. Resultados Obtidos e Análise de Dados a) IpTables

Detalhes do comando do item 4. Parâmetros utilizados:

• -A ou –append: referência de que o comando irá acrescentar uma nova regra no final de uma das tabelas pertencente à iptables.

• INPUT: Informa que a regra que será acrescentada servirá apenas para pacotes recebidos, excluindo os pacotes de saída.

• -p ou --protocol: Esse parâmetro informa a qual protocolo a regra será válida. Neste caso, o protocolo tcp.

• --dport ou --destination-port: Informa que a regra só será válida para a porta tcp do parâmetro. No caso, a porta 113. OBS: O argumento ‘--dports’ aceita várias portas separadas por vírgula, ao contrário do ‘--dport’ que só aceita uma.

• -j ou --jump: Informa uma ação a ser tomada caso validada a regra para algum pacote.

• REJECT: Utilizado para enviar uma mensagem de erro ao remetente com o a opção ‘--reject-with’. Possui os parâmetros ‘tipo’ para enviar uma msg específica. Neste caso tipo= tcp-reset.

O comando do item 5 acrescenta, no final da tabela ‘nat’, a regra de NAT(Network address Translation) para a interface eth0 para onde os pacotes serão enviados.

Para evitar o spoofing de IP utilizando o firewall, configure a sua rede para rejeitar pacotes de redes externas que declaram ser de um endereço local. O comando abaixo bloqueia o syn-flood, parte da estratégia de um atacante por IP spoofing.

"iptables ‐N syn‐flood” 

E para barrar todo o tráfego (última regra).

“iptables ‐A INPUT ‐j DROP”

b) IPSec

Comparando os resultados do envio e recepção dos pacotes obtidos com o wireshark, notamos uma semelhança inesperada. Era aguardada a visualização dos pacotes cifrados do IPSec, que foram registrados, pelo sniffer, como pacotes comuns, ou seja, como se não tivéssemos criado uma VPN entre os Hosts A e B.

Page 6: Relatório - VPN e Firewall

Atribuímos isso possivelmente a decifração que poderia estar ocorrendo antes da captura do pacote pelo sniffer utilizado. Vale lembrar que o tcpdump também não capturou pacotes cifrados. Na pior das hipóteses a configuração da VPN não estava correta e por estarem na mesma sub-rede, se comunicavam sem utilizar a VPN.

Page 7: Relatório - VPN e Firewall

Conclusão 

a) Iptables – O firewall do Linux se mostrou robusto e adaptável a qualquer rede. Porém, de difícil manipulação, através de comandos dependentes de uma série de parâmetros em cada regra criada. Definitivamente uma tarefa que exige muita lógica e memória.

b) IPSec – A configuração do serviço racoon com os parâmetros passados não foi um problema. Porém, se descobriu que o laboratório liga seus computadores na rede através de um switch, aparelho que otimiza o envio de pacotes da rede, bloqueando à máquinas usuárias a visualização do tráfego.

O trabalho não tem imagens por descuido do grupo. Pois as imagens de printScreen das telas salvas durante a execução do roteiro, foram perdidas.

4. Referências Site: http://pt.wikipedia.org/wiki/ em 25 de Abril, as 16:50. Site: http://www.linuxmanpages.com/man8/iptables.8.php em 17 de Maio, as 16:00. Site:

http://www.linuxsecurity.com.br/biblioteca/out_frame.php?PHPSESSID=&ID=558 em 18 de Maio, as 16:00.