🕸️With great power comes great responsibility
Part for those who know their stuff ...not like me !
Well, we've just had a quick look at some of the commands available for interacting with containers, images and tools, but I've made sure that the project as a whole is manageable and customizable according to the user's needs.
.env
To do this, first find the environment file that interacts with docker-compose variables.
exemple:
In this case we interact with the Osint service, but it's the same thing for the others services.
Usage:
If you want to switch from one variable to another, especially _NET _RUN variables, you need to comment out the unwanted variable(s) with a #. You need both a _NET and a _RUN variable.
OSINT_APP="docker-default"
OSINT_SEC=./configuration/profiles/default.json
OSINT_RAM="3g"
OSINT_CPU="0.5"
OSINT_NET="bridge"
#OSINT_NET="host"
#OSINT_NET="none"
OSINT_RUN="runsc"
#OSINT_RUN="runc"OSINT_APP="docker-default"
As previously explained, we use isolation reinforcement technologies, and in this case this configuration line specifies the profile to be used by apparmor, as we explained, given that we work in pentest environments, it is difficult to manage some of the profiles without hindering proper operation in a future release, this management will be much finer and more optimal.
OSINT_SEC=./configuration/profiles/default.json
This is the seccomp profile part, which blocks 44 syscalls between the container and the host.
As for apparmor, we will improve this service to make it even more efficient and accurate.
DISCLAIMER:
Any future improvements will obviously only be made in conjunction with the tools available, so if custom tools or tools not included in the project are to be implemented, I'd like you to consider the problems that could arise in connection with these two profiles, however we will try to be available for the integration of this tool and therefore the management of security profiles and where the default profile will still be available.
OSINT_RAM="3g"
This variable allows you to define the amount of ram you want to allocate to your container, if you don't specify anything docker tends to take ram, in a state where the container isn't processing anything, usage will be stable, however as soon as a processing is launched, docker won't hesitate to take all the ram, available if you don't define any limits, it will take all it can.
OSINT_CPU="0.5"
This variable represents the processing capacity (CPU) allocated to the Docker container running the OSINT application. In this example, the container will be configured to use 0.5 units of processing capacity.
OSINT_NET="bridge"OROSINT_NET="host"OROSINT_NET="none"
"bridge":
This variable represents the network mode used by the Docker container. Bridge" mode creates an isolated network for the container, allowing it to communicate with other containers on the same bridge network.
"host":
The Docker container will use the "host" network mode, allowing it to use the host network directly
Clarification:
This option is very interesting in that it is the wireless service indeed if you need to carry out an attack on the wireless network, and you want to be able to use your external network card allowing packet injection you will have to use this option and therefore comment on the others.
"none":
The Docker container will be configured to have no network access at all. This means it will be isolated and unable to communicate with the host network or with other containers.
OSINT_RUN="runsc"OROSINT_RUN="runc"
"runsc":
Using gVisor and its runsc runtime avoids excessive interaction with the host. By running containers in this lightweight sandbox, gVisor provides an additional layer of security by limiting direct access to the host's core. This helps prevent potential attacks and strengthens the isolation between containers and the host.
"runc":
Runc is the basic docker runtime that enables services to be lifted, but it doesn't provide any real "isolation" of the container and can therefore endanger your host. That's why, as I said earlier, the best thing to do is to use cascading to make our host as secure as possible, and that's where I've tried to bring in the seccomp and apparmor profiles (still to be improved).
Clarification:
if you switch the network management to "host", you'll have to take into account that gvisor's "runsc" won't work, as this operation will be incompatible with its operation, which is logical. However, for some containers you'll have to map the network in this way, so you'll also have to, In this case, you'll reduce the isolation of your container(s), relying solely on the seccomp and apparmor profiles, but if, for example, you want to use your external network card for the wireless container, you'll have no choice. A release to improve this situation has already been taken into account.
Dockerfile & Scripts
I've written a number of fairly basic Dockerfiles, allowing you to install tools locally and build your docker images directly, this is the "build" function.
However, to avoid having to interact directly with the dockerfile, I've written some basic scripts that call up the tools to be installed, in this case I'm using the Kali metapackages.
I'm leaving this generic configuration in place to allow as many people as possible to have as many tools as possible without being too excessive, but since the dockerfiles refer to the scripts, anyone wanting to install custom or specific tools can do so without any problems, just by modifying the scripts.
Last updated