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

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!)

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

3.) Convert your harddisks:

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

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”:

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:

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? 😉