Tag Archives: JUNOS

Juniper Junos Idle Timeout

1 Reply

Juniper SRX 210I recently noticed that Junos doesn’t set an idle timeout on CLI sessions for newly created user/administrator logins. It doesn’t set an idle timeout (by default) on the default root account either. While this wouldn’t be that much of a concern for most we place analog modems on the console ports of all our remote office Juniper SRX 210Hs. If an engineer or administrator forgets to logout of the console before hanging up with the modem we could have a big security problem. Someone could stumble across our device (by war dialing or accidentally) and they would find themselves logged into a Juniper SRX 210H with full administrator privileges.

Thankfully you can configure an idle timeout for CLI sessions in Junos.

We don’t use the default root account but instead create an admin account for the day to day management and configuration changes. Here are the steps we use to create that admin account;

set system login user admin full-name Administrator
set system login user admin uid 100
set system login user admin class super-user
set system login user admin authentication plain-text-password password

That leaves us with the following configuration;

user admin {
    full-name Administrator;
    uid 100;
    class super-user;
    authentication {
        encrypted-password "*****************************"; ## SECRET-DATA
    }
}

Since the idle-timeout value is set per user class and we can’t modify the default super-user class we had to create a new class called super-user-local. After setting the idle-timeout and permissions we add the user admin to that user class.

set system login class super-user-local idle-timeout 10
set system login class super-user-local super-user-local permissions all
set system login user admin class super-user-local

If we look at the configuration after those changes we should be able to see the new user class.

class super-user-local {
    idle-timeout 10;
    permissions all;
}
user admin {
    full-name Administrator;
    uid 100;
    class super-user-local;
    authentication {
        encrypted-password "********************************"; ## SECRET-DATA
    }
}

And now lets test it…

[root@linux ~]# telnet vpn-testlab
Trying 10.101.203.1...
Connected to vpn-testlab (10.1.1.1).
Escape character is '^]'.

vpn-testlab (ttyp0)

login: admin
Password:

--- JUNOS 10.4R9.2 built 2012-02-02 08:09:42 UTC
admin@vpn-testlab> 

Warning: session will be closed in 5 minutes if there is no activity
Warning: session will be closed in 1 minute if there is no activity
Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session

Connection closed by foreign host.

With that change any CLI sessions that are idle for 10 minutes will be automatically logged out.

I mentioned creating a few screencasts so here’s my first “public” attempt. I’ve created a few private screencasts for my employer from time to time but nothing ever public. Have a look below, feel free to leave any feedback even constructive criticism is welcome. I know that I need to work on my microphone volume and settup. I don’t smoke but you’d never know that by listening to the video with my heaving breathing. Any if you decide to watch why not have a go at counting the number of uhms or ahs?

Cheers!

Juniper Networks

4 Replies

Juniper NetworksI traveled to Juniper‘s offices in San Jose, CA on Friday afternoon October 12, 2012 for Networking Field Day 4. We met with Derick Winkworth and a number of Juniper product managers and specialists.

I actually have some experience with Juniper and JunOS. I currently employ a clustered pair of Juniper Secure Access 4000 appliances for clientless and SSL-VPN based remote access. I’m also in the process of migrating to the Juniper SRX for our branch office VPN connections utilizing Juniper SRX 650s in the main office and Juniper SRX 210Hs in the branch office. I’m a big fan of the Juniper Secure Access product and the Network Connect client. Our recent deployment of the Juniper SRX product is been going quite well. We’re deploying virtual routing instances (VRFs) within JunOS so we can tunnel all Internet traffic from the branch back to the main office for content filtering and logging.

I’m going to outline the different presentations that we heard and perhaps make a few points here and there if I have anything useful to say. I’ll include a short blurb from Juniper in italics to help define/describe each product or solution. Thankfully since the sessions were recorded you can watch for yourself and make your own informed opinion.

Here’s my disclaimer; I’m not endorsing any of the solutions presented below. I’m merely passing on the information along with a few comments of my own. If you have any personal opinions about the solutions below why not share them with us in the comments?

Introduction

