-
-
Notifications
You must be signed in to change notification settings - Fork 132
orchestrator.py
This document describes the detailed step-by-step process of how the Orchestrator
class works, including the specific methods, classes, and functions used at each step, particularly when it is launched by the Bjorn
application via orchestrator.run()
.
The orchestrator imports several modules, including:
- Standard libraries:
json
,importlib
,time
,logging
,sys
,threading
,datetime
- Custom modules:
NmapVulnScanner
,shared_data
,Logger
- An instance of the
Orchestrator
class is created. - Attributes such as
shared_data
,actions
,standalone_actions
,failed_scans_count
,network_scanner
, andlast_vuln_scan_time
are initialized. - The
load_actions
method is called to load actions from the configuration file. - A semaphore is initialized to limit the number of active threads to 10.
Purpose: Initializes the orchestrator. Key Steps:
- Initializes various attributes including shared data, actions lists, scan counters, and scanners.
- Loads actions from a configuration file.
- Sets up a semaphore for managing concurrent threads.
Purpose: Loads all actions from the actions configuration file. Key Steps:
- Reads the configuration file containing action definitions.
- Iterates through each action and delegates loading to specific methods (
load_scanner
,load_nmap_vuln_scanner
,load_action
).
Purpose: Loads and initializes the network scanner module.
Purpose: Loads the Nmap vulnerability scanner module.
Purpose: Loads a specific action from the configuration file. Key Steps:
- Imports the required module for the action.
- Instantiates the action class and sets necessary attributes.
Purpose: Executes an action on a specified target. Key Steps:
- Checks if the required port for the action is open.
- Handles retry logic for previously successful or failed actions.
- Executes the action and updates the status in shared data based on the result.
Purpose: Executes a standalone action not tied to specific network targets. Key Steps:
- Initializes standalone action data if not present.
- Handles retry logic for successful or failed standalone actions.
- Executes the standalone action and updates the status in shared data.
Purpose: Main loop to continuously execute actions. Key Steps:
- Reads current data from shared data file.
- Iterates over actions and executes them on eligible targets.
- Updates shared data with the results of action executions.
- Initiates network scans if no actions were executed.
- Periodically performs vulnerability scans based on configured intervals.
- Reads the current state of network data from the shared data source to determine the targets for action execution.
- Loops through each predefined action to determine which need to be executed.
- Checks the list of targets and evaluates whether the action should be performed based on the target's status.
- For each target-action combination:
- Checks if the action's port is open.
- Evaluates retry logic based on previous success or failure timestamps and configured retry delays.
- Executes the action and updates the status in shared data.
- Ensures dependent child actions are executed in the correct order.
- Writes changes back to the shared data to ensure the latest state is saved.
- If no actions are executed, sets status to "IDLE".
- Initiates a network scan to discover new targets.
- Enters an idle state if no new targets are found, waiting before retrying.
- Periodically checks if it is time to perform a vulnerability scan based on the configured interval.
- Executes vulnerability scans on alive targets and updates their status accordingly.
The Orchestrator
class is the heuristic AI component responsible for coordinating and executing various network scanning and actions. It manages the loading and execution of actions, handles retries for successful and failed actions, continuously scans for new targets, and ensures actions are executed in a logical order. The orchestrator updates statuses and logs events for maintainability and debugging, ensuring smooth operation within the Bjorn
application framework.