A connected unit makes a test connection
The app connects to an operator-configured honeypot or reporting firewall rule. The receiving node detects the event and reports it normally to the DB server. The app does not manufacture an attack report.
DEMO 5 · PARTNER ACCOUNTABILITY
What happens when a partner stops tagging?
A gateway may continue forwarding traffic after losing TaraSec tagging. Demo 5 tests whether ordinary rejection reports reveal that failure and whether other participating receivers can protect themselves independently.
The normal security path triggers the test.
The DB associates it with a partner
The observed source address is matched to the registered partner router or subnet. The partner is notified through the normal reporting endpoint and given time to tag subsequent traffic.
Repeated untagged traffic becomes evidence
An initial untagged connection can be expected before the source unit is reported. Continued untagged rejections after successful notification and the grace period indicate a tagging failure. Missing packet evidence remains unknown.
Receivers enforce a temporary restriction
The DB distributes a restriction to enabled receiving nodes. Each receiver applies its own expiring firewall rule and acknowledges enforcement. The offending partner cannot clear that restriction itself.
A partner address does not identify the infected device.
With NAT, a gateway and its connected devices may share the same visible address. With routed addresses, the registered subnet identifies the responsible partner network. Neither alone proves the router itself is infected.
Demo 5 restricts the observed source address as a /32, rather than automatically blacklisting an entire subnet. Behind NAT this can affect other users sharing that address, which is why the exercise is enabled only on a dedicated test gateway.
Read the result in the app.
The app keeps polling the DB and displays receiver evidence, observed tag, partner notification, tagging status, blacklist scope and expiry, and receiver acknowledgements. A blacklist issued by the DB is shown as pending until every selected receiver has confirmed application. Zero receiving nodes is not success.
A healthy gateway should produce tagged traffic after notification. To test failure, the operator arranges missing tagging on the dedicated gateway—for example, a test deployment without tarakernel. Demo 5 does not install malware or stop services automatically.
A connection timeout is only an observation. It does not prove that tagging failed or that a blacklist was applied. Use “Copy debug info for AI” to inspect the complete result.
Expiry and recovery remain visible.
Restrictions last for the configured test period and expire in the receiver's kernel even if its polling worker or the DB becomes unavailable. “Release this exercise” issues an early release; removal is confirmed separately by each receiver. Expiry does not prove the partner has repaired tagging.
This feature requires the Demo 5 database migration, enabled test configuration, updated receiving nodes and app. The test verifies only the selected receivers; it does not claim that every network on the Internet blocks the source.