Author: Diego Dias

Fortigate: SSL-VPN

Diego DiasLeave a comment

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:

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/579694/ssl-vpn-web-mode-for-remote-user

Tunnel Mode

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:

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/954097/ssl-vpn-tunnel-mode

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

Sniffers e Análise de pacotes na rede cabeada

Diego DiasLeave a comment

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.

Custo OSPF

Diego DiasLeave a comment

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.

Até logo!

VICTOR HAYASHI – SEGURANÇA EM IOT – PODCAST #11

Diego DiasLeave a comment

Nesse bate-papo com o Victor Hayashi, um dos escritores do livro Segurança em IoT, falamos sobre segurança em dispositivos de Internet das Coisas, aplicações residenciais, aplicações na indústria, livros, seu trabalho de mestrado, controle de acesso, cursos, arduino, hardwares e mais.

VLAN – Trunk utilizando 802.1q (dot1q)

Diego DiasLeave a comment

A utilização de VLAN (Virtual Local Area Network) permite que uma rede física seja dividida em várias redes lógicas dentro de um Switch. A partir da utilização de VLANs, uma estação não é capaz de comunicar-se com estações que não são pertencentes a mesma VLAN (para isto, é necessário a utilização de uma sub-rede por VLAN e que o tráfego passe primeiro por um roteador para chegar a outra rede [ou utilizando um Switch Multicamada para efetuar o Roteamento]).

Se não utilizássemos uma interface como Trunk e precisássemos passar o tráfego da VLAN para o outro Switch, seria necessário a passagem de um cabo de cada VLAN para o outro dispositivo, como no exemplo abaixo.

Como a maioria dos Switches possui entre 24 e 48 portas a solução ficaria inviável, inutilizando a maioria das portas para conexões entre os dispositivos.

O protocolo IEEE 802.1q permite utilizarmos apenas um cabo na comunicação entre os Switches, marcando cada Frame (quadro) com o ID de cada VLAN.

A marcação efetuada (chamada de TAG) adiciona aos quadros Ethernet 4 bytes no frame original e calculam um novo valor de checagem de erro para o campo FCS.

Dos valores contidos dentro do campo TAG o número da VLAN é adicionado ao campo VLAN id permitindo a identificação da VLAN entre os Switches.

Uma observação relevante é a utilização do campo Priority (também dentro da TAG) para função de QoS em camada 2 para Ethernet, chamado de 802.1p ou CoS (Class of Services), permitindo a diferenciação de classes de serviços por Switches sem a necessidade de leitura do campo IP.

Já a comunicação entre computadores no mesmo Switch que pertencem a mesma VLAN não são “tagueadas” (untagged). Muitas placas de rede para PC’s e impressoras não são compatíveis com o protocolo 802.1Q e ao receberem um frame tagged, não compreenderão o TAG de VLAN e descartarão a informação.
Os Switches que recebem na sua interface Trunk um frame com TAG, irão remover o campo e entregar o quadro ao destino sem a marcação.

A regra é bem simples para a maioria dos casos (salvo exceções):

  • Para comunicação entre Switches, configure as interfaces como Trunk ( Tagged)
  • Para comunicação entre Switches e hosts, servidores, impressoras; configure as interfaces como Access (untagged) com o ID da VLAN

Configuração

Para a maioria dos Switches Cisco IOS, configure as portas como trunk da seguinte maneira (desde que as VLANs  já tenham sido criadas no Switch ou aprendidas via VTP):

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type trunk
! configuração da interface como trunk (frames encaminhados como tagged)
port trunk permit vlan all
! configuração da porta permitindo todas as VLANs no trunk

Um detalhe importante a ser percebido é  sintaxe switchport trunk encapsulation dot1q . Apesar do protocolo 802.1q não encapsular o quadro Ethernet, a sintaxe Cisco solicita a configuração do protocolo via o comando   .  Suponho que a sintaxe deva ter surgido quando a Cisco apostava na utilização de interfaces Trunk utilizando o protocolo ISL  que efetivamente encapsulava o quadro Ethernet.

