No decorrer da vida nos deparamos com circunstâncias que muitas vezes geram em nós um desejo de mudança. Seja pelas novas oportunidades do mercado, por questões financeiras, desemprego, descoberta de um novo talento, desejo de viver novos desafios ou pela mudança no estilo de vida, a transição de carreira pode ser um divisor de águas na nossa história.
Um bom planejamento, estudo e identificação de seus pontos fortes e reconhecimento dos fracos, podem facilitar o caminho dessa jornada. Nesse bate-papo com o Coach Rodrigo Matos conversamos sobre transição de carreira, analise comportamental, comunicação e autoconhecimento.
A página https://tmgmatrix.cisco.com/ auxilia os administradores de rede e parceiros a identificar quais são os transceivers compatíveis para cada equipamento Cisco. O site possui um mecanismo de busca que auxilia a pesquisa por tipo de transceiver, Part Number, modulo ou dispositivo de rede.
Uma vez identificado os transceivers compatíveis a página ainda oferece mais detalhes para cada um dos tipos de transceivers como padrões, distâncias, compatibilidade com DOM, IOS, se o transceiver é EoS/EoL e assim por diante.
As tecnologias de threat deception são ferramentas que visam enganar e atrair cibercriminosos, desviando sua atenção de ativos reais e sensíveis. Através da simulação de sistemas, dados e ambientes falsos, os deceptions protegem a infraestrutura real e coletam informações valiosas sobre os atacantes.
A premissa é: Em caso de falha nas defesas da empresa – um cenário cada vez mais possível com a crescente sofisticação dos ataques cibernéticos – a tecnologia de deception se torna crucial para proteger dados sensíveis.
A tática utilizada tem como objetivo criar iscas (decoys) digitais para atrair os atacantes. Isso pode ser feito através da simulação de:
Redes e dispositivos falsos, simulando uma infraestrutura de TI completa, atraindo os atacantes para um ambiente controlado, onde seus movimentos podem ser monitorados e analisados.
Dados falsos, a criação desses arquivos, como documentos confidenciais ou informações de clientes, tem o objetivo de levar os atacantes a acreditar que obtiveram acesso a informações valiosas, enquanto na verdade o acesso ao dado está sendo monitorado.
Aplicações falsas, simulando aplicações web ou serviços online, os decoys podem capturar informações valiosas sobre os métodos de ataque utilizados pelos cibercriminosos.
Quais os benefícios de usar deception, honeypot e sandbox?
Duas técnicas iniciais têm funções similares ao deception: as honeypots e sandboxes.
Um honeypot é uma armadilha digital que imita um dispositivo real na rede, com a ideia de atrair atacantes para estudar suas ações. As honeypots (máquinas), honeynets (redes), honeytokens e suas variações, são simples de implementar, mas menos eficazes contra os atacantes experientes, pois trabalham utilizando técnicas reativas e estáticas enquanto as soluções corporativas de deception trabalham além de detecção baseada em assinatura como também na análise comportamental, heurística e Inteligência Artificial para ambientes OT/IoT/TI.
Os sandboxes, por outro lado, são ambientes virtuais controlados (on-premisses ou cloud) que restringem as atividades de malware e permitem a análise pós-exploração de códigos maliciosos sem colocar a organização em risco.
Ao usar essas técnicas em conjunto, as equipes de segurança conseguiram criar armadilhas que as alertam quando um comportamento suspeito é detectado, permitindo detectar e analisar com segurança as ameaças de malware antes que causem qualquer dano.
Hoje, o termo deception assumiu um significado muito mais amplo. A tecnologia herdada concentrava-se apenas na criação de infraestrutura semelhante a servidores Linux ou Windows, mas isso não é mais eficaz no cenário de ameaças em constante evolução. Com as infraestruturas em nuvem, as redes definidas por software e o trabalho remoto tem se tornando cada vez mais populares sem o perímetro tradicional para controle dos ativos. Isto significa que métodos inovadores devem ser usados para manter a segurança.
As tecnologias de threat deception modernas oferecem diversos benefícios para a segurança da informação, como baixo falso positivo e integração com outras soluções como SIEM e SOAR. Hoje os ativos “deceptive” são combinados e implantados em toda a rede (distribuída e/ou híbrida), como também nos endpoints corporativos e ou em armazenamentos de credenciais, como o Active Directory.
Considerações importantes:
É importante ressaltar que as tecnologias de deception não são uma solução mágica. Elas devem ser usadas em conjunto com outras medidas de segurança para garantir a proteção completa da organização. Além disso, o uso de iscas pode ser complexo e exige planejamento e expertise. É importante contar com uma equipe qualificada para implementar e gerenciar a solução de forma eficaz.
“Deception efforts need to be balanced with strong incident response workflows as the skill sets required to interpret the output of deception tools and engage in proper response to the identified threats are fairly sophisticated.” Gartner
Nesse bate-papo com o Lucas de Souza conversamos sobre a função de um SRE (Site Reliability Engineering), cultura DevOps, ferramentas e migração de carreira.
A função do SRE requer experiência, conhecimento e habilidades em desenvolvimento de software, administração de sistemas e operações de TI.
As equipes de SRE são responsáveis pela maneira como o código é implantado, configurado e monitorado, bem como pela disponibilidade, latência, gerenciamento de mudanças, resposta a emergências e gerenciamento de capacidade dos serviços em produção.
IEEE 802.1X (também chamado de dot1x) é um padrão IEEE RFC 3748 para controle de acesso à rede. Ele prove um mecanismo de autenticação para hosts que desejam conectar-se a um Switch, por exemplo. A funcionalidade é também bastante poderosa para vínculo de VLANs, VLANs Guest e ACL’s dinâmicas. As funcionalidades do 802.1x permitem por exemplo, que caso um computador não autentique na rede, a máquina seja redirecionada para uma rede de visitantes etc.
O padrão 802.1x descreve como as mensagens EAP são encaminhadas entre um suplicante (dispositivo final, como um host da rede) e o autenticador (Switch ou access point), entre o autenticador e o servidor de autenticação. O autenticador encaminha as informações EAP para o servidor de autenticação pelo protocolo RADIUS.
Uma das vantagens da arquitetura EAP é a sua flexibilidade. O protocolo EAP é utilizado para selecionar o mecanismo de autenticação. O protocolo 802.1x é chamado de encapsulamento EAP over LAN (EAPOL). Atualmente ele é definido para redes Ethernet, incluindo o padrão 802,11 para LANs sem fios.
Os dispositivos que compõem a topologia para o funcionamento do padrão 802.1x são:
Suplicante (Supplicant): um suplicante pode ser um host com suporte a 802.1x com software cliente para autenticação, um telefone IP com software com suporte a 802.1x etc.
Autenticador (Authenticator): Dispositivo (geralmente o Switch, AP, etc) no meio do caminho que efetua a interface entre o Autenticador e o Suplicante. O autenticador funciona como um proxy para fazer o relay da informação entre o suplicante e o servidor de autenticação. O Switch recebe a informação de identidade do suplicante via frame EAPoL (EAP over LAN) que é então verificado e encapsulado pelo protocolo RADIUS e encaminhado para o servidor de autenticação. Os frames EAP não são modificados ou examinados durante o encapsulamento. Já quando o Switch recebe a mensagem do RADIUS do Servidor de autenticação, o cabeçalho RADIUS é removido, e o frame EAP é encapsulado no formato 802.1x e encaminhado de volta ao cliente.
Servidor de Autenticação (Authentication Server): O Servidor RADIUS é responsável pelas mensagens de permissão ou negação após validação do usuário. Durante o processo de autenticação o Authentication Server continua transparente para o cliente pois o suplicante comunica-se apenas com o authenticator. O protocolo RADIUS com as extensões EAP são somente suportados pelo servidor de autenticação.
O suplicante envia uma mensagem start para o autenticador.
O autenticador envia uma mensagem solicitando um login ao suplicante.
O suplicante responde com o login com as credenciais do usuário ou do equipamento.
O autenticador verifica o quadro EAPoL e encapsula-o no formato RADIUS, encaminhando posteriormente o quadro para o servidor RADIUS.
O servidor verifica as credenciais do cliente e envia uma resposta ao autenticador com a aplicação das políticas.
Baseado ne mensagem da resposta, o autenticador permite ou nega o acesso a rede para a porta do cliente.
EAP Types
Os tipos de EAP podem ser divididos em duas categorias: ‘EAP native’ e ‘EAP tunneled’ (que usa um túnel TLS entre o suplicante e o autenticador).
Native EAP Types:
EAP-MD5: Envia as credenciais escondidas em hash. O hash é enviado para o servidor que então compara com o hash local. Entretanto o EAP-MD5 não possui mecanismo para autenticação mútua, o servidor valida o cliente, mas o cliente não valida o servidor de autenticação. EAP-MD5 é geralmente utilizado em telefones IP e também permite alguns Switches utilizar o MAB (MAC authentication Bypass).
EAP-TLS: utiliza TLS para prover a transação de identidade de forma segura. Utiliza certificados X.509 e prove a habilidade de suportar autenticação mútua onde o cliente e o servidor devem confiar o certificado. É considerado o mais seguro tipo de EAP pois a captura da senha não é uma opção; o dispositivo final ainda deve ter uma chave privada.
EAP-MSCHAPv2: As credenciais do cliente são enviadas criptografadas para o servidor com uma sessão MSCHAPv2. Permite uma simples transmissão do usuário e senha, ou mesmo nome do computador e senha para o servidor RADIUS que autentica com o Active Directory (AD).
EAP-GTC: EAP-Generic Token Card foi criado pela Cisco como alternativa para o MSCHAPv2 que permite autenticação genérica para virtualmente armazenar qualquer identidade, incluindo servidor de Token OTP, LDAP, Novel E-Directory, etc.
Tunneled EAP Types:
O modo native EAP envia suas credenciais imediatamente enquanto o tunneled EAP forma primeiro um túnel criptografado e então transmite as credenciais dentro do túnel.
PEAP: Protected EAP (PEAP): foi originalmente proposto pela Microsoft e rapidamente tornou-se popular e largamente implementado. O PEAP forma um túnel criptografado entre o cliente e servidor utilizando o certificado x.509. Após a formação do túnel, o PEAP utiliza outro tipo EAP como método interno, autenticando o cliente utilizando o EAP dentro do túnel, utilizando EAP-MSCHAPv2, EAP-GTC e EAP-TLS.
EAP-FAST: Flexible Authentication via Secure Tunnel (FAST) é similar ao PEAP. Assim como o PEAP, FAST forma um túnel TLS externo e então transmite as credenciais dentro do túnel. A diferença do FAST para o PEAP é a habilidade PAC (protected access credentials). O PAC atua como um cookie seguro, armazenando localmente no host uma prova do sucesso da autenticação. Pode utilizar como EAP interno EAP-MSCHAPv2, EAP-GTC e EAP-TLS.
O modo tunneled EAP inclui o conceito de identidade inner e outer (interna e externa). A identidade inner é o dispositivo que autentica utilizando protocolo native EAP. A identidade outer é utilizado entre o suplicante e o servidor de autenticação para estabelecimento do TLS.
A utilização de VRF (Virtual Routing and Forwarding) em Roteadores e Switches Cisco possibilita a criação de tabelas de roteamentos virtuais que trabalham de forma independente da tabela de roteamento “normal” (geralmente chamada de tabela de roteamento global [Global Routing Table]).
Da mesma forma como a utilização de VLANs em Switches Ethernet permitem a divisão de dominios de broadcasts, a utilização de VRF permite a virtualização da tabela de roteamento.
Apesar da tecnologia VRF ter a sua função vinculada às redes MPLS (por ser largamente utilizado em Provedores e Data Centers) há a possibilidade de criar tabelas de roteamento apenas para funções locais do Roteador, chamado de VRF-lite ou também Multi-VRF.
Você pode ser perguntar: “Mas por qual razão eu precisaria configurar outra tabela de roteamento em meu roteador?
Geralmente as empresas que prestam serviços de TI, monitoração de redes e serviços, precisam lidar com clientes que usam em sua maioria endereços da RFC1918 (endereços IPv4 privados) o que aumenta a probabilidade de mais de um cliente possuir endereços de rede IPv4 iguais (além do fator de segurança) além da complexidade em usar a segregação das redes com NAT e ACL. A utilização de VRFs possibilita a independência das tabelas de roteamento, permitindo que uma tabela de rotas não possua roteamento com as outras.
Além do Roteamento para as interfaces diretamente conectadas é possível também separar as rotas estáticas e protocolos de Roteamento em processos independente para cada VRF
A comunicação entre hosts em uma rede local com o Protocolo IPv6 ocorre com a utilização de mensagens ICMPv6 para descoberta de dispositivos vizinhos no mesmo segmento. O assunto gerou uma discussão bastante saudável em um curso de IPv6 que participamos promovido pelo NIC.br na cidade de SP.
Para o protocolo IP versão 6 foram atribuídas funções importantes ao ICMPv6 que combinam as atividades de protocolos como o ARP, ICMP Router Discover, ICMP Redirect e etc, além de adicionar novos métodos não existentes na versão anterior do protocolo IP. A facilidade de comunicação entre equipamentos é muito prática e em determinados cenários dispensa configuração.
A eliminação de endereços broadcast para descoberta de dispositivos da mesma sub-rede para o IPv6 foram substituídas por mensagens com endereços Multicast como All-Routers, All-nodes, Solicited-Node, etc.
Para a comunicação entre dispositivos na LAN são utilizada as mensagens NS (Neighbor Solicitation, ICMPv6 tipo 135) e NA (Neighbor Advertisement, ICMPv6 tipo 136) para mapeamento de endereço de rede e da camada de enlace.
Para a auto-configuração chamada de stateless de endereços globais (únicos, com acesso a Internet) para dispositivos da LAN, são utilizadas mensagens RS (Router Solicitation , ICMPv6 tipo 133) e RA (Router Advertisement, ICMPv6 tipo 134). Nesse caso o roteador encaminhará o prefixo de rede no segmento e os dispositivos interessados “anexarão” dinamicamente porção de host (gerada do endereço MAC ou aleatóriamente para criar seu endereço global IPv6).
Os protocolos de descoberta de vizinhos e descoberta de roteadores traz a possibilidade de cenários como a automação residencial onde todos os equipamentos de uma casa conversam entre si e possuem acesso a Internet.
Com o crescimento dos Data Centers, da virtualização de máquinas e de serviços de Cloud, surge a necessidade de estender as VLANs através ou além dos DCs.
Para conseguir manter a utilização dos recursos computacionais de maneira eficiente, há uma tendência de utilizar VMs pertencentes a um ambiente compartilhado em inúmeras localizações físicas e estas VMs devem mover-se entre diferentes localizações sob demanda. Mas a movimentação de VMs necessita que a máquina retenha o endereço MAC e IP para que o processo ocorra de maneira transparente para as camadas superiores como a de Aplicação. Este é um grande desafio para o modelo tradicional de Data Center, onde VMs necessitam mover-se dentro de um tradicional domínio de broadcast.
Para suportar a mobilidade de VMs entre PODs em um DC, ou sites, a rede deve ser desenhada como uma grande rede L2, o que acarreta várias limitações que precisam ser reendereçadas:
– Primeiro: Devido a virtualização de servidores, cada máquina virtual (VM) requer um endereço MAC único e um endereço IP. A escalabilidade da tabela de endereços de camada 2 é uma das grandes preocupações em Data Centers virtualizados. Com a virtualização, o número de endereços MAC por porta pode atingir de 50 a 100 VMs por servidor, sobrecarregando assim os Switches ToR (Top-of-Rack) ou da camada de aggregação. Com isso após a tabela MAC dos Switches atingir o limite, uma parte do tráfego começa a ser “inundado” por toda a rede, resultando em um grande fluxo de dados desnecessário.
– Outro ponto importante é a extensão de VLANs pelos Switches do DC que se torna uma tarefa complexa quando planejamos uma implantação fim-a-fim pelo Data Center.
– Com a utilização do STP para fornecer uma topologia livre de loops de camada 2, o protocolo Spanning-Tree desativa links redundantes. Assim, Equal-Cost Multi-Path (ECMP) não é habilitado. No entanto, 0 ECMP é fácil de habilitar em uma rede IP.
VXLAN
O padrão VXLAN (Virtual eXtensible Local Area Network) trabalha em cima da limitação da quantidade de VLANs em um Data Center que é a de 4K VLANs. O Protocolo VXLAN emprega MAC sobre IP/UDP, e permite assim aumentar o número de domínios de Broadcast para 16 milhões.
O VXLAN é uma rede de camada 2 sobreposta em uma rede de camada 3. Cada rede sobreposta é chamada de segmento VXLAN e é identificada por um ID único de 24 bits chamado VNI – VXLAN Network Identifier (Identificador de Rede VXLAN) ou VXLAN ID. Já a identificação de uma máquina virtual é uma combinação do endereço MAC e o VNI.
As Máquinas virtuais em VXLAN diferentes não podem comunicar umas com as outras (sem a utilização de um roteador). O pacote original enviado pela VM na camada 2 é encapsulado em um cabeçalho VXLAN que inclui o VNI associado ao segmento VXLAN que aquela máquina virtual pertence.
O encapsulamento do quadro é feito pelo equipamento que está na extremidade do túnel VXLAN, que é chamado de VTEP (VXLAN Tunnel Endpoint).
O VTEP pode ser tanto ser implementado como um módulo de software em um Switch Virtual, em um Servidor ou em um Switch Top-of-Rack (ToR). Uma interface VTEP é vinculada a um endereço IP único e pode ser considerada equivalente a uma interface loopback.
Quando uma VM quer comunicar com outra VM no mesmo segmento, o VTEP vinculado à VM atribui o encapsulamento adequado da VXLAN, inserindo o cabeçalho VXLAN, sobre o cabeçalho original, colocando o endereço IP de origem do VTEP (como Source IP Address [SIP] nesse novo cabeçalho) e o endereço de destino (Destination IP Address [DIP]) correspondente ao VTEP que a VM de destino reside. Quando o pacote é recebido pelo VTEP de destino, o cabeçalho VXLAN é removido e o pacote interno e é encaminhado para a VM de destino.
O VTEP mantém uma tabela de endereços MAC aprendidos e armazena o endereço IP do túnel para o VTEP remoto. Quadros unicast entre VMs são enviadas diretamente para o endereço unicast L3 do VTEP remoto. Os pacotes multicast e broadcast das VMs são enviados a um grupo IP multicast associado à VNI, o VTEP remoto recebe o quadro multicast, encaminha o pacote a máquina destino (efetuando todos os mapeamentos do VTEP e VM de origem. A VM de destino faz uma resposta ARP normalmente em unicast. O VTEP encapsula o pacote ARP com o padrão VXLAN e encaminha o quadro para o VTEP da VM de origem….
Consequentemente, um segmento VXLAN “estendido” requer:
Um Grupo IP Multicast associado
Roteamento Multicast entre os VTEP
Mas como é feita a comunicação com equipamentos não-virtualizados?
Uma das maneiras de permitir a conexão entre VXLAN e uma VLAN tradicional é através de um equipamento (virtual ou não) chamado de VXLAN Gateway.
A funcionalidade do Gateway VXLAN pode ser embutida no VTEP, fazendo o mapeamento para substituição do encapsulamento VXLAN para cabeçalho 802.1Q e assim por diante, tendo a responsabilidade como um ponto de entrada e saída de uma nuvem VXLAN.
Pelas características de funcionamento para o Gateway VXLAN entre o ambiente físico e virtual, encontramos essa função em documentações atribuída como Layer 2 VXLAN Gateway (ou Gateway VXLAN de Camada 2).
Já para o roteamento entre VXLANs essa função é atribuída ao VXLAN Gateway, também chamada de Layer 3 VXLAN Gateway.
Durante o recebimento de pacotes para acessar outras Redes externa a LAN para comunicação entre máquinas IPv6, o roteador efetuará uma consulta na sua tabela de roteamento IPv6 para verificar se existe alguma rota para o destino. Se a rota existir o pacote será encaminhado, senão, o pacote será descartado.
A maior parte dos parâmetros de configuração de rotas estáticas em IPv6 são idênticos ao IPv4. Como por exemplo, rota estática padrão, sumarizada e flutuante.
O next-hop (ou próximo salto) pode ser identificado por um endereço IPv6, interface de saída ou ambos.
É possível verificar a tabela de roteamento IPv6 com o comando show ipv6 route.
A rota “ipv6 route ::0 0 [próximo-salto]” é uma “rota padrão” e corresponde a qualquer prefixo IPv6 (utilizado quando uma rota específica não é encontrada na tabela de roteamento).
Exemplo de Configuração
Antes de iniciar a configuração de rotas estáticas IPv6, habilite o encaminhamento de pacotes IPv6 configurando ipv6 unicast-routing no modo de configuração global.
Endereço do next-hop como link-local
Caso haja a necessidade de configurar o endereço de next-hop como endereço IPv6 link-local, é necessário configurar a interface de saída, como no exemplo abaixo:
Para validar as rotas configuradas resumimos alguns comandos abaixo:
Router# ping ipv6 [endereço do host em IPv6]
!Testes de PingRouter# traceroute [endereço do host em IPv6]
!Testes de traceroutRouter# show ipv6 route
!Verificar tabela de roteamento IPv6Router# show ipv6 interface [interface com endereço IPv6 no roteador]
! Verifique todos os endereços IPv6 da interface ( global, link-local, etc)
RotaDefault 