OSPF between a vSRX-Cluster and a standalone vSRX over vQFX on EVE-NG

I promised to deliver this and here it is: OSPF over vQFX 😉
These days I lab a lot with EVE and I love it more every day – the possibilities are endless and the Labs are very very quick configured and running. With 2 new CPU’s my EVE now runs with decent Speed so compared to VMware ESX 6.0 there is no extreme performance difference anymore. I can live with that. Since D63 on the vQFX is running very stable and smooth I thought of this small OSPF Lab – I will add more “Quick-Labs” in the Future.

WARNING:
The SRX in Clustermode runs very well on EVE – however there is an optical error. If you build a Cluster, the interface mappings on EVE are completely wrong. This is due to the SRX getting a new interface (em0) as second interface Card – so if you select ge-0/0/0 in EVE, you really select em0.

But why is that you will ask? The answer is simple:
EVE is not aware of Cluster-Naming or Cluster Interfaces – so you have to think twice, what you have to select – I needed Wireshark to see what happened…
From top down the first Interface in EVE is fxp0, the second Interface is em0, the third is ge-0/0/0 or 7/0/0, the fourth is ge-0/0/1 or 7/0/1 and so on (see the Table below from Juniper):

Once I figured that out I could successfully build the Cluster (this time fully working, not just partially) and here is the Lab:

Topology:

 

vSRX-NG5+6 (the SRX-Cluster):

set version 15.1X49-D90.7
set groups node0 system host-name vSRX-NG5
set groups node1 system host-name vSRX-NG6
set apply-groups "${node}"
set system root-authentication encrypted-password "$5$i6krJW/Y$G.KrWGkf3RPukhgAVNOJDY0pdCtCd0TTAOKT3/5/4A3"
set system syslog user * any emergency
set system syslog file messages any any
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system license autoupdate url https://ae1.juniper.net/junos/key_retrieval
set chassis cluster control-link-recovery
set chassis cluster reth-count 2
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set security zones security-zone internal host-inbound-traffic system-services all
set security zones security-zone internal host-inbound-traffic protocols all
set security zones security-zone internal interfaces reth0.0
set interfaces ge-0/0/5 gigether-options redundant-parent reth0
set interfaces ge-7/0/5 gigether-options redundant-parent reth0
set interfaces fab0 fabric-options member-interfaces ge-0/0/0
set interfaces fab1 fabric-options member-interfaces ge-7/0/0
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 unit 0 family inet address 10.10.10.2/24
set protocols ospf area 0.0.0.0 interface reth0.0
set protocols lldp interface all

 

 

vSRX-NG7 (the standalone SRX):

set version 15.1X49-D90.7
set system host-name vSRX-NG7
set system root-authentication encrypted-password "$5$6X6aODJh$tmTDU.0wKBkuF0tTDeOJQkaHGVUeVXY8RWJMY9BLpDD"
set security zones security-zone internal host-inbound-traffic system-services all
set security zones security-zone internal host-inbound-traffic protocols all
set security zones security-zone internal interfaces ge-0/0/1.0
set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.1/24
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
set protocols lldp interface ge-0/0/1

 

 

Lab-C01 (Coreswitch 01, vQFX running 15.1X53-D63.9):

set version 15.1X53-D63.9
set system host-name LAB-C01
set system root-authentication encrypted-password "$1$YBH6cP7S$QFmKOiVnTEpuot6QaEWYw."
set system services ssh root-login allow
set system services netconf ssh
set system services rest http port 8080
set system services rest enable-explorer
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system extensions providers juniper license-type juniper deployment-scope commercial
set system extensions providers chef license-type juniper deployment-scope commercial
set chassis aggregated-devices ethernet device-count 2
set interfaces xe-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/10 ether-options 802.3ad ae0
set interfaces xe-0/0/11 ether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members all
set interfaces em0 unit 0 family inet dhcp
set interfaces em1 unit 0 family inet address 169.254.0.2/24
set protocols lldp interface all
set protocols igmp-snooping vlan default
set vlans default vlan-id 1
set vlans vl-10 description OSPF-VLAN
set vlans vl-10 vlan-id 10

 

 

Lab-C02 (Coreswitch 02, vQFX running 15.1X53-D63.9):

