Sunday, 6 October 2013

Junos : Local Web filtering

To configure local Web filtering using the CLI, you must first create your custom objects.
  1. Configure a URL pattern list custom object by creating the list name and adding values to it as follows:
    Note: Because you use URL pattern lists to create custom URL category lists, you must configure URL pattern list custom objects before you configure custom URL category lists. The URL and IP address is added in this example.
    user@host# set security utm custom-objects url-pattern urllist3 value [http://www.juniper.net 1.2.3.4]
    user@host# set security utm custom-objects url-pattern urllist4 value [http://www.acmegizmo.com 1.2.3.4]
    Note: URL pattern wildcard support—The wildcard rule is as follows: \*\.[]\?* and you must precede all wildcard URLs with http://. You can only use “*” if it is at the beginning of the URL and is followed by a “.”. You can only use “?” at the end of the URL.
    The following wildcard syntax is supported: http://*.juniper.net, http://www.juniper.ne?, http://www.juniper.n??. The following wildcard syntax is NOT supported: *.juniper.net , www.juniper.ne?, http://*juniper.net, http://*.
  1. Configure a custom URL category list custom object by using the URL pattern list you created as follows:
    user@host# set security utm custom-objects custom-url-category custurl3 value urllist3
    user@host# set security utm custom-objects custom-url-category custurl4 value urllist4
Now that your custom objects have been created, you can configure the juniper-local Web filtering feature profile.
  1. If you are using included global whitelist and blacklist categories, select those global categories. This is the first filtering category that both integrated, redirect, and local Web filtering use. If no match is made, the configured default fallback action is performed. 
  2. user@host# set security utm feature-profile web-filtering url-blacklist custurl3
    user@host# set security utm feature-profile web-filtering url-whitelist custurl4
  3. Select juniper-local as your Web filtering engine as follows:
    user@host# set security utm feature-profile web-filtering type juniper-local
  4. Create a juniper-local profile by first creating a profile with a default action (permit, log and permit, block) for requests that experience errors as follows:
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 default permit
  5. Enter a custom message to be sent when HTTP requests are blocked.
    user@host# set security utm feature-profile web-filtering juniper-local profile localprofile1 custom-block-message “Access to this site is not permitted”
  6. Select fallback settings (block or log and permit) for this profile. The fallback actions are taken when errors in each configured category occur.
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 fallback-settings default block
    user@host# set security utm feature-profile web-filtering juniper–local profile localprofile1 fallback-settings too-many-requests block
  1. Configure a UTM policy for the Web filtering protocol and attach this policy to a profile. CLI commands for configuring a UTM policy for HTTP Web filtering, and attaching that policy to a profile you created earlier for content filtering are:
    user@host# set security utm utm-policy utmp5 web-filtering http-profile localprofile1
  2. Attach the UTM policy to a firewall security policy.
    user@host# set security policies from-zone trust to-zone untrust policy p5 match source-address any
    user@host# set security policies from-zone trust to-zone untrust policy p5 match destination-address any
    user@host# set security policies from-zone trust to-zone untrust policy p5 match application junos-http
    user@host# set security policies from-zone trust to-zone untrust policy p5 then permit application-services utm-policy utmp5

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.

Monday, 19 August 2013

Junos: DDOS Protection

DDoS policers are enabled by default for all supported protocol groups and packet types. Policers are established at the level of the individual line card and the Routing Engine. You can disable the line card policers globally for all MPCs or FPC5s. You can also disable the Routing Engine policer. When you disable either of these policers, the policers at that level for all protocol groups and packet types are disabled.
DDoS logging is also enabled by default. You can disable all DDoS event logging (including flow detection event logging) for all protocol groups and packet types across the router.


To configure global DDoS settings:
  1. (Optional) Disable line card policers.
    [edit system ddos-protection global]user@host# set disable-fpc
  2. (Optional) Disable Routing Engine policers.
    [edit system ddos-protection global]user@host# set disable-routing-engine
  3. (Optional) Disable event logging.
    [edit system ddos-protection global]user@host# set disable-logging

Monday, 12 August 2013

Junos : Firewall Authentication Part 2

Pass-through firewall user authentication occurs when the client is trying to access a destination on another zone using FTP, Telnet, or HTTP. After authenticating successfully, the firewall acts as a proxy for an FTP, Telnet, or HTTP server so that it can first authenticate the user before allowing access to the actual FTP, Telnet, or HTTP server behind the firewall

