quarta-feira, 25 de abril de 2007

Alterando o shell padrão no Nokia IPSO

Para usar o backspace para apagar os "dedos-gordos", ops! os erros quando está utilizando o shell padrão do Nokia IPSO (C shell), é necessário trocar o C shell pelo sh (/bin/sh).

% clish

NokiaIPSO> set user admin shell /bin/sh
NokiaIPSO> save config
NokiaIPSO> exit

Fica também a dica para alterar opções dentro da CLI (clish) do IPSO.

terça-feira, 3 de abril de 2007

Dynamips Video Tutorial

Josh Horton publicou em seu blog uma série de tutoriais em vídeo de como instalar e configurar o Dynamips. Vale a pena principalmente pelo conceito interessante de passar uma informação através de imagens.

Installation

Basic T1 Configuration

Communication between virtual router and PC loopback interface

segunda-feira, 2 de abril de 2007

VPN Cisco e MTU

O protocolo IP Path MTU Discovery, definido no RFC 1191, permite que um host descubra dinamicamente qual o maior MTU em que ele pode enviar dados sem ter que efetuar a fragmentação dos pacotes (e que por consequência diminui a quantidade de pacotes enviados). Além disso, este algoritmo é útil caso o MTU de um caminho varie, por exemplo devido ao chaveamente para um link secundário de MTU diferente, permitindo assim que os hosts das pontas "negociem" um novo tamanho máximo de pacote.

O padrão para interfaces Ethernet é de 1518 bytes já contando os cabeçalhos de camada 2. No entanto quando se usa um túnel VPN esse MTU diminui devido aos cabeçalhos adicionais de criptografia (este MTU pode variar dependendo do algoritmo utilizado).

Quando um roteador Cisco tenta passar um pacote maior do que o túnel VPN permite ele manda uma mensagem ICMP unreachable para o originador do pacote informando qual o novo MTU. Portanto é importante permitir que o roteador envie as mensagens de ICMP unreachable com o seguinte comando nas interfaces inside e outside do túnel VPN.

conf t
int fas 0/0
ip unreachables
int fas 0/1
ip unreachables

Para descobrir qual o maior MTU permitido em um determinado caminho podem ser utilizados os seguintes comandos:

traceroute -M -I icmp dest_ip_addr

ou

tracepath -n dest_ip_addr

Maiores informações em:

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1049788

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080435c3e.html#wp1051721

domingo, 1 de abril de 2007

CUIDADO! Esta página esta infectada!

Sim, esta é realmente uma brincadeira de primeiro de abril, mas o título deste post poderia ser verdade. A nova vulnerabilidade dos cursores animados do Windows CVE-2007-0038 (0-day .ANI vulnerability), agora já não tão "zero-day" assim, deve ser cuidadosamente analisada neste início de semana. O Infocon (do ISC) e o Symantec's ThreatCon já foram alterados para um nível de alerta maior devido à esta nova vulnerabilidade - e esta não é história de primeiro de abril.

A Microsoft confirmou esta vulnerabilidade no último dia 29 - ainda sem disponibilizar o patch, no "Microsoft Security Advisory (935423)" - e provocou uma série de notícias sobre uma vulnerabilidade ainda "sem correção". Ok, você está lendo este post pois com certeza já aplicou o patch no seu computador pessoal e em todos os outros que você administra, certo? Ok, vamos lá, a Microsoft promete disponbilizar o patch até o próximo dia 3...

Como o MSIE faz o download e executa automaticamente um arquivo .ani referenciado dentro de uma página HTML esta vulnerabilidade pode ser facilmente explorada somente deixando um arquivo infectado disponível em um servidor e referenciando este arquivo em uma página web - o que abre um leque enorme de possibilidades associadas a cross-site scripting, SQL injection, etc. além da facilidade de propagação através de worms, por exemplo, baseados em mensagens eletrônicas. Para saber se o seu sistema está vulnerável, consulte a página oficial da Microsoft.

Uma análise detalhada de um artefato infectado foi publicada aqui e o Mcafee Avert Lab Blog publicou um vídeo mostrando o que acontece com o Windows Vista após ser comprometido com um arquivo .ani. O CISRT também publicou um anúncio sobre um novo worm que utiliza arquivos infectados com esta vulnerabilidade para comprometer o sistema operacional.

