Marcio Cunha

How to create an isolated environment for security analysis with Mantis

Learn how to configure a secure laboratory using Mantis to conduct penetration testing and vulnerability triage without exposing your corporate network to unnecessary risks.

Marcio Cunha12 min
Also available in:EspañolPortuguês
Summary
  • Network isolation prevents malicious artifacts from reaching the main infrastructure during the triage phase.
  • Choosing lightweight virtualization ensures portability and rapid reproducibility of test scenarios.
  • The use of strict firewall policies blocks any attempt at data exfiltration to the public internet.
  • External log persistence ensures that forensic investigation remains viable even after catastrophic failures.
  • Automating the laboratory lifecycle reduces the time spent preparing new analysis sessions.

Introduction to Environment Isolation in Security Analysis

When executing security tests, the greatest danger is not just the malicious code we are evaluating, but the possibility that it escapes into the company's primary network. In practice, this means a configuration mistake can turn your work computer into an infection vector for corporate servers or confidential data. To avoid this nightmare, engineers use isolated environments, often called sandboxes, which act as a glass dome where we can observe dangerous reactions without putting anything at risk.

In this article, we will explore the step-by-step construction of a dedicated laboratory using Mantis, a robust tool for incident tracking and test organization. More than just installing software, our goal is to design a secure network topology, configure rigid traffic rules, and ensure any analyst can reproduce the environment easily. We will cover everything from the foundation of the virtual infrastructure to data cleanup and destruction policies after analyses conclude.

Understanding Architecture and Execution Risks

Before touching code or network settings, it is crucial to understand the threat model we face. Analyzing vulnerabilities requires interacting with payloads, which are blocks of code created to exploit specific system flaws. If these blocks contact the production network unsupervised, the damage can be immense. Mantis enters this ecosystem not as the tool executing the attack itself, but as the central nervous system cataloging findings, correlating evidence, and keeping the team aligned.

The separation between the analysis machine and the target must be physically or virtually inviolable. In practical terms, we configure virtual local area networks (VLANs) that lack routing to the public internet unless passing through a rigorous inspection gateway. This creates controlled friction: the analyst can download dependencies through controlled local mirrors, but the malware under investigation remains trapped in a box without exit doors.

Preparing the Host System and Virtualization Tools

The first practical step in building our lab is preparing the host machine, the physical computer or server housing the virtual environments. We recommend Linux-based operating systems due to refined control over iptables, a built-in firewall utility in the OS kernel that decides which data packets enter or leave. Additionally, we use containerization tools like Docker, which package applications into isolated compartments called containers while safely sharing the operating system kernel.

To run Mantis alongside the testing environment, we create an orchestration file defining the necessary services. In practice, this automates the creation of the database, the Mantis web interface, and the isolated networks. Below is a simplified configuration example using Docker Compose, a tool for managing multiple containers simultaneously:

version: '3.8'
networks:
  isolated_net:
    internal: true
services:
  mantis_db:
    image: mariadb:10.5
    environment:
      MYSQL_ROOT_PASSWORD: secure_root_password
      MYSQL_DATABASE: mantis_db
    networks:
      - isolated_net
  mantis_app:
    image: mantisbt/mantisbt:latest
    ports:
      - "8080:80"
    networks:
      - isolated_net
    depends_on:
      - mantis_db

This code snippet configures an internal network named 'isolated_net' with no internet access, protecting the database and tracking system. Port 8080 is exposed only so authorized analysts on the local network can securely access the Mantis web interface.

Configuring Network Rules and Isolation Barriers

With basic services running, the next challenge is shielding communication. The most common mistake is trusting default virtualization settings, which often permit outbound traffic for convenience. In practice, we must apply explicit firewall rules blocking any external connection attempts originating inside the test network. This is done using terminal commands to configure packet routing.

If malicious software tries sending collected data to a command-and-control server on the internet, the network barrier intercepts and drops the packet instantly. For auditing, we configure a log collector recording all blocked connection attempts. This provides valuable insights into the analyzed artifact's behavior, allowing the team to document compromise indicators directly in Mantis for future reference.

Integrating Mantis into the Incident Response Workflow

An isolated environment loses much of its utility if analysis results scatter across local text files or manual notes. Mantis shines here, serving as a centralized repository where every discovered vulnerability turns into a structured ticket. When an analyst identifies suspicious behavior, they open a detailed ticket explaining malware signatures, file hashes, and mitigation steps.

To optimize this process, we can configure webhooks, which are automated notifications sent by systems upon specific events. In practice, whenever an automation script finishes scanning a file in the sandbox, it can send a preliminary report directly to Mantis, populating ticket description fields without human intervention. This reduces typing errors and drastically accelerates critical incident response.

Best Practices for Laboratory Cleanup and Maintenance

Maintaining a functional security analysis environment demands discipline when discarding generated waste. Unlike traditional servers meant to last years, our test laboratory must be ephemeral—designed to be destroyed and easily recreated. After each deep analysis session, containers and virtual machines contacting unknown code must be discarded and replaced with clean images.

Long-term evidence storage should occur exclusively in secure, encrypted external volumes, ensuring no infectious traces remain active in the infrastructure. Following this rigorous routine allows engineering teams to conduct complex security research, test defenses, and document findings in Mantis with total peace of mind and operational control.

Conclusion

Creating an isolated environment for security analyses using Mantis represents a watershed moment between chaotic reactive operations and structured defensive engineering. By combining lightweight virtualization, restricted networks, and ticket automation, we contain risks without sacrificing investigation agility.

Investing time in proper infrastructure configuration protects organizations against breaches and ensures knowledge acquired during analysis is preserved in an organized manner. Ultimately, information security relies less on magical solutions and much more on consistent processes, rigorous isolation, and reliable tracking tools.