by Derick Winkworth (Networking Field Day 3 Delegate)
Tech Field Day Video

I only learned on my flight back to Philadelphia, PA that Derick was a Networking Field Day 3 delegate although once I did that explained a few things.

Storage Networking and FCoE in the Network

by Simon Gordon and Joe White
Tech Field Day Video

Juniper attempted to demonstrate the Juniper QFX3500 switch with a Windows and Linux server using the converged Intel X520-SR2 network adapter connected to a prototype storage array nicknamed ‘platypus’. Unfortunately ‘platypus’ wasn’t behaving that day and Juniper was unable to present the demo.

Edit: Updated 11/1/2012 – as pointed out by Simon it was the prototype storage array that mis-behaved and not the QFX3500.

My Thoughts?

I’m not expert, not even a novice when it comes to understanding the subject of FCoE. I believe there’s definitely value to be found in a converged FC SAN and NIC adapter. What do you do with your SAN traffic once it gets to the FCoE switch seems to be the question.

I have a question? What exactly is a latency bubble? It sounds like bullshit bingo to me but you never know it might be real.

Douglas Fourlay over at Network World is wondering Why FCoE is Dead, But Not Buried Yet. The article is dated but makes some interesting points.

Virtual Chassis Technology

by Yafan An
Tech Field Day Video

Juniper Networks Virtual Chassis technology is a feature of the Juniper Networks EX4200 line of Ethernet switches allowing the interconnection and operation of switches as a unified, single, high bandwidth device. Up to 10 EX4200 switches may be interconnected via dedicated Virtual Chassis ports on each device, or through optional uplink module ports that are configured as Virtual Chassis ports, with a combined backplane bandwidth of up to 128 Gbps.

Virtual Chassis Technology – stacking in closet or top of rack with 4 different models, EX3300 – 1Gbps Fixed Switch (stack up to 6), EX4200 – 1Gbps Fixed Switch (up to 10), EX4500 – 10Gbps Switch (up to ?), EX8200 – Modular Chassis Core Switch. EX8200s can be supplemented by external XRE (eXternal Routing Engines) all managed as a single switch, single IP address utilizing JunOS. The EX8200 can be stacked up to 40kM apart in a virtual chassis.

My Thoughts?

Initially it appeared to be just another stacking solution for closet/edge switches. Although then I realized that you can actually stack the modular EX8200 chassis which sounds similar to some other vendor solutions.

MyKonos – Web Application Security

Tech Field Day Video

Mykonos Software’s web Intrusion Deception™ system effectively eliminates false positives because it employs tar traps to detectttacks with certainty. The software inserts detection points into web application code including urls, forms and server files to create a variable minefield. These traps detect hackers when they manipulate the deception points during the reconnaissance phase of the attack, before they can establish an attack vector. And because hackers are manipulating code that has nothing to do with the website or web application, the malicious action is certain.

My Thoughts?

If you were watching the live stream you probably saw me prop up in my chair. This was a devilishly clever approach to the problem of application hacking and how to thwart the majority of such attempts. I’ve run a number of honeypots over the years but this was really a better mouse trap than anything I’ve ever seen. The MyKonos solution essentially acts as a reverse proxy server that front ends your Internet facing application web servers and injects small pieces of cheese into the HTML to see if anyone will bite. Once someone/something reacts to the pieces of cheese the solution will start tracking the user/host and will attempt to continue deceiving the ‘hacker’ by offering them additional tidbits of information to keep them interested. The ultimate goal of the solution is to keep the rogue users interested by wasting their time (and money) while building a profile of the attacker. Ultimately MyKonos can integrate with third party firewalls to block the IP address of an intruder once they’ve reached the end of the rainbow.

The delegates discussed for a few minutes the legality of placing cookies in a user’s web browser but it seems that Juniper has already addressed the majority of those concerns in a knowledge base article KB25858.

JunOS Automation

by Dan Beckman and Dereck Winkworth
Tech Field Day Video

JunOS 12.2 added the ability to add Curl calls from scripting which enables you to centralize your code snippets.

