Conversation
Added optional CRS update logic and improved logging for background processes.
Added initial README.md for CRS Auto Update script with planned features and assumptions.
Removed comment about Sidekick code generation.
Added logging and process management for Apache and Filebeat.
Updated the script to enforce SHA256 checksum format and added timeout options for curl and wget commands.
Updated filebeat configuration path to absolute path.
Updated Dockerfile to include TARGETARCH argument and modified file paths.
Added headers to prevent HTTP_PROXY leakage and set authentication headers.
Add a test script to verify the existence of bundled CRS paths and includes in the Docker container.
This script tests the successful update of the CRS within a Docker container, ensuring that the configuration remains valid and usable after the update.
Refactor test script for CRS update to use unique identifiers and validate fixture installation.
This script tests the behavior of the CRS update when the updater is disabled, ensuring that the status reflects 'skipped' and that the bundled CRS files remain intact.
Add a test script to verify fallback behavior during CRS update download failure.
This script tests the fallback behavior of the CRS updater when the SHA256 checksum does not match the expected value. It verifies that the bundled CRS remains unchanged and that the correct status is recorded.
This script tests the behavior of the CRS update process when a lock is held by another instance. It verifies that the update is skipped and the bundled CRS remains intact.
Refactor Docker exec commands for better readability and maintainability. Update status checks to use fixed-string checks for improved reliability.
Refactor CRS update script for better readability and functionality.
|
Hi @adrianwinckles, I wanted to clarify and apologize for a misunderstanding on my side. In my earlier work (PRs 8–11) I implemented personas and chameleon behavior inside a single container by swapping files and reloading Apache. After re‑reading the GSoC ideas and our Slack conversation, I now realize you were aiming for a container‑swapping chameleon design (separate persona containers that are swapped based on external stimuli like Shodan), not just in‑container persona switching. In this PR I’ve started to realign with that direction by: Introducing a personas/ structure and moving the existing honeypot into personas/generic/. Would appreciate your feedback on whether this is now in line with what you had in mind. |
1 participant
Title: Refactor persona framework toward container‑swapping chameleon design
Hi @adrianwinckles,
Earlier I misunderstood the chameleon idea and implemented personas and swapping inside a single container (PRs 8–11). After re‑reading the GSoC ideas and our Slack discussion, I now understand you were aiming for swapping Docker containers based on external stimuli rather than in‑container file swapping. Sorry for the confusion on my side.
This PR starts to realign the implementation with that container‑based design while keeping behavior as close as possible to the current honeypot.
Changes in this PR
Created a top‑level personas/ directory to support multiple honeypot personas.
Moved the existing honeypot implementation into personas/generic/ (no intentional functional changes to the generic behavior).
Updated the Dockerfile to include persona assets in the image.
Updated docker-compose.yml so that:
modsec_crs remains the ModSecurity WAF front end.
Persona containers (persona-generic, and placeholders for persona-wordpress / persona-drupal) are defined and share the same network.
Added scripts/swap_persona.sh, a small helper script that:
Stops any currently running persona container.
Starts the requested persona container.
Is intended to be called by the Shodan watcher or manually to perform an actual container‑level persona swap.
Kept all existing CRS auto‑update logic, ModSecurity rules, and tests intact.
What this PR does not do yet
It does not add new behavior or fingerprints beyond the existing generic persona.
It does not yet wire Shodan detection directly into the new container‑swap script (that will be done in a follow‑up PR).
It does not change any CRS 4.1 / plugin behavior.
Next steps (planned follow‑up PRs)
Add realistic backend containers and fingerprints for WordPress and Drupal personas, using the existing persona assets.
Wire shodan_watcher.py to call scripts/swap_persona.sh so Shodan tagging triggers real container swaps.
Update and add integration tests to validate:
Persona loading at the container level.
Live persona swaps via the swap script.
Robust fallback behavior and Shodan‑disabled mode.
This PR is meant as the infrastructure step toward the container‑swapping chameleon variant you described. I’ll update/rework my more recent persona PRs to build on this direction instead of the earlier in‑container approach.