Was sind einige Problemumgehungen / Korrekturen für UTM / IDP unter Junos 12.1X44-D10.4 für Zweigstellengeräte der SRX-Serie?

Die neuesten JNCIP / JNCIE-SEC-Kurse verwenden 12.1X44-D10.4 als empfohlene Junos-Version. Ich habe auf meinem SRX-Heimgerät eine 30-Tage-Evaluierung eingerichtet, um JIPS basierend auf 12.1 zu untersuchen. An dieser Stelle schätze ich, dass mein Problem darin besteht, dass Testlizenzen für 12.1X44-D10.4 möglicherweise 12.2, 12.3 entsprechen oder überhaupt nicht unterstützt werden. Folgendes versuche ich jetzt:

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

Da die Lizenz ordnungsgemäß installiert wurde (jedoch nicht die IDP-Signaturen), wollte ich auch manuell einen Download mit den richtigen URL-Parametern anfordern ( siehe KB19502 ).

Ich hatte kein Glück auf Juniper.net, aber hier sind meine geplanten nächsten Schritte:

• Schnüffeln Sie am Datenverkehr und finden Sie heraus, welche Version heruntergeladen werden soll
• Fordern Sie manuell einen Download an, z. 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
• Sprechen Sie diese Woche mit meinem Juniper-Mitarbeiter (und ja, ich füge Unterstützung für dieses Gerät hinzu). Bearbeiten: hat ein Kundenbetreuungsticket mit Juniper geöffnet, da es sich um ein neues Gerät handelt. Wird mit Auflösung folgen.
• Ich lese in den Techpubs / in der Dokumentation nach, ob es zusätzliche Schritte gibt, die dazu führen können, dass dies fehlschlägt, aber ich habe die üblichen Verdächtigen wie Namensauflösung, Systemzeit / NTP usw. usw. ausprobiert.

Bearbeiten: Ein Downgrade auf 12.1R5.5 hat das Problem nicht behoben, und ich bekomme immer noch eine beschädigte / MD5-Hash-Übereinstimmung fehlgeschlagen. Dies scheint nicht auf mangelnden Speicher zurückzuführen zu sein, was zu seltsamen Fehlern wie diesem führen kann.

Es schien, dass dies eine einfache Lösung war (ich habe auch 12.1R6.5 und 12.1X44-D11.5 ausprobiert, ohne Erfolg).

Zuerst habe ich mir die Version der Signatur-DB angesehen, die heruntergeladen werden soll (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)

Dann entschied ich, dass dies möglicherweise eine tatsächlich schlechte MD5-Prüfsumme ist (gemäß den Erwartungen von Junos), und lud die vorherige Version 2262 herunter:

 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

Es funktionierte! Ich musste auf Netscreen etwas Ähnliches machen, aber es ist schon eine Weile her. Ich habe automatisierte Updates deaktiviert und kann wieder studieren.

 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)

Nachdem der Download abgeschlossen ist, wird alles ordnungsgemäß installiert:

 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.

Ich denke, dass dies entweder ein Fehler in SRX110H-VA ist, eine Kombination aus Hardware- / Software-Release oder schlechte Signatur-Updates auf services.netscreen.com. Ich bin mir ziemlich sicher, dass ich einfach durch das XML schauen und herausfinden könnte, wo sich die schlechte md5sum befindet (und sie von Hand reparieren), aber ich werde nachgehen, sobald ich von Juniper etwas höre.

Neueste Bearbeitung: Ich musste die Richtlinienvorlage auch manuell von Juniper herunterladen, mit extrahieren gzip -d templates.xml.gzund in platzieren /var/db/idpd/sec-download/sub-download/. Sobald das erledigt war, konnte ich es installieren. Das Problem hierbei ist, dass der request security idp security-package install policy-templatesBefehl keine 'Version' annimmt, wie die anderen IDP-Befehle. Dies wird immer dann ein Problem sein, wenn die Head-IDP-Richtlinie md5-Fehler aufweist, obwohl ich hoffen würde, dass dies bei Juniper nicht häufig vorkommt.

 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)!