Using the LXD Kali container image

If you have a look at the list of container images for LXD (repository images:), you will notice the recent addition of the Kali container images. These were added by Re4son (@kali.org).

But Kali is a security distribution, does it make sense to create system containers with Kali? LXD offers system containers, which are similar to virtual machines, but not quite like virtual machines.

In this post we see how to use a Kali system container with the WiFi security tools by attaching a network card to the container.

Prerequisites

We are using a USB WiFi adapter. Any network card can work here, but it’s a USB WiFi adapter for today.

When you connect the adapter to your computer, it will be autoconfigured by NetworkManager. We do not want that. We want the network adapter to be unmanaged, not managed by NetworkManager on the host.

We have connected the network adapter. Let’s see it and identify the MAC address. The MAC address is 00:0f:00:7c:e0:55.

$ iwconfig
wlx000f007ce055  IEEE 802.11  ESSID:off/any  
           Mode:Managed  Access Point: Not-Associated   Tx-Power=0 dBm   
           Retry short limit:7   RTS thr:off   Fragment thr:off
           Power Management:on

$ ifconfig wlx000f007ce055
wlx000f007ce055: flags=4098  mtu 1500
        ether 00:0f:00:7c:e0:55  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We edit and append the following lines in /etc/NetworkManager/NetworkManager.conf.

[keyfile] 
unmanaged-devices=mac:00:0f:00:7c:e0:55

Finally, we restart NetworkManager in order to consider this network device as an unmanaged (by itself) device.

$ sudo systemctl reload NetworkManager

Finally, we check whether RFKILL is blocking the wireless adapter. If it is, we unblock it.

$ rfkill list
0: : Wireless LAN
    Soft blocked: yes
    Hard blocked: no
$ rfkill unblock all
$ rfkill list
0: : Wireless LAN
    Soft blocked: no
    Hard blocked: no

We are now good to go. The network device is unmanaged, and the Kali container can now start using it.

Creating a Kali system container

Let’s see the list of available Kali container images. The command is lxc image list and we specify the repository images:. The kali means that we are searching for all images that contain kali anywhere in the name. There is a kali container image, that defaults (in my case) to the x86_64 image (same with the host). There exist container images for i386, armel and armhf, which apparently correspond to all supported architectures of the Kali project.

$ lxc image list images:kali
+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

|           ALIAS           | FINGERPRINT  | PUBLIC |             DESCRIPTION             |  ARCH   |  SIZE   |          UPLOAD DATE          |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali (5 more)             | 00302e62e5f2 | yes    | Kali current amd64 (20190813_17:14) | x86_64  | 87.70MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/arm64 (2 more)       | 54747ab801e8 | yes    | Kali current arm64 (20190813_17:14) | aarch64 | 84.52MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/armel (2 more)       | 351adfe2cbf7 | yes    | Kali current armel (20190813_17:34) | armv7l  | 82.22MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/armhf (2 more)       | 0281fd185db7 | yes    | Kali current armhf (20190813_17:14) | armv7l  | 82.73MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/cloud (3 more)       | 2e6c1ee1604a | yes    | Kali current amd64 (20190813_17:14) | x86_64  | 87.70MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/cloud/arm64 (1 more) | 2353897a13d5 | yes    | Kali current arm64 (20190813_17:14) | aarch64 | 84.52MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/cloud/armel (1 more) | 16ce426ef8ca | yes    | Kali current armel (20190813_17:14) | armv7l  | 82.23MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/cloud/armhf (1 more) | 61cdf9b01f18 | yes    | Kali current armhf (20190813_17:14) | armv7l  | 82.73MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/cloud/i386 (1 more)  | ff564b63033a | yes    | Kali current i386 (20190813_17:14)  | i686    | 88.65MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

| kali/i386 (2 more)        | 7de5fdd5ab55 | yes    | Kali current i386 (20190813_17:55)  | i686    | 88.65MB | Aug 13, 2019 at 12:00am (UTC) |

+---------------------------+--------------+--------+-------------------------------------+---------+---------+-------------------------------+

There is a kali and there is a kali/cloud. The container images have almost the same size, but different checksums. The cloud container images just have enabled support for cloud-init. This means that if you have the need to pass initial configuration to the container using cloud-init, then use the cloud container images.

We launch a container called mykali from the images:kalicontainer image.

$ lxc launch images:kali mykali

Let’s have a look at it the newly created container. It got a private IP address, in my case 10.10.10.20. We will use this later.

$ lxc list mykali
 +--------+---------+--------------------+-----------------------------------------------+------------+-----------+
 |  NAME  |  STATE  |        IPV4        |                     IPV6                      |    TYPE    | SNAPSHOTS |
 +--------+---------+--------------------+-----------------------------------------------+------------+-----------+
 | mykali | RUNNING | 10.10.10.20 (eth0) | fd42:3964:5d29:887a:216:3eff:fe39:56a5 (eth0) | PERSISTENT | 0         |
 +--------+---------+--------------------+-----------------------------------------------+------------+-----------+