UPDATE [03-abr-2007]: Patch disponibilizado pela Microsoft em através do Windows Update ou http://www.microsoft.com/technet/security/Bulletin/MS07-017.mspx.

UDPATE [04-abr-2007]: Vários usuários estão reportando que após a aplicação do patch ocorreram outros problemas, inclusive a Microsoft já disponibilizou um novo patch para corrigir alguns desses problemas. Mais detalhes na página do ISC - este que está fazendo um excelente trabalho de divulgação de informações sobre esta vulnerabilidade.

terça-feira, 27 de março de 2007

Portas para Acesso do Cliente VPN Check Point

Mesmo sendo muito simples instalar e configurar uma conexão VPN client-to-gateway utilizando o SecureClient ou SecuRemote da Checkpoint, podem haver diversos problemas de conexão entre o cliente e o gateway de VPN quando a comunicação passa através de um firewall (ou proxy) que não libera todo o acesso do cliente para o gateway de VPN. Ou seja, é necessário liberar as portas e protocols (do cliente para o gateway):

  • TCP 264 (download da topologia)

  • UDP 500 (IPSEC and IKE)

  • IPSEC ESP (protocolo 50)

  • IPSEC AH (protocolo 51)

  • TCP 500 (se utilizada a opção "IKE over TCP")

  • UDP 2746 ou outra porta(*) (se utilizada a opção "UDP encapsulation")
Esta última(*) é definida dentro das propriedades do gateway Checkpoint (SmartDashboard selecionar o gateway dentro de "Network Objects" e depois em "Check Point") na opção "Remote Access" selecionar qual será a porta UDP na opção NAT Traversal.

Ainda para a versão SecureClient, a Check Point recomenda permitir as seguintes portas:
  • FW1_scv_keep_alive (UDP port 18233) — SCV keep-alive packets

  • FW1_pslogon_NG (TCP port 18231) or (TCP port 65524 for Application Intelligence) — SecureClient's login to Policy Server

  • FW1_sds_logon (TCP port 18232) — SecureClient's Software Distribution Server (SDS) download protocol

  • tunnel_test (UDP port 18234) — used by Check Point's Tunnel Test application

  • RDP (UDP port 259) — Used in MEP's Proprietary Probing (PP) to discover available gateway
Estas informações podem ser utilizadas para a versão NG-AI (testado no R55) e para o NGX (R60). Para mais detalhes consultar o documento do SecureKnowledge Check Point aqui.

quinta-feira, 22 de março de 2007

Linksys e a porta 916

A porta 916/udp poderia ter passado despercebida por muitos, mas não passou para Daniël Niggebrugge. Neste último dia 20/03/2007 ele anunciou na lista Bugtraq que encontrou uma vulnerabilidade no equipamento Linksys WAG200G que permite qualquer pessoa conectada em uma interface WAN ou LAN obter informações tais como modelo do produto, usuário e senha PPPoA, senha para a interface de configuração web, ssid, chave WPA, etc. Daniël disse também que avisou a Linksys há um mês atrás e não houve qualquer manifestação sobre o problema.

A vulnerabilidade funciona através da porta 916/udp. Basta enviar um simples pacote para a porta 916/udp e esperar pelo resultado em um datagrama IP com endereço de destino 255.255.255.255 (broadcast). Os testes que realizei no access point Linksys WRT54GC são:

02:20:01.749708 IP 192.168.0.1.1866 > 192.168.0.10.916: UDP, length 0
02:20:01.766548 IP 192.168.0.10.916 > 255.255.255.255.1866: UDP, length 443

Sim, realmente funciona. Mais informações na mensagem original do Daniël. Aparentemente o problema não tem correção até o momento.

segunda-feira, 26 de fevereiro de 2007

Simulando roteadores Cisco com Dynagen

Apesar de ser somente uma pequena nota sobre um um software de simulação, o post sobre Dynamips é o mais visitado deste blog. Por isso, achei interessante explicar com maiores detalhes o funcionamento do Dynamips e do Dynagen. Para tornar tudo ainda mais fácil, os exemplos que mostrarei abaixo serão todos baseados no dynamips/dynagen para Windows, mas os mesmos funcionam igualmente no Linux (ou até melhor... quem sabe? Mais adiante discutiremos sobre isso também).

