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 mykaliwifi, 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.
Recent Comments