Configurando MPLS Traffic Engineer em roteadores cisco

Share Button

English Title: Configuring MPLS Traffic Engineer in cisco routers

Nesse simples artigo irei demostrar como configurar uma rede em formado de malha usando OSPF, e realizando engenharia de trafego com MPLS.

Para criar essa topologia utilizei o GNS3 como emulador. Emulei 4 routers cisco 7200 mais 2 Mikrotiks emulados com o QEMU apenas para ter um terminal para os testes.

Depois de criar a rede MPLS criei um túnel MPLS-TE entre o router-1 e router-2 e propositalmente farei com que o trafego entre o router-1 e 2 passe por todos os routers (caminho mais longo) para chegar ao seu destino.

Segue topologia:
topology

Sendo assim mãos a obra. Segue configurações que realizei em cada equipamento.
ROUTER-01

hostname cisco-R1
ip cef
mpls traffic-eng tunnels
interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 10.10.10.2
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth  100000
 tunnel mpls traffic-eng path-option 1 explicit name VOLTA
 no routing dynamic
!
interface Loopback0
 ip address 10.10.10.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.1.1 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet1/0
 ip address 10.0.2.1 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet1/1
 ip address 192.168.11.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 log-adjacency-changes
 no auto-cost
 network 10.0.0.0 0.0.0.255 area 0
 network 10.0.1.0 0.0.0.255 area 0
 network 10.0.2.0 0.0.0.255 area 0
 network 10.10.10.1 0.0.0.0 area 0
 network 192.168.11.0 0.0.0.255 area 0
!
ip explicit-path name VOLTA enable
 next-address 10.10.10.3 
 next-address 10.10.10.4 
!

Foi configurando também em cada interface que faz parte do MPLS a velocidade de 100Mbps nesse cenário todas as interfaces são FastEthernet.

Também foi configurado a velocidade do tunnel com o comando:

tunnel mpls traffic-eng bandwidth  100000

Caso necessite diminuir a velocidade que esse túnel pode alcançar basta diminuir esse valor.

E também foi configurado o caminho que sera utilizado para entre o túnel com os comandos:

tunnel mpls traffic-eng path-option 1 explicit name VOLTA
ip explicit-path name VOLTA enable
 next-address 10.10.10.3 
 next-address 10.10.10.4 
!

E da mesma forma configurei o router-2 que nesse caso é a outra ponta do tunnel.

ROUTER-02

hostname cisco-R2
ip cef
mpls traffic-eng tunnels
interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 10.10.10.1
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng priority 0 0
 tunnel mpls traffic-eng bandwidth  100000
 tunnel mpls traffic-eng path-option 1 explicit name VOLTA
 no routing dynamic
!
interface Loopback0
 ip address 10.10.10.2 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.3.1 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet0/1
 ip address 10.0.0.2 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet1/0
 ip address 192.168.10.1 255.255.255.0
 duplex auto
 speed auto
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 log-adjacency-changes
 network 10.0.0.0 0.0.0.255 area 0
 network 10.0.3.0 0.0.0.255 area 0
 network 10.10.10.2 0.0.0.0 area 0
 network 192.168.10.0 0.0.0.255 area 0
!
ip explicit-path name VOLTA2 enable
 index 8 next-address 10.10.10.4 
 next-address 10.10.10.3 
!

ROUTER-03

hostname cisco-R3
ip cef
mpls traffic-eng tunnels
interface Loopback0
 ip address 10.10.10.3 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.4.1 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet0/1
 ip address 10.0.1.2 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 log-adjacency-changes
 network 10.0.1.0 0.0.0.255 area 0
 network 10.0.4.0 0.0.0.255 area 0
 network 10.10.10.3 0.0.0.0 area 0
!

ROUTER-04

hostname cisco-R4
ip cef
mpls traffic-eng tunnels
interface Loopback0
 ip address 10.10.10.4 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.0.3.2 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet0/1
 ip address 10.0.4.2 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
interface FastEthernet1/0
 ip address 10.0.2.2 255.255.255.252
 duplex auto
 speed auto
 mpls traffic-eng tunnels
 ip rsvp bandwidth 100000
!
router ospf 1
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 log-adjacency-changes
 network 10.0.2.0 0.0.0.255 area 0
 network 10.0.3.0 0.0.0.255 area 0
 network 10.0.4.0 0.0.0.255 area 0
 network 10.10.10.4 0.0.0.0 area 0
!

E também as configurações realizadas nos mikrotiks.

MIKROTIK-01

/ip address add adress=192.168.10.2/24 interface=ether1
/ip route add gateway=192.168.10.1

MIKROTIK-04

/ip address add adress=192.168.11.2/24 interface=ether1
/ip route add gateway=192.168.11.1

Vejam os testes realizados entre os mikrotiks.

Captura de tela de 2014-07-06 20:36:19

E a tabela de roteamento OSPF do router-01

Captura de tela de 2014-07-06 20:37:22

É isso, espero ter ajudado.

 

 

Diferenças entre Deliberant APC v2 e v3

Share Button

English title: The difference between Deliberant APC v2 and V3

5M_v2_vs_v3

 

E-mail ‘seguro’ do governo terá ‘porta dos fundos’, admite Serpro

Share Button

via: br-linux.org – g1.globo.com

Um executivo do Serviço de Processamento de Dados do governo federal (Serpro) admitiu que o sistema de e-mail seguro do governo, chamado de Expresso, terá uma “porta dos fundos” ou “backdoor” – uma “chave mestra” que permitirá ler qualquer mensagem protegida pelo sistema.