Dynamips é um software de código-aberto escrito por Christophe Fillot para simular um roteador 7200 em um PC comum utilizando um processador MIPS. Com este software é possível simular um IOS diretamente no PC - por este motivo o Dynamips necessita de uma imagem do Cisco IOS para funcionar. Atualmente o Dynamips suporta as plataformas 2600, 3600 e 7200 de roteadores Cisco e ainda vários tipos de módulos para estas plataformas.

Para utilizar o Dynamips, por exemplo, para simular uma rede de 4 roteadores interconectados entre si, era necessário mapear em cada instância do Dynamips as interfaces de interconexão utilizando portas UDP. Para facilitar este trabalho de mapeamento Greg Anuzelli desenvolveu um front-end para o Dynamips chamado Dynagen. Com o Dynagen o mapeamento das interconexões é automático: basta definir em um arquivo de configuração qual interface de um roteador conecta-se a outro roteador. Para saber mais detalhes sobre o Dynagen, consulte este tutorial escrito pelo próprio Greg Anuzelli.

Alguns centros especializados em treinamento para as certificações Cisco já disponibilizam laboratórios pré-configurados - ou seja, um arquivo de configuração do Dynagen - para treinamentos e exercícios em um laboratório virtual. Por exemplo, o arquivo do laboratório virtual do Internetwork Expert pode ser pego aqui e do IE Mentor aqui. Estes dois exemplos anteriores foram especialmente desenvolvidos para provas do CCIE.

Desta vez iremos instalar o laboratório do Internetwork Expert. A primeira medida é ter o Dynagen instalado na máquina. Para isso, você deve fazer o download e instalar o Dynagen e a biblioteca libpcap - como estamos no Windows, iremos baixá-la com o nome de Winpcap. Em seguida será necessário pegar a imagem do IOS e descompactá-la com o PKUNZIP ou Winrar (no windows) ou o unzip do Linux. Neste exemplo, iremos utilizar a imagem c3640-is-mz.123-14.T7.bin e descompactá-la no Linux.

$ unzip c3640-is-mz.123-14.T7.bin && mv image.bin c3640-is-mz.123-14.T7.extracted.bin
Coloque a imagem no diretório C:\Program Files\Dynamips\images. Em seguida, você deve rodar o Dynamips com esta imagem (com qualquer configuração de módulos) para descobrir qual é o valor do idle-pc para esta imagem. Para isso, utilizei o comando "C:\Program Files\Dynamips>dynamips.exe -P 3600 images\c3640-is-mz.123-14.T7.extracted.bin" e aguardei o término do processo de boot da imagem. Note que a CPU do seu PC estará constantemente em 100% pois não carregamos o valor do idle-pc no boot da imagem. Para descobrirmos este valor é necessário entrar com a seqüência de break e em seguida pressionar a tecla "i" durante a execução do simulador. No windows a seqüência de break é "Ctrl+ç"e em seguida "i". Pode ser também a combinação "Ctrl+]" e depois "i".
Router>
Please wait while gathering statistics...
Done. Suggested idling PC:
0x605c057c (count=54)
0x605f1cf0 (count=22)
0x605f1d10 (count=46)
0x605f1ed8 (count=32)
0x605f1f3c (count=27)
0x605f2010 (count=69)
0x606a23fc (count=42)
0x606a2478 (count=21)
0x605f2814 (count=23)
0x605f2850 (count=27)
Restart the emulator with "--idle-pc=0x605c057c" (for example)
Agora podemos testar a imagem com algum dos valores que foram descobertos e verificar que a CPU não está mais constantemente em 100%. Esse procedimento é necessário quando precisamos rodar vários roteadores em um mesmo PC e não queremos esperar vários dias para sair do modo exec e entrar no modo de configuração de um dos roteadores...

Agora ajustamos o arquivo com as configurações do laboratório para refletir o nome da imagem e o valor do idle-pc da imagem que acabamos de testar. Temos que editar o arquivo ie.routing.and.switching.topology.4.00.net e atualizar todas as entradas do nome da imagem e idle-pc.

image = C:\Program Files\Dynamips\images\c3640-is-mz.123-14.T7.extracted.bin
idlepc = 0x605c057c

