Category Archives: Juniper

Working with IPv6 and Juniper SRX

Posted by on November 22, 2011 14 comments

I finally decided that if I don’t run IPv6 then I am never truly going to understand it. I figured the best place to get started would be my own home. I didn’t want to completely get rid of my IPv4 network, I only wanted to try to get IPv6 up and running, so I decided to run a dual-stack. Since the computers are running Windows 7 and I have an SRX100 as our household firewall this proved not to be a problem. Also, it was only an after-thought, but apparently our wireless access point would pass the IPv6 traffic without any problems. My next problem was external IPv6 connectivity, what good would my private IPv6 network be if I couldn’t connect to any other IPv6 networks?

Enter Hurricane Electric and their free IPv6 tunnel broker service at http://tunnelbroker.net/. This is a free service that allows you to build a 6to4 tunnel to their network which then acts as your IPv6 gateway. 6to4 tunneling (RFC 3056 http://tools.ietf.org/html/rfc3056) is an IPv6 transition mechanism which allows IPv6 packets to be encapsulated (aka tunneled) within IPv4 packets to a 6to4 gateway router which is then de-encapsulated and sent on to IPv6 networks. So I registered with HE using my external IPv4 address as the tunnel end-point and was assigned my tunnel endpoints as well as my very own routed /64 block of IPv6 addresses. I was also given an IPv6 DNS server to point to. It was finally time to get IPv6 up and running.

The first thing I needed to do was get my tunnel up and running. On my SRX100 this involved creating an IP tunnel interface, adding an IPv6 static route, and putting the SRX in packet-mode for IPv6 traffic.

interfaces {
   ip-0/0/0 {
      unit 0 {
         tunnel {
            source 99.111.88.228;
            destination 216.66.22.2;
         }
         family inet6 {
            address 2001:470:7:e9e::2/64;
         }
      }
   }
}
routing-options {
   rib inet6.0 {
      static {
         route ::/0 next-hop 2001:470:7:e9e::1;
      }
   }
}
security {
   forwarding-options {
      family {
         inet6 {
            mode packet-based;
         }
      }
   }
}

At that point I could see my tunnel was operational and I was able to ping the remote end of the tunnel. Next I needed to get IPv6 running internally. I decided to use Stateless Address Auto Configuration (SLAAC) for address configuration. Devices running IPv6 will automatically configure for themselves a link-local address. This address is created using the FE80::/64 block + the EIU64 Interface ID. The EIU64 Interface ID is dynamically created using the Ethernet MAC address. The link-local address is required for basic IPv6 operations such as Neighbor Discovery Protocol (NDP) which is used for SLAAC. Basically the link-local address allows for local communication of hosts without configuration in order to facilitate higher-level communications. One thing about link-local address are that they are not globally routable, which means that my computers with only a link-local IPv6 address would not be able to communicate with other IPv6 devices such as web servers.

I needed to use my /64 block of globally routable IPv6 addresses I was given and assign them to my hosts. To do this I needed to configure IPv6 Router Advertisements (RAs) to allow my hosts to use SLAAC and auto-configure themselves an IPv6 address.

interfaces {
   vlan {
      unit 0 {
         family inet {
            address 192.168.1.1/24;
         }
         family inet6 {
            address 2001:470:8:e9e::1/64;
         }
      }
   }
}
protocols {
   router-advertisement {
      interface vlan.0 {
         max-advertisement-interval 20;
         min-advertisement-interval 15;
         prefix 2001:470:8:e9e::/64;
      }
   }
}

Now my hosts have both a link-local and a global IPv6 address and are able to ping through my tunnel. So far I haven’t done enough experimenting to get DHCPv6 working for DNS server assignment so I currently have my hosts DNS servers statically configured. I was then able to go online and check my IPv6 connectivity via http://test-ipv6.com/.

