A receiver rejects traffic
A participating firewall observes and rejects suspicious or unwanted traffic.
DEMO 3 · REQUEST FOR ASSISTANCE
Let the network help before one server has to defend itself alone.
Demo 3 shows how a server under pressure can ask participating networks not to send traffic from units already known to be infected.
THE PROBLEM
Brute-force attacks can deny service or try to break in.
Distributed denial-of-service attacks are a major challenge for Internet services. An online bank may be designed to serve 10,000 concurrent customers. If a botnet of 100,000 infected computers sends traffic or simulates simultaneous login attempts, the service may become unavailable to its real customers.
The attackers may not steal anything during the attack, but the losses can still be substantial: customers lose access, the organisation loses income, trust and reputation suffer, and the incident can trigger expensive emergency work and additional security investment.
Password guessing is another form of brute-force attack. Its purpose is different: repeated login attempts are used to break into an account or machine and steal, alter or misuse whatever the attacker can reach.
TODAY'S RESPONSE
Defenders often block addresses after the attack reaches them.
When an attack happens, operators commonly begin blocking source addresses or ranges. They may use lists of addresses believed to be infected. During a severe attack, broad blocks may be applied—even to large networks, countries or regions—which can exclude substantial amounts of innocent traffic together with the attack.
This leaves each targeted service doing much of the defensive work after unwanted traffic has already crossed the Internet and reached its infrastructure.
THE TARASEC APPROACH
Share the warning, then contain unwanted traffic closer to its source.
The sender's network is notified
TaraSec reports the rejection to the network responsible for the sending unit.
The unit is assessed
The cause may be infection, a mistyped address, a configuration error or deliberate abuse. AI and human operators can assess the evidence; one rejection is not automatically treated as proof of criminal intent.
TaraSec is built on the principle that compromised units should not be free to attack thousands of systems while every receiving server is left to defend itself alone.
REQUEST FOR ASSISTANCE
A service under pressure can ask participating networks for help.
A server experiencing an attack or other serious distress can ask participating ISPs and gateways not to send it traffic from units already marked infected. This enables destination-specific containment at the source network, which knows the unit from earlier reports.
The request does not ask every network to disconnect the unit from the Internet. It identifies the protected service that needs assistance. Each participating network retains control of its own response.
WHAT DEMO 3 DOES
Test the real cooperation logic without launching an attack.
Participants join the same demo session and mark their phone or unit either CLEAN or INFECTED. A countdown replaces the real-world alarm trigger.
When the countdown reaches zero, the demo server sends a real TaraSec Request for Assistance. Participating gateways temporarily stop units marked INFECTED from communicating with that protected server. CLEAN units should continue to reach it. The app shows the participants and lets you observe which units stop reporting and which later recover.
The system knows that this is a demonstration. The request is released automatically when the exercise ends, after which communication with the protected server should return.
FROM DEMO TO REAL USE
In production, service conditions replace the countdown.
A real Request for Assistance would be triggered by an operator or an authorised automated system using signals such as server load, connection rates, firewall observations or database health. It would not normally wait for a demonstration timer.
The effect is otherwise the same: the requesting service identifies itself, the request is distributed to cooperating networks, and those networks apply their policy to traffic from units they already consider infected. Demo 3 exercises the same Request for Assistance and release functions used for real traffic.
IMPORTANT NETWORK BEHAVIOUR
What CLEAN and INFECTED mean during the demonstration.
TaraSec traffic tagging
When you mark the unit INFECTED, that status is stored on the local TaraSec gateway. Unless a technical error occurs, its traffic to other TaraSec participants will be tagged accordingly. There are currently no other TaraSec participants involved beyond the systems prepared for this demonstration.
The Request for Assistance itself contains communication only with the protected demo server. It is released automatically when the demo ends.
Regular Internet traffic
Depending on the phone or unit and the TaraSec hotspot configuration, regular Internet traffic may use the hotspot, may be routed through the phone's mobile-data connection, or may be unavailable during the demonstration.
Some TaraSec Wi-Fi installations intentionally restrict ordinary Internet access so the event uses little mobile data and only approved demo traffic passes through the hotspot.
TRY IT
Join a controlled TaraSec challenge.
Demo 3 is designed to make cooperative containment visible: one service asks for help, several networks respond, and the result can be observed without staging a real attack.