diff --git a/.gitignore b/.gitignore index 1d192c6..721afdb 100644 --- a/.gitignore +++ b/.gitignore @@ -41,3 +41,6 @@ configs/keys/* # Remove the riotpot binary riotpot + +# Remove the local samples +local \ No newline at end of file diff --git a/README.md b/README.md index a4e2524..f789f6f 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,3 @@ -

@@ -6,10 +5,10 @@

- GitHub Actions status - + GitHub Actions status + - +

___ @@ -17,7 +16,7 @@ ___ - [1. Description](#1-description) - [1.1 Architecture](#11-architecture) - [1.2 Noise Filter](#12-Noise-Filter) -- [2. Requirements](#2-requirements) +- [2. Requirements](#2-requirements) - [3. Installation](#3-installation) - [3.1 Local Build](#31-local-build) - [3.2 Containerized Build](#32-containerized-build) @@ -29,66 +28,67 @@ ___ RIoTPot is an interoperable high interaction honeypot, primarily focused on the emulation IoT and OT protocols, although, it is also capable of emulating other services. Alongside, it also supports low and hybrid interaction modes. -Services are loaded in the honeypot in form of plugins and containers making RIoTPot a modular, and very transportable honeypot. The services are loaded at runtime, meaning that the weight of the honeypot will vary on premisses, and the services loaded e.g. HTTP, will only be used when required. As consequence, we highly recommend building your own binary customized to your own needs. Refer to the following section, Installation, for more information. Plugins are locally emulated binaries which mimic the protocol behavior. On the other hand, docker containers of a particular service acts as a sandboxed plugin. - +Services are loaded in the honeypot in form of plugins and containers making RIoTPot a modular, and very transportable honeypot. The services are loaded at runtime, meaning that the weight of the honeypot will vary on premises, and the services loaded e.g. HTTP, will only be used when required. As consequence, we highly recommend building your own binary customized to your own needs. Refer to the following section, Installation, for more information. Plugins are locally emulated binaries which mimic the protocol behavior. On the other hand, docker containers of a particular service acts as a sandboxed plugin. ### 1.1 Architecture -RIoTPot has a modular architecture that facilitates extensability of the honeypot. The honeypot further offers a hybrid-interaction capability where users can choosed the desired interaction levels for the protocols simulated. The image below shows the high/level architecture of RIoTPot. +RIoTPot has a modular architecture that facilitates extensibility of the honeypot. The honeypot further offers a hybrid-interaction capability where users can choose the desired interaction levels for the protocols simulated. The image below shows the high/level architecture of RIoTPot. -![alt text](architecture.jpg "Architecture") +![alt text](assets/architecture.jpg "Architecture") -The architecture contains 6 components. +The architecture contains 6 components. -__RIoTPot core__ +**RIoTPot core** The core of the honeypot consists of the required modules for configuration, administration and orchestration of the container network. -__Configuration & Orchestration__ -The configuration module provides RIoTPot with all the required parameters at startup. This includes the user preferences for specific protocols and profile simulation and the desired interaction level. The orchestration module is responsible for the network management from the core to the high-interaction protocol services simulated on containers. The received attack traffic is forwarded to the respective container that hosts the protocol on which the attack was targeted. Furthermore, the orchestra tor also facilitates the communication to the containers if they are hosted on a cloud-based environment. +**Configuration & Orchestration** +The configuration module provides RIoTPot with all the required parameters at startup. This includes the user preferences for specific protocols and profile simulation and the desired interaction level. The orchestration module is responsible for the network management from the core to the high-interaction protocol services simulated on containers. The received attack traffic is forwarded to the respective container that hosts the protocol on which the attack was targeted. Furthermore, the orchestra tor also facilitates the communication to the containers if they are hosted on a cloud-based environment. -__Attack Capture and Noise Filter__ -The attack capture and noise filter module filters out the suspicious traffic received from Internet-wide scanners like Shodan and Censys. This helps the administrator to concentrate on attacks that are not from benign sources. +**Attack Capture and Noise Filter** +The attack capture and noise filter module filters out the suspicious traffic received from Internet-wide scanners like Shodan and Censys. This helps the administrator to concentrate on attacks that are not from benign sources. -__Hybrid-Interaction (Low and High-Interaction modes)__ -RIoTPot is implemented in Go language \cite{go} and facilitates the modular architecture and development through packages. The packages act as plug-ins that can be added to the honeypot to extend the protocols simulated. RIoTPot offers a hybrid-interaction model with a preference of low- or high-interaction. +**Hybrid-Interaction (Low and High-Interaction modes)** +RIoTPot is implemented in Go language \cite{go} and facilitates the modular architecture and development through packages. The packages act as plug-ins that can be added to the honeypot to extend the protocols simulated. RIoTPot offers a hybrid-interaction model with a preference of low- or high-interaction. The low-interaction is achieved through independent packages, with each package simulating a specific protocol. The high-interaction model is realized with a containers with the protocols simulated as services installed. The containers act as high-interaction modules that offer a full implementation of the protocol. Additional protocol services can be added by integration of containers with desired protocol services. The hybrid-interaction model further allows the user to emulate selective protocols on low or high-interaction levels. For example, the user can choose to have SSH in low-interaction mode and MQTT in high-interaction mode thereby operating in a hybrid-interaction mode. -__Attack Database__ +**Attack Database** The attack database stores all the attack traffic received on the honeypot. The database is setup as an independent module to ensure data availability even if the honeypot crashes on potential large scale attacks. The database is accessible from the low-interaction and high-interaction modules for attack storage. ### 1.2 Noise Filter + The Noise filter module of RIoTPot filters the attacks from internet scanning engines to reduce alert fatigue. -With this feature, attacks are labelled as __*benign*__ when they originate from sources like Shodan. The +With this feature, attacks are labelled as **_benign_** when they originate from sources like Shodan. The list of scanning services filtered by RIoTPot is below: - 1. Shodan (https://www.shodan.io/) - 2. Censys (https://censys.io/) - 3. Project Sonar (https://www.rapid7.com/research/project-sonar/) - 4. LeakIX (https://leakix.net/) - 5. ShadowServer (https://www.shadowserver.org/) - 6. RWTH Aachen (http://researchscan.comsys.rwth-aachen.de/) - 7. Quadmetrics (https://www.quadmetrics.com/) - 8. BinaryEdge (https://www.binaryedge.io/}) - 9. ipip.net (https://en.ipip.net/) - 10. Arbor Observatory (https://www.arbor-observatory.com/) - 11. CriminalIP (https://security.criminalip.com/) - 12. BitSight (https://www.bitsight.com/) - 13. InterneTT (http://www.internettl.org/) - 14. ONYPHE (https://www.onyphe.io/) - 15. Natlas (https://github.com/natlas/natlas) - 16. Net Systems Research (https://www.netsystemsresearch.com/) - 17. Sharashka (https://sharashka.io/data-feeds) - 18. Alpha Strike Labs (https://www.alphastrike.io) - 19. Stretchoid (http://stretchoid.com/) - - Note: the list will be updated on support for additional scanning sources. - -> **Summary:** To summarize, the design of RIoTPot facilitates modularity through packages and containers as plugins. Furthermore, the modular architecture helps in achieving a hybrid-interaction model. +1. Shodan (https://www.shodan.io/) +2. Censys (https://censys.io/) +3. Project Sonar (https://www.rapid7.com/research/project-sonar/) +4. LeakIX (https://leakix.net/) +5. ShadowServer (https://www.shadowserver.org/) +6. RWTH Aachen (http://researchscan.comsys.rwth-aachen.de/) +7. Quadmetrics (https://www.quadmetrics.com/) +8. BinaryEdge (https://www.binaryedge.io/}) +9. ipip.net (https://en.ipip.net/) +10. Arbor Observatory (https://www.arbor-observatory.com/) +11. CriminalIP (https://security.criminalip.com/) +12. BitSight (https://www.bitsight.com/) +13. InterneTT (http://www.internettl.org/) +14. ONYPHE (https://www.onyphe.io/) +15. Natlas (https://github.com/natlas/natlas) +16. Net Systems Research (https://www.netsystemsresearch.com/) +17. Sharashka (https://sharashka.io/data-feeds) +18. Alpha Strike Labs (https://www.alphastrike.io) +19. Stretchoid (http://stretchoid.com/) + +Note: the list will be updated on support for additional scanning sources. + +> **Summary:** To summarize, the design of RIoTPot facilitates modularity through packages and containers as plugins. Furthermore, the modular architecture helps in achieving a hybrid-interaction model. ## 2. Requirements -Make sure that you abide by the following software and platform requirements before running the riotpot, -- Ubuntu 18.04 or higher +Make sure that you abide by the following software and platform requirements before running RIoTPot, + +- Ubuntu 18.04 or higher - gcc 9.3.0 or higher - GNU make 4.2.1 or higher - Go version go1.16.4 or higher @@ -102,7 +102,7 @@ Although one can download the binaries and configuration files containing the se We thrive on the idea of making RIoTPot highly transportable, therefore, in this section one can find multiple methods of installation for diverse environments that fit a broad list of requirements and constrains. -There are multiple ways to run RIoTPot, one can choose to go for local build mode or containerized mode. In local build mode the RIoTPot core runs on host machine and has options to run IoT, OT or other protocols both in local plugins or as a separate containerized service. Running RIoTPot in a virtualized/containerized self-contained network mode using `Docker` is highly reommended. +There are multiple ways to run RIoTPot, one can choose to go for local build mode or containerized mode. In local build mode the RIoTPot core runs on host machine and has options to run IoT, OT or other protocols both in local plugins or as a separate containerized service. Running RIoTPot in a virtualized/containerized self-contained network mode using `Docker` is highly recommended. @@ -114,37 +114,39 @@ Follow the steps to get the RIoTPot project first: $ git clone git@github.com:aau-network-security/riotpot.git # 2. Navigate to the newly created directory with the repository -$ cd riotpot +$ cd RIoTPot ``` + ### 3.1 Local Build -Make sure user meets the dependency requirements before running the RIotPot, specially MongoDB instance, User can follow this [guide for quick MongoDB setup](https://abresting.github.io/posts/2021/MongoDB-QuickSetup/): +Make sure user meets the dependency requirements before running RIoTPot, specially MongoDB instance, User can follow this [guide for quick MongoDB setup](https://abresting.github.io/posts/2021/MongoDB-QuickSetup/): To build RIoTPot locally, follow the steps: ```bash # Running the following command from RIoTPot directory will compile the necessary plugins and binaries # and put it in the standard go path as well as in current directory. -$ make riotpot-build-local +$ make RIoTPot-build-local # Command will run the RIoTPot locally -$ ./riotpot +$ ./RIoTPot ``` -![Local Build](https://github.com/aau-network-security/riotpot/blob/master/internal/media/local_build.gif?raw=true) + +![Local Build](https://github.com/aau-network-security/RIoTPot/blob/master/internal/media/local_build.gif?raw=true) Upon running, user needs to select the mode of interaction, in Low mode, all plugins run locally as binaries, in High mode, the selected services run in separate container, and, in Hybrid mode, mix of Low and High i.e. some services locally and some inside containers. In every mode, there is an option to run the services directly from reading the configuration file located at `config/samples/configuration.yml` -![Config file](https://github.com/aau-network-security/riotpot/blob/master/internal/media/configuration_file.png?raw=true) +![Config file](https://github.com/aau-network-security/RIoTPot/blob/master/internal/media/configuration_file.png?raw=true) -By editing the ``boot_plugins`` tag, services to run as binaries inside can be provided, see ``emulators`` tag in the same configuration file to input allowed service plugins only +By editing the `boot_plugins` tag, services to run as binaries inside can be provided, see `emulators` tag in the same configuration file to input allowed service plugins only -By editing the ``start_images`` tag, services to run inside a container can be provided, see ``images`` tag in the same configuration file to input allowed container images only +By editing the `start_images` tag, services to run inside a container can be provided, see `images` tag in the same configuration file to input allowed container images only -> **Not for Local build**, by editing ``mode`` tag, the RIoTPot running mode can be provided +> **Not for Local build**, by editing `mode` tag, the RIoTPot running mode can be provided -To exit the RIoTPot in it's running state at any time press ``Ctrl + C`` +To exit the RIoTPot in it's running state at any time press `Ctrl + C` ### 3.2 Containerized Build @@ -154,15 +156,16 @@ To build inside containers, follow the steps: ```bash # Assuming user is at root directory of the RIoTPot github repository -$ cd riotpot/deployments +$ cd RIoTPot/deployments # Run the command to enter the interactive mode to choose services to run $ go run interactive_deployer.go ``` -![Containerized Build](https://github.com/aau-network-security/riotpot/blob/master/internal/media/containerized_build.gif?raw=true) +![Containerized Build](https://github.com/aau-network-security/RIoTPot/blob/master/internal/media/containerized_build.gif?raw=true) Upon choosing modes and services correctly, following message will be displayed: + ``` Perfect!, now run the command docker-compose -f docker-compose.yml up -d --build @@ -176,7 +179,7 @@ $ docker-compose -f docker-compose.yml up -d --build ``` To check if the containers are correctly setup, check with the following command and see, -if ``riotpot:development`` and other selected service containers are up and running. +if `RIoTPot:development` and other selected service containers are up and running. ```bash $ docker ps @@ -186,21 +189,21 @@ $ docker ps One can also setup the Containerized RIoTPot through config file located at, `config/samples/configuration.yml` -![Config file](https://github.com/aau-network-security/riotpot/blob/master/internal/media/configuration_file.png?raw=true) +![Config file](https://github.com/aau-network-security/RIoTPot/blob/master/internal/media/configuration_file.png?raw=true) -By editing the ``boot_plugins`` tag, services to run as binaries inside can be provided, see ``emulators`` tag in the same configuration file to input allowed service plugins only +By editing the `boot_plugins` tag, services to run as binaries inside can be provided, see `emulators` tag in the same configuration file to input allowed service plugins only -By editing the ``start_images`` tag, services to run inside a contaianer can be provided, see ``images`` tag in the same configuration file to input allowed container images only +By editing the `start_images` tag, services to run inside a container can be provided, see `images` tag in the same configuration file to input allowed container images only -By editing ``mode`` tag, the RIoTPot running mode can be provided, see ``allowed_modes`` tag in the same configuration file to input allowed modes only +By editing `mode` tag, the RIoTPot running mode can be provided, see `allowed_modes` tag in the same configuration file to input allowed modes only To stop the RIoTPot in Containerized mode use the following command: -``` bash +```bash $ docker-compose down -v -``` +``` -> **NOTE:** Using the *-v* tag will remove all the mounted volumes, i.e. the database used by RIoTPot to store information and the volumes mounted to store logs and binaries collected by the honeypot. Remember to make copies before using the *-v* tag, or skip it altogether. +> **NOTE:** Using the _-v_ tag will remove all the mounted volumes, i.e. the database used by RIoTPot to store information and the volumes mounted to store logs and binaries collected by the honeypot. Remember to make copies before using the _-v_ tag, or skip it altogether. ### 3.3 Via Docker Hub Image @@ -208,16 +211,16 @@ Build the latest release of RIoTPot directly from the image provided in the Dock ```bash # Command will compile the necessary plugins and binaries and put it in the standard go path as well as in current directory. -$ make riotpot-build-local +$ make RIoTPot-build-local # Command will run the RIoTPot locally -$ ./riotpot +$ ./RIoTPot ``` ```bash # Grab and run the latest release of the RIoTPot consumer image # detached from the console with -d. -$ docker run -d riotpot-docker:latest +$ docker run -d RIoTPot-docker:latest ``` ## 4. Documentation @@ -226,12 +229,13 @@ The documentation for RIoTPot can be found in [go.pkg.dev](https://pkg.go.dev/), The most common way of pre-visualizing documentation is by using `godoc`, however, this requires an initial setup of the go project. Find more information in the [godoc page](https://pkg.go.dev/golang.org/x/tools/cmd/godoc). -For simplicity, the RIoTPot `godoc` documentation can be run as a separated local container from the dockerfile `Dockerfile.documentation`. To use the container simply type: +For simplicity, the RIoTPot `godoc` documentation can be run as a separated local container from the Dockerfile `Dockerfile.documentation`. To use the container simply type: ```bash -$ make riotpot-doc +$ make RIoTPot-doc ``` -This will run a container tagged with `riotpot/v1` at `http://localhost:6060/`. The documentation of the package can be accessed directly from [http://localhost:6060/pkg/riotpot/](http://localhost:6060/pkg/riotpot/). + +This will run a container tagged with `RIoTPot/v1` at `http://localhost:6060/`. The documentation of the package can be accessed directly from [http://localhost:6060/pkg/RIoTPot/](http://localhost:6060/pkg/RIoTPot/). ## 5. Easy Access @@ -239,16 +243,17 @@ We previously described how to set up the whole project, both installation and d The following commands will be run using `make` plus the alias of the command. The `Makefile` contains more commands, but this are the most widely useful: -Command|Container Name|Description -:---|:---:|---: -riotpot-up|riotpot:development| Puts up RIoTPot in **development** mode. -riotpot-down|riotpot:development| Puts down RIoTPot. -riotpot-doc|riotpot/v1| Puts up a container with the local documentation. -riotpot-all|riotpot/v1, riotpot| Puts the documentation and RIoTPot **development** mode up. -riotpot-builder|| Builds the binary and the plugins. +| Command | Container Name | Description | +| :-------------- | :-----------------: | ----------------------------------------------------------: | +| RIoTPot-up | RIoTPot:development | Puts up RIoTPot in **development** mode. | +| RIoTPot-down | RIoTPot:development | Puts down RIoTPot. | +| RIoTPot-doc | RIoTPot/v1 | Puts up a container with the local documentation. | +| RIoTPot-all | RIoTPot/v1, RIoTPot | Puts the documentation and RIoTPot **development** mode up. | +| RIoTPot-builder | | Builds the binary and the plugins. | **Example usage:** + ```bash # run a command given its alias from Makefile -$ make riotpot-doc +$ make RIoTPot-doc ``` diff --git a/architecture.jpg b/assets/architecture.jpg similarity index 100% rename from architecture.jpg rename to assets/architecture.jpg diff --git a/build/docker/Dockerfile b/build/docker/Dockerfile index daf5577..c2efc32 100644 --- a/build/docker/Dockerfile +++ b/build/docker/Dockerfile @@ -25,17 +25,23 @@ RUN tar -xzf glider_0.15.0_linux_amd64.tar.gz && cd glider_0.15.0_linux_amd64 && RUN apt-get update && apt-get install -y netcat # Copy everything into the image -# TODO: this can be optimized to copy just the necessary files! -COPY . . +# Copy only the app files in the image +COPY internal internal/ +COPY tools tools/ +COPY pkg pkg/ +COPY cmd cmd/ +COPY configs configs/ +COPY build/docker/entrypoint.sh ./ # Run the command from the Makefile to build all the plugins # and build the project # -- Comment this line when on development if you know you have a ready to go version built -- # Disclaimer: if you comment this line, be 100% sure that the binary can be run on linux -RUN make riotpot-builder +COPY Makefile . +RUN make builder # give permissions to the entrypoint to run the file -RUN chmod +x build/docker/entrypoint.sh +RUN chmod +x ./entrypoint.sh # Run RIoTPot -ENTRYPOINT [ "./build/docker/entrypoint.sh" ] +ENTRYPOINT [ "./entrypoint.sh" ] diff --git a/build/docker/entrypoint.sh b/build/docker/entrypoint.sh index 2df92e5..9e0f73c 100644 --- a/build/docker/entrypoint.sh +++ b/build/docker/entrypoint.sh @@ -1,16 +1,15 @@ #!/bin/sh - -# wait for the database to be up +# Wait for the database to be up if [ $DB_HOST ] then - echo "Waiting for mongodb..." + echo "Waiting for database..." while ! nc -z $DB_HOST $DB_PORT; do sleep 0.1 done - echo "MongoDB started" + echo "database started" fi # run riotpot diff --git a/build/env/.env b/build/env/.env index 9e3aedf..d80c061 100644 --- a/build/env/.env +++ b/build/env/.env @@ -2,5 +2,6 @@ AUTOD=false DB_HOST=mongodb DB_USER=superuser DB_PASS=password -DB_NAME=mongodb -DB_PORT=27017 \ No newline at end of file +DB_NAME=db +DB_PORT=27017 +DB_ENGINE=mongodb \ No newline at end of file diff --git a/configs/samples/profile.yml b/configs/samples/profile.yml index e940998..df78fdf 100644 --- a/configs/samples/profile.yml +++ b/configs/samples/profile.yml @@ -8,9 +8,9 @@ greet: # Keep in mind that the initial message contains some waiting time, # which is helpful in docker images to give time to the database # to be set-up before starting the application! - initial : false + initial: false # Terminal options and configuration terminal: # Color of the terminal path and headers - color: #eb4034 \ No newline at end of file + color: "#eb4034" diff --git a/dataset/sample.pcap b/dataset/sample.pcap deleted file mode 100644 index e69de29..0000000 diff --git a/deployments/docker-compose-template.yml b/deployments/docker-compose-template.yml deleted file mode 100644 index e36d9fb..0000000 --- a/deployments/docker-compose-template.yml +++ /dev/null @@ -1,99 +0,0 @@ -# This Docker Compose file is meant to be used on a development -# environment for testing. -# This environment includes a fake local network, a local database and -# a volume mounted with the code to see changes on the go. -version: "3.8" - -volumes: - postgres_data: - mongodb_data: - -networks: - honeypot: - name: honeypot - ipam: - config: - - subnet: 10.5.0.0/16 - -services: - - # Tcpdump host that stores all the stuff that happens - # in the network - tcpdump: - image: kaazing/tcpdump - network_mode: "host" - volumes: - - ../tcpdump:/tcpdump - # Run tcdump in autorotating mode, with gzip compression - # The files will be rotated every 24h or 500MB and named - # after the timestamp when the file is created. - command: [ - "-z", "gzip", # compress to gzip - "-G", "86400", # 24h in seconds - "-C", "500", # maximum file size - "-W", "10", # ignored, only affects the name - "-v", # verbose - "-i", "any", # any interface - "-w", "tcpdump/trace_%Y_%m_%d_%H_%M_%S.pcap" # trace_.pcap - ] - - # RIoTPot is the container for the central node - riotpot: - build: - context: .. - dockerfile: ./build/docker/Dockerfile - image: riotpot:development - #command: - restart: always - ports: - # Ports under 60 might see errors when unquoted - # https://stackoverflow.com/questions/58810789/quotes-on-docker-compose-yml-ports-make-any-difference - - "7:7" - # - "22:22" - - "23:23" - - "502:502" - - "8080:8080" - - "1883:1883" - - "5683:5683" - - "27017:27017" - env_file: - - ../build/env/.env - networks: - honeypot: - # give a static IP to the honeypot so we can find it - # and attack it seamlessly - ipv4_address: 10.5.0.6 - - postgres: - image: postgres:latest - environment: - - POSTGRES_USER=superuser - - POSTGRES_PASSWORD=password - - POSTGRES_DB=postgres - volumes: - - postgres_data:/var/lib/postgresql/data/ - networks: - honeypot: - - mongodb: - image: mongo - container_name: mongodb - environment: - MONGO_INITDB_ROOT_USERNAME: superuser - MONGO_INITDB_ROOT_PASSWORD: password - MONGO_INITDB_DATABASE: mongodb - volumes: - - mongodb_data:/data/db/ - networks: - honeypot: - - attacker: - build: - context: .. - dockerfile: ./build/docker/Dockerfile.attacker - stdin_open: true # docker -i - tty: true # docker -t - volumes: - - ../test/pkg/services/mqtt:/riotpot/ - networks: - honeypot: \ No newline at end of file diff --git a/deployments/docker-compose.prod.yml b/deployments/docker-compose.prod.yml index 1e0a5da..773902a 100644 --- a/deployments/docker-compose.prod.yml +++ b/deployments/docker-compose.prod.yml @@ -36,6 +36,7 @@ services: - "7:7" - "22:22" - "23:23" + #- "80:80" - "502:502" - "8080:8080" - "1883:1883" diff --git a/deployments/docker-compose.yml b/deployments/docker-compose.yml index e36d9fb..9c6c96f 100644 --- a/deployments/docker-compose.yml +++ b/deployments/docker-compose.yml @@ -2,19 +2,6 @@ # environment for testing. # This environment includes a fake local network, a local database and # a volume mounted with the code to see changes on the go. -version: "3.8" - -volumes: - postgres_data: - mongodb_data: - -networks: - honeypot: - name: honeypot - ipam: - config: - - subnet: 10.5.0.0/16 - services: # Tcpdump host that stores all the stuff that happens @@ -39,11 +26,11 @@ services: # RIoTPot is the container for the central node riotpot: + container_name: riotpot build: context: .. dockerfile: ./build/docker/Dockerfile image: riotpot:development - #command: restart: always ports: # Ports under 60 might see errors when unquoted @@ -52,6 +39,7 @@ services: # - "22:22" - "23:23" - "502:502" + #- "80:80" - "8080:8080" - "1883:1883" - "5683:5683" @@ -64,24 +52,13 @@ services: # and attack it seamlessly ipv4_address: 10.5.0.6 - postgres: - image: postgres:latest - environment: - - POSTGRES_USER=superuser - - POSTGRES_PASSWORD=password - - POSTGRES_DB=postgres - volumes: - - postgres_data:/var/lib/postgresql/data/ - networks: - honeypot: - mongodb: image: mongo container_name: mongodb environment: - MONGO_INITDB_ROOT_USERNAME: superuser - MONGO_INITDB_ROOT_PASSWORD: password - MONGO_INITDB_DATABASE: mongodb + MONGO_INITDB_ROOT_USERNAME: ${DB_USER:-superuser} + MONGO_INITDB_ROOT_PASSWORD: ${DB_PASS:-password} + MONGO_INITDB_DATABASE: ${DB_NAME:-db} volumes: - mongodb_data:/data/db/ networks: @@ -96,4 +73,15 @@ services: volumes: - ../test/pkg/services/mqtt:/riotpot/ networks: - honeypot: \ No newline at end of file + honeypot: + +volumes: + postgres_data: + mongodb_data: + +networks: + honeypot: + name: honeypot + ipam: + config: + - subnet: 10.5.0.0/16 \ No newline at end of file