Slips v1.1.19

.github/workflows/integration-tests.yml

@@ -55,7 +55,7 @@ jobs:
 
       - name: Upload Artifacts
         if: always()
-        uses: actions/upload-artifact@v5
+        uses: actions/upload-artifact@v6
         with:
           # Replaces slashes with underscores for valid artifact naming
           name: ${{ github.run_id }}-${{ strategy.job-index }}-integration-output

.github/workflows/unit-tests.yml

@@ -56,7 +56,7 @@ jobs:
 
       - name: Upload Artifacts
         if: always()
-        uses: actions/upload-artifact@v5
+        uses: actions/upload-artifact@v6
         with:
           name: test_slips-output-${{ strategy.job-index }}
           path: |

.secrets.baseline

@@ -149,7 +149,7 @@
         "filename": "config/slips.yaml",
         "hashed_secret": "4cac50cee3ad8e462728e711eac3e670753d5016",
         "is_verified": false,
-        "line_number": 268
+        "line_number": 278
       }
     ],
     "dataset/test14-malicious-zeek-dir/http.log": [
@@ -7185,5 +7185,5 @@
       }
     ]
   },
-  "generated_at": "2026-03-02T22:46:58Z"
+  "generated_at": "2026-03-27T14:25:16Z"
 }

AGENTS.md

@@ -0,0 +1,42 @@
+# AGENTS.md
+
+## Project overview
+- Entry point: `slips.py` (starts the main process, spawns modules, runs in interactive/daemon modes).
+- Core framework code lives in `slips/`, `slips_files/`, and `managers/`.
+- Detection/analysis modules are in `modules/` (implement the `IModule` interface).
+- Configuration is in `config/` (main config: `config/slips.yaml`).
+- Tests live under `tests/` (unit + integration suites).
+- Documentation is in `docs/` (see `docs/contributing.md` for contribution workflow, branching, and PR expectations).
+- UIs/tools: `SlipsWeb/`, `webinterface/`, `webinterface.sh`, and `kalipso.sh`.
+
+## Build and test commands
+- Run locally (no build step):
+  - `./slips.py -e 1 -f dataset/test7-malicious.pcap -o output_dir`
+- Build the Docker image (from `docs/installation.md`):
+  - `docker build --no-cache -t slips -f docker/Dockerfile .`
+  - If build networking fails: `docker build --network=host --no-cache -t slips -f docker/Dockerfile .`
+- Run the Docker image:
+  - `docker run -it --rm --net=host slips`
+
+## Code style guidelines
+- Python formatting is enforced via pre-commit:
+  - Black with `--line-length 79` (see `.pre-commit-config.yaml`).
+  - Ruff is used for linting and autofixes.
+- Keep docstrings at the top of files where present (pre-commit `check-docstring-first`).
+- Maintain clean whitespace (no trailing whitespace, final newline).
+- Follow existing module patterns (`IModule` in `slips_files/common/abstracts/module.py`).
+
+## Testing instructions
+- The canonical test runner is `tests/run_all_tests.sh` (runs unit tests then integration tests).
+- Equivalent manual sequence (from `tests/run_all_tests.sh`):
+  - `./slips.py -cc`
+  - `printf "0" | ./slips.py -k`
+  - `python3 -m pytest tests/ --ignore="tests/integration_tests" -n 7 -p no:warnings -vvvv -s`
+  - `python3 tests/destrctor.py`
+  - `./slips.py -cc`
+  - `printf "0" | ./slips.py -k`
+  - `python3 -m pytest -s tests/integration_tests/test_portscans.py -p no:warnings -vv`
+  - `python3 -m pytest -s tests/integration_tests/test_dataset.py -p no:warnings -vv`
+  - `python3 -m pytest -s tests/integration_tests/test_config_files.py -p no:warnings -vv`
+  - `printf "0" | ./slips.py -k`
+  - `./slips.py -cc`

CHANGELOG.md

@@ -1,3 +1,11 @@
+1.1.19 (Mar 31st, 2026)
+
+* Add SSH bruteforce detection based on Zeek SSH, software, and notice logs.
+* Improve performance under high-throughput traffic with parallel evidence handling, profiler/input optimizations.
+* Fix issues while slips is shutting down.
+* Add optional performance plots and CSV metrics for latency, throughput, and resource usage.
+* Fix skipped first-flow processing and reduce shutdown race conditions on small files and PCAPs.
+
 1.1.18 (Mar 3rd, 2026)
 
 * Add the HTTPS anomaly detection module with adaptive baselines, confidence scoring, and detailed evidence reasons.