Junos Automation Technology Overview Presentation
Juniper Script Library

SLAX – SLAX is a syntax overlay of the XSLT programming language. While XSLT is used internally by Junos to power its on-box scripting capabilities, it is not the most intuitive or efficient of languages, so SLAX was created to simplify on-box script programming and make it more comfortable to write. SLAX Reference

JUISE – JUISE takes the abilities provided by the scripting facility of JUNOS and moves it into the open source world, where a script can run on a remote box, accessing JUNOS resources over the NETCONF (or JUNOScript) API. Initially this will be an excellent environment for creating and debugging scripts, but for many users, it may become their “normal” scripting environment.

My Thoughts?

I was able to relate with Dereck as he used phrases like “mountain of automation workflow”, “stop the hurt” and “IT is hard”. I’m a believer in letting the computer do the work and where ever possible and reducing the duplication of effort (eliminate the paperwork). You only need to look at my scripts library and see that I’ve written my share of code using Expect and Perl to automate various tasks and push functionality out to the help desk and support personnel. I just recently coded a Perl application to interface with Infoblox to support personnel could quickly and easily update the DHCP MAC address list which is used to filter DHCP requests (poor mans NAC). The goal was to allow help desk and field engineers to make updates to Infoblox without requiring them to log into the Infoblox appliance. I had to code all sorts of data validation routines within JavaScript to make it as bullet proof as possible.  I took the same Perl application and allowed Symantec’s Altiris to make CGI calls to it while provisioning desktops and laptops thereby completely automating the process of on-boarding new desktops and laptops into the network.

Now that I have 2 Juniper SRX 650s and 31 Juniper SRX 210H to manage I’ll be definitely be looking into what I can do to help automate the management of these devices and JUISE will probably be the first component I look at in my quest to make “IT easier”.

Closing

Let me say thanks to Derrick and the entire Juniper team. The presentations were very informative and educational.

Cheers!

Juniper SRX VPN Branch Office

7 Replies

Juniper SRX 210We recently started replacing our aging Avaya VPN Routers (formerly Nortel Contivity) with Juniper SRX series gateways. We chose a Juniper SRX 650 to replace our Avaya VPN Router 1750 and we chose the Juniper SRX 210H to replace the Avaya VPN Router 1010 and 1050 models. While it was fairly easy to get both route based tunnels and policy based tunnels setup we had an interesting time trying to route all traffic at the branch back to the main office (as opposed to routing it directly to the Internet on the branch Juniper SRX 210H) so it could be policed by our corporate firewalls and content filtering solutions. We were able to accomplish this configuration through the use of VRFs and I’m going to outline how we did it (just in case anyone else is trying to follow in our footsteps – or better yet can improve the configuration).

Configure the Juniper SRX 210 Branch Office

Login to the serial console of the Juniper SRX gateway with the username of “root” (password should be blank). We’ll start the configuration by loading the factory defaults and then setting up some basic system information. We’ll add a user called “admin” for future use.

root@% cli
root> configure
Entering configuration mode
[edit]
load factory-default
set system host-name vpn-srx210h-gw
set system domain-name vpn.acme.org
set system time-zone America/New_York
set system root-authentication plain-text-password
set system login user admin full-name Administrator
set system login user admin uid 100
set system login user admin class super-user
set system login user admin authentication plain-text-password

Lets set the SNMP information including a reference to the routing-instance “centralized-internet”. This will allow us to perform SNMP polls against this VRF from the specific IP management workstations we’ve listed below.

set snmp description "Juniper SRX 210H"
set snmp location "Local Branch Office (Somewhere, USA)"
set snmp contact "Technology Team"
set snmp community readonlystring authorization read-only
set snmp community readonlystring routing-instance centralized-internet clients 10.1.20.50/32
set snmp community readonlystring routing-instance centralized-internet clients 10.2.20.50/32
set snmp community readwritestring authorization read-write
set snmp routing-instance-access
commit