Using the Kali LXD container

Let’s get a shell into kali.

$ lxc exec mykali -- /bin/bash
root@mykali:~# 

We are in! Now what? Let’s refresh the package list. And then try something related to WiFi. There is no iw command, therefore we install the iw package. Still, there is no Wifi card because the default settings in a LXD container does not include a WiFi interface. We have to add such an interface.

root@mykali:~# apt update
 Hit:1 https://kali.download/kali/ kali-rolling InRelease
 Reading package lists… Done
 Building dependency tree       
 Reading state information… Done
 All packages are up to date.
 root@mykali:~# iw
 bash: iw: command not found
 root@mykali:~# apt install iw
...
root@mykali:~# iw
root@mykali:~# logout
$ 

Adding a WiFi adapter to the Kali LXD container

LXD has the facility to make a network interface disappear from the host and make it appear in a LXD container. The LXD container has exclusive use if the network adapter. And all this is hot-pluggable (with a caveat). Here is again the USB WiFi adapter. It has the interface name wlx000f007ce055 on the host.

$ lsusb
 ...
 Bus 003 Device 006: ID 148f:7601 Ralink Technology, Corp. MT7601U Wireless Adapter
...
$ iw dev
 phy#1
     Interface wlx000f007ce055
         ifindex 40
         wdev 0x100000001
         addr 00:0f:00:7c:e0:55
         type managed
         txpower 0.00 dBm

Let’s move this network interface into the Kali LXD container. We add to the container mykali a device called wifi, which is a nic LXD device. The nictype is physical, with the interface name wlx000f007ce055 on the host, and in the container it will be known as wlan0.

$ lxc config device add mykali wifi nic nictype=physical parent=wlx000f007ce055 name=wlan0
Device wifi added to mykali

Did it work? It sure did!

$ lxc exec mykali -- /bin/bash
root@mykali:~# iw dev
 phy#0
     Interface wlan0
         ifindex 40
         wdev 0x100000001
         addr 00:0f:00:54:e9:aa
         type managed
         txpower 0.00 dBm
 root@mykali:~# 

Let’s put the interface in monitor mode. We use phy0 because the command above says phy#0. The new interface is called mon0. Then, we UP the interface and it is ready to use.

root@mykali:~# iw phy phy0 interface add mon0 type monitor
root@mykali:~# ip link set mon0 up

Now the interface mon0 is available, and we can use it with any WiFi network security tools in Kali.

Running Aircrack-ng in a LXD Kali system container

We install aircrack-ng in Kali and try out the tool.

root@mykali:~# apt install -y aircrack-ng

The network interface is already prepared in MONITOR mode, therefore we can straight away run commands like the following.

root@mykali:~# airodump-ng mon0

Running Kismet in a LXD Kali system container

We install Kismet in Kali and try out the tool.

root@mykali:~# apt install -y kismet

Then, we run kismet.

root@mykali:~# kismet
...
INFO: Starting Kismet web server…
INFO: Started http server on port 2501

We can now open our Web browser on the host and visit http://10.10.10.20:2501/ to continue with Kismet from the Web interface. Substitute accordingly the private IP address of your mykali container.

We set a username and password, and then logged into the Web interface of Kismet. We went into the Data Sources setting (top left of page), and enabled the Source mon0.

As soon as we enabled the data source, we are able to use Kismet from the Web interface.

Enabling CUDA in a LXD Kali system container

Here is how to enable GPU support in the container. We enable the nvidia.runtime, which means that the GPU libraries are loaded from the NVidia-supplied runtime, and matches our host’s driver version.

$ lxc launch images:kali mykali 
Creating mykali
Starting mykali
$ lxc config set mykali nvidia.runtime true
$ lxc config device add mykali mygpu gpu
Device mygpu added to mykali
$ lxc restart mykali
$ lxc exec mykali -- nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.116                Driver Version: 390.116                   |
|-------------------------------+----------------------+----------------------+
...

Future steps

In this post, we introduced the LXD Kali container image and showed how to use it with a WiFi adapter. We showed how to use with the aircrack-ng suite and with kismet. You can also use with other tools, such as wifite which work better with CUDA support.

It is possible to run GUI tools in the Kali system container, though this is not shown in this post.

You can also attach any other network interface into the container. For example, you can put the Kali system container on a VPS and attach to it a dedicated secondary network interface. Or, use the VPS from the emergency console and attach the main network interface to the Kali container.

You can also expose the Kali container on the network using either a bridge or macvlan, and it is as if it was a separate and independent computer.

Simos Xenitellis