Is your company ready for large-scale remote working?


I want to preface this article by saying that I don’t like “click-bait” or fear-mongering news titles. We live in a fairly safe and secure world, all things considered.

However, this sense of security shouldn’t become complacent. Unforeseen events can happen at any time. Fortunately, most of them, terrible as they may be (terrorist attacks, natural catastrophes, social unrest, …), are short-lived. Others, not so much. Pandemics are one of them.

The H1N1 (“Swine Flu”) seems far away. The SARS epidemic is almost an ancient memory. The human mind is great and tends to favor remembering the good times a lot better than the bad. That doesn’t mean we should forget the lessons we learned from the difficult times and look at the past with rose-tinted glasses.

During previous epidemics, many companies contacted Spirent for our ability to test VPN concentrators at scale. With the current events surrounding COVID-19, a.k.a. “Coronavirus”, the phones are ringing again. More and more companies are starting to ask their employees to work from home (Microsoft, Twitter, Amazon, Nestlé, L’Oréal, Airbnb, …). These large companies have probably incorporated pandemics as part of their Business Continuity plans and have already put them to the test. They are ready.

Is your company ready? If this pandemic, or the next one, or the next catastrophic event makes matters worse, are you sure that you are ready to keep the business going? We’ve already seen that the global economy has slowed down due to the Coronavirus. Some jobs must be done on-site, but a lot of them will be done remotely. The last thing you want is to overwhelm your IT Helpdesk with calls from your employees unable to set-up a VPN tunnel or experiencing poor performance and high response times just because your firewall is undersized.

Now more than ever you should put this to the test. It’s the only way to know for sure. The vendors’ datasheets for performance numbers are “best case” scenarios but might not represent the real, live network conditions. The only way to know for sure is to put the infrastructure to the test and get the real results.

If you think it’s expensive to test, wait until you don’t test and your business is disrupted.

Posted in General | Tagged , , , | Leave a comment

DNS over HTTPS Testing Using Avalanche (JSON format)


DNS over HTTPS (DOH) is very popular these days. Several groups have formed to define and push the technology forward, RFCs are being written and working implementations exist.

Several customers started asking us to support DNS over HTTPS. The thing is, we already support HTTPS. We have very good support for it, actually. Before knowing anything about the protocol I assumed it was just some form of DNS data being sent back and forth between a client and a server. Instead of being an unencrypted, UDP-based protocol, DNS became a TCP-based, strongly encrypted HTTP application data. And that’s exactly what it is.

HTTP is a very nice protocol to work with because it’s highly flexible. It immediately becomes awesome when coupled to TLS and becomes HTTPS. Spirent’s Avalanche load generator supports all of this.

Here’s how to test DNS over HTTPS using Avalanche. In this article we’ll focus on the JSON version, not the UDP Wireformat one.

Continue reading
Posted in General | Tagged , , , , | Leave a comment

Import a large amount of content into CyberFlood


One of Spirent CyberFlood‘s best feature is the ability for users to upload their own content – application, attack or malware signatures – to its library and use it anywhere in the product – send it at load, or in a catch-rate scenario, or a protocol mix, etc. Spirent provides a very, very large library of content with thousands upon thousands of signatures.

But sometimes this is not enough (when you sell a product, nothing is ever enough to please everyone, trust me on this). I recently met a customer who had a library of 20,000 network attacks, which is more than we do. Makes sense, that customer makes Intrusion Prevention Systems. But CyberFlood has no way to import thousands of signatures. Fortunately the product ships with a full REST API.

This is how the CyberFlood Python Importer was born. The name says it all: it’s a Python script that allows users to import a lot of PCAPs or HAR (HTTP Archive) files to a CyberFlood Controller. The script is open source under a MIT licenses. It means you can use, modify and distribute it in any way you see fit. It works both on Windows and Linux, in CLI or headless mode.

Continue reading
Posted in Uncategorized | Tagged , , | Leave a comment

Protocol Simulation vs Emulation – What are the differences and why do they matter?


There are several ways to generate test traffic. At Spirent define two main approaches: simulated and emulated traffic. But what are the differences and why do they matter?

At first, they sound like they are the same and both terms could be used interchangeably. But when you look at the semantics of both words they don’t describe quite the same thing. A simulation is something close enough to the reality but when looked at in details can be easily distinguished from the real thing. An emulation however is supposed to look exactly the same.

Think of Simulation as a high definition print of the Mona Lisa. From afar it’ll look just the same to most people, but upon closer inspection you’ll see the pixels and the lack of relief that paint adds.

An Emulation however would be a copy of the painting made by a Master. These paintings are sometimes indistinguishable from the original version – and sometimes even sold as originals. They are so close to the reality that 99.9% of the people in the world couldn’t tell one from the other.

Continue reading

Posted in General | Tagged , , | Leave a comment

Founding members of NetSecOPEN announced


NetSecOPEN is an initiative that I’ve been meaning to talk about on this blog for a long time. It wasn’t really finished yet so there wasn’t much to talk about except good intentions. But we’re now moving into the next phase so let’s discuss this great project. The organization officially released the name of the founding members. Spirent is one of them.

A couple of websites picked up on this, in case you want to read the opinions of non-Spirent employees 🙂

What is NetSecOPEN?

In just a few words, NetSecOPEN (NSO) is a working group of Network Security (hence the “NetSec” part of the name, as I’m sure everybody realizes) companies whose aim is to define an open and modern Test Methodology for testing Network Security Devices (now you also get the “OPEN” part of the name). The first type of devices that the group targets are Next-Generation Firewalls (NGFW).

The goal is to make this a standard methodology because, believe it or not, there are no official standard. Because of this, the Methodology will me put under the supervision of IETF’s Benchmarking Methodology Working Group (BMWG). Anyone can read the methodology. It’s for now a “personal draft” but it’ll soon be moved to the BMWG. The draft is available right there: https://datatracker.ietf.org/doc/draft-balarajah-bmwg-ngfw-performance/

Anybody can run this test, given that their traffic generator supports the features. Any employee of the companies joining NSO can attend any call and input comment. It’s almost free to join, too. “Almost” because NSO is a Non-Profit so it needs money to pay a couple of employees and the few expenses involved (conferencing systems, hosting, etc).

I personally like NSO a lot because it’s modern and completely open. Anybody can read the test specifications and get a better understanding of the tests and what the results mean. It also means that when a NGFW gets certified to perform at a given number, you can directly compare that number to another device of the test category.

How will devices certified?

The beauty of this working group is that its members come from different areas of the industry: Network Equipment Manufacturers (NEMs), independent Test Labs and Network Test Equipment Manufacturers (Spirent falls into that last category obviously).

When a NEM wants to certify an equipment of theirs, they get in touch with a Test Lab able to deliver the NSO test suites. Once that’s done, they submit their configs and results to NSO for kind of an “auditing” of the test and its results, and validate them (or not). The results are then validated and the NEM is allowed to publish the numbers, on their datasheets for instance. The goal is to kind of “train” the end users (the ones who’ll purchase devices from the NEMs) to look for the “NetSecOPEN Certified Performance Numbers” on datasheets.

The founding members are the following:

  • NEMs: Check Point Software Technologies, Cisco, Fortinet, Palo Alto Networks, SonicWall, Sophos, WatchGuard;
  • Test Vendors: Spirent, Keysight
  • Test Labs: European Advanced Networking Test Center (EANTC), Underwriters Labs (UL), University of New Hampshire InterOperability Lab (UNH-IOL).
Posted in General | Tagged , , , , , | 1 Comment

Avalanche 4.86 released


On Friday May 30th we released a new version of Avalanche. The list of feature isn’t huge, but they are Really Good Features.

First, Avalanche now supports Adaptive Bitrate MPEG DASH Live (on the client-only for that initial release). This is important because, although we could test DASH VoD in the past (as well as the Apple, Microsoft and even Adobe flavors), the Live implementation was something a lot of our Content Provider customers asked for. We’ll add the server-side at a later stage, and I’m personally okay with this because more often than note we are testing against real servers.

The second large feature is the upgrade of our TLS 1.3 implementation to Draft 26. Which as far as I understand is the latest technical draft – the follow up two drafts are tweaks to the document etc.

Another TLS related feature is the support of RFC 7627. This RFC adds a TLS 1.2 extension to protect the sessions’ Master Secret further and prevent some very specific (and technically challenging, but theoretically possible I suppose) Man-in-the-Middle attacks.

And last but not least, we can now disable Duplicate Address Detection in our IPv6 stack.

The release also brings a metric ton of bug fixes so customers with valid Support Contracts are recommended to upgrade to this version.

Posted in Releases | Leave a comment

Deploying the CyberFlood Controller on ESXi (6)


CyberFlood is Spirent’s next-generation GUI for Security and Performance Testing. If you need to test a Firewall, Next-Gen (NGFW) or not, this is the tool you need. The Controller is a Virtual Machine that you deploy and that allows you to configure and run your tests, manage your load generators (whether they are appliances or virtual endpoints), regroup your test results, and so on and so forth.

In this article we’ll see how to deploy the Controller on an ESXi 6.0 host. It’s not the latest ESXi version available today, but that’s what I have. ESXi 6.5 doesn’t change much in the way to deploy the controller except that VMware interface is in HTML. But the important stuff doesn’t change. Continue reading

Posted in Tutorial | Tagged , | Leave a comment

Cipher Suite Names


Probably because everything needs to be complicated in cryptography, OpenSSL (and compatible APIs and products) have two sets of Cipher Suite names : Long-Name Format and Short-Name Format. Another way to look at it is that long form names are the most technically accurate ones while short form are just more practical – especially if you try to fit them in a UI. Just to prove my point, the table below breaks the layout of this website a little bit 🙂

And this is what we do in Avalanche and CyberFlood: we show the Short-Name Format. The table below shows a mapping between Long and Short Name formats. This is directly taken from our documentation, and I might forget to keep this up to date. For reference, the Knowledge Base article this is taken from is available on Spirent Support Website (login required).

Continue reading

Posted in General | Tagged , , , , , | Leave a comment

Pi-Hole is a wonderful DNS server (and much more)


I was recently made aware of a nifty project called Pi-Hole. Besides having one of the best project name ever, it’s just a brilliant idea. What PH does is black hole Fully-Qualified Domain Names (FQDN) known for serving advertisement but also used for user-tracking or “telemetry”. Like for instance what Microsoft does with Windows 10 – I don’t want to single them out, they’re hardly the only ones doing this. And the data they get is probably very useful to develop the product. This post is not about the merits of advertisement or user-tracking.

Continue reading

Posted in General | Tagged , , , , | Leave a comment

IPSEC Remote Access Testing using Avalanche and Fortigate – The Sequel


A few years ago I wrote an article on how to test IPSEC on a Fortigate using Avalanche. But the article is largely outdated and only covers Preshared Key Authentication. It so happens that I recently needed to configure a similar test, except this time the authentication mechanism had to be Digital (RSA) Certificates. So let’s get to it.

Test Bed

Let’s recap what we have:

  • Load Generator is a Spirent Avalanche C100-S3 running version 4.75.
  • DUT is a Fortigate 1500D running FortiOS 5.2.2 (I know it’s not the latest version, but it’s the one I have)
  • Devices are connected through a MRV switch and a Velocity topology using 2x 10GbE fibre.

Test Requirements

  • IPSEC in Tunnel mode
  • Digital Certificate Authentication
  • Phase 1: IKEv1, DH-Group 14, AES-256 encryption and SHA-256 hash, Aggressive Mode
  • Phase 2: AES-256 and SHA-256 no need for PFS (customer’s requirement; Avalanche supports P2 PFS just fine).

Continue reading

Posted in General, Tutorial | Tagged , , , , , , , | Leave a comment