README.md

@@ -1,5 +1,5 @@
 <h1 align="center">
-Slips v1.1.18
+Slips v1.1.19
 </h1>
 
 

VERSION

@@ -1 +1 @@
-1.1.18
+1.1.19

config/slips.yaml

@@ -163,6 +163,16 @@ parameters:
   # client_ips : [10.0.0.1, 11.0.0.0/24]
   client_ips: []
 
+#############################
+Debug:
+  # Generate latency, throughput, and other performance related CSV files and plots in output/performance_plots/ for debugging
+  # When enabled, Slips records extra per-flow/per-minute performance data from
+  # input, profiler workers, and evidence handling, then generates summary plots
+  # during shutdown. Keep this disabled for normal runs because it adds extra
+  # bookkeeping and disk writes.
+  #  available options are true/false
+  generate_performance_plots: false
+
 #############################
 detection:
 
@@ -215,6 +225,12 @@ flowmldetection:
   # 'Malicious' data in order for the test to work.
   mode: test
 
+#############################
+bruteforcing:
+  # Minimum number of SSH attempts from one source to one destination
+  # before Slips considers it brute forcing.
+  ssh_attempt_threshold: 9
+
 #############################
 anomaly_detection_https:
   # Number of initial hours used to train the baseline model assuming benign traffic.

dataset/test19-malicious-ssh/README.md

@@ -0,0 +1,5 @@
+## SSH Bruteforce
+Using nmap to bruteforce SSH with 1 user and 40 passwords in port 902/TCP with SSH.
+
+Command
+`nmap -p 902 --script ssh-brute --script-args userdb=users.lst,passdb=pass.lst,ssh-brute.timeout=4s 147.32.80.37 -sV`

docs/bruteforcing.md

@@ -0,0 +1,120 @@
+# Bruteforcing Module
+
+The `Bruteforcing` module detects SSH bruteforcing by combining repeated SSH sessions, Zeek SSH metadata, client software banners, and Zeek notice confirmations.
+
+This module is loaded automatically by Slips like the rest of the modules in `modules/`, unless it is explicitly disabled in `config/slips.yaml`.
+
+## Inputs
+
+The module subscribes to the following Slips channels:
+
+- `new_ssh`
+- `new_software`
+- `new_notice`
+- `tw_closed`
+
+These channels are populated from Zeek logs:
+
+- `ssh.log`
+- `software.log`
+- `notice.log`
+
+## What It Detects
+
+The module tracks repeated SSH activity from the same source IP to the same destination IP and destination port inside the same time window.
+
+It uses the following inputs:
+
+- `ssh.log` to count repeated SSH sessions and authentication attempts
+- `software.log` to extract the `SSH::CLIENT` banner and identify likely automation libraries such as `libssh`, `libssh2`, `paramiko`, `hydra`, `medusa`, or `ncrack`
+- `notice.log` to consume Zeek `SSH::Password_Guessing` confirmations
+
+## Detection Logic
+
+### Counting Attempts
+
+For each SSH flow, the module first checks the Zeek SSH authentication outcome:
+
+- If `auth_success` is `true` or `T`, the flow is ignored for bruteforcing.
+- If `auth_attempts` is greater than `0`, that value is added to the bruteforce campaign counter.
+- If `auth_attempts` is `0` or missing, but the SSH session is not marked successful, the module counts the session as one suspected password attempt.
+
+The last rule is important for datasets where Zeek records repeated SSH handshakes without recording explicit authentication attempts, such as the `malicious-ssh-bruteforce.pcap` sample.
+
+### Threshold and Reporting
+
+The default SSH bruteforcing threshold is `9` attempts.
+
+After the threshold is reached, the module does not alert on every new attempt. Instead, it uses sparse bucketed reporting so alerts become less frequent over time but never completely stop. With the default threshold, the alert points are:
+
+- 9
+- 10
+- 12
+- 16
+- 24
+- 40
+- ...
+
+### Confidence
+
+The evidence threat level is `medium`.
+
+Confidence grows with the number of attempted passwords:
+
+- first bruteforcing evidence starts at the configured threshold
+- full confidence is reached at `30` attempts
+- suspicious SSH client banners add a small confidence bonus
+- a Zeek `SSH::Password_Guessing` notice acts as confirmation and promotes confidence using Zeek's confirmed connection count
+
+## Evidence Produced
+
+The module emits `PASSWORD_GUESSING` evidence with:
+
+- source attacker IP
+- destination victim IP when available
+- TCP destination port
+- time window
+- accumulated UIDs
+- threat level `medium`
+- confidence based on the number of attempts and confirmation data
+
+Example description:
+
+```text
+SSH bruteforcing from 147.32.80.40 to 147.32.80.37 on SSH 902/tcp. Attempts observed: 24. Client banner: libssh libssh2_1.11.0 from software.log. Confidence: 0.89. by Slips
+```
+
+## Zeek Confirmation
+
+If Zeek raises `SSH::Password_Guessing` in `notice.log`, the module:
+
+- emits an evidence immediately based on the notice
+- stores the notice as confirmation for later bruteforcing evidence
+- uses the confirmed connection count from the Zeek notice to increase confidence
+
+If Zeek does not generate `notice.log` for SSH password guessing, the module still detects bruteforcing from `ssh.log` and `software.log`.
+
+## Configuration
+
+The module currently exposes:
+
+```yaml
+bruteforcing:
+  ssh_attempt_threshold: 9
+```
+
+This value is read from `config/slips.yaml`.
+
+## Relationship With Flow Alerts
+
+SSH bruteforcing is now handled by the `Bruteforcing` module.
+
+The `Flow Alerts` module still handles:
+
+- successful SSH detections
+- Zeek port-scan notices
+- certificate alerts
+- DNS and connection heuristics
+- SMTP bruteforce and the rest of the single-flow detections
+
+It no longer owns SSH password guessing detection.

