One of the primary advantages of S4E On-Prem is the ability to scan assets that are not reachable from the public internet. Since the platform runs inside your network, it has direct access to internal IP ranges, private DNS zones, and web applications behind firewalls.

Supported Asset Types

S4E On-Prem can scan the following internal asset types:

Adding Internal Assets

Via the Web Interface

1. Navigate to Assets in the left sidebar.
2. Click Add Asset.
3. Enter the internal hostname, IP address, or CIDR range.
4. Select the asset group (or create a new one).
5. Click Save.

Via the API

curl -X POST 'https://<s4e-core-host>/api/assets' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: token=<your-session-token>' \
  -d '{
    "target": "10.0.1.0/24",
    "group_id": 1,
    "asset_type": "ip_range"
  }'

Scan Types for Internal Assets

Port Scanning

Discover open ports and running services across internal IP ranges. Useful for identifying shadow IT, unauthorized services, and misconfigured hosts.

Web Application Scanning

Run vulnerability assessments against internal web applications:

• SQL injection, XSS, CSRF, and other OWASP Top 10 checks
• Header security analysis (HSTS, CSP, X-Frame-Options)
• SSL/TLS configuration review
• Authentication and session management testing

Web Crawling

The S4E crawler pipeline discovers endpoints and content on internal web applications:

1. Directory fuzzing (ffuf) -- brute-force common paths and filenames.
2. Deep crawling (Katana) -- follow links and JavaScript-rendered routes.
3. API documentation parsing -- extract endpoints from OpenAPI/Swagger specs.
4. URL unification -- deduplicate and normalize discovered URLs.
5. PII detection -- flag endpoints that expose personally identifiable information.

API Endpoint Discovery

Automatically discover and catalog internal API endpoints, including:

• REST endpoints exposed by microservices
• GraphQL schemas
• gRPC service definitions (via reflection)

Network Considerations

Firewall Rules

Ensure that the Kubernetes nodes running S4E worker pods can reach the target assets:

DNS Configuration

For scanning internal domains, the Kubernetes cluster must be configured to use your internal DNS servers:

# CoreDNS ConfigMap snippet
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    corp.internal:53 {
        forward . 10.0.0.2 10.0.0.3
    }
    .:53 {
        forward . /etc/resolv.conf
    }

Scan Scheduling

Internal scans can be scheduled to run during specific time windows to minimize impact on production systems:

• Configure scan schedules through the web interface or API.
• Use the s4e-scheduler service to define cron-like schedules.
• Set rate limiting to control scan intensity.

Microservice Auto-Start Scheduling

In the on-premises deployment, you can configure the automatic start time of each scanning microservice independently. This gives you fine-grained control over when specific scanning components begin their operations.

Configurable services:

You can set the auto-start schedule for each service through the platform's scheduling interface, allowing you to stagger service start times or align them with your organization's operational windows.

Skip Configuration

Similar to the Cloud version, on-prem deployments support Skip Configuration to define time windows when scans should not run. This prevents scanning during maintenance windows or other sensitive periods. Configure skip rules through the Manage > Manager > Schedule section in the web interface using cron expressions.

Scan Results

Scan results for internal assets are stored and displayed the same way as external asset results:

• Dashboard -- aggregated vulnerability counts by severity.
• Asset detail view -- per-asset findings with remediation guidance.
• Reports -- exportable PDF and CSV reports.
• API -- programmatic access to all scan results.

Results never leave your network perimeter. All data is stored in the local PostgreSQL and MongoDB instances.

Best Practices

1. Start with discovery -- run a broad network scan to discover all reachable hosts before targeted scanning.
2. Group assets logically -- organize assets by business unit, environment (dev/staging/prod), or network segment.
3. Use scan profiles -- create scan profiles tailored to different asset types (web apps vs. infrastructure).
4. Schedule regular scans -- configure recurring scans to detect configuration drift and new vulnerabilities.
5. Review exclusions -- maintain an exclusion list for hosts that should not be scanned (e.g., fragile legacy systems).