Caveats:
Packet-based forwarding of IPv6 – Still researching the implications of this in regards to security
Had to use Junos 10.4R7.5 to assign family inet6 on vlan interfaces
Still have to experiment with DNS server assignment either through DHCPv6 or some other means
Lack of IPv6 websites/stuff to do
Security Considerations for 6to4 RFC 3964 http://tools.ietf.org/html/rfc3964

CLI Shortcuts

Posted by on October 18, 2011 2 comments

In my attempt to become a CLI wizard I felt like I needed to gain a little more speed and control when I’m at the command line. Holding down arrow keys or the backspace key is really a time waster, and not very accurate. So I dug around a little and found these shortcut combos. I’ve tested them in PuTTY on both a Cisco and Juniper device.

Move to Begining of Line
Ctrl+a

Move to End of Line
Ctrl+e

Move Forward a Word
Alt+f

Move Backward a Word
Alt+B

Delete a Line (On Cisco, Only Worked From End of Line)
Ctrl+x or Ctrl+u

Delete a Character (Under Cursor)
Ctrl+d

Delete Word Forward (In Front of Cursor)
Alt+d or Esc+d

Delete Word Backwards (Behind Cursor)
Ctrl+w or Alt+Backspace

Clear Line From Cursor Forward
Ctrl+k

SRX Firewall User Authentication

Posted by on October 17, 2011 No comments

Juniper SRX firewalls have a feature called Firewall User Authentication. FUA is another layer of protection on top of security policies to restrict/permit users or groups of users individually. FUA is a very limited feature but it could be used as a poor-man’s NAC in a pinch. Users are authenticated via a single external source(RADIUS, LDAP, or SecureID) or the local database. FUA can operate in two different modes, Pass-Through Authentication, and Web Authentication.

Pass-Through Authentication is limited to Telnet, FTP, and HTTP traffic only(notice these are plain-text protocols). Pass-through auth works by interjecting a login challenge into the original protocol login challenge. For example a user would initiate a telnet connection, the FUA would interject and prompt the security challenge. Once authenticated, traffic from the same source IP is automatically allowed to pass through the SRX(could be dangerous with source NAT). This would allow the telnet connection to continue and the user can authenticate to the telnet host. Once the user has authenticated via FUA the IP address becomes exempt from further FUA requirements. This means that you can create a security policy that matches on ANY traffic type and require FUA; Pass-through authentication only works with Telnet, FTP, or HTTP, however once the IP/user has authenticated then it is exempt from further FUA, and it is then only bound by security policy. I said that to say this: you can use a telnet session to authenticate a user via FUA who, once authenticated, can pass any type of traffic which is allowed by the security policy.

Web Authentication operates in two sub-modes, standard web authentication, and web redirect. Standard web auth first requires you enable the HTTP system service, and also allow http in host-inbound-traffic. With standard web auth, you would direct your users to a secondary IP address of an interface on the SRX. Users would be prompted with an HTTP login form for the FUA. Once authenticated the IP address is added to the exempt list and is able to pass through the firewall as much as security policy allows. The web redirect operates like standard web auth, but you don’t have to hand out an IP address of your firewall or direct users to a separate login page. Web redirect works much like what you’re used to in a hotel room; You open your browser and head to Google.com, and you are automagically redirected to a login page. Once you authenticate you are able to pass through the firewall as much as security policy allows.

With all the authentication methods you are also able to configure a default timeout for inactivity and login/success/failure banners. Web redirect + a login banner would be a great poor-man option for a Guest Wireless NAC. You could hand out the username and password to guests, and they would be prompted with the Acceptable Use Policy before logging in.

All FUA configuration follows the same basic principles: configure an access profile, configure the firewall authentication options, and finally call on the firewall authentication from security policy. (Good to know on an exam).

Configure the access profile (local user database):

set access profile *profile-name* client *name* firewall-user password *pwd*

or (external authentication):

set access profile *profile-name* authentication-order [radius password]
set access profile *profile-name* radius-server *ip-address* secret *radius-secret*