“Por lei, pelo Marco Civil da Internet, eu tenho que garantir a auditabilidade desses meios de comunicação. Se eu uso criptografia ponto a ponto, como as boas práticas nos indicam, eu faço com que aquela criptografia seja invisível para qualquer outra pessoa. Se eu não tiver um modelo HSM de chave mestra, ela passa a ser não auditável. Ou seja, eu estou descumprindo questões legais”, afirmou o coordenador de ações governamentais do Serpro.

govern-sempro

A declaração foi feita pelo executivo durante o 12º Fórum de Certificação Digital (CertForum) nesta quarta-feira (28), em resposta a um questionamento feito por Paulo Roque, da Associação Brasileira das Empresas de Software (Abes). Há um vídeo disponível na web com a pergunta de Roque e a resposta.

O Marco Civil da Internet não determina especificações para requerimentos de auditoria de conteúdo das comunicações, apenas de registros de acesso, que normalmente não sofrem interferência de criptografia em conteúdo. A lei possui, no entanto, algumas regras específicas para administração pública. O coordenador não informou qual artigo especificamente do Marco Civil, ou de outra legislação, exige que o sistema do governo tenha a “chave mestra”.

Não é mais teoria: já se conhece um caso de servidor OpenVPN comprometido via bug Heartbleed

Share Button

De uma tacada só, os atacantes usaram o Heartbleed para dar a volta tanto no sistema de autenticação de múltiplos fatores e no sistema de verificação que buscava garantir que os clientes da sua VPN pertenciam à empresa e estavam rodando determinados sistemas de segurança.

Embora só na quinta-feira tenha circulado amplamente a informação sobre a infame vulnerabilidade no OpenSSL também afetar o OpenVPN, o ataque bem-sucedido ao concentrador de VPNs de uma corporação de grande porte que foi divulgado ontem iniciou há quase 2 semanas, já no dia 8 – um dia depois da divulgação da existência do próprio bug Heartbleed, inicialmente associado a um risco contra servidores web (https).

Não foi divulgada qual a empresa afetada, só que ela é de grande porte e conta com meios avançados de detecção de ataques – mas eles não foram suficientes para evitar que este ataque em particular se consumasse. Seus logs indicam que apenas 17.000 tentativas de leitura de memória por meio do bug foram necessárias.

Ao contrário do que ocorre com servidores web, este ataque bem-sucedido a um servidor OpenVPN não tentou obter senhas ou outras informações pessoais dos usuários, mas sim ter acesso a tokens confirmando a autenticação bem-sucedida de sessões existentes – e aí os atacantes usaram esses tokens para sequestrar as conexões dos usuários legítimos, usando-as.

heartbleed-vpn-hacked

Como o primeiro caso conhecido ocorreu no dia 8, é possível que o seu procedimento de segurança exija que você faça revisão dos logs dos seus próprios servidores OpenVPN. Se for o caso, os responsáveis pela identificação da invasão acima sugerem que você pesquise por situações em que mais de um IP usou a mesma sessão VPN paralelamente – meras mudanças de IP ao longo da sessão são comum em casos legítimos, mas o uso simultâneo por 2 IPs é um forte indício de que havia algo estranho – como um sequestro de sessão – em andamento. Feliz Páscoa! (via arstechnica.com – “Heartbleed maliciously exploited to hack network with multifactor authentication | Ars Technica”)

Original link: http://www.br-linux.org/2014/01/nao-e-mais-teoria-ja-se-conhece-um-caso-de-servidor-openvpn-comprometido-via-bug-heartbleed.html

Nagios – Checando erros de configuração

Share Button

English title: Nagios Checking errors of configuration. 

Configurar os arquivos do Nagios incluir novos hosts novos groups ou services é uma tarefa bem árdua. Principalmente quando se gerencia uma grande quantidade de hosts e services nesses arquivos.

Como muitos aqui devem sabem para o Nagios um ponto e virgula (;) fora do lugar correto resulta em não poder restartar o serviço novamente, sendo assim após uma alteração caso o usuário restart o serviço fica difícil descobrir onde esta o erro de configuração, e quando falamos de erro por integrante de um grupo de hosts fica muito mais difícil.

Recentemente procurando uma alternativa para auxiliar os usuários a encontrarem os erros com maior facilidade, acabe me deparando com uma maneira bem simples que o próprio Nagios disponibiliza.

O comando consiste em executar como root:

#[arquivo binario do nagios] -v [caminho do arquivo de conf padrão do nagios]

Caso a instalação do seu Nagios esteja feita no local padrão /usr/local basta executar como root:

#/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

A saida do comando será:

Checking services...
Checked 100 services.
Checking hosts...
Checked 36 hosts.
Checking host groups...
Checked 12 host groups.
Checking service groups...
Checked 0 service groups.
Checking contacts...
Checked 5 contacts.
Checking contact groups...
Checked 5 contact groups.
Checking service escalations...
Checked 0 service escalations.
Checking service dependencies...
Checked 0 service dependencies.
Checking host escalations...
Checked 0 host escalations.
Checking host dependencies...
Checked 0 host dependencies.
Checking commands...
Checked 34 commands.
Checking time periods...
Checked 5 time periods.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors: 0

Things look okay - No serious problems were detected during the pre-flight check

Com esse resultado é possível verificar as checagens de cada arquivo de configuração e no final é mostrando o total de Warnings e errors, informando também que não foi encontrado problemas dessa forma podemos dar o restart o serviço do para que as alterações tenham efeito.

#/etc/init.d/nagios restart