Tuesday 24 September 2013

JTAC Recommended Junos Software Versions for SRX and M Series- Sep 2013

SRX Series Services Gateways

Platform JTAC Recommended Junos Software by Platform Release
Type
Last
updated
SRX100B/H Junos 11.4R7.5 Standard 8 April 2013
SRX100H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX110H Junos 11.4R7.5 Standard 8 April 2013
SRX110H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX210B/H/BE/HE Junos 11.4R7.5 Standard 8 April 2013
SRX210H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX220H Junos 11.4R7.5 Standard 8 April 2013
SRX220H2 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX240B/H/B2/H2 Junos 11.4R7.5 Standard 8 April 2013
SRX550 Junos 12.1X44-D20.3 Standard 5 August 2013
SRX650 Junos 11.4R7.5 Standard 8 April 2013
SRX1400 (*1) Junos 11.4R7.5 Standard 8 April 2013
SRX3400 Junos 11.4R7.5 Standard 8 April 2013
SRX3600 Junos 11.4R7.5 Standard 8 April 2013
SRX5600 Junos 11.4R7.5 Standard 8 April 2013
SRX5600 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 4 September 2013
SRX5800 Junos 11.4R7.5 Standard 8 April 2013
SRX5800 w/NG-SPC (*2) Junos 12.1X44-D22 Standard 4 September 2013
(*1) SRX 1400 deployment as a Chassis Cluster requires Junos 11.1 or above.
(*2) TSB16197 - Intermittent PHY or MAC layer link failure on SRX5600 and SRX5800 with SRX5K-SPC-4-15-320.


M, T and MX Series Routers

Platform JTAC Recommended Junos Software by Platform Release
Type
Last
updated
M Series Junos 11.4R7.5 Standard 15 March 2013
T Series Junos 11.4R7.5 Standard 15 March 2013
MX Series Junos 11.4R7.5 Standard 15 March 2013
MX Series with Enhanced SCB Junos 11.4R7.5 Standard 15 March 2013
MX5, MX10, MX40 Series Junos 11.4R7.5 Standard 15 March 2013


Sunday 15 September 2013

JUNOS : Configure Antivirus Full File-Based Scanning

Setting Up Automatic Updates

By default, the antivirus pattern database is configured to automatically update once every 60 minutes.  You also can specify the email notification sent to the administrator when the pattern update is complete.
  1. Configure the pattern-updates at a different interval for the Kaspersky scan engine.
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update url http://update.juniper-updates.net/AV/SRX240
user@host#
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update interval 120
Note: "SRX240” in the URL is the platform name. This part of the URL is different and platform specific for each platform. (Other than the platform name, you should not change this URL unless you are experiencing problems with it and have called for support.)
Alternately, you can configure the pattern update manually by entering the following operational command:
user@host> request security utm anti-virus kaspersky-lab-engine pattern-update
  1. Define the pattern-update email.
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify admin-email "admin@juniper.net"
user@host# set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify custom-message "Pattern UPDATE Done"
user@host#
set security utm feature-profile anti-virus kaspersky-lab-engine pattern-update email-notify custom-message-subject "AV UPDATE COMPLETE"

CLI Configuration

To activate full file-based antivirus using the default antivirus profile:
  1. Define what scan engine you are going to use (in this example, Kaspersky Lab engine).
user@host# set security utm feature-profile anti-virus type kaspersky-lab-engine
  1. Define the UTM policy for the HTTP protocol to be scanned with the full file-based default profile.
user@host# set security utm utm-policy custom-utm-policy anti-virus http-profile junos-av-defaults
Note:  A separate anti-virus profile is needed for each protocol.  The available protocols include HTTP, SMTP, POP3, and IMAP.
  1. Apply the UTM policy to a security policy (in this example, security policy called web-access).
user@host# set security policies from-zone trust to-zone untrust policy web-access then permit application-services utm-policy custom-utm-policy

Sunday 8 September 2013

Juniper SRX vs ScreenOS


The Juniper family of SRX services gateways are the replacement platforms for the SSG platforms, the ISG 1000 and
ISG 2000 as well as the NS 5000 Series (NS-5200 and NS-5400). The SRX family include a set of branch platforms
(SRX210, SRX240 and SRX650), and the high end platforms (SRX3000 and SRX5000).
The entire line of SRX platforms uses JUNOS, a very powerful networking platform that consolidates switching, routing,
security and applications into a single OS. JUNOS is very different than ScreenOS and as such, will place a significant
migration burden on Juniper, their customers and their partners.
Key points to consider:
The SRX Is not positioned as a firewall.
JUNOS is not a security OS and the SRX positioning reflects this based on the routing and switching emphasis
which Juniper uses as a means to compete with Cisco. Withthe SRX, security is merely a service that is enabled
along with switching. Juniper does not try to address the problem of the lack of innovation at the firewall which
resulted in the loss of visibility and control over applications, users and content.

Application visibility and control belongs in the firewall and the port based SRX platforms cannot deliver that
functionality.
Juniper has taken the Cisco approach to say they can do what we do using multiple devices (SRX with IDP, UAC
Controller, a UAC agent on every desktop and multiple management components). Even with this “everything-but-
the-kitchen-sink” approach, they cannot address the visibility and control (applications, users and content) problem.

Stuck on old technology
The SRX uses stateful inspection which relies on port and protocol for policy decisions, a technique that is ineffective
at controlling applications that use dynamic ports, encryption, or tunnel across often used/allowed ports to bypass
firewalls.
Full IDP is supported, and can block a very limited set of, mostly bad applications like
P2P and IM – currently at 126, an incremental improvement over the 118 from April 2007.
The threat focused approach is inadequate in detecting and positively enabling applications.
Applications are not threats. They should not be treated as such.
loading...