O Controle de Acesso à Rede, ou NAC (Network Access Control) tem como objetivo proteger a rede contra ameaças, garantindo que apenas dispositivos autorizados e em conformidade com as políticas de segurança tenham acesso à rede.
Redes
macof
A ferramenta macof inunda a rede local com endereços MAC randômicos forçando alguns switches a atuarem como repetidores, permitindo ao atacante praticar o sniffing da rede.
Pode também ser utilizada em testes para validação de funcionalidades de segurança da rede, como o port-security, pentest e provas de conceito. https://www.youtube.com/embed/eG50DlUZEt8
Como escolher um transceiver para o seu switch, controladora e roteador Cisco?
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.
802.1X
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.
Referências
CCNP Security SISAS 300-208 Official Cert Guide, Cisco Press 2015, Aaron Woland and Kevin Redmon
http://blog.ccna.com.br/2009/02/25/pr-o-que-e-8021x/
https://tools.ietf.org/html/rfc3748
VRF (Virtual routing and forwarding)
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
Outras referências
http://www.cocheno.com/2012/08/introducao-ao-vrf-lite/
http://labcisco.blogspot.com.br/2013/01/configuracao-da-nuvem-mpls-em-provedores.html
http://www.comutadores.com.br/vrf-em-switches-e-roteadores-hpn-vpn-instance/
http://packetlife.net/blog/2009/apr/30/intro-vrf-lite/
IPv6 – Descoberta de Roteadores e Descoberta de Vizinhos
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.
Introdução a VXLAN
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.
Imagem copiada do site da http://blogs.cisco.com/datacenter/cisco-vxlan-innovations-overcoming-ip-multicast-challenges/
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.
Referência
http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2012_2/nvgre/vxlan.html
http://networksbase.blogspot.in/2012/09/vxlan.html
http://codingrelic.geekhold.com/2011/09/care-and-feeding-of-vxlan.html
Data Center Virtualization Fundamentals – Cisco Press – 2013 – Gustavo A.A. Santana
Using TRILL, FabricPath, and VXLAN – Cisco Press 2014 – Sanjay K. H., Shuyam Kapadia,Padmanabhan Krishnan.
Configuração de rota estática IPv6
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.
Abaixo a sintaxe de um roteador Cisco IOS:
Router(config)# ipv6 route rede/prefixo [próximo-salto]
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:
Router(config)#ipv6 route 2001:DB8:222::/64 FastEthernet0/0 FE80::C802:71FF:FEFC:
Testes
Para validar as rotas configuradas resumimos alguns comandos abaixo:
Router# ping ipv6 [endereço do host em IPv6] !Testes de Ping Router# traceroute [endereço do host em IPv6] !Testes de tracerout Router# show ipv6 route !Verificar tabela de roteamento IPv6 Router# show ipv6 interface [interface com endereço IPv6 no roteador] ! Verifique todos os endereços IPv6 da interface ( global, link-local, etc)
Até logo.
DIG
O comando ‘dig’ é uma ferramenta para consultar servidores DNS a fim de obter informações sobre endereços de host, servidores de email (MX), servidores de nomes (NS) e informações relacionadas. Esta ferramenta pode ser usada a partir de qualquer sistema operacional Linux (Unix) ou OS X nativamente. É a melhor ferramenta para diagnosticar e entender rapidamente as respostas do DNS.
Abaixo, fizemos uma pequena compilação para consulta de registros A, NS e MX.
Execute o comando
dig rotadefault.com.br ; <<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21507 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;rotadefault.com.br. IN A ;; ANSWER SECTION: rotadefault.com.br. 3600 IN A 191.252.51.69 ;; AUTHORITY SECTION: rotadefault.com.br. 86400 IN NS ns1.locaweb.com.br. rotadefault.com.br. 86400 IN NS ns2.locaweb.com.br. ;; ADDITIONAL SECTION: ns1.locaweb.com.br. 1283 IN A 189.126.108.2 ns2.locaweb.com.br. 83435 IN A 201.76.40.2 ns1.locaweb.com.br. 368 IN AAAA 2804:218:d1::ca5a ns2.locaweb.com.br. 60858 IN AAAA 2804:218:d2::cafe ;; Query time: 127 msec ;; SERVER: 181.213.132.2#53(181.213.132.2) ;; WHEN: Mon Oct 16 10:34:28 -02 2017 ;; MSG SIZE rcvd: 195
Olhando de perto
<<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21507
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
HEADER: exibe o número de versão do comando dig, as opções globais usadas pelo comando dig e algumas informações de cabeçalho adicionais. O status é um ponto importante; neste caso, não houve nenhum erro informado. Este campo pode mostrar um dos seguintes status quando uma consulta é solicitada:
- NOERROR: Tudo ok. A zona está sendo atendida pela autoridade solicitada sem problemas.
- SERVFAIL : O nome que foi consultado existe, mas não há dados ou os dados são invalidos para esse nome na autoridade requerida.
- NXDOMAIN: Non-Existent Domain – O nome em questão não existe e, portanto, não há dados DNS autenticados a serem atendidos. Como no exemplo abaixo:
dig testerotadefault.com.br ; <<>> DiG 9.9.3-P2 <<>> testerotadefault.com.br ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23792 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
- REFUSED: O servidor de nomes se recusa a executar a operação por motivos de política. Por exemplo, um servidor de nomes pode não querer fornecer a informação ao solicitante especifico ou um servidor de nomes pode não desejar executar uma operação específica (por exemplo, transferência de zona) para dados específicos.
Para as flags, do cabeçalho temos as seguintes opções:
QUESTION SECTION: Exibe as questões feitas ao DNS, por exemplo, uma vez que digitamos ‘dig rotadefault.com.br’, indicará nessa sessão a ser consultada para um registro A do site rotadefault.com.br.
;; QUESTION SECTION:
;rotadefault.com.br. IN A
ANSWER SECTION: Exibe a resposta que recebe do DNS. Exibe o registro A record de rotadefault.com.br;
;; ANSWER SECTION:
rotadefault.com.br. 3600 IN A 191.252.51.69
Veja que o TTL está em 3600 segundos, equivalente a uma hora.
AUTHORITY SECTION: Exibe o nome do servidor DNS que tem autoridade para responder essa consulta.
;; AUTHORITY SECTION:
rotadefault.com.br. 86400 IN NS ns1.locaweb.com.br.
rotadefault.com.br. 86400 IN NS ns2.locaweb.com.br.
ADDITIONAL SECTION: Exibe o endereço IP do servidor de nomes listados em AUTHORITY SECTION.
;; ADDITIONAL SECTION:
ns1.locaweb.com.br. 1283 IN A 189.126.108.2
ns2.locaweb.com.br. 83435 IN A 201.76.40.2
ns1.locaweb.com.br. 368 IN AAAA 2804:218:d1::ca5a
ns2.locaweb.com.br. 60858 IN AAAA 2804:218:d2::café
Exibindo apenas ANSWER SECTION da saída do comando ‘dig’
A grande parte das nossas consultas apenas procura a “ANSWER SECTION” do comando dig. Conforme comandos abaixo, podemos omitir algumas saídas:
+nocomments: Não exibe a linha de comentários;
+noauthority: Não exibe a saída autoritativa;
+noadditional : Não exibe ‘additional section’;
+nostats: Não exibe ‘stats section’;
+noanswer: Não exibe answer section.
+noall: Não exibe os resultados mas se utilizado como +noall +answer irá exibir somente as respostas;
+short: Exibe a resposta em um formato mínimo.
dig www.rotadefault.com.br +nocomments ; <<>> DiG 9.9.3-P2 <<>> www.rotadefault.com.br +nocomments ;; global options: +cmd ;rotadefault.com.br. IN A rotadefault.com.br. 1279 IN A 191.252.51.69 dig rotadefault.com.br +noall +answer ; <<>> DiG 9.10.3-P4-Debian <<>> rotadefault.com.br +noall +answer ;; global options: +cmd rotadefault.com.br. 3533 IN A 191.252.51.69 dig rotadefault.com.br +short 191.252.51.69
Consultando registros MX , NS, A, TXT, etc.
A consulta de diferentes registros DNS podem ser executados com os argumentos inseridos na consulta como:
dig uol.com.br MX
dig uol.com.br MX +answer +nocomments ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br MX +answer +nocomments ;; global options: +cmd ;uol.com.br. IN MX uol.com.br. 14397 IN MX 10 mx.uol.com.br.
dig uol.com.br NS
dig uol.com.br NS +short eliot.uol.com.br. borges.uol.com.br. charles.uol.com.br.
dig uol.com.br A
dig uol.com.br A +answer +nocomments ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br A +answer +nocomments ;; global options: +cmd ;uol.com.br. IN A uol.com.br. 11 IN A 200.221.2.45
dig uol.com.br ANY
dig uol.com.br ANY ; <<>> DiG 9.10.3-P4-Debian <<>> uol.com.br ANY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58271 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;uol.com.br. IN ANY ;; ANSWER SECTION: uol.com.br. 3554 IN SOA eliot.uol.com.br. root.uol.com.br. 2016038165 7200 3600 432000 900 uol.com.br. 254 IN A 200.147.67.142 uol.com.br. 254 IN A 200.221.2.45 uol.com.br. 254 IN AAAA 2804:49c:3103:401:ffff:ffff:ffff:1 uol.com.br. 17954 IN MX 10 mx.uol.com.br. uol.com.br. 14 IN TXT "DZC=qvK68EJ" uol.com.br. 14 IN TXT "v=spf1 include:_net1.uol.com.br include:_net2.uol.com.br -all" uol.com.br. 3554 IN NS charles.uol.com.br. uol.com.br. 3554 IN NS borges.uol.com.br. uol.com.br. 3554 IN NS eliot.uol.com.br.
Consulta do reverso com -x
dig -x 200.147.67.142 +short 200-147-67-142.static.uol.com.br.
Caso você queira forçar a consulta utilizando um servidor DNS diferente da sua máquina use o @ip_servidor_dns
dig uol.com.br @4.2.2.2 ; <<>> DiG 9.9.3-P2 <<>> uol.com.br @4.2.2.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51526 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;uol.com.br. IN A ;; ANSWER SECTION: uol.com.br. 1 IN A 200.147.67.142
Se vocês tiverem alguma dica, algum comando secreto… especial, deixe nos comentários.
Referências
https://ns1.com/articles/decoding-dig-output
https://mediatemple.net/community/products/dv/204644130/understanding-the-dig-command
Rota estática flutuante (floating static route)
Uma rota estática flutuante é uma rota com uma distância administrativa maior do que a estabelecida por padrão em Switches e Roteadores. Por exemplo, no IOS da Cisco as rotas estáticas possuem distância administrativa com o valor 1 e o protocolo OSPF com o valor 110, nesse caso pelo fato da menor distância administrativa ser escolhida quando duas rotas idênticas (com a mesma “rede” e “máscara de rede”) são aprendidas de maneiras distintas pelo roteador, o dispositivo escolherá o processo com menor AD ( administative distance/ distancia administrativa).
Como exemplo, poderíamos imaginar um roteador com 2 links, em um deles a rota 192.168.1.0/24 pode ser aprendida via OSPF e nesse caso precisaremos encaminhar o tráfego para esse link como principal. Já como backup configuraríamos a rota estática 192.168.1.0/24 com a distância administrativa com o valor 250 apontando para o next-hop do segundo link.
Quando o primeiro link apresentar problemas, o processo OSPF perceberá a falha e removerá a rota 192.168.1.0/24 aprendida dinamicamente e começará a utilizar a rota estática (não utilizada anteriormente) com o mesmo endereço 192.168.1.0/24 configurada para encaminhar os pacotes para o segundo link.
Quando o OSPF voltar a funcionar com o restabelecimento do primeiro link (incluindo novamente a rota 192.168.1.0/24 de maneira dinâmica), a rota estática deixará de ser utilizada.
Rt(config)# ip route 192.168.1.0 255.255.255.0 172.17.1.2 250
Obs: Lembre-se que a rota estática só entrará na tabela de roteamento se a interface correspondente ao próximo salto (next-hop) estiver UP.
Caso tenham alguma dúvida sobre o assunto, deixe um comentário.
RotaDefault 