É importante também ter uma forma de conectar na console de cada um dos equipamentos que serão simulados. Para isso a sugestão para este laboratório é criar uma interface de loopback (para saber como fazer no Windows clique aqui) e atribuir o IP 169.254.0.1/16. Temos que descobrir o endereço de hardware desta interface de loopback com o comando "dynamips -e" - algo como {4065B11C-2A6C-4FD2-8204-A12A9A8328A4} - e atualizar este endereço no arquivo de configuração do laboratório para o último roteador - TermServ - que será nosso servidor de console para todos os outros equipamentos.

Para finalizar, iniciamos duas instâncias do dynamips para suportar todo o laboratório:

C:\Program Files\Dynamips>dynamips.exe -H 7200
C:\Program Files\Dynamips>dynamips.exe -H 7201
E depois iniciamos o Dynagen carregando o arquivo de configuração do latoratório.

C:\Program Files\Dynamips>dynagen.exe sample_labs\internetworkexpert\ie.routing.
and.switching.topology.4.00.net

Reading configuration file...


Network successfully started

Dynagen management console for Dynamips

=> list
Name Type State Server Console
TermServ 3640 stopped localhost:7201 2000
R1 3640 stopped localhost:7200 2001
R2 3640 stopped localhost:7200 2002
R3 3640 stopped localhost:7200 2003
R4 3640 stopped localhost:7200 2004
R5 3640 stopped localhost:7200 2005
R6 3640 stopped localhost:7200 2006
SW1 3640 stopped localhost:7200 2007
SW2 3640 stopped localhost:7201 2008
SW3 3640 stopped localhost:7201 2009
SW4 3640 stopped localhost:7201 2010
BB1 3640 stopped localhost:7201 2011
BB2 3640 stopped localhost:7201 2012
BB3 3640 stopped localhost:7201 2013
FRSW FRSW n/a localhost:7201 n/a
=> start TermServ
100-C3600 'TermServ' started
=>

Agora você poderá iniciar cada um dos equipamentos e conectar nos mesmos para testar as mais diferentes configurações. Depois de iniciar o roteador TermServ, pode-se utilizar o telnet para conectar no TermServ e depois na console de cada um dos equipamentos do laboratório.

C:\telnet 169.254.0.2

TermServ>
Agora temos um laboratório virtual de roteadores para testar e simular os mais diferentes ambientes.

O Dynagen pode trabalhar com instâncias do Dynamips rodando em máquinas diferentes, permitindo simular redes de roteadores ainda maiores distribuindo a carga entre máquinas distintas. Se esta for a sua idéia, então é aconselhável a utilização do Linux, já que o Windows não trabalha muito bem com processos que ocupam mais de 2 GB de memória RAM e sabe-se que tem problemas de desempenho depois de uma certa quantidade de roteadores. Mais informações sobre o Dynamips podem ser encontradas no Forum 7200emu.hacki.at ou ainda no blog do Christophe Fillot, autor do Dynamips.

UPDATE (16-fev-2008): Veja também o post sobre o GNS3.

sexta-feira, 23 de fevereiro de 2007

Configurando Interfaces VLAN no FreeBSD

Quando trabalhamos com vlans, podemos segmentar a rede para diminuir o tráfego broadcast compartilhado e segmentar de forma que por exemplo tenhamos uma vlan por serviço/aplicação. A vantagem de ter um Freebsd com interfaces vlans seria, utilizar a mesma interface física para transportar varios tags (vlan id), excluindo a necessidade de uma placa de rede para cada segmento.

Configurando FreeBSD

Primeiramente necessitamos levantar o módulo if_vlan ou para quem queira deixar este suporte nativamente no kernel.

Para habilitar o suporte a vlans sem ter q recompilar o kernel utilizaremos o comando abaixo:

# kldload if_vlan

Não podemos esquecer de adicionar a entrada if_vlan_load=”YES” no arquivo /boot/loader.conf

Caso você queira compilar o suporte nativamente, adicione a entrada abaixo no seu arquivo de configuração e recompile o seu kernel:

device vlan


Depois do suporte a int vlans estar habilitado, vamos começar a configuração no Freebsd.

Vamos utilizar 4 tags para a nossa configuração, 5, 10, 15 e 20, para facilitar vamos associar o tag ao nome da interface vlan, tag 5 (vlan5), tag 10 (vlan10), tag 15 (vlan15), tag 20 (vlan20).