Then configure the authentication type and options:

set access firewall-authentication pass-through default-profile *profile-name*
set access firewall-authentication pass-through [telnet/ftp/http] banner login "You must login"

or

set interface *name* unit 0 family inet address *ip/mask* web-authentication http
set access firewall-authentication web-authentication default-profile *profile-name*
set access firewall-authentication web-authentication banner success "Login successful"

Finally set a permit action of firewall-authentication in the security policy. For pass-through use: “Permit firewall-authentication pass-through client-match *client-name*”. For web auth use: “Permit firewall-authentication web-authentication client-match *client-name*”. For web redirect use the same as pass-through but add a web-redirect argument: “Permit firewall-authentication pass-through web-redirect”.

And finally to verify:

show security firewall-authentication users
show security firewall-authentication history

Security Policy and Address Groups

Posted by on September 29, 2011 5 comments

I recently sat through a Juniper Security (JSEC) training course and learned something new about security policy regarding the objects that are able to be referenced in policy. When I got back to work I had a few rules I needed to add and some that needed to be removed so I thought it would be a good point to make the switch. I am talking about the use of address groups in security policy. Before we can reference a prefix in security policy it must be created as an address object. These address objects are stored in an address-book per security zone.  We can also create address-sets (Junos) and address groups (ScreenOS) which are basically groups consisting of individual address members. When we create a security policy, instead of creating a policy for each address entry, we can reference the address-set/address group to apply the policy to like entries. This allows us to change individual entries for a policy without directly affecting the policy. For example, I have a group of 5 servers that need web access to download updates, but I don’t want the entire zone to have Internet access. Instead of creating 5 individual policies I can create a single policy and refence an address-set/address group which consists of the 5 server address objects. In the future if I ever decide to give a new server Internet access or I need to remove Internet access for a server, I don’t have to worry about cluttered policies, I can just add or remove an address to the address-set/address group.

Junos

We first need to create our address objects:

set security zones security-zone *ZoneName* address-book *AddressName* x.x.x.x/y

Then we need to create our address-set:

set security zones security-zone *ZoneName* address-book address-set *SetName* address *AddressName*

A few caveats, an address-set can only exist when there multiple addresses in the address-book. An address-set can only contain addresses from the same security zone, and also the address-set name cannot be the same as an existing address name.

ScreenOS

First create the address objects:

set address *ZoneName* *AddressName* x.x.x.x/y *Comment*

Then create the address group:

set group address *ZoneName* *GroupName* *Comment*
set group address *ZoneName* *GroupName* add *AddressName*

One thing I noticed in the Junos TechPubs was that when you reference an address-set in policy Junos creates an internal rule for each member, as well as each service. So if you create a policy which references an address-set for both source and destination and also a service group, Junos actually creates multiple internal rules. If you don’t pay attention to the size of your groups you could exceed policy resources even though it appears you have a relatively small number of configured policies.

The main point I want to convey isn’t necessarily how to configure address sets/groups, but to motivate you to use them. It’s standard practice in the Windows AD realm where you rarely want to give an individual user rights to a server, it’s much cleaner to give a security group rights to the server and then manage the membership of that group. This is particularly helpful if the same group will be referenced on multiple servers. The same concept applies to our firewall security policies.

So go forth and simplify your firewall rules…

Link Aggregation Showdown – Juniper, Cisco, VMware

Posted by on July 25, 2011 3 comments

A friend and I got into a discussion regarding supported link aggregation methods between VMware and various networking vendors. As I was trying to inform him of the differences, I was sure to do my research and I thought I would share.

