Target & IP Processing
Relevant source files
The following files were used as context for generating this wiki page:
Target and IP Processing is a foundational component of the OWASP Nettacker framework, responsible for ingesting, validating, and expanding various target definitions into actionable scan items. This system allows users to define targets using multiple formats, including single IP addresses, domain names, CIDR blocks, and IP ranges, ensuring flexibility for both targeted assessments and large-scale network mapping.
The processing logic is primarily contained within the nettacker/core/ directory, specifically leveraging specialized modules for IP address manipulation and target set calculation. These components ensure that duplicate targets are removed and complex ranges are correctly expanded before the scanning engine initiates multi-threaded attacks.
Sources: nettacker/core/readme.md, README.md:31-31
Target Input Methods
Nettacker supports several input vectors for defining targets. Users can provide targets directly via the CLI, through a comma-separated list, or by importing them from external files.
| Input Type | CLI Flag / Attribute | Description |
|---|---|---|
| Single Target | -i / --targets | Accepts a single IPv4, IPv6, Domain, or URL. |
| Target List | -l / --targets-list | Accepts a comma-separated list of multiple targets. |
| File Input | -L / --targets-from-file | Reads targets line-by-line from a specified text file. |
| IP Range | Range Format | Supports hyphenated ranges (e.g., 192.168.1.1-192.168.1.100). |
| CIDR Block | CIDR Format | Supports standard CIDR notation (e.g., 10.0.0.0/24). |
Sources: README.md:31-31, nettacker/web/static/index.html:150-155, nettacker/locale/en.yaml:104-106
Target Validation and Typing
Before processing, the system categorizes targets into specific types to determine the appropriate handling logic. Recognized types include:
SINGLE_IPv4: A standard individual IPv4 address.RANGE_IPv4: A range of IPv4 addresses.CIDR_IPv4: An IPv4 network defined by a prefix.DOMAIN: A standard domain name.HTTP: A full URL (e.g.,https://example.com).
Sources: nettacker/locale/ar.yaml:189-191, nettacker/locale/fa.yaml:166-168
Target Expansion and Calculation
The core logic for transforming user input into a final list of targets resides in nettacker/core/targets.py and nettacker/core/ip.py. This process involves resolving domain names, expanding CIDR blocks into individual IP addresses, and calculating every IP within a provided range.
IP Address Logic
The nettacker/core/ip.py module contains specialized functions for IPv4 and IPv6 handling. This includes checking if a host is up before scanning (if the --ping-before-scan flag is set) and ensuring that IP inputs conform to standard networking rules.
Sources: nettacker/core/readme.md, nettacker/locale/en.yaml:83-83
The Expansion Flow
When a scan is initiated, the target processing system performs the following sequence:
The diagram above shows how various input formats are normalized and consolidated into a unique set of targets.
Sources: nettacker/core/targets.py, nettacker/core/ip.py, README.md:31-31
Scan Orchestration
Once targets are processed, they are passed to the scanning engine. The nettacker/core/scan_targets.py module manages the distribution of these targets across hardware resources.
Parallelism and Resource Management
Nettacker employs a multi-tiered threading model to optimize performance:
- Host Threads: Number of hosts scanned in parallel (default 30).
- Connection Threads: Number of concurrent connections per host (default 100).
The system also performs "Target Regrouping" based on available hardware resources to prevent system exhaustion during large-scale scans.
Sources: nettacker/web/static/index.html:190-205, nettacker/locale/en.yaml:52-52, nettacker/locale/en.yaml:116-117
Pre-Scan Operations
If enabled, the system performs a service discovery or "ping" check before attempting full module execution.
- Ping Check: If
--ping-before-scanis used, targets that do not respond to ICMP/ping are skipped to save time. - Deduplication: The engine automatically skips duplicate targets where subdomains or domains resolve to the same IP address already included in a range.
Sources: nettacker/locale/ja.yaml:94-95, nettacker/locale/ja.yaml:45-46
Target Discovery Features
In addition to explicit target definitions, Nettacker includes modules that dynamically discover new targets during the reconnaissance phase.
Subdomain Enumeration
When the -d or --subdomains flag is used, the engine attempts to find all subdomains associated with a target domain. These newly discovered subdomains are then added to the target list for subsequent module execution.
Sources: README.md:100-101, nettacker/locale/en.yaml:118-118
Comparison and Drift Detection
Nettacker uses its internal database (nettacker.db) to store results. The target processing system can compare a current scan against a previous scan_id to identify "Drift"—newly discovered hosts or services that were not present in previous assessments.
| Change Type | Description |
|---|---|
| New Targets | Hosts or IPs found in the current scan but missing in the old one. |
| Missing Targets | Hosts or IPs found in the old scan that are no longer responsive. |
Sources: nettacker/web/static/report/compare_report.html:170-185, README.md:38-40
Summary of Core Files
| File Path | Primary Responsibility |
|---|---|
nettacker/core/ip.py | IPv4/IPv6 validation, range expansion, and ping checks. |
nettacker/core/targets.py | Calculation, deduplication, and counting of final target sets. |
nettacker/core/scan_targets.py | Management of multi-processing and distribution of targets to modules. |
nettacker/core/utility.py | Supporting functions for target string manipulation. |
nettacker/core/readme.md | Overview of core module relationships. |
Sources: nettacker/core/readme.md, nettacker/core/targets.py, nettacker/core/ip.py