Posts filed under Junos

Juniper vSRX Firewall and VMWare Workstation 14

For a work related project, I wanted to run the Juniper vSRX firewall (v15.1X49-D110) on my work laptop by using VMWare Workstation Pro 14. Unfortunately, the installation (importing the Juniper vSRX OVA file resulted in a VMWare Workstation crash.

Juniper SRX and DHCP Client Challenge

A couple of years ago I wrote a post about a dual ISP config with a Juniper SRX firewall. At the time I ran into some challenges regarding the DHCP client functionality of the SRX. For some reason it couldn't get a lease from the Ziggo ISP DHCP servers. Any other DHCP server on my local network worked just fine. Since I created a work-around at the time (by using an additional NAT router and static IP addresses) I didn't give it much thought.... Until last week.

Last week I ran into a networking challenge that kinda freaked me out. For some reason my Apple TV wouldn't connect to my NAS, but it could connect to the Internet. For some reason my Apple TV got a public IP address while it was located on my internal network. The public IP address was completely unknown to me. So, WTF was giving my Apple TV a public IP address?

Posted on February 13, 2017 and filed under Internet, Security, Tips'n Tricks, Junos.

Run Juniper Virtual SRX in VMWare Workstation

The Juniper Virtual SRX firewall can run on multiple platforms, but VMware Workstation is not mentioned in the list of supported platforms. Having some experience with both, I know that almost all VM's designed for the VMware ESXi environment will run on the (stand-alone) VMware Workstation product.

I downloaded the .ova file from the Juniper website and imported it in VMware Workstation v12.1. During the import I adjusted the number of CPU's to save resources, which turned out to be a mistake. The VM really needs the two CPU's, because if you don't it just won't work (routing failures, etc..). So, don't change the defaults for CPU and memory.

Posted on January 12, 2016 and filed under Junos, Security, Tips'n Tricks.

Juniper SRX210 Sudden Back-To-Factory Defaults

Earlier this week I configured an Juniper SRX210 for testing. The configuration consisted of several security zones, IDP, UAC (layer3 enforcement) and Application Firewall and Identification. The Junos version I used was JUNOS 12.1X46-D15.3.

This setup worked until today. Today, the SRX was unresponsive. No ICMP reply, no SSH access, nothing. Accessing the SRX via the serial console showed me the Amnesiac login. This means that the configuration is gone. At least the configuration I created was reset to the factory defaults config. A typical WTF!!! moment.

Fortunately, I had configured logging to an external source (Splunk). So I went to investigate. Turned out that the SRX stopped sending syslog messages around 01:30PM. Further investigation showed that the config was actually reset (UI_FACTORY_OPERATION event), and checking the event-codes, it was (probably) done by pressing the reset button on the device.

(the following logging should be read bottom-top)

May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.808+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="finished copying juniper.db to juniper.data+"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.369+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="copying juniper.db to juniper.data+"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.369+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="finished loading commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.368+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="no transient commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.368+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="no commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.367+02:00 srx210 mgd 6211 UI_COMMIT_PROGRESS [junos@2636.1.1.1.2.36 message="start loading commit script changes"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.133+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:28:30 10.0.0.1 1 2014-05-28T13:28:30.355+02:00 srx210 mgd 6211 - - auto-snapshot is not configured
May 28 13:28:28 10.0.0.1 1 2014-05-28T13:28:28.814+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//srx210h-defaults.conf"]
May 28 13:28:27 10.0.0.1 1 2014-05-28T13:28:27.823+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//jsrxsme-series-defaults.conf"]  
May 28 13:28:27 10.0.0.1 1 2014-05-28T13:28:27.217+02:00 srx210 mgd 6211 UI_LOAD_JUNOS_DEFAULT_FILE_EVENT [junos@2636.1.1.1.2.36 pathname="/etc/config//junos-defaults.conf"]   
May 28 13:28:26 10.0.0.1 1 2014-05-28T13:28:26.808+02:00 srx210 mgd 6211 - - WARNING: activating factory configuration
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:28:25.378+02:00 srx210 mgd 6211 - - WARNING: removing all configurations
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:28:25.232+02:00 srx210 mgd 6211 UI_FACTORY_OPERATION -
May 28 13:28:25 10.0.0.1 1 2014-05-28T13:27:35.000+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:27:19 10.0.0.1 1 2014-05-28T13:26:39.941+02:00 srx210 - - - - last message repeated 11 times
May 28 13:17:19 10.0.0.1 1 2014-05-28T13:16:34.309+02:00 srx210 - - - - last message repeated 11 times
May 28 13:07:19 10.0.0.1 1 2014-05-28T13:06:28.346+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:05:33 10.0.0.1 1 2014-05-28T13:05:33.297+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:04:38 10.0.0.1 1 2014-05-28T13:04:38.248+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]
May 28 13:04:19 10.0.0.1 1 2014-05-28T13:04:19.548+02:00 srx210 utmd 1380 AV_PATTERN_UPDATED [junos@2636.1.1.1.2.36 version="05/28/2014 12:36 GMT, virus records: 522178" file-size="18635751"]
May 28 13:03:42 10.0.0.1 1 2014-05-28T13:03:42.934+02:00 srx210 rmopd 1350 PING_TEST_COMPLETED [junos@2636.1.1.1.2.36 test-owner="XS4ALL" test-name="testsvr"]

This is strange, since there was no one around at the time. So it must have been some sort of bug that caused this.

Thankfully I had a backup of the config, so the device was up and running again within 10 minutes. So now I have to keep an out out for this. Especially the next couple of days.

UPDATE: There's is definitely something wrong with the hardware. I tried different Junos versions (also stable recommended versions), and different configs, but for some reason the device detect a 'Config button pressed' event and goes back to the default factory config. This happens within 12 hours.