He was using Cisco switches and wanted to run LACP because he thought that Cisco’s Etherchannel did not have any negotiation protocol unless you used LACP. He then thought that VMware would support LACP, since it was an open standard after-all. We have both been bitten by misconfigured link aggregations when connecting to VMware. It turns out he was wrong here on both fronts. First of all, VMware only supports static configuration for link aggregation (NIC teaming as they call it.) Secondly, Cisco’s Etherchannel does support negotiation using PAgP(Cisco Proprietary), if configured to do so. I just wanted to point this out for future reference. So I put together a quick cheat sheet for him to use building link aggregation bundles across vendors.

Static Link Aggregation:
VMware – Configure the port group NIC teaming to “Route Based on IP Hash”
Cisco – 

port-channel # mode on

Juniper – 

set interface <name> ether-options 802.3ad ae#

Link Aggregation Negotiation (LACP):
VMware – Not Supported
Cisco – 

port-channel # mode active

Juniper – The Static Configuration + 

set interface ae# aggregated-ether-options lacp active

Link Aggregation Negotiation (PAgP):
VMware – Not Supported
Cisco – 

port-channel # mode desirable

Juniper – Not Supported

There are also passive configuration options for both LACP and PAgP, however I prefer to always statically define my port roles. These are also not complete configs for either Cisco or Juniper, I merely wanted to point out the differences in the commands between the different vendors.

OSPF Quick Notes

Posted by on May 6, 2011 5 comments

OSPFv2 – RFC2328
OSPFv3 – RFC5340
Opaque LSA Option – RFC2370

All OSPF Routers Multicast Address – 224.0.0.5
All OSPF DRs Multicast Address – 224.0.0.6

OSPF Packet Types

  • Type 1 – Hello – Used to discover & maintain neighbors
  • Type 2 – DBD – (Data Base Descriptor) Used in adjacency formation process to exchange LSAs
  • Type 3 – LSR – (Link State Request) Used when LSDB becomes stale or is missing an LSA
  • Type 4 – LSU – (Link State Update) Contains LSAs
  • Type 5 – LSAck – (Link State Acknowledgement) Acknowledges LSAs
    *An individual link-state acknowledgment packet can contain an acknowledgment for a single link-state update packet or for multiple link-state update packets. – JNCIS-ENT Routing Study Guide

OSPF Adjacency States

  • Down – Initial state, waiting for start event
  • Init – Hello sent but bidirectional communication not established
  • 2Way – Hello received, bidirectional communication established
  • ExStart – Routers negotiate who in in charge of LSDB sync
  • Exchange – Exchange LSA headers, if missing data send LSR
  • Full – LSDBs fully sync’d

OSPF Router Types

  • DR – Designated Router – Represent multiple routers on a broadcast link
  • DR forms Full adjancies with all DROthers and the BDR
  • BDR – Backup Designated Router
  • BDR forms Full adjancies with the DR and all DROthers, does not advertise learned link state info
  • DROther – Other routers on a broadcast link
  • DROthers form 2Way adjacencies with each other
  • ABR – Area Border Router – Router with links to at least 2 different areas
  • ASBR – Autonomous System Boundary Router – Injects information from outside the OSPF AS
  • Backbone Router – Any router with a link to the Backbone Area
  • Internal Router – Any router with all links in the same area

OSPF Area Types
*Multiple areas are used to shrink LSDB size and isolate troubles

  • Backbone Area (Area 0) – Distributes routes between different areas
  • Stub Area – No AS External LSAs (Type 4 & 5) are flooded, ABR floods default route
  • Totally Stubby Area – Receives only default route (No Type 3, 4, or 5)
  • Not-So-Stubby-Area – Can receive and leak external routes in area, but external routes from other areas are not flooded (No Type 4 & 5)

OSPF Route Types

  • External – Redistributed from other protocols (LSA Type 5 & 7)
  • Inter-Area – (Summary Routes) Originate from other areas (LSA Type 3 & 4)
  • Intra-Area – (Internal Routes) Originate within same area (LSA Type 1 & 2)