docs/contributing.md

@@ -167,6 +167,14 @@ Once all modules are done processing, EvidenceHandler is killed by the Process m
 - It runs the unit tests first, then the integration tests.
 - Please get familiar with pytest first https://docs.pytest.org/en/stable/how-to/output.html
 
+### What does `generate_performance_plots` do?
+
+- `Debug.generate_performance_plots` in [config/slips.yaml](config/slips.yaml) is a developer-only debugging switch for performance investigations.
+- When it is `true`, Slips writes extra CSVs under `output/performance_plots/csv/`, including alert latency (`latency.csv`), profiler worker latency (`profiler_worker_*_latency.csv`), and throughput (`flows_per_minute.csv`).
+- On shutdown, the process manager turns those CSVs into plots and metrics under `output/performance_plots/` and `output/metrics.txt`.
+- Leave it `false` for normal development and production-style runs. Enabling it adds Redis bookkeeping, file writes, and plot-generation work that are only useful when diagnosing throughput or latency behavior.
+- The plots shown in [docs/immune/stress_testing.md](docs/immune/stress_testing.md) were generated with this parameter enabled.
+
 ### Where and how do we get the GW info?
 
 Using one of these 3 ways

docs/detection_modules.md

@@ -95,7 +95,12 @@ tr:nth-child(even) {
   </tr>
   <tr>
     <td>Flow Alerts</td>
-    <td>Finds malicious behaviours by analyzing only one flow. Now detects: self-signed certificates, TLS certificates which validation failed, vertical port scans detected by Zeek (contrary to detected by Slips), horizontal port scans detected by Zeek (contrary to detected by Slips), password guessing in SSH as detected by Zeek, long connection, successful ssh</td>
+    <td>Finds malicious behaviours by analyzing one flow at a time. It detects self-signed certificates, invalid TLS certificates, Zeek vertical and horizontal port-scan notices, long connections, successful SSH, DNS and connection heuristics, SMTP bruteforce, and related per-flow behaviours.</td>
+    <td>✅</td>
+  </tr>
+  <tr>
+    <td>Bruteforcing</td>
+    <td>Detects SSH bruteforcing from repeated SSH sessions, SSH authentication metadata, client banners from software.log, and Zeek SSH password-guessing notices.</td>
     <td>✅</td>
   </tr>
   <tr>
@@ -126,6 +131,22 @@ tr:nth-child(even) {
 
 </table>
 
+## Bruteforcing Module
+
+The `Bruteforcing` module is responsible for SSH bruteforcing detection.
+
+It consumes:
+
+- `ssh.log`
+- `software.log`
+- `notice.log`
+
+It correlates repeated SSH sessions by source IP, destination IP, destination port, and time window. It starts alerting at `9` attempts by default, reports sparsely as the count grows, uses the SSH client banner to adjust confidence, and uses Zeek `SSH::Password_Guessing` notices as confirmation.
+
+For the full design and configuration details, see:
+
+- [Bruteforcing Module](bruteforcing.md)
+
 ## HTTPS Anomaly Detection Module
 
 For the full technical description of the HTTPS anomaly detector (features, training, adaptation, z-score logic, evidence format, and configuration), see:

docs/features.md

@@ -21,7 +21,7 @@ The detection techniques are:
 - Malicious JA3 hashes
 - Connections to port 0
 - Multiple reconnection attempts
-- Alerts from Zeek: Self-signed certs, invalid certs, port-scans and address scans, and password guessing
+- Alerts from Zeek: Self-signed certs, invalid certs, port-scans and address scans
 - DGA
 - Connection to multiple ports
 - Malicious SSL certificates
@@ -507,7 +507,12 @@ tr:nth-child(even) {
   </tr>
   <tr>
     <td>flowalerts</td>
-    <td>Finds malicious behaviours by analyzing only one flow. Now detects: self-signed certificates, TLS certificates which validation failed, vertical port scans detected by Zeek (contrary to detected by Slips), horizontal port scans detected by Zeek (contrary to detected by Slips), password guessing in SSH as detected by Zeek, long connection, successful ssh</td>
+    <td>Finds malicious behaviours by analyzing one flow at a time. It detects self-signed certificates, invalid TLS certificates, Zeek vertical and horizontal port-scan notices, long connections, successful SSH, DNS and connection heuristics, SMTP bruteforce, and related per-flow behaviours.</td>
+    <td>✅</td>
+  </tr>
+  <tr>
+    <td>bruteforcing</td>
+    <td>Detects SSH bruteforcing from repeated SSH sessions, SSH authentication metadata, client banners from software.log, and Zeek SSH password-guessing notices.</td>
     <td>✅</td>
   </tr>
   <tr>

docs/flowalerts.md

@@ -13,7 +13,7 @@ The detection techniques are:
 - Malicious JA3 hashes
 - Connections to port 0
 - Multiple reconnection attempts
-- Alerts from Zeek: Self-signed certs, invalid certs, port-scans and address scans, and password guessing
+- Alerts from Zeek: Self-signed certs, invalid certs, port-scans and address scans
 - DGA
 - Connection to multiple ports
 - Malicious SSL certificates
@@ -184,9 +184,7 @@ the same destination IP on the same destination port.
 ## Zeek alerts
 
 By default, Slips depends on Zeek for detecting different behaviours, for example
-Self-signed certs, invalid certs, port-scans, address scans, and password guessing.
-
-Password guessing is detected by zeek when 30 failed ssh logins happen over 30 mins.
+Self-signed certs, invalid certs, port-scans, and address scans.
 
 Some scans are also detected by Slips independently of Zeek, like ICMP sweeps and vertical/horizontal portscans.
 Check
@@ -197,11 +195,13 @@ section for more info
 
 Slips alerts when 3+ invalid SMTP login attempts occurs within 10s
 
-## Password Guessing
+## SSH Bruteforcing
+
+SSH bruteforcing is documented in the dedicated `Bruteforcing` module page:
+
+- [Bruteforcing Module](bruteforcing.md)
 
-Password guessing is detected using 2 ethods in slips
-1. by Zeek engine. when 30 failed ssh logins happen over 30 mins.
-2. By slips. when 20 failed ssh logins happen over 1 tiemwindow.
+The `Flow Alerts` module still detects successful SSH sessions, but SSH password guessing is no longer owned by `Flow Alerts`.
 
 ## DGA
 

docs/immune/Immune.md

@@ -15,6 +15,7 @@ This is the main guide to the documentation related to the changes done to Slips
 - [Testing](https://stratospherelinuxips.readthedocs.io/en/develop/immune/testing.html)
 - [LLM Research and Selection](https://stratospherelinuxips.readthedocs.io/en/develop/immune/research_and_selection_of_llm_candidates.html)
 - [LLM RPI Performance](https://stratospherelinuxips.readthedocs.io/en/develop/immune/research_rpi_llm_performance.html)
+- [Stress Testing](https://stratospherelinuxips.readthedocs.io/en/develop/immune/stress_testing.html)
 
 ### Security & Network Configuration