Let’s start by configuring the WAN (public) and LAN (private) IP addresses. The interface ge-0/0 is the public interface which will connect to the Internet Service Provider. The interface vlan.0 is the private interface which is made up of physical interfaces ge-0/1 – ge0/7. We’ll also delete the factory default address of 192.168.1.1.

set interface ge0/0/0 unit 0 family inet address 1.51.88.10/30
set routing-options static route 0.0.0.0/0 next-hop 1.51.88.9
set interface vlan unit 0 family inet address 10.1.200.1/24
delete interfaces vlan unit 0 family inet address 192.168.1.1/24

Let’s enable the web management GUI on the public interface and set the TCP port to 10443 as opposed to the default of 443.

set system services web-management https interface ge-0/0/0.0
set system services web-management https port 10443

Let’s enable the system services we want to allow in the untrust zone.

set security zones security-zone untrust host-inbound-traffic system-services ike
set security zones security-zone untrust host-inbound-traffic system-services ping
set security zones security-zone untrust host-inbound-traffic system-services https

Let’s repeat those commands for the specific public interface.

set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services ike
set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services ping
set security zones security-zone untrust interface ge-0/0/0 host-inbound-traffic system-services https

Let’s build the VPN tunnel interfaces to Juniper SRX 650. We’ll need to assign IP addresses to these interfaces since we’re setting up a Point to MultiPoint network with route based VPN tunnels.

set interfaces st0 unit 0 family inet address 10.1.255.120/24
set interfaces st0 unit 0 family inet mtu 1500

Let’s finish up setting up the security zones and adding the VPN interfaces.

set security zones security-zone vpn interfaces st0.0
set security zones security-zone untrust interfaces ge-0/0/0.0
set security zones security-zone trust interfaces vlan.0
set security zones security-zone trust host-inbound-traffic system-services all

Let’s not forget to allow the remote management via the web interface. (added 10/18/2011)

set security zones security-zone vpn host-inbound-traffic system-services all
set security zones security-zone vpn host-inbound-traffic protocols all
set system services web-management http interface st0.0

Let’s setup the IKE policies and pre-shared-key for both VPN tunnels, please make sure to replace the preshared-key and IP addressing below with the values that’s specific to your installation (not the example one). I use the acronym PDC to stand for Primary Data Center since we have both a primary and alternate/standby.

set security ike policy PDC-IKE mode main
set security ike policy PDC-IKE proposal-set standard
set security ike policy PDC-IKE pre-shared-key ascii-text "c3DrmFiRei37NpW65GnygdOorykE0ZjnpyX"
set security ike gateway PDC-GW ike-policy PDC-IKE
set security ike gateway PDC-GW address 2.1.1.25
set security ike gateway PDC-GW external-interface ge-0/0/0.0

set security ipsec policy ACME-VPN proposal-set standard
set security ipsec policy ACME-VPN perfect-forward-secrecy keys group2

set security ipsec vpn PDC-VPN ike gateway PDC-GW
set security ipsec vpn PDC-VPN ike ipsec-policy ACME-VPN
set security ipsec vpn PDC-VPN bind-interface st0.0
set security ipsec vpn PDC-VPN establish-tunnels immediately

The Juniper SRX still acts as a firewall so we need to create policies to allow the traffic to flow. I’ll set everything wide open for this example.

edit security policies from-zone trust to-zone vpn
set policy local-to-spokes match source-address any
set policy local-to-spokes match destination-address any
set policy local-to-spokes match application any
set policy local-to-spokes then permit
exit

edit security policies from-zone vpn to-zone trust
set policy local-to-spokes match source-address any
set policy local-to-spokes match destination-address any
set policy local-to-spokes match application any
set policy local-to-spokes then permit
exit

edit security policies from-zone vpn to-zone vpn
set policy local-to-spokes match source-address any
set policy local-to-spokes match destination-address any
set policy local-to-spokes match application any
set policy local-to-spokes then permit
exit

We’ll create a virtual routing instance setting the next-hop to interface st0.0

set routing-options interface-routes rib-group inet centralized
set routing-options rib-groups centralized import-rib inet.0
set routing-options rib-groups centralized import-rib centralized-internet.inet.0