OSPF LSA Types

  • Type 1 – Router – Intra-Area Adjacencies (DROther to DR)
  • Type 2 – Network – Describe Broadcast Segment (DR to DROthers)
  • Type 3 – Summary – Area Summary Sent by ABR to other areas
    *OSPFv3 – Inter-Area-Prefix-LSA
    • As re-injected into other areas LSA type doesn’t change
  • Type 4 – ASBR Summary – ASBR Description Sent by ABR to other areas
    *OSPFv3 – Inter-Area-Router-LSA
    • As re-injected into other areas LSA type doesn’t change
  • Type 5 – AS-External – Sent by ASBR describing prefixes from other protocols
    *OSPFv3 – AS-External-LSA
    • As re-injected into other areas LSA type doesn’t change
  • Type 6 – Used by Multicast OSPF, deprecated in OSPFv3
  • Type 7 – NSSA External – Sent by ASBRs in NSSAs
    • Translated to Type 5 LSA by NSSA ABR
  • Type 8 – External Attributes (Intended to mimic capability of iBGP)
    *OSPFv3 – Link-LSA
  • Type 9 – Opaque LSA (Link Scope)
    *OSPFv3 – Intra-Area-Prefix-LSA
  • Type 10 – Opaque LSA (Area Scope)
  • Type 11 – Opaque LSA (AS Scope)

JUNOS – Destination NAT as Port Forwarding

Posted by on March 25, 2011 3 comments

I recently moved into a new house and a new cable Internet provider. I decided I’d take the opportunity to upgrade my home network and implement a Juniper SRX100 (I <3 JUNOS) as my Internet router/firewall.

The initial setup of the SRX100 was surprisingly pain-free. I had to reset it to factory defaults after I had been using it for some labbing, and the factory default config worked pretty much out of the box. I run a few private servers at my house and needed to setup some port forwarding as I only have a single public IP address. You can easily accomplish this with JUNOS Destination NAT, and I would like to share with you some interesting quirks I found in its implementation.

Destination NAT works by specifying NAT rules based upon a packet’s destination address (and port). By configuring NAT rules based on the destination address of your public IP address you’re able to to redirect a certain address or port to a private internal address of your choosing. In the case of the standard home user you would specify rules for different ports destined (incoming) to your single public IP address to be translated to multiple private addresses (one-to-many NAT). If you had multiple public IP addresses you could configure the different address to be redirected to multiple private addresses (many-to-many NAT).

Configuration of Destination NAT is also relatively simple; it only requires a destination pool for your internal server(s), NAT rules, and a security policy to allow traffic to flow between the zones.

I first configured a single pool for my internal server’s IP address:

set security nat destination pool <pool_name> address 192.168.1.5/32

Next I began to configure NAT rules for each port I wanted to forward. This is also where it got interesting. The syntax for creating NAT rules is:

set security nat destination rule-set <rule_set_name> from zone untrust
set security nat destination rule-set <rule_set_name> rule <rule_name> match destination-address 0.0.0.0/0
set security nat destination rule-set <rule_set_name> rule <rule_name> match destination-port <#>
set security nat destination rule-set <rule_set_name> rule <rule_name> then destination-nat pool <pool_name>

To keep things straightforward I named my rule-set “untrust-to-trust” and the rule names to match the port number (i.e. Port1024). Setting the destination-address to 0/0 is not in the documentation, but it will work if you rely on a dynamically assigned public IP address like I do. Another issue I ran into was a limitation on the number of rules allowed in a rule-set. Any JUNOS code version before 10.1R1 has a limitation of 8 rules per rule-set.  You can see how this could become a problem if you’re attempting to forward a range of IP addresses. A code upgrade resolved this problem for me and extended the limitation to 512 rules per rule-set. Unfortunately there is no way to configure destination NAT for a range of ports, each rule is limited to a single port definition.

The final step requires configuring a security policy and address book entry to allow traffic to cross zones:

set security zones security-zone trust address-book address <address_name> 192.168.1.5/32
set security policies from-zone untrust to-zone trust policy <policy_name> match source-address any
set security policies from-zone untrust to-zone trust policy <policy_name> match destination-address <address_name>
set security policies from-zone untrust to-zone trust policy <policy_name> match application any
set security policies from-zone untrust to-zone trust policy <policy_name> then permit

You can obviously keep your security tighter by specifying an application instead of using ‘application any’.  The NAT is applied before the security policies are checked which is why the NAT rule’s destination address is your public IP address and the security policy’s destination address is the private internal IP address.

By using Destination NAT in JUNOS  you can effectively implement port forwarding for your home network. I’m satisfied with my SRX as a home router/firewall and enjoy the flexibility it brings.

What is QFabric?

Posted by on February 24, 2011 3 comments

Yesterday Juniper released another piece to the Project Stratus puzzle. Project Stratus is Juniper’s attempt at a 3-2-1 process of flattening the data center hierarchy model. They introduced the new QFX3500 switch, and the concept of QFabric. As always, Twitter went crazy. I did enjoy the back and forth, it was educational listening to different perspectives from people much smarter than myself. A small debate broke out whether or not Juniper’s QFabric was different from Cisco’s FabricPath. I’m writing this article to hopefully entice some other opinions or blog replies. I’m sure not an expert, but I’m going to do my best to explain what I think the differences are. I’m not going to say one is better than the other, but to myself they do appear different.

Hardware

The QFX3500 is a 1U 48port 10GE switch, fully L2/L3 capable. This box seems similar to the Cisco Nexus 5548 switch. Not much to get excited about here, it was about time Juniper released something comparable.

Is there a major difference? I’m thinking no.

The Design, Stratus, QFabric

Project Stratus is supposed to consist of the QFX3500s linked back to a large chassis switch, which has yet to be released, using Juniper’s new QSFP+ ports. This is supposed to yield an extension of the control plane(packets are processed once at ingress to the “fabric”), and a single point of management. This concept sounds to me like how the Nexus 7000 can now support Nexus 2000s hanging off of it. I see two differences here: 1. Cisco does it with standard SFP+ ports(I made the mistake of not researching the standard QSFP+ ports Juniper uses), and 2. The Nexus 2000 is little more than a dumb line-card and does not do any packet processing. I’m not sure if the method how the Stratus/QFX3500 or the Nexus 7k/2k uplink is much different(i.e. fex-fabric ports vs. Juniper’s yet to be released config info), I plan on doing some more research into that.

Is there a major difference? I think a few small details, but the design is quite similar.

FabricPath = QFabric?

According to Cisco, FabricPath “brings the stability and scalability of routing to Layer 2.” FabricPath is more of a L2 domain control innovation, or a stop-gap to TRILL/SPB, than a control plane extension. However, if you look at the FEX Fabric that links Nexus 5k>2k or 7k>2k, now that is a more accurate comparison to QFabric. With FEX Fabric and QFabric, the packet is processed once, and forwarded directly to it’s destination. FabricPath still relies on multiple switch hops to operate. I think Juniper looks at from the view that if the network operates like one giant switch fabric, then there are no multiple hops and therefore no need for TRILL/SPB.

Is FabricPath = QFabric? I don’t think so. But it does sound similar to Cisco’s FEX Fabric.

Vaporware?

Yes. Juniper has only released the QFX3500 switch, which today can be used as a standard 10GE ToR switch. For Project Stratus to come together they still have to release their director chassis switch which will then use QFabric to interconnect the QFX3500s.

Final Thoughts

First I’m a little disappointed in Juniper for being so vague. If I hadn’t already talked to our Juniper reps about this release, I think I would be even more confused. Is QFabric similar to FabricPath? I still don’t think so, but I’m open to being educated. Is QFabric revolutionary? At first I thought it was, but after seeing the Twitter-discussion, I’m not so sure now. Please feel free to reply/inform/complain, I’m on Twitter @robertjuric.

