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.

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

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

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.

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

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.

Junos OS Release Changes for 2013-2014

Junos OS Release Changes for 2013-2014
Juniper is adjusting the Junos OS release schedule for 2013 and 2014 to better align our software development to new Juniper products for the cloud, data center and mobile markets. Below are the specifics:

• Junos OS 13.2 will ship in August 2013.
• Junos OS 13.3 moves to 1Q 2014 and remains an Extended End-of-Life (EEOL) release.
• Junos OS 14.1 will ship 1H 2014.
• Junos OS 14.2 will ship in 2H 2014.
• Junos OS 14.3 feature content will be delivered in 2015.

Release Changes Old and New Plan

Junos OS SRX Series News

• Junos OS 12.1R7 scheduled for release July 25, 2013, will be in the final 12.1R release for SRX Series platforms.
• 11.4 EEOL will continue to support SRX Series platforms.
• Junos OS 12.1x44 will deliver new features for the SRX Series platform.

Junos : SRX Traffic Shaping

let us assume, you want to limit traffic coming from the subnet 10.132.245.0/24 to 50Mbps on the outgoing interface ge-0/0/0.

Here is how you do it:

Note: monitor  the 'ddn' queue and 'ddn scheduler'.

Configuration:

class-of-service {
    forwarding-classes {
       queue 1 real-time;
       queue 2 burst-hi;
       queue 0 best-effort;
       queue 3 network-control;
       queue 4 ddn;
    }
interfaces {
    ge-0/0/0 {
        unit * {
            scheduler-map cos-map;
            shaping-rate 1g;
        }
    }
}
scheduler-maps {
    cos-map {
        forwarding-class real-time scheduler rt-scheduler;
        forwarding-class burst-hi scheduler bh-scheduler;
        forwarding-class best-effort scheduler be-scheduler;
        forwarding-class network-control scheduler nc-scheduler;
        forwarding-class ddn scheduler ddn-scheduler;
    }
}
schedulers {
    nc-scheduler {
        transmit-rate 70k;
        buffer-size percent 5;
        priority high;
    }
rt-scheduler {
    transmit-rate 50k;
    buffer-size percent 1;
    priority high;
}
bh-scheduler {
    transmit-rate 100k;
    buffer-size percent 10;
    priority medium-high;
}
be-scheduler {
    transmit-rate remainder;
    buffer-size remainder;
    priority low;
}
ddn-scheduler {
    transmit-rate 50m exact; << Key word “exact” solved the issue
    buffer-size percent 40;
    priority low;
}
}
}

firewall {
    family inet {
        filter ddn-traffic {
            term 1 {
               from {
                   source-address {
                       10.132.245.0/24;
                   }
               }
then {
    forwarding-class ddn;
       accept;
}
            }
term default {
    then {
       forwarding-class best-effort;
           accept;
   }
}
        }
   }
}


Procedure:

1. Create a separate queue; that is the queue for ddn.


2. Then create a scheduler; that is the ddn-scheduler.


3. Define the exact rate, at which you want to limit the traffic that belongs to that class.


4. Create a scheduler-map and attach the ddn-scheduler to the map.


5. Define a firewall filter, which matches the traffic you want to forward through the ddn class.


6. If the exact keyword is not defined, then the traffic will go up to 50Mbps and then snatch the available BW; if no other class is utilizing the BW.

Junos : VRRP

For Ethernet, Fast Ethernet, Gigabit Ethernet, 10-Gigabit Ethernet, and logical interfaces, you can configure the Virtual Router Redundancy Protocol (VRRP) or VRRP for IPv6. VRRP enables hosts on a LAN to make use of redundant routing platforms on that LAN without requiring more than the static configuration of a single default route on the hosts. 

The VRRP routing platforms share the IP address corresponding to the default route configured on the hosts. At any time, one of the VRRP routing platforms is the master (active) and the others are backups. If the master fails, one of the backup routers or switches becomes the new master router, providing a virtual default routing platform and enabling traffic on the LAN to be routed without relying on a single routing platform. Using VRRP, a backup router can take over a failed default router within a few seconds. This is done with minimum VRRP traffic and without any interaction with the hosts.

Routers or running VRRP dynamically elect master and backup routers. You can also force assignment of master and backup routers using priorities from 1 through 255, with 255 being the highest priority. In VRRP operation, the default master router sends advertisements to backup routers at regular intervals. The default interval is 1 second. If a backup router does not receive an advertisement for a set period, the backup router with the next highest priority takes over as master and begins forwarding packets.

Configure one master (Router A) and one backup (Router B) routing platform. The address configured in the virtual-address statements differs from the addresses configured in the address statements. When you configure multiple VRRP groups on an interface, you configure one to be the master virtual router for that group.

On Router A

[edit interfaces]

ge-0/0/0 {unit 0 {family inet {address 192.168.1.20/24 {vrrp-group 27 {virtual-address 192.168.1.15;priority 254;authentication-type simple;authentication-key booJUM;}}}}}

On Router B

[edit interfaces]

ge-4/2/0 {unit 0 {family inet {address 192.168.1.24/24 {vrrp-group 27 {virtual-address 192.168.1.15;priority 200;authentication-type simple;authentication-key booJUM;}}}}}

Configuring One Router to Be the Master Virtual Router for the Group

[edit interfaces]

ge-0/0/0 {unit 0 {family inet {address 192.168.1.20/24 {vrrp-group 2 {virtual-address 192.168.1.20;priority 255;advertise-interval 3;preempt;}vrrp-group 10 {virtual-address 192.168.1.55;priority 201;advertise-interval 3;}vrrp-group 1 {virtual-address 192.168.1.54;priority 22;advertise-interval 4;}}}}}

Configuring VRRP and MAC Source Address Filtering

The VRRP group number is the decimal equivalent of the last byte of the virtual MAC address.

[edit interfaces]

ge-5/2/0 {gigether-options {source-filtering;source-address-filter {00:00:5e:00:01:0a; # Virtual MAC address}}unit 0 {family inet {address 192.168.1.10/24 {vrrp-group 10; # VRRP group numbervirtual-address 192.168.1.10;priority 255;preempt;}}}}