set version 15.1X53-D63.9
set system host-name LAB-C02
set system root-authentication encrypted-password "$1$hy9eoMhU$T.tkfC86QC6LTdln/lYSW/"
set system services ssh root-login allow
set system services netconf ssh
set system services rest http port 8080
set system services rest enable-explorer
set system syslog user * any emergency
set system syslog file messages any notice
set system syslog file messages authorization info
set system syslog file interactive-commands interactive-commands any
set system extensions providers juniper license-type juniper deployment-scope commercial
set system extensions providers chef license-type juniper deployment-scope commercial
set chassis aggregated-devices ethernet device-count 2
set interfaces xe-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/0 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/1 unit 0 family ethernet-switching interface-mode access
set interfaces xe-0/0/1 unit 0 family ethernet-switching vlan members vl-10
set interfaces xe-0/0/10 ether-options 802.3ad ae0
set interfaces xe-0/0/11 ether-options 802.3ad ae0
set interfaces ae0 aggregated-ether-options minimum-links 1
set interfaces ae0 aggregated-ether-options lacp active
set interfaces ae0 aggregated-ether-options lacp periodic fast
set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk
set interfaces ae0 unit 0 family ethernet-switching vlan members all
set interfaces em0 unit 0 family inet dhcp
set interfaces em1 unit 0 family inet address 169.254.0.2/24
set protocols lldp interface all
set protocols igmp-snooping vlan default
set vlans default vlan-id 1
set vlans vl-10 description OSPF-VLAN
set vlans vl-10 vlan-id 10

 

Download this Lab for your EVE here: (Size 16kB, zip-Archive)
EVE-OSPF-vSRX-vQFX-Lab

Running vQFX 15.1X53-D63 on EVE (KVM)

The KVM version of the latest vQFX routing engine VM (vqfx10k-re-15_X53-D63) seems to be broken. If you try to run it, it will crash with a kernel9 panic and will never boot up completely.
However you can “cheat your way around this”:

1.) Simply download the Vagrant .box file of the D63 RE.
2.) Extract the .box File with 7zip – you will extract a file with no extension.
3.) Extract this file again and “magically” a file called packer-virtualbox-ovf-1491593710-disk001.vmdk will appear.
4.) Upload this to eve, convert it to hda.qcow2, fix permissions and run it – voila: D63 on EVE.

 

PFE is the same (no D63 Version available, since the PFE is not tied to a Software Version).

It’s always a good idea to dig around the provided Files from Juniper once something breaks 😉

Download the Files here: http://www.juniper.net/support/downloads/?p=vqfxeval#sw

EX2200-C and JunOS 15.1R6.7

Today I installed the 15.1R6.7 on my EX2200-C at home – this Release fixed one of the most annoying Bugs –> The Temp-Sensors are now “seen” again and the red-alert is gone.

root@OEK-EX2200C-01> show version 
fpc0:
--------------------------------------------------------------------------
Hostname: OEK-EX2200C-01
Model: ex2200-c-12p-2g
Junos: 15.1R6.7
JUNOS EX  Software Suite [15.1R6.7]
JUNOS FIPS mode utilities [15.1R6.7]
JUNOS Online Documentation [15.1R6.7]
JUNOS EX 2200 Software Suite [15.1R6.7]
JUNOS Web Management Platform Package [15.1R6.7]

{master:0}
root@OEK-EX2200C-01> show chassis environment 
Class Item                           Status     Measurement
Power FPC 0 Power Supply 0           OK        
Temp  FPC 0 GEPHY1                   OK         0 degrees C / 32 degrees F
      FPC 0 GEPHY2                   OK         50 degrees C / 122 degrees F
      FPC 0 GEPHY3                   OK         50 degrees C / 122 degrees F
      FPC 0 GEPHY4                   OK         50 degrees C / 122 degrees F

By setting GEPHY1 to 0 degrees C the Alarm has no intention to cry – and finally my Juniper-Rack is green again – thanks Juniper 🙂

root@OEK-EX2200C-01> show chassis alarms 
No alarms currently active

{master:0}
root@OEK-EX2200C-01> show system alarms 
No alarms currently active