Criando as interfaces:

# ifconfig vlan5 create
# ifconfig vlan10 create
# ifconfig vlan15 create
# ifconfig vlan20 create


Apenas para conferir se as interfaces foram criadas

# ifconfig

A saída deverá ser algo como mostrado abaixo:

vlan5: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan10: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan15: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:

vlan20: flags=8002 mtu 1500
ether 00:00:00:00:00:00
vlan: 0 parent interface:


Nossas interfaces ja estão criadas, agora vamos associa-las ao devido tag e a interface física.

OBS: não é necessario a nome da int vlan ter o mesmo tag, por exemplo, pode ser criado a interface vlan0 e associado qualquer tag, criamos a vlan5 associada ao tag 5 para ficar mais fácil de coomprender.

Associando os tags:

# ifconfig vlan5 vlan 5 vlandev em0
# ifconfig vlan10 vlan 10 vlandev em0
# ifconfig vlan15 vlan 15 vlandev em0
# ifconfig vlan20 vlan 20 vlandev em0


Pronto, os tags ja estao devidamente configurados e associados a interface física em0.

Agora, atribua os endereços ips nas interfaces vlans.

# ifconfig vlan5 192.168.5.1 netmask 255.255.255.0 up
# ifconfig vlan10 192.168.10.1 netmask 255.255.255.0 up
# ifconfig vlan15 192.168.15.1 netmask 255.255.255.0 up
# ifconfig vlan20 192.168.20.1 netmask 255.255.255.0 up


A saída do ifconfig ficará como mostrado abaixo:

vlan5: flags=8843 mtu 1500
inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 5 parent interface: em0

vlan10: flags=8843 mtu 1500
inet 192.168.10.1 netmask 0xffffff00 broadcast 192.168.10.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 10 parent interface: em0

vlan15: flags=8843 mtu 1500
inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 15 parent interface: em0

vlan20: flags=8843 mtu 1500
inet 192.168.20.1 netmask 0xffffff00 broadcast 192.168.20.255
inet6 fe80::203:47ff:fe07:63ff%vlan20 prefixlen 64 scopeid 0xb
ether 00:0a:5e:53:f8:ec
media: Ethernet autoselect (100baseTX )
status: active
vlan: 20 parent interface: em0


Nossas configurações já estão prontas, todas as int vlans configuradas com as tags associadas e com a interface física fxp0 devinida.

Agora vamos colocar nossas configurações no rc.conf para nao perde-las quando o FreeBSD for rebootado.

Adicionar no arquivo /etc/rc.conf as entradas abaixo:

cloned_interfaces="vlan5 vlan10 vlan15 vlan20"
ifconfig_vlan5="inet 192.168.5.1 netmask 255.255.255.0 vlan 5 vlandev em0"
ifconfig_vlan10="inet 192.168.10.1 netmask 255.255.255.0 vlan 10 vlandev em0"
ifconfig_vlan15="inet 192.168.15.1 netmask 255.255.255.0 vlan 15 vlandev em0"
ifconfig_vlan20="inet 192.168.20.1 netmask 255.255.255.0 vlan 20 vlandev em0"


Nossa configuração está concluída no lado do FreeBSD, vou colocar a configuração que deve ser realizada switchs Cisco Catalyst 3750.

Logue no switch com seu usuário e senha, entre em modo enable:

Switch# enable


Defina uma porta onde será conectado o FreeBSD com as interfaces vlans, no nosso exemplo vamos escolher a porta Gi1/0/1.

Entre em como de configuração

Switch# configure terminal
Switch (config)# interface Gi1/0/1


Lembrando que a interface pode variar conforme o modelo do switch.

Switch (config-if)# switchport trunk encapsulation dot1q
Switch (config-if)# switchport mode trunk
Switch (config-if)# switchport trunk allowed vlan 5,10,15,20
Switch (config-if)# description “DESCRIÇÃO DA PORTA”


Com estas configurações na porta estamos deixando trafegar apenas as vlans 5, 10, 15 e 20, caso queira adicionar mais uma vlan no trunk do switch, utilize o comando abaixo:

Switch (config-if)# switchport trunk allowed vlan add 25


Adicionamos a vlan 25 na porta Gi1/0/1 do switch.

