Feature Request: Docker Image about tsunami-security-scanner HOT 15 CLOSED

Real quick working example, but without any fancyness:

FROM openjdk:14-buster

RUN apt-get update -y
RUN apt-get install -y nmap ncrack

COPY . /tsunami
WORKDIR /tsunami

RUN "/tsunami/quick_start.sh"

WORKDIR /root/tsunami

docker build -t tsunami .
docker run --rm --net=host -it tsunami /bin/bash

In container you can run this:

java -cp "/root/tsunami/tsunami-main-0.0.2-SNAPSHOT-cli.jar:/root/tsunami/plugins/*" -Dtsunami-config.location=/root/tsunami/tsunami.yaml com.google.tsunami.main.cli.TsunamiCli --ip-v4-target=[target_IP]

from tsunami-security-scanner.

I'd like to take this

from tsunami-security-scanner.

Thank you @rayanht

I noticed that the output is json. Do you know if there is a GUI that can display this data in a more meaningful way or provide reports? Something like OpenVAS or Nessus?

from tsunami-security-scanner.

I noticed earlier today there is something here, but not very useful.

from tsunami-security-scanner.

@vdjagilev pretty minor, I believe --it are single character flags, so the docker run command should be:
docker run --rm --net=host -it tsunami /bin/bash

Thanks for putting together that working example.

from tsunami-security-scanner.

Would love to see the ability to scan a larger range-subnet such as

com.google.tsunami.main.cli.TsunamiCli --ip-v4-target=192.168.1.0/24 or

com.google.tsunami.main.cli.TsunamiCli --ip-v4-target=10.0.0.0/16

from tsunami-security-scanner.

@mwahl217 Just my two cents but I feel like that's something that should be implemented at the application level rather than through some Docker wizardry

from tsunami-security-scanner.

@mwahl217 Just my two cents but I feel like that's something that should be implemented at the application level rather than through some Docker wizardry

I agree, ill open a new feature request.

from tsunami-security-scanner.

Extended version with arguments and envs - also in CMD - suitable for CI systems integration.

FROM openjdk:8

RUN echo "Defining default values (when no --build-args)"
ARG var_target_ip_version="--ip-target-v4"
ARG var_target_host_ip="127.0.0.1"

# override the defaults (when --build-args passed during image build)
ENV TARGET_IP_VER=$var_target_ip_version
ENV TARGET_HOST_IP=$var_target_host_ip

RUN if [ -z ${TARGET_IP_VER+x} ] ; then \
    echo "var_target_ip_version is unset"; exit 1; else \
    echo "${TARGET_IP_VER} has been set (pass --build-arg to override)" ; fi

RUN if [ -z ${TARGET_HOST_IP+x} ] ; then \
    echo "target hostname missing"; exit 1; else \
    echo "${TARGET_HOST_IP} variable has been set (pass --build-arg to override)" ; fi

RUN apt-get update -y
RUN apt-get install -y nmap ncrack git

WORKDIR /root/tsunami
COPY quick_start.sh .

RUN chmod +x quick_start.sh \
     && ./quick_start.sh

RUN find ${HOME}/tsunami -name "tsunami-main-*-cli.jar" -print0 | xargs -0 -I {} mv {} ${HOME}/tsunami/tsunami-cli.jar

RUN mkdir ${HOME}/tsunami/logs/
RUN ls -l -h -a ${HOME}/tsunami/plugins

ENV JAVA_OPTS="-Dtsunami-config.location=tsunami.yaml com.google.tsunami.main.cli.TsunamiCli"
ENTRYPOINT ["sh", "-c", "java -cp tsunami-cli.jar:plugins/* ${JAVA_OPTS} ${TARGET_IP_VER}=${TARGET_HOST_IP} \
--scan-results-local-output-format=JSON --scan-results-local-output-filename=logs/tsunami-output.json"]

This way you can build your image from a build system passing the proper variables to the pipeline job (ip version and host ip).

These variables are rendered during docker image build time.
If there are no --build-arg defined, the image will render by default with ip v4 and ip 127.0.01 values.

Such Image is immutable - it only needs to be kubectl deployed or docker run after it's built.
Example: pass build args with ip address of k8s node and ip version, tag the image with these and then simply deploy this in the cluster in node matching defined ip address (docker Image Tag being IP should be defined in deployment (extra ansible variable) and with affinity definition in deploy.yaml the pod lands on the node that is going to be matched by the label (ip) and scanned in result)

Example for building image:
docker build --build-arg var_target_ip_version="--ip-v4-target" -t <imageRepo>/tsunami-scanner:127.0.0.1 -f Dockerfile . (based on above Dockerfile logic var_target_host_ip will be defaulted to 127.0.0.1, this default ip can be overridden during a build time with another --build-arg var_target_host_ip="x.x.x.x".

docker run -v "$HOME/tsunami_logs":/root/tsunami/logs <imageRepo>/tsunami-scanner:127.0.0.1

Going step further for more generic use (linux only), --network="host" could be passed in the CI pipeline, perhaps such image should be tagged first with hostnet instead of ip only (<imageRepo>/tsunami-scanner:hostnet-127.0.0.1)

from tsunami-security-scanner.

Closing as the Dockerfile has been added. Public docker image release is under internal review.

from tsunami-security-scanner.

@magl0 Do you have an update on the docker image release? Do you know if there will be Raspberry Pi support as well? I was unable to run docker build on the Pi (issue) and also had trouble cross-compiling for it using the buildx multiarchitecture option of docker (issue).

from tsunami-security-scanner.

@frakman1 This public docker image is still under internal security and license review. I'll post an update here once the review is done and the image is released to gcr.io.

from tsunami-security-scanner.

@magl0 Do you know if the docker image will support Raspberry Pi (i.e. arm architecture)? I have not been successfull in using docker build on the Pi. I've tried building it natively on the Pi and using buildx multiarchitecture from a Linux machine as well as running quickstart.sh on the Pi directly. All have failed for various reasons. I've opened tickets for these issues:

quickstart.sh on Pi
buildx multiarchitecture
Docker Build on Pi

from tsunami-security-scanner.

@frakman1 Unfortunately the initial release of the docker image will not support ARM architecture. The main focus point of the project right now is on Linux servers. Adding support for ARM architecture and other OSes like Windows is relatively low on our priority list and will not have a SLO.

But thanks for opening the issues and adding the data points for the build failures on ARM!

from tsunami-security-scanner.

No problem. I hope you reconsider ARM because it is a low-cost Linux server that is ideally suited for LAN side testing of network devices that traditional x86/arm64 Linux servers on the WAN side can't reach.

I understand Windows would be a low priority but Raspberry Pis are a popular testing platform.

from tsunami-security-scanner.