Introduction to ScreenOS

Posted by on January 24, 2011 No comments

I feel like I haven’t written in a while but I’ve been going through a job transition. I finally feel like I’m starting to settle in and I thought I would share some of my new experiences learning about the Juniper Netscreen firewalls.

Unlike a majority of Juniper firewall users, I’ve had no experience with Netscreen firewalls. I was a little a little off-balance trying to pick up the SCREENOS commands, but once I got going on it I found they made logical sense and were similar to the JUNOS commands (sometimes).

My new job involves standing up a new development “enclave” network. When I arrived, a few others had turns unsuccessfully trying to make the network go, so my first task was to get the firewall passing traffic. I spent a few hours that night researching the basics of SCREENOS and the next day I was able to get the packets flowing.

SCREENOS CLI is very similar to to JUNOS in that it uses ‘set’ commands to make configuration changes. SCREENOS also differs greatly in that it uses ‘get’ commands to view config snippets.

get config
get interface
get policy

A few examples of the ‘get’ commands

I learned to imagine SCREENOS in layers. The foundation layer is the virtual-router, which closely resembles routing-instances in JUNOS. There are two system configured VRs: trust-vr and untrust-vr. The virtual routers are essentially routing table instances. The next layer is compromised of the security zones, which are by default assigned to the trust-vr virtual router. From here we need to step back and see how the Netscreen operates. It can operate in one of three modes, NAT mode, route mode, and transparent mode. I like to think of the 3rd layer of the Netscreen as the interfaces. When an interface is assigned to the Trust security zone it is by default configured in NAT mode, if you wish to configure straight routing you must explicitly configure it. Also, before you can assign an IP address to an interface, the interface must first be assigned to a security zone.  

set int eth2/1 zone Trust
set int eth2/1 ip 10.10.1.1/30
set int eth2/1 route
set int eth1/1 zone Untrust
set int eth1/1 ip 10.10.2.1/30

Now that we have our virtual router, security zones, and interfaces configured, the next layer consists of the routing and security policies which will allow the traffic to flow. The first thing we can do is configure a static default route:

set route 0.0.0.0/0 interface eth1/1 gateway 10.10.2.2

The next thing we need to do is configure a security policy to allow some traffic to flow through our security zones:

set policy from Trust to Untrust any any any permit

This policy consists of a source zone, destination zone, source object, destination object, and control action. More simply it reads: From zone Trust to zone Untrust and from any address to any address using any protocol then allow. Like JUNOS, SCREENOS uses address objects any time it references a specific IP or range of IPs in a security policy. For instance:

set address DMZ 192.168.75.1/32 "Exchange"
set address Untrust 1.1.1.16/28 "SmartHost"
set policy from Untrust to DMZ SmartHost Exchange smtp permit

That’s pretty much the basics of getting the firewall to pass traffic. A quick note with the policies. If you do a ‘get policy’ it will list a policy id number next to each entry. You can then do ‘unset policy id #’ to remove policies. I just wanted to take a second to share with you my introduction to SCREENOS. I plan to write some more about it and the Netscreen firewalls as I spend more time working with them.

JUNOS – Security Policies

Posted by on December 21, 2010 No comments

As I have been continuing to setup our Juniper SRX firewalls I thought I would take a moment to discuss how to implement security policies in JUNOS. Before we get started I think it’s important to cover a few quick concepts:

  • Stateful Firewall – Monitors the state of network connection streams so that when traffic is inspected and permitted in one direction, the return traffic is also permitted.
  • Zone-Based Firewall – Interfaces are arranged into groups called zones to build security boundaries
  • JUNOS Security Policy Applications – Applications are a sort of profiles for apps which have defined protocol standards. Applications store information such as transport protocol, source and destination port numbers, and timeout values. These applications can be grouped into an Application-Set in order to simplify policy creation for multi-port applications. JUNOS has many predefined applications and also has the capability to define custom applications as needed. For more information, check out Juniper’s documentation.
  • JUNOS Security Addresses – When building security policies, JUNOS relies on predefined addresses or address books which contain entries for either IP prefixes or FQDNs. Multiple addresses can be grouped together into an address-set to simplify policy creation for a group of address or prefixes.