In the next days I will lab some more with this release – I expect it to be “recommended” ASAP by Juniper because 99% of our Customers didn’t move from 12 to 15 due to this nasty optical bug. Of course there are also some problems with dot1x in 15.1R5 but that’s a different story 😉

ESX vs EVE-NG

      9 Comments on ESX vs EVE-NG

I got the opportunity to play with EVE-NG last week. Luckily this was running on a DL360G7 – just as my ESX 6.0 Server so I can compare both of them very well 🙂

Getting EVE-NG to run was pretty easy – I downloaded the “bare metal” iso, installed it on the Server and it was ready to go.
I installed a fresh ESX 6.0u3 on the other Lab-Server to make sure, that both of them are fresh installed.

I created 6 vSRX and 2 vMX – the vQFX was not part of this Setup.

 

First Test – boot-time:
ESX 6.0 took about 1 minute from the moment I pressed the power button to the login screen – pretty solid.
EVE-NG needed about 30 seconds – damn that thing was fast 🙂 Thanks to the Ubuntu 16.04 EVE-NG starts up very fast.

Second Test – boot the whole lab at once (powering up all 10 Machines):
ESX 6.0 took about 10 minutes until every VM was powered up and had the login prompt. All Devices were blazingly fast after booting.
EVE-NG took about 30 minutes until I could login to each VM – however the VM’s were practically useless, since the login itself took about 5mins. After 2 more hours all Devices reacted somehow fast – but slow compared to ESX. I searched the Forums but couldn’t find out why.

Third Test – the Resources:
ESX 6.0 needed around 40G of RAM and around 50% of all usable 16 CPU-Cores.
EVE-NG needed around 70G of RAM (don’t ask me why) and needed almost 100% of all CPU Cores.

Fourth Test – access:
ESX needs the Web-Client or the ESX-Windows-Client.
The Windows-Client is not installed on every PC – so “Lab-Everywhere” is not possible. The Web-Client is an Option.
EVE-NG comes with a HTML5 Web-Client – easy to access from everywhere – also EVE shows a Visio-like Lab-Topology with drag and drop – this is a huge plus compared to ESX.

All in all I will stick to the ESX-Server because of multiple reasons:
+ ESX itself runs very smooth and is well known by me (compared to KVM)
+ The Resources were way too much on the EVE-NG (I could run about twice as much Devices for the same resources)
+ ESX needs less time to power up the whole Lab. My Lab runs mostly on Fridays. So I power my Server down after labbing – I don’t like the idea of powering it up at Thursday evening just to waste my money (Power-Bill) to be able to lab on friday – that feels wrong…

Of course there are still ways to tweak both Hypervisors – a tweaked ESX runs all the Test-Devices at about 10% CPU – I can’t tell what a KVM will do.

Hopefully this gives you a small overview of both Systems

The itself not so secure JIPS-Course

Last week I attended the 2-days JIPS (Junos Intrusion Prevention Systems), which will soon be part of the shiny new 5-day AJSEC (hopefully way way way better)…

Anyways – currently this was an official Juniper course so for the preparation for my JNCIE-SEC I thought, that it might be wise to attend it in order to prepare myself for some IDS / IPS – baaaaaad mistake and wasted time…

I like to share the following picture with you:

Yes – we have 2017 – and yes, the official course includes:

Windows Server 2003 (at least someone patched it to SP2…)
Wireshark 1.0.8 (from – well – I honestly don’t even remember when this came out…)
CentOS 5.4 (from 2009!!!)
NSM2009.1 r1 (Jesus Crist I thought this was already buried 7 years ago…)
JunOS 12.1R2.9 (Well, I have seen 11.1 in the field, so…)

Guys – 2017 – for a freakin security course you should/could have done way better…
I suggest for the new course you should look for:

Windows Server 2016
Wireshark 2.2.6
CentOS 7.3
JunOS Space Security Director 16.2
JunOS 12.1X46-D65 or even better instead of SRX240-H (which is EoL by the way), use the new SRX340 with 15.1X49-D75 or the vSRX…

I am very disappointed and this was beyond a doubt the worst course I ever had to attend. Don’t get me wrong – the (old) AJSEC was great – very interesting stuff and somewhat usable for up-to-date SRXes. But the JIPS – even sitting inside the hotelroom and looking out of the window would have told me about security more than this. Now I will have to recreate myself some IDP-Patterns and hopefully the exam won’t have much to do with it.

