w3af inside docker¶
Using w3af
inside docker should be transparent for most use cases, this page
documents the use cases which are complex to solve when docker is added to the
mix.
Ports and services¶
Some w3af plugins, such as crawl.spider_man
and audit.rfi
start proxy
HTTP services. In order to access these services the plugins need to be
configured to listen on 0.0.0.0
and the port needs to be made accessible
to the host using the -p
parameter in the helper script
(ie. extras/docker/scripts/w3af_console_docker
)
Take a look at this commit for more information about exposing ports.
Sharing data with the container¶
When starting w3af using the w3af_console_docker
or w3af_gui_docker
commands the docker containers are started with two volumes which are mapped to
your home directory:
~/.w3af/
from your host is mapped to/root/.w3af/
in the container. This directory is mostly used byw3af
to store scan profiles and internal data.~/w3af-shared
from your host is mapped to/root/w3af-shared
in the container. Use this directory to save your scan results and provide input files to w3af.
Debugging the container¶
The container runs a SSH daemon, which can be used to both run the w3af_console
and w3af_gui
. To connect to a running container use root
as username and
w3af
as password. Usually you don’t need to worry about this, since the helper
scripts will connect to the container for you.
Another way to debug the container is to run the script with the -d
flag:
$ sudo ./w3af_console_docker -d
root@a01aa9631945:~#
Note
WARNING: Don’t bind w3af’s docker image to a public IP address unless you really know what you’re doing! Anyone will be able to SSH into the docker image using the hard-coded SSH keys!