Portas de acesso:

interface GigabitEthernet 1/0/x
! acesso a interface GigabitEthernet
port link-type access
! configuração da interface como acesso (frames encaminhados como untagged)
port access vlan 2
! configuração da porta na vlan 2

Obs: Por default os frames da VLAN 1 não são encaminhados com TAG dentro do Trunk.

Abraços a todos!!!

Iniciando os testes de APIs Meraki com DevNet Sandbox

Diego DiasLeave a comment

O Cisco Meraki é um conjunto de soluções de rede gerenciadas pela internet que permite uma única fonte de gerenciamento sobre locais, infraestrutura e dispositivos. Componentes incluem uma solução completa de TI gerenciada por nuvem para atendimento as soluções de wireless, switching, segurança, gerenciamento de dispositivos móveis (MDM) e comunicações, integrando o hardware, software e a nuvem.

Há cinco maneiras pelas quais uma aplicação pode estender as funcionalidades da plataforma Meraki:

  • A Dashboard API, que fornece um serviço RESTful para provisionamento, gerenciamento e monitoramento de dispositivos.
  • Alertas de webhook, um serviço que permite atualizações em tempo real da saúde e configuração da rede.
  • A API de localização, um método HTTP POST configurado no Meraki Dashboard que fornece informações de localização do cliente (GPS, X/Y) com base no posicionamento do mapa do Meraki Access Point (AP) e na intensidade do sinal do cliente.
  • O External Captive Portal (EXCAP), que permite que uma organização crie modelos de engajamento personalizados para dispositivos que aproveitam seu ambiente WiFi.
  • MV Sense, que oferece chamadas de API REST e fluxo de dados em tempo real para aproveitamento das câmeras MV12

O ambiente “Meraki DevNet Always On Read Only Sandbox” fornece um ambiente de desenvolvimento para validar e testar o ‘Cisco Meraki Dashboard’, Dashboard API, integração do Captive Portal, MV Sense, Webhook Alerts e Location Scanning.

Todas as chamadas de API são muito bem documentadas usando a especificação OpenAPI (Swagger interface). Há ótimo trabalho disponibilizando tudo como um Documento Postman, um recurso muito útil no desenvolvimento de uma API.

O Postman é uma ferramenta de desenvolvimento de API baseada no modelo web/cliente, perfeita para simular chamadas e explorar como funcionam determinadas APIs. A plataforma da Meraki está atualmente na sua API versão 1.x .

Qual o uso das APIs?
Existem muitos casos de uso para essas APIs, atendendo a requisitos de escalabilidade ​​para os administradores e automatização para as redes Meraki. Os casos de uso comuns são:

  • Provisionamento em massa (usando a API do painel)
  • Monitoramento avançado (usando MV Sense e APIs MR)
  • Automação de rede (usando chamadas MS)
  • Integrações na nuvem (integrar Meraki com dispositivos de terceiros — com Cisco Umbrella, por exemplo)

Cisco Sandbox

O ambiente Cisco DevNet Sandbox permite que engenheiros, desenvolvedores, administradores de rede, arquitetos ou qualquer pessoa que queira desenvolver e testar as APIs, controladores, equipamentos de rede, suíte de colaboração e muito mais da ferramentas da Cisco, possa fazê-lo gratuitamente!

https://developer.cisco.com/site/sandbox

Ambiente Meraki

Nesse post faremos um laboratório utilizando a infraestrutura Meraki (Meraki Always On).

Faça login, no dashboard com as credenciais fornecidas, acesse o ambiente “DevNet Sandbox”

Certifique se o use o uso de API está ativo “Enable access to the Cisco Meraki Dashboard”. Logado no painel vá para: Organization -> Settings -> Dashboard API Access, marque a caixa:

Gere uma API key para aquela conta. Cada conta poderá ter até 2 API Keys.

Clique no seu Perfil (canto superior direito): My Profile -> API Access -> Clique em “Generate API Key” copie e armazene em local seguro.

Postman