Configuring Pass-Through Firewall Authentication
Image auth-passthrough.gif



To configure the device for pass-through firewall authentication as shown in above, follow these steps:
  1. Create IP addresses for the interfaces on the device.
    user@host# set interfaces ge-0/0/1
    user@host# set unit 0 family inet address 20.20.20.1/24
    user@host# set unit 0 family inet address 20.20.20.2/24
    user@host# set interfaces ge-5/0/0
    user@host# set unit 0 family inet address 30.30.30.1/24
    user@host# set unit 0 family inet address 30.30.30.2/24
  2. Create an access profile, FWAUTH, for FWClient1 and specify a password, pwd.
    user@host# set access profile FWAUTH client FWClient1 firewall-user password pwd
  3. Add the FWAUTH profile for pass-through firewall authentication and define a success banner for Telnet sessions.
    user@host# set access firewall-authentication pass-through default-profile FWAUTH
    user@host# set access firewall-authentication pass-through telnet banner success "WELCOME TO JUNIPER TELNET SESSION"
  4. Create security zones.
    user@host# set security zones security-zone UT-ZONE host-inbound-traffic system-services all
    user@host# set security zones security-zone UT-ZONE interfaces ge-0/0/1.0 host-inbound-traffic protocols all
    user@host# set security zones security-zone T-ZONE host-inbound-traffic system-services all
    user@host# set security zones security-zone T-ZONE interfaces fe-5/0/0.0 host-inbound-traffic protocols all
  5. Assign a security policy, policy1, to the zones.
    user@host# set security policies from-zone UT-ZONE to-zone T-ZONE policy policy1 match source-address any
    user@host# set security policies from-zone UT-ZONE to-zone T-ZONE policy policy1 match destination-address any
    user@host# set security policies from-zone UT-ZONE to-zone T-ZONE policy policy1 match application junos-telnet
    user@host# set security policies from-zone UT-ZONE to-zone T-ZONE policy policy1 then permit firewall-authentication pass-through client-match FWclient1
  6. Use Telnet to autheticate firewall user, FWClient1, to host2.
    regress@FWClient1# run telnet 30.30.30.2
    Trying 30.30.30.2...
    Connected to 30.30.30.2.
    Escape character is '^]'.
    Firewall User Authentication
    Username: FWClient1
    Password:***
    WELCOME TO JUNIPER TELNET SESION
    Host1 (ttyp0)
    login: regress
    Password:
    --- JUNOS 8.5R1.1 built 2007-10-12 13:30:18 UTC
    %
  7. If you are finished configuring the device, commit the configuration.

Sunday, 4 August 2013

Junos : Firewall Authentication Part 1

Web authentication is an alternative to pass-through user authentication. Instead of pointing to the resource that you want to connect to from your client browser, you point the browser to an IP address on the device that is enabled for Web authentication. This initiates an HTTP session to the IP address hosting the Web authentication feature on the device. The device then prompts you for your username and password and caches the result in the device. Later, when traffic encounters a Web authentication policy, you are allowed or denied access based on the prior Web authentication results.
Web Authentication Example
Image webauth_prepol_chk.gif
Follow these Web authentication guidelines:
  • You can leave the default Web authentication server as the local database or you can choose an external authentication server for the role. The default Web authentication profile determines if the user authenticates using the local database or the external authentication server. An access profile stores usernames and passwords of users or points to external authentication servers where such information is stored.
  • The Web authentication address must be in the same subnet as the interface that you want to use to host it. For example, if you want authentication users to connect using Web authentication through ethernet3, which has IP address 1.1.1.1/24, then you can assign Web authentication an IP address in the 1.1.1.0/24 subnet.
  • You can put a Web authentication address in the same subnet as the IP address of any physical interface or virtual security interface (VSI). (For information about different types of interfaces.
  • You can put Web authentication addresses on multiple interfaces.
  • After a device authenticates a user at a particular source IP address, it subsequently permits traffic—as specified in the policy requiring authentication through Web authentication—from any other user at that same address. This might be the case if the user originates traffic from behind a NAT device that changes all original source addresses to a single translated address.
  • With Web authentication enabled, any HTTP traffic to the IP address will get the Web authentication login page instead of the administrator login page. Disabling this option will show the administrator login page (assuming that [system services web-management HTTP] is enabled.
loading...