A feature uRPF compara o endereço IP de origem do cabeçalho IP com a tabela de rotas, com o objetivo de descartar pacotes que não possuem uma referência de rotas em determinada interface. Em resumo, o roteador só encaminhará o pacote, se o endereço IP de origem inserido no cabeçalho for acessível por aquela interface de entrada.
Lembrando que por padrão, no encaminhamento de pacotes, o roteador irá validar apenas o endereço de destino de um pacote IP.
O uRPF possui 2 modos distintos (strict e loose) que podem potencialmente ajudar a reduzir ataques com endereços IP falsificados.
Em um exemplo simples, é como se um roteador com uma interface com o endereço de LAN 192.168.1.0/24 receber um pacote com o endereço de origem 172.16.1.20. Esse endereço não faz parte da rede local.
Unicast RPF Strict Mode
O uRPF strict mode permitirá apenas os pacotes acessíveis por aquela interface.
No caso de rotas com custos iguais, o tráfego também será encaminhado.
O roteador irá validar os pacotes que estão entrando no roteador e validará com a FIB. Se o pacote é recebido pela interface e tem rota para o endereço de origem do cabeçalho (para aquela interface), o pacote será recebido e encaminhado.
O comando a ser aplicado em uma interface é “ip verify unicast source reachable-via rx”. No caso de roteamento assimétrico, o tráfego será descartado.
R1 # show ip int fa0/0 | i ^ [1-9]+ verification drops
8 verification drops
R1# show ip traffic | i unicast
0 no route, 8 unicast RPF, 0 forced drop
Unicast RPF Loose mode
O uRPF configurado como loose mode, bloqueará pacotes que não possuem a rede de origem na tabela de roteamento. Por exemplo, caso haja duas interfaces com rotas diferentes para a mesma rede e o pacote vir por uma porta que não é a rota preferida pelo roteador, o mesmo roteará o pacote.
O uRPF loose mode é bastante útil para roteadores que aprendem suas rotas dinamicamente via BGP, descartando endereços privados,como da RFC 1918.
O comando a ser aplicado em uma interface é ‘ip verify unicast source reachable-via any‘. No caso de roteamento assimétrico o tráfego será encaminhado.
R1(config-if)#ip verify unicast source reachable-via any
Rota default
Caso o endereço seja apenas conhecido via rota default, o uRPF continuará bloqueando os endereços. Para permitir os endereços a partir da rota default use o comando “ip verify unicast source reachable-via rx allow-default”
A utilização de VRFs (Virtual Routing and Forwarding) em Roteadores permite a criação de tabelas de roteamento virtuais que trabalham de forma independente da tabela de roteamento “normal”, protegendo os processos de roteamento de cada cliente de forma individual.
Empresas que prestam serviços de gerenciamento de rede ou monitoração, empresas que vendem serviços em Data Center e provedores de serviço utilizam largamente VRFs, otimizando assim a administração e o retorno financeiro no total do custo de um projeto.
A configuração de VRFs é bem simples. Já o Roteamento entre VRFs ocorre quando há a necessidade de comunicarmos diferentes tabelas de roteamento que estão segregadas por VRF, para compartilharem alguns ou todos os prefixos. Há diversas formas de configurarmos o roteamento entre VRFs, como por exemplo com a utilização de um cabo virado para o próprio roteador com as portas em diferente VRFs [apontando assim uma rota para nexthop da proxima VRF; ou com algum IGP] e também com a utilização de um outro roteador, etc; nesse post explicaremos o roteamento interVRF com o processo MPBGP que é a maneira mais escalável… preparados? Então vamos lá…
Habilitando o import e export das VRFs
Ao configurarmos o processo de roteamento entre VRFs em um mesmo roteador , dois valores de extrema importancia devem ser configurados na VRF: o RD (route distinguisher) e o RT (route target)
RD
Como explicado anteriormente, as VRFs permitem a reutilização de endereços IP em diferentes tabelas de roteamento. Por exemplo, suponha que você tenha que conectar a três diferentes clientes , os quais estão usando 192.168.1.0/24 em sua rede local. Podemos designar a cada cliente a sua própria VRF de modo que as redes sobrepostas são mantidas isoladas em suas VRFs .
O RD funciona mantendo o controle de quais rotas 192.168.1.0/24 pertencem a cada cliente como um diferenciador de rota (RD) para cada VRF. O route distinguisher é um número único adiciondo para cada rota dentro de uma VRF para identificá-lo como pertencente a essa VRF ou cliente particular. O valor do RD é carregado juntamente com uma rota através do processo MP- BGP quando o roteador troca rotas VPN com outros Roteadores PE.
O valor RD é de 64 bits e é sugerido a configuração do valor do RD como ASN::nn ou endereçoIP:nn. Mas apesar das sugestões, o valor é apenas representativo.
R1(config-vrf)#rd ?
ASN:nn or IP-address:nn VPN Route Distinguisher
! Configurando a VRF para os clientes A B e C
ip vrf Cliente_A
rd 65000:1
!
ip vrf Cliente_B
rd 65000:2
!
ip vrf Cliente_C
rd 65000:3
Quando rotas VPN são anunciados entre os roteadores PE via MP-BGP, o RD é incluído como parte da rota, juntamente com o prefixo IP. Por exemplo, uma via para 192.0.2.0/24 na VRF Cliente_B é anunciado como 65000:2:192.0.1.0 / 24.
RT Considerando que o valor do RD é utilizado para manter a exclusividade entre rotas idênticas em diferentes VRFs, o RT (route target)é utilizado para compartilhar rotas entre eles. Podemos aplicar o RT para uma VRF com o objetivo de controlar a importação e exportação de rotas entre ela e outras VRFs.
O route target assume a forma de uma comunidade BGP estendida com uma estrutura semelhante à de um RD (que é, provavelmente, porque os dois são tão facilmente confundidos). Segue abaixo um exemplo de configuração, onde o Cliente_A fará o roteamento entre VRFs com o Cliente_B, já o Cliente_C continuará com a sua VRF isolada dos outros clientes.
Segue abaixo a configuração das interfaces de cada VRF , e o processo MP-BGP responsável por funcionar o import/export de prefixos das VRFs.
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface Loopback1
ip vrf forwarding Cliente_A
ip address 1.1.1.1 255.255.255.0
!
interface Loopback2
ip vrf forwarding Cliente_B
ip address 2.2.2.2 255.255.255.0
!
interface Loopback3
ip vrf forwarding Cliente_C
ip address 3.3.3.3 255.255.255.0
!
router bgp 65000
no synchronization
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf Cliente_A
redistribute connected
no synchronization
exit-address-family
!
address-family ipv4 vrf Cliente_B
redistribute connected
no synchronization
exit-address-family
!
address-family ipv4 vrf Cliente_C
redistribute connected
no synchronization
exit-address-family
!
Segue abaixo os outputs das rotas aprendidas para o roteamento entre VRFs e o teste de ICMP
R1#show ip route vrf Cliente_A Gateway of last resort is not set 1.0.0.0/24 is subnetted, 1 subnets C 1.1.1.0 is directly connected, Loopback1 2.0.0.0/24 is subnetted, 1 subnets B 2.2.2.0 is directly connected, 00:08:22, Loopback2 R1#ping vrf Cliente_A 2.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
O Transport Layer Security, ou TLS, é um protocolo utilizado para fornecer privacidade e integridade de dados entre duas partes durante a comunicação pela Internet. É a tecnologia de segurança padrão para estabelecer um link criptografado entre um servidor web e um navegador/aplicação.
A criptografia Secured Socket Layer, ou SSL, foi desenvolvida pela Netscape em 1995 com o propósito de garantir privacidade, autenticação e integridade de dados nas comunicações pela Internet. Em 1999, a Internet Engineering Task Force (IETF) propôs uma atualização para SSL. Como esta atualização estava sendo desenvolvida pela IETF e a Netscape não estava mais envolvida, o nome foi alterado para TLS.
Em 2014, o SSL foi oficialmente considerado obsoleto devido à falta de atualizações e vulnerabilidades de segurança identificadas. A maioria dos navegadores modernos parou de oferecer suporte ao SSL, tornando-o incompatível com websites e serviços modernos. Os termos SSL e TLS agora são usados indistintamente quando se referem a esta tecnologia. O TLS, ou Transport Layer Security, funciona de maneira similar para proteger seus dados online. É como um protocolo de segurança que cria um túnel confidencial entre seu dispositivo e um site ou serviço. Através desse túnel, as informações trafegam de forma criptografada.
Como o TLS funciona?
O objetivo principal do TLS é a Autenticação e a Confidencialidade, mas ele também fornece Integridade para os dados.
Durante o processo de autenticação chamado handshake entre dois dispositivos em comunicação, o processo garante que ambos os dispositivos devam confirmar quem afirmam ser. Durante um handshake TLS, os dois lados em comunicação trocam mensagens para se reconhecerem, verificarem um ao outro, para então estabelecer os algoritmos de criptografia que usarão e assim concordar com as chaves de sessão. Caso alguma pessoa tente interceptar esses dados que serão criptografados verá apenas uma mistura distorcida de caracteres que é quase impossível de descriptografar. O SSL/TLS também assina digitalmente os dados para fornecer integridade dos dados, verificando se os dados não foram alterados antes de chegarem ao destinatário pretendido.
Passo a passo do TLS:
O handshake TLS consiste em três partes, começando com um cliente enviando uma solicitação SYN para um servidor que hospeda as informações que o cliente está procurando. O servidor então confirmará o recebimento da solicitação de sincronização do cliente enviando um SYN ACK de volta ao cliente. Por último, o Cliente confirma o recebimento da mensagem de sincronização do servidor (ACK).
Quando um cliente, como um navegador da Web, inicia uma conexão TLS, com a mensagem ClientHello, ele especifica a versão mais alta do protocolo TLS que suporta, um número aleatório, uma lista de conjuntos de criptografia que suporta em ordem preferencial, métodos de compactação sugeridos e quaisquer extensões TLS, como ID de sessão, tickets de sessão, SNI, ALPN e assim por diante.
Depois de receber o ClientHello, o servidor escolhe os parâmetros para o handshake daqui para frente. O servidor então responde ao cliente escolhendo o seguinte: uma versão do protocolo, um número aleatório, um conjunto de criptografia, Certificado e um método de compactação. O servidor pode impor sua própria preferência de seleção do conjunto de cifras seguido de uma mensagem informando que a negociação do handshake foi finalizada.
O cliente então valida o Certificado em relação ao trusted store, o período de validade especificado no certificado e verifica a revogação pela Autoridade de Certificação emissora, a CA. O cliente pode responder com uma Troca de Chave do Cliente (Client Key Exchange), se necessário, seguida por uma mensagem Alterar Especificação de Cifra (Change Cipher Spec). Isto indica ao servidor que todas as mensagens futuras nesta conexão serão criptografadas e autenticadas com as informações previamente negociadas. Finalmente, o cliente envia uma mensagem Finished contendo o código de autenticação das mensagens de handshake anteriores.
O servidor então responde com sua própria mensagem Change Cipher Spec, indicando ao cliente que todas as mensagens futuras nesta conexão serão criptografadas e autenticadas com as informações previamente negociadas.
Finalmente, o servidor envia uma mensagem Finished contendo o código de autenticação das mensagens de handshake anteriores. O handshake TLS agora está completo e inicia-se a comunicação segura entre o cliente e a aplicação.
Ao final da comunicação, cliente e servidor fecham o túnel privado e descartam a chave secreta compartilhada.
A feature de espelhamento de porta – técnica para cópia do tráfego de uma ou mais portas para outra porta com fins de análise, estatísticas, coleta, entre outros – é chamada pela Cisco de SPAN (Switched Port Analyzer).
A configuração para a maioria dos Switches Cisco com IOS é bem simples e é necessário somente escolher a porta ou VLAN de origem da coleta e depois o destino para o tráfego que será copiado:
Switch# configure terminal
Switch(config)# monitor session 1 source interface fa0/11! Definindo a interface de origem para cópia do tráfego
Switch(config)# monitor session 1 destination interface fa0/12! Definindo o destino do tráfego copiado
Além disso, podemos escolher se o tráfego espelhado será somente de transmissão (tx) ou recepção (rx) para a porta desejada
Caso o servidor de coleta esteja em um Switch diferente da origem do tráfego desejado é possível atribuir a função de trânsito para uma VLAN transportar o tráfego espelhado e estender a VLAN até o Switch que o Servidor de coleta está conectado – essa funcionalidade é chamada de RSPAN (Remote SPAN). Abaixo demonstramos a configuração juntamente com a topologia.
No Switch 3, encaminharemos o tráfego de entrada da VLAN 10 e 11 para a VLAN 200 (remote SPAN). O Switch 2 fará transito para a VLAN remote SPAN e encaminhará também o tráfego de entrada da VLAN 15. O Switch 1 encaminhará todo o tráfego da copiado para a VLAN remote SPAN para interface fa0/24, conectada ao servidor de coleta.
Obs: – O RSPAN não suporta o monitoramento de pacotes BPDU ou outros protocolos de comutação da Camada 2. – A VLAN do RSPAN é configurada apenas em portas trunk e não em portas de acesso. Para evitar tráfego que o indesejado na VLAN RSPAN, verifique se o a funcionalidade VLAN “remote span” é suportada em todos os Switches participantes. – Não pode haver nenhuma porta de acesso associada com a VLAN do RSPAN – Os pacotes CDP não são encaminhados na VLAN configurada por RSPAN. Desabilite o CDP em todas as interfaces que transportam RSPAN VLAN nos dispositivos conectados ao switch.
Os ataques à rede local do tipo man-in-the-middle, ou comumente conhecido como MITM, permitem ao atacante posicionar-se no meio da comunicação entre duas partes. Este ataque é útil para conduzir outros ataques, como sniffing(captura das informações) e session hijacking (sequestro de sessão).
Em um ataque MITM, a vítima não percebe a interceptação do tráfego e isso permite ao atacante a leitura e captura do tráfego entre as duas vítimas como também a alteração da informação para os fins de objetivo do ataque, sem a interrupção da comunicação do ponto de vista da vítima.
Em IPv4, um ataque man-in-the-middle pode ser executado de diversas formas, como com o envenenamento do cache ARP (ARP cache poisoning /ARP Spoofing) e a falsificação de mensagens ICMPv6 durante a descoberta de vizinhos e/ou o serviço DHCPv6.
arpspoof
Os equipamentos com função de gateway na rede possuem a responsabilidade de rotear os pacotes da rede local para outras redes dentro do domínio da empresa ou Internet. Ferramentas como arpspoof disparam mensagens ARP reply ao computador da vítima (em uma rede IPv4) falsificando o endereço MAC do gateway. Essa série de respostas ARP dizem ao nosso alvo que a máquina atacante é o gateway de destino. Desse modo, quando o alvo enviar o tráfego para o dispositivo de destino, o switch enviará os pacotes da vítima diretamente para a máquina do atacante.
THC-IPv6
O THC-IPv6 possui diversas ferramentas para spoofing (falsificação) em redes IPv6, forjando os pacotes de router advertisement (RA ou anuncio de roteadores), neighbor advertisement (NA ou anuncio de vizinhos), router solicitation (RS ou solicitação de roteadores) e neighbor solicitation (NS ou solicitação de vizinhos). Em ataques específicos MITM, o THC-IPv6 pode anunciar que a máquina do atacante é o roteador para os pacotes de solicitação (RS e NS) ou envia deliberadamente que possui a melhor rota padrão, assim o computador da vítima recebe o anúncio falso da máquina atacante e envia todos os pacotes que iriam direto ao roteador para a máquina atacante.
A RFC 4861, lista 3 (três) tipos de prioridades para rotas ensinadas aos computadores da rede local via mensagens ICMPv6 RA: baixa, média (padrão) e alta. Utilizando dessa implementação o THC-IPv6 consegue enviar uma atualização anunciando-se como o roteador em a rede com a mais alta prioridade.
Com o atacante personificando o gateway da rede tanto em redes IPv4 e IPv6, todo o tráfego não criptografado pode ser lido, modificado ou descartado, possibilitando outros tipos de ataques.
SSLStrip
Uma vez que o atacante consegue se posicionar para capturar todo o tráfego da vítima e ler as informações que trafegam sem nenhum tipo de criptografia, algumas técnicas podem ser utilizadas para as conseguir acesso as credenciais através de serviços de rede que utilizam navegadores de Internet.
A grande maioria dos sites provedores de serviço tem gerado versões de suas páginas com o protocolo SSL que tem como objetivo criar um canal criptografado entre o servidor da aplicação e o cliente. O SSL é associado juntamente com outros protocolos para fornecer uma implementação segura de serviços e aplicações, como: SMTPS, IMAPS, e etc. Uma vez que o SSL é utilizado com o protocolo HTTP, ele é denominado como HTTP over SSL ou HTTPS.
Os atacantes atualmente utilizam de técnicas como sequestro de sessão (session hijacking) para explorar a comunicação de uma sessão valida da vítima. O roubo de sessão para o trafego HTTPS, também conhecido como SSL hijacking, trabalha em cima da conexão HTTP (não segura) para uma segura (HTTPS) intermediando a conexão SSL, antes dela correr. Geralmente um usuário ao acessar uma página digita apenas o nome da página sem o prefixo “http://” ou “https://”, os navegadores de Internet como o Internet Explorer, Chrome, Firefox, entre outros, adicionam automaticamente o prefixo ‘http://’ na requisição da página web. Se a página for HTTPS, o servidor web retornará uma mensagem ao host solicitando o redirecionamento para a versão https://”.
Usando como referência o site http://outlook.com , quando o navegador recebe a resposta de redirecionamento do servidor web, ele emite uma nova requisição para o site incorporado na resposta da mensagem de redirecionamento, em nosso caso https://outlook.live.com/owa/. O navegador então estabelecerá a conexão SSL / TLS com o site. O resto da comunicação acontece via HTTPS a partir de agora.
A ferramenta SSLStrip, escrita por Moxie Marlinspike, é bastante utilizada em um ataque man-in-the-middle para SSL Hijacking. O SSLStrip fecha uma sessão HTTP com a vítima e uma sessão HTTPS com a página web, capturando assim as informações que deveriam ser criptografadas. A vítima não receberá nenhuma informação do certificado da página segura e na barra de endereço do navegador o site exibirá o nome da página apenas com o prefixo HTTP enquanto o SSLStrip comunica-se em HTTPS com o servidor web.
Laboratório
Em um ambiente de testes, executamos as ferramentas arpspoof e SSLStrip com o objetivo principal de capturar as credenciais digitadas em páginas web.
Como preparação no Kali Linux é necessário habilitar o IP forwarding e configurar o iptables para redirecionar o tráfego HTTP para a porta que será utilizada pelo SSLStrip.
O próximo passo para iniciar o ataque inclui a execução das ferramentas arpspoof e o SSLStrip.
Com o ataque em execução, o SSLStrip irá registrar as credenciais inseridas em páginas que solicitam autenticação, tanto no acesso as páginas HTTP e HTTPS. Abaixo um exemplo da captura durante a autenticação em um serviço de e-mail da Microsoft utilizando o navegador Internet Explorer8.
Análise dos resultados
A execução dos testes em ambiente de laboratório simulando uma rede local de uma empresa demonstrou a facilidade que um atacante interno consegue capturar e modificar o tráfego da vítima.
Os testes para as máquinas alvo incluíram os sistemas operacionais Windows 7, Windows 10 e o Debian 9. Algumas funcionalidades de segurança incorporadas por padrão aos equipamentos e softwares utilizados no estudo serviram para mitigar o ataque, como a utilização do navegador Firefox que possui suporte nativo ao protocolo HSTS, que permite que a comunicação entre o servidor web e o navegador ocorra somente com criptografia e com certificado emitido por uma autoridade certificadora confiável.
A utilização de funcionalidades em switches como arp inspect (DAI) validam se a mensagem ARP é gerada pela máquina verdadeira.
Uma outra opção também surge em cenários que não é necessário a comunicação entre todas a máquinas da rede sendo possível efetuar a configuração em switches e access points para isolamento dos hosts entre si, permitindo apenas a comunicação entre hosts e equipamentos e servidores de rede.
Um usuário mais atento poderia também perceber que a pagina requisitada estaria trabalhando apenas em HTTP ao invés de HTTPS, visto que os provedores de serviço na Internet quase em sua totalidade trabalham com a versão segura do protocolo.
Apesar desse estudo utilizar-se de algumas técnicas exploradas há anos, elas ainda se tornam efetivas tanto em redes IPv4 quanto em redes IPv6, inclusive para captura do tráfego de outros serviços críticos.
Os ataques MITM atuam diretamente na privacidade do usuário pois coletam informações confidenciais através das técnicas citadas nesse trabalho. É relevante notar que a aplicação de políticas de segurança ajudaria a mitigar e isolar alguns cenários de ataque.
O objetivo final desse artigo é contribuir para que os responsáveis pela infraestrutura e segurança da tecnologia da informação estejam atentos aos riscos. Uma vez que esse tipo de ataque é comumente efetuado dentro da rede local, algumas ações podem ser facilmente adotadas contra dispositivos não cadastrados e contra o acesso indevido a rede da empresa através do uso de certificados digitais para validação da máquina e/ou usuário. Um outro ponto importante inclui o estudo da implementação do protocolo IPv6 em dispositivos como smartphones e usuários do sistema operacional Linux e Windows, pois os diferentes sistemas operacionais trazem implementações diferente das principais RFC’s que padronizam as implementações dos protocolos.
Referências
ORIYANO, Sean-Philip. CEHv9 – Certified Ethical Hacker Version 9 – Study Guide. Indianópolis: John Wiley & Sons,2017. WEIDMAN, Georgia.Teste de Invasão – Uma introdução prática ao hacking. São Paulo: Novatec, 2014.
Galera, compartilho com muito carinho o Treinamento Comware para Switches HP (não oficial) onde damos um overview das principais funcionalidades para os switches! São 8 aulas com bastante conteúdo.
A utilização de soluções de VPNs estende o acesso a redes privadas através da conectividade remota para o fornecimento de comunicação segura entre os dispositivos.
Uma VPN estabelece um túnel entre dois dispositivos, que estão separados por uma rede pública insegura, como a Internet por exemplo, entregando acesso seguro para a rede privada. A VPN pode também ser utilizada na comunicação entre uma matriz e suas filiais, entre empresas para fornecimento de serviços ou para o estabelecimento do teletrabalho.
Existem diversos mecanismos para estabelecimento de VPNs e os principais para conectividade para o acesso remoto utilizam o SSL ou IPsec.
O FortiOS suporta a utilização de VPNs IPsec e SSL, assim como outros métodos menos seguros.
Uma VPN deve utilizar métodos seguros para que somente usuários autorizados possam estabelecer a comunicação e acessar os recursos da rede. A comunicação deve ter como premissa a criptografia do tráfego ( que não poderá ser lido quando interceptado por usuários não autorizados).
Neste artigo faremos um breve resumo sobre SSL-VPN no FortiOS.
Protocolo SSL
O protocolo SSL é uma aplicação para criptografia de camada 7, que fornece comunicação segura pela Internet através de um navegador web, e-mail e outros tipos de tráfego.
O principal objetivo é providenciar tanto a privacidade, quanto a integridade dos dados, oferecendo comunicação segura entre as aplicações.
Por padrão o SSL para o tráfego web utiliza a porta TCP 443.
SSL-VPN
A solução de VPN quando baseada em SSL, oferece conectividade a determinados recursos internos da empresa, através de acesso remoto por um computador conectado a Internet, através de um software cliente ou um navegador web com criptografia SSL nativa.
O FortiOS permite dois modos para o estabelecimento de SSL-VPN e a escolha dependerá do uso das aplicações pela VPN, conhecimento técnico dos usuários e/ou permissões administrativas em seus computadores.
SSL-VPN Web Mode: Requer unicamente um navegador web, mas possui limitação no número de protocolos. É o modo mais fácil de configuração.
SSL-VPN Tunnel Mode: Oferece suporte a grande maioria dos protocolos, mas requer a instalação de um software cliente VPN, um virtual network adapter, que pode ser utilizado com o FortiClient ou o módulo FortiSSL-VPN client.
Web Mode
O modo Web permite ao usuário conectar em um portal no Fortigate (que atua como um servidor de proxy reverso) e então comunicar-se com a rede ou aplicação.
O portal web permite a configuração de bookmarks que contém todos os recursos disponíveis para acesso ao usuário. A principal vantagem do modo web é que o usuário não necessitará instalar nenhum software adicional. A desvantagem é que toda interação acontecerá através do navegador para os protocolos mais populares como HTTP, FTP e compartilhamento Windows.
1 – Os usuários remotos estabelecem um túnel seguro ao Fortigate utilizando HTTPS.
2 – Uma vez conectado, os usuários fornecem as credenciais para autenticação.
3 – O Fortigate irá exibir um portal SSL-VPN que contém os serviços e recursos de rede para acesso ao usuário.
Para configurar a SSL-VPN no modo Web utilize o cookbook abaixo:
A opção Tunnel Mode requer a instalação de um cliente SSL-VPN (FortiClient) para conexão ao Firewall. O FortiClient adiciona um virtual network adapter identificado como fortissl para o usuário que recebe dinamicamente um endereço IP do Fortigate na conexão da VPN. O tráfego será enviado encapsulado em um túnel SSL/TLS.
O modo Tunnel permite a comunicação de qualquer aplicação (quando permitida nas políticas do firewall) através do túnel.
1 – Os usuários remotos solicitam um túnel seguro ao Fortigate utilizando FortiClient.
2 – Os usuários fornecem as credenciais para autenticação.
3 – O Fortigate estabelece um túnel e atribui um endereço IP ao software client com um virtual network adapter (fortissl), durante o tempo da conexão.
4 – Após o estabelecimento da conexão é possível acessar os recursos de rede através do túnel criptografado.
Para configurar a SSL-VPN no modo Web utilize o cookbook abaixo:
O Forticlient com a SSL-VPN estabelecida, fará a criptografia dos dados ao Fortigate que ao receber o tráfego removerá a criptografia e encaminhará a comunicação ao dispositivos de destino.
O Tunnel mode também permite o split tunneling, que encaminhará todo o tráfego de Internet diretamente para a Internet (sem encaminhá-lo ao túnel). O tráfego para a rede privada continuará sendo enviado através da VPN.
Referências
FortiGate Security Study Guide for FortiOS 6.2
Network Security Technologies and Solutions, Cisco press – Yusuf Bhaiji
Os sniffers são ferramentas que permitem capturar e scanear o trafego da rede, possibilitando ao administrador reunir informações, monitorar o uso de protocolos que não deveriam trafegar na rede e enfrentar de forma objetiva questões que afetam o desempenho de serviços.
A análise dos pacotes capturados permite o levantamento de questões como: “o tráfego da rede está normal”? “Existe alguma flag TCP não usual”?
Há também a possibilidade de analisarmos assinaturas de malwares, tráfego não criptografado e protocolos trocados entre dispositivos de rede para fins de aprendizado, laboratório, troubleshooting e ajustes.
A análise de pacotes pode ser dividida em 4 fases: gather (reunir), decode (decodificar), display (exibir) e analyze (analisar).
Os softwares de análise de pacotes reúnem e decodificam os bits recebidos pela placa de rede. Uma vez decodificada as informações por protocolo e fluxo, os sniffers exibem o resultado de uma forma legível ao administrador. A analise do tráfego capturado pode ser efetuada tanto em tempo real da captura ou com a utilização um arquivo pré-capturado.
A maioria dos programas utilizados para sniffer são bastante funcionais independentemente do SO ou o modo de exibição. Sniffers como Wireshark possuem um painel principal para exibição dos pacotes de entrada e alguns destaques, permitindo a utilização de filtros para visualizar apenas parte do tráfego que o administrador deseja analisar.
Podemos utilizar o bash (linux) para capturar o trafego de rede e salvar um arquivo .pcap para abrir posteriormente em um wireshark:
# Pegando todo o trafego
tcpdump -i any -w file.pcap
#Filtrando uma porta TCP especifica
tcpdump -i any port 80 -w file.pcap
Cenários para a capturar os pacotes?
As principais formas de captura de pacotes são as seguintes:
– Host ou Servidor conectado a uma porta de Switch: Nesse cenário o administrador poderá conectar um host com um software de sniffer e então visualizará (apenas) as mensagens direcionadas a aquela máquina, além de mensagens em broadcast, multicast na LAN.
– Host ou Servidor conectado a um TAP ou HUB: Um HUB ou TAP replica a comunicação de uma porta para todas as portas, nesse caso é possível visualizar todo o tráfego que passa pelo HUB utilizando um sniffer. Atualmente TAPs cada vez mais “inteligentes” permitem a otimização e seleção do tráfego copiado.
– Host ou Servidor conectado a uma porta de Switch com SPAN (espelhada): Uma porta espelhada direciona uma cópia do tráfego de uma determinada origem (porta ou VLAN) para a porta configurada com SPAN. Nesse tipo de cenário o administrador pode copiar todo o tráfego de um uplink/porta e direcionar para um servidor IDS ou máquina com sniffer.
– MAC Flooding: Utilizando ferramentas como o macof, um atacante pode inundar (flood) a rede de quadros Ethernet com endereços MAC falsos, esgotando a tabela CAM dos switches e forçando os equipamentos a entrar no modo fail-open, atuando assim como um HUB – alguns equipamentos reiniciam ou entram em modo de proteção nesses cenários.
– ARP Spoofing: Utilizando ferramentas como arpspoof (entre outras) o atacante consegue interceptar o tráfego entre 2 partes atuando como man-in-the-middle, podendo inclusive manipular o tráfego sem a percepção das vítimas.
Ataques passivos e ativos utilizando sniffing
O sniffing pode ser classificado como ativo ou passivo. Normalmente, o sniffing passivo é considerado como qualquer tipo de captura onde o tráfego é apenas analisado e não há alteração no tráfego da rede. Já no sniffing ativo, o tráfego além de ser monitorado é também alterado pelo atacante.
A utilização de sniffers afeta os seguintes pontos da Segurança da Informação:
– Confidencialidade: Proteção dos dados contra divulgação não autorizada; – Integridade: Proteção dos dados contra modificação não autorizada; – Disponibilidade: Data e serviços disponíveis aos usuários autorizados; – Autenticação: Verificação da identidade de um usuário ou equipamento.
Monitoração e defesa
A captura de informações da rede pode ser utilizada para o início de ataques contra a rede como também ser considerada ilegal – a menos que a ação tenha sido autorizada ou o administrador esteja monitorando a rede como empregado/contratado.
Existem algumas práticas para mitigar o sniffing:
– Desabilite portas não utilizadas em switches.
– Use criptografia no tráfego de rede sempre que possível, principalmente para informações sensíveis como e-mail, transações via web e configuração de equipamentos.
– Use funcionalidades de segurança em Switches como portsecurity, dhcp-snooping com dynamic arp inspection e ip source guard para mitigar ataques como Mac flooding e ARP spoofing/poisoning.
– Utilize autenticação via 802.1x para rede cabeada e sem-fio.
– Crie uma rede segregada para serviços, usuários, usuários Guest e dispositivos BYOD.
– Cuide da segurança física dos equipamentos de rede.
Para finalizar, utilize ferramentas como IDS, SIEM, UBA, NBA, Syslog, SNMP, entre outros para monitoração do tráfego e eventos na rede.
Referências
ORIYANO, Sean-Philip. CEHv9 – Certified Ethical Hacker Version 9 – Study Guide. Indianópolis: John Wiley & Sons,2017.
O protocolo OSPF permite a todos roteadores em uma área ter a visão completa da topologia. O protocolo possibilita assim a decisão do caminho mais curto baseado no custo que é atribuído a cada interface, com o algoritmo Dijkstra. O custo de uma rota é a soma dos custos de todas as interfaces de saída para um destino. Por padrão, os roteadores calculam o custo OSPF baseado na fórmula Cost =Reference bandwidth value / Link bandwidth.
Caso o valor da “largura de banda de referência” não seja configurado, os roteadores usarão o valor de 100Mb para cálculo. Por exemplo, se a interface for 10Mb, calcularemos 100Mb dividido por 10Mb, então o custo da interface será 10. Já os valores fracionados, serão arredondados para valor inteiro mais próximo e toda velocidade maior que 100Mb será atribuído o custo 1.
Veja no exemplo abaixo o custo que o R1 atribui as suas interfaces:
R1#show ip ospf interface ethernet 1/1
Ethernet1/1 is up, line protocol is up
Internet Address 192.168.13.1/24, Area 0
Process ID 1, Router ID 1.1.1.1,Network Type BROADCAST,Cost: 10
! saída omitida
R1#show ip ospf interface ethernet 1/0
Ethernet1/0 is up, line protocol is up
Internet Address 192.168.12.1/24, Area 0
Process ID 1, Router ID 1.1.1.1,Network Type BROADCAST,Cost: 10
! saída omitida e o custo atribuído para a Loopback é 1
R1#show ip ospf interface loo 1
Loopback1 is up, line protocol is up
Internet Address 1.1.1.1/24, Area 0
Process ID 1, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
O custo do Roteador R1 para a Loopback do Roteador R2 será 11.
R1#show ip route | inc 2.2.2.2
O 2.2.2.2 [110/11] via 192.168.12.2, 01:01:46, Ethernet1/0
Alterando o custo de uma interface …
R1#interface Ethernet1/0 ip ospf cost 200 ! Alterando o custo da interface para 200
R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "ospf 1", distance 110, metric 21, type intra área Last update from 192.168.13.3 on Ethernet1/1, 00:10:06 ago Routing Descriptor Blocks: * 192.168.13.3, from 2.2.2.2, 00:10:06 ago, via Ethernet1/1 Route metric is 21, traffic share count is 1
Caso seja necessário alterar a referência para largura de banda utilize o seguinte comando em um roteador Cisco IOS:
R1(config)# router ospf 100
R1(config-router)#auto-cost reference-bandwidth ?
The reference bandwidth in terms of Mbits per second
O “auto-cost reference-bandwidth 100″ é o default para 100Mb, onde 100Mb na topologia tem o custo = 1 . Assim, para ter links 1G com o custo = 1 , o “auto-cost…” deve ser configurado como 1000. Se a referência for links 10G , “auto-cost…” seria 10000 , para 100G, seria 100000 .
Obs: Lembre-se de sempre manter o “auto-cost reference-bandwidth” consistente em todos os roteadores para evitar comportamentos inesperados no roteamento.
RotaDefault 