-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Docker Linux
The recommended docker run command to be run under Linux host is:
~# docker run \
--rm \
-ti \
--name airgeddon \
--net=host \
--privileged \
-p 3000:3000 \
-v /path/to/some/dir/on/your/host:/io \
-v /path/to/another/dir/on/your/host:/opt/airgeddon/plugins \
-e DISPLAY=$(env | grep DISPLAY | awk -F "=" '{print $2}') \
v1s1t0r1sh3r3/airgeddon
Parameters explanation:
-
--rm
→ Ephemeral containter. It will be removed on exit. -
-ti
→ Attach pseudo-TTY terminal to the container as interactive. -
--name airgeddon
→ Name for the container. -
--net=host
→ Is needed to have access to the host network interfaces inside the container. -
--privileged
→ Needed to have permissions over network interfaces (mode switching). -
-p 3000:3000
→ Open port to access to BeEF control panel from the host. -
-v /path/to/some/dir/on/your/host:/io
→ It maps a directory from host to the container. Useful to use external files like dictionaries, get pots after successfull attacks or whatever. -
-v /path/to/another/dir/on/your/host:/opt/airgeddon/plugins
→ It maps another directory from host to the container. Useful if you want to run a plugin inside the container. -
-e DISPLAY=$(env | grep DISPLAY | awk -F "=" '{print $2}')
→ It overwrites the needed var to connect to local X Window system. DISPLAY=:0 is used by default so you can avoid this parameter if you already have set DISPLAY=:0 var on your host system. -
v1s1t0r1sh3r3/airgeddon
→ Is the name and tag of the image.v1s1t0r1sh3r3/airgeddon
is the stable version built from master branch and is the same asv1s1t0r1sh3r3/airgeddon:latest
. Alternatively you can usev1s1t0r1sh3r3/airgeddon:beta
for development version built from dev branch.
Don't forget to replace on docker command the string "/path/to/some/dir/on/your/host" with a path of an existing directory of your choice on your host machine. That directory will be the "input/output" point for the script. For example, if you place a dictionary.txt file there, inside the script you must access to it as "/io/dictionary.txt". If you capture a trophy or a Handshake file, save it at "/io/" dir to access it from the host.
Regarding the second volume "/path/to/another/dir/on/your/host", it is optional and it shoulde be set only if you want to run a plugin for airgeddon. Check here what plugins can do for you.
On some distros like Ubuntu, in order to open the possibility of connecting airgeddon
xterm windows to your host X Window system, you must launch first ~# xhost +
command. You can check if you need it easily. The resolution should be detected inside airgeddon
on initial checks. If not is detected, you have a problem with your DISPLAY var. You should launch ~# xhost +
command or adjust DISPLAY var on docker run command.
As described in Options wiki section, it is possible to set up some available options. Running airgeddon
in docker still allow this. Let's suppose that you want to run airgeddon without any color. The AIRGEDDON_BASIC_COLORS
must be set to "false" to perform this. We can set it as another environment var just using another -e
parameter on docker run command. Example:
docker run --rm -ti --name airgeddon --net=host --privileged -p 3000:3000 -v /path/to/some/dir/on/your/host:/io -v /path/to/another/dir/on/your/host:/opt/airgeddon/plugins -e DISPLAY=$(env | grep DISPLAY | awk -F "=" '{print $2}') -e AIRGEDDON_BASIC_COLORS=true v1s1t0r1sh3r3/airgeddon
You can add as many options as you want setting a -e
parameter for each one.
Evil Twin attacks are using hostapd
to create fake AP which usually are in conflict with network-manager
. In native mode airgeddon
handle this to solve process conflicts, but when launched in a Docker container is not possible because the conflicting network-manager is on the Linux host (not on container). Anyway, airgeddon
will show you a warning as a reminder of this while running on Docker before launch hostapd
. So, before launching any Evil Twin Attack, be sure of killing conflicting processes or disabling/stopping network-manager
if you have it installed on Linux host or you'll get an error like this:
Configuration file: /tmp/ag.hostapd.conf
nl80211: Could not configure driver mode
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
nl80211 driver initialization failed.
wlan0: interface state UNINITIALIZED->DISABLED
wlan0: AP-DISABLED
hostapd_free_hapd_data: Interface wlan0 wasn't started
The easiest way is to launch on host this command:
~# airmon-ng check kill
→ This will kill conflicting processes.
Or if you prefer, you can directly disable network-manager
. To do this there are several ways. Depending on your Linux distribution the command may vary. Some of them are:
~# service network-manager stop
→ Valid for Kali, Backbox, Ubuntu, Debian, Raspbian, Parrot and Cyborg.
~# service NetworkManager stop
→ Valid for SuSE, CentOS, Fedora, Gentoo and Red Hat.
~# systemctl stop NetworkManager.service
→ Valid for Arch, BlackArch and OpenMandriva.
~# rc-service NetworkManager stop
→ Valid for Pentoo.
The goal is to see at hostapd
window something like this:
Configuration file: /tmp/ag.hostapd.conf
Using interface wlan0 with hwaddr 00:11:22:33:44:55 and ssid "airgeddon-test"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
It's understood that your Linux host has the needed drivers for your wireless card and its kernel support all the needed features for wireless operations (switching mode managed/monitor) in the same way as is needed to run it in native mode on any Linux system.
Content & Features
Requirements
- Requirements
- Compatibility
- Essential Tools
- Optional Tools
- Update Tools
- Internal Tools
- Known Incompatibilities
Getting Started
Learning
Project & Development
- Plugins system
- Supported Languages
- Contributing & Code of Conduct
- Merchandising Online Shop
- Changelog
- Disclaimer & License
- Contact
Acknowledgments & References