Denial of Service
Learning Goals
- Importance of the availability aspect of cybersecurity
- Attacks on availability: denial of service (DOS) and distributed DOS
- Mitigation techniques, such as rate limiting
Description
By this point students might have already discovered the simplest - yet very effective - attack of DoS. The main real world example of these is when more traffic is sent to some network address than can be adequately handled. When this happens, service is interrupted for actual users. We will further demonstrate this by having one robot do a series of actions in a repeating pattern as the victim.
Then attackers will interrupt the robot - making it unavailable to the legitimate user's requests - by bombarding the target robot with repeated commands of a different nature. The attackers' commands should be different in nature from the robot's intended behavior to show that the attackers aren't actively changing the instructions related to the original task.
The provided examples of patterns for the target robot are tuned to demonstrate this loss of commands easily. The students can be instructed to use any non set speed commands on repeat to overwhelm the robot and make it miss instructions from its owner. Using the beep command on repeat with a low frequency and duration (such as beep 10 10) is a good option for covert attacking.
Glossary
Required/Authorized Commands
- set total rate
- set client rate
- reset rate
Activities
- Simple Rate Control
- NetsBlox will provide an RPC to start rate control: the students will be able to set a rate for their own robots that controls the maximum frequency the server will send commands to it. This approach won’t help much since the legitimate commands will still get lost at a high probability during a DoS attack. Meaning everyone's commands, including the legitimate user's commands, are ignored after a threshold frequency is reached.
- Source-Specific Rate Control
- There is another Roboscape RPC designed to start source-specific rate control: the students will be able to set a rate for their own robots that controls the maximum frequency the server will accept requests from each client to send commands to the given robot. The RPC will have arguments for the rate and the timeout a given client will be locked out if the rate exceeds the limit. This approach will prevent the DoS attack, but with a caveat: the legitimate programs will have to be careful not to exceed the rate limit.
- Tug of War Challenge Revisited
- This challenge is a perfect fit for reinforcing the ideas of rate control. The competition changes drastically as either everyone combined or a specific user is suddenly limited in the number of actions that can be taken per second.
Common Pitfalls
- Long-duration beeps will lock the robot
- Students might lock themselves out of their robot by getting rate limited.
- The maximum penalty duration is not so high that waiting is impractical, but they could always use the reset button to reset the setting on the robot and get control back.
Hints
Generally a good time to switch to these rate control techniques is when students have learned that using a forever loop to spam the commands they want to their robots is an effective strategy for Tug of War.
Next Steps
- Any previous challenge could be redone with the added attack surface of DOS.
Additional Reading