Configure o restante das portas do switch em mode access conforme mensionado abaixo:

Switch (config-if)# interface Gi1/0/2
Switch (config-if)# switchport mode access
Switch (config-if)# switchport access vlan 5


Com isso a porta dois consequirá conversar com a interface vlan 5 do FreeBSD através da porta 1 do switch que esta configurada em mode trunk. Faça o mesmo com as outras portas definindo a vlan que deve ser acessada pela porta.

Com isto finalizamos nosso how-to, este tipo de configuração normalmente é utilizado em firewalls, faça um cálculo de tráfego para não ter gargalo físico na placa de rede, se o tráfego for grande em cada vlan utilize uma placa Gigabit de boa qualidade.

Performance em conexões tcp

Um problema que muitos administradores de rede encontram é quando há reclamações de performance em conectividade. Escrevi um programinha para realizar testes de conexões em modo paralelo e sequencial, um programa em C muito simples, pode ser baixado neste link
Basta compilar com suporte a pthread com o comando abaixo:

gcc multiconnect.c -o multiconnect -lpthread


Syntax: ./multiconnect hostname port [connections]
Se não for passado o número de conexões, o default é 100.

Ele mede a performance em microsegundos já converte para segundos.

quarta-feira, 14 de fevereiro de 2007

Simulando um roteador com JunOS

Não é de hoje que sabemos que grande parte da arquitetura dos roteadores da Juniper é totalmente baseada no PC: memória RAM, ROM, CPU, placa-mãe, etc. Também sabe-se que o JunOS - sistema operacional que controla uma parte específica destes roteadores: a routing engine ou RE - é também baseado no sistema operacional FreeBSD. Por isso, sempre houve um certo mito sobre a possibilidade de rodar o JunOS em um PC "caseiro". Esta combinação - PC mais o JunOS - foi gentilmente apelidada de Olive. A principal motivação para instalarmos o Olive - além da natural curiosidade - é o aprendizado e a familiarização com o sistema operacional JunOS.

Em linhas gerais, os passos para instalar o Olive são:

- Instalar o FreeBSD
- Instalar o pacote do JunOS (jinstall)
- Reboot

Existem também algumas dicas e observação importantes que podem ajudar neste teste. Para começar é recomendável instalar o FreeBSD 4.x-mini (testado com a versão 4.4-mini) com a seguinte estrutura de diretórios:

ad0s1a     /       100M
ad0s1b swap 1G
ad0s1e /config 12M
ad0s1f /var (maior slice, o resto do disco)

Apesar de ser aconselhável utilizar o modelo de particionamento acima, a instalação do pacote jinstall (JunOS) poderá alterar a estrutura de diretórios caso seja necessário. O próximo passo é copiar o pacote do JunOS - que deve ser um arquivo do tipo jinstall-xxx.tgz - para o diretório /var/tmp e iniciar a instalação. Os passos são:
rm /dev/wd0c
ln -s /dev/ad0c /dev/wd0c
mkdir /var/etc
cd /var/etc
touch master.passwd; touch inetd.conf; touch group
cd /var/tmp; pkg_add jinstall-7.0R1.5-domestic-signed.tgz
reboot
Neste momento você poderá ver o Olive rodando em um PC comum. Para conectar-se e iniciar alguma configuração é necessário possuir um cabo de console e utilizar um programa como o Hyper Terminal ou similar. Se você instalou o Olive em uma máquina virtual VMware (FreeBSD), então você pode utilizar o programa VMware Serial Line Gateway para conectar na porta serial sem a necessidade de um cabo serial - a idéia deste programa é criar um gateway para conexão via telnet e traduzir essa conexão para a porta serial do VMware. No caso do VMware, ainda existe uma dica importante: edite o arquivo *.vmx e adicione a linha descrita abaixo, dessa forma o VMware irá simular uma interface de rede Intel que o JunOS/FreeBSD poderá reconhecer.
ethernet0.virtualDev = "e1000"
É importante saber também que o JunOS/Olive é incompatível com a maioria das placas de rede mais comuns. Para saber mais sobre o Olive, versões testadas de JunOS e placas de rede compatíveis basta acessar a página wiki do Olive ou ainda a página de outras pessoas que também já testaram o Olive como o "Sid Smokes" e o Joel Knight.