If you want more Infos – well – you know how to reach me…

In my opinion this course should have been EoL in 2012 at latest or someone should have upgraded it properly to show new IDP techniques, patterns and maybe more about finding ransomware-patterns.

Of course I will not blackmail the Training-Partner – because he got the Lab straight from Juniper.

EVE-NG and the vQFX

      8 Comments on EVE-NG and the vQFX

Just wanted to give you a short update regarding my attempt to run the vQFX on the latest eve-ng.

Here is how I managed to run it:

1.) Connect to your eve-ng server via ssh and create 2 folders according to the eve-ng naming scheme (important or your vQFX will not be recognized!)

mkdir /opt/unetlab/addons/qemu/vqfxre-15d1X53
mkdir /opt/unetlab/addons/qemu/vqfxpfe-20160609-2

2.) Copy your vmdk-images to the eve-ng server via scp or sftp (I used /tmp as directory)

3.) Convert your harddisks:

/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 vqfx10k-pfe-20160609-2.vmdk /opt/unetlab/addons/qemu/vqfxpfe-20160609-2/hda.qcow2 
/opt/qemu/bin/qemu-img convert -f vmdk -O qcow2 vqfx10k-re-15.1X53-D60.vmdk /opt/unetlab/addons/qemu/vqfxre-15d1X53/hda.qcow2

4.) Run the script to fix your file-permissions:

/opt/unetlab/wrappers/unl_wrapper -a fixpermissions

5.) Go to your eve-ng webinterface and create 2 nodes inside your lab.
Leave the settings like CPU and RAM at the default.

6.) Enjoy your vQFX 10k on eve-ng 🙂

SRX ssh brute-force countermeasures

It’s always a good idea to secure and also harden your SRX in case it is reachable via the Internet.
Today I labbed a bit to see if this Filter actually works.

 

For this Lab we setup the “system login retry-options”:

set system login retry-options tries-before-disconnect 5
set system login retry-options backoff-threshold 3
set system login retry-options backoff-factor 10
set system login retry-options lockout-period 4

Now to the Options we have:

tries-before-disconnect: Sets the maximum number of times the user is allowed to enter a password to attempt to log in to the device through SSH or Telnet. When the user reaches the maximum number of failed login attempts, the user is locked out of the device.

backoff-threshold: Sets the threshold for the number of failed login attempts on the device before the user experiences a delay when attempting to reenter a password.

backoff-factor: Sets the length of delay in seconds after each failed login attempt. When a user incorrectly logs in to the device, the user must wait the configured amount of time before attempting to log in to the device again.

lockout period: Sets the amount of time in minutes before the user can attempt to log in to the device after being locked out due to the number of failed login attempts specified in the tries-before-disconnect statement.
You can read the full explanations here:
https://www.juniper.net/documentation/en_US/junos/topics/example/system-retry-options-configuring.html

 

 

After that (to see it more easy), we create a syslog-file for just the ssh failed attempts:

set system syslog file ssh-logs any any
set system syslog file ssh-logs match SSHD_LOGIN_FAILED
set system syslog file ssh-logs archive size 1m
set system syslog file ssh-logs archive files 10
set system syslog file ssh-logs structured-data

What this does is basically telling your SRX to log all failed ssh-attempts to a file called ssh-logs.

This way, your SRX is ready to take on almost every script-kiddie brute-force attack and logs every failed attempt.

Be sure to check the file from time to time – and remember: change your passwords from time to time and use at least 64 letters and numbers, hash-signs, virgin-blood and so on –> you get the idea right? 😉

 

vSRX on Hyper-V – I still prefer VMware…

Yesterday with the Release of the new vSRX (15.1X49-D80) I thought “why not give Hyper V a try?”.
I spinned up a Windows Server 2012 R2, installed Hyper-V and deployed the new vSRX.
In fact I was surprised – everything (including Cluster mode) seems to run decent – of course I know that this vSRX has only limited functionality under Hyper-V and can’t scale up very well.
However it was nice to see that the vSRX now runs on VMware, KVM and Hyper-V – what else do you want? 😉

Interface-Mapping can be found here:
Interface Mapping for vSRX in Hyper-V