Skip to main content

AutoMirror v0.4 aka The Load-Balancing Release

AutoMirror keeps improving, with valuable feedback from users and from better testing it out in the field. In this post we'll highlight a few important and new features.

If you haven't yet, we encourage you to check out the article where we presented the 3CS AWS Mirror Toolkit. You can find the blog post here.

As a follow up to that post, and after getting a lot of valuable feedback from clients and the overall community, we're really excited to release a new version of 3CS AWS AutoMirror.

Even though you can can keep an eye on the Changelog, and see screenshots of new features that we include on all opened issues, this post will add a bit more context to the features we added since we first talked about it.

By writing about use cases we also intend to provide the community with ideas to make better deployments by adopting more resilient architectures. Hopefully the features we add to AutoMirror and the use cases behind them will help you do that!

So, if traffic mirroring automation is something that interests you, buckle in and let's take a look at the awesomeness of 3CS AutoMirror v0.4!

Easy identification of sessions and its sources

We added this feature quickly after our first release, but didn't add a lot of context on why we wanted to do this. Since the 0.2 release, all Mirror Sessions created by AutoMirror will be named after the instance ID for which the session was created.

When dealing with mirrored traffic in AWS, instances identifiers are not really relevant. The network cards attached to the instances are the parts we focus on. With this feature, we give a visual representation that directly associates a mirror session with an instance, giving the user a visual aid regarding which instances are involved in a particular mirror session.

OCD-Approved tagging 

When AutoMirror was first released, conditions for setting tags, either for execution of AutoMirror or as a way to interact with it, were hardcoded and case sensitive. We now transform all tags and you are free to tag them in the way that makes the most sense to you, as long as you don't change the tags themselves. 😌 Whether you'd like to use mirror or Mirror, it's up to you. 

The same for the controlling tags. Mirror-Filter/Target, mirror-Filter/Target or mirror-filter/target. 

Report on active sessions

AutoMirror will now use the existing logging structure to provide a count of active mirror sessions. For invoicing or just to keep an eye out for what's going on, you'll now find the following information in your logs:

Screenshot from 2019-11-06 14-38-06

We added Mirror Filter creation!

There are several situations where creating a Traffic Mirror Filter might not be something you want to do manually. Because of that, AutoMirror will now create a Filter for you if one does not exist. 

You can read the characteristics of this feature in Github, but in summary, if you're running in an account where a Mirror Filter is not available, AutoMirror will create a filter that copies all the traffic on all protocols:

69461486-8e1c3b80-0d6e-11ea-924c-e122d8164939.png (988×227)

AI-powered Load Balancing!

Ah! You really thought we'd go down that route? Not yet (sorry sales)!

AutoMirror now has a Load Balancing capability that makes it perfect for deployments in environments with more than one Traffic Mirror Target.

AutoMirror will first check the load of each Traffic Mirror Target and distribute the creation of sessions amongst them! How cool is that?! 😍

AutoMirror + High Availability = 🏆

Stay tuned!

Follow us on Twitter!

Popular posts from this blog

Community Update - 3CORESec Blacklist 📓 🍯

Recently we tweeted about some issues we had with 3CORESec Blacklist , a platform that shares - openly and freely - a subset of the information seen and processed by our honeypot network.  While those issues have been addressed, and seeing as significant changes were made to how we monitor the generation of the lists (which is reflected in our status page ) and how we determine if an IP should be listed as an offending IP or not, this felt like a good opportunity to write a bit more about the platform as well as the changes we made.   For regular users of Blacklist 📓 the first thing they’ll notice is an increase on the numbers of IPs we include. That is a direct result of the changes we made and the growth of the honeypot network itself. We have not - and will not - ever increase the period for which we query the honeypot network, as we believe anything higher than 24h (as specified in the project page) for IP addresses can quickly fall into a decaying state that adds little value

Detection as Code (DaC) challenges - Introducing Automata

This blog post is the second part of our Detection as Code (DaC) challenges series. You can read part one here . The development process of detections by itself doesn't pose a lot of barriers for security engineering teams, as they are typically done in a lab/controlled environment, but after tuning and deploying rules to a SIEM, the work is only starting. Many things can go wrong after this, and a process of continued and automated testing is crucial. Detection Validation In an ideal (and fictional) world, once the datasets are parsed, normalized, and put into production, detections developed by your team would work forever. Still, the reality is quite different. Maintenance is heavy work that needs to be done frequently - especially if you work on an MSP - but the reality is that the ecosystem lacks tooling and processes to do it proactively. Effectiveness is an important metric and crucial to the successful response of incidents in time, and effectiveness is what we aim to ensu

Trapdoor - The serverless HTTP honeypot

  Today we are announcing the release of Trapdoor , our AWS-based serverless honeypot.  The idea of a serverless honeytoken isn't new. Adel released his honeyLambda a few years ago and we've been working with it for quite some time. It was because of this experience and the goal of improving on what was already a great idea that we decided to go to the drawing board and see how we would change and tweak the concept.  What is it? Trapdoor is a serverless application that can be deployed in any AWS environment. Its goal is to receive HTTP requests with the intent of identifying, and alerting, on its visitors. The URLs generated by Trapdoor can also be referred to as honeytokens .  While you can get creative on how to use it, one of the goals of a honeytoken is to be hidden or stored in a "safe" place and, if accessed, fire of an alarm, as access to the token would be considered a compromise or unauthorized access.  This example is the passive way of using deception ta