Depois de seguir os passos acima, você pode começar a fazer chamadas de API para seu dashboard e dispositivos usando o Postman ou seus scripts Python.

Se você precisar de ajuda com o Postman, incluindo como importar a API Postman Meraki, confira: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/  com poucos cliques é possível instalar a Coleção “Meraki Dashboard API – v1”

Vamos fazer nossa primeira chamada de API e definir o escopo da nossa documentação da API, pois existem algumas maneiras de fazer isso:

  • Você pode acessá-lo através do Meraki Dashboard: Clique em Help -> API Docs.
  • Importe o documento de API mais recente do Postman para sua conta do Postman.

Após importar para sua conta você poderá ver quantas chamadas de API estão disponíveis e como ela está organizada, confira abaixo:

Escolha um request que você possa preencher facilmente com as informações que já possui (por enquanto só temos a chave da API, portanto precisamos de uma solicitação que exija apenas o valor da Chave da API), por exemplo, poderíamos listar todas as Organizações disponíveis no Chave de API que estamos usando, depois de inserir os campos obrigatórios no cabeçalho da API:

baseURL: https://api.meraki.com/api/v1

apiKey: ae829149e162f8dd0535ca5f0b98e96f1d3adc29 (a API key gerada )

1º Passo, crie um ambiente. Clique no ícone do olho na parte superior direita e  “Add” para criar um novo ambiente.

2º Defina as variáveis. Adicione as informações baseURL e keyAPI

3º Execute o teste para coletar o ID do ambiente “DevNet Sandbox” dentro de “Organization” do ambiente Meraki.

Armado com essas informações, podemos começar a criar scripts e integrar nosso ambiente Meraki com outras ferramentas/plataformas.

Uma vez que coletamos a informação do ID da Organização, podemos atualizar as variáveis e coletar as informações de rede.

Por exemplo, podemos coletar o ID das redes.

Uma vez que coletamos a informação do ID da Rede, podemos atualizar as variáveis e coletar as informações de rede.

Por exemplo, podemos coletar as informações detalhadas dos equipamentos de rede, como endereço IP, serial, geolocalização, modelo, etc.

Coletar os SSIDs da rede:

Visualizando o mesmo SSID no ambiente Meraki:

Com o método PUT podemos alterar ou inserir nos parâmetros para a os SSIDs da Rede.

Referências

Andre Camillo: https://andrecamillo.medium.com/getting-started-with-meraki-apis-7633a822a9da

Charles Judd: https://www.youtube.com/watch?v=86uq_Imi-L0

Meraki API V1: https://developer.cisco.com/meraki/api-v1/

Postman, API development tool: https://www.postman.com/

Meraki API V1 Postman Documentation (import from here):  https://documenter.getpostman.com/view/897512/SzYXYfmJ

Getting started with Postman: https://developer.cisco.com/meraki/build/meraki-postman-collection-getting-started/

https://documenter.getpostman.com/view/897512/SzYXYfmJ#intro

BRUNO WANDERLEY – TI COM AÇAI / REDES / WIRELESS / TELECOM / SATELITES / CONCURSO PUBLICO – PODCAST #10

Diego DiasLeave a comment

Nesse bate-papo com o Bruno Wanderley do TI com Açai, conversamos sobre carreira, redes wireless, redes satélites, estudo para concurso, livros, cursos e mais. A conversa foi sensacional. Vale a pena assistir.

MPLS (Multi Protocol Label Switching)

Diego DiasLeave a comment

Apesar de existirem inúmeros sites em português com ótimas referencias de Introdução ao Protocolo MPLS, escreveremos uma serie de artigos com a utilização de MPLS em diversos cenários. Esse post servirá como uma pequena introdução para a descrição e utilização do protocolo com o foco um pouco mais simples na arquitetura e serviços.

