Aplicando Filtro e Monitorando pacotes em Juniper Parte 2

 No artigo anterior nos falamos sobre filtro no JUNOS e como monitorar o trafico passante pela interface. Ação comum e necessária em trobleshooting de redes.
 Hoje vou mostrar um filtro um pouco mais elaborado. A idéia dessa filtro é bloquear o acesso http ao device e permitir  o resto.
  Vamos a config:

root@Sinapse# edit firewall family inet

[edit firewall family inet]
root@Sinapse# show
filter Block_HTTP {
    term port-80 {
        from {
            source-address {
                192.168.62.0/24;
            }
            protocol tcp;
            destination-port http;
        }
        then {
            reject;
        }
    }
    term Permit_all_else {
        then accept;
    }
}

 Vamos lá. Foi criado um filtro chamado Block_HTTP e dentro desse filtro foram criados dois term. O primeiro term bloqueia acessos vindo da rede 192.168.62.0/24 com protocolo tcp na porta http.
O segundo term não permite nada específico. Porém, a não adicao desse term, causaria todas as portas serem bloqueadas.
Não podemos esquecer que, assim como nas ACL do IOS, os term do  JUNOS também possui um deny any implícito. Desta forma, adicionar um filtro permitindo, após um único filtro bloqueando, é fundamental.


Agora vamos ver os tráfico passando pela interface:









root@Sinapse> monitor traffic detail interface em0 matching "port  80"
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em0, capture size 1514 bytes

Reverse lookup for 192.168.62.100 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

