CoreDetection
Request Demo
Operating

Protected Networks

CoreDetection only evaluates traffic destined for protected prefixes you define. Two YAML files work together: network.yaml lists CIDRs the detection engine monitors, and protected-networks.yaml tells the flow collector how to classify destinations (including the customers role used by default detection filters).

network.yaml (detection engine)

Path: /opt/coredetection/network.yaml (override with network_config_file in [general]). The engine loads this file at startup and on POST /reload.

# Protected prefixes monitored by CoreDetection.
# Add the CIDR ranges you want to detect attacks against.

networks:
  - 203.0.113.0/24
  - 198.51.100.0/24

Shipped default is 0.0.0.0/0 (monitor everything). In production, list only customer / infrastructure prefixes you protect — tighter lists reduce noise and query cost.

Verify loaded prefixes via the API:

curl -H "X-API-Key: YOUR_KEY" \
  http://localhost:9009/CoreDetection/api/v0/config/network

protected-networks.yaml (flow collector)

Path: /opt/coredetection-flow/config/protected-networks.yaml. The bundled Akvorado flow pipeline includes this file and tags enriched flow records with a destination network role.

# Protected customer prefixes for flow classification (DstNetRole = customers).
# Add one block per prefix. Example:

203.0.113.0/24:
  name: customer-example
  role: customers

198.51.100.0/24:
  name: customer-acme
  role: customers

Each prefix block needs a role. The default detection filter dst_net_role = customers in [filters] only evaluates flows whose enriched destination role matches — so prefixes you want monitored must appear here with role: customers (or change the filter to match your role naming).

Keep both files aligned. Every prefix in network.yaml should have a matching entry in protected-networks.yaml with the correct role, or detection queries may return no traffic for that destination.

dst_net_role filter

In config.ini → [filters], dst_net_role selects which enriched destination role the detection query evaluates:

[filters]
dst_net_role = customers
in_if_boundary = external
KeyPurpose
dst_net_roleDestination network role from flow enrichment (default customers)
in_if_boundaryOptional ingress boundary filter (external by default; blank to disable)

Tune live via PUT /config/filters or the portal Settings → Filters page. See Configuration → Traffic Filters.

Portal Settings → Networks

The Appliance Portal → Settings → Networks shows a read-only view of prefixes loaded from network.yaml via GET /config/network.

To add or remove prefixes:

  1. Edit /opt/coredetection/network.yaml on the appliance (or use the portal Config Editor).
  2. Add matching blocks to protected-networks.yaml with the correct role.
  3. Restart the flow stack if you changed protected-networks.yaml, then call POST /reload on the engine (or restart coredetection).

Workflow checklist

  • Export flows from edge routers — Router Flow Export
  • List customer CIDRs in network.yaml
  • Classify those CIDRs in protected-networks.yaml with role: customers
  • Confirm traffic in portal Traffic Monitor
  • Adjust dst_net_role only if you use custom role names

Next steps