O protocolo MPLS (Multi Protocol Label Switching) foi criado para permitir o encapsulamento de diversos protocolos de rede para serem encaminhados por Roteadores baseando-se apenas no endereço do Label ao invés do endereço de rede. A tecnologia é largamente utilizada pelos Provedores de Internet com diversas topologias de serviços orientado a redes em apenas uma única rede convergida com o MPLS em seu Backbone, permitindo a utilização de Redes Privadas (VPNs MPLS), Qualidade de Serviço (QoS), Any Transport over MPLS (AToM) e Engenharia de tráfego (MPLS-TE).

Ele é chamado de Multiprotocolo pois é utilizado com qualquer protocolo da camada de Rede e em certos cenários permite até o transporte de protocolos da Camada de Enlace sobre MPLS, apesar de quase todo o foco estar voltado no uso do MPLS com o IP.

O objetivo de uma rede MPLS dentro dos Provedores de Serviço não é o de conectar diretamente a sistemas finais.  Ao invés disto ela é uma rede de trânsito, para transporte de pacotes.

Em sua função básica os Roteadores do Backbone chamados de Provider Routers (P) encaminham o tráfego baseando-se apenas nos Labels.  Já os roteadores que são responsáveis por receber os pacotes IP e encapsulá-los com labels em uma rede MPLS são chamados de Provider Edge Routers (PE).

A terminologia dada aos equipamentos em uma rede MPLS é muito importante para identificarmos a função de cada equipamento na topologia e a sua função na arquitetura.

De certa forma, um cliente ao comprar uma comunicação entre as filiais utilizando um link MPLS privado (MPLS VPN), não terá necessariamente em seus roteadores o encaminhamento de pacotes via labels e muito menos a troca deles. Os roteadores designados para clientes, chamados de Customer Edge Routers (CE) possuem a função de prover conectividade na rede MPLS situados na “borda do cliente” (saída para rede).

A conectividade entre PE e CE poderá ser tanto provida por roteamento estático ou via IGP.

Mas o que são os Labels?

Em uma tradução literal, poderíamos dizer que label teria a atribuição de um rótulo. Em sua função no modo frame o label é inserido na frente do cabeçalho da camada de rede. Um pacote pode ter um ou mais rótulos dependendo do serviço oferecido na rede MPLS.

O label é um identificador, de tamanho fixo e significado local. Todo pacote ao entrar numa rede MPLS recebe um label. Desta forma os roteadores só analisam os labels para encaminhar os pacotes. O cabeçalho MPLS deve ser posicionado depois de qualquer cabeçalho da camada de enlace e antes do cabeçalho da camada de rede, ele é conhecido como Shim Header pelo seu posicionamento entre os 2 cabeçalhos e é “carinhosamente” chamado de protocolo da camada 2,5.do Modelo OSI.

Nos próximos posts daremos foco no processo de encaminhamento e troca de labels, outros termos comuns em uma rede MPLS e a configuração de Roteadores para a troca de labels.

Um grande abraço

Referências:

http://www.gta.ufrj.br/grad/01_2/mpls/mpls.htm
http://pt.wikipedia.org/wiki/MPLS
Designing and Implementing, IP/MPLS-Based Ethernet Layer 2 VPN Services, An Advanced Guide for VPLS and VLL, Zhuo ( Frank) Xu – Wiley Publishing, INC – 2010
MPLS Fundamentals, Luc De Ghein. – Cisco Press – 2006
TCP sobre MPLS, ENNE, ANTONIO JOSE FIGUEIREDO – Ciência Moderna – 2009

CheckPoint: Entendendo o Security Management Server

Diego DiasLeave a comment

O Security Management Server (SMS) da CheckPoint é um componente central da plataforma on-premises de segurança do fabricante. Ele fornece uma interface centralizada para gerenciar e monitorar os firewalls (security gateways). O Security Management Server permite aos administradores configurar, gerenciar e aplicar políticas de segurança consistentes em todos os dispositivos Check Point.

Existem duas opções para implementação do SMS:

  • Appliance Check Point Quantum Smart-1
  • Open Server (virtualizado e instalado em hardware de terceiros)

O SMS faz parte da arquitetura de 3 camadas utilizada pela CheckPoint que inclui 3 componentes principais com as suas responsabilidades especificas:

SmartConsole: O SmartConsole é uma interface gráfica de usuário (GUI) que permite configurar e monitorar seus dispositivos de segurança da CheckPoint. Ele fornece uma visão abrangente do status de segurança da rede, incluindo o tráfego de rede, os logs de eventos e as configurações de segurança. O SmartConsole é utilizado para criar e gerenciar políticas de segurança no Security Management Server (SMS), aplicar atualizações de software e solucionar problemas de segurança.

O SmartConsole pode ser instalado em um desktop, como também ser utilizado em uma versão portable ou ser acessado no modo clientless, através de browser.

SMS: O SMS ( Security Management Server) é um servidor de gerenciamento de segurança que fornece uma plataforma centralizada para configurar e monitorar os Security Gateways em uma rede local ou em uma rede distribuída.

Security Gateway: O Security Gateway é um firewall de próxima geração (NGFW) que fornece proteção de perímetro para redes corporativas com uma ampla gama de recursos de segurança, incluindo prevenção de intrusões, filtragem de conteúdo, controle de acesso à rede, sandbox e criptografia.

Entre as atribuições e funções do Security Management Server ele é responsável por:

  • Banco de dados
    • O SMS hospeda um banco de dados PostgreSQL centralizado que armazena com segurança todos os dados gerenciados e os disponibiliza mediante solicitação.
  • Internal Certificate Authority (ICA)
    • O SMS inclui uma ICA (Internal Certificate Authority) que pode ser usada para emitir e gerenciar certificados digitais para dispositivos de segurança e usuários. Os certificados digitais são usados para autenticação, criptografia e outros fins de segurança, como a comunicação SIC entre os dispositivos CheckPoint.
  • Servidor de Logs
    • O SMS pode ser usado também para coletar e armazenar logs de eventos de dispositivos de segurança. Os logs de eventos podem ser usados para rastrear o tráfego de rede, identificar ameaças e responder a incidentes. De forma opcional é possível instalar um servidor SMS exclusivo para os logs.
  • Repositório de Licenças e Contratos
    • O SMS pode ser usado para armazenar informações sobre licenças de software e contratos de serviços. Essas informações podem ser usadas para gerenciar o licenciamento e os custos de segurança.
  • Monitoração
    • O SMS pode ser usado para monitorar os Security Gateways e exibir informações em tempo real como contadores, estatísticas de tráfego, uso de disco, CPU e memória. O monitoramento pode ser usado para detectar problemas de segurança e responder a incidentes.
  • Security Automation
    • O SMS pode ser usado para automatizar tarefas de segurança e o uso de APIs, permitindo aos desenvolvedores criarem scripts e efetuarem mudanças nas políticas de segurança utilizando CLI e web services.

Cenários de implementação do SMS

A implementação do SMS pode ser executada em duas topologias, modo standalone e distributed.

No modo standalone deployment o SMS e o Security Gateway são instalados no mesmo computador ou appliance. O SmartConsole é instalado em uma máquina Windows que então conecta ao Security Management Server para configuração e gerenciamento do Security Gateway.

O modo standalone é recomendável apenas em ambientes small businesses, devido as limitações de performance que ele pode gerar no security gateway.

O modo distributed deployment, o SMS e o Security Gateway são instalados em diferentes computadores ou appliance. O SmartConsole é instalado em uma máquina Windows que então conecta ao Security Management Server para configuração e gerenciamento dos Security Gateway.

Um Security Management Server é requerido mesmo se a implementação consiste em apenas um Security Gateway. Já um servidor SMS pode gerenciar múltiplos NGFWs.

Resumindo…

Em resumo Security Management Server da CheckPoint é um software/aplicação que centraliza o gerenciamento e monitoramento de dispositivos de segurança da CheckPoint, sendo um elemento fundamental na configuração e gestão de dispositivos Quantum.

Os administradores interagem com o Security Management Server por meio de uma interface gráfica chamada SmartConsole, que fornece ferramentas para configuração, monitoramento e relatórios.