The device keeps going back to the factory default config. Today I changed the behavior of the reset button. The reset button doesn't react to physical interactions when adding the following line to the config:

root@srx210# set chassis config-button no-clear no-rescue

Let's see if that helps. If it does, it means that the hardware reset button (mechanism) is malfunctioning.

UPDATE 2: looks like the config button config did the trick (so far). The device is still up-and-running for nearly 24 hours. -keepingfingerscrossed-

UPDATE 3: and we have a winner. The SRX210 is still operational. Just need to remember to add the command when I reconfigure it. Perhaps a sticker on top as a visual reminder :-)

Posted on May 28, 2014 and filed under Annoying, Junos, Security.

Use Cisco ISE for RADIUS Authentication with Juniper Junos Devices

While preparing for some Juniper exams, I wanted to test RADIUS authentication for Junos device access. This way of authenticating is helpful in larger networks. Instead of providing all the devices with several usernames and passwords you can use a centralized RADIUS server for authenticating on all those devices. If that RADIUS server uses the Active Directory as a user database you can login on your network devices using your regular username and password.

The RADIUS server of choice (at the moment of writing this) is Cisco Identity Service Engine (ISE). Overkill for this specific blog post, but fun to do.

Posted on January 22, 2014 and filed under Junos, Security, Tips'n Tricks.

Using EX Firewall Filters With UAC

Network Access Control (NAC) is hot in Enterprise environments. NAC offers an excellent mechanism to (safely) allow various devices network connectivity and staying in control as a network administrator. There are numerous ways to allow iOS devices, BYOD, CYOD, Corporate laptops onto your network without compromising valuable corporate resources.

In my line of work I deal with several vendors / solutions to create these NAC protected environments. The most popular at the moment are;

  • Identity Service Engine (ISE) from Cisco
  • Junos Pulse Access Control (UAC) Service from Juniper

Both solutions have their pro's and cons. Juniper has an excellent client for the desktop to safely connect to the network, and an integration with their SRX firewalls to (dynamically) enforce firewall policies on a per user basis. Cisco on the other hand has a more flexible way of creating access policies, and the use of so-called downloadable Access Lists (dACL). 

Posted on December 20, 2013 and filed under Junos, Security, Tips'n Tricks.

Juniper SRX IDP Attack Log Investigation

Last week I fiddled with the IDP functionality on my SRX100H. I eventually installed a modified version of the so-called "Recommended" IDP policy. The full Recommended policy consumes to much memory on the SRX100H, so I had to remove some rules.

After installing the IDP policy I 'configured' Splunk to run reports on IDP Attack Events (IDP Attacks in the last 24 hours). This way I have a nice overview of the detected attacks.

Today I checked the logging, and to my surprise I found several IDP_ATTACK_LOG_EVENT entries in the log. This triggered my curiosity a bit.

Thankfully I use an NTP server for syncing all the devices around the house, so working backward shouldn't be too hard. 

The IDP event was triggered by my iMac which had the 192.168.1.109 IP address at the time (hurray for DHCP logging). The reported exploit (HTTP:XSS:HTML-SCRIPT-IN-URL-VAR) is basically website related, so I started to dig through the browser history. Turned out that I visited the Victorinox website at the time looking for winter coats. During my visit at the website I tried to find a local store where they sell these items, but for some reason the 'Store Locator' thingy on the website didn't work. Now the logging explained why it didn't work.

It looks like they use a map-service (hosted on the destination address 199.16.46.10) in combination with some cross-site-scripting to deliver the functionality.

I tested this again, and indeed, every time I go to that website and try to locate a store, the same IDP_ATTACK_LOG_EVENT occurs.

In this case the cross-site-scripting (XSS) is relatively harmless. The use it to display a map with possible stores based on your query. Unfortunately, there are numerous other scenario's where this (XSS) isn't harmless. 

Posted on November 11, 2013 and filed under Junos, Security.

Quick And Dirty Juniper SRX IDP Test Config

When implementing a SRX IDP (Intrusion Detection and Prevention) configuration, you may want to check if everything is working properly. The 'default' templates supplied by Juniper can't be tested easily, since they protect your network from very specific attacks. Chances are small that you'll see one while you're testing. 

I usually use a simple ICMP-TEST policy which will drop all ICMP traffic, and logs the event to a local file (for basic testing, but you'll want to forward these events to a syslog server).

IDP Config: 

set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match from-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match source-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match to-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match destination-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match application default
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REPLY
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REQUEST
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then action drop-packet
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then notification log-attacks alert
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then severity critical
set security idp active-policy ICMP-TEST

Add the IDP to the appropriate firewall rules and verify that your ICMP (ping) packets are being dropped.

Firewall rule example: 

set security policies from-zone trust to-zone untrust policy trust-to-untrust then permit application-services idp

If your ICMP packets aren't being dropped while 'pinging' to Google DNS (8.8.8.8), you dit something wrong :-)

Verification of IDP functionality in Splunk

Posted on November 1, 2013 and filed under Junos, Security, Tips'n Tricks.

Junos Dual ISP Backup Route Configuration

The last couple of years, we've had two ISP's on premise. One (XS4ALL) for basic Internet Access via VDSL, and one our (VoIP) phone provided by Ziggo. The Ziggo phone services includes free (and ultra lite) Internet access through the use of their cable modem. It's ultra-lite, since it's only 256kbps. More than enough for VoIP, but not nearly enough for modern basic Internet access.

Having these two ISP's means that I should be able to provide some redundancy in case my primary DSL connection fails (for whatever reason). Preferably an automated fail-over of some kind.  Since there are no dynamic protocols available from either ISP (the Internet service is consumer-grade), I have to find some work-around.
Posted on August 16, 2013 and filed under Security, Tips'n Tricks, Junos.