02:51:15.038586  In IP (tos 0x0, ttl 128, id 13151, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58473 > 192.168.62.100.http: S 3234236900:3234236900(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:15.295991  In IP (tos 0x0, ttl 128, id 13152, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58474 > 192.168.62.100.http: S 1097943701:1097943701(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:16.327213  In IP (tos 0x0, ttl 128, id 13154, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58475 > 192.168.62.100.http: S 2398065096:2398065096(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:16.581450  In IP (tos 0x0, ttl 128, id 13155, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58476 > 192.168.62.100.http: S 2117150508:2117150508(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
02:51:17.982157  In IP (tos 0x0, ttl 128, id 13157, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.62.151.58473 > 192.168.62.100.http: S 3234236900:3234236900(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

 Como existem outros fluxos passando pela interface, fiz um filtro para capturar apenas a porta 80. O monitor é como o tcpdump e como tal é muito flexível.

 E assim concluo esse artigo. Simples mas de importância em um trobleshooting. A medida que for estudando sobre esse magnífico JUNOS, vou postando mais configurações aqui.

Aplicando Filtro e Monitorando pacotes em Juniper.

 Tenho estudado Juniper nos últimos dias e estou realmente impressionado.  Juniper surpreende em muitos aspectos. Umas das funcionalidades que mais me chamou a impressão, logo de cara, foi a possibilidade de ter um "tcpdump" a nível de Junos com o comando 'monitor traffic interface'. Para quem realiza constantes troubleshooting em equipamentos de redes, essa funcionalidade é realmente uma mão na roda.

root@sre-sc-a> monitor traffic interface em0 detail
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em0, capture size 1514 bytes

Reverse lookup for 172.16.1.1 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

20:57:50.855750  In IP (tos 0x0, ttl  64, id 8762, offset 0, flags [none], proto: ICMP (1), length: 84) 172.16.1.2 > 172.16.1.1: ICMP echo request, id 774, seq 0, length 64
20:57:50.855996 Out IP (tos 0x0, ttl 255, id 6372, offset 0, flags [DF], proto: ICMP (1), length: 56) 172.16.1.1 > 172.16.1.2: ICMP host 172.16.1.1 unreachable - admin prohibited filter, length 36
        IP (tos 0x0, ttl  64, id 8762, offset 0, flags [none], proto: ICMP (1), length: 84) 172.16.1.2 > 172.16.1.1: ICMP echo request, id 774, seq 0, length 64
20:57:51.890619  In IP (tos 0xc0, ttl   1, id 8763, offset 0, flags [none], proto: OSPF (89), length: 80) 172.16.1.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
       
 A saída do comando acima é um  exemplo da funcionalidade. Vejam que a saída é parecida com o tcpdump. Nesse caso, um dos fluxos registrado foi um ping vindo do IP 172.16.1.2 e veja que interessante:
ICMP host 172.16.1.1 unreachable - admin prohibited filter

 O equipamento está avisando que houve um bloqueio devido a uma ACL, ou, Filtro, como é referido pela Juniper. Agora vejamos onde o ping foi originado:

64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=29.344 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=9.431 ms
36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216b   0 0000  40  01 ff1a 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216c   0 0000  40  01 ff19 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216e   0 0000  40  01 ff17 172.16.1.2  172.16.1.1

 Podemos ver que o ping está acontecendo com sucesso até que um filtro foi aplicado no destino. Imediatamente a origem passou a ser avisada que a comunicação foi proibida devido a uma ACL.

 Como é inevitável  a comparação, isso não se vê em equipamentos Cisco.
Existem muitas situações em que nos vemos obrigados a provar que não há bloqueio em Firewall. Com Juniper, isso não se faz necessário.

 Vamos ver agora como criar um Filtro e como aplicar esse filtro.



edit firewall filter sample-filter term block-bad-subnet from

 Essa primeira linha cria um filtro chamado sample-filter. Ao inves de linhas, como  o IOS, o Junos usa 'term' para diferenciar as váras entradas em um filtro. Em nosso exemplo, usamos o term block-bad-subner


set source-address 172.16.1.2/32




 Com essa linha, definimos o trafico que queremos permitir ou bloquear. Reparem que, até aqui, ainda não definimos qual vai ser a política.

edit firewall filter sample-filter term block-bad-subnet then reject


Nessa linha,então, definimos que nossa política é reject.

edit interfaces em0 unit 0 family inet filter
set input sample-filter

Por último, nós aplicamos o filtro a uma das interfaces.


64 bytes from 172.16.1.1: icmp_seq=10 ttl=64 time=1.393 ms
64 bytes from 172.16.1.1: icmp_seq=11 ttl=64 time=29.344 ms
64 bytes from 172.16.1.1: icmp_seq=12 ttl=64 time=9.431 ms
36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216b   0 0000  40  01 ff1a 172.16.1.2  172.16.1.1

36 bytes from 172.16.1.1: Communication prohibited by filter
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 216c   0 0000  40  01 ff19 172.16.1.2  172.16.1.1

 E aqui podemos ver o ping informando que está sendo barrado por um filtro.


Desta forma concluímos nosso primeiro post técnico sobre Juniper. Como disse acima, Juniper é surpreendente.

Emulando JUNOS no QEMU em Windows 7.

   QEMU, em conjunto com GNS3, é uma das maiores invensões em termos de software que eu já vi. Se não pela complexidade, é pela importância. Todos que buscam aperfeiçoamento na área de redes, como eu, e não dispoe de recurso para comprar equipamentos reais,como eu, GNS3 é uma plataforma fundamental.
 Hoje vou escrever um artigo rápido para ajudar quem tiver interessado em emular o Sistema Operacional JUNOS com QEMU.
 Eu levei algum tempo para conseguir emular o meu, mas seguindos as dicas não é complicado.
Antes de qualquer coisa é preciso ter os seguintes softwares:

freebsd-4.11.img
junos-auto-fix-checkpic 
 jinstall-9.6R1.13-domestic-signed.tgz.

Pode ser que a versão do jinstall encontrada na Internet seja diferente dessa mas isso não é um problema.

Não é obrigatório, mas os tutoriais na Internet recomendam alterar o nome da imagem :

copy freebsd-4.11.img olive-9.6R1.13.img

Descompacte todos os programas acima em uma pasta. Importante que esta pasta tenha o programa junos-auto-fix-checkpic, a pasta "bin" que aparecerá assim que o software for descompactado. Alem da imagem criada no passo anterior.
   Na pasta onde for descompactado os programas acima, execute o seguinte comando

junos-auto-fix-checkpic-v1.0.bat jinstall-9.6R1.13-domestic-signed.tgz

Copie o arquivo gerado para a pasta onde fica o QEMU e
execute o seguinte comando. No meu caso, o QEMU fica em: C:\Program Files\GNS3>

qemu.exe  -m 1G -hda olive-9.6R1.13.img -cdrom jinstall-9.6R1.13-domestic-olive.iso

 Se tudo correu bem até aqui, o QEMU irá bootar a imagem criada. Ele irá executar o FreeBSD como se fosse um CD em um driver. É preciso logar como root usando usuário root e senha root.
 Uma vez logado no FreeBSD, faça a montagem do CDROM:

mount /cdrom

Feito isso, vem o último e mais emocionante passo:

pkg_add -f /cdrom/jinstall-9.6R1.13-domestic-olive.tgz

Com esse comando, você irá instalar o JUNOS no FreeBSD.
 Esse comando leva um bom tempo, algo em torno de meia hora e o sistema pode pedir para rebootar. Pode ser usado o comando halt para isso. No final, uma imagem de quase um Giga é criado.

 A partit daí, basta configurar o GNS3 para usar essa imagem e você terá um JUNOS rodando em seu PC.

 

 
 Detalhe, o JUNOS demora uma enormidade para subir e consome muita memoria e muita CPU. Esteja preparado para isso e aproveite os estudos.