Quais são algumas soluções / correções para UTM / IDP no Junos 12.1X44-D10.4 para dispositivos de derivação da série SRX?

Os cursos mais recentes do JNCIP / JNCIE-SEC usam 12.1X44-D10.4 como a versão Junos recomendada. Configurei uma avaliação de 30 dias no meu dispositivo SRX doméstico para estudar o JIPS, com base em 12.1. Neste ponto, acho que meu problema é que as licenças de teste para 12.1X44-D10.4 podem ser equivalentes a 12.2, 12.3 ou totalmente não suportadas. Aqui está o que estou tentando agora:

netops> request security idp security-package download full-update    
Will be processed in async mode. Check the status using the status checking CLI

root> request security idp security-package download status         
In progress:SignatureUpdate_tmp.xml.gz                          100 % 2034681 Bytes/ 2034681 Bytes

root> request security idp security-package download status    
Done;File applications.xml.gz is corrupt - MD5 hash match failed

Como a licença foi instalada corretamente (mas não as assinaturas IDP), eu também solicitava manualmente um download com os parâmetros de URL apropriados (mencionados em KB19502 )

Não tive sorte no Juniper.net, mas aqui estão meus próximos passos planejados:

• Cheirar o tráfego / descobrir qual versão está tentando baixar
• Solicite manualmente um download, por exemplo. https://services.netscreen.com/cgi-bin/index.cgi?device=jsrx650&feature=idp&os=10.3&detector=10.4.160100823&from=1817&to=1805&type=update
• Fale com o meu representante Juniper esta semana (e sim, estou adicionando suporte neste dispositivo). Editar: abriu um tíquete de atendimento ao cliente com o Juniper, pois é um novo dispositivo. Continuará com a resolução.
• Estou lendo os techpubs / documentation para verificar se existem etapas adicionais que podem causar falhas, mas tentei os suspeitos do costume, como resolução de nomes, hora do sistema / NTP, etc. etc.

Editar: o downgrade para 12.1R5.5 não corrigiu o problema e ainda estou recebendo a correspondência de hash corrompido / md5 com falha. Isso não parece ser devido à falta de armazenamento, o que poderia causar erros estranhos como esse.

Parecia que essa era uma solução fácil (eu também tentei as versões 12.1R6.5 e 12.1X44-D11.5, sem sucesso).

Primeiro, observei a versão do banco de dados de assinatura que está tentando baixar (2263):

 netops> request security idp security-package download check-server    
 Successfully retrieved from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2263(Detector=12.6.160130325, Templates=2263)

Então, decidi que essa é possivelmente uma soma de verificação md5 ruim real (conforme o que Junos espera) e baixei a versão anterior, 2262:

 netops> request security idp security-package download version full-update 2262    
 Will be processed in async mode. Check the status using the status checking CLI

Funcionou! Eu tive que fazer algo semelhante na Netscreen, mas já faz um tempo. Desativei as atualizações automáticas e posso voltar a estudar.

 netops> request security idp security-package download status    
 Done;Successfully downloaded from(https://services.netscreen.com/cgi-bin/index.cgi).
 Version info:2262(Tue May 14 16:27:00 2013 UTC, Detector=12.6.160130325)

Agora que o download foi concluído, tudo está sendo instalado corretamente:

 netops> request security idp security-package install          
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status 
 In progress:performing DB update...

 netops> request security idp security-package install status    
 In progress:performing DB update for an xml (groups.xml)

 netops> request security idp security-package install status
 In progress:performing DB update for an xml (applications.xml)

 etc.

 netops> request security idp security-package install status    
 Done;Attack DB update : successful - [UpdateNumber=2262,ExportDate=Tue May 14 16:27:00   2013 UTC,Detector=12.6.160130325]
 Updating control-plane with new detector : successful
 Updating data-plane with new attack or detector : not performed
  due to no active policy configured.

Acredito que isso seja um bug no SRX110H-VA, uma combinação de versão de hardware / software ou atualizações incorretas de assinatura em services.netscreen.com. Tenho certeza de que eu poderia apenas olhar através do XML e descobrir onde está o md5sum ruim (e corrigi-lo manualmente), mas continuarei assim que tiver notícias do Juniper.

Edição mais recente: eu também tive que baixar manualmente o modelo de política do Juniper, extraí-lo gzip -d templates.xml.gze colocá-lo /var/db/idpd/sec-download/sub-download/. Feito isso, consegui instalá-lo. O problema aqui é que o request security idp security-package install policy-templatescomando não usa uma 'versão', como os outros comandos idp. Isso sempre será um problema quando a política do IDP principal possui erros MD5, embora eu esperasse que isso não seja uma ocorrência frequente na Juniper.

 netops> request security idp security-package install policy-templates 
 Will be processed in async mode. Check the status using the status checking CLI

 netops> request security idp security-package install status              
 Done;policy-templates has been successfully updated into internal repository
 (=>/var/db/scripts/commit/templates.xsl)!