We’ll create a virtual routing instance setting the next-hop to interface st0.0

set routing-instances centralized-internet instance-type virtual-router
set routing-instances centralized-internet interface st0.0
set routing-instances centralized-internet routing-options static route 0.0.0.0/0 next-hop st0.0

This filter will direct all traffic to the centralized-internet routing table. The first term allows us to add an exception although it’s not used today but can be for testing and troubleshooting by changing the IP address to a valid LAN client IP address. This filter allows traffic from 10.1.200.254 to be routed based on the default routing-instance which would send it directly out to the Internet as opposed to routing it over the VPN tunnel back to the main office.

set firewall filter centralized-internet-filter term 1 from destination-address 10.1.200.254/32
set firewall filter centralized-internet-filter term 1 then accept
set firewall filter centralized-internet-filter term 2 then routing-instance centralized-internet

We’ll apply the filter we created above to traffic ingressing the interface vlan.0.

set interface vlan unit 0 family inet filter input centralized-internet-filter

Let’s configure a DHCP relay instance to forward DHCP requests to a centralized server (10.1.1.40).

set forwarding-options helpers bootp relay-agent-option
set forwarding-options helpers bootp description "Branch DHCP Relay"
set forwarding-options helpers bootp server 10.1.1.40 routing-instance centralized-internet
set forwarding-options helpers bootp vpn
set forwarding-options helpers bootp interface vlan.0

Let’s configure the TCP-MSS value so we don’t have any MTU issues tunneling over IPSec

set security flow tcp-mss ipsec-vpn mss 1350

Let’s configure the debug options so we can troubleshoot any IKE/IPSEC issues.

set security ike traceoptions file size 1m
set security ike traceoptions flag policy-manager
set security ike traceoptions flag ike
set security ike traceoptions flag routing-socket

We need to disable IDP to prevent unwanted error messages from filling the log.

set system processes idp-policy disable

Now we need to commit and save all the changes we’ve made above.

commit

If you have issues committing the changes with errors such as :

root# commit
[edit system]
'autoinstallation'
incompatible with 'forwarding-options helpers bootp'
[edit forwarding-options helpers]
'bootp'
incompatible with 'system autoinstallation'
error: commit failed: (statements constraint check failed)

Just issue the following command and re-issue the commit

root# delete system autoinstallation

If you are connected to the public Internet you can sync the date/time via NTP over the public interface.

root# set date ntp 173.9.142.98

Configure the Juniper SRX 650 Main Office

Now we need to configure the Juniper SRX 650 which is the main office side of the tunnel.

Let’s create an IKE policy for this specific connection. Please remember to substitute the preshared-key and IP addresses I use in the example below.

set security ike policy TESTLAB-IKE mode main
set security ike policy TESTLAB-IKE proposal-set standard
set security ike policy TESTLAB-IKE pre-shared-key ascii-text "c3DrmFiRei37NpW65GnygdOorykE0ZjnpyX"

Let’s create a gateway and tie it together with our IKE policy. Let’s set the public IP address of the branch office VPN site.

set security ike gateway TESTLAB-GW ike-policy TESTLAB-IKE
set security ike gateway TESTLAB-GW address 1.51.88.10
set security ike gateway TESTLAB-GW external-interface ge-0/0/0.0

Let’s create a VPN policy and tie all the policies together binding it to st0.10 which is a multipoint interface on the main office side.

set security ipsec vpn TESTLAB-VPN ike gateway TESTLAB-GW
set security ipsec vpn TESTLAB-VPN ike ipsec-policy ACME-VPN
set security ipsec vpn TESTLAB-VPN bind-interface st0.10
set security ipsec vpn TESTLAB-VPN establish-tunnels immediately

Since we’re not yet doing OSPF we need to create a static route in the appropriate routing instance.

set routing-instances routing-table-lan routing-options static route 10.1.200.1/24 next-hop 10.1.220.10

I’m omitting a few steps on the Juniper SRX 650 to implement the Multipoint VPN feature but it’s well documented (as most of this is) in the Juniper documentation.

References;

 

Cheers!