JUNOS security policies are different from firewall filters in that security policies are stateful and applied to security zones, while firewall filters are stateless and applied directly to interfaces. Now let’s get to it. The first thing we have to do is setup our security zones. A security zone is configured with 3 main components, the address-book, the interfaces, and host-inbound-traffic rules. The first two are pretty self-explanatory; host-inbound-traffic rules are configured to secure traffic originating from connected hosts within a zone. In other words, host-inbound-traffic rules are used to protect a zone from internal attacks. See here for more information on configuring host-inbound-traffic.

Here is an example config for a trust and untrust zone:

set security zones security-zone trust address-book address mail01 dns-name mail01srv.domain.com
set security zones security-zone trust address-book address mail02 dns-name mail02srv.domain.com
set security zones security-zone trust address-book address-set mail_servers address mail01
set security zones security-zone trust address-book address-set mail_servers address mail02
set security zones security-zone trust host-inbound-traffic system-services all
set security zones security-zone trust host-inbound-traffic protocols all
set security zones security-zone trust interfaces ge-0/0/0
set security zones security-zone trust interfaces lo0.0

set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust host-inbound-traffic system-services traceroute
set security zones security-zone untrust interfaces ge-0/0/1

Now that we have our two zones configured, they are by default policy not permitted to pass any traffic. So we must configure policies to allow traffic to flow between the zones. Security policies work much like firewall filters in that they use a series of “match…then” statements which are applied to traffic in the order they are listed. A policy ‘match’ statement must specify a source-address, a destination-address, and an application. These specifications can be address-sets and application-sets respectively. A policy ‘then’ statement can contain either:

  • Permit – Allows traffic to pass
  • Deny – Denies traffic to pass by *silently* dropping the packet
  • Reject – Denies traffic to pass by dropping the packet, but also sends an ICMP Port Unreachable reply for every dropped packet
  • Log – An option to enable logging of the sessions, requires the creation of a logfile via “set system syslog file <file-name> <options> “
  • Count – An option to enable counting (in bytes or kilobytes) of all traffic permitted by the policy

Here is an example of a few policies which will first allow SMTP traffic from my mail servers, then block SMTP from any host, and finally all any traffic:

set security policies from-zone trust to-zone untrust policy allow-smtp match source-address mail_servers
set security policies from-zone trust to-zone untrust policy allow-smtp match destination-address any
set security policies from-zone trust to-zone untrust policy allow-smtp match application junos-smtp
set security policies from-zone trust to-zone untrust policy allow-smtp then permit

set security policies from-zone trust to-zone untrust policy block-smtp match source-address any
set security policies from-zone trust to-zone untrust policy block-smtp match destination-address any
set security policies from-zone trust to-zone untrust policy block-smtp match application junos-smtp
set security policies from-zone trust to-zone untrust policy block-smtp then deny
set security policies from-zone trust to-zone untrust policy block-smtp then log session-init session-close

set security policies from-zone trust to-zone untrust policy internet-allow match source-address any
set security policies from-zone trust to-zone untrust policy internet-allow match destination-address any
set security policies from-zone trust to-zone untrust policy internet-allow match application any
set security policies from-zone trust to-zone untrust policy internet-allow then permit

It is important to take note of the policy ordering. Security policies are applied in order. If my internet-allow policy were at the top of the list, it would make my SMTP filtering policies useless. I could fix this easily this with the command:

insert policy <name>  {before/after} policy <name>

That gives you the basic run-down to configure security policies in JUNOS. I would recommend reading the documentation when it comes planning time so that you can properly configure the correct features for your requirements.