Basic infection demo
Mark a phone clean or infected and see the same security status appear at its gateway and at the receiving node. This demonstrates that threat information can follow traffic between networks.
TARASEC APP DEMOS
See threat information follow the traffic.
The TaraSec App includes three practical demonstrations: threat information following traffic, SSH evidence correcting itself when a legitimate connection is attributed, and several devices responding to a real Request for Assistance.
THREE APP DEMOS
From one visible tag to cooperative containment.
SSH attribution and self-correction
Create real SSH rejection evidence at Node A, then use a temporary credential at a non-executing Node B. The central database correlates the session and clears only the reversible evidence created by that demo.
Request for Assistance
Several participants mark their units CLEAN or INFECTED. When the protected server asks for assistance, infected units lose communication with that server and are released automatically after the exercise.
All three are controlled demonstrations. They do not install malware or inspect personal files. Demo 2 uses restricted test services, and Demo 3 applies temporary containment only to the designated demo server.
THE THREE PARTS
A small network path with a visible security signal.
Your phone or computer
This is the unit whose demo security status changes between clean and infected.
A gateway
The gateway routes traffic from your unit into TaraSec's simulated Internet and keeps the unit's current threat information.
An endpoint
A node inside the demo network receives the traffic, reads its TaraSec tag and requests additional threat context from the gateway.
This is a safe status simulation. The demo does not install malware, infect your device or inspect your personal files.
CHOOSE THE RIGHT GATEWAY
The gateway determines which endpoints are available.
Hotspot or your own router
If you are connected directly to a TaraSec Wi-Fi hotspot—or you have configured your own TaraSec gateway and routing—the choice is straightforward: that hotspot or router is your gateway.
The app asks the selected gateway which endpoints it handles. A gateway with one configured endpoint selects it automatically; a gateway with several lets you choose.
WireGuard demo network
If you joined using the TaraSec QR code and WireGuard configuration, route selection is more specialised. TaraSec currently provides three designated gateways in the demo network, primarily for testing and backup.
Squash
Gateway: 100.68.25.154
Endpoint: Tomato — 100.68.22.33
Squash handles this single demo endpoint, so Tomato is selected automatically.
Audi
Gateway: 100.68.153.251
Endpoint: Porsche — 100.68.187.10
Audi handles this single demo endpoint, so Porsche is selected automatically.
Standard gateway
Gateway: 100.68.165.190
This gateway handles the remaining configured demo endpoints. The app presents a choice; the cheese-named nodes are the endpoints normally used for testing.
The endpoint list comes from the gateway itself. A later version may allow broader selection of other participating nodes where their configuration and access policy permit it.
DEMO 1 · BASIC INFECTION DEMO
Change the status, then observe it at the destination.
Once the gateway and endpoint are selected, the app can simulate the phone becoming infected. The selected gateway stores the phone's demo infection status because it is the network component responsible for that unit and its outgoing traffic.
The app then polls the receiving endpoint. The endpoint reads the TaraSec tag carried with the TCP traffic, obtains more detailed threat information from the responsible gateway and returns the observed status to the app.
This lets you see whether the receiving node knows that the source unit is marked clean or infected—without actually compromising the device.
DEMO 2 · SSH SELF-HEALING
Rejected traffic becomes evidence—then corrects itself when attribution is proven.
The app starts a short-lived, database-authoritative session and assigns two test targets plus a temporary classroom credential.
First, connect to Node A. It rejects SSH, creating ordinary rejection evidence. TaraSec receives the report and marks the source unit infected. Then connect to Node B with the temporary credential. Node B is a non-executing honeypot: it exposes no shell, files or real account.
If the database can correlate the complete connection tuple with the active demo session, it validates the legitimate connection and clears only the reversible evidence created by this demo. Independent or ambiguous evidence remains for the hotspot owner to review.
DEMO 3 · REQUEST FOR ASSISTANCE
See several networks cooperate to protect one requesting server.
Anyone can start or join a short community-containment exercise. Each participant marks the local phone or unit CLEAN or INFECTED, while the exercise defines a countdown.
At zero, the protected demo server issues a real TaraSec Request for Assistance. Participating gateways temporarily stop units marked INFECTED from communicating with that server. Their status polling visibly stops, while CLEAN units remain connected.
Read the full explanation of Demo 3 →
After the chosen containment period, communication is released automatically and polling resumes. This demonstrates local enforcement, measured containment and recovery—not central control of all Internet access.
ADD YOUR OWN TEST ENDPOINTS
Tell your TaraSec hotspot which endpoints it handles.
The most flexible way to add and test your own nodes is to operate a TaraSec hotspot. When a phone is connected directly to it, the app automatically uses that hotspot as the gateway and hides the remote WireGuard gateway choices.
Edit /etc/tarasecfw.conf on the hotspot or gateway. DEMO_NODES contains comma-separated endpoint addresses; DEMO_NODE_NAMES contains their display names in the same order.
# One endpoint
DEMO_NODES="100.68.22.33"
DEMO_NODE_NAMES="Tomato"
# Several endpoints
DEMO_NODES="100.68.176.110,100.68.149.164,100.68.51.247"
DEMO_NODE_NAMES="Roquefort,Camembert,Gouda"
# Optional; defaults to web access on ports 80 and 443
HOTSPOT_ALLOWED_NETBIRD_TCP_PORTS="80,443"
# TaraSec notifications, threat-data requests and syslog
UDP_PORTS="5551,5552,514"The number and order of names should match the addresses. The gateway's /script/appDemoConfiguration.php endpoint reads these settings and supplies the list to the app. The app refreshes it automatically.
Publishing an endpoint and permitting traffic are related: after changing the configuration, reapply the current TaraSec firewall policy when that gateway uses it for forwarding. Existing remote administration should be checked before changing firewall rules.
Each endpoint must also serve the TaraSec app endpoints, including /script/appNode.php and /script/appInfection.php. Network reachability alone does not make a server demo-compatible.
The source and current technical instructions are available in the TaraSec Core repository. You can ask an AI assistant to inspect that repository and guide you through gateway setup, routing, endpoint deployment and testing.
WHAT TO REMEMBER
The route and the security information belong together.
Select the gateway responsible for the endpoint you want to test. The gateway supplies the valid endpoint choices, tracks the source unit's threat status and provides the context that lets the receiving node understand the traffic.