June « 2011 « ShortestPathFirst

29Jun/118

Juniper SRX Tips :: Uniform Security Policy Modification

Often there are instances where we want to affect all security policies configured on an SRX device. For example, let's say that we have thousands of policies configured on our firewall, and we want to enable logging for every single policy. Obviously this would take some time if we were to do this manually on each and every individual policy, so an easier way is desired.

In ScreenOS we have the concept of a Global zone which acts as a container encompassing all zones, but to date, Junos does not support a similar functionality on the SRX. Furthermore, the Global zone doesn't affect existing policies but rather is way to apply a consistent policy to all Inter-zone and Intra-zone traffic that doesn't match any of the existing policies.

However, despite all of this, there is in fact a methodology we can use to uniformly modify all of the existing security policies on our box, in a manner that is actually much more powerful than what is accomplished in ScreenOS with the Global zone.

Let's take a look. First, let's say we have some policies that we would like to enable logging on:

root@ce-1# show security policies
from-zone Trust to-zone Untrust {
    policy allow-outbound {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone Untrust to-zone Trust {
    policy allow-web {
        match {
            source-address any;
            destination-address web-server;
            application junos-http;
        }
        then {
            permit;
        }
    }
}

Here you can see we have a policy allowing all traffic outbound from Trust to Untrust, and another policy allowing inbound HTTP traffic from the Untrust zone towards the Web Server in the Trust zone. Now, let's enable logging for all of our policies by using an apply-group and matching on all policies from any zone to any other zone. Note that this will encompass both Inter-zone as well as Intra-zone traffic:

groups {
    global-logging {
        security {
            policies {
                from-zone <*> to-zone <*> {
                    policy <*> {
                        then {
                            log {
                                session-init;
                            }
                        }
                    }
                }
            }
        }
    }
}

Finally, let's apply our apply-group at the [security policies] stanza within our configuration:

root@ce-1# set security policies apply-groups global-logging

Now that we've completed the configuration, let's examine the results of the application of our apply-group by taking a look at our security policies, this time by displaying the inherited configuration:

root@ce-1# show security policies | display inheritance
apply-groups global-logging
from-zone Trust to-zone Untrust {
    policy allow-outbound {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
            ##
            ## 'log' was inherited from group 'global-logging'
            ##
            log {
                ##
                ## 'session-init' was inherited from group 'global-logging'
                ##
                session-init;
            }
        }
    }
}
from-zone Untrust to-zone Trust {
    policy allow-web {
        match {
            source-address any;
            destination-address web-server;
            application junos-http;
        }
        then {
            permit;
            ##
            ## 'log' was inherited from group 'global-logging'
            ##
            log {
                ##
                ## 'session-init' was inherited from group 'global-logging'
                ##
                session-init;
            }
        }
    }
}

As you can see, with a couple of lines of code we can alter all of the existing policies on our device without having to resort to manual configuration of each and every one. This type of functionality is perfect when we want to have a singular set of configuration elements apply to all of our policies uniformly. On the other hand, if there are certain policies that we don't want to inherit these settings, we can simply utilize the apply-group-except statement for each of those respective policies.

In our next article we will examine how to change the default-deny behavior on the SRX to also including logging of denied packets.

Filed under: Firewalls, Juniper, Network Security 8 Comments

21Jun/1112

JNCIE Tips from the Field :: Summarization Made Easy

Today we'll start with a series of articles covering tips and techniques that might be utilized by JNCIE candidates, whether pursuing the JNCIE-SP, JNCIE-ENT, or even the JNCIE-SEC. The tips and techniques I will be covering might prove to be useful during a lab attempt but could also be used in real-world scenarios to save time and minimize configuration burden in addition to eliminating mistakes that might otherwise be made. I want everyone to understand that what I am about to write is simply a technique. I am not divulging any materials or topics which are covered under NDA.

NOTE: For full disclosure, I must reveal that I am an employee of Juniper Networks in their Education Services department. As such, I take the responsibility of protecting the content and integrity of the exam as well as the certification credentials very seriously. I would never reveal anything which would allow a candidate to have in-depth knowledge of any specific topics or questions that may appear on the exam. Not only that, I worked REALLY, REALLY hard to achieve my JNCIE certifications, and I believe everyone else should too! It's certainly more rewarding that way too don't you think?!

So without further delay, let's take a look at today's technique.

It is well known that sumarization is a key aspect of any type of practical exam involving routing of some sort. Those who have ever taken a CCIE Routing & Switching or CCIE Service Provider exam can attest, summarization is one thing every expert level candidate needs to master. It is no different with Juniper. In fact, Juniper's certification web page clearly lists as one of the JNCIE-ENT exam objectives the requrement to "Filter/summarize specific routes".

What I will show you next is a technique which I find quite handy when attempting to determine the best summary for a given route, and you can do so without having to resort to pen and paper and figuring it out the old fashioned way, i.e. looking at prefixes in binary. This technique, rather, allows you to use the power of Junos to your advantage to perform these tasks. What I will reveal will also show you a fundamental difference between IOS and Junos and highlights why I believe Junos to be a more flexible, powerful, and superior network operating system. You simply can't do what I am about to do on a Cisco platform running IOS.

So let's start off by looking at a diagram. Let's say we have a network that has several OSPF areas, and we must summarize some information for each respective area towards the backbone without encompassing routing information that might exist outside of that area.

ospf-summarization-example

Here we can see we have a backbone area, consisting of two routers, P1 and P2. P1 is acting as an ABR for Area 1 and is connected to both R1 and R2. P2 is acting as an ABR for Area 2 and is connected to R3. As you can see from the diagram, I have configured more than a single set of IP addresses on many of the physical interfaces as well as the loopbacks. This way I can represent many more networks and therefore create multiple Network LSAs for purposes of summarization.

So let's assume that we need to create the largest aggregate possible for a particular area and advertise only that aggregate towards the core without encompassing any routes which might be outside the area from which the summary describes. Now normally, one would take a look at the diagram, get out a pen and paper, and start a lengthy exercise of supernetting based on binary addresses. This can take several minutes or more and is valuable time that could certainly be used on wide variety of other more important tasks like setting up MPLS LSPs or troubleshooting that Layer 2 VPN connectivity. So let's take a look at a simple trick that actually takes advantage of Junos to determine what the summary should be.

What we are going to do is take advantage of a feaure inside Junos which automatically shows us a range of prefixes which match a given CIDR block. The Junos operating system has built-in route matching functionality which allows us to specify a given CIDR block and returns all routes with a mask length equal to or greater than that which is specified. So by applying this principle, what we want to do is look at the diagram for a particular area, choose the lowest IP within that area as our base, and then apply a subnet mask to it which attempts to encompass that route as well as others.

For example, looking at this diagram, we see that the lowest IP address being used in Area 1 is the 168.10.32.1 address assigned to R1's loopback. So let's start by using this as our base for our summary, and then simply apply a subnet mask to it which we think might encompass additional routes:

sfouant@p1# run show route 168.10.32.0/22

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.32.1/32     *[OSPF/10] 8w4d 19:04:48, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:48, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:43, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:43, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0

Note: We can do this on any router within Area 1 since the Link-State Database is the same on all devices, but I prefer to perform the work on the ABR since this is where I will be performing the aggregation. Also, the ABR may have other local and/or direct routes (or perhaps routes from other protocol sources) so we want to see things from the perspective of the ABR.

What we see here is that we have just now determined the summary route which in fact encompasses all the loopback addresses on both R1 as well as R2, but we need to keep going because this doesn't incorporate the Gigabit Ethernet links between all the devices:

sfouant@p1# run show route 168.10.32.0/21

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.32.1/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:45, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:45, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0

Not quite. Let's keep trying:

sfouant@p1# run show route 168.10.32.0/20

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.32.1/32     *[OSPF/10] 8w4d 19:04:55, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:55, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:50, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0

Nope, still not there yet. Let's try again:

sfouant@p1# run show route 168.10.32.0/19

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.32.1/32     *[OSPF/10] 8w4d 19:04:58, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:04:58, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:53, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:53, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0
168.10.48.4/30     *[OSPF/10] 00:36:26, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.48.8/30     *[Direct/0] 8w4d 19:36:13
                    > via ge-0/0/1.0
168.10.48.9/32     *[Local/0] 8w4d 19:36:13
                      Local via ge-0/0/1.0
168.10.60.0/30     *[Direct/0] 8w4d 19:51:31
                    > via ge-0/0/0.0
168.10.60.1/32     *[Local/0] 8w4d 19:51:31
                      Local via ge-0/0/0.0
168.10.60.4/30     *[OSPF/10] 00:36:26, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.60.8/30     *[Direct/0] 8w4d 19:36:13
                    > via ge-0/0/1.0
168.10.60.9/32     *[Local/0] 8w4d 19:36:13
                      Local via ge-0/0/1.0

Ok, this looks more like it. Here we can see we have all the Gigabit Ethernet links connecting all devices, as well as the loopback addresses. This might be a suitable summary. Let's keep going to see what happens:

sfouant@p1# run show route 168.10.32.0/18

inet.0: 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.0.1/32      *[Direct/0] 8w4d 19:51:37
                    > via lo0.0
168.10.0.2/32      *[Direct/0] 8w4d 19:36:19
                    > via lo0.0
168.10.0.3/32      *[OSPF/10] 00:28:41, metric 1
                    > to 168.10.18.2 via fe-0/0/2.0
                      to 168.10.26.2 via fe-0/0/2.0
168.10.0.4/32      *[OSPF/10] 00:28:41, metric 1
                    > to 168.10.18.2 via fe-0/0/2.0
                      to 168.10.26.2 via fe-0/0/2.0
168.10.18.0/30     *[Direct/0] 8w4d 19:05:28
                    > via fe-0/0/2.0
168.10.18.1/32     *[Local/0] 8w4d 19:05:28
                      Local via fe-0/0/2.0
168.10.26.0/30     *[Direct/0] 8w4d 19:05:28
                    > via fe-0/0/2.0
168.10.26.1/32     *[Local/0] 8w4d 19:05:28
                      Local via fe-0/0/2.0
168.10.32.1/32     *[OSPF/10] 8w4d 19:05:04, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.2/32     *[OSPF/10] 8w4d 19:05:04, metric 1
                    > to 168.10.60.2 via ge-0/0/0.0
168.10.32.3/32     *[OSPF/10] 8w4d 19:04:59, metric 1
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
168.10.32.4/32     *[OSPF/10] 8w4d 19:04:59, metric 1
                    > to 168.10.48.10 via ge-0/0/1.0
                      to 168.10.60.10 via ge-0/0/1.0
168.10.48.4/30     *[OSPF/10] 00:36:32, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.48.8/30     *[Direct/0] 8w4d 19:36:19
                    > via ge-0/0/1.0
168.10.48.9/32     *[Local/0] 8w4d 19:36:19
                      Local via ge-0/0/1.0
168.10.60.0/30     *[Direct/0] 8w4d 19:51:37
                    > via ge-0/0/0.0
168.10.60.1/32     *[Local/0] 8w4d 19:51:37
                      Local via ge-0/0/0.0
168.10.60.4/30     *[OSPF/10] 00:36:32, metric 2
                      to 168.10.48.10 via ge-0/0/1.0
                    > to 168.10.60.10 via ge-0/0/1.0
                      to 168.10.60.2 via ge-0/0/0.0
168.10.60.8/30     *[Direct/0] 8w4d 19:36:19
                    > via ge-0/0/1.0
168.10.60.9/32     *[Local/0] 8w4d 19:36:19
                      Local via ge-0/0/1.0

Clearly from this command, we can see we have now gone beyond what might be considered a suitable summary because we are now encompassing routes that exist within the backbone Area 0. So it should be clear from this simple set of commands that the 168.10.32.0/19 would be a suitable address to use for our summary.

We could easily apply a similar example to Area 2 to quickly determine what the best summary would be. We see from looking at the diagram the lowest IP within Area 2 is the 168.10.96.1 loopback address applied to R3. When we use that as our base and go through the steps above, we can find our summary:

sfouant@p2# run show route 168.10.96.0/19

inet.0: 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

168.10.96.1/32     *[OSPF/10] 01:00:57, metric 1
                      to 168.10.112.2 via fe-0/0/3.0
                    > to 168.10.118.2 via fe-0/0/3.0
168.10.96.2/32     *[OSPF/10] 01:00:57, metric 1
                    > to 168.10.112.2 via fe-0/0/3.0
                      to 168.10.118.2 via fe-0/0/3.0
168.10.112.0/30    *[Direct/0] 01:13:48
                    > via fe-0/0/3.0
168.10.112.1/32    *[Local/0] 01:13:48
                      Local via fe-0/0/3.0
168.10.118.0/30    *[Direct/0] 01:13:48
                    > via fe-0/0/3.0
168.10.118.1/32    *[Local/0] 01:13:48
                      Local via fe-0/0/3.0

And there you have it! As you can see it's really quite simple and if you haven't stumbled upon this already you may be saying to yourself, "Why didn't I think of that before?". I hear from many candidates that they spend considerable time the old fashioned way to determine summaries and I always ask myself why. As you can see, there is an easier way!

Clearly the benefit to using a technique such as the above is to easily find the routes that best summarize a bunch of more specific routes. The utility of such an approach, while very useful during a practical exam, might be considerably lessened in the real-world where it is likely that hierarchy has already been built into the network and you have network diagrams at your disposal. On the other hand, there may be situations where you inherit a network that was developed with hierarchy in mind, however summarization was never employed, or it was employed improperly. In such cases, the above technique can be a real time saver, allowing you to spend less time doing binary math and more time doing the fun stuff - like troubleshooting why that MPLS LSP isn't getting established!

Stay tuned for additional articles covering time saving tips and techniques which can be used during your next lab attempt! Good luck, and may the force be with you!

Filed under: Juniper, Juniper Certifications, Network Design, Routing Protocols 12 Comments

20Jun/110

Day One Guide: Junos Tips, Techniques, and Templates 2011

small-junos-tips-2011 I am happy to announce that Juniper has just released a new Day One Guide entitled "Junos Tips, Techniques, and Templates 2011". For this particular Day One Guide, Juniper Networks Books and J-Net joined forces and requested the best and brightest Junos tips and techniques from the Junos user community. In fact, the book was created after a thorough selection process which included reviewing over 300 submitted tips by over 100 individuals on the J-Net community boards at forums.juniper.net.

I am honored that Juniper accepted my contributions and decided to include them in this guide. My contribution "Automatically Allow Configured BGP Peers in a Loopback Firewall Filter" covers how to configure a Junos prefix-list in conjunction with the apply-path features to parse a configuration and then dynamically build a list of matching prefixes for use in a firewall filter.

Outside of my meager contribution, this guide is chock full of dozens of useful tips and techniques and is an indispensable guide for anyone involved in managing Juniper platforms on a daily basis.

Junos Tips, Techniques, and Templates 2011 can be ordered on Amazon in hardcopy or Kindle edition, and is also available as a free download in PDF format. Enjoy!