Skip to content
Switch branches/tags

MI-LXC : Mini-Internet using LXC            


MI-LXC uses LXC to simulate an internet-like environment. I use this environment for (infosec) practical work (intrusion, firewall, IDS, etc.). The small memory footprint of LXC combined with differential images allows to run it on modest hardware.

It is based on the infrastructure-as-code principle: these scripts programmatically generate the target environment.

Example practical work using this environment (in french) :

There is also a walkthrough tutorial and a video.


Features and composition

Features :

  • Containers run up-to-date Debian Buster or Alpine Linux
  • The infrastructure-as-code principle allows for easy management, deployment and evolution along time
  • The infrastructure is built by final users on their own PC
  • Every container also have access to the real internet (for software installation)
  • Containers provide shell access as well as X11 interface

The example network is composed of :

  • some transit/ISP routed through BGP to simulate a core network
  • an alternative DNS root, allowing to resolve real TLDs + a custom ".milxc" TLD (the .milxc registry is maintained inside MI-LXC)
  • some residential ISP clients (hacker and a random PC), using mail adresses @isp-a.milxc
  • a target organization, owning its own AS number, running classical services (HTTP, mail, DNS, filer, NIS, clients, etc.) for target.milxc domain
  • a certification authority (MICA) ready for ACME (Let's Encrypt-style)
  • MISP instances on (on target-dmz) and misp.gozilla.milxc (on gozilla-infra)

A few things you can do and observe :

  • You can http from isp-a-hacker. Packets will go through the core BGP network, where you should be able to observe them or alter the routes
  • You can query the DNS entry from isp-a-hacker. isp-a-hacker will ask the resolver at isp-a-infra, which will recursively resolve from the DNS root ns-root-o, then from reg-milxc and finally from target-dmz
  • You can send an email from hacker@isp-a.milxc (or another forged address...), using claws-mail on isp-a-hacker, to commercial@target.milxc, which can be read using claws-mail on target-commercial (with X11 sessions in both containers)

The "IANA-type" numbering (AS numbers, IP space, TLDs) is described in doc/MI-IANA.txt. There is currently no cryptography deployed anywhere (no HTTPS, no IMAPS, no DNSSEC, etc.). This will probably be added at some point but in the meantime, deploying this is part of the expected work from students.

More precise details on what is installed and configured on hosts is in doc/

How to use


You can either:


The script generates and uses containers (as root, since it manipulates bridges and lxc commands, more on this here)

  • ./ print # Displays the configured topology
  • ./ create # Creates master containers and then clones it to create all the containers
  • ./ start # Start the generated infrastructure (stop to stop it)
  • ./ attach [user@]<name> [command] # Executes [command] in the container <name> as user [user]. [command] and [user] are optional; if not specified, user is root and command is an interactive shell.
  • ./ display [user@]<name> # X11 access to the container <name>. Default user is debian
  • ./ renet # Updates containers network interfaces and setups to reflect topology changes (global.json/local.json)
  • ./ # Usage and list of container names
  • ./ destroy && ./ destroymaster # Destroys everything (master containers and all linked containers)
  • There is also a walkthrough tutorial.

What is done with root permissions ?

  • Manipulation of LXC containers (no unprivileged LXC usage yet)
  • Management of virtual ethernet bridges with brctl, ifconfig and iptables (in and, around line 324)
  • Increase of fs.inotify.max_queued_events, fs.inotify.max_user_instances and fs.inotify.max_user_watches through sysctl (in, around line 278)

This is not ideal but is currently needed. An issue is opened on the topic but it is not currently planned.

How to extend

The address space is explained in MI-IANA.txt and the global topology is defined in global.json. It describes:

  • masters, in the masters/ subfolder (currently a Debian Buster and an Alpine Linux)
  • groups of hosts, typically AS interconnected with BGP

Groups of hosts are described through:

  • group templates in templates/groups/<groupname>/local.json, which typically provides a as-bgp group template to setup an AS
  • enriched with local specifications in groups/<groupname>/local.json

Finally, hosts are described and provisonned through:

  • host templates in templates/hosts/<family>/<template>/, which typically provide templates for BGP routers, mail servers, mail clients, ...
  • specific scripts for a given host in groups/<groupname>/<hostname>/

To extend it, you can either extend an existing AS (typically, Target) or create a new AS. In this second case, you can duplicate Target and then connect it to some transit operator under a new AS number (all BGP-related configuration is specified in global.json)


This software is licensed under AGPLv3 : you can freely reuse it as long as you write you use it and you redistribute your modifications. Special licenses with (even) more